Каким образом пользователи идентифицируются в ос windows

11

Лекция №4

Вопросы:

1. Этапы
идентификации и аутентификации
пользователя, реализуемые ОС Windows.

2. Протоколы
аутентификации Windows.

1.Этапы идентификации и аутентификации пользователя, реализуемые ос Windows

Аутентификация
представляет собой один из компонентов
любой компьютерной системы
управления доступом.
Как показано на рисунке 1, системы
управления доступом обеспечивают
идентификацию, аутентификацию, авторизацию
и отчетность.

Рисунок 1. Механизмы
управления доступом и аутентификация
в Windows

1. Идентификация

Это первый этап
входа в КС. Как известно, на этом этапе
вводится имя пользователя КС (логин).

При этом ОС (а
именно, процесс Winlogon, отвечающий за вход
в КС и выход из неё) создает уникальный
идентификатор пользователя (SID),
представляющий собой набор данных,
который уникально идентифицирует объект
безопасности (пользователя, группу,
компьютер, учетную запись службы).

Пример.

S-1-5-21-1463437245-1224812800-863842198-1128

1 — №версии;

5 – код агента ОС
(назначающей SID);

Четыре кода
субагентов-попечителей;

1128 – RID или средство
создания уникальных SID.

SID назначается
компьютеру при установке ОС. Далее
Winlogon назначает SID локальным учетным
записям на данном компьюторе.

SID(ЛУЗ) = SID (К) + RID
пользователя.

RID = 500 – администратор;

RID = 501 – гость;

RID = 1000, 1001….. –
пользователи.

Процесс Winlogon
создает уникальный локальный SID для
пользователя. Если вход пользователя
прошел успешно, этот SID будет включен в
маркер доступа.

Маркер доступа
(МД) –
идентификатор контекста защиты процесса
или потока. Он наследуется всеми
процессами, запущенными от имени
пользователя.

Для защиты от НСД
используются два элемента МД:

1. SID пользователя
   и SIDы групп, в которые входит пользователь;

2. Список привилегий
   (прав), сопоставленных с маркером.

2. Аутентификация

После того как
субъект безопасности вводит с клавиатуры
необходимую для идентификации информацию
(например, имя пользователя), он должен
ввести с клавиатуры или представить
частную информацию для аутентификации
(например, пароль или PIN-код).

В Windows субъект
безопасности вводит эту информацию на
экране регистрации с помощью программ
Microsoft Graphical Identification and Authentication DLL
(msgina.dll) и Winlogon.exe. Протокол аутентификации
и механизм системы шифруют представленную
информацию на персональном компьютере
и передают запрос аутентификации.

Службой аутентификации
Windows может быть база данных SAM или Active
Directory.

База данных SAM
обслуживает локальные
процедуры регистрации и регистрацию
на контроллерах домена Windows NT 4.0. Эта
база обязательно имеется на каждом
компьютере с операционной системой
Windows. В ней хранится вся информация,
используемая для аутентификации
пользователей Windows при интерактивном
входе в систему и при удаленном доступе
к ней по компьютерной сети.

База
данных SAM представляет собой один из
кустов (hive) системного реестра (registry)
Windows. Этот куст принадлежит ветви
(subtree) HKEY_LOCAL_MACHINE и называется SAM. Физически
база данных SAM располагается в каталоге
wmnt_rootSystem32ConfIg (winnt_root — условное
обозначение каталога с системными
файлами Windows) в отдельном файле, который
тоже называется SAM.

Информация в базе
данных SAM хранится в основном в двоичном
виде. Доступ к ней обычно осуществляется
через диспетчер учетных записей. Изменять
записи, находящиеся в базе данных SAM,
при помощи программ, позволяющих напрямую
редактировать реестр Windows (REGEDT или
REGEDT32), не рекомендуется. По умолчанию
этого и нельзя делать, т. к. доступ к базе
данных SAM запрещен для всех без исключения
категорий пользователей операционной
системы Windows.

Именно
в учетных записях базы данных SAM находится
информация о пользовательских именах
и паролях, которая необходима для
идентификации и аутентификации
пользователей при их интерактивном
входе в систему. Как и в любой другой
современной многопользовательской
операционной системе, эта информация
хранится в зашифрованном виде. В базе
данных SAM каждый пароль пользователя
представлен в виде двух 16-байтовых
последовательностей (хешей), полученных
разными методами

Active
Directory
аутентифицирует запросы в Windows
2000/XP/Vista
или доменах более поздних версий этой
операционной системы. Протокол
аутентификации используется для
транспортировки запросов аутентификации
и последующих транзакций между экраном
регистрации и службой аутентификации.
Чуть ниже каждый протокол аутентификации
будет рассмотрен отдельно.

Рис.2.
Компоненты, участвующие в процессе
аутентификации.

При
интерактивном входе в систему (в отличие
от входа через сеть) происходит
взаимодействие с процессами Winlogon,
Lsass,
одним или несколькими пакетами
аутентификации, а также SAM
или Active
Directory.
Пакеты
аутентификации
(authentication
packages)
— это DLL-модули,
выполняющие
проверки, связанные с аутентификацией.

Windows использует
два стандартных пакета аутентификации
при интерактивном входе: Kerberos и MSV1_0.

Пакетом
аутентификации Windows
для интерактивного входа в домен
является
Kerberos.

Пакет
MSV1_0
используется для
интерактивного входа на локальные
компьютеры.

Таким
образом, пакетом аутентификации по
умолчанию в автономной
системе
Windows является пакет — MSV1_0
(WindowsSystem32Msvl_0.dll).

Пакет
аутентификации MSV1_0 принимает имя
пользователя и хешированную версию
пароля и посылает базе SAM запрос на
получение информации из учетной записи,
включая пароль, группы, в которые входит
пользователь, и список ограничений по
данной учетной записи. Сначала MSV1_0
проверяет ограничения, например
разрешенное время или типы доступа.
Если ограничения из базы данных SAM
запрещают регистрацию пользователя в
это время суток, MSV1_0 возвращает LSA статус
отказа.

Далее
MSV1_0 сравнивает хешированный пароль и
имя пользователя с теми, которые хранятся
в SAM.

Winlogon — процесс,
отвечающий за взаимодействие с
пользователем.

Он координирует
вход, запускает первый процесс при входе
в систему данного пользователя,
обрабатывает выход из системы и управляет
множеством других операций, имеющих
отношение к защите, — вводом паролей
при регистрации, сменой паролей,
блокированием и разблокированием
рабочих станций и т. д. Процесс Winlogon
должен обеспечить невидимость операций,
связанных с защитой, для других активных
процессов. Так, Winlogon гарантирует, что в
ходе этих операций недоверяемый процесс
не сможет перехватить управление рабочим
столом и таким образом получить доступ
к паролю.

Winlogon получает имя
и пароль пользователя через Graphical
Identification and Authentication (GINA) DLL Стандартная
GINA — WindowsSystem32 Msgina.dll. Msgina выводит
диалоговое окно для входа в систему.

Позволяя заменять
Msgina другими GINA-библиотеками, Windows дает
возможность менять механизмы идентификации
пользователей. Например, сторонний
разработчик может создать GINA для
поддержки устройства распознавания
отпечатков пальцев и т.д.

Winlogon — единственный
процесс, который перехватывает запросы
на регистрацию с клавиатуры. Получив
имя и пароль пользователя от GINA, Winlogon
вызывает LSASS для аутентификации этого
пользователя. Если аутентификация
прошла успешно, процесс Winlogon активизирует
оболочку. Схема взаимодействия между
компонентами, участвующими в процессе
регистрации, показана на слайде.

Соседние файлы в папке лк

• #

  02.02.2021530.94 Кб28Л9.ppt

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Аутентификация пользователей в ОС Windows

База данных аутентификации в ОС, построенных на технологии NT, имеет название SAM (Security Accounts Manager) и располагается в каталоге WinntSystem32Config [7].

Информация в файле хранится в служебном формате, а доступ к ней ограничен со стороны ОС. Любое обращение к этой базе со стороны пользователя (копирование, чтение, запись и т.д.) блокируется.

Существующие средства Windows, ограничивающие доступ к SAM, не работают корректно, и злоумышленник обходными путями может получить доступ к нему, в том числе скопировать для последующего анализа.

Рассмотрим реализованный Microsoft способ защиты баз данных аутентификации SAM он несанкционированного изучения [5,7].

В SAM для каждой учётной записи пользователя хранится два вида хэшей пароля – хэш LANMAN, используемый для аутентификации сетевых служб и совместимости с ранее разработанными ОС Windows 9x, и хэш NTLM, используемый при локальной аутентификации пользователя.

Алгоритм хэширования LANMAN.

Схема данного алгоритма представлена на рисунке 29.

Шаг 1. Пользовательский пароль преобразуется путем замены всех малых символов, входящих в него, большими.

Шаг 2. Результат преобразуется в 14-символьную цепочку. Если пароль длиннее 14 символов, то лишние символы урезаются; если короче, то недостающие позиции заполняются нулями.

Шаг 3. Полученная цепочка из 14 символов делится на два блока по 7 символов, каждый из которых в дальнейшем обрабатывается независимо.

Шаг 4. Каждый из сформированных блоков используется в качестве ключа шифрования алгоритма DES известной 64-битовой последовательности (4B, 47, 53, 21, 40, 23, 24, 25). На выходе формируются два блока по 8 байт.

Рис. 29. Схема алгоритма хэширования LANMAN

Шаг 5. Конкатенация двух 8-байтных блока является хэшем LANMAN (16 байт).

В алгоритме LANMAN используется свойство стойкости к атакам по открытому тексту алгоритма DES для формирования закрытых паролей. Даже зная 8-байтную последовательность, которая шифруется по данному алгоритму, восстановление ключа шифрования возможно только полным перебором.

Алгоритм LANMAN обладает рядом недостатков, которые значительно снижают его криптостойкость. Перечислим их.

1. Преобразование всех символов в заглавные значительно снижает объем ключевого пространства, которое нужно перебрать злоумышленнику. Данное преобразование уменьшает энтропию паролей.

2. Разбивка пароля на два фрагмента, обрабатываемых независимо, также приводит к значительному снижению объема ключевого пространства.

Предположим, что пароли составляются только из малых и больших английских букв (мощность алфавита равна 52). Так как все символы пароля преобразуются в большие, то мощность алфавита уменьшается до 26. Кроме этого, независимость обработки блоков из 7 символов приводит к тому, что для взлома хэша LANMAN приходится осуществлять перебор не 26 14 вариантов ключей, а 2*26 7 , так как левая и правая части хэша LANMAN подбираются независимо. Таким образом, в силу двух приведенных недостатков, для рассмотренного примера пространство перебора ключей содержит не 52 14 паролей, а 2*26 7 . Перебрать такое количество ключей не трудно.

Алгоритм хэширования NTLM свободен от недостатков, свойственных хэшу LANMAN. NTLM символы не преобразуются к верхнему регистру и могут быть любыми. Разбивка на два блока здесь также не используется. В качестве алгоритма хэширования используется MD4.

Следует отметить, что для совмещения с прошлыми версиями Windows, в базе данных SAM хранятся оба хэша – LANMAN и NTLM (за исключением паролей длины, большей 14). Поэтому, наличие хэша NTLM в SAM никак не усиливает защиту, взломать её злоумышленник может так же быстро, подобрав вначале хэш LANMAN и определив пароль с приближением к верхнему регистру, затем найти истинный пароль, подобрав хэш NTLM путём перекомбинации больших и малых букв.

Дата добавления: 2014-01-11 ; Просмотров: 508 ; Нарушение авторских прав?

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Понятие идентификации и аутентификации пользователей

Тема 3. Идентификация и аутентификация пользователей ОС

В защищенной операционной системе любой субъект доступа, пе­ред тем как начать работу с системой, должен пройти идентификацию, аутентификацию и авторизацию.

Идентификация субъекта доступа заключается в том, что субъект сообщает операционной системе идентифицирующую информацию о се­бе (имя, учетный номер и т.д.) и таким образом идентифицирует себя.

Аутентификация субъекта доступа заключается в том, что субъект предоставляет операционной системе помимо идентифицирующей ин­формации еще и аутентифицирующую информацию, подтверждающую, что он действительно является тем субъектом доступа, к которому отно­сится идентифицирующая информация. Пусть, например, пользователь, входя в систему, ввел имя и пароль. В этом случае имя пользователя яв­ляется идентифицирующей информацией, а известный только ему пароль — аутентифицирующей информацией. Вводя пароль, пользователь под­тверждает, что введенное имя принадлежит именно ему.

Авторизация субъекта доступа происходит после успешной иден­тификации и аутентификации. При авторизации субъекта операционная система выполняет действия, необходимые для того, чтобы субъект мог начать работу в системе. Например, авторизация пользователя в опера­ционной системе UNIX включает в себя порождение процесса, являюще­гося операционной оболочкой, с которой в дальнейшем будет работать пользователь. В операционной системе Windows NT авторизация пользо­вателя включает в себя создание маркера доступа пользователя, созда­ние рабочего стола и запуск на нем от имени авторизуемого пользователя процесса UserInit, инициализирующего индивидуальную программную сре­ду пользователя. Авторизация субъекта не относится напрямую к подсис­теме защиты операционной системы. В процессе авторизации решаются чисто технические задачи, связанные с организацией начала работы в сис­теме уже идентифицированного и аутентифицированного субъекта досту­па.

С точки зрения обеспечения безопасности ОС процедуры идентификации и аутентификации являются весьма ответст­венными. Действительно, если злоумышленник сумел войти в систему от имени другого пользователя, злоумышленник легко получает доступ ко всем объектам операционной системы, к которым имеет доступ этот поль­зователь. Если при этом в процессе работы злоумышленника с системой подсистема аудита генерирует сообщения о событиях, потенциально опасных для безопасности операционной системы, то в журнал аудита за­писывается не имя злоумышленника, а имя пользователя, от имени кото­рого злоумышленник работает в системе.

Хотя аутентификация может осуществляться как для физических пользователей, так и для псевдопользователей – фиктивных пользовате­лей, используемых операционной системой для запуска системных про­цессов, наибольший интерес с точки зрения обеспечения защиты инфор­мации в операционной системе представляет аутентификация физических пользователей. Если в системе принята адекватная политика безопасно­сти, физический пользователь просто не может войти в систему от имени псевдопользователя. Конечно, поскольку псевдопользователи обычно об­ладают в операционной системе весьма большими правами, вход зло­умышленника в систему от имени псевдопользователя дает злоумышлен­нику большие возможности для осуществления несанкционированного доступа, однако на практике осуществить такую атаку на операционную систему крайне трудно. Поэтому в дальнейшем мы будем рассматривать аутентификацию только обычных пользователей.

Дата добавления: 2014-01-07 ; Просмотров: 1045 ; Нарушение авторских прав?

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Аутентификация в системах Windows. Часть 1 — NTLM

Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне.

В рамках данного материала мы будем рассматривать сознательно упрощенное представление процедур аутентификации, достаточное для понимания базового принципа работы, впоследствии данные знания могут быть углублены путем изучения специализированной литературы.

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

• Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
• Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию — это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу — это процесс авторизации, т.е. вашего права здесь находиться.

Точно также, сотрудник полиции, остановив трудового мигранта и проверив его паспорт, просит разрешение на работу, если разрешения нет, то зарубежный гость успешно прошел аутентификацию, но провалил авторизацию. Если аутентификация не пройдена, то до авторизации дело не дойдет.

Для аутентификации в компьютерных системах традиционно используется сочетания имени пользователя и некой секретной фразы (пароля), позволяющей определить, что пользователь именно тот, за кого себя выдает. Существуют также и иные способы аутентификации, например, по смарт-карте, но в данной статье мы их касаться не будем.

Локальная аутентификация

Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

Затем LSA сравнивает хэш введенного пароля и хэш из базы SAM, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и находится там до окончания сеанса пользователя.

В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

• Пароль регистронезависимый и приводится к верхнему регистру.
• Длина пароля — 14 символов, более короткие пароли дополняются при создании хэша нулями.
• Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

Исходя из современных требований к безопасности можно сказать, что LM-хэш практически не защищен и будучи перехвачен очень быстро расшифровывается. Сразу оговоримся, прямое восстановление хэша невозможно, однако в силу простоты алгоритма шифрования возможен подбор соответствующей паролю комбинации за предельно короткое время.

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

Получив запрос от клиента, сервер точно также направит ему запрос сервера, но получив NTLM-ответ он не сможет вычислить значение для проверки на своей стороне, так как не располагает хэшем пароля доменного пользователя, поэтому он перенаправляет NTLM-ответ контроллеру домена и отправляет ему свой запрос сервера. Получив эти данные, контроллер домена извлекает хэш указанного пользователя и вычисляет на основе запроса сервера проверочную комбинацию, которую сравнивает с полученным NTLM-ответом, при совпадении серверу посылается сообщение, что аутентификация прошла успешно.

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

Но и перехваченного хэша может оказаться вполне достаточно, так как NTLM-ответ генерируется на базе пароля пользователя и подлинность клиента сервером никак не проверяется, то возможно использовать перехваченные данные для неавторизованного доступа к ресурсам сети. Отсутствие взаимной проверки подлинности также позволяет использовать атаки плана человек посередине, когда атакующий представляется клиенту сервером и наоборот, устанавливая при этом два канала и перехватывая передаваемые данные.

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере.

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число — запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента. Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

Источник

Протоколы, составляющие основу процедуры

Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows, но ее механизм не изучается системными администраторами досконально. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC). В данной статье речь пойдет сначала об основных принципах аутентификации Windows, а затем о связанных с ней протоколах. В заключение приводятся краткие рекомендации по повышению надежности процедуры аутентификации в сети Windows.

Аутентификация: общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Рисунок 1. Механизмы управления доступом и аутентификация Windows

Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

Отчетность (accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом — отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.

Задачи протокола

Протокол аутентификации должен выполнять по крайней мере две задачи. Во-первых, он должен безопасно передавать транзакции от запросчика в базу данных аутентификации и на любой другой компьютер, на котором размещен соответствующий ресурс. Во-вторых, он должен безопасно и надежно хранить пароль или маркер. Последнее представляет особый интерес для взломщиков паролей. Протокол аутентификации должен защитить введенную пользователем информацию при пересылке в базу данных аутентификации (т. е. SAM или AD). Для этого протокол подписывает, скрывает или шифрует транзакцию. Кроме того, ей присваивается временная метка, чтобы взломщик не мог воспользоваться учетными данными в будущем. Чтобы не позволить немедленно извлечь пароль пользователя из базы данных, протокол должен обеспечить скрытное хранение паролей в базе данных аутентификации.

В течение более чем десяти лет протоколы аутентификации в основном обеспечивали защиту путем сохранения паролей в скрытой форме (обычно хешированной) в базе данных аутентификации и полного запрета на передачу паролей между запросчиком и базой данных аутентификации простым текстом (даже в скрытой форме). Процесс запрос—ответ выглядит следующим образом:

1. Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.
2. Сервер аутентификации генерирует случайное произвольное значение (называемое запросом — challenge) и посылает его запросчику.
3. Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом — response) серверу аутентификации.
4. Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

В протоколах аутентификации используется процесс запрос—ответ, поэтому пароль никогда не передается через сеть.

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Протоколы аутентификации Windows

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

Если раньше LAN Manager был вполне приемлем, то сейчас он считается очень ненадежным. С помощью специальных инструментов пароли, зашифрованные методом хеширования LAN Manager, можно всего за несколько секунд преобразовать в простой текст. LM-хешам свойственны принципиальные недостатки, а также имеется ряд уязвимых мест:

• пароли могут состоять из ограниченной последовательности 128 символов ASCII;
• длина пароля не превышает 14 символов;
• если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
• перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLM

С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.

NTLMv2

В итоге выяснилось, что и NTLM уязвим, и специалисты Microsoft подготовили NTLMv2, который до сих пор считается достаточно надежным, хотя сейчас предпочтительный протокол — Kerberos. NTLMv2 по-прежнему широко используется для локальной регистрации и в некоторых других случаях. NTLMv2 похож на NTLM, но в хеше пароля NTLMv2 используется аутентификация сообщений HMAC-MD5, а последовательности запрос—ответ присваивается метка времени, чтобы предотвратить атаки, в ходе которых взломщик записывает учетные данные и впоследствии их использует.

В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

• взаимная аутентификация между клиентом и сервером;
• надежная защита пароля, так как Windows пересылает пароль только при начальном обращении, а не в каждом событии аутентификации и все сеансы связи шифруются;
• последовательность запрос-ответ с меткой времени не позволяет взломщику использовать перехваченный пароль по прошествии определенного времени;
• серверный процесс может обращаться к удаленному ресурсу от имени пользователя;
• интероперабельность.

Краткое описание работы Kerberos:

1. После успешной обычной аутентификации компьютер пользователя запрашивает билет безопасности из сервера Kerberos (DC) для будущих запросов аутентификации.
2. Сервер Kerberos выдает запросчику билет для участия в будущих событиях аутентификации и авторизации без повторного предъявления первоначальных учетных данных аутентификации.
3. Когда запросчику нужно обратиться к ресурсу сервера-участника, он получает другой билет доступа от сервера Kerberos и предъявляет его серверу ресурса для проверки.
4. Первоначальные учетные данные аутентификации не передаются по сетевым каналам ни в одном из последующих сеансов аутентификации (до тех пор, пока не истечет срок действия билета, выданного на этапе 2).

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

• Отключить хранение LM-хешей, как описано в статье Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» (http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Это делается для того, чтобы помешать взломщикам открыть исходный пароль.
• Отключить все протоколы аутентификации, кроме NTLMv2 и Kerberos (после исчерпывающего тестирования). Процедура описана в статье Microsoft TechNet «Network security: LAN Manager authentication level» (http://www.microsoft.com/resources/ documentation/windowsserv/2003/ standard/proddocs/en-us/576.asp).
• Запретить начальную загрузку со сменных носителей, чтобы предотвратить запуск инструментов взлома пароля в обход операционной системы. Запрет начальной загрузки со всех дисков, кроме выбираемого по умолчанию, предотвращает доступ автономных программ взлома пароля к базе данных аутентификации, где хранятся хеши паролей.
• Пользователи должны назначать сложные пароли длиной не менее 8 символов.
• Пользователи должны менять свои пароли по крайней мере раз в квартал.
• Активизировать блокировку учетной записи хотя бы на одну минуту с автоматическим сбросом. Это предотвращает разгадывание паролей в сети.

Обязанности пользователей

Благодаря NTLMv2, Kerberos и смарт-картам Windows располагает надежными механизмами аутентификации, устойчивыми к подслушиванию и атакам с применением метода перебора. Но оптимальные процедуры и надежные протоколы аутентификации не помогут, если пользователи назначают слабые пароли. Необходимо научить пользователей правильно выбирать пароли и добиться, чтобы пароли были сложными и надежными.

Роджер Граймз — Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. roger@banneretcs.com

А.Щеглов, К.Щеглов

Идентификация и аутентификация – это один из основных
механизмов защиты, который, пожалуй, на сегодняшний день наиболее исследован.
Вместе с тем, большинство исследований посвящено различным способам хранения и
ввода идентификационной информации о пользователе. Однако разработчики средств
защиты почему-то забывают (что наглядно иллюстрируют возможности большинства
представленных на рынке средств защиты), что задача иденетификации и
аутентификации в своей постановке, когда речь заходит о компьютерной
безопасности, куда шире, чем задача контроля входа пользователя в систему.

Требования нормативных документов к механизму идентификации и
аутентификации

Прежде всего, напомним основные понятия. Идентификация —
это процесс распознавания элемента системы, обычно с помощью заранее
определенного идентификатора или другой уникальной информации — каждый субъект
или объект системы должен быть однозначно идентифицируем. Аутентификация — это
проверка подлинности идентификации пользователя, процесса, устройства или
другого компонента системы (обычно осуществляется перед разрешением доступа).

Прежде всего, обратимся к формализованным требованиям в
области защиты информации, попробуем в них найти ответ на вопрос, какими же
функциями должен быть наделен механизм идентификации и аутентификации?
Формализованные требования к механизму идентификации и аутентификации
пользователей задаются действующим сегодня нормативным документом
«Гостехкомиссия России. Руководящий документ. Средства вычислительной
техники. Защита от несанкционированного доступа к информации. Показатели
защищенности от НСД к информации».

Для СЗИ от НСД, используемых для защиты конфиденциальной
информации (5 класс СВТ) требования к механизму идентификации и аутентификации
состоят в следующем:

●     Комплекс
средств защиты информации (КСЗ) должен требовать от пользователей
идентифицировать себя при запросах на доступ.

●     КСЗ
должен подвергать проверке подлинность идентификации — осуществлять
аутентификацию.

●     КСЗ
должен располагать необходимыми данными для идентификации и аутентификации.

●     КСЗ
должен препятствовать доступу к защищаемым ресурсам неидентифицированных
пользователей и пользователей, подлинность идентификации которых при
аутентификации не подтвердилась.

Видим, что, выдвигается требование, состоящее в
необходимости идентификации и аутентификации пользователя именно при запросах
на доступ.

Заметим, что в требованиях к СВТ 4-го класса защищенности
вообще задачи идентификации и аутентификации пользователя при входе в систему и
при запросе на доступ разделены на две самостоятельные задачи, кроме того,
здесь появляется некое понятие «субъект» в общем виде.

Что же представляет собою запрос на доступ к ресурсу? В
общем случае подобный запрос может быть охарактеризован тем, какой пользователь
обращается к ресурсу (идентификатор пользователя, определяющий, кому нужен
ресурс), какой процесс (приложение) обращается к ресурсу (идентификатор
процесса, определяющий для решения каких задач пользователю нужен ресурс), и,
собственно, к какому ресурсу осуществляется обращение (идентификатор объекта
доступа).

Естественно, возникает вопрос, с какой целью необходима
какая-либо идентификация и аутентификация субъекта и объекта доступа при
запросах на доступ к ресурсу. Ведь в любой системе защиты предполагается, что
реализуется механизм идентификации и аутентификации пользователя при входе в
систему. Результатом этого является однозначная идентификация пользователя,
запускаемые им процессы наследуют этот идентификатор, т.е. именно от лица
идентифицированного пользователя и обращаются к ресурсу, на чем, кстати говоря,
и строится в своей основе разграничительная политика доступа к ресурсам. С
объектом доступа вообще все понятно, например, файловый объект, казалось бы,
однозначно идентифицируется своим полнопутевым именем. Какие здесь еще
проблемы?

Задача идентификации и аутентификации субъекта «пользователь» при
запросах на доступ

Этапы идентификации и аутентификации пользователя, реализуемые ОС Windows

Этапы идентификации и аутентификации пользователя,
реализуемые в системе (на примере ОС Windows), представлены на рис. 1.

Первый шаг
идентификации, поддерживаемый режимом аутентификации, реализуется при входе
пользователя в систему. Здесь следует выделить возможность входа в штатном и в
безопасном режиме (Safe Mode). В порядке замечания отметим, что принципиальным
отличием безопасного режима является то, что при запуске системы в безопасном
режиме можно отключить загрузку сторонних по отношению к системе драйверов и
приложений. Поэтому, если в системе используется добавочная СЗИ от НСД, можно
попытаться загрузить систему в безопасном режиме без компонент СЗИ от НСД, т.е.
без средства защиты. С учетом же того, что загрузить систему в безопасном
режиме может любой пользователь (в Unix системах – только Root), то СЗИ от НСД
должна обеспечивать возможность входа в систему в безопасном режиме (после
идентификации и аутентификации) только под учетной записью администратора.

Второй шаг
состоит в запуске пользователем процессов, которые уже, в свою очередь,
порождают потоки (именно потоки в общем случае и осуществляют обращение к
ресурсам). Все работающие в системе процессы и потоки выполняются в контексте
защиты того пользователя, от имени которого они так или иначе были запущены.
Для идентификации контекста защиты процесса или потока используется объект,
называемый маркером доступа (access token). В контекст защиты входит
информация, описывающая привилегии, учетные записи и группы, сопоставленные с
процессом и потоком. При регистрации пользователя (первый шаг, см. рис. 1) в
системе создается начальный маркер, представляющий пользователя, который входит
в систему, и сопоставляющий его с процессом оболочки, применяемой для
регистрации пользователя. Все программы, запускаемые пользователем, наследуют
копию этого маркера. Механизмы защиты в Windows используют маркер, определяя
набор действий, разрешенных потоку или процессу.

Рис.1. Этапы
идентификации и аутентификации пользователя

В общем случае пользователь имеет возможность запуска
процесса как с собственными правами, так и под учетной записью другого
пользователя. Запуск пользователем процесса под другой учетной записью возможен
только после выполнения процедуры аутентификации – пользователь должен ввести
идентификатор и пароль, соответствующие той учетной записи, под которой им
будет запущен процесс (например, подобную возможность в ОС Windows
предоставляет утилита runas.exe, но, начиная с ОС Windows XP, эта функция уже
вынесена в проводник — ее можно реализовать, нажав правой кнопкой мыши на
выбранном в проводнике исполняемом файле).

В порядке замечания отметим следующее. С одной стороны,
это очень полезная опция, которая может быть использована в корпоративных
приложениях, когда на одном компьютере требуется обрабатывать конфиденциальные
и открытые данные. При этом предполагается, что для обработки данных различных
категорий создаются различные учетные записи. Данная опция предполагает, что
одновременно (без перезагрузки) можно обрабатывать данные различных категорий,
например, под одной учетной записью обрабатывать необходимым приложением
конфиденциальные данные, под другой учетной записью запустить
Internet-приложение (у Вас на мониторе может быть открыто одновременно два
окна). Естественно, что реализация данной возможности выставляет и
дополнительные требования к СЗИ от НСД (например, при подобном запуске
приложения ОС Windows между пользователями не изолируется буфер обмена, который
в ОС является «принадлежностью» рабочего стола).

Однако важнейшей особенностью рассматриваемого способа
запуска процесса является то, что при этом система начинает функционировать в
многопользовательском режиме – в системе одновременно зарегистрировано
несколько пользователей. Как следствие, может возникнуть проблема однозначной
идентификации пользователя при доступе к ресурсу, что характерно для решения
задачи реализации разграничительной политики доступа к устройствам (об этом —
ниже).

Третий шаг
состоит в порождении процессом потоков, которые собственно и обращаются к
ресурсам. Система предоставляет разработчикам приложений сервисы олицетворения.
Сервис олицетворения (impersonation) предоставляет возможность отдельному
потоку выполняться в контексте защиты, отличном от контекста защиты процесса,
его запустившего, т.е. запросить олицетворить себя с правами другого
пользователя, в результате — действовать от лица другого пользователя. Как
следствие, именно на этом этапе и возникают вопросы корректности идентификации
и аутентификации пользователя при запросе доступа к ресурсам, а задача
идентификации и аутентификации пользователей при запросах на доступ сводится к
контролю корректности олицетворения.

В порядке замечания отметим, что аналогичная ситуация
имеет место и в ОС семейства Unix, где существуют понятия идентификатора и
эффективного идентификатора (под которым собственно и осуществляется запрос
доступа к ресурсам).

Вывод.
Требование «КСЗ должен обеспечивать идентификацию пользователей при
запросах на доступ…» актуально и должно реализовываться современными СЗИ
от НСД. При этом задача защиты при выполнении этого требования сводится к
контролю корректности олицетворения при запросах доступа к ресурсам, т.к.
именно использование сервиса олицетворения может привести к неконтролируемой
смене исходного идентификатора.

Реализация механизма идентификации и аутентификации при запросах доступа к
ресурсам

В общем виде решение задачи должно состоять в следующем.
При запросе доступа к ресурсу должны выявляться факты произошедшего
олицетворения (соответственно, субъектом доступа здесь выступает процесс, для
которого анализируется наличие олицетворяющего маркера доступа) и проверяться
их корректность в соответствии с заданными разрешениями (запретами), что
проиллюстрировано на рис. 2. Очевидно, что проверка прав субъекта доступа к
ресурсу должна осуществляться уже после проверки корректности его
идентификации.

Рис.2. Укрупненный
алгоритм идентификации и аутентификации при запросе доступа к ресурсу

Таким образом, в качестве субъекта доступа выступает
процесс (в том числе, это обусловливается и тем, что различные процессы
(приложения) могут затребовать и различных правил разрешенных (запрещенных)
олицетворений, что невозможно обеспечить, если в качестве субъекта доступа
принять пользователя – учетную запись).

Ограничения возможности корректного решения задачи

Ограничения, о которых пойдет далее речь, в первую
очередь, относятся к реализации разграничительной политики доступа к
устройствам.

Разграничение доступа к устройствам – это задача
противодействия внутренним ИТ-угрозам (в частности, решаемая для защиты
информации от санкционированных пользователей – инсайдеров), которая далеко не
единственная в данных приложениях, но, пожалуй, сегодня наиболее обсуждаемая.

Заметим, что в нормативном документе «Гостехкомиссия
России. Руководящий документ. Средства вычислительной техники. Защита от
несанкционированного доступа к информации. Показатели защищенности от НСД к
информации» вопросы контроля доступа пользователей к устройствам (начиная
с СВТ 4-го класса защищенности) формируются в виде отдельного требования: КСЗ должен включать в себя механизм,
посредством которого санкционированный пользователь надежно сопоставляется с
выделенным ему конкретным устройством.

Чтобы понять суть существующих ограничений,
проанализируем, как ОС Windows (в ОС семейства Unix рассматриваемые проблемы не
столь критичны, т.к. устройства в них монтируются к файловой системе) работает
с устройствами, и сразу натолкнемся на проблему (решения рассматриваемой
задачи, реализуемые собственно ОС Windows, рассматривать не будем, т.к. они не
удовлетворяют требованиям применения в корпоративных приложениях). Проблема
здесь состоит в том, что многие устройства предполагают возможность взаимодействия
с ними приложения не напрямую, а через драйвер. В этом случае запрос доступа к
устройству осуществляется от лица пользователя System (варианты решения задачи
на прикладном уровне рассматривать не будем, ввиду их априорной уязвимости).
Возникает вопрос, а откуда взять идентификатор пользователя, который
инициировал это обращение к устройству. Можно, конечно, «посмотреть»,
какой пользователь зарегистрирован в системе, и фильтровать запросы доступа
применительно к его учетной записи (кстати говоря, подобный подход реализуется
некоторыми специализированными средствами защиты). Но не будем забывать, что
современные ОС Windows многопользовательские. Как отмечалось выше, начиная с
Windows XP, возможность входа в многопользовательский режим уже вынесена в интерфейс
(например, из проводника можно по правой кнопки мыши выбрать опцию запуска
приложения с правами другого пользователя – получим многопользовательский
режим). В многопользовательском режиме в системе одновременно зарегистрировано
уже несколько пользователей, при этом выявление учетной записи, от которой
осуществлен запрос доступа к устройству, становится неразрешимой (или, по
крайней мере, весьма сложно корректно решаемой) задачей.

В результате получаем некорректное решение задачи защиты в
общем виде, которое обусловливается не особенностью частного решения, а
архитектурной особенностью ОС. А ведь решение по реализации обработки на
компьютере одним и тем же пользователем как открытой, так и конфиденциальной
информации, априори предполагающее задание различных режимов обработки
(соответственно, различных прав доступа к ресурсам) информации различной
категории, состоящее в том, что информация различной категории обрабатывается
одним и тем же пользователем под различными учетными записями, на сегодняшний
день, на наш взгляд, является единственно эффективным решением.

В порядке замечания отметим, что существуют средства,
предполагающие иные подходы к решению задачи задания различных режимов
обработки информации различной категории одним пользователем (не разделение по
учетным записям), однако эффективность подобных средств в данной работе
анализироваться не будет (это вопрос самостоятельного исследования).

Таким образом, видим, что задача идентификации
пользователя может решаться некорректно именно в тех приложениях, для
использования в которых и предназначено средство защиты.

Возникает вопрос — как решить данную задачу (речь идет о
корректном разграничении доступа пользователей к устройствам, доступ к которым
осуществляется через драйверы), если архитектурная особенность реализации
обращения к ресурсу такова, что он осуществляется от имени пользователя System?

При этом будем учитывать, что для обращения к подобным
устройствам, как правило, необходимо приложение (отдельная программа),
взаимодействующая с драйвером устройства. С учетом сказанного можем заключить,
что данную задачу можно решить с использованием механизма обеспечения
замкнутости программной среды, разрешив/запретив пользователю запуск приложения
для работы с устройствами (при доступе к объекту файловой системы идентификатор
пользователя всегда, в том числе, и при многопользовательском режиме, может
быть корректно определен, при этом, конечно, не будем забывать о необходимости
идентификации и аутентификации при запросах доступа к ресурсам – это первая из
рассмотренных нами задач).

Вывод. Требование
«КСЗ должен включать в себя механизм, посредством которого
санкционированный пользователь надежно сопоставляется с выделенным ему
конкретным устройством» для ряда устройств (взаимодействующих по средством
драйвера) технически невыполнимо. Поэтому для опосредованного выполнения
данного требования должны применяться механизмы защиты, позволяющие
ограничивать взаимодействие конкретных пользователей с устройствами с
использованием тех механизмов контроля доступа к ресурсам, которые позволяют
однозначно идентифицировать пользователя при запросе доступа к ресурсу.

Задача идентификации и аутентификации субъекта «процесс» при
запросах на доступ

Прежде всего, несколько слов об альтернативных подходах к
реализации разграничительной политики доступа к ресурсам. В качестве субъекта
доступа (для которого разграничиваются права доступа к ресурсам) в общем случае
необходимо рассматривать ту сущность, которая по каким-либо соображениям не
пользуется доверием (для нее и следует ограничивать права доступа). Если мы говорим
о внутренних ИТ-угрозах (противодействие попыткам хищения информации со стороны
санкционированных пользователей – инсайдеров), в качестве субъекта доступа, в
первую очередь, следует рассматривать пользователя. При этом в равной мере
актуальны задачи разграничения прав доступа к ресурсам как между различными
пользователями (чтобы один пользователь не получил доступ к информационным
ресурсам другого пользователя), так и для одного пользователя. В последнем
случае необходимо ограничивать (либо разделять, если пользователем может
обрабатываться и открытая, и конфиденциальная информация) режимы обработки
информации (по сути – это уже «сессионный» контроль доступа к
ресурсам).

Однако на практике не менее актуальной является задача
разграничения прав доступа к ресурсам для субъекта «процесс».В общем
случае именно процесс следует рассматривать в качестве источника возникновения
внешней ИТ-угрозы. Тому может быть несколько причин, что следует из приведенной
классификации известных типов вирусов, положим их в основу классификации
процессов, несущих в себе угрозу:

●     Несанкционированные
(сторонние) процессы. Это процессы, которые не требуются пользователю для
выполнения своих служебных обязанностей и могут несанкционированно
устанавливаться на компьютер (локально, либо удаленно) с различными целями, в
том числе, и с целью осуществления несанкционированного доступа (НСД) к
информации;

●     Критичные
процессы. К ним мы отнесем две группы процессов: к процессам первой группы
отнесем те, которые запускаются в системе с привилегированными правами,
например, под учетной записью System, к процессам второй группы те, которые
наиболее вероятно могут быть подвержены атакам, например, сетевые службы. Атаки
на процессы первой группы наиболее критичны, что связано с возможностью расширения
привилегий, в пределе – получения полного управления системой; атаки на
процессы второй группы наиболее вероятны.

●     Скомпрометированные
процессы – процессы, содержащие ошибки (уязвимости), ставшие известными,
использование которых позволяет осуществить НСД к информации. Отнесение данных
процессов в отдельную группу обусловлено тем, что с момента обнаружения
уязвимости и до момента устранения ее разработчиком системы или приложения
может пройти несколько месяцев. В течение этого времени в системе находится
известная уязвимость, поэтому система не защищена.

●     Процессы,
априори обладающие недекларированными (документально не описанными)
возможностями. К этой группе мы отнесем процессы, являющиеся средой исполнения
(прежде всего, это виртуальные машины, являющиеся средой исполнения для
скриптов и апплетов, и офисные приложения, являющиеся средой исполнения для
макросов).

На самом деле, процесс всегда несет в себе угрозу
компьютерной безопасности. Даже если не акцентировать свое внимание на
закладках (особенно этот вопрос актуален для свободно распространяемого ПО,
либо ПО иностранного производства для особо критичных приложений), всегда
высока вероятность ошибки программирования в приложении, предоставляющей
злоумышленнику недекларируемую разработчиком ПО возможность НСД.

Таким образом, если вероятность угрозы, исходящей со
стороны пользователя, еще можно снизить, то вероятность угрозы со стороны
процесса всегда высока.

Заметим, что угроза, порождаемая процессом, далеко не
всегда является внешней ИТ-угрозой. Инсайдер также может запустить стороннюю
программу, модифицировать код санкционированного приложения, воспользоваться
недекларируемой возможностью ПО.

Другими словами, разграничительная политика доступа к
ресурсам для процессов носит более общий характер и обязательно должна
реализовываться СЗИ от НСД (если, конечно, мы говорим об эффективном средстве
защиты информации). Задача обеспечения компьютерной безопасности в
рассматриваемых приложениях в основе своей сводится к задаче контроля запуска и
локализации действий процессов на защищаемом компьютере.

На практике трудно себе представить ситуацию, когда может
понадобиться реализация разграничительной политики доступа к ресурсам либо
только для субъекта «пользователь», либо только для субъекта
«процесс». Поэтому актуальна задача комплексирования.

Для решения рассматриваемой задачи при управлении доступом
к ресурсам следует различать два самостоятельных субъекта доступа –
«пользователь» и «процесс». При этом необходимо управлять
доступом (разграничивать права доступа) не только для субъекта
«пользователь», или только для субъекта «процесс», но и для
субъекта «пользователь, процесс» в комплексе. Как следствие, могут
быть выделены следующие схемы задания разграничительной политики доступа к
ресурсам:

●     разграничение
прав доступа к объектам процессов вне разграничений пользователей (эксклюзивный
режим обработки запросов процессов — доступ к объекту разрешается, если он
разрешен процессу);

●     разграничение
прав доступа к объектам пользователей вне разграничений процессов (эксклюзивный
режим обработки запросов пользователей — доступ к объекту разрешается, если он
разрешен пользователю);

●     комбинированное
разграничение прав доступа — разграничение прав доступа к объектам процессов в
рамках разграничений пользователей (доступ к объекту разрешается, если он
разрешен и пользователю, и процессу).

Заметим, что техническое решение, реализующее данный
подход, нами запатентовано (А.Ю.Щеглов. Система разграничения доступа к
ресурсам, патент №2207619, приоритет от 12.07.2001).

Вернемся к вопросам идентификации и аутентификации, но уже
применительно к субъекту доступа «процесс». Идентификатором его
является полнопутевое имя. Таким образом, для корректной идентификации субъекта
«процесс» необходимо предотвратить возможность запуска процессов под
иными именами и предотвратить возможность модификации исполняемых файлов,
полнопутевые имена которых разрешены для выполнения.

Напрашивается очевидное решение – контролировать
разрешенные к запуску исполняемые файлы на целостность (естественно,
асинхронно, перед запуском). Однако данное решение обладает слишком серьезными
недостатками, чтобы рекомендовано его для использования в общем случае. Причем
основной недостаток здесь связан не с очевидной сложностью администрирования
данного механизма, а с влиянием механизма на вычислительный ресурс защищаемого
компьютера (это ведь исполняемые файлы не только приложений, но и всех
системных процессов). Поэтому будем рассматривать данную возможность в качестве
опциональной, рекомендуемой для использования в случаях, когда невозможно
предотвратить модификацию разрешенного к запуску исполняемого файла иными
средствами, например, когда приложение должно запускаться с внешнего
накопителя, хранящегося у пользователя.

Для решения рассматриваемой задачи в общем случае
целесообразно использовать механизм обеспечения замкнутости программной среды.

В общем случае создание замкнутой программной среды
достигается за счет исполнения механизмом контроля доступа регламента запуска и
обеспечения целостности ПО. При этом механизм считается реализованным корректно
лишь при условии, если выполняются требования к полноте и корректности
разграничений прав на запуск исполняемых файлов. Под полнотой разграничений
понимается возможность регламентировать доступ для операции «выполнить»
для всех ресурсов, из которых возможен запуск ПО, а под корректностью –
способность противодействия любой модификации разрешенных к исполнению
объектов, а также запуску под их именем других (несанкционированных) программ.

В предлагаемой нами реализации для локализации программной
среды необходимо регламентировать права доступа к папкам (каталогам,
подкаталогам), из которых пользователям разрешено (запрещено) запускать
исполняемые файлы. С учетом принятых правил размещения приложений и необходимости
запуска системных процессов, целесообразно разрешать выполнение программ только
из каталогов Program Files, куда следует устанавливать приложения, и Winnt
(WINDOWS). А чтобы предотвратить возможность модификации санкционированных
исполняемых файлов, запись пользователям в эти каталоги, напротив, следует
запретить.

Заметим, что если в качестве субъекта доступа может
выступать как сущность «пользователь», так и сущность
«процесс», то данный механизм защиты позволит настраивать замкнутость
программной среды не только для пользователей, но и для процессов. В этом
случае можно разрешить любому процессу, либо контролируемому процессу (как
субъекту) запуск исполняемых файлов только из каталогов Program Files, и
Winnt (WINDOWS) и запретить прикладным процессам запись в них. Очевидное
достоинство этого решения в «равноправности» разграничений для всех
пользователей — вне зависимости от корректности их идентификации при доступе к
ресурсам (в частности, атаки на расширение привилегий становятся невозможными).

Вывод.
Требование «Комплекс средств защиты информации (КСЗ) должен обеспечивать
идентификацию пользователей при запросах на доступ, проверять подлинность
идентификатора субъекта — осуществлять аутентификацию…» актуально и должно
реализовываться современными СЗИ от НСД и применительно к субъекту доступа
«процесс». При этом задача защиты при выполнении этого требования
сводится к реализации механизма обеспечения замкнутости программной среды.

Вопросы корректности идентификации объекта доступа

Здесь, на первый взгляд, проблем вообще не существует.
Однако если внимательно рассмотреть архитектурные принципы реализации и
возможности современных универсальных ОС, точка зрения на этот вопрос
радикально меняется. В качетсве примера рассмотрим предоставляемые современными
ОС Windows возможности идентификации файлового объекта при запросе доступа.

В NTFS файловый объект может быть идентифицирован
различными способами:

●     файловые
объекты, задаваемые длинными именами, характеризуются той отличительной
особенностью, что к ним можно обращаться как по длинному, так и по короткому
имени, например к каталогу «Program files» можно обратиться по
короткому имени «Progra~1»;

●     файловые
объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют
короткое имя, которое формируется с использованием кодировки Unicode (внешне
они могут существенно различаться), например короткое имя для каталога
«C:Documents and SettingsUSER1Главное меню» выглядит как
«C:Docume~1USER15D29~1». К этим объектам также можно обратиться
как по длинному, так и по короткому имени;

●     файловый
объект идентифицируется не только именем, но и своим идентификатором (ID) –
индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым
объектам не по имени, а именно по ID.

Пусть установленная в вашей информационной системе СЗИ от
НСД не перехватывает и не анализирует лишь один подобный способ обращения к
файловому объекту, и, по большому счету, она становится полностью бесполезной
(рано или поздно, злоумышленник выявит данный недостаток средства защиты и
воспользуется им).

Вывод. Из
сказанного выше получаем следующее требование к идентификации объекта доступа –
объект доступа должен однозначно идентифицироваться при любом допустимом
способе обращения к нему (при любом способе его идентификации приложением) на
доступ.

Мы в исследовании не затронули вопросы ссылок, возможность
обращения к файловым объектам по их ID, что на практике реализуется рядом
приложений, и т.д.

Таким образом, проведя данное исследование, видим,
насколько сложна задача идентификации и аутентификации как в своей постановке в
общем виде, так и в решении, если, конечно, говорить о построении эффективного
средства защиты информации, сколько механизмов защиты должно быть реализовано в
составе СЗИ от НСД для решения данной задачи в общем виде. А если хотя бы
одного из рассмотренных механизмов в средстве защиты нет – уже уязвимость!
Кстати говоря, о термине «эффективность» в данных приложениях.
Заметим, что СЗИ от НСД не может обладать высокой или низкой эффективностью
(это не параметр производительности). СЗИ от НСД либо защищает, либо нет. Если
существует хотя бы один канал обхода средства защиты, рано или поздно им
воспользуется злоумышленник, как следствие, в этом случае правомерно
утверждать, что данная СЗИ от НСД не обладает потребительской стоимостью (или
просто бессмысленна для практического использования). Здесь невольно возникает
вопрос (это уже в части формализации требований к СЗИ от НСД – сегодня очень
актуальный вопрос), а как подразделять СЗИ от НСД на какие-либо классы или
группы? СЗИ от НСД высокого класса обеспечивает защиту, а низкого нет (иного не
дано)? Напрашивается вывод о том, что подобное разделение СЗИ от НСД на
какие-либо группы или классы по функциональным возможностям и по набору
механизмов защиты недопустимо! Тогда на основании чего могут быть введены
классификационные признаки СЗИ от НСД?

В заключение отметим, что в данной работе на примере
исследования лишь одной, на первый взгляд, наиболее изученной сегодня задачи
защиты информации, авторы сделали попытку убедить читателя, что защита
информации – это очень сложная научно-техническая и инженерная задача. К
сожалению, исторически нас приучили к тому, что средство защиты может быть
простым в использовании и в администрировании. Большую (на наш взгляд,
отрицательную) роль в этом сыграли антивирусные средства, основанные на
сигнатурном анализе – «нажал две кнопки, запустил «черный ящик»,
все проверил, безопасность обеспечена». Однако сигнатурные анализаторы –
это не средства защиты – это средства контроля (сравнение с эталоном). Поэтому,
с одной стороны, они могут быть простыми в использовании (задача лишь в
пополнении набора эталонов, которая для потребителя «прозрачна»), с
другой стороны, их использование принципиально не может обеспечить эффективной
защиты (принципиально невозможно обеспечить выполнение требования к полноте и
достаточности набора эталонов). Если же мы говорим о корпоративных приложениях,
где конфиденциальные данные являются потенциальным товаром, т.е. обладают
потребительской стоимостью, к вопросам компьютерной безопасности необходимо
относиться серьезно, необходима соответствующая квалификация лиц, отвечающих на
предприятии за защиту информации (о разработчиках СЗИ от НСД уж и не говорим).
В этом случае потребитель уже должен ожидать от разработчика средств защиты не
простых, а эффективных и обоснованных решений!