Материал: Книга Active directory

Сетевые ответчики часто являются альтернативой или дополнением к спискам CLR, которые поддерживают процесс отзыва сертификатов. Сетевые ответчики Microsoft соответствуют стандартам RFC 2560 для OCSP. Более подробную информацию об этих стандартах RFC можно найти по адресу http://go.microsoft.com/ fwlink/?LinkID-67082.

• Служба подачи заявок сетевых устройств Устройства, к о т о р ы е исполь - зуют низкоуровневые операционные системы, например м а р ш р у т и з а т о р ы и коммутаторы, также могут принимать участие в инфраструктуре P K I через службу NDES (Network Device Enrollment Service) с п о м о щ ь ю п р о т о к о л а SCEP (Simple Certificate Enrollment Protocol), разработанного к о м п а н и е й Cisco Systems, Inc. Эти устройства обычно не участвуют в каталоге AD DS и поэтому не располагают учетными записями AD DS. О д н а к о с п о м о щ ь ю службы NDES и протокола C S E P их также можно сделать частью иерархии PKI, которая поддерживается и управляется службами AD CS.

Эти четыре компонента ф о р м и р у ю т я д р о с л у ж б ы AD CS в W i n d o w s Server 2008.

К СВЕДЕНИЮ Новые компоненты AD CS

Более подробную информацию о новых компонентах, поддерживаемых службами AD CS в Windows Server 2008, можно найти по адресу http://technet2.microsoft.com/ windowsserver2008/en/library/171362c0-3773-498d-8cc3-0ddcd8082bf51033.mspx.

Независимые СА и центры с е р т и ф и к а ц и и п р е д п р и я т и я

При подготовке к развертыванию AD CS особое в н и м а н и е следует уделить структурированию основных четырех служб AD CS. Прежде всего нужно за-

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

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

Учтите также потенциальные сценарии развертывания AD CS. Будете ли вы взаимодействовать с партнерами вне вашей сети? Будут ли использоваться смарт-карты? Будут ли задействованы беспроводные сети? Будет ли использоваться IPSec или новый SSTP? Для сертификации подлинности устройства, приложения или пользователя необходимо использовать AD CS и, возможно, сторонние коммерческие центры сертификации.

Получив ответы на эти вопросы, можно переходить к планированию иерархии AD CS. При этом необходимо учесть следующее.

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

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

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

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

Реализация иерархии из двух уровней

Службы сертификации Active Directory

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

Рис. 15-4. Иерархия из двух уровней

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

Как видите, чем больше уровней в иерархии, тем выше уровень сложности процессов управления и администрирования. Однако по мере усложнения иерархии также нужно повышать уровень безопасности. Кроме того, нужно учесть тип СА, который будет развернут на каждом уровне. Типы СА в зависимости от количества уровней в этой модели описаны в табл. 15-2.

Табл. 15-2. Назначение типа СА в зависимости от числа уровней в модели