207

Списки отзыва сертификатов

Сертификаты, как и большинство удостоверений в обычной жизни, могут терять силу и становиться недействительными. ЦС также вправе отозвать сертификат по какой-либо причине. С этой целью ЦС ведет список отзыва сертификатов (certificate revocation list, CRL). Он доступен пользователям сети, и они могут определять действительность любого конкретного сертификата.

8.1.3.1. Иерархия ЦС

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

•гибкость — легко перемещать, отзывать или связывать ЦС, не затрагивая остальные части организации;

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

•собственные политики безопасности — у каждого центра ЦС может быть своя политика безопасности.

ЦС на вершине иерархической цепочки называется корневым, нижележащие — промежуточными (intermediate), подчи-

ненными (subordinate) или издающими (issuing).

8.1.4.Службы сертификации

Службы Microsoft Certificate Services позволяют организа-

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

Службы Microsoft Certificate Services предоставляют ши-

рокие возможности для организаций, которые не хотели бы об-

208

ращаться к сторонним ЦС и которым нужен адаптируемый механизм аутентификации.

Независимость от политики

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

Политика реализуется в соответствующих компонентах,

написанных на языках Java, Visual Basic или Microsoft C/C++.

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

Независимость от способа передачи

Службы сертификации могут запрашивать и рассылать сертификаты посредством любого транспорта. Они вправе принимать запросы сертификата от любого заказчика и высылать ему сертификаты по протоколу HTTP, путем удаленного вызова процедур (remote procedure call, RPC), публикации в файловой системе или иначе.

Соответствие стандартам

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

•принимают запросы, соответствующие стандарту Public Key Cryptography Standards (PKCS) #10;

•поддерживают данные, подписанные по стандарту

PKCS #7;

•издают сертификаты по стандарту Х.509 версий1.0 и 3.0. Службы сертификации способны поддерживать и допол-

нительные форматы сертификатов, а также включают в себя компонент LDAP, т.е. интегрированы в Active Directory .

Управление ключами

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

209

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

8.1.4.1. Архитектура служб сертификации

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

Рис. 8.3. Схема взаимодействия компонентов служб сертификации

Серверное ядро

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

Посредник

Этот архитектурный компонент получает запросы новых сертификатов от клиентов и направляет их серверному ядру. Посредник состоит из двух частей: приложения-посредника,

210

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

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

База данных сервера

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

Журнал

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

Очередь запросов

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

Модуль политики

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