Update 05.12.2009: выпилена часть про смену пароля как не совсем правильную (см.каменты). Судя по логике смены паролей компьютерами в домене, можно реализовать Offline CA в доменной среде с большим сроком бездействия. Но это всё равно не отменяет того факта, что такое решение будет не совсем правильным.

Сегодня хочу немного обсудить несколько (все не получится :-() вопросов планирования ирерархий Certification Authority (CA), как это делается в реальном мире. Как таковых бест-практисов на эту тему не существует, равно как и бест-практисов по планированию лесов Active Directory. Есть только несколько стандартных классических схем и рекомендаций на основании которых можно выбирать. Этот вопрос очень серьёзный, поскольку иерархии PKI и AD очень редко меняются в силу сложности и дороговизны процесса. И с тем вариантом, который вы выбрали на этапе планирования, скорее всего вы будете жить очень долго.

Лирическое отступление

В реальной жизни домены и PKI в основном развёртываются по одному из трёх сценариев:

• Говноадминами в метро на коленке за 15 минут;
• Системными администраторами после тщательного (по мере сил) анализа существующей инфраструктуры;
• Системными интерграторами или аутсорсерами, грохая огромные деньги на полный и компетентный анализ существующей инфраструктуры, учитывая требования бизнеса с запасом на 5 лет минимум.

Не всем посчастливилось устроиться работать в компанию последней группы и чаще всего приходится работать в первых двух. С первым вариантом даже обсуждать нечего, потому что с такими администраторами говорить вовсе не о чем, разве что смаковать последние новости с ЛОРа, секлаба и двача. Я всё-таки надеюсь, что этот пост будет полезен администраторам второй группы.

Перед принятием решения о развёртывании PKI необходимо понять, что детский сад уже заканчивается и начинается взрослая половая жизнь к которой нужно относиться весьма серьёзно. Это будет означать, что PKI будет достаточно критичным моментом в инфраструктуре и любые фейлы потенциально (в реальности так и происходит) могут очень негативно отразиться на бизнесе, поэтому саму архитектуру нужно спланировать так, чтобы возможность эпик-фейла была как можно минимальной, а расширение было безболезненным. Самое основное, что должен знать администратор — это роли CA их назначение. Всего этих ролей 3:

1. Root CA — корневой CA, который является наиболее критической точкой в инфраструктуре, потому что потеряв/скомпрометировав его, ваша PKI и репутация компании летит к чёрту, поскольку это та точка доверия, которая проверяется весьма условно. Т.е. вы доверяете тому или иному корневому сертификату только на основании каких-то косвеных данных или собственных предпочтениях. Технически проверить «хорошесть» корня не представляется возможным. Как правило выдаёт сертификаты только подчинённым Policy CA.
2. Policy CA — даже не знаю как его перевести, поэтому не буду. Но его суть сводится к тому, что данный тип CA определяет политику сертификации на данном CA и на всех последующих CA в цепочке. Каждый Policy CA характеризуется своим собственным CPS (Certificate Practice Statement). Поэтому если у вас на предприятии используются различные схемы проверки подлинности участников, которые запрашивают сертификаты и требования к ним, а так же мероприятия по организации CA, то каждая такая схема выносится в отдельный CPS и отдельный Policy CA. Так же, как и корень, является критической точкой в иерархии, но чуть меньше, чем корневой CA. Поскольку изъять из эксплуатации (decomission) Policy CA всяко проще, чем корневой. Об этой проблеме я уже говорил в посте Certificate chaining engine (CCE) и отзыв корневых сертификатов. Policy CA может быть выделенный и выдавать сертификаты только подчинённым Policy или Issuing CA. А может быть и одновременно совмещён с ролью Issuing CA.
3. Issuing CA — издающий CA, который уже выдаёт сертификаты конечным потребителям — пользователям, компьютерам, различным сетевым устройствам. Каждый Issuing CA должен подчиняться тем требованиям и указаниям, которые описаны в CPS Policy CA.

Enterprise Root CA — хороший выбор?

В условиях малого и среднего бизнеса не всегда можно набрать компетентный в этих вопросах персонал, поэтому админстраторы обычно делают всё попроще — ставят 1 или 2 Enterprise Issuing CA и радуются жизни. В таких ситуациях один единственный CA выполняет все 3 роли — он и корневой, и Policy и издающий CA. Чем это плохо? Учитывая тот факт, что сервер CA находится постоянно в сети и его настройки безопасности могут содержать брешь, через которую CA можно легко скомпрометировать. Это, например, совмещение роли CA с другими ролями, как контроллер домена, сервер терминалов, файл-сервер и т.д. В данных случаях получить доступ к закрытому ключу CA будет проще, чем в остальных сценариях.

Если выделить отдельный сервер, член домена, под роль CA, то риск снижается, но незачительно, поскольку любой член групп Domain/Enterprise Admins, операторы бэкапа, etc. могут получить доступ к ключу CA. Это весьма неиллюзорная угроза, поскольку обидевшийся админ может поломать вам единственный корневой CA и даже использовать его ключ в корыстных целях — выпускать «липовые» сертификаты. Учитывая, что не существует идеальной ОС и в любой из них обнаруживаются те или иные уязвимости, при помощи которых злоумышленник может положить ваш CA не слезая с подругидивана просто запустив эксплоит (я надеюсь, что случай с конфикером/кидо напоминать не надо?). Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес, поскольку мигрировать в другой домен/лес может быть весьма проблематично. И если вы решили переименовать домен или мигрировать в другой лес, то неиллюзорный секс с миграцией PKI вас ожидает, особенно, если всё делалось простым Next-Next. Это означает, что даже в условиях сети на 20 человек, держать корневой CA постоянно в сети — не самая лучшая идея. Хотя, если у вас есть HSM (Hardware Security Module), то опасность компрометации такого CA снижается, но не на столько, чтобы оправдать наличие корневого CA в доменной сети. Да и цена таких девайсов явно не по карману компаниям малого и среднего бизнеса. Лично мне с HSM поработать не довелось.

Следовательно, чтобы избежать всех этих проблем путь есть только один — вынос корневого CA из домена на отдельный сервер рабочей группы. При этом вы можете не покупать Enterprise редакции Windows Server, поскольку в рабочей группе хватает Standard Edition (а с выходом Winows Server 2008 R2, Standard тянет даже на Enterprise CA). Какие преимущества вы получите от такого CA?

• Резко уменьшается количество людей, которые могут получить доступ к серверу (как физический, так и программный);
• В рабочей группе вы никак не привязаны к имени домена/леса. Что позволяет сохранять корень доверия даже при смене лесов;
• В рабочей группе сервер не обязательно должен быть подключён к сети. А лучше вообще не подключать к сети, в результате чего вероятность атаки с использованием уязвимости резко падает до нуля;
• Вы можете сделать Offline CA, который будет включаться только для того, чтобы обновить свои CRL, выдать сертификат новому подчинённому CA или обновить свой собственный сертификат. Учитывая, что корневой CA выдаёт сертификаты только другим CA, поэтому вероятность необходимости отзыва такого сертификата не очень высока. Это позволяет увеличить срок действия CRL до нескольких месяцев. Здесь главное — не переусердствовать и делать срок действия CRL более 3-х месяцев вряд ли будет разумным.

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

Policy CA — что это и зачем оно нужно?

Это достаточно большой и очень теоретический вопрос. В действительности Policy CA от остальных отличает только активная кнопка Issuer Statement:

К сожалению очень многие компании забивают на такую мелочь. Подумаешь, есть кнопка или нет её. Но в действительности Policy CA очень нужен, поскольку кнопка Issuer Statement ведёт на CPS данной ветки иерарахии CA. Как я уже говорил, CPS документально описывает порядок работы служб сертификации и сопутствующих механизмов. В RFC 3647 вы можете более подробно ознакомиться с содержимым CPS или просто почитать CPS коммерческих CA, например, VeriSign — http://www.verisign.com/repository/cps. И это не просто бумажка какая-то, а уже юридический документ, за нарушение условий которого можно получить конфет пизденцовнанести сильный ущерб доверию компании со стороны самих сотрудников и внешних партнёров. Поскольку компания может вырасти или могут поменяться условия работы, не рекомендуется совмещать роль Policy CA с ролью корневого CA, потому что корень у вас только один, а политик сертификации может быть несколько. Все последующие CA (если есть) будут подчиняться политике самого первого Policy CA в цепочке. Поэтому каждый CA второго уровня (следом за корнем) будет представлять своё дерево политик сертификации со своим CPS.

Если Policy CA не рекомендуется совмещать с корнем, то совмещать его с Issuing CA вполне можно, если у вас планируется только один Issuing CA. Если же их будет больше одного, то Policy CA следует выносить отдельно и предусмотреть для него такие же правила размещения, как и для Offline Root CA (об этом я рассказывал чуть выше). Почему не рекомендуется совмещать Policy CA и Issuing CA, если издающих будет больше одного? Дело в том, что у вас не должно быть больше одного уровня издающих CA. Т.е. вот такой схемы:

Поскольку в этом во-первых нет необходимости и вы почём зря удлиняете цепочку сертификации. В принципе, иерархии состоящие из более, чем 4-х уровней нежизнеспособны, поскольку CCE (Certificate Chaining Engine) каждый раз будет тратить очень много времени на построение и проверки цепочек сертификатов и из-за таймаутов может давать битые цепочки. Конечно же, за такое вас никто бить по лицу ногами не будет, но таких схем лучше избегать за исключением очень сложных схем, когда используется 2 уровня Policy CA (что подразумевает несколько различных политик сертификаций) и 2 уровня издающих CA. Такое возможно только в больших компаниях и их я не затрагиваю в данном материале. В случае если вам необходимо иметь несколько издающих CA под одним Policy CA, то схему лучше строить вот так, в зависимости от количеста издающих CA:

В первом случае у нас будет простая иерархия с единственным издающим CA, который так же выполняет роль Policy CA и ниже по иерархии ничего нет. Если ВНЕЗАПНО появятся потребности в ещё одном издающем CA, то это решается достаточно путём миграции ко второй схеме. Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Просто при миграции нужно учитывать несколько нюансов и всё. Поэтому с учётом перспективы целесообразно делать такую схему изначально. По большому счёту это наиболее распространённые схемы иерархий PKI.

Время жизни сертификата CA

И ещё один момент, который хочу посмотреть — какой срок действия должен быть у сертификата CA? Вопрос достаточно риторический и зачастую зависит от требования к сроку действия конечных сертификатов. Но обычно используется простая схема:

• конечный сертификат — 3 года;
• Issuing CA — 5 лет;
• 2 Level Policy CA — 10 лет;
• 1 Level Policy CA — 15 лет;
• Root CA — 20 лет.

Т.е. если у вас 2-х уровневая иерархия PKI, то Issuing CA будет на 5 лет, а Root CA на 10 лет. Для 3-х уровневой иерархии Issuing CA на 5 лет, Policy CA на 10 лет и Root CA на 15 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.

Как бы и всё. Данный материал в основном опирается на общие рекомендации и моё личное восприятие этого мира, поэтому готов обсудить альтернативные варианты.