ГЛАВА 2

Система
безопасности'

Операционная система Windows NT всегда обладала прекрасными и
широко применимыми на практике возможностями защиты. Однократ-
ная регистрация в домене Windows NT предоставляет пользователям
доступ к ресурсам всей корпоративной сети.

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

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

С точки зрения пользователя система защиты Windows NT Server пол-
ноценна и несложна в обращении. Простая процедура регистрации
обеспечивает доступ к соответствующим ресурсам. Для пользователя
невидимы такие процессы, как шифрование пароля на системном уров-
не. (Шифрование пароля нужно, чтобы исключить передачу пароля в

В этой главе не описаны некоторые механизмы обеспечения безопасной ра-
боты в Интернете, а также вопросы, связанные с безопасностью частных
виртуальных сетей. См. главы 7 и 8 соответственно.

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

Более глубокий уровень безопасности — то, как Windows NT Server
защищает данные, находящиеся в физической памяти компьютера.
Доступ к ним предоставляется только имеющим на это право програм-
мам. Так же, если данные больше не содержатся на диске, система пре-
дотвращает несанкционированный доступ к той области диска, где они
содержались. При такой системе защиты никакая программа не «под-
смотрит» в виртуальной памяти машины информацию, с которой опе-
рирует в данный момент другое приложение.

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

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

Перечислим новые функции безопасности Windows NT.

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

• В Active Directory поддерживается иерархичное простран-
ство имен пользователей, групп и учетных записей машин.

Учетные записи могут быть сгруппированы по организационным
единицам (что существенно отличается от плоской структуры имен
в предыдущих версиях Windows NT).

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

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

• Доменная модель изменена и использует Active Directory для
поддержки многоуровневого дерева доменов. Управление до-
верительными отношениями между доменами упрощено за счет
транзитивности в пределах всего дерева доменов.

• В систему безопасности включены новые механизмы аутен-
тификации, такие как Kerberos v5 и TLS (Transport Layer Security),
базирующиеся на стандартах безопасности Интернета,

• Протоколы защищенных каналов (SSL 3.0/TLS) обеспечивают
поддержку надежной аутентификации клиента. Она достига-
ется путем сопоставления мандатов пользователей в форме серти-
фикатов открытых ключей с существующими учетными записями
Windows NT. Для управления учетной информацией и контроля за
доступом применяются одни и те же средства администрирования,
независимо от того, используется ли защита с открытым ключом или
с общим секретом.

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

• В состав новой версии входит Microsoft Certificate Server.

Этот сервер предназначен для организаций и позволяет выдавать со-

трудникам и партнерам сертификаты Х.509 версии 3. В CryptoAPI
включены интерфейсы и модули управления сертификатами откры-
тых ключей, включая выданные коммерческим УС (Уполномочен-
ным сертификации), сторонним УС или Microsoft Certificate Server.
Системные администраторы могут указывать, сертификаты каких
уполномоченных являются доверяемыми в системе и, таким обра-
зом, контролировать аутентификацию доступа к ресурсам.

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

• В распоряжении пользователей простые средства управления
парами закрытых (открытых) ключей и сертификатами, ис-
пользуемыми для доступа к ресурсам Интернета.

• Технология шифрования встроена в операционную систему

и позволяет использовать цифровые подписи для идентификации
потоков.

Базовые сведения о шифровании

В подробном разговоре о системе безопасности Windows NT неизбеж-
ны постоянные ссылки на некоторые базовые понятия: симметричное
шифрование — шифрование с закрытым или личным (private) ключом,
асимметричное шифрование — шифрование с открытым или публич-
ным (public) ключом, цифровая, подпись, сертификаты.

Давайте сначала вкратце рассмотрим эти механизмы2.

Симметричное шифрование

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

В этом разделе Вы найдете лишь краткие объяснения. За более подробной
информацией лучше обратиться к специальной литературе.

Симметричное шифрование

Асимметричное шифрование

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

Асимметричное шифрование

Цифровые подписи

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

Проверка цифровой подписи

Сертификаты

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

Точно так же и сервер, к которому подключается клиент, «убеждается»
в подлинности последнего путем проверки его сертификата.

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

тавлять сертификат по мере доступа к новым узлам. Очевидно, что
при этом отпадает надобность поддерживать учетную базу на каж-
дом сервере.

Давайте рассмотрим несколько примеров использования сертификатов.

1. Организация хочет предоставить своим нынешним и бывшим со-
трудникам доступ к информации об их пенсионных накоплениях.
Информация хранится на сервере Web. В этом случае:

— все такие сотрудники получают сертификаты;

— доступ к пенсионной информации осуществляется либо через
Интернет, либо по интрасети с использованием протокола SSL и
предоставлением сертификата для аутентификации;

— при этом сотрудники имеют доступ к остальным Web-узлам ком-
пании без дополнительной регистрации.

2. Организация желает избирательно предоставить своим поставщи-
кам информацию из корпоративной интрасети. В этом случае:

— для поставщиков назначается группа Windows NT с определенны-
ми правами доступа;

— сервер сертификации выдает поставщикам сертификаты, соотне-
сенные с учетной записью в Windows NT;

— поставщик регистрируется в интрасети корпорации и автомати-
чески аутентифицируется программой просмотра при предостав-
лении сертификата;

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

3. Организация предоставляет посетителям услуги по подписке на свой
Web-сервер. При этом:

— потенциальный пользователь заходит на Web-узел и заполняет
регистрационную форму подписчика;

— входной модуль сервера сертификации обрабатывает запрос и
выдает сертификат, а также заносит в корпоративную базу ин-
формацию о пользователе и правах, ему предоставленных;

— теперь пользователь может снова зайти на Web-узел, предоста-
вить сертификат и, после аутентификации, воспользоваться под-
пиской;

— если пользователь больше не нуждается в подписке или исполь-
зует ее не по назначению, администратор может отозвать серти-
фикат пользователя и запретить доступ.

В Windows NT 5.0 встроен сервер сертификатов Certificate Server, кото-
рый может выдавать сертификаты в стандартных форматах (Х.509 вер-
сий 1 и 3), а также добавлять расширения по мере надобности.

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

Протокол аутентификации Kerberos определяет взаимодействие между
клиентом и сетевым сервисом аутентификации, известным как KDC
(Key Distribution Center). В Windows NT KDC используется как сервис
аутентификации на всех контроллерах домена. Домен Windows NT эк-
вивалентен области Kerberos, но к ней обращаются как к домену. Реа-
лизация протокола Kerberos в Windows NT основана на определении
Kerberos в RFC1510, Клиент Kerberos реализован в виде ПФБ (постав-
щика функций безопасности) Windows NT, основанном на SSPI. Началь-
ная аутентификация Kerberos интегрирована с процедурой WinLogon.
Сервер Kerberos (KDC) интегрирован с существующими службами бе-
зопасности Windows NT, исполняемыми на контроллере домена. Для
хранения информации о пользователях и группах он использует служ-
бу каталогов Active Directory.

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

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

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

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

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

Перед тем, как рассмотреть процесс аутентификации Kerberos, вспом-
ним механизм, действующий в предыдущих версиях Windows NT.

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

Если пользователь имеет учетную запись и привилегии доступа в сис-
тему, а введенный им пароль верен, подсистема защиты создает объект
маркер доступа, представляющий пользователя. Он сравним с ключом,
содержащим «удостоверение личности» пользователя. Маркер доступа
хранит такую информацию, как идентификатор защиты SID (Security
ID), имя пользователя и имена групп, к которым он принадлежит.

Маркер доступа или его копия ассоциируются с любым процессом,
выполняемым пользователем (например, открытие или печать файла).
Комбинация процесс-маркер называется субъектом. Субъекты опери-
руют над объектами Windows NT путем вызова системных сервисов.
Когда субъект осуществляет доступ к защищенному объекту, (например,
файлу или каталогу), содержимое маркера сравнивается с содержимым
списка контроля доступа к объекту ACL (Access Control List) путем стан-
дартной проверки. При этом определяется, можно ли предоставить
субъекту право на выполнение запрашиваемой операции. Эта же про-
цедура может при необходимости сгенерировать сообщения аудита,
отражающие результаты попыток доступа.

Созданный маркер передается процессу Win32 WinLogon. WinLogon
предписывает подсистеме Win32 создать процесс для пользователя, и
маркер доступа присоединяется к этому процессу. После этого подси-
стема Win32 инициирует Windows NT Explorer, и на экране появляется
соответствующее окно.

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

Основы Kerberos

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

CTRL+ALT+DEL

Начальная аутентификация Kerberos

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

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

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

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

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

Интеграция Kerberos

Протокол Kerberos полностью интегрирован с системой безопасности
и контроля доступа Windows NT. Начальная регистрация в Windows NT
обеспечивается процедурой WinLogon, использующей ПФБ Kerberos

для получения начального билета TGT. Другие компоненты системы,
например, Redirector, применяют интерфейс SSPI к ПФБ Kerberos для
получения сеансового билета для удаленного доступа к файлам серве-
ра SMB.

В протоколе Kerberos версии 5 для сеансовых билетов определено шиф-
руемое поле. Оно предназначено для данных авторизации, однако ис-
пользование этого поля определяется конкретными приложениями, В
Windows NT поле данных авторизации служит для хранения иденти-
фикатора безопасности Security ID, однозначно определяющего пользо-
вателя и членство в группе. Поставщик функций безопасности Kerberos
на серверной стороне использует поле авторизации для создания мар-
кера защищенного доступа (security access token), представляющего
пользователя в этой системе. Сервер, следуя модели безопасности Win-
dows NT, использует этот маркер для доступа к локальным ресурсам,
защищенным списками контроля доступа.

Делегирование аутентификации поддерживается в протоколе Kerberos
версии 5 путем использования в сеансовых билетах флагов proxy и
forwarding. Сервер Windows NT применяет делегирование для получения
сеансового билета на доступ от имени клиента к другому серверу.

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

Взаимодействие Kerberos

Протокол Kerberos версии 5 реализован в различных системах и ис-
пользуется для единообразия аутентификации в распределенной сети.

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

• общий протокол аутентификации пользователя или сервиса по ос-
новному имени при сетевом подключении;

• возможность определения доверительных отношений между облас-
тями Kerberos и создания ссылочных запросов билетов между обла-
стями;

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

• поддержка форматов маркера безопасности Kerberos версии 5 для
установления контекста и обмена сообщениями так, как это опре-
делено рабочей группой lETFCommon Authentication Technology.

Поддержка Kerberos открытых ключей

В Windows NT также реализованы расширения протокола Kerberos, под-
держивающие дополнительно к аутентификации с совместно исполь-
зуемым секретным ключом аутентификацию, основанную на парах
открытого (закрытого) ключа. Поддержка открытых ключей позволяет
клиентам запрашивать начальный ключ TGT с помощью закрытого
ключа, в то время как KDC проверяет запрос с помощью открытого
ключа, полученного из сертификата Х.509 (хранится в пользовательс-
ком объекте в каталоге Active Directory), Сертификат пользователя мо-
жет быть выдан как сторонним уполномоченным сертификации (Certi-
fication Authority), так и Microsoft Certificate Server, входящим в Windows
NT. После начальной аутентификации закрытым ключом используют-
ся стандартные протоколы Kerberos для получения сеансовых билетов
на доступ к сетевым службам,

Поддержка протоколом Kerberos открытых ключей — основа аутенти-
фикации в сети с помощью смарт-карт. Пользователи Windows NT 5.0
могут их применять для входа в систему.

Сервер сертификатов Microsoft
Certificate Server

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

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

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

На рисунке показаны компоненты сервера сертификатов: исполнитель-
ная часть, очереди и журнал находятся в одном сервисе Windows NT;

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

Структура сервера сертификатов

Клиент и входной модуль

Запрос сертификата поступает от любого, поддерживающего цифровые
сертификаты, клиентского приложения. Это может быть, например,
программа просмотра страниц Web, почтовый клиент или клиент элек-
тронного магазина. Точку входа Certificate Server — так называемый
входной модуль — можно настроить на прием запросов во многих стан-
дартных форматах. Входные модули исполняют две основные функции:

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

Модуль очередей и правил

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

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

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

Создание сертификата и регистрация в журнале

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

Выходной модуль

Certificate Server передает сертификат в выходной модуль, который
упаковывает его в соответствующий транспортный механизм или про-
токол. Так, сертификат может быть передан по почте, по сети или по-
мещен в службе каталогов, например, Active Directory.

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

Административные инструменты

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

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

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

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

Распределенные службы безопасности Windows NT 5.0 используют Acti-
ve Directory в качестве хранилища учетной информации. Active Direc-
tory значительно превосходит реестр по производительности и маст-
табируемости. Особо впечатляют ее административные возможности.

Рассмотрим преимущества интегрированного управления учетными
записями службой каталогов Active Directory.

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

• Каталог Active Directory позволяет учитывать намного боль-
ше объектов пользователей, чем реестр. Размер одного домена
уже не ограничен производительностью сервера, хранящего учетные
записи. Дерево связанных между собой доменов Windows NT может
поддерживать большие и сложные организационные структуры.

• Администрирование учетной информации расширено за
счет графических средств управления Active Directory, а так-
же за счет поддержки OLE DS в языках сценариев. Общие за-
дачи администрирования могут быть решены в виде сценариев, что
позволяет автоматизировать их выполнение.

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

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

Понятие групп упростилось, и место локальных и глобальных групп
теперь занимают просто объекты zpynn''. С их помощью можно управ-
лять как доступом к ресурсам в масштабе всего домена, так и к локаль-
ным ресурсам контроллера домена.

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

На рисунке изображены фундаментальные отношения между Active Di-
rectory и службами безопасности операционной системы.

Интеграция Active Directory и служб безопасности

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

Для определения прав данного клиента считывать или модифицировать
определенный объект в Active Directory служит имперсонация и вери-
фикация доступа Windows NT. Иными словами, при поступлении LDAP-
запроса от клиента доступ к объектам каталога контролируется опера-
ционной системой, а не службой каталогов Active Directory.

Модель безопасности Windows NT обеспечивает однородный и унифи-
цированный механизм контроля за доступом к ресурсам домена на
основе членства в группах. Компоненты безопасности Windows NT до-
веряют хранимой в каталоге информации о защите. Например, сервис
аутентификации Windows NT хранит зашифрованные пароли пользо-
вателей в безопасной части каталога объектов пользователя. По умол-
чанию операционная система «считает», что правила безопасности за-
щищены и не могут быть изменены кем-либо несанкционированно.
Общая политика безопасности домена также хранится в каталоге Active
Directory.

Доверительные отношения между доменами

В Windows NT 5.0 домены могут быть организованы в виде иерархи-
ческих деревьев. Между доменами устанавливаются доверительные от-
ношения, Поддерживаются два вида таких отношений:

• явные однонаправленные доверительные отношения с доменами
Windows NT 4.0;

• двусторонние транзитивные доверительные отношения между
всеми доменами, входящими в дерево.

Явные отношения доверия устанавливаются не только с доменами ста-
рого типа, но и в том случае, когда неявные двусторонние отношения
не пригодны для использования: например, для домена финансового
отдела или бухгалтерии. Установление явных односторонних довери-
тельных отношений автоматически отменяет неявные доверительные
отношения Kerberos.

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

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

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

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

Существует три способа делегирования административных полномочий:

• на изменение свойств определенного контейнера, например, Local-
DomainPolicies самого домена;

• на создание и удаление дочерних объектов определенного типа
(пользователи, группы, принтеры и пр.) внутри OU;

• на обновление определенных свойств некоторых дочерних объек-
тов внутри OU (например, право устанавливать пароль для объек-
тов типа User).

Делегировать полномочия просто. Достаточно выбрать лицо, которо-
му будут делегированы полномочия, и указать, какие именно полномо-
чия передаются. Интерфейс программы администрирования Active
Directory позволяет без затруднений просматривать информацию о
делегировании, определенную для контейнеров.

Детальное назначение прав доступа

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

Архитектурой безопасности объектов Active Directory используются
дескрипторы защиты Windows NT для контроля за доступом к объек-
там. Каждый объект в каталоге имеет уникальный дескриптор защиты.
Входящий в дескриптор список контроля доступа ACL (Access Control
List), содержит строки, определяющие разрешение или запрет на оп-
ределенные виды доступа для отдельных лиц или групп. Права доступа
могут быть предоставлены или запрещены в различной степени. Суще-
ствуют уровни прав доступа, различающиеся применением к:

• объекту в целом (при этом затрагиваются все свойства объекта);

• группе свойств, определенной наборами свойств внутри объекта;

• отдельному свойству объекта.

По умолчанию доступ для чтения и записи ко всем свойствам объекта
получает создатель объекта.

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

Наконец, назначение прав доступа к отдельным свойствам представля-
ет собой наивысший уровень детализации, применимый ко всем объек-
там Active Directory.

Контейнерные объекты в каталоге также поддерживают детализацию
доступа, регламентируя, кто имеет право создавать дочерние объекты
и какого типа. Например, правило доступа, определенное на уровне
организационной единицы, может определять, кто имеет право созда-
вать объекты типа User (пользователи) в этом контейнере. Другое пра-
вило в этой же OU может определять, кто имеет праао создавать объек-
ты типа Printer.

Новая реализация редактора списков контроля доступа представляет
собой диалоговое окно, в котором легко просмотреть или изменить
права доступа к объектам Active Directory; а также задать права цосг/па
как к отдельным свойствам объектов Active Directory, так и к наборам
свойств. Кроме того, редактор ACL позволяет организовывать наследо-
вание прав доступа к объектам-контейнерам.

Наследование прав доступа

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

В Windows NT реализована статическая форма наследования прав до-
ступа, иногда также называемая наследованием в момент создания.
Информация об управлении доступом к контейнеру распространяется
на все вложенные объекты контейнера. При создании нового объекта
наследуемые права сливаются с правами доступа, назначаемыми по
умолчанию. Любые изменения наследуемых прав доступа, выполняемые
в дальнейшем на высших уровнях дерева, должны распространяться на
все дочерние объекты. Новые наследуемые права доступа распростра-
няются на объекты Active Directory в соответствии с тем, как эти новые
права определены. Статическая модель наследования позволяет увели-
чить производительность.

Элементы безопасности системы

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

Учетные записи пользователей и групп

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

4 Описание приведено в соответствии с Windows NT 5.0 первой бета-версии.
Именно поэтому часть возможностей, описанных в предыдущих разделах, но
пока еще не реализованных, здесь не затронута.

Так же, как и в предыдущих версиях Windows NT, в версии 5.0 имеется
несколько встроенных учетных записей пользователей и групп. Эти
учетные записи наделены определенными полномочиями и могут ис-
пользоваться в качестве основы для новых учетных записей,

К встроенным учетным записям пользователей относятся:

• Guest — учетная запись, фиксирующая минимальные привилегии
гостя;

• Administrator — встроенная учетная запись для пользователей, на-
деленных максимальными привилегиями;

• Krbtgt — встроенная учетная запись, используемая при начальной
аутентификации Kerberos.

Кроме них имеются две скрытые встроенные учетные записи:

• System — учетная запись, используемая операционной системой;

• Creator owner — создатель (файла или каталога).

Перечислим встроенные группы:

• локальные (оставлены для совместимости)

— Account operators;

— Administrators;

— Backup operators;

— Guests;

— Print operators;

— Replicator;

— Server operators;

— Users;

• и глобальные

— Domain guests — гости домена;

— Domain Users — пользователи домена;

— Domain Admins — администраторы домена.

Помимо этих встроенных групп имеется еще ряд специальных групп:

• Everyone — в эту группу по умолчанию включаются вообще все
пользователи в системе;

• Authenticated users — в эту группу включаются только аутентифи-
цированные пользователи домена;

• Self — сам объект.

Для просмотра учетных записей используется слепок консоли управ-
ления Directory Service Manager, в котором надо выбрать контейнер
Users.

Диалоговое окно Microsoft Management Console, слепок, Directory
Service Manager, контейнер Users

По сравнению с предыдущими версиями Windows NT, отпадает необ-
ходимость в отдельном инструменте User Manager или User Manager for
Domains для управления учетными записями пользователей и групп.

Для просмотра и модификации свойств учетной записи достаточно
щелкнуть имя пользователя или группы и на экране появится диалого-
вое окно User Properties.

Диалоговое окно User Properties, вкладка General
Диалоговое окно содержит следующие вкладки:

• General — общее описание пользователя; все параметры необяза-
тельные;

• Address — домашний и рабочий адрес пользователя; все параметры
необязательные;

• Account — обязательные параметры учетной записи;

• Telephone/notes — необязательные параметры;

• Organization — дополнительные необязательные сведения;

• Membership — обязательная информация о принадлежности
пользователя к группам;

• Dial-in — параметры удаленного доступа;

• Object — идентификационные сведения о пользовательском объекте;

• Security — информация о защите объекта.

Необязательные параметры можно и не вводить, но они полезны при
поиске того или иного пользователя по второстепенным признакам.

Окно свойств учетной записи пользователя (вкладка Account) во мно-
гом похоже на соответствующее диалоговое окно в User Manager for
Domains.

Диалоговое окно User Properties, вкладка Account
Здесь следует указать:

• характеристики пароля (должен ли пользователь его изменить при
следующем входе в домен, имеет ли пароль ограничения по сроку);

• не заблокирована ли учетная запись;

• срок истечения времени действия учетной записи;

• профиль пользователя и его домашний каталог;

• время работы;

• рабочие станции, с которых допустим вход в домен.

Подробнее см. [I].

Для включения пользователя в ту или иную группу выберите вкладку
Membership. Появится список групп, в которые входит пользователь.
Поскольку, обычно, пользователь может входить в группы, принадле-
жащие любому домену в дереве, имена групп записываются с указани-
ем относительного пути в каталоге Active Directory.

Диалоговое окно User properties, вкладка Membership

Чтобы включить пользователя в новую группу, выделите ее в списке и
щелкните кнопку Add. Чтобы исключить пользователя из группы, вы-
делите ее в списке и щелкните кнопку Remove.

Права доступа к пользовательскому объекту станут доступны для про-
смотра и редактирования, если выбрать вкладку Security. Если рассмат-
риваемый объект не является контейнером, то для него определяются
наиболее общие разрешения, приведенные в таблице 2-1.

Таблица 2-1

Таблица 2-1 (продолжение)

Диалоговое окно User Properties, вкладка Security

Обратите внимание на то, что доступ можно не только предоставлять
(поле Allow), но и запрещать (поле Deny). Это позволяет избежать
создания множества дополнительных групп с наборами прав доступа,
немногим отличающимися друг от друга.

Дополнительно к перечисленным правам доступа для пользовательско-
го объекта, определены еще несколько (см. таблицу 2-2).

Таблица 2-2

Чтобы добавить нового пользователя в организационную единицу (OU),
щелкните ее имя правой кнопкой мыши, выберите в контекстном меню
команду New/User. Появится диалоговое окно Create User.

w.

Это диалоговое окно во многом похоже на аналогичное в User Manager
for domains. В нем так же можно указать общее имя пользователя (сп),
его полное имя, пароль (со сроком действия, если есть), запрещено ли
использование этой учетной записи. Отличие же состоит в том, что
теперь, не создав пользователя, нельзя определить его свойства. Ранее
же такая возможность предоставлялась еще до фактического добавле-
ния учетной записи в базу.

Свойства групп можно просмотреть так же, как и свойства любого объ-
екта в каталоге: щелкнуть правой кнопкой мыши имя группы и в кон-
текстном меню выбрать команду Properties. Перед Вами появится ди-
алоговое окно Group Properties.

Диалоговое окно Group Properties, вкладка General

В диалоговом окне Group Properties есть вкладки со следующей ин-
формацией:

• General — общей о группе, а также список ее членов;

• Membership — о том, в какие группы входит выбранная группа;

• Managed by — об администраторе группы;

• Object — об объекте-группе;

• Security — о правах доступа к объекту-группе.

Список членов группы представлен в виде относительного имени
пользователей в каталоге, например, domain /Users/Account Name. Для до-
бавления новых пользователей надо щелкнуть кнопку Add и выбрать
пользователей этого или иного домена.

Диалоговое окно Group Properties, вкладка Membership

Напомню, что в предыдущих версиях Windows NT вложенными могли
быть только глобальные группы, которые включались в локальные. В
новой версии все группы могут быть вложенными. Чтобы включить
существующую группу в какую-либо иную, надо в окне свойств группы
выбрать вкладку Membership. Перед Вами появится список групп, в
которые входит выбранная. Так как в общем случае группы могут при-
надлежать разным доменам, имена групп представлены в виде относи-
тельного имени объекта в каталоге, например, domain/Builin/Admi-
nist rato rs. Для включения группы в еще одну группу щелкните кнопку
Add и укажите нужную группу. Для исключения выбранной группы из
другой — выделите в списке имя той группы, которую надо покинуть, и
щелкните кнопку Remove.

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

Домены Windows NT

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

Как уже указывалось, домены объединяются в деревья. Для просмотра
дерева доменов используется специальный слепок консоли управления
(domain.msc), называемый Domain Tree Management. На рисунке показа-
но окно консоли с загруженным слепком и одним доменом в дереве.

Окно консоли управления с загруженным слепком Domain Tree
Management

Если Вы щелкните имя домена правой кнопкой мыши, то в появившем-
ся контекстном меню увидите две команды: Manage и Properties. Пер-
вая вызывает загрузку в консоль слепка DNS Manager, а вторая имеет
прямое отношение к теме данной главы и позволяет вывести на экран
диалоговое окно Domain Properties.

Диалоговое окно Domain Properties, вкладка General

В диалоговом окне Domain Properties несколько вкладок со следую-
щей информацией:

• General — общей, а также о правилах, используемых в домене и
локально;

• Trusts — о доверительных отношениях явного типа (не Kerberos);

• Mode — о режиме работы домена;

• Managed by — общей об администраторе домена;

• Object — об идентификации доменного объекта в каталоге;

• Security — о параметрах доступа к домену и объекту.

Установление доверительных отношений явного типа ничем не отли-
чается от применявшегося в предыдущих версиях: в верхний список
заносятся имена доменов, которым доверяет данный домен; а в ниж-
ний — имена доменов, которые могут ему доверять.

Диалоговое окно Domain Properties, вкладка Trusts

Как уже указывалось, эти доверительные отношения есть смысл зада-
вать лишь тогда, когда двустороннее транзитивное доверие Kerberos,
устанавливаемое по умолчанию, не отвечает безопасности; а также в
случае связи между корневыми доменами деревьев в лесу (см. главу 1).

Домены могут работать в двух режимах: «родном» (native) и смешанном
(mixed). При работе в смешанном режиме в домен могут входить как
контроллеры доменов, на которых установлена версия Windows NT 5.0,
так и с более ранними версиями.

«Родной» режим работы допускает включение в домен только контрол-
леров домена с Windows NT 5.0. В этом режиме появляется возможность
создания вложенных групп, а также междоменного членства в группе.

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

Информация о домене представляет собой набор свойств доменного
объекта. Среди свойств есть обязательные, например, имя домена. А вот

Диалоговое окно Domain Properties, вкладка Mode

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

Диалоговое окно Domain Properties, вкладка Managed By

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

Диалоговое окно Domain Properties, вкладка Security

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

Таблица 2-3

Таблица 2-3 (продолжение)

Локальная политика безопасности

Для редактирования локальной политики безопасности необходимо в
диалоговом окне Domain Properties, на вкладке General щелкнуть
кнопку Edit в группе Computer security policy при включенном флаж-
ке Use a local policy object in this domain. На экране появится диа-
логовое окно Default Local Policy Properties.

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

По сравнению с имевшимися в Windows NT 4.0 возможностями аудита,
в новой версии ОС добавлен аудит еще двух категорий событий. Это
специфичные события, связанные с доступом к службе каталогов Active
Directory, и события, относящиеся к аутентификации Kerberos. Досту-
пен раздельный аудит успешных и неуспешных событий.

Диалоговое окно Default Local Policy Properties, вкладка Audit Policy

Вкладка Administrative Roles отражает делегирование административ-
ных полномочий, уже описанное ранее. Предположим, что Вам необ-
ходимо предоставить полномочия оператора учетных записей пользо-
вателю Hitrov, определенному в OU=TestLab в домене ОМ=Мозс(ЖДля это-
го выберите в списке встроенных административных ролей Account
operators и щелкните кнопку Add. Из списка всех пользователей и групп
выберите нужного Вам пользователя (Moscow/Test Lab/Hit rov). Пример
делегирования административных полномочий приведен на рисунке.

Диалоговое окно Default Local Policy Properties,
вкладка Administrative Roles

С помощью вкладки User Rights Вы можете наделять отдельных пользо-
вателей определенными дополнительными полномочиями (аналогич-
ный порядок действует и в предыдущей версии).

Диалоговое окно Default Local Policy Properties, вкладка User Rights

Выделив привилегию, Вы увидите список пользователей, которым она
предоставлена, а щелкнув кнопку Arid — сможете добавить в этот спи-
сок новые учетные записи. Как и все уже откомментированные спис-
ки пользователей, этот также перечисляет пользователей в формате
domain/orgunit/name. В таблице 2-4 перечислены все предлагаемые
встроенные привилегии и учетные записи пользователей, обладающих
ими по умолчанию.

Таблица 2-4

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

Таблица 2-4 (продолжение)

Таблица 2-4 (продолжение)

Доменная политика

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

Для редактирования доменной политики следует щелкнуть кнопку Edit
в группе Domain security policy на вкладке General диалогового окна
Domain Properties. На экране появится диалоговое окно Default
Domain Policy Properties. С его помощью можно изменять:

• максимальный срок действия пароля;

• минимальную длину пароля;

• минимальный срок неизменности пароля;

• уникальность пароля;

• блокировку учетных записей при неудачной регистрации;

• продолжительность блокировки;

• а также некоторые другие параметры.

Диалоговое окно Default Domain Policy Properties,
вкладка Password Policy

Если пароль пользователя долгое время неизменен, защищенность сис-
темы от несанкционированного доступа значительно снижается. Имен-
но поэтому система должна принуждать пользователя к периодической
смене пароля. Политика ведения учетных записей позволяет задать
определенный срок действия пароля в пределах от 1 до 999 дней или
назначить пароль постоянным. По умолчанию продолжительность дей-
ствия пароля 42 дня.

Если администратор задал параметр Password never expires для кон-
кретного пользователя, тот может не менять пароль. Но такая практика
рекомендуется только для служебных учетных записей, от имени кото-
рых исполняются сервисы в системе.

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

Ограничение минимально возможного срока изменения пароля пользо-
вателем целесообразно, например, если в системе работает много на-

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

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

Минимальный период для разрешения смены пароля варьируется в
пределах от 1 до 999 дней. По умолчанию он не ограничивается. Обыч-
но, достаточно установить 14 дней.

Параметр Password uniquiness позволяет запоминать в системе от 1
до 24 паролей, что обеспечивает уникальные пароли для пользователя
на протяжении длительного времени.

Включив флажок Password must be strong. Вы снимете с себя тяжкое
бремя! Вам больше не придется разъяснять пользователям, почему в
качестве пароля нельзя использовать свое имя, имена жены, детей, про-
чих родственников и домашних животных, дату своего (или чьего-либо
еще) дня рождения и вообще любые слова и фразы, присутствующие в
словарях. Система сама позаботится о том, чтобы пароль содержал как
минимум три из перечисленных ниже типа символов:

• прописные буквы латинского алфавита;

• строчные буквы латинского алфавита;

• цифры;

• специальные символы.

Если включен флажок User must logon in order to change password,

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

Открыв вкладку Account Lockout диалогового окна Default Domain

Policy Properties, Вы попадете в раздел доменной политики, позволя-
ющий обезопасить Вашу систему от «словарных атак»- — программ,
взламывающих систему защиты путем перебора в поисках пароля наи-
более часто используемых слов и фраз из словаря. Чтобы такая про-
грамма не могла работать, установите максимальное число неудачных
попыток регистрации (по умолчанию пять), после которых учетная за-
пись будет заблокирована. Можно также указать время, через которое
счет неудачных попыток сбросится (по умолчанию 20 минут), и время,
в течение которого учетная запись будет блокирована (по умолчанию

1 час). После удачной регистрации счет неудачных регистрации будет
обнулен.

Диалоговое окно Default Domain Policy Properties, вкладка
Account Lockout

Редактор конфигураций безопасности

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

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

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

некоторые области, что ни в коей мере не ограничивает Вас в иденти-
фикации и добавлении в редактор новых областей.

По умолчанию поддерживаются следующие области безопасности:

• политика безопасности — задание различных атрибутов безопас-
ности на локальном и доменном уровнях; так же охватывает неко-
торые установки на машинном уровне;

• управление группами с ограничениями — позволяет управлять
членством в группах, которые, по мнению администратора, «чув-
ствительны» с точки зрения безопасности системы;

• управление правами и привилегиями — позволяет редактиро-
вать список пользователей и их специфических прав и привилегий;

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

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

Функции редактора конфигураций безопасности

Редактор конфигураций безопасности — слепок консоли управления
ММС. Рассмотрим его основные функции.

• Определение шаблонов конфигураций безопасности. Если
Вы стремитесь обеспечить безопасность в масштабах предприятия,
насчитывающего сотни или тысячи компьютеров, лучше всего вос-
пользоваться шаблонами вместо индивидуальной настройки каждой
машины. Предположим, что все компьютеры могут иметь десять раз-
личных вариантов настройки параметров защиты. В таком случае,
удобно сделать десять шаблонов, каждый из которых будет соответ-
ствовать своему варианту защиты, и применять эти шаблоны в со-
ответствии с потребностями. Когда Вы применяете шаблон, в реестр
компьютера вносятся изменения, которые и определяют настройки
системы безопасности. Шаблоны безопасности в Windows NT — это
текстовые файлы, формат которых похож на формат inf-файлов. В
отдельных секциях описываются различные параметры безопасно-
сти. При загрузке файла в редактор конфигураций эти параметры
отображаются в удобном для анализа и редактирования виде. Редак-
тор также позволяет создавать новые файлы-шаблоны.

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

дет к записи параметров из шаблона в реестр), либо воспользовать-
ся версией редактора, исполняемой из командной строки. При вто-
ром варианте вызов редактора можно встроить в административный
сценарий, который будет исполнен или незамедлительно, или в лю-
бое удобное для Вас время.

• Анализ системной безопасности. Анализ параметров, сравнение
их с заданными, обеспечивающими определенный уровень защиты,
не менее важен, чем собственно настройка. Так, в Windows NT Re-
source Kit 4.0 входит утилита, позволяющая на основе анализа на-
строек системы делать заключение о соответствии защиты уровню
С2. Редактор конфигураций безопасности дает возможность сравни-
вать настройки с шаблоном. Выполняется эта операция либо с по-
мощью соответствующей команды меню редактора, либо запуском
из командной строки.

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

Внимание! Упомянутые функции поддерживаются только версией
редактора с пользовательским графическим интерфейсом. Версия для
исполнения в командной строке поддерживает только конфигуриро-
вание системы и сводку результатов анализа.

Графическая версия редактора

Как уже упоминалось, редактор конфигураций безопасности представ-
ляет собой слепок для консоли управления. Однако в первой бета-вер-
сии Windows NT Server он не устанавливается в системе по умолчанию.

Графический интерфейс редактора конфигураций безопасности

Чтобы установить редактор конфигураций безопасности, следует вой-
ти в каталог %windir%\System32 и дать команду Regsvr32 wsecedit. dll.
Затем нужно запустить консоль управления Microsoft Management Con-
sole и добавить к ней слепок Security configuration Editor. (Подробнее о
загрузке слепков — в главе 6).

На экране появится окно ММС с загруженным слепком редактора.

Версия редактора для командной строки

Для запуска версии редактора конфигураций безопасности в команд-
ной строке наберите secedit /?. Программа выведет на экран список
доступных параметров.

Версия редактора конфигураций безопасности для командной
строки

Назначение параметров следующее:

• /configure — конфигурирует систему;

• /analyse — анализирует параметры безопасности системы;

• /scppath scppath—указывает полный путь к профилю конфигура-
ции безопасности;

• /sadpath sadpath — указывает путь к тому месту, где будет создана
база данных для последующего анализа состояния защиты (эта ин-
формация игнорируется, если система была ранее сконфигурирова-
на или анализ уже выполнялся);

• /areas areas — определяет области защиты, которые должны быть
сконфигурированы или проанализированы;

• /log logpath— указывает путь к файлу, в который будут заноситься
сообщения об ошибках.

Конфигурирование безопасности

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

Чтобы работать с шаблоном следует войти в каталог %windir%\secu-
rity\templates и скопировать файл sample.infB файл custom.inf. Открыв
редактор конфигураций, Вы обнаружите в разделе Configuration/Ins-
pection Templates два шаблона — Sample и Custom. Последний можно
использовать для экспериментов.

Политика безопасности

Выбрав в окне обзорного просмотра ветвь, соответствующую шаблону
Custom, щелкните папку Security Policy. В правой части окна появится
перечень параметров политики безопасности, хорошо знакомый каж-

Конфигурирование элементов политики безопасности в шаблоне

дому администратору Windows NT (ограничения, применяемые к па-
ролям, параметры блокировки учетных записей, параметры входа в
систему и т. д). Рядом с каждым из параметров указано значение, запи-
санное в шаблоне.

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

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

Управление правами и привилегиями
пользователей

Выбрав в окне обзорного просмотра ветвь, соответствующую шаблону
Custom, щелкните папку User rights assignments. В правой части окна
появится список привилегий, а также список групп пользователей, ко-
торым назначены эти привилегии в шаблоне. Чтобы добавить новые
группы или исключить уже имеющиеся, дважды щелкните название
привилегии и выполните необходимые изменения в появившемся ди-
алоговом окне.

К()11фигурч1>оваш1е привилегий пользователей в шаблоне

Управление группами с ограниченными правами

Выбрав в окне обзорного просмотра ветвь, соответствующую шаблону
Custom, щелкните папку Restricted Groups. В шаблоне, который постав-
ляется в качестве примера, показана только одна группа с ограничени-
ями — Administrators. Вы можете добавить иные группы, отредакти-
ровав шаблон по своему усмотрению.

В списке перечислены пользователи — члены той или иной группы, а
в списке Member of— те группы, членами которых одновременно яв-
ляются эти пользователи. Таким образом, Вы можете четко контроли-
ровать всех, кто принадлежит к той или иной группе с ограниченными
полномочиями, а также их привилегии и права.

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

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

Управление членством в группах с ограниченными полномочиями

Управление доступом к реестру

Реестр — это дерево объектов. Доступ к каждому объекту в дереве дол-
жен быть регламентирован. Выбрав в окне обзорного просмотра ветвь,
соответствующую шаблону Custom, щелкните папку Registry. В правой

части окна появится список ветвей реестра, доступ к которым можно
ограничивать. В шаблоне, поставляемом с редактором, приведена не-
кая мифическая ветвь MACHINE\HARDWARE, которую надо истолковывать
как HKEY_LOCAL_MACHINE\Hardware. Чтобы добавить к дереву новые вет-
ви, их надо в явном виде прописать в шаблоне с помощью любого тек-
стового редактора.

Для разграничения доступа к выбранной ветви реестра дважды щелк-
ните ее имя и укажите нужный тип доступа и имя соответствующей
учетной записи. Изменения будут занесены в шаблон.

Управление доступом к ветви реестра

Разграничение доступа к файлам

Шаблоны можно использовать для разграничения доступа к файлам
локального компьютера. Все дисковые тома рассматриваются в виде
узлов одного дерева. Выбрав в окне обзорного просмотра ветвь, соот-
ветствующую шаблону Custom, щелкните папку File System. Образец
файла шаблона содержит описание доступа только к одному каталогу —
%systeii]drive%\temp. Другие каталоги можно добавить в шаблон само-
стоятельно, используя любой текстовый редактор.

Для определения прав доступа дважды щелкните имя нужного файла и
произведите изменения в появившемся диалоговом окне. Вы можете
указать стандартные виды доступа, а также имена пользователей и
групп.

Замечание. Первая бета-версия не позволяет указывать специальный
вид доступа.

Определение в шаблоне прав доступа к файловой системе

Применение шаблона к системе

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

Анализ установок безопасности системы

Чтобы проанализировать действующую конфигурацию безопасности
системы и сравнить ее с шаблонной с помощью редактора, следует
щелкнуть правой кнопкой папку Last Configuration/Inspection и выбрать
в контекстном меню команду Perform Inspection.

После завершения анализа в папке Last Configuration/Inspection появят-
ся вложенные папки, соответствующие разделам шаблона: Security Poli-
cy, User Rights Assignment, Restricted Groups, System Services, Registry и
File System. В них будут помещены результаты анализа.

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

Анализ политики безопасности

Выбрав в окне обзорного просмотра ветвь, соответствующую результа-
там анализа, щелкните папку Security Policy. В правом окне появится
список соответствий.

Результаты сравнения действующей конфигурации политики
безопасности с шаблонной

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

Анализ привилегий пользователей

Выбрав в окне обзорного просмотра ветвь, соответствующую результа-
там анализа, щелкните папку User Rights Assignment. В правом окне
появится список соответствий.

Этот список похож на описанный ранее, однако надо сделать неболь-
шое замечание. В третьей колонке достаточно много строк, отмечен-
ных как Not Configured. Тем не менее результат сравнения с шабло-
ном оценивается для них как положительный.

Результаты анализа использования прав пользователей

Анализ доступа к реестру

Результаты доступа к реестру отображаются в несколько ином виде. В
том случае, если назначенные в шаблоне права совпадают с фактичес-
кими, в столбце Permission будет запись Match, в противном случае —
Mismatch.

Результаты анализа защищенности ветви реестра

Заключение

Система безопасности Windows NT 5.0, интегрированная со службой
каталогов Active Directory, позволяет гибко решать проблемы построе-
ния надежной наращиваемой корпоративной сети. Новые средства ад-
министрирования позволяют управлять учетными записями в рамках
больших сетей. Доверительные отношения Kerberos существенно упро-
стили построение сложных многодоменных деревьев, отражающих
структуру организации. Использование стандартных протоколов позво-
ляет интегрировать Windows NT в гетерогенные сети и использовать
единые механизмы защиты.

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

Все это свидетельствует, что новая версия приспособлена для работы как
в сетях крупных транснациональных корпораций, так и в Интернете.