файлы. Каталоги помечаются как зашифрованные, все файлы, которые будут помещены в них впоследствии, шифруются автоматически
Дешифрует все указанные после ключа файлы. Каталоги помечаются как незашифрованные — все файлы, которые будут помещены в них впоследствии, шифроваться не будут
Выполняет определенную ключом операцию как для каталогов, так и для отдельных файлов
Продолжает выполнение указанной операции даже после возникновения ошибочной ситуации. По умолчанию при появлении ошибки программа cipher останавливается
Осуществляет принудительное шифрование всех файлов, указанных после ключа, даже если они уже зашифрованы. По умолчанию уже зашифрованные файлы не подвергаются вторичному шифрованию
Создает новый ключ шифрования файлов для пользователя, запустившего команду; при этом все другие ключи команды игнорируются
может быть маской, файлом или каталогом. Команда cipher без параметров выдает информацию о том, зашифрован ли данный каталог или файлы, находящиеся в нем. Если параметр путь
присутствует, то имен файлов может быть несколько. Между собой параметры должны быть разделены пробелом.
|
Сортировка по
|
Папка
|
Содержит
|
Логическим хранилищам
|
Личные (Personal)
|
Сертификаты, связанные с личными, закрытыми ключами пользователя
|
|
Доверенные корневые центры сертификации
(Trusted Root Certification Authorities)
|
Доверяемые корневые центры сертификации
|
|
Доверительные отношения в предприятии
(Enterprise Trust)
|
Список доверительных отношений сертификатов (certificate trust list). Обеспечивает механизм доверия к корневым сертификатам со стороны других организаций
|
|
Промежуточные центры сертификации
(Intermediate Certification Authorities)
|
Сертификаты, выпущенные для других пользователей и центров сертификации
|
|
Объект пользователя Active Directory
(Active Directory User Object)
|
Сертификаты, связанные с вашим пользовательским объектом и опубликованные в Active Directory
|
|
REQUEST
|
Сертификаты, для которых запущен запрос, и отклоненные сертификаты
|
Назначению (основные группы)
|
Проверка подлинности сервера (Server Authentication)
|
Сертификаты, которые используются серверными программами для аутентификации при обращении к клиентам
|
|
Проверка подлинности клиента (Client Authentication)
|
Сертификаты, которые используются клиентскими программами для аутентификации при обращении к серверам
|
|
Подписывание кода (Code Signing)
|
Сертификаты, связанные с парами ключей, используемых для подписи активного содержания
|
|
Защищенная электронная почта (Secure Email)
|
Сертификаты, связанные с парами ключей, используемых для подписи электронных сообщений
|
|
Шифрованная файловая система (Encrypting File System)
|
Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для шифрования и дешифрования данных
|
|
Восстановление файлов
(File Recovery)
|
Сертификаты, связанные с парами ключей, которые шифруют и дешифруют симметричный ключ, используемый для восстановления зашифрованных данных
Поля вкладки Состав (Details)
Таблица 26.3.
Поля вкладки
Состав
(Details)
|
Поле
|
Описание
|
Версия (Version)
|
Номер версии стандарта Х.509
|
Серийный номер (Serial Number)
|
Уникальный серийный номер, который ЦС назначил сертификату. Серийный номер является уникальным для всех сертификатов, выпущенных данным центром сертификации
|
Алгоритм подписи (Signature Algorithm)
|
Алгоритм хэширования (hash algorithm), который ЦС использует для цифровой подписи сертификата
|
Поставщик (Issuer)
|
Информация о ЦС, который выпустил сертификат
|
Действителен с (Valid from)
|
Дата начала действия сертификата
|
Действителен по (Valid to)
|
Дата окончания действия сертификата
|
Субъект (Subject)
|
Имя индивидуального пользователя или ЦС, для которого выпущен сертификат. Если выпустивший сертификат ЦС находится на сервере — члене домена вашего предприятия, то данное имя является отличительным именем внутри вашей организации. В противном случае в этом поле будут записаны полное имя и адрес электронной почты
|
Открытый ключ (Public Key)
|
Тип и длина открытого ключа, связанного с сертификатом
|
Улучшенный ключ (Enhanced Key Usage)
|
Дополнительные задачи, для решения которых можно использовать открытый ключ, связанный с сертификатом
|
Алгоритм печати (Thumbprint Algorithm)
|
Алгоритм хэширования, который генерирует снимок или
дайджест
данных для цифровых подписей
|
Печать (Thumbprint)
|
Снимок или дайджест
|
Понятное имя (Friendly Name)
|
Дружественное или общее имя
Вкладка
Путь сертификации
содержит путь выпустившего сертификат ЦС.
Технологии шифрования EFS
|
Технологии шифрования EFS
EFS основана на шифровании с открытым ключом и использует все возможности архитектуры CryptoAPI в Windows 2000. Каждый файл шифруется с помощью случайно сгенерированного ключа, зависящего от пары открытого (public) и личного, закрытого (private) ключей пользователя. Подобный подход в значительной степени затрудняет осуществление большого набора атак, основанных на
криптоанализе.
При криптозащите файлов может быть применен любой алгоритм симметричного шифрования. Текущая версия EFS использует алгоритм DESX (расширенный DES) с длиной ключа
56
бит. EFS позволяет осуществлять шифрование и дешифрование файлов, находящихся на удаленных файловых серверах.
|
|
Примечание 1
Примечание 1
|
|
В данном случае EPS может работать только с файлами, находящимися на диске. Шифрующая файловая система не осуществляет криптозащиту данных, передаваемых по сети. Для шифрования передаваемой информации в операционной системе Windows 2000 следует применять специальные сетевые протоколы, например SSL/PCT.
Требования к рабочему окружению
Протокол Kerberos налагает несколько требований на рабочее окружение, в котором он может эффективно работать:
|
|
Kerberos не противодействует атакам типа "отказ в обслуживании". Особенности протокола Kerberos позволяют злоумышленнику заставить приложение не принимать, участие в процессе аутентификации. Обнаружение и борьба с атаками этого типа (часть которых может проявляться в установлении необычных режимов работы программного обеспечения), как правило, лучше всего выполняются администраторами систем.
|
|
Партнеры по обмену данными должны хранить свои секретные ключи в надежном месте. Если злоумышленник каким-либо образом похитит секретный ключ, он сможет выдать себя за одного из партнеров или имперсонализировать сервер для законного клиента.
|
|
Kerberos не противодействует атакам типа "подбор пароля". Если пользователь задает легко угадываемый пароль, злоумышленник с большой ве-ро'ятностью может его определить подбором с применением словаря.
|
|
Каждый хост сети должен иметь часы, которые приблизительно синхронизируются с часами других хостов. Синхронизация необходима, чтобы было легче обнаружить факт передачи копии заранее перехваченного сообщения. Степень приблизительности синхронизации может быть установлена индивидуально для каждого сервера. Сам протокол синхронизации серверов сети должен быть защищен от атак злоумышленников.
|
|
Идентификаторы партнеров не могут быть повторно использованы через небольшой промежуток времени. Как правило, для управления доступом применяются
списки управления доступом
(Access Control List, ACL), в которых хранятся разрешения доступа, предоставленные всем партнерам по обмену данными. Если в базе данных списков управления доступом остался список уничтоженного партнера по обмену данными, идентификатор которого используется вторично, то новый партнер унаследует все права доступа уничтоженного партнера. Избежать подобной опасности можно, только если запретить использование идентификаторов уничтоженных партнеров в течение продолжительного времени, а лучше вообще сделать идентификаторы уникальными.
Установка центра сертификации
Центр сертификации (ЦС, СА) — важный элемент в системе безопасности организации, поэтому в большинстве организаций имеется собственный ЦС. В системе Windows 2000 есть два модуля политик, которые обеспечивают следующие два класса ЦС:
ЦС предприятия
(Enterprise СА) и
изолированный ЦС
(Stand-alone СА). Внутри каждого класса могут быть два типа ЦС:
корневой
(root) и
подчиненный
(subordinate). Модули политик определяют действия, которые должен выполнить ЦС при поступлении запроса на получение сертификата.
В большинстве случаев центры сертификации организованы в иерархическом порядке, где наиболее доверяемый или корневой центр находится на вершине иерархии. В корпоративной сети все остальные ЦС в иерархии являются подчиненными. В корпоративной сети ЦС предприятия имеет максимальное доверие. ЦС предприятия имеют специальный модуль политик, который определяет, как обрабатываются и выпускаются сертификаты. Информация политики из данного модуля хранится в Active Directory, поэтому для инсталляции ЦС предприятия сперва следует установить Active Directory и сервер DNS. Изолированные ЦС имеют очень простой модуль политик и не хранят никакой информации на удаленном сервере, поэтому для инсталляции данного центра не требуется наличие Active Directory.
Для инсталляции собственного ЦС:
|
1.
|
Выберите на панели управления значок
Установка и удаление программ
(Add/Remove Programs).
|
2.
|
В открывшемся диалоговом окне нажмите кнопку
Добавление и удаление компонентов Windows
(Add/Remove Windows Components). Откроется диалоговое окно
Мастер компонентов Windows
(Windows Components Wizard).
|
3.
|
Установите флажок
Службы сертификации
(Certificate Services) и нажмите кнопку
Далее
(Next).
|
4.
|
В следующем диалоговом окне необходимо выбрать тип ЦС:
корневой ЦС предприятия (Enterprise root CA) — установите переключатель в это положение, если данный ЦС будет выпускать сертификаты для всех устройств, подключенных к сети в организации, и будет зарегистрирован в Active Directory. Данный ЦС являемся корнем в корпоративной иерархии ЦС. Обычно корневой ЦС предприятия выпускает сертификаты только для подчиненных ЦС.
подчиненный ЦС предприятия
(Enterprise subordinate CA) — если у вас уже установлен корневой ЦС предприятия, выберите это положение переключателя. Однако данный ЦС не имеет наивысшего доверия в организации, поскольку он подчиняется корневому ЦС.
изолированный корневой ЦС
(Stand-alone root CA) — данный ЦС устанавливается для выпуска сертификатов за пределами корпоративной сети. Например, требуется установить изолированный корневой ЦС, если этот ЦС не будет участвовать в корпоративном домене и будет выпускать сертификаты для узлов во внешних сетях. Корневой ЦС обычно используется для выпуска сертификатов для подчиненных ЦС.
изолированный подчиненный ЦС
(Stand-alone subordinate CA) — подчиненный ЦС, который выпускает сертификаты для узлов за пределами корпоративной сети.
|
5.
|
Если вы собираетесь изменить установки шифрования, установите флажок
Дополнительные возможности
(Advanced Options).
|
6.
|
Нажмите кнопку Далее.
|
7.
|
В следующих диалоговых окнах вам будет предложено указать сведения о вас и о вашей компаний, которые будут занесены в сертификат, выбрать каталог, в котором будет находиться информация сертификатов. Введите необходимую информацию и нажмите кнопку
Далее.
|
8.
|
По окончании процедуры инсталляции нажмите кнопку
Готово
(Finish).
Утилита cipher
Эта утилита командной строки позволяет шифровать и дешифровать файлы. Ниже приведен ее синтаксис, описание ключей дано в табл. 26.1.
cipher [/Е | D] [t/S:каталог] [/A] [/I] [/F] [/Q] [/Н] [/К] [путь [...]]
Восстановление данных, зашифрованных с помощью неизвестного личного ключа
EFS располагает встроенными средствами восстановления зашифрованных данных в условиях, когда Неизвестен личный ключ пользователя. Необходимость подобной операции может возникнуть в следующих случаях:
|
|
Пользователь был уволен из компании и ушел, не сообщив свой пароль.
Работа с зашифрованными файлами такого пользователя невозможна.
|
|
Пользователь утратил свой личный ключ.
|
|
Органы государственной безопасности направили запрос на получение доступа к зашифрованным данным пользователя.
Windows 2000 позволяет создать необходимые ключи для восстановления зашифрованных данных в описанных ситуациях. Пользователи, которые могут восстанавливать зашифрованные данные в условиях утраты личного ключа, называются
агентами восстановления данных.
Агенты восстановления данных обладают сертификатом (Х509 version 3) на восстановление файлов и личным ключом, с помощью которых выполняется операция восстановления зашифрованных файлов. Используя ключ восстановления, можно получить только сгенерированный случайным образом ключ, с помощью которого был зашифрован конкретный файл. Поэтому агенту восстановления не может случайно стать доступной другая конфиденциальная информация. Средство восстановления данных предназначено для применения в разнообразных конфигурациях вычислительных сред. Параметры процедуры восстановления зашифрованных данных в условиях утраты личного ключа задаются
политикой восстановления.
Она представляет собой одну из политик открытого ключа. При установке Windows 2000 Server политика восстановления автоматически создается на первом контроллере домена. Администратор домена одновременно является и агентом восстановления. Могут быть добавлены и другие агенты. Это делается с помощью оснастки
Групповая политика
(Group Policy), в которой нужно раскрыть узел
Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Политики открытого ключа | Агенты восстановления шифрованных данных
(Computer Settings | Security Settings I Public Key Policies | Encrypted Data Recovery Agents) и выполнить в контекстном меню команду
Добавить
(Add) или
Создать
(Сгеа1е)( в первом случае выбирается пользователь с
имеющимся
сертификатом агента восстановления, во втором — запрашивается и устанавливается
новый
сертификат для текущей учетной записи). Политика восстановления существует и на одиночном компьютере. В этом случае агентом восстановления автоматически становится администратор компьютера.
|
|
Примечание 1
Примечание 1
|
|
Из вышесказанного следует, что политика восстановления определяется только для
компьютера,
но не для
пользователя.
Политика восстановления, применяемая по умолчанию, создается на каждом компьютере при инсталляции системы. Если компьютер подключается к сети, для него политика восстановления может быть определена также на уровне его домена или подразделения, причем она должна быть установлена
до
того, как начнет применяться шифрование, и имеет приоритет над политиками восстановления, задаваемыми локальными администраторами.
Существует три "типа" политик восстановления:
|
|
Политика агентов восстановления.
Когда администратор добавляет одного или нескольких агентов восстановления, начинает действовать политика агентов восстановления. Это наиболее широко используемый тип политики.
|
|
Пустая политика восстановления
(empty policy). Когда администратор уничтожает всех агентов восстановления и их сертификаты открытых ключей, начинает действовать пустая политика восстановления. Это значит, что не существует ни одного агента восстановления, и в пределах области действия данной политики пользователи не могут шифровать свои данные. Применение пустой политики восстановления эквивалентно отключению работы EFS.
|
|
Отсутствие политики восстановления
(no policy). Когда администратор удаляет групповую политику восстановления, для восстановления зашифрованных данных в условиях утраты личного ключа используются
локальные
политики восстановления, существующие на каждом компьютере, и процессом восстановления управляет локальный администратор компьютера.
Настройка параметров политики восстановления выполняется с помощью оснастки
Групповая политика
(узел
Политики открытых ключей
).
|
|
Примечание 2
Примечание 2
|
|
Некоторое неудобство
графическою
интерфейса оснастки Групповая политика состоит в том, что
в
узле Политики открытых ключей нечетко отображаются состояния "пустая политика" и "отсутствие политики". При отсутствии записей в этом узле о текущем состоянии можно судить косвенно по опциям контекстного меню: в первом случае присутствует команда Удалить политику и нельзя добавить/создать агента восстановления (хотя мастер и выполнит все операции), а во втором — имеется команда Инициализировать пустую политику.
Восстановление зашифрованных файлов на другом компьютере
Часто возникает необходимость восстановить зашифрованную информацию не на том компьютере, на котором она была заархивирована. Это можно выполнить с помощью утилиты архивации. Однако необходимо позаботиться о переносе на новый компьютер соответствующего сертификата и личного ключа пользователя с помощью перемещаемого профиля либо вручную.
На любом компьютере, где зарегистрировался пользователь, обладающий перемещаемым профилем, будут применяться одни и те же ключи шифрования.
Ручной перенос личного ключа и сертификата выполняется в два этапа: сначала следует создать резервную копию сертификата и личного ключа, а затем восстановить созданную копию на другом компьютере. Создание резервной копии сертификата состоит из следующих шагов:
|
1.
|
Запустите оснастку Сертификаты.
|
2.
|
В левом подокне оснастки
Сертификаты
откройте папку
Личные
(Personal), а затем папку
Сертификаты.
В правом подокне появится список ваших сертификатов.
|
3.
|
Укажите переносимый сертификат и щелкните правой кнопкой мыши. В появившемся контекстном меню выберите команду
Все задачи
(All Tasks). В ее подменю выберите команду
Экспорт
(Export). Запустится Мастер экспорта сертификатов (Certificate Export Wizard).
|
4.
|
Нажмите кнопку
Далее.
|
5.
|
В следующем окне мастера выберите опцию
Да, экспортировать закрытый ключ
(Yes, export the private key). Затем нажмите кнопку Далее.
|
6.
|
В следующем окне мастера доступен только один формат (PFX), предназначенный для персонального обмена информацией. Нажмите кнопку
Далее.
|
7.
|
В следующих окнах сообщите пароль, защищающий данные файла *.pfx, а также путь сохранения файла *.pfx; затем нажмите кнопку
Далее.
|
8.
|
Отобразится список экспортируемых сертификатов и ключей. Нажмите кнопку
Готово.
|
9.
|
Завершите работу мастера экспорта нажатием кнопки ОК в окне диалога, сообщающем об успешном выполнении процедуры экспорта.
В результате сертификат и секретный ключ будут экспортированы в файл с расширением pfx, который может быть скопирован на гибкий диск и перенесен на другой компьютер.
Для восстановления сертификата из резервной копии:
|
1.
|
Перенесите созданный на предыдущем этапе файл с расширением pfx на компьютер, где вы планируете восстанавливать зашифрованные данные.
|
2.
|
Запустите оснастку
Сертификаты.
|
3.
|
В окне структуры оснастки
Сертификаты
откройте папку
Личные,
затем папку
Сертификаты.
В правом подокне появится список ваших сертификатов.
|
4.
|
Щелкните правой кнопкой мыши на пустом месте правого подокна. В появившемся контекстном меню выберите команду
Все задачи.
В ее подменю выберите команду
Импорт
(Import). Запустится Мастер импорта сертификатов (Certificate Import Wizard).
|
5.
|
Следуйте указаниям мастера — укажите местоположение файла с расширением pfx и сообщите пароль защиты данного файла. Восстановление данных из резервной копии должно быть выполнено в папку
Личные.
|
6.
|
Для начала операции импорта нажмите кнопки
Готово
и
ОК.
После завершения процедуры импорта нажмите кнопку ОК и закройте окно мастера импорта.
В результате текущий пользователь получит возможность работать с зашифрованными данными на этом компьютере.
|
|
Примечание 1
Примечание 1
|
|
Официальные источники от Microsoft утверждают, что в текущей версии Windows совместное использование зашифрованных файлов невозможно. Однако описанная процедура позволяет получить доступ не только к своим зашифрованным данным, но и обеспечить доступ к информации на общем ресурсе всем пользователям, которые установят сертификат и ключ, примененные для шифрования (при большом числе пользователей это, конечно, обеспечить непросто). Предоставляем читателям возможность еще раз проверить это утверждение.
Взаимодействие безопасности IP с различными программными продуктами
Следующие замечания относятся к текущей версии Windows 2000 Server:
|
|
Для работы безопасности IP оба компьютера должны работать под управлением Windows 2000.
|
|
Безопасность IP в Windows 2000 не будет функционировать с Microsoft Proxy Server или брандмауэрами третьих фирм, если не разрешена пересылка IP-пакетов.
|
|
Сетевой монитор показывает пакеты, обработанные безопасностью IP, но не может отображать шифрованную информацию.
Взаимодействие с удаленными владениями
Протокол Kerberos может работать вне пределов одной компании. Клиент данной организации может быть аутентифицирован на сервере, находящемся в другой организации. Каждое предприятие, желающее применять в своей сети Kerberos, должно установить границы своего
владения
(realm; используется также термин
сфера).
Имя владения, в котором зарегистрирован данный пользователь, составляет часть его имени и может быть использовано конечной службой для принятия решения об удовлетворении данного запроса.
Установив общие ключи для владений, администраторы могут позволить клиентам различных владений выполнять
удаленную аутентификацию.
Конечно, обладая необходимыми разрешениями, клиент может зарегистрировать партнера, имеющего не связанное с данным владением имя, и установить нормальный обмен сообщениями. Однако даже при незначительном количестве удаленных регистрации такой подход создает большие неудобства, поэтому рекомендуются более автоматизированные методы. При обмене
общими во владениях ключами
(inter realm keys) (при передаче информации в каждом направлении может быть использован отдельный ключ) службы выдачи билетов регистрируются в противоположном владении в качестве партнера по обмену данными. После этого клиент может получать ТОТ от локальной службы выдачи билетов для такой же службы, находящейся в удаленном владении. При использовании этого TGT для его дешифрования удаленная служба выдачи билетов применяет общий для владений ключ, который, как правило, отличается от ключа TGS-сервера. Это гарантирует, что данный TGT был передан собственным TGS-сервером клиента. Билеты,
посланные удаленной службой выдачи билетов, укажут конечной службе, что аутентификация клиента была выполнена в удаленном владении.
Одно владение может обмениваться информацией с другим владением, если оба они обладают общим ключом, или если локальная служба выдачи билетов обладает общим ключом с промежуточным владением, в свою очередь обладающим общим ключом с целевым владением.
Путь аутентификации —
это последовательность промежуточных владений, каждое из которых может обмениваться информацией со своими соседями.
Как правило, владения организованы в иерархическую структуру. Каждое владение обладает общим ключом со своим родителем и отдельным общим ключом с каждым дочерним владением. Если между двумя владениями не существует общего ключа, иерархическая структура позволяет легко установить путь аутентификации. Если иерархическая структура владений не используется, для обнаружения пути аутентификации следует применять базу данных.
Иерархическая организация владений делает возможным альтернативный путь аутентификации — минуя промежуточные владения. Это может оптимизировать обмен данными между двумя владениями. Конечной службе важно знать, через какие владения проходит путь аутентификации, поскольку от этого зависит достоверность всего процесса аутентификации. Для облегчения принятия такого решения каждый билет содержит поле, где хранятся имена всех владений, которые составляют путь аутентификации.
Взаимодействие Windows 2000 КDС и UNIX
Часто возникает вопрос: как Windows 2000 будет работать с существующими серверами Kerberos, функционирующими в ОС UNIX? Windows 2000 взаимодействует с КОС, работающими на MIT Kerberos, двумя способами:
|
|
Компьютер с Windows 2000 может быть настроен на применение UNIX КОС. Пользователи могут входить в систему с помощью учетной записи, определенной в UNIX КОС, точно так же, как это делают станции UNIX, Любое приложение Windows 2000 или UNIX, требующее только аутентификации, основанной на имени, может использовать UNIX КОС в качестве сервера Kerberos. Например, сервер баз данных, имеющий собственную таблицу авторизации на доступ к базе, может аутентифицировать клиента Windows 2000 с помощью билетов Kerberos, полученных у UNIX KDC. Поскольку сервер баз данных не использует средства управления доступом Windows 2000, он может работать в среде Windows 2000 без применения имперсонализации. Для приема билетов сеанса, выдаваемых UNIX KDC, и запроса контекста безопасности для определенного имени клиента сервер вызывает поставщика безопасности Kerberos. Билеты, выданные UNIX KDC, могут быть использованы при взаимной аутентификации и защите сообщений. Однако без данных авторизации контекст безопасности не может быть использован для имперсонализации.
|
|
Windows 2000 может взаимодействовать с MIT Kerberos посредством доверия, установленного между владением UNIX и доменом Windows 2000. Это наилучший способ поддержки служб Windows 2000, использующих имперсонализацию и средства управления доступом. Доверие, установленное между владениями, очень похоже на широко применяемую модель нескольких доменов Windows NT 4.0, которые делятся на
домены учетных записей
и
домены ресурса”.
В этом случае KDC выполняет роль домена учетных записей, а службы, работающие в среде Windows 2000, находятся в домене ресурсов. Windows 2000 KDC — это сервер авторизации для служб Windows 2000. Данные авторизации Windows 2000 добавляются в KDC к билетам сеанса, предназначенным для серверов домена Windows 2000. Данные авторизации хранят соответствие между именами партнеров по обмену данными владения UNIX и теневыми (proxy) учетными записями; при этом учитывается принадлежность учетных записей к группам, информация о которых хранится в Active Directory. Эти учетные записи могут быть синхронизированы с помощью LDAP.
Может ли UNIX KDC быть сервером авторизации для служб Windows 2000? Модель распределенной безопасности Windows 2000 зависит не только от списка идентификаторов безопасности, хранящихся в данных авторизации билетов Kerberos. Например, Редактору ACL, используемому для управления безопасностью файлов, расположенных в NTFS, требуется для работы сервер домена, предназначенный для поиска соответствия имени и SID, в процессе которого посредством защищенного канала NetLogon выполняется RFC-вызов к контроллеру домена. Без трансляции идентификаторов, выполняемой интерфейсом RPC, Редактор ACL отображает права доступа к файлам NTFS для учетной записи, имя которой неизвестно (account unknown), поскольку идентификатор безопасности не может быть распознан.
Интерфейс пользователя должен позволять выбирать учетные записи, которым следует предоставить права доступа. Эта функция позволит администратору выбрать пользователя или группу из списка, являющегося результатом запроса LDAP к Active Directory. В нем установлены все соответствия между именами учетных записей и их идентификаторами безопасности.
Для успешной работы UNIX KDC в качестве сервера авторизации служб Windows 2000 необходимо, чтобы KDC обеспечивал поддержку имен NetBIOS. Пользователи Windows NT хорошо знакомы с именами компьютеров для NetBIOS. Кроме того, приложения должны иметь возможность аутентифицироваться в серверах с помощью имен типа
\\project1\projectshare.
Наконец, поставщик безопасности Kerberos проверяет данные авторизации, находящиеся в билетах Kerberos и присланные не обладающими доверием приложениями, с помощью RPC к контроллеру домена. Защищенный RPC используется, чтобы проверить подпись KDC для предотвращения несанкционированного использования привилегий членства в группах.
Замена контроллера домена на UNIX KDC потребует от MIT Kerberos возможности выполнения дополнительных функций, связанных с поддержкой защищенного канала NetLogon, аутентифицированного RPC, имен NetBIOS и протокола LDAP.
На данный момент компания Microsoft интенсивно работает над созданием сетевой системы безопасности, обладающей возможностью работы на различных платформах и основанной на протоколах, являющихся отраслевыми стандартами, например SSL, TLS, ISAKMP/Oakley и Kerberos версии 5. Следует отметить, что возможности взаимодействия со средствами обеспечения безопасности, работающими на других платформах, демонстрируемые Windows 2000, открывают новые перспективы построения защищенных распределенных компьютерных систем на базе гетерогенных сетей предприятий. Управление инфраструктурой системы безопасности сети предприятия требует целого набора протоколов, позволяющих поддерживать модель распределенной безопасности. Важнейшими элементами инфраструктуры распределенных систем на основе Windows 2000 являются аутентификация с использованием Active Directory и протокол Kerberos 5.
Запрос сертификата
Если ваш администратор создал политику открытого ключа для автоматизации запросов на получение сертификатов, то вам, возможно, никогда не придется запрашивать сертификаты самостоятельно, если только вы не работаете со смарт-картами. Пользователи смарт-карт должны запрашивать свои сертификаты.
Если вы пользуетесь смарт-картами, или в вашей организации не применяются автоматические запросы на получение сертификатов, то вы можете запросить новые сертификаты. Запросить новый сертификат можно с помощью Мастера запроса сертификата (Certificate Request Wizard) или на веб-страницах служб сертификации. При запросе сертификатов в центре сертификации предприятия Windows 2000 используется, как правило, Мастер запроса сертификата, вызываемый из оснастки
Сертификаты.
Кроме того, центр сертификации, установленный на Windows 2000 Server, имеет веб-страницу, на которой можно запрашивать базовые и расширенные сертификаты. По умолчанию эти сертификаты находятся по адресу
http://servemame/certsrv,
где
servername —
имя сервера Windows 2000, на котором находится ЦС.
Для того чтобы запросить сертификат в оснастке
Сертификаты
:
|
1.
|
Откройте окно оснастки
Сертификаты.
|
2.
|
На панели структуры (левое подокно) откройте нужный узел (для пользователя
Сертификаты — текущий пользователь
(Certificates | Current User), для компьютера —
Сертификаты (локальный компьютер)
(Certificates | Computer Name)).
|
3.
|
Если вы находитесь в режиме просмотра "по логическим хранилищам", выберите папку
Личные.
Если вы в режиме "по назначению", выберите соответствующий режим (папку).
|
4.
|
В меню
Действие
выберите команду
Все задачи | Запросить новый сертификат
(All Tasks | Request New Certificate).
|
5.
|
В окне мастера запроса сертификата выберите:
Шаблон сертификата, который вы запрашиваете
ЦС, который выдаст сертификат (если имеется несколько ЦС) (если установлен флажок
Дополнительные параметры
(Advanced Options))
Поставщика службы криптографии
(Cryptographic Service Provider, CSP) (если установлен флажок
Дополнительные параметры)
|
6.
|
После выбора и проверки всех параметров нажмите кнопку Готово (Finish), а затем, после получения сертификата — кнопку
Установить сертификат
(Install Certificate). Перед установкой выданный сертификат можно просмотреть.
Запуск оснастки Центр сертификации (Certification Authority)
После инсталляции центра сертификации выберите команду
Пуск | Программы | Администрирование | Центр сертификации
(Start | Programs | Administrative Tools | Certification Authority). Откроется окно оснастки (Рисунок 26.15), с помощью которой можно просматривать списки сертификатов и политики безопасности, а также управлять ими.
|
|
Рис 26.15.
Окно оснастки
Центр сертификации
(Certification Authority)