Как происходит непрямая аутентификация в ос windows 2000 - Доктор Windows

МОСКОВСКИЙ
ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ
УНИВЕРСИТЕТ «СТАНКИН»

Кафедра
информационных систем

Отчёт

по
лабораторной работе № 6

дисциплина

«Защита
информации»

тема
работы

«Освоение
программных средств для работы с
сертификатами открытых ключей»

Выполнил:
студент группы ИДБ-15-15 Кулагина
Алиса Николаевна

Проверил:
преподаватель
Симонов Михаил Фёдорович

Москва
2018

С
помощью командной строки откроем
утилиту makecert
и создадим закрытый ключ ЭЦП и сертификат.

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

Как
видим, сертификат и ключ успешно
создались!

Просмотрим
сведения о сертификате. Он у нас является
недостоверным. Посему создадим достоверный
сертификат.

Для
этого я заново создам новый сертификат
и назову его MyNewRoot,
как прописано в методичке.

Следующими
командами мы создадим самоподписанный
сертификат, который сохраняется в
системном хранилище CA и в файле
myNewRoot.cer. Затем этот сертификат использум
для удостоверения вновь созданного
сертификата, помещаемого в хранилище
myNewSign, это и будет наш MyNewRoot:

MakeCert
-sk myNewRootKey -r -ss ca myNewRoot.cer

MakeCert
-is ca -ic myNewRoot.cer -ss myNewSign

Открываем
наш сертификат. Появляется окошко, в
котором нажимаем на кнопку “Установить
сертификат”.

Далее
весь процесс виден на скриншотах:

Далее
выбираем “Доверенные корневые
сертификаты”

Нажимаем
ОК и появляется окно предупреждения о
безопасности

В
итоге получаем доверенный сертификат.

2.
С помощью командной строки прописываем
путь к файлу утилиты makectl
и вызываем её.

Выбираем
по заданию назначения “Подписывание
кода” и “Сертификат шифрования ЦС”.

Выбираем
как доверенный сертификат созданный
нами ранее сертификат MyNewRoot.

Сохраняем
наш список доверия сертификатов в файл
Titorenko.stl

Просматриваем
файл Titorenko.stl

3.
С
помощью командной строки прописываем
путь к файлу утилиты CertMgr
и вызываем её.

Открывается
окно с имеющимися сертификатами. Далее
попробуем экспортировать сертификат.

Получили
новый сертификат Student.
Cer
.

Попробуем
теперь импортировать его .

А
вот что нам выдаст система при удалении
сертификата.

4.
Какие существуют методики применения
PIN-кодов?

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

10.
Какими могут быть атаки на протокол
прямой аутентификации в ОС Windows?

Атаки
на протоколы можно разделить на два
класса:

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

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

13.
Как происходит непрямая аутентификация
в ОС Windows 2000?

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

Соседние файлы в папке Защита информации

Источник

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

Аутентификация — происходит от английского слова 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. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию, и никогда не используют сеансовую безопасность NTLMv2.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	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). Для этого протокол подписывает, скрывает или шифрует транзакцию. Кроме того, ей присваивается временная метка, чтобы взломщик не мог воспользоваться учетными данными в будущем. Чтобы не позволить немедленно извлечь пароль пользователя из базы данных, протокол должен обеспечить скрытное хранение паролей в базе данных аутентификации.

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

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

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

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

При регистрации пользователя одна из первых задач 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:

После успешной обычной аутентификации компьютер пользователя запрашивает билет безопасности из сервера Kerberos (DC) для будущих запросов аутентификации.
Сервер Kerberos выдает запросчику билет для участия в будущих событиях аутентификации и авторизации без повторного предъявления первоначальных учетных данных аутентификации.
Когда запросчику нужно обратиться к ресурсу сервера-участника, он получает другой билет доступа от сервера Kerberos и предъявляет его серверу ресурса для проверки.
Первоначальные учетные данные аутентификации не передаются по сетевым каналам ни в одном из последующих сеансов аутентификации (до тех пор, пока не истечет срок действия билета, выданного на этапе 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

Источник

Возможности, предоставляемые пользователям

Вход пользователя в систему

Аутентификация Kerberos

Основы Kerberos

Интеграция Kerberos

Pасширения Kerberos для использования
смарт-карт

Вторичная регистрация «Run As»

Файловая система с шифрованием

Реализация EFS

Использование EFS

Функции системы безопасности для администраторов

Безопасность и Active Directory

Группы

Делегирование административных полномочий

Безопасная передача по протоколу IP

Заключение

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

Условно функции защиты данных можно разделить на функции, приносящие выгоду
пользователям, и функции, приносящие выгоду администраторам. К первым относятся
новые, упрощенные, но более надежные способы регистрации в сети, шифрование
файлов пользователей и использование сертификатов. Ко вторым — служба каталогов
Active Directory, содержащая все объекты системы и позволяющая не только разграничивать
права и привилегии, но и легко выполнять их делегирование; средства конфигурирования
уровня безопасности и управления политикой безопасности; средства аудита системы;
средства обеспечения безопасной передачи данных по сети по протоколу IP.

Возможности, предоставляемые пользователям

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

Вход пользователя в систему

При входе в систему пользователь может задать не только свое короткое имя в
системе, но и полное имя в виде «имя@имя_домена». Это позволяет интегрировать
систему безопасности с Интернетом. Дополнительно по умолчанию используется иной
протокол аутентификации — Kerberos. Для повышения защищенности служит и использование
при регистрации смарт-карт. Все это выполнено таким образом, что наряду с серверами,
работающими под управлением Windows 2000, в сети могут существовать машины и
с предыдущими версиями Windows NT и с иными ОС.

Аутентификация Kerberos

Протокол Kerberos усиливает существующие функции безопасности Windows NT и
добавляет новые.

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

Основы Kerberos

Kerberos является протоколом аутентификации с совместным секретом. Так он называется
потому, что и пользователю, и KDC известен пароль (KDC на самом деле известен
зашифрованный пароль). Протокол Kerberos определяет серию обменов между клиентами,
KDC и серверами для получения билетов Kerberos (рис. 1).
Когда клиент начинает регистрацию в Windows 2000, поставщик функций безопасности
(ПФБ) Kerberos получает начальный билет Kerberos (Ticket grant ticket — TGT),
основанный на зашифрованном представлении пароля. Windows 2000 хранит TGT в
кэше билетов на рабочей станции, связанной с контекстом регистрации пользователя.
При попытке клиентской программы обратиться к сетевой службе выполняется проверка
кэша билетов на наличие в нем верного билета для текущего сеанса работы с сервером.
Если такого билета нет, на KDC посылается запрос, содержащий TGT, для получения
сеансового билета, разрешающего доступ к серверу.

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

На рис. 2 изображено взаимодействие между клиентом, KDC
и сервером приложений, использующим протокол аутентификации Kerberos.

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

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

Интеграция Kerberos

Протокол Kerberos полностью интегрирован с системой безопасности и контроля
доступа Windows 2000. Начальная регистрация в Windows 2000 обеспечивается процедурой
WinLogon. Она использует поставщика функций безопасности Kerberos для получения
начального билета TGT. Другие компоненты системы, например Redirector, используют
интерфейс SSPI к ПФБ Kerberos для получения сеансового билета для удаленного
доступа к файлам сервера SMB.

Делегирование аутентификации (рис. 3) поддерживается в протоколе Kerberos v5 путем
использования в сеансовых билетах флагов proxy и forwarding. Функция делегирования
используется сервером Windows 2000 для получения сеансового билета на доступ от
имени клиента к другому серверу.

Расширения Kerberos для использования смарт-карт

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

В отличие от регистрации с вводом пароля пользователь вставляет в приемное
устройство смарт-карту, в которой содержится персональная информация о пользователе
и его личный ключ. Для активации смарт-карты пользователь вводит свой PIN-код.
Личный ключ и сертификат, хранимые в карточке, аутентифицируют пользователя
в KDC, и он получает TGT. Таким образом, для каждого пользователя необходима
своя смарт-карта.

Вторичная регистрация «Run As»

Полезной функцией, встроенной в Windows 2000, является сервис вторичной регистрации,
позволяющий выполнять отдельные процессы с разным уровнем привилегий. Для этого
в командной строке используется команда runas. Она подобна утилите SU в UNIX.
Указывая имя процесса и учетную запись, от имени которой будет запущен процесс,
можно изменять привилегии этого процесса.

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

Обратный пример: вы обладаете достаточно высокими правами в системе, но вам
надо запустить некоторую программу, в безвредности которой вы не уверены. Что
ж, запустите ее под гостевой учетной записью, и программа не сможет причинить
вреда.

Файловая система с шифрованием

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

Файловая система с шифрованием (Encrypting File System — EFS) призвана решать
эту проблему.

Реализация EFS

Файловая система с шифрацией (рис. 4) является частью
послойной модели Windows 2000 и состоит из следующих компонентов:

Драйвер EFS. Этот драйвер располагается непосредственно над NTFS
и взаимодействует с сервисом EFS для запроса ключей шифрования файлов, полей
дешифрования файлов, полей восстановления файлов и других сервисов, связанных
с управлением ключами.
EFS FSRTL. Этот модуль драйвера EFS реализует различные вызовы NTFS
для выполнения таких операций файловой системы, как чтение, запись и открытие
зашифрованных файлов и каталогов, а также операции шифрования, дешифрования
и восстановления данных при записи на диск или считывании с диска.
Сервис EFS. Этот сервис является частью подсистемы защиты.
Интерфейсы Win32 API. Обеспечивают программные интерфейсы для шифрования
текстовых файлов, дешифрации или восстановления закодированных текстов, а
также импорта или экспорта зашифрованных файлов без их предварительного дешифрования.

Шифрование выполняется для пользователя, зарегистрированного в данный момент.
Однако в API имеется поддержка шифрования для нескольких пользователей. Каждый
файл шифруется своим уникальным ключом.

Также имеется возможность восстановления файлов в случае потери личного ключа
пользователя.

Использование EFS

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

Функции системы безопасности для администраторов

В первую очередь к функциям системы безопасности, предоставляющим новые возможности
администраторам, безусловно, следует отнести службу каталогов Active Directory.
Помимо этого имеются Delegation Wizard — инструмент для упрощения делегирования
административных полномочий, Enterprise Certificate Services — средство выдачи
сертификатов, а также средства управления локальным компьютером и политикой безопасности.

Безопасность и Active Directory

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

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

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

Хранение учетной информации в Active Directory означает, что пользователи и группы
представлены в виде объектов каталога. Права на чтение и запись могут быть предоставлены
как по отношению ко всему объекту в целом, так и по отношению к отдельным его
свойствам. Администраторы способны точно определять, кто именно может модифицировать
информацию о пользователях и какую именно.

Между Active Directory и Службами безопасности Windows 2000 существуют фундаментальные
отношения. В Active Directory хранятся правила безопасности домена, определяющие
использование системы, — ограничения паролей, ограничения доступа к системе. Объекты
каталога, относящиеся к безопасности, должны быть защищены от несанкционированного
доступа. В Windows 2000 реализована объектная модель безопасности и контроля доступа
ко всем объектам в каталоге Active Directory. У каждого объекта имеется свой уникальный
дескриптор защиты, определяющий разрешения, необходимые для чтения или обновления
свойств объектов.

Группы

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

Универсальные группы характерны тем, что членство в них публикуется в Глобальном
каталоге. Глобальные группы включают в себя пользователей или группы того же самого
домена, в котором определены глобальные группы. Членство в этих группах не публикуется
в Глобальном каталоге.

Локальные группы домена включают в себя как пользователей, так и группы из доверяемых
доменов. Членство в этих группах также не публикуется в Глобальном каталоге.

Делегирование административных полномочий

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

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

Для делегирования полномочий применяется Delegation Wizard.

Безопасная передача по протоколу IP

В RFC 1825-1829 определены спецификации протокола IPSec. Этот протокол является
обязательным для IPv6 и опционным для IPv4, тем не менее он реализован в Windows 2000.
IPSec защищает трафик IP по двум протоколам: Authentication Header (AH) и Encapsulating
Security Payload (ESP).

AH обеспечивает целостность и неизменность как заголовка пакета IP, так и его
содержимого. Если хакер внес изменения в пакет, то AH позволяет узнать об этом
на приемной стороне.

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

IPSec работает в двух режимах: транспортном и туннельном. В транспортном режиме
AH или ESP располагается в оригинальном пакете IP между IP-заголовком и верхним
слоем расширений заголовка. Этот режим используется для защиты соединений точка-точка,
например между рабочей станцией и сервером.

В туннельном режиме оригинальный пакет IP помещается внутри нового пакета, а AH
или ESP — между заголовком IP нового пакета и оригинальным пакетом. Новый заголовок
пакета IP указывает на конечную точку туннеля, в то время как в старом заголовке
хранится точное место назначения. Туннельный режим используется для создания туннеля
между двумя системами, например между двумя конечными точками, между конечной
точкой и защищенным шлюзом или между двумя защищенными шлюзами. Под защищенным
шлюзом можно рассматривать туннельный сервер, маршрутизатор, межсетевой экран
или виртуальную частную сеть.

Ядром реализации IPSec в Windows 2000 является политика безопасности IP. В
рамках этой политики можно задать параметры для фильтров IP, политики переговоров,
метода аутентификации, туннеля IPSec, а также выбрать тип соединения — локальной
сети или удаленного доступа. Политика безопасности может храниться как на отдельных
машинах, так и в Active Directory, что позволяет распространить ее на всю организацию
в целом.

Заключение

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

КомпьютерПресс 8’1999

Источник