В цикле статей будет рассммотрена двухуровневая иерархическая структура, которая является “классикой жанра” и подходит для большинства сценариев.
У нас будет один Автономный корневой ЦС (Offline Root CA) и один отказоустойчивый Корпоративный подчиненный издающий ЦС (Issuing Enterprise CA).
Доступ к сервису необходим как изнутри, так и извне организации, а значит будет осуществлен не через LDAP, а через веб. Для веб-публикации также будет применятся отказоустойчивый кластер.
В реальности часто приходится встречать “упрощенные” варианты – например единственный CA, еще и на контроллере домена. Не стоит думать что это нормально – восстановление после сбоя будет достаточно сложной процедурой.
Есть и другая крайность: много CA = длинная цепочка проверки, это также нерекомендуемый сценарий.
Root CA будет оффлайн т.к. это практически ничего не стоит, а преимуществ дает сразу пачку:
- Виртуальная машина с Root CA может храниться на флешке в сейфе – доступ к ней будет только у тех, кому положено;
- Приватный ключ Root CA может быть экспортирован в еще более защищенное место;
- Если доменная инфраструткура будет полностью изменена (например при слиянии предприятий), PKI не придется разворачивать заново;
- Обновление CRL будет выполняться вручную, по мере необходимости что повышает осознанность процесса.
Вопросы CPS я сознательно опускаю (но покажу как включать ее в CAPolicy.inf) потому что CPS уже юридическая тема, а статья посвещена технической стороне.
Роль Policy CA будет выполнять Issuing CA (издающий ЦС), и все что нужно знать на данном этапе – CPS это по-сути регламент, нарушение которого влечет за собой потерю цели внедрения PKI.
Что касается вопросов безопасности, общие рекомендации таковы:
Доступ к серверам и сервисам PKI должен быть ограничен – разумно создать отдельню группу, дать ей права, а затем выпилить остальных – например, Domain Admins, BUILTIN\Administrator, и т.п.
Также рекомендую сделать резервную копию для CA Private Key и ветки реестра в которой храняться настройки CA (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfiguration).
Для такого сервиса как PKI желательно выполнять не только резервное копирование, но и иметь рабочий Disaster Recovery Plan (DRP).
По отказоустойчивости будут использованы штатные возможности Windows Server – DFS и NLB, ничего сложного или примечательного там нет.