Административные шаблоны

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

Административные шаблоны не задействуют весь реестр целиком, а только два его ключа: HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER. Создаваемый пользователем административный шаблон может охватывать любые подразделы в рамках указанных ключей. Ключ HKEY_LOCAL_MACHINE используется для определения настроек операционной системы. Значения параметров данного ключа используются для настройки системы непосредственно на этапе ее инициализации (т. е. до момента регистрации пользователя). Содержимое этого ключа реестра определяется в рамках административного шаблона групповой политики конфигурации компьютера (computer configuration).

Ключ HKEY_CURRENT_USER используется для формирования на рабочей станции индивидуальной среды пользователя. Значения параметров данного ключа используются для настройки системы на этапе регистрации пользователя. Содержимое этого ключа реестра определяется в рамках административного шаблона групповой политики конфигурации пользователя (user configuration).

Хотя, как было замечено, административный шаблон может использоваться для конфигурирования любых ключей реестра, предпочтительным является использование ключей HKEY_LOCAL_MACHINE\software\Policies (для управления Параметрами компьютера) И HKEY_CURRENT_USER\Software\Policies (для управления средой пользователей). Данные ключи реестра очищаются системой автоматически, при каждом применении или отзыве объекта групповой политики. Как следствие, в случае, когда компьютер не подпадает под действие ни одного объекта групповой политики, для настройки системы используются стандартные значения параметров, определенных в соответствующих ключах реестра.

Административный шаблон представляет собой текстовый файл в формате Unicode, в котором определяются требуемые значения параметров реестра. Данный файл имеет расширение adm и хранится в папке %SystemRoot%\inf. Файл содержит перечисление ключей и параметров реестра, которые должны быть определены администратором в процессе формирования групповой политики. Административные шаблоны, поставляемые в составе Windows Server 2003, перечислены в табл. 21.2.

Таблица 21.2. Административные шаблоны, поставляемые в составе Windows Server 2003

Административный шаблон	Описание
Common.adm	Административный шаблон, используемый для настройки параметров системы на Windows 9х/МТ-клиентах
Conf.adm	Административный шаблон, используемый для настройки NetMeeting
Inetcorp.adm	Административный шаблон, используемый для настройки браузера Internet Explorer для работы в корпоративной среде
Inetres.adm	Административный шаблон, используемый для настройки ограничений браузера Internet Explorer
Inetset.adm	Административный шаблон, используемый для настройки браузера Internet Explorer
System. adm	Административный шаблон, используемый для настройки различных параметров системы
Windows. adm	Административный шаблон, используемый для конфигурирования Windows Эх-клиентов
Winnt.adm	Административный шаблон, используемый для конфигурирования Windows NT-клиентов
Wmplayer.adm	Административный шаблон, используемый для настройки приложения Windows Media Player
Wuau.adm	Административный шаблон, используемый для настройки службы автоматического обновления

Для работы с шаблонами Common.adm, Windows.adm и Winnt.adm необходимо использовать утилиту System Policy Editor (Редактор системной политики).

Блокировка процесса наследования параметров объектов групповой политики

Администратор может управлять процессом наследования параметров объектов групповых политик. Для этого в окне оснастки Active Directory Users and Computers необходимо открыть окно свойств контейнера, к которому привязан объект групповой политики. На вкладке Group Policy (Групповая политика) необходимо установить флажок Block Policy inheritance (Блокировать наследование политики) (рис. 21.14). При этом параметры групповой политики, определенные на уровне вышестоящих контейнеров, не будут распространяться на содержимое конфигурируемого контейнера.

Использование групповых политик

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

Настройка основного режима перенаправления папок

В данном режиме для всех пользователей используется единая схема перенаправления папок. Администратору при этом необходимо определить, какая именно из возможных схем будет использоваться для перенаправления.

 Папки всех пользователей перенаправляются в одну общую папку. Для выбора данной схемы в поле Target folder location (Расположение папки) следует выбрать значение Create a folder for each user under the root path (Создать папку для каждого пользователя в корневой папке) (рис. 21.9).

В поле Root Path (Путь к корневой папке) необходимо указать общую папку, которая будет использоваться для размещения перенаправленных папок.

Рис. 21.9. Настройка основного режима перенаправления папки

 Папки пользователей перенаправляются на некоторый сетевой ресурс, на котором для каждого пользователя создается отдельная папка. Для выбора данной схемы в списке Target folder location (Расположение папки) необходимо выбрать значение Redirect to the following location (Перенаправить в следующее место). В поле Root Path (Путь к корневой папке) необходимо указать папку, в которую будет производиться перенаправление папок.

 Папки пользователей перенаправляются в локальный профиль пользователя. Данная схема перенаправления необходима для того, чтобы вернуть содержимое папок из сетевого ресурса в локальный профиль пользователя. Если просто отключить механизм перенаправления, то содержимое папок пользователя будет утеряно. Поэтому перед отключением администратор должен перенаправить папки пользователя на его локальный профиль. Только после выполнения этой операции администратор может отключить механизм перенаправления. Для выбора данной схемы в списке Target folder location (Расположение папки) необходимо выбрать значение Redirect to the local user profile location (Перенаправить в локальный профиль пользователя).

Для папки My Documents (Мои документы) возможна еще одна схема перенаправления. Указанная папка может быть перенаправлена в домашнюю папку пользователя (home directory). Подобная схема перенаправления разрешена только для клиентов, находящихся под управлением операционных систем Windows XP Professional и Windows Server 2003.

Для выбора данной схемы в списке Target folder location (Расположение папки) необходимо выбрать значение Redirect to the user's home directory (Перенаправить в домашнюю папку пользователя). При этом на момент перенаправления для пользователя должно быть определено месторасположение домашней папки. Для этого на вкладке Profile (Профиль) окна свойств объекта, ассоциированного с пользователем, необходимо в группе элементов Home folder (Домашняя папка) указать требуемую папку. Это может быть как папка на локальном диске, так и некий сетевой ресурс (рис. 21.10).

Рис. 21.10. Назначение домашней папки пользователя

Настройка расширенного режима перенаправления папок

Расширенный режим позволяет выбирать способ перенаправления папок пользователя в зависимости от его членства в группах. Благодаря этому, администратор может реализовать различные уровни обеспечения надежности для хранимых папок для разных категорий пользователей (рис. 21.11). Наиболее важные документы, например, должны храниться на RAID-массивах. Как следствие, администратор может организовать различные политики резервного копирования для этих данных.

Рис. 21.11. Настройка расширенного режима перенаправления папки

Конфигурирование расширенного режима перенаправления папки выполняется аналогично основному режиму. Чтобы определить возможные параметры режима, надо щелкнуть по кнопке Add (Добавить) и в открывшемся окне (рис. 21.12) в поле Security Group Membership указать группу, для членов которой необходимо определить перенаправление. Остальные параметры аналогичны рассмотренным в предыдущем разделе.

Рис. 21.12. Конфигурирование параметров перенаправления

Назначение приложений

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

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

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

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

Для назначения приложения в контекстном меню контейнера Software Installation необходимо выбрать пункт Package. В открывшемся окне требуется указать месторасположение инсталляционного пакета. В окне Deploy Software администратор должен установить параметр Assigned (см. рис. 21.13).

Ограничение действия параметров групповой политики

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

Рис. 21.16. Запрет на применение параметров данного объекта групповой политики к членам группы Enterprise Admins

Для этого необходимо на вкладке Security (Безопасность) окна свойств выбранного объекта групповой политики указать нужную группу безопасности и установить флажок Deny (Запретить) напротив разрешения Apply Group Policy (Применять групповую политику) (рис. 21.16). Эта процедура называется фильтрацией групповых политик (group policy filtering).

Определение действующих политик

Для работы с доменными групповыми политиками в системах Windows Server 2003 имеются появившиеся еще в Windows XP две очень полезные утилиты командной строки:

 GPUpdate.exe — выполните эту команду, если вы изменяли групповые политики и хотите, чтобы они немедленно стали активными (сначала запустите ее с параметром /?). В Windows 2000 для этих целей использовалась команда secedit /refreshPolicy;

 GPResult.exe — эта команда, входившая ранее в состав пакета Windows 2000 Resource Kit, стала стандартной командой системы. С ее помощью можно определить, какие настройки групповых политик фактически применяются по отношению к указанному компьютеру/пользователю. Может выполняться для удаленного компьютера. Запускать команду лучше всего с параметром /v — в этом случае сразу становятся видны ее возможности. Аналогичную задачу выполняет описываемая ниже оснастка Resultant set of Policies (Результирующая политика).

Оснастка Group Policy Object Editor

Оснастка Group Policy Object Editor (Редактор объектов групповой политики) используется для редактирования параметров объектов групповой политики (group policy objects, GPO). Эта оснастка может использоваться для редактирования любых объектов GPO (как локальных, так и тех, что хранятся в каталоге). Администратор может запустить оснастку Group Policy Object Editor из определенных административных оснасток. Кроме того, эта оснастка может быть добавлена непосредственно в пользовательскую консоль.

Оснастка позволяет конфигурировать параметры групповой политики, касающиеся как компьютера, так и пользователя. В панели пространства имен оснастки эти группы параметров GPO представлены контейнерами Computer Configuration (Конфигурация компьютера) и User Configuration (Конфигурация пользователя).

Оснастка Group Policy Object Editor предоставляет администратору больше возможностей по конфигурированию параметров групповой политики по сравнению с другими оснастками, предполагающими работу с групповой политикой, — оснастками Local Security Policy, Domain Controller Security Policy и Domain Security Policy. Указанные оснастки обеспечивают доступ только к ограниченному подмножеству параметров групповой политики, расположенных в контейнере Security Setting (Параметры безопасности) соответствующего объекта групповой политики. Оснастки Domain Controller Security Policy и Domain Security Policy устанавливаются на каждом контроллере домена. Оснастка Local Security Policy присутствует на каждом рядовом компьютере под управлением Windows 2000/XP или Windows Server 2003.

Оснастка Resultant set of Policies

В системах Windows XP и Windows Server 2003 имеется очень удобный инструмент для работы с групповыми политиками, который особенно оценят администраторы крупных доменов с многоуровневой иерархией объектов GPO — это оснастка Resultant set of Policies (Результирующая политика).

Информацию о результирующих политиках можно получать в одном из двух режимов.

 Режим планирования (planning mode) позволяет администраторам моделировать использование групповых политик, определенных в различных объектам GPO, при этом можно даже не выбирать целевые компьютеры и пользователей. К примеру, с помощью этого режима можно получить ответ на вопрос "Какие установки групповых политик применяются к пользователям, учетные записи которых находятся в подразделении Admins, а зарегистрировались они на компьютерах, входящих в подразделение Managers?" При этом можно также моделировать присутствие или отсутствие пользователя в определенных группах безопасности.

 Режим ведения журнала (logging mode) можно использовать только для определения реально действующих параметров групповых политик для пользователя, зарегистрированного на некотором компьютере.

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

Процедура предварительного конфигурирования оснастки Resultant Set of Policy практически одинакова для обоих режимов, поэтому нет смысла рассматривать их индивидуально. Для примера определим, какие групповые политики применяются к пользователям, чьи учетные записи располагаются в некотором подразделении. Для этого:

1. Откроем оснастку Active Directory Users and Computers, выберем в окне структуры интересующее нас подразделение и в контекстном меню выполним команду All Tasks | Resultant Set of Policy (Planning) (Все задачи | Результирующие политики (планирование)).

2. В окне мастера Resultant Set of Policy Wizard (рис. 21.17) можно изменить выбранный контейнер (нажав кнопку Browse и выбрав другой контейнер для пользовательского или компьютерного объекта) или конкретизировать запрос, установив переключатель User или Computer и выбрав соответствующую учетную запись (которая может находиться и в другом подразделении).



Рис. 21.17.Окно выбора объектов, для которых определяются результирующие политики

3. Пропустим второстепенные настройки мастера, для чего установим флажок Skip to the final page и нажмем кнопку Далее (Next).

4. После проверки правильности заданных критериев на странице Summary of Selections снова нажмем кнопку Next. Система некоторое время будет анализировать параметры политик.

5. На последней странице мастера нажмем кнопку Finish (Готово).

Процесс анализа завершен — можно анализировать результаты. В окне (рис. 21.18), напоминающем окно оснастки Group Policy Object Editor, будут отображаться только те папки (ниже второго уровня), в которых имеются установленные политики. В нашем случае узел Computer Configuration содержит все политики, действующие на учетные записи компьютеров, находящиеся в подразделении Admins, а узел User Configuration содержит все политики, действующие на учетные записи пользователей, находящиеся в этом же подразделении.



Рис. 21.18. Оснастка Resultant Set of Policy позволяет быстро найти действующие политики

Например, в нашем примере показано, что для выбранного пользователя установлен сценарий выхода из системы (узел Logoff), а для компьютера задана политика отключения журнала событий выключения системы — Display Shutdown Event Tracker; причем в столбце GPO Name можно видеть, что эта политика была установлена доменным объектом GPO. Полученные сведения можно (и полезно!) проверить с помощью утилиты GRResult и сравнить результаты.

Полученный инструмент ММС можно закрыть или сохранить (при повторном запуске оснастка вновь анализирует систему и выводит обновленные данные). Можно изменить критерии запроса и выполнить анализ повторно, не закрывая полученной оснастки Resultant Set of Policy. Для этого нужно выбрать корневой узел в окне структуры и в меню Action выполнить команду Change Query.

Перенаправление пользовательских папок

Традиционным местом размещения документов пользователей является папка My Documents (Мои документы). В ситуации, когда пользователи перемещаются по организации, регистрируясь в сети на различных рабочих станциях, администратор может использовать перемещаемые профили для организации централизованного хранения пользовательских документов и настроек (roaming user profiles).

Профиль создается в момент первой регистрации пользователя в системе. По умолчанию локальные профили пользователя в операционных системах Windows 2000/XP и Windows Server 2003 размещаются в папке Documents and Settings (Документы и настройки). Механизм перемещаемых профилей позволяет организовать централизованное хранение всех настроек и документов пользователей на сервере. Централизованное хранение профилей позволяет упростить такие процессы, как регулярное резервное копирование, проверка на наличие вирусов и т. п.

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

Таблица 21.3. Папки пользовательского профиля, для которых допускается перенаправление

Папка		Описание
Application data		В папке размещается информация, используемая приложениями. Некоторые приложения могут хранить в этой папке свои настройки, индивидуальные для каждого конкретного пользователя
Desktop		В папке хранятся объекты рабочего стола, включая ярлыки и файлы
My Documents		Папка используется для размещения документов пользователя
My Pictures		Папка используется для размещения графических файлов пользователя
Start Menu		В папке размещаются ярлыки программ главного меню

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

Режим перенаправления пользовательских папок настраивается в объектах групповой политики исключительно в конфигурации пользователя. Для определения параметров этого режима используется категория параметров Folder Redirection (Перенаправление папок). Администратор может определить индивидуально параметры перенаправления для каждой из пяти описанных папок. Для этого необходимо в контекстном меню объекта, ассоциированного с папкой, выбрать пункт Properties. На вкладке Target из раскрывающегося списка Setting (Настройка) необходимо выбрать режим перенаправления. Возможны три режима перенаправления папок. .

 Перенаправление папки не выполняется. Чтобы выбрать данный режим, необходимо выбрать из списка значение Not configured (He определено).

 Основной режим. В данном режиме указанная папка для всех пользователей, подпадающих под действие редактируемого объекта групповой политики, перенаправляется на один сетевой ресурс. Данному режиму соответствует значение Basic - Redirect everyone's folder to the same location (Основной — перенаправлять папки всех пользователей в одно место).

 Расширенный режим. В этом режиме администратор может определить перенаправление папок пользователей на различные сетевые ресурсы. Выбор конкретного сетевого ресурса определяется группой, к которой принадлежит пользователь. Для выбора этого режима перенаправления в списке необходимо выбрать значение Advanced — Specify locations for various user groups (Расширенный — определить место для различных групп пользователей).

Ниже рассмотрим процесс настройки основного и расширенного режимов более подробно.

Перенаправление папок возможно только для Windows 2000/XP- и Windows Server 2003-клиентов. Следует также заметить, что функциональность механизма перенаправления папок была существенным образом расширена в Windows Server 2003. Однако появившиеся новые возможности доступны только на клиентах Windows XP и Windows Server 2003.

Построение иерархии объектов групповой политики

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

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

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

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

 последними применяются объекты групповой политики, привязанные к подразделениям.

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

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

Предоставление полномочий на доступ к объектам групповой политики

Администратор может делегировать некоторым пользователям часть обязанностей по управлению объектами групповой политики. Чтобы предоставить пользователю полномочия, необходимые для выполнения привязки объекта групповой политики на уровне определенного контейнера, администратор должен использовать мастер Delegate of Control Wizard (Мастер делегирования управления). При работе мастера надо делегировать пользователям полномочия, необходимые для выполнения задачи управления привязками объектов групповой политики (флажок Manage Group Policy links на странице мастера Tasks to Delegate).

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

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

Применение административных шаблонов

Следует четко понимать, что использование административных шаблонов возможно исключительно через механизм групповой политики. Это означает, что для распространения административного шаблона на некоторое множество компьютеров, он должен являться частью соответствующего объекта групповой политики. Чтобы сделать административный шаблон частью объекта групповой политики, следует загрузить его в оснастку Group Policy Object Editor. Для этого в контекстном меню контейнера Administrative Tools необходимо выбрать пункт Add/Remove Templates (Добавить/удалить шаблоны). В открывшемся окне (рис. 21.6) надо выбрать интересующий шаблон и нажать кнопку Add (Добавить). В результате, шаблон будет применен к конфигурируемому объекту групповой политики.

Рис. 21.6. Применение административного шаблона к объекту групповой политики

При помощи оснастки Group Policy Object Editor администратор имеет возможность редактировать вручную параметры групповой политики, расположенные внутри контейнера Administrative Templates и отвечающие за конфигурирование реестра клиентского компьютера. Выбрав интересующий параметр, администратор должен открыть окно его свойств. На вкладке Settings (Настройки) окна свойств (рис. 21.7) можно определить значение выбранного параметра:

 Not Configured (He определено). Данное значение оставляет неопределенной возможность использования пользователем выбранного режима в рамках рассматриваемого объекта групповой политики. Фактически доступность выбранного режима удаленной установки ставится в зависимость от значения аналогичного параметра групповой политики, определенного на вышестоящем уровне;

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

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

Рис. 21.7. Определение параметров групповой политики

Привязка объекта групповой политики к контейнеру Active Directory

Любой объект групповой политики может быть привязан к некоторому сайту, домену или подразделению. Один объект групповой политики может быть привязан к множеству контейнеров. Для выполнения привязки необходимо щелкнуть на кнопке Add на вкладке Group Policy окна свойств контейнера. В окне Browse for a Group Policy Object все объекты групповой политики, существующие в домене, перечислены на вкладке All (Все).

Администратору достаточно выбрать необходимый объект групповой политики и щелкнуть по кнопке ОК.

Возможна и обратная операция. Администратор может найти контейнеры, к которым привязан выбранный объект групповой политики. Для этого в оснастке Group Policy Object Editor необходимо в контекстном меню корневого объекта оснастки выбрать пункт Properties (Свойства), чтобы открыть окно свойств объекта групповой политики. В окне свойств необходимо перейти на вкладку Links (рис. 21.4). Выбрав из раскрывающегося списка Domain нужный домен и щелкнув по кнопке Find Now (Найти), администратор получит список контейнеров, к которым к настоящий момент привязан рассматриваемый объект групповой политики.

Рис. 21.4. Просмотр привязок выбранного объекта групповой политики

Привязка оснастки к объекту групповой политики

Оснастка Group Policy Object Editor может быть вызвана из оснасток Active Directory Users and Computers и Active Directory Sites and Services. Для этого в окне свойств объекта, ассоциированного с сайтом, доменом или подразделением, необходимо перейти на вкладку Group Policy (рис. 21.1).

Рис. 21.1.Вкладка Group Policy окна свойств подразделения

Чтобы изменять параметры произвольного объекта GPO, администратор должен вручную загрузить оснастку Group Policy Object Editor в консоль ММС, при этом необходимо выполнить ее привязку к некоторому объекту групповой политики. В окне Select Group Policy Object (Выбор объекта групповой политики) по умолчанию предлагается привязать оснастку либо к локальному объекту GPO, либо к одному из доменных GPO. Чтобы выбрать объект групповой политики, щелкните по кнопке Browse (Обзор). В окне Browse for a Group Policy Object (Поиск объекта групповой политики) администратор может (рис. 21.2):

 выбрать один из существующих (и, как правило, уже привязанный к какому-нибудь контейнеру каталога) объектов групповой политики в списке и загрузить его для редактирования в оснастку Group Policy Object Editor;

 создать новый объект групповой политики.

Рис. 21.2. Выбор объекта групповой политики

В дальнейшем необходимо различать операцию привязки оснастки Group Policy Object Editor к некоторому объекту GPO и операцию привязки непосредственно самого объекта GPO к некоторому контейнеру каталога.

Следует заметить, что один экземпляр оснастки Group Policy Object Editor позволяет работать только с одним экземпляром объекта групповой политики. Привязка оснасток возможна только в момент создания пользовательских консолей, включающих оснастку Group Policy Object Editor. Если необходимо редактировать другой объект групповой политики, администратор должен запустить второй экземпляр оснастки.

Публикация приложений

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

В процессе публикации приложений инсталляционные пакеты (installation package) помещаются в специальное хранилище. Для установки опубликованного приложения, пользователь должен использовать мастер Add/Remove Programs (Установка/удаление программ). Чтобы просмотреть список опубликованных приложений, пользователь должен щелкнуть по пиктограмме Add New Programs (Добавить новое приложение).

Чтобы опубликовать приложение, в контекстном меню контейнера Software Installation необходимо выбрать пункт New | Package. Указав в открывшемся окне месторасположение инсталляционного пакета, администратор должен указать способ развертывания приложения (рис. 21.13).

Рис. 21.13. Определение способа развертывания приложений

Сценарии

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

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

 сценарии, выполняемые при инициализации системы (startup scripts);

 сценарии, выполняемые при регистрации пользователя в системе (logon scripts);

 сценарии, выполняемые при выключении компьютера (shutdown scripts);

 сценарии, выполняемые при выходе пользователя из системы (logoff scripts).

Интерпретация сценариев осуществляется сервером сценариев Windows Script Host. Этот стандартный компонент, входящий в состав Windows 2000/XP и Windows Server 2003, позволяет создавать сценарии, используя специализированные языки Visual Basic Scripting Edition, JScript. Для старых версий клиентов (Windows 9x/NT) сценарии должны представлять собой пакетные файлы (.bat-файлы), либо нужно установить на них сервер сценариев Windows Script Host (загружаемый свободно с сайта Microsoft).

Все сценарии, определяемые в рамках объекта групповой политики, хранятся в шаблоне групповой политики, который в свою очередь располагается в папке %SystemRoot%\SYSVOL\sysvol\<имя-домена>\policies\<GUID-объекта-групповой-политики>

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

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

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

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



Рис. 21.8. Назначение сценария выхода из системы объекту групповой политики

Создание административных шаблонов

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

Административные шаблоны Windows Server 2003 имеют порядка 200 новых параметров, отсутствующих в административных шаблонах Windows 2000.

Создание и удаление объектов групповой политики

Для создания нового объекта групповой политики достаточно щелкнуть на кнопке New (Создать) на вкладке Group Policy (см. рис. 21.1) в окне свойств некоторого контейнера или щелкнуть на соответствующей кнопке в панели инструментов окна Browse for a Group Policy Object (см. рис. 21.2). Система предложит администратору дать имя создаваемому объекту групповой политики. После этого системой будет создан объект групповой политики со значениями параметров по умолчанию.

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

 Remove the link from the list (Изъять ссылку из списка, не удаляя объекта). Выбирая этот режим, администратор фактически только удаляет привязку выбранного объекта групповой политики к некоторому контейнеру каталога. Непосредственно сам объект групповой политики остается неизменным, и администратор может использовать его впоследствии;

 Remove the link and delete the Group Policy Object permanently (Изъять ссылку и окончательно удалить объект групповой политики). Выбор данного режима приводит к удалению непосредственно самого объекта групповой политики. При этом также удаляются существующие привязки указанного объекта к контейнерам каталога.

Структура объекта групповой политики

Множество параметров, определяемых в рамках объекта групповой политики, разделено на две части. Одна часть параметров используется для конфигурирования компьютера (computer configuration), другая часть параметров используется для конфигурирования среды пользователя (user configuration). Конфигурирование компьютера предполагает определение значений для параметров, влияющих на формирование окружения любых пользователей, регистрирующихся на данном компьютере. Конфигурирование среды пользователя дает возможность управлять процессом формирования окружения конкретного пользователя, независимо от того, на каком компьютере он регистрируется в сети.

Независимо от типа конфигурирования, параметры групповой политики организованы в специальные категории (рис. 21.5). Каждая из категорий параметров групповой политики определяет отдельную область окружения пользователя. Доступные категории параметров перечислены в табл. 21.1. В свою очередь категории параметров групповой политики организованы в три контейнера в соответствии со своим назначением:

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

Рис. 21.5. Структура объекта групповой политики

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

 Administrative Templates (Административные шаблоны). Этот контейнер содержит категории параметров групповой политики, применяемых для управления содержимым системного реестра компьютера.

Таблица 21.1. Категории параметров групповой политики

Категория		Контейнер		Описание
Software Installation		Software Settings		Данная категория параметров используется для централизованного управления приложениями, доступными на данном компьютере, или для данного пользователя. При этом в зависимости от параметров групповой политики приложения могут либо устанавливаться принудительно, либо рекомендоваться для установки
Remote Installation Service		Windows Settings		Данная категория параметров используется для управления процессом удаленной установки на клиентском компьютере. Эта категория параметров доступна только в случае конфигурирования на уровне пользователя
Scripts		Windows Settings		Категория используется для определения сценариев, которые будут выполняться при включении/выключении компьютера (Startup/Shutdown Scripts), либо при регистрации пользователя в системе или его выхода из нее (Logon/Logoff Scripts)
Security Settings		Windows Settings		Параметры данной категории используются для управления настройками безопасности клиентского компьютера. Помимо групповой политики, администратор может также использовать другие механизмы для управления настройками безопасности
Folder Redirection		Windows Settings		Посредством параметров данной категории администратор может сконфигурировать процесс перенаправления папок из пользовательского профиля (таких, например, как My Documents) на некоторый сетевой ресурс. Эта категория параметров доступна только для конфигурации пользователя
Internet Explorer Maintenance		Windows Settings		Параметры данной категории используются для настройки браузера Internet Explorer. Эта категория параметров доступна только для конфигурации пользователя
Windows Components		Administrative Templates		В данной категории представлены параметры, посредством которых администратор может осуществлять управление настройками Windows-компонентов, установленных на конфигурируемой системе
Start Menu and Taskbar		Administrative Templates		Параметры данной категории позволяют администратору конфигурировать главное меню и панель задач клиентского компьютера (прежде всего, ограничивать доступную функциональность). Эта категория параметров доступна только для конфигурации пользователя
Desktop		Administrative Templates		Параметры данной категории позволяют администратору конфигурировать вид рабочего стола клиентского компьютера и его функциональность. Эта категория параметров доступна только в случае конфигурирования на уровне пользователя. Эта категория параметров доступна только для конфигурации пользователя
Control Panel		Administrative Templates		Параметры данной категории позволяют администратору управлять видимостью отдельных компонентов панели управления на клиентском компьютере. Эта категория параметров доступна только для конфигурации пользователя
Shared Folders		Administrative Templates		Параметры данной категории позволяют управлять процессом публикации общих папок. Эта категория параметров доступна только для конфигурации пользователя
Networks		Administrative Templates		Данная категория параметров используется для управления конфигурацией сетевых компонентов системы
System		Administrative Templates		В данной категории представлены параметры, позволяющие управлять настройками реестра, влияющими на поведение системы в целом
Printers		Administrative Templates		Параметры данной категории используются для управления процессом публикации принтеров. Эта категория параметров доступна только для конфигурации компьютера

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

Управление приложениями

Механизм групповой политики может использоваться как средство управления процессом развертывания приложений на Windows 2000/XP- и Windows Server 2003-клиентах. Администратор может определить перечень приложений, которые будут доступны пользователям. В зависимости от выбранного режима, в процессе применения объекта групповой политики на компьютере будут установлены все необходимые приложения. Возможны следующие режимы управления процессом развертывания приложений:

 публикация приложений;

 назначение приложений пользователям',

 назначение приложений компьютерам.

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

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

Выбор контроллера домена

Оснастка Group Policy Object Editor работает с объектами каталога, следовательно, все ее манипуляции с объектами должны производиться в контексте некоторого контроллера домена. Чтобы определить правило выбора контроллера домена, в контексте которого будет работать оснастка Group Policy Object Editor, выберите имя оснастки и в меню View (Вид) выполните команду DC Options (Параметры контроллера домена). В открывшемся окне (рис. 21.3) следует выбрать необходимое значение.

Рис. 21.3. Определение схемы выбора контроллера домена

Отдельного комментария заслуживает вторая из предлагаемых опций. Оснастку Group Policy Object Editor можно запускать из окна оснасток Active Directory Users and Computers или Active Directory Sites and Services, которые в этот момент подключены к определенному контроллеру домена. В подобной ситуации оснастка Group Policy Object Editor может работать с тем же контроллером домена, что и оснастка, из которой она была запущена. Выбранная опция сохраняется и используется при следующем запуске оснастки. При этом, если выбранный контроллер домена недоступен при запуске оснастки, возникает ошибка.

Существует групповая политика, позволяющая администратору определить стратегию выбора предпочитаемого контроллера домена. Откройте используемый объект GPO и перейдите к узлу User Configuration | Administrative Templates | System | Group Policy (Конфигурация пользователя Административные шаблоны | Система | Групповая политика). Откройте политику Group Policy domain controller selection. Активизируйте политику, установив переключатель Enable, а затем одну из следующих возможностей:

 Use the Primary Domain Controller (Использовать основной контроллер домена);

 Inherit from Active Directory Snap-ins (Унаследовать от оснасток Active Directory);

 Use any available domain controller (Использовать любой доступный контроллер домена).

Если эта политика запрещена (disabled) или не установлена (not configured), оснастка Group Policy Object Editor подключается к контроллеру домена, являющегося исполнителем роли РОС. Если политика установлена, она переопределяет опцию, заданную в самой оснастке Group Policy Object Editor.

Примечание

Поскольку при поиске объектов групповой политики выполняются обращения к DNS, ошибки при запуске оснасток Group Policy Object Editor нередко объясняются неправильной работой службы DNS. Поэтому при появлении подобных ошибок всегда проверяйте конфигурацию DNS. Помните о том, что DNS — это динамическая система, и ресурсные записи становятся просроченными и требуют периодической перерегистрации.

Запрещение переопределения параметров объектов групповой политики

Для запрещения переопределения параметров объектов групповой политики в окне свойств контейнера необходимо перейти на вкладку Group Policy и щелкнуть по кнопке Options (Параметры). В открывшемся окне (рис. 21.15) надо установить флажок No Override (He переопределять). При этом на содержимое дочернего контейнера будут распространяться параметры объекта групповой политики, привязанные к родительским контейнерам, даже в том случае, если аналогичные параметры переопределены непосредственно на уровне дочернего контейнера. При установленном флажке No Override наследуемые параметры имеют преимущество над аналогичными параметрами объекта групповой политики, привязанного к дочернему контейнеру, даже если для этого контейнера установлен флажок Block Policy inheritance.

Рис. 21.14. Блокирование процесса наследования параметров объектов групповой политики

Рис. 21.15. Запрещение переопределения параметров объектов групповой политики

Запрещение применения параметров объекта групповой политики

Администратор может запретить применение параметров любых объектов групповой политики к содержимому некоторого контейнера каталога. Для этого на вкладке Group Policy окна свойств контейнера необходимо щелкнуть по кнопке Options (Параметры) и в открывшемся окне (см. рис. 21.15) установить флажок Disabled (Отключено).

Администрирование безопасности IP

Управление безопасностью IP в Windows Server 2003 позволяет администраторам создавать настраиваемую политику безопасности с уникальной политикой переговоров и IP-фильтрами. Не требуются никакие изменения прикладных программ. Также не требуется обучать конечных пользователей, поскольку администраторы конфигурируют всю политику безопасности в службе Active Directory, а действия шифрования прозрачны на уровне конечного пользователя.

Рис. 22.6. Управление политиками IP Security в окне оснастки Default Domain Policy

Можно конфигурировать безопасность IP, используя оснастки Local Security Settings (Локальные параметры безопасности) (на локальном компьютере) или Default Domain Policy (рис. 22.6) (для домена). Также можно подключить к консоли ММС изолированную оснастку IP Security Policy Management (Управление политикой безопасности IP) и настроить ее для компьютера или домена.

Алгоритмы шифрования

Для защиты данных применяются математические алгоритмы шифрования. Безопасность IP в Windows 2000/Server 2003 использует стандартные криптографические алгоритмы, перечисленные ниже.

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

 Код аутентификации хэшированного сообщения (НМАС, Hash Message Authentication Code). НМАС — алгоритм шифрования с закрытым ключом, обеспечивающий целостность сообщений, установление их подлинности и предотвращение повторного использования. Установление подлинности, использующее функции хэширования (перемешивания), объединено с методом закрытого ключа. Хэшированное значение, известное также как дайджест (digest), или выборка сообщений, используется для создания и проверки цифровой подписи. Это уникальное значение намного меньше, чем первоначальное сообщение, созданное из цифровой копии кадра данных. Если передаваемое сообщение изменилось по пути следования, то хэшированное значение будет отличаться от оригинала, а IP-пакет будет отброшен.

 HMAC-MD5. Дайджест сообщений-5 (MD5, Message Digest) — функция хэширования, которая порождает 128-разрядное значение, являющееся подписью данного блока данных. Эта подпись служит для установления подлинности, целостности и предотвращения повторного использования.

 HMAC-SHA. Безопасный алгоритм хэширования (SHA, Secure Hash Algorithm) — еще одна функция хэширования, которая порождает 160-разрядное значение подписи, необходимое для установления подлинности, целостности и предотвращения повторного использования.

 DES-CBC. Стандарт шифрования данных (Data Encryption Standard, DES) — формирование цепочки шифрованных блоков (Cipher Block Chaining, CBC) — алгоритм шифрования с закрытым ключом, обеспечивающий конфиденциальность. Генерируется случайное число, которое используется совместно с закрытым ключом для шифрования данных.

Архитектура безопасности IP

Механизм безопасности IP в Windows Server 2003 разработан для защиты любого сквозного соединения между двумя компьютерами (рис. 22.2). При сквозном соединении два осуществляющих связь компьютера (системы) поддерживают IP-безопасность на каждом конце соединения. Сделано предположение, что располагающаяся между ними среда, по которой передаются данные, небезопасна. Данные прикладной программы компьютера, начинающего связь, перед пересылкой по сети автоматически (прозрачно для прикладной программы) шифруются. На компьютере адресата данные также автоматически дешифруются — прежде, чем они будут переданы приложению-получателю. Шифрование всего сетевого IP-трафика гарантирует, что любая связь с использованием TCP/IP защищена от подслушивания. Поскольку данные передаются и шифруются на уровне протокола IP, для каждого протокола в наборе протоколов TCP/IP не требуются отдельные пакеты, обеспечивающие безопасность.

Безопасность IP в Windows Server 2003 объединяет методы шифрования с открытыми и закрытыми ключами для повышения уровня безопасности и большей производительности.

Управление безопасностью IP в Windows Server 2003 допускает создание политики, определяющей тип и уровень безопасности, необходимые во время обмена информации.

 Политика безопасности (security policy)

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

Рис. 22.2. Архитектура безопасности IP в Windows Server 2003

 Политика переговоров (negotiation policy)

Политика переговоров определяет службы безопасности, используемые во время связи. Можно выбрать услуги, включающие конфиденциальность (ESP) или не обеспечивающие конфиденциальность (АН), или можно определить, какой алгоритм нужно использовать для безопасности IP. Можно установить несколько методов безопасности для каждой политики переговоров. Если первый метод недопустим для ассоциации безопасности, служба ISAKMP/Oakley продолжит просмотр этого списка до тех пор, пока не будет найден тот алгоритм, который безопасность IP сможет использовать для установления ассоциации. Если переговоры не увенчались успехом, устанавливается соединение без безопасности IP.

 IP-фильтры

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

Для поддержки обмена информацией с использованием безопасности IP на каждом компьютере с Windows Server 2003 устанавливаются локальные службы и драйверы.

 Служба агента политики безопасности (Policy Agent Service)

Агент политики — локальный, резидентный агент. Он отыскивает политику безопасности IP в Active Directory во время инициализации системы. Затем он передает информацию о политике сетевому драйверу безопасности IP (IPSec-драйверу) и службе ISAKMP/Oakley. Агент политики не хранит политику безопасности локально, а находит ее в Active Directory (рис. 22.3).



Рис. 22.3. Функционирование агента политики безопасности

 Служба управления ключами ISAKMP/Oakley

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



 Драйвер безопасности IP (IPSec-драйвер)

Это локальный, резидентный агент, который просматривает все IP-пакеты на соответствие фильтру IP. Если он находит соответствие, то задерживает пакеты в очереди, в то время как служба ISAKMP/Oakley генерирует необходимую SA и ключ, чтобы защитить обмен информацией. Агент, получив эту информацию от службы ISAKMP, шифрует IP-пакеты и посылает их компьютеру-адресату (рис. 22.4). Драйвер IPSec запускается агентом политики.



Рис. 22.4. Функционирование драйвера IPSec

Все три перечисленные компонента установлены в Windows Server 2003 по умолчанию и запускаются автоматически.

Каждый контроллер домена содержит Центр распространения ключей Kerberos (Kerberos Distribution Center, KDC) для установления подлинности, который конфигурируется сетевым администратором. Протокол Kerberos служит третьим доверенным лицом, которое проверяет подлинность поддерживающей связь стороны. Безопасность IP в Windows Server 2003 использует Kerberos для идентификации компьютеров.

Рассмотрим пример, в котором пользователь Компьютера А (Пользователь 1) посылает данные пользователю Компьютера В (Пользователю 2). Безопасность IP установлена на обоих компьютерах.



Рис. 22.5. Пример реализации безопасности IP

На уровне пользователя процесс доставки IP-пакетов прозрачен. Пользователь 1 просто запускает приложение, которое использует протокол стека TCP/IP, например FTP, и посылает данные Пользователю 2. Политики безопасности, назначенные Компьютеру А и Компьютеру В администратором, определяют уровень безопасности взаимодействия. Они выбираются агентом политики и передаются службе ISAKMP/Oakley и драйверу IPSec. Служба ISAKMP/Oakley на каждом компьютере использует политику переговоров, связанную с назначенной политикой безопасности, чтобы установить ключ и общий метод переговоров (ассоциация безопасности). Результаты переговоров о политике ISAKMP между двумя компьютерами передаются драйверу IPSec, который использует ключ для шифрования данных. В заключение драйвер IPSec посылает шифрованные данные на Компьютер В. Драйвер IPSec на Компьютере В дешифрует данные и передает их приложению-получателю (см. описание процесса на рис. 22.5).

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

Архитектура EFS

EFS содержит следующие компоненты операционной системы (рис. 22.7).

 Драйвер EFS. Драйвер EFS является надстройкой над файловой системой NTFS. Он обменивается данными со службой EFS — запрашивает ключи шифрования, наборы DDF (Data Decryption Field) и DRF (Data Recovery Field), — а также с другими службами управления ключами. Полученную информацию драйвер EFS передает Библиотеке реального времени файловой системы EFS (File System Run-Time Library, FSRTL), которая прозрачно для операционной системы выполняет различные операции, характерные для файловой системы (чтение, запись, открытие файла, присоединение информации).

 Библиотека реального времени файловой системы EFS. FSRTL — это модуль, находящийся внутри драйвера EFS, реализующий вызовы NTFS, выполняющие такие операции, как чтение, запись и открытие зашифрованных файлов и каталогов, а также операции, связанные с шифрованием, дешифрованием и восстановлением файлов при их чтении или записи на диск. Хотя драйверы EFS и FSRTL реализованы в виде одного компонента, они никогда не обмениваются данными напрямую. Для передачи сообщений друг другу они используют механизм вызовов (callouts) NTFS, предназначенный для управления файлами. Это гарантирует, что вся работа с файлами происходит при непосредственном участии NTFS. С помощью механизма управления файлами операции записи значений атрибутов EFS (DDF и DRF) реализованы как обычная модификация атрибутов файла. Кроме того, передача ключа шифрования файла РЕК (см. ниже), полученного службой EFS, в FSRTL выполняется так, чтобы он мог быть установлен в контексте открытого файла. Затем контекст файла используется для автоматического выполнения операций шифрования и дешифрования при записи и чтении информации файла.

Рис. 22.7. Архитектура EFS

 Служба EFS. Служба EFS (EFS Service) является частью системы безопасности операционной системы. Для обмена данными с драйвером EFS она использует порт связи LPC, существующий между Локальным администратором безопасности (Local Security Authority, LSA) и монитором безопасности, работающим в привилегированном режиме. В режиме пользователя для создания ключей шифрования файлов и генерирования данных для DDF и DRF служба EFS использует CryptoAPI. Она также поддерживает набор API для Win32.

 Набор API для Win32. Этот набор интерфейсов прикладного программирования позволяет выполнять шифрование файлов, дешифрование и восстановление зашифрованных файлов, а также их импорт и экспорт (без предварительного дешифрования). Эти API поддерживаются стандартным системным модулем DLL — advapi32.dll.

Архивация зашифрованных файлов

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

Специализированная операция архивации не требует для ее выполнения доступа к открытым ключам пользователя — только к архивируемой информации. Поэтому для обеспечения безопасности конфиденциальных данных при создании резервных копий рекомендуется применять специальные утилиты архивации. Для этих целей предназначена стандартная утилита архивации данных Backup.

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

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

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

Сертификаты служат для обеспечения аутентификации в следующих случаях:

 аутентификация пользователя для защищенного веб-узла посредством протоколов Transport Layer Security (TLS) или Secure Sockets Layer (SSL);

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

Аутентификация Kerberos в доменах Active Directory

По мере роста и усложнения компьютерных сетей предприятия, построенных на основе систем Windows, становится необходимым применение протокола, обеспечивающего более совершенную и надежную аутентификацию пользователей при доступе к распределенным ресурсам. В операционных системах Windows 2000 для этих целей начат применяться протокол аутентификации Kerberos версии 5, входящий в систему безопасности доменов Windows 2000, тесно интегрированную с Active Directory. Реализация протокола Kerberos версии 5 в Windows 2000 основана на RFC 1510. Этот документ широко обсуждался и корректировался многими организациями, работающими в области создания и применения защищенных средств передачи информации по компьютерным сетям. Аутентификация Kerberos полностью отвечает требованиям к протоколам подобного назначения и позволяет создать высокопроизводительную и защищенную сеть предприятия. Программное обеспечение Kerberos, созданное Microsoft, поддерживает всех клиентов, удовлетворяющих RFC 1510. Однако полную поддержку сетей Windows 2000 осуществляет только клиент Kerberos, разработанный Microsoft, поскольку версия Kerberos Microsoft обладает рядом расширений.

Системы Windows Server 2003 в полной мере используют все средства распределенной безопасности, внедренные в Windows 2000. Протокол Kerberos интегрирован в существующую модель распределенной безопасности Windows 2000/Server 2003. В этих системах используются расширения протокола Kerberos — так же, как и другие архитектуры безопасности, например ОСЕ и SESAME. Протокол Kerberos — один из протоколов безопасности, поддерживаемых Windows 2000/Server 2003. Кроме него, поддерживаются протоколы NTLM для совместимости с предыдущими версиями, SSL и стандарт IETF безопасности транспортного уровня. В качестве механизма безопасности применяется протокол защищенных переговоров (Simple Protected Negotiation, SPNEGO). Для обеспечения безопасности передачи данных на сетевом уровне применяется технология IP Security (IPSec).

Безопасность IP (IPSec)

Средства безопасности протокола IP позволяют управлять защитой всего IP-трафика от источника информации до ее получателя. Возможности технологии IP Security Management (Управление безопасностью IP) в Windows Server 2003 позволяют назначать и применять политику безопасности IP, которая гарантирует защищенный обмен информацией для всей сети. Механизм безопасности IP представляет собой прозрачную для пользователя реализацию протокола безопасности IP (IP Security, IPSec), причем администрирование безопасности централизовано и совмещает гарантии безопасного обмена информацией с легкостью применения.

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

 доступа субъектов, не имеющих на это прав;

 перехвата, просмотра или копирования;

 модификации данных во время пути по сети.

Эти проблемы характеризуются такими показателями, как целостность данных, конфиденциальность и подлинность. Кроме того, защита от повторного использования (replay protection) предотвращает принятие повторно посланного пакета.

Реализация безопасности IP в Windows Server 2003 основана на стандартах RFC, разработанных консорциумом Internet Engineering Task Force (IETF), рабочей группой IP Security (IPSEC).

Центр сертификации

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

Центры сертификации

Центр сертификации (также встречается термин поставщик сертификатов) (Certification Authority, CA) представляет собой службу, которой доверен выпуск сертификатов, если индивидуальный пользователь или организация, которые запрашивают сертификат, удовлетворяют условиям установленной политики. Это осуществляется путем принятия запроса на получение сертификата, проверки и регистрации имени запрашивающего сертификат пользователя и открытого ключа в соответствии с политикой. Каждый ЦС должен получить от запрашивающей сертификат стороны подтверждение ее идентичности, такое как удостоверение личности или физический адрес. Затем производится подписание и назначение сертификата, подтверждающего выполнение пользователем критериев политики, которые были установлены для авторизации. Большинство используемых на .сегодня сертификатов основаны на стандарте Х.509, эта фундаментальная технология применяется в инфраструктуре открытых ключей Windows 2000 и Windows Server 2003.

Центром сертификации может быть удаленная организация, такая как VeriSign, или локальная служба, созданная в вашей организации путем инсталляции служб Certificate Services (Служб сертификации). Выбор ЦС основывается на доверительном отношении (trust). Вы доверяете, что ЦС использует правильную политику при рассмотрении запросов на подписание сертификатов. Кроме того, вы доверяете, что ЦС отзывает сертификаты с истекшим сроком действия путем публикации списка отозванных сертификатов (certificate revocation list).

Центры сертификации также имеют собственные сертификаты. Причем вышестоящий центр подписывает сертификаты для нижестоящих центров. Таким образом, формируется иерархия сертификатов (certificate hierarchy).

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

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

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

 открытый ключ (public key) владельца сертификата;

 идентификационную информацию владельца сертификата;

 период действия сертификата;

 информацию о центре сертификации;

 цифровую подпись (digital signature).

Все сертификаты имеют ограниченный срок действия. Даты начала и окончания срока действия сертификата указываются в сертификате. Для каждого ЦС устанавливается политика обновления сертификатов с истекшим сроком действия.

Если в компании для организации центра сертификации установлены службы сертификации на Windows 2000 Server или Windows Server 2003, то используется один из двух типов ЦС:

 центр сертификации предприятия (enterprise certification authority). Требует наличия Active Directory. Использует информацию, доступную в Active Directory, для проверки идентификационной информации запрашивающего сертификат. Публикует списки отозванных сертификатов в Active Directory, а также в общей папке;

 изолированный (автономный) центр сертификации (stand-alone certification authority). He зависит от Active Directory. По умолчанию пользователи могут запрашивать сертификаты у данного центра только с веб-страниц. Изолированный центр сертификации публикует списки отозванных сертификатов в общей папке или в Active Directory (если служба каталогов доступна).

Что такое сертификат

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

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

Наиболее распространенным на данный момент стандартом сертификатов является ITU-T X.509. Эта фундаментальная технология применяется в Windows 2000 и Windows Server 2003. Однако это не единственная форма сертификатов.

Цифровые (электронные) подписи

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

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

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

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

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

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

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

Дешифрование файлов и каталогов

Чтобы дешифровать файл или каталог:

1. На вкладке Sharing окна свойств соответствующего объекта нажмите кнопку Advanced.

2. В открывшемся диалоговом окне в группе Compress or Encrypt attributes сбросьте флажок Encrypt contents to secure data.

Достоинства IP Security

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

IP Security в системах Windows 2000 и Windows Server 2003 обеспечивает следующие преимущества, которые помогают достичь высокого уровня безопасности взаимодействия при низких затратах.

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

 Прозрачность безопасности IP для пользователей и прикладных программ. Не нужно иметь отдельные программные средства безопасности для каждого протокола в стеке TCP/IP, поскольку приложения, использующие TCP/IP, передают данные уровню протокола IP, где они шифруются. Установленная и настроенная служба IPSec прозрачна для пользователя и не требует обучения.

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

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

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

  Усиленная служба аутентификации, которая предотвращает перехват данных путем подмены идентификаторов.

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

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

 Безопасная связь между пользователями в любом домене корпоративной сети, основанной на протоколе IP.

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

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

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

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

Возможности стандарта IPSec и подробности реализации очень сложны и описаны подробно в ряде RFC и проектов IETF, а также в документах Microsoft. IPSec использует криптографическую защиту для обеспечения управления доступом, целостности без установления логического соединения, удостоверения подлинности данных, защиты от повторного использования, полной и ограниченной конфиденциальности потока данных. Поскольку протокол IPSec работает на уровне IP, его услуги доступны протоколам верхнего уровня в стеке и, очевидно, существующим приложениям.

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



IPSec может защищать пути между компьютерами, между шлюзами защиты или между шлюзами защиты и компьютерами. Услуги, доступные и требуемые для трафика, настраиваются с использованием политики IPSec. Политика IPSec может быть настроена локально на отдельном компьютере или может быть назначена через механизм групповых политик в Active Directory. Политика IPSec определяет, как компьютеры доверяют друг другу. Самое простое — полагаться на применение доменов доверия Active Directory, основанных на протоколе Kerberos. Для того чтобы доверять компьютерам в том же самом или в другом доверенном домене, задается предопределенная политика IPSec.

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

 передать на обработку службам IPSec;

 передать ее без изменений;

 игнорировать ее.

Установка IPSec включает описание характеристик трафика для фильтрации (IP-адрес источника/адресата, протокол, порт и т. д.) и определение того, какие механизмы требуется применить для трафика, соответствующего фильтру (фильтрам). Например, в очень простом случае два автономных компьютера могут быть сконфигурированы для использования IPSec между ними в одном и том же домене Active Directory и активизации политики блокировки (lockdown). Если два компьютера — не элементы одного и того же или доверенного домена, то доверие должно быть сконфигурировано с использованием пароля или ключа pre-shared в режиме "закрытый". Для этого выполняются операции:

 установка фильтра, который определяет весь трафик между двумя компьютерами;

 выбор метода опознавания (выбор ключа pre-shared или ввод пароля);

 выбор политики переговоров (в режиме "закрытый", при этом весь трафик, соответствующий фильтру (фильтрам), должен использовать IPSec);



 определение типа подключения (ЛВС, коммутируемое соединение или оба типа подключения).

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

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

Базовые механизмы

Базовые механизмы и концепции

Хранилища сертификатов

Операционная система сохраняет сертификаты локально на том компьютере, с которого запрашивался сертификат для данного компьютера или для пользователя, работающего за данным компьютером. Место хранения сертификатов называется хранилищем сертификатов (certificate store).

С помощью оснастки Certificates (Сертификаты) (рис. 22.10) можно просматривать хранилища сертификатов для пользователя, компьютера или сервиса (службы), в которых сертификаты можно сортировать. Режим сортировки определяется переключателями в окне View Options (Параметры просмотра), которое вызывается с помощью команды View | Options (Вид Параметры). Переключатель Certificate purpose определяет режим просмотра сертификатов по назначению, а переключатель Logical certificate stores — по логическим хранилищам. В табл. 22.1 перечислены некоторые основные папки, которые отображаются в окне оснастки Certificates в разных режимах просмотра.

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

Рис. 22.10. Окно оснастки Certificates

Таблица 22.1. Список папок хранилища сертификатов с кратким описанием

Сортировка по		Папка		Содержит
Логическим хранилищам		Personal (Личные)		Сертификаты, связанные с закрытыми ключами пользователя. Сертификаты, которые были выданы компьютеру или службе, для которых выполняется управление сертификатами
Trusted Root Certification Authorities (Доверенные корневые центры сертификации)		Полностью доверяемые центры сертификации
Enterprise Trust (Доверительные отношения в предприятии)		Списки доверяемых отношений сертификатов (certificate trust list). Обеспечивает механизм доверия к корневым сертификатам со стороны других организаций
Intermediate Certification Authorities (Промежуточные центры сертификации)		Сертификаты, выпущенные для других пользователей и центров сертификации
Active Directory User Object (Объект пользователя Active Directory)		Сертификаты, связанные с вашим пользовательским объектом и опубликованные в Active Directory
Trusted Publishers (Доверенные издатели)		Сертификаты, выпущенные центрами сертификации, которые соответствуют политикам Software Restriction
Untrusted Certificates (Сертификаты, к которым нет доверия)		Сертификаты, для которых явно установлено отсутствие доверительных отношений
Third-Party Root Certification Authorities (Сторонние корневые центры сертификации)		Доверяемые корневые сертификаты от центров сертификации, отличных от Microsoft и вашей собственной организации
Trusted People (Доверенные лица)		Сертификаты, выпущенные для других пользователей или конечных устройств, с которыми налажены доверительные отношения
По назначению		Server Authentication (Проверка подлинности сервера)		Сертификаты, которые используются серверными программами для аутентификации при обращении к клиентам
Client Authentication (Проверка подлинности клиента)		Сертификаты, которые используются клиентскими программами для аутентификации при обращении к серверам
Code Signing (Подписывание кода)		Сертификаты, связанные с парами ключей, используемых для подписи активного содержания
Secure Email (Защищенная электронная почта)		Сертификаты, связанные с парами ключей, используемых для подписи электронных сообщений
Encrypting File System (Шифрующая файловая система)		Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для шифрования и расшифровки данных
File Recovery (Восстановление файлов)		Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для восстановления зашифрованных данных

<
/p> При наличии соответствующих прав вы можете импортировать или экспортировать сертификаты из любой папки в хранилище сертификатов. Если личный ключ, связанный с сертификатом, доступен для экспорта, то вы можете экспортировать сертификат и личный ключ в файл, соответствующий стандарту PKCS #12.

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

Команда Find Certificates (Поиск сертификатов) (контекстного меню или меню Action (Действие)) помогает отыскать выпущенные сертификаты в хранилищах сертификатов. Вы можете провести поиск в определенном хранилище или во всех хранилищах и ограничить поиск на основании определенной информации сертификатов, например, искать сертификаты, выпущенные определенным центром сертификации.

Импорт и экспорт сертификатов

При импорте или экспорте сертификат копируется в хранилище или из хранилища. Импорт или экспорт сертификата проводится при выполнении следующих задач:

 инсталляция сертификата, полученного вами от другого пользователя (импорт);

 восстановление сертификата, который хранился в виде резервной копии (импорт);

 создание резервной копии сертификата (экспорт);

 копирование сертификата или ключа для использования на другом компьютере (экспорт).

Передавать сертификаты можно в следующих форматах.

 Personal Information Exchange (Обмен персональной информацией) (PKCS #12)

Данный формат (Personal Information Exchange, PFX) позволяет приложениям передавать сертификаты и соответствующие личные ключи с одного компьютера на другой, на съемный накопитель или смарт-карту.

PKCS #12 является стандартным в отрасли форматом, применяемым для передачи или резервного копирования и восстановления сертификатов и их ключей. Сертификаты в этом формате могут передаваться между продуктами одного или различных производителей, например, Microsoft и IBM. Для использования формата PKCS #12 поставщик услуг шифрования (CSP) должен считать сертификаты и ключи доступными для экспорта.

Экспорт личного ключа — рискованная операция, поскольку ключом могут завладеть посторонние лица. Поэтому PKCS #12 является единственным форматом, который Microsoft поддерживает для экспорта сертификатов и связанных с ними личных ключей.

 Cryptographic Message Syntax Standard (Криптографический стандарт на синтаксис сообщений) (PKCS #7)

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

PKCS #7 позволяет передавать сертификат и все сертификаты в пути сертификата с одного компьютера на другой или с компьютера на съемный диск. Имена файлов сертификатов имеют расширение р7Ь.

 DER Encoded Binary X.509

Формат могут использовать центры сертификации, находящиеся не на серверах Windows. Имена файлов сертификатов имеют расширение сеr.

 Base64 Encoded X. 509

Данный формат могут применять ЦС, находящиеся не на серверах Windows, — например, ЦС, использующие программное обеспечение Netscape. Имена файлов сертификатов имеют расширение сеr.

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

Интегрированная аутентификация Kerberos

В Windows Server 2003 аутентификация Kerberos реализована на уровне доменов, что позволяет выполнять одну регистрацию в системе при доступе ко всем ресурсам сети и поддерживать модель распределенной безопасности Windows Server 2003. На любом участке дерева доменов Active Directory протокол Kerberos обеспечивает взаимную аутентификацию, ускоренную аутентификацию и транзитное доверие на аутентификацию. Аутентификация Kerberos в Windows Server 2003 используется для выполнения интерактивной регистрации пользователя в домене. Расширение стандартной аутентификации Kerberos для применения открытого ключа позволяет применять регистрацию в Windows Server 2003 с помощью смарт-карты. Протокол Kerberos реачизован в виде поставщика безопасности, доступ к которому осуществляется с применением интерфейса поддержки поставщика безопасности (Security Support Provider Interface, SSPI).

Поставщик безопасности Kerberos используется клиентом и сервером SMB (Server Message Block). Он также доступен для DCOM, авторизованного RPC и любого протокола, использующего SSPI для обеспечения безопасности информации, передаваемой по сети. SSPI — это интерфейс безопасности Win32, который существует в составе Windows NT, начиная с версии 3.5. Он также поддерживается в Windows 95/98. В SSPI применяются те же архитектурные концепции, что и в наборе программных вызовов общих служб безопасности (Generic Security Services API, GSS-API), соответствующих RFC 1964. SSPI позволяет освободить приложения от непосредственного взаимодействия с протоколами сетевой безопасности.

В системах Windows 2000 и Windows Server 2003 реализован Центр распространения ключей Kerberos (Kerberos Key Distribution Center, KDC). На каждом контроллере домена помимо службы Active Directory имеется служба KDC, выполняющаяся вместе с Active Directory как процесс в привилегированном режиме. Оба процесса осуществляют управление жизненно важной информацией, включая пароли учетных записей пользователей. Active Directory выполняет автоматическую репликацию служебной информации на всех контроллерах домена. Поэтому создавать новые учетные записи пользователей, настраивать членство пользователей в группах или переустанавливать пароли можно на любом контроллере домена. Это означает, что в отличие от Windows NT 4,0, где изменить административную информацию можно было только на главном контроллере домена (Primary Domain Controller, PDC) с последующим обновлением доступных только для чтения реплик на резервных контроллерах домена (Backup Domain Controller, BDC), в доменах Active Directory можно изменять любую реплику каталога, хранящуюся на некотором контроллере домена.

Клиенты и серверы используют протокол Kerberos для взаимной аутентификации. Запрос Kerberos содержит билет сеанса и аутентификатор, получаемый в КDС и позволяющий исключить возможность подмены билета сеанса. Поставщик безопасности Kerberos на стороне клиента интегрируется с локальным администратором безопасности, поддерживающим локальный кэш билетов. При инициализации клиентом контекста безопасности поставщик безопасности Kerberos считывает билет сеанса, соответствующий целевой службе, или запрашивает новый билет сеанса в КОС. Сообщение запроса Kerberos, созданного поставщиком безопасности Kerberos, соответствует форматам маркера механизма GSS KerbS, описанным в RFC 1964. Клиенты могут аутентифицироваться для любой службы домена или доверенного владения, поддерживающего механизм GSS. Поставщик безопасности Kerberos может воспринять запрос Kerberos, который сгенерирован любым клиентом, поддерживающим форматы маркера в стандарте GSS, RFC 1964.

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

Использование сертификатов для обеспечения безопасности

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

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

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

 Шифрование (encryption). Обеспечивает доступ к информации только для того пользователя, которому она предназначена.

 Цифровые подписи (digital signatures). Обеспечение целостности и подлинности данных.

Использование сертификатов в Интернете

При работе в Интернете браузер Internet Explorer использует два типа сертификатов: персональный сертификат (personal certificate) и сертификат веб-узла (Web site certificate). Персональный сертификат удостоверяет личность пользователя. Информация сертификата используется при передаче личной информации через Интернет на веб-узел, который требует проверки пользователя посредством сертификата. Сертификат веб-узла подтверждает, что данный узел является безопасным и подлинным. При этом гарантируется, что никакой другой веб-узел не является идентичным оригинальному веб-узлу. Internet Explorer при подключении к веб-узлу проверяет, что интернет-адрес в сертификате совпадает с действительным адресом и срок действия сертификата еще не истек.

Ключи

Для обеспечения безопасности данных в криптографии совместно с алгоритмами используются ключи. Ключ — это некоторое значение, применяемое для шифрования или дешифрования информации. Для шифрования в системах безопасности могут использоваться как закрытые, так и открытые ключи. Даже если алгоритм известен, без ключа данные нельзя просмотреть или изменить. Безопасность IP в Windows Server 2003 использует ключи большой длины, чтобы обеспечить повышенную безопасность. Если длину ключа увеличить на один бит, число возможных комбинаций удваивается. Безопасность IP в Windows Server 2003 также применяет динамическое обновление ключей; это означает, что после определенного интервала для продолжения обмена данными генерируется новый ключ. Такое решение позволяет защититься от злоумышленника, который получил доступ к части информации во время ее передачи.

Компоненты Windows Server 2003, обеспечивающие шифрование

На рис. 22.1 схематично показана логическая взаимосвязь средств Windows 2000, позволяющих применять шифрование с открытым ключом.

Изображенные на рис. 22.1 средства необязательно должны размещаться на отдельных компьютерах. Несколько служб могут эффективно работать на одном компьютере. Ключевое звено схемы — службы сертификатов Microsoft (Microsoft Certificate Services). Они позволяют создать один или несколько ЦС предприятия, поддерживающих создание и отзыв сертификатов. Они интегрированы в Active Directory, где хранится информация о политике ЦС и их местоположении. Кроме того, с помощью Active Directory выполняется публикация информации о сертификатах и их отзыве. Средства работы с открытым ключом не заменяют существующих механизмов доверительных отношений между доменами и аутентификации, реализованных с помощью контроллеров доменов и центров распространения ключей Kerberos (Key Distribution Center, KDC). Напротив, данные средства взаимодействуют с этими службами, что позволяет приложениям безопасно передавать конфиденциальную информацию через Интернет и корпоративным глобальным каналам.

Рис. 22.1. Взаимосвязь средств Windows 2000 и Windows Server 2003, предназначенных для работы с открытым ключом

Поддержка прикладных средств шифрования информации с открытым ключом включена в состав программного обеспечения всех операционных систем Windows.

Основой архитектуры поддержки прикладных программ шифрования информации с открытым ключом является библиотека CryptoAPI. Она позволяет работать со всеми устанавливаемыми поставщиками услуг шифрования (Cryptographic Service Providers, CSP) через стандартный интерфейс. CSP могут быть реализованы на программном уровне или с помощью специального оборудования. Они поддерживают различные длины ключей и алгоритмы шифрования. Один из CSP поддерживает смарт-карты. Услугами служб шифрования пользуются службы управления сертификатами. Они соответствуют стандарту Х.509 v3 и позволяют организовывать принудительное хранение, службы подсчета и дешифрования. Кроме того, эти службы предназначены для работы с различными отраслевыми стандартами сообщений. В основном они поддерживают стандарты PKCS и разработанный в IETF (Internet Engineering Task Force) набор предварительных стандартов PKIX (Public Key Infrastructure, X.509).

Остальные службы используют CryptoAPI для придания дополнительной функциональности прикладным программам. Защищенный канал (Secure Channel) поддерживает сетевую аутентификацию и шифрование в соответствии со стандартными протоколами TLS и SSL, обращение к которым может быть выполнено с помощью интерфейсов Microsoft Winlnet и SSPI. Служба Authenticode предназначена для проверки и подписи объектов и в основном используется при получении информации через Интернет.

Конфиденциальность

Для обеспечения конфиденциальности при передаче данных в незащищенных сетях или по частным локальным сетям применяется шифрование с секретным, или закрытым, ключом (secret key encryption).

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

 Secure Multipurpose Internet Mail Extensions (S/MIME);

 Transport Layer Security (TLS);

 IP Security (IPSec).

Копирование, перемещение, переименование и уничтожение зашифрованных файлов и папок

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

Модель распределенной безопасности Windows Server

Модель распределенной безопасности Windows Server 2003 основана на трех основных концепциях.

 Каждая рабочая станция и сервер имеют прямой доверенный путь (trust path) к контроллеру домена, членом которого является данная машина. Доверенный путь устанавливается службой NetLogon с помощью аутентифицированного соединения RPC с контроллером домена. Защищенный канал устанавливается и с другими доменами с помощью междоменных доверительных отношений. Этот канал используется для проверки информации безопасности, включая идентификаторы безопасности (Security Identifiers, SID) пользователей и групп.

 Перед выполнением запрошенных клиентом операций сетевые службы имперсонализируют контекст безопасности этого клиента. Имперсонализация основана на маркере адреса безопасности, созданном локальным администратором безопасности (Local Security Authority, LSA). Он представляет собой авторизацию клиента на сервере. Поток, находящийся на сервере и соответствующий данному клиенту, имперсонализирует контекст безопасности клиента и выполняет операции в соответствии с авторизацией данного клиента, а не в соответствии с идентификатором безопасности сервера. Имперсонализация поддерживается всеми службами Windows Server 2003, включая, например, службу удаленного файлового сервера CIFS/SNB. Аутентифицированный RPC и DCOM поддерживают имперсонализацию для распределенных приложений. Серверы семейства BackOffice: Exchange Server, SNA Server и Internet Information Server также поддерживают имперсонализацию.

 Ядро Windows Server 2003 поддерживает объектно-ориентированное управление доступом, сравнивая SID в маркере доступа с правами доступа, определенными в списке управления доступом данного объекта. Каждый объект Windows Sewer 2003 (ключи реестра, файлы и каталоги NTFS, общие ресурсы, объекты ядра, очереди печати и т. д.) имеют собственные списки управления доступом. Ядро Windows Server 2003 проверяет разрешения при каждой попытке доступа к данному объекту. Управление доступом и аудит осуществляются с помощью настройки свойств безопасности объекта, позволяющих предоставить пользователю или группе доступ к объекту. Управление авторизацией выполняется централизованно посредством включения пользователей в локальные группы системы, которым предоставлены необходимые права доступа.

В операционной системе Windows Server 2003 существуют дополнительные средства обеспечения безопасности — аутентификация клиента с помощью открытого ключа посредством SSL/TLS и протокола Kerberos версии 5, которые интегрированы в систему безопасности.

Обеспечение истинности открытых ключей

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

Общие понятия безопасности

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

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

 Конфиденциальность (privacy). Гарантия того, что данные будут раскрыты только тем получателем, которому они были предназначены. Это свойство не является обязательным.

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

Основные понятия

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

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

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

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

 каким образом клиент будет получать информацию о секрете?

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

 каким образом клиент будет проверять полномочия сервера?

 каким образом сервер сможет убедиться в том, что полномочия, предоставленные клиентом, подлинные?

 каким образом будет обеспечиваться безопасность взаимодействия сервера и клиента в ходе проверки полномочий?

 каким образом будет исключаться возможность использования перехваченных пакетов?

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

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

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

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

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

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

Аутентификация выполняется следующим образом:

1. Клиент посылает запрос серверу аутентификации (Authentication Server, AS) на информацию, однозначно идентифицирующую некоторый нужный клиенту сервер.



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

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

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

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

Протокол Kerberos состоит из нескольких субпротоколов (или протоколов обмена сообщениями). Существует два метода, которыми клиент может запросить у сервера Kerberos информацию, идентифицирующую определенный сервер. Первый способ предполагает, что клиент посылает AS простой текстовый запрос билета для конкретного сервера, а в ответ получает данные, зашифрованные с помощью своего секретного ключа. Как правило, в данном случае клиент посылает запрос на билет, позволяющий получить билет (Ticket Granting Ticket, TGT), который в дальнейшем используется для работы с выдающим билеты сервером (Ticket Granting Server, TGS). Второй способ предполагает, что клиент посылает TGT-билеты на TGS-сервер так же, как будто он обменивается информацией с другим сервером приложений, требующим аутентификации Kerberos.



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

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

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

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

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

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

Политики безопасности действуют в рамках сайта, домена или контейнера (подразделения, или организационной единицы, OU) и распространяются на группы, компьютеры и пользователей — т. е. на все объекты администрирования. Безопасность шифрования с открытым ключом является одним из аспектов общей политики безопасности Windows 2000/Server 2003 и интегрирована в ее структуру. Это механизм, с помощью которого можно посредством объектов политики безопасности централизованно осуществлять настройку и управление глобальной политикой работы с открытым ключом.

С помощью политики открытого ключа можно определять следующие аспекты безопасности Windows 2000/Server 2003:

 доверенные корни ЦС;

 процесс регистрации и обновления сертификатов;

 регистрация в системе с помощью смарт-карты.

и Windows Server 2003 обладают

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

Аутентификация Kerberos используется многими службами

Аутентификация Kerberos используется многими службами домена Active Directory. Интерфейс SSPI применяется для аутентификации в большинстве системных служб, поэтому их перевод с аутентификации NTLM на Kerberos требует минимальных усилий. Более сложные изменения необходимы на сервере SMB, который не использовал SSPI до версии Windows 2000. Многие новые распределенные службы Windows 2000 используют аутентификацию Kerberos. Примеры областей применения аутентификации Kerberos в Windows 2000/Server 2003:

 аутентификация в Active Directory с применением LDAP для запросов или управления каталогом;

 протокол удаленного доступа к файлам CIFS/SMB;

 управление распределенной файловой системой DFS;

 защищенное обновление адресов DNS;

 службы печати;

 необязательная взаимная аутентификация IPSec-хостов при работе протоколов ISAKMP/Oakley;

 запросы резервирования для службы качества обслуживания (Quality of Service);

 аутентификация интрасети в службах Internet Information Services;

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

 удаленное управление сервером или рабочей станцией с помощью аутентифицированного RPC и DCOM.

Это первый шаг к основной цели, поставленной в Windows 2000, — полному исключению аутентификации NTLM в компьютерных сетях, основанных на этой операционной системе.

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

Протокол аутентификации Kerberos является основным механизмом аутентификации, используемым в среде Windows 2000/Server 2003. Этот протокол был разработан в Массачусетском технологическом институте (Massachusetts Institute of Technology, MIT) в начале 1980-х гг. Существует несколько версий протокола Kerberos. В среде Windows 2000/Server 2003 применяется пятая версия протокола Kerberos, спецификация которого определена в стандарте RFC 1510.

Имперсонализация Windows Server 2003 требует,

Имперсонализация Windows Server 2003 требует, чтобы локальный администратор безопасности (LSA) сервера мог безопасно получать SID пользователя и список идентификаторов безопасности членов групп. Идентификаторы безопасности генерируются системой безопасности домена и используются в LSA при создании маркеров доступа для имперсонализации. После создания соединения связанный с ним поток имперсонализирует зарегистрировавшегося пользователя, после чего операционная система сравнивает маркер доступа клиента с ACL объекта, к которому пользователь пытается получить доступ. При аутентификации NTLM идентификаторы безопасности пользователя и группы передаются с помощью защищенного канала Net Logon прямо с контроллера домена или любого доверенного домена. При использовании протокола Kerberos идентификаторы безопасности пользователей и групп передаются в составе данных авторизации билета сеанса Kerberos.

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

Протокол Kerberos позволяет обращаться к данным авторизации билета Kerberos, которые определяются приложением. Они полностью соответствуют RFC 1510. Кроме того, их структура преобразована для уменьшения проблем, возникающих при совместной работе с другими операционными системами.

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

По мере развития ОС Windows Server 2003 формат данных авторизации может изменяться. Но в любом случае эти данные будут содержать список идентификаторов безопасности, предназначенных для поддержки аутентификации Kerberos в много платформенных системах, а также подпись, обеспечивающую целостность данных и устанавливаемую КОС.

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

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

 Протокол ассоциаций безопасности и управления ключами Интернет (ISAKMP, Internet Security Association and Key Management Protocol) Прежде чем IP-пакеты будут переданы от одного компьютера другому, должна быть установлена ассоциация, или сопоставление, безопасности (Security Association, SA). SA — набор параметров, который определяет необходимые для защищенной связи услуги и механизмы, типы ключей для безопасных протоколов. SA должна существовать между двумя поддерживающими связь сторонами, использующими безопасность IP. ISAKMP определяет основу для поддержки и установления ассоциаций безопасности. Протокол ISAKMP не связан ни с одним конкретным алгоритмом, методом порождения ключей или протоколом безопасности.

 Oakley. Протокол определения ключей, который использует алгоритм обмена ключами Diffie-Hellman (D-H). Oakley генерирует ключи, необходимые для безопасного обмена информацией.

 Заголовок аутентификации IP (АН, Authentication Header). АН обеспечивает целостность, установление подлинности и защиту от повторного использования. Также при помощи АН поддерживается конфиденциальность. АН основан на некотором алгоритме вычисления ключевого кэшированного значения сообщения (НМАС) для каждого IP-пакета.

 Протокол инкапсуляции безопасности (ESP, Encapsulating Security Protocol). В дополнение к услугам АН, описанным выше, ESP обеспечивает конфиденциальность, используя алгоритм DES-CBC.

Работа с EFS

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

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

Средства восстановления данных предназначены для применения в разнообразных конфигурациях вычислительных сред. Параметры процедуры восстановления зашифрованных данных в условиях утраты личного ключа задаются политикой восстановления. Она представляет собой одну из политик открытого ключа (public key policy). Политика восстановления определяется только в домене Windows Server 2003. Администратор домена одновременно является и агентом восстановления с соответствующими полномочиями. Могут быть добавлены и другие агенты. Это делается с помощью оснастки Group Policy Object Editor (Групповая политика), в окне которой нужно выбрать узел Security Settings | Public Key Policies | Encrypting File System. В контекстном меню этого узла имеются команды, позволяющие управлять агентами и политиками восстановления. Политика восстановления может быть задана и на одиночном компьютере.

Политики восстановления в Windows Server 2003 работают иначе, чем в Windows 2000. По умолчанию на компьютерах под управлением Windows Server 2003 агенты восстановления не создаются и политика восстановления не препятствует работе EFS. Это означает, что восстановить зашифрованную информацию могут только те пользователи, которые ее зашифровали.

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

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

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

Перед тем как реализовать безопасность IP в Windows 2000, полезно разработать и задокументировать план безопасности, охватывающий всю корпоративную сеть. Необходимо проанализировать следующие вопросы.

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

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

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

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

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

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

1. Создать политику безопасности с именем Legal и привязать ее к заданной по умолчанию политике домена (Default Domain Policy). Поскольку каждый компьютер входит в домен компании, агент политики компьютера выберет политику безопасности Legal в каталоге Active Directory. Политика безопасности Legal могла бы иметь описанные ниже политику переговоров и IP-фильтры, связанные с ней.

2. Создать две политики переговоров и связать их с политикой безопасности Legal:

  первую политику переговоров, Legal NP 1, настроенную на службы и обеспечивающую конфиденциальность для взаимодействия пользователей юридического отдела с пользователями других отделов ("передаваемые данные будут конфиденциальны, подлинны и не модифицированы" — парадигма протокола безопасности ESP);

 вторую политику переговоров, Legal NP 2, настроенную на службы и обеспечивающую только установление подлинности и защиту от изменений, когда пользователи юридического отдела общаются друг с другом ("передаваемые данные будут подлинны и не модифицированы" — парадигма протокола безопасности АН).

3. Создать два IP-фильтра и связать каждый с политикой переговоров. Пользователи в юридическом отделе находятся в сети 157.55.0.0 с маской подсети 255.255.0.0. Пользователи других отделов находятся в сети 147.20.0.0 с маской подсети 255.255.0.0.

Первый IP-фильтр, Legal IP Filter 1, предназначен для пользователей в юридическом отделе, которые связываются с пользователями других отделов. Он будет связан с политикой переговоров Legal NP 1. Администратор устанавливает свойства фильтра в соответствии со следующими значениями:

 заданный IP-адрес для источника — 157.55.0.0. Этот адрес будет соответствовать любому адресу IP в сети юридического отдела, т. к. он является IP-адресом подсети;

 заданный IP-адрес для получателя — 147.20.0.0;

 поскольку план безопасности компании обусловливает безопасность всех данных, посланных при помощи протокола IP, тип протокола — любой (Any).

Пользователи юридического отдела, поддерживающие связь с другими пользователями внутри отдела, используют второй IP-фильтр, Legal IP Filter 2. Он связан с политикой переговоров, Legal NP 2, а параметры фильтра установлены в соответствии со следующими значениями:

 заданный IP-адрес для источника — 157.55.0.0;

 заданный IP-адрес для получателя — 157.55.0.0;

 тип протокола — любой (Any).

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

Например, если пользователь в юридическом отделе с адресом IP 157.55.2.1 посылает данные пользователю с адресом 147.20.4.5, это соответствует Legal IP Filter 1. Это означает, что связь будет организована на уровне безопасности, определенном политикой переговоров Legal NP 1, которая обеспечивает установление подлинности, защиту от изменений и конфиденциальность связи.

Сертификаты

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

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

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

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

Шифрование файлов для совместного использования

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

После того как владелец-создатель зашифровал файл, он может снова открыть окно Advanced Attributes (Дополнительные атрибуты) и нажать кнопку Details (Подробно). Появится окно, аналогичное показанному на рис. 22.8 (для изолированного компьютера картина будет аналогичной). В приведенном примере видно, что к файлу помимо агента восстановления имеют доступ еще два пользователя.

Рис. 22.8. В этом окне перечислены все пользователи, имеющие доступ к зашифрованному файлу

Рис. 22.9. Данное окно позволяет выбрать пользователя и просмотреть его сертификат

Зашифровав файл или папку и открыв заново окно Encryption Details (Подробности шифрования), вы можете легко проверить, определен ли в вашей системе агент восстановления.

Теперь можно нажать кнопку Add (Добавить) и в окне Select User (Выбор пользователя) (рис. 22.9) указать, какие пользователи смогут также работать с зашифрованным файлом. Окно Select User позволяет просмотреть имеющиеся сертификаты пользователей и искать пользователей в каталоге Active Directory.

Шифрование файлов и каталогов

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

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

Для шифрования/дешифрования файлов и папок можно также использовать утилиту командной строки Cipher.exe.

Шифрование информации задается в окне свойств файла или папки:

1. Укажите файл или папку, которую требуется зашифровать, нажмите правую кнопку мыши и выберите в контекстном меню команду Properties (Свойства).

2. В появившемся окне свойств на вкладке General (Общие) нажмите кнопку Advanced (Другие). Появится диалоговое окно Advanced Attributes (Дополнительные атрибуты).

3. В группе Compress or Encrypt attributes (Атрибуты сжатия и шифрования) установите флажок Encrypt contents to secure data (Шифровать содержимое для защиты данных) и нажмите кнопку ОК.

4. Нажмите кнопку ОК в окне свойств зашифровываемого файла или папки. В появившемся диалоговом окне подтвердите режим шифрования.

При шифровании папки можно указать следующие режимы:

 Apply changes to this folder (Только к этой папке);

 Apply changes to this folder, subfolders and files (К этой папке и всем вложенным папкам и файлам).

Шифрование с открытым ключом

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

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

Фундаментальное отличие шифрования с открытым ключом (асимметричное шифрование) заключается в том, что зашифровывающий и расшифровывающий ключи не совпадают. Шифрование информации является односторонним процессом: открытые данные шифруются с помощью зашифровывающего ключа, однако с помощью того же ключа нельзя осуществить обратное преобразование и получить открытые данные. Для этого необходим расшифровывающий ключ, который связан с зашифровывающим ключом, но не совпадает с ним. Подобная технология шифрования предполагает, что каждый пользователь имеет в своем распоряжении пару ключей — открытый ключ (public key) и личный или закрытый ключ (private key). Свободно распространяя открытый ключ, вы даете возможность другим пользователям посылать вам зашифрованные данные, которые могут быть расшифрованы с помощью известного только вам личного ключа. Аналогично, с помощью личного ключа вы можете преобразовать данные так, чтобы другая сторона убедилась в том, что информация пришла именно от вас. Эта возможность применяется при работе с цифровыми или электронными подписями. Шифрование с открытым ключом имеет все возможности шифрования с закрытым ключом, но может проходить медленнее из-за необходимости генерировать два ключа. Однако этот метод безопаснее.

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

Существует несколько хорошо известных алгоритмов шифрования с открытым ключом. Некоторые из них, например RSA (Rivest-Shamir-Adelman) и шифрование с помощью эллиптической кривой (Elliptic Curve Criptography, ECC), являются алгоритмами общего употребления в том смысле, что они поддерживают все упомянутые выше операции. Другие алгоритмы поддерживают только некоторые операции. К ним относятся: алгоритм цифровой подписи (Digital Signature Algorithm, DSA), используемый только для работы с цифровыми подписями, и алгоритм Diffie-Hellman (D-H), применяемый только для соглашений о секретных ключах. Алгоритмы шифрования, используемые безопасностью IP (IP Security), подробнее описаны в данной главе в разд. "Безопасность IP".

Ниже кратко рассмотрены основные области применения шифрования с открытым ключом.

Шифрующая файловая система EFS

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

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

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

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

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

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

Все перечисленные выше проблемы позволяет решить шифрующая фашювая система (Encrypting File System, EFS), впервые реализованная в Windows 2000 и работающая только на NTFS 5.0. В следующих разделах подробно описаны технология шифрования, место шифрования в операционной системе, взаимодействие с пользователями и способ восстановления данных.

Временные файлы, создаваемые приложениями, наследуют

EPS тесно взаимодействует с NTFS 5.0. Временные файлы, создаваемые приложениями, наследуют атрибуты оригинальных файлов (если файлы находятся в разделе NTFS). Вместе с файлом шифруются также и его временные копии. EFS находится в ядре Windows Server 2003 и использует для хранения ключей специальный пул, не выгружаемый на жесткий диск. Поэтому ключи никогда не попадают в файл подкачки.

В Windows Server 2003 файловая система EFS имеет некоторые новые возможности:

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

 можно шифровать автономные папки и файлы (offline folders);

 агент восстановления (recovery agent) по умолчанию не используется;

 стандартный алгоритм шифрования — Advanced Encryption Standard, AES (Rijndael) (256 бит). Алгоритм DESX, используемый по умолчанию системой EFS в Windows 2000 и Windows XP Professional, не может применяться для шифрования файлов в Windows Server 2003;

 вместо AES может использоваться алгоритм шифрования 3DES (128 или 168 бит), для этого нужно изменить политику безопасности;

 зашифрованные файлы могут располагаться в веб-папках;

 сертификаты EFS могут автоматически доставляться пользователю службами сертификатов (Certificate Services) и механизмом автоподписи сертификатов;

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

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

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

Напомним, что каталоги и файлы можно шифровать только на томах NTFS.



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

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

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

Соглашение о секретном ключе, достигаемое с помощью открытого ключа

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

Совместная работа средств обеспечения безопасности сети

Домены Active Directory должны иметь возможность одновременно поддерживать клиентские компьютеры и серверы, на которых работает программное обеспечение Windows NT 3.x—4.0, Windows 9х/МЕ, а также Windows 2000/XP и Windows Server 2003. Для этого в Windows Server 2003 остается поддержка аутентификации NTLM, обеспечивающей совместимость с операционными системами более ранних версий. Обновленные версии клиента Active Directory обеспечивают расширенные возможности аутентификации по протоколу NTLM v.2; хотя протокол Kerberos не поддерживается.

Создание агента восстановления

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

Чтобы создать сертификат агента восстановления:

1. Войдите в систему как администратор.

2. В окне консоли введите команду cipher /R:имяФайла — без расширения.

3. Введите и подтвердите пароль, защищающий личный ключ.

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

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

1. Зарегистрируйтесь в системе как администратор.

2. Запустите оснастку Certificates, откройте узел Personal.

3. Импортируйте созданный РЕХ-файл.

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

1. Запустите оснастку Local Security Settings.

2. Выберите узел Public Key Policies | Encrypting File System (Политики открытого ключа | Файловая система EPS).

3. В контекстном меню выполните команду Add Data Recovery Agent (Добавить агента восстановления данных).

4. В окне мастера Add Recovery Agent Wizard (Мастер добавления агента восстановления) нажмите кнопку Browse Folders (Обзор папок) и выберите местоположение созданного ранее файла сертификата с расширением сеr. (Имя пользователя будет неизвестно, поскольку оно не хранится в файле — это нормальная ситуация.)

5. Нажмите кнопку Next (Далее) и на следующей странице мастера — Finish (Готово).

Сертификат будет импортирован и его владелец станет агентом восстановления на данном компьютере. Обратите внимание на то, что в столбце Intended Purposes (Назначение) импортированного сертификата указано File Recovery (Восстановление файлов).

Теперь можно использовать шифрование информации, не опасаясь потери "ключа" к ней.

В этой главе описываются базовые

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

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

Технологии шифрования EFS

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

EFS основана на шифровании с открытым ключом и использует все возможности архитектуры CryptoAPI. Каждый файл шифруется с помощью случайно сгенерированного ключа, зависящего от пары открытого (public) и личного, закрытого (private), ключей пользователя. Подобный подход в значительной степени затрудняет осуществление большого набора атак, основанных на криптоанализе. При криптозащите файлов может быть применен любой ачгоритм симметричного шифрования. EFS позволяет осуществлять шифрование и дешифрование файлов, находящихся на удаленных файловых серверах.

В данном случае EFS может работать только с файлами, находящимися на диске. Шифрующая файловая система не осуществляет криптозащиту данных, передаваемых по сети. Для шифрования передаваемой информации следует применять специальные сетевые протоколы, например SSL/PCT.

В EFS для шифрования и дешифрования информации используются открытые ключи. Данные зашифровываются с помощью симметричного алгоритма с применением Ключа шифрования фаша (File Encryption Key, FEK). FEK — это сгенерированный случайным образом ключ, имеющий определенную длину.

В свою очередь, FEK шифруется с помощью одного или нескольких открытых ключей, предназначенных для криптозашиты ключа. В этом случае создается список зашифрованных ключей FEK, что позволяет организовать доступ к файлу со стороны нескольких пользователей. Для шифрования набора FEK используется открытая часть пары ключей каждого пользователя. Список зашифрованных ключей FEK хранится вместе с зашифрованным файлом в специальном атрибуте EFS, называемом Полем дешифрования данных (Data Decryption Field, DDF). Информация, требуемая для дешифрования, привязывается к самому файлу. Секретная часть ключа пользователя используется при дешифровании FEK. Она хранится в безопасном месте, например на смарт-карте или другом устройстве, обладающем высокой степенью защищенности.

FEK применяется для создания ключей восстановления. Для этого FEK шифруется с помощью одного или нескольких открытых мючей восстановления. Список FEK, зашифрованных для целей восстановления, хранится вместе с зашифрованным файлом в специальном атрибуте EFS, называемом Полем восстановления данных (Data Recovery Field, DRF). Благодаря существованию набора зашифрованных ключей FEK агенты восстановления данных могут дешифровать файл. Для шифрования ключа FEK в поле DRF необходима только общая часть пары ключей восстановления, ее присутствие в системе необходимо в любой момент времени для нормального функционирования файловой системы. Сама процедура восстановления выполняется довольно редко, когда пользователь увольняется из организации или забывает секретную часть ключа. Поэтому агенты восстановления могут хранить секретную часть ключей восстановления в безопасном месте, например на смарт-картах или других хорошо защищенных устройствах.

Управление центром сертификации

После инсталляции центра сертификации можно запустить управляющую оснастку Certification Authority. Для этого в меню Administrative Tools выполните команду Certification Authority. В окне оснастки (рис. 22.11) можно просматривать списки сертификатов, а также работать с шаблонами сертификатов. В системах Windows Server 2003 шаблоны сертификатов можно создавать и модифицировать, для чего имеется специальная оснастка — Certificate Templates.

Рис. 22.11. Окно оснастки Certification Authority

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

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

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

Управление сертификатами, их импорт и экспорт осуществляются с помощью контекстных меню оснастки Certificates (см. также ниже разд. "Импорт к экспорт сертификатов"). Пользователи имеют возможность управлять только своими собственными сертификатами.

Установка центра сертификации

Центр сертификации (ЦС) — важный элемент в системе безопасности организации, поэтому в большинстве организаций имеется собственный ЦС. В Windows Server 2003 центры сертификации могут быть двух классов: ЦС предприятия (Enterprise СА) и изолированный ЦС (Stand-alone CA). Внутри каждого класса могут быть два типа ЦС: корневой (root) и подчиненный (subordinate).

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

Для развертывания собственного ЦС:

1. Выберите на панели управления значок Add or Remove Programs (Установка и удаление программ).

2. В открывшемся окне нажмите кнопку Add/Remove Windows Components (Добавление и удаление компонентов Windows).

3. В окне мастера Windows Components Wizard (Мастер компонентов Windows) установите флажок Certificate Services (Службы сертификации) (при этом система предупредит вас о последствиях установки этих служб) и нажмите кнопку Next (Далее).

4. На следующей странице мастера необходимо выбрать тип ЦС. Существуют четыре типа ЦС:

 Enterprise root СА (Корневой ЦС предприятия) — установите переключатель в это положение, если данный ЦС будет выпускать сертификаты для всех устройств, подключенных к сети в организации, и будет зарегистрирован в Active Directory. Данный ЦС является корнем в корпоративной иерархии ЦС и может устанавливаться только на контроллере домена. Обычно корневой ЦС предприятия выпускает сертификаты только для подчиненных ЦС;

 Enterprise subordinate СА (Подчиненный ЦС предприятия) — если у вас уже установлен корневой ЦС предприятия, выберите это положение переключателя. Однако данный ЦС не имеет наивысшего доверия в организации, поскольку он подчиняется корневому ЦС. Может устанавливаться только на контроллере домена;

 Stand-alone root CA (Изолированный корневой ЦС) — данный ЦС устанавливается для выпуска сертификатов за пределами корпоративной сети. Например, требуется установить изолированный корневой ЦС, если этот ЦС не будет участвовать в корпоративном домене и будет выпускать сертификаты для узлов во внешних сетях. Корневой ЦС обычно используется для выпуска сертификатов для подчиненных ЦС;

 Stand-alone subordinate CA (Изолированный подчиненный ЦС) — подчиненный ЦС, который выпускает сертификаты для узлов за пределами корпоративной сети.

5. Если вы собираетесь изменить параметры шифрования по умолчанию, установите флажок Use custom setting to generate the key pair and CA certificate (Использовать специальные параметры для генерации пары ключей и сертификата ЦС).

6. Нажмите кнопку Next.

7. Укажите имя ЦС и срок действия сертификатов. Введите необходимую информацию и нажмите кнопку Next.

8. Укажите папку на локальном или общем диске для хранения сертификатов и нажмите кнопку Next.

9. По окончании процедуры инсталляции нажмите кнопку Finish (Готово).

Восстановление зашифрованных файлов на другом компьютере

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

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

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

Запрос сертификата

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

Если вы пользуетесь смарт-картами, или в вашей организации не применяются автоматические запросы на получение сертификатов, то вы можете запросить новые сертификаты. Запросить новый сертификат можно с помощью мастера Certificate Request Wizard (Мастер запроса сертификата) или на веб-страницах служб сертификации. При запросе сертификатов в центре сертификации предприятия Windows Server 2003 используется, как правило, мастер Certificate Request Wizard, вызываемый из оснастки Certificates. Кроме того, центр сертификации, установленный на Windows Server 2003 в сочетании со службами Интернета (Internet Information Services), имеет веб- страницу, на которой можно запрашивать сертификаты. По умолчанию ЭТИ сертификаты находятся ПО адресу http://servername/certsrv, где servername — имя сервера, на котором находится ЦС.

Для того чтобы запросить сертификат в оснастке Certificates:

1. Откройте окно оснастки Certificates.

2. На панели структуры (левое подокно) откройте нужный узел: для пользователя Certificates | Current User (Сертификаты | текущий пользователь), для компьютера — Certificates | Computer Name (Сертификаты (локальный компьютер)).

3. Если вы находитесь в режиме просмотра "по логическим хранилищам", выберите папку Personal. В режиме "по назначению" выберите соответствующий режим (папку).

4. В меню Action (Действие) выберите команду All Tasks | Request New Certificate (Все задачи | Запросить новый сертификат).

5. В окне мастера Certificate Request Wizard выберите:

 тип (шаблон) сертификата;

 ЦС, который выдаст сертификат (если имеется несколько ЦС) (если установлен флажок Advanced (Дополнительно));

 поставщика службы криптографии (Cryptographic Service Provider, CSP) (если установлен флажок Advanced).

6. Введите дружественное имя сертификата и его описание.

7. После выбора и проверки всех параметров нажмите кнопку Finish (Готово).

---

---