Contents of this directory is archived and no longer updated.

КДПВВ разных интернетах ходят разные толки по поводу Policy CA. В своё время я давал краткую справку о нём: Обсуждение схем иерархии Certification Authority и есть необходимость немного дополнить ту статью и показать применением выделенного Policy CA в реальном мире. Назначение Policy CA вполне понятно — разделять PKI на одну или несколько веток, которые будут различаться правилами выдачи и обслуживания сертификатов. Интернеты (и разные там специалисты) всячески рекомендуют деплоить 3-х уровневые иерархии вида:

Offline Root CA
           Offline Policy CA
                      Online Issuing CA

Это считается бест-практисом. Отдельные люди указывали мне, что совмещение ролей (Policy и Issuing) не есть хорошо по причине безопасности и всё такое. Но если говорить о бест-практисах, то их здесь нету совсем. Есть только некоторые рекомендации, по которым можно подобрать себе оптимальную иерархию. Всё остальное является следствием буйной фантазии. Давайте ещё раз пробежимся по этим моментам.

Когда применяем 1-уровневую иерархию?

Если у вас небольшая компания (скажем, человек 10-100) без особых требований к PKI, вы спокойно разворачиваете одноуровневую иерархию с Online Root CA и используете сертификаты для логона (VPN, IIS и/или применяете смарт-карты) или шифруете данные. Как пример. Хоть я в предыдущей статье весьма критически относился к такому решению, оно в реальном мире вполне себе жизнеспособно (опыт иногда меняет отношение к каким-то вопросам в ту или иную сторону). Не потому что она ВНЕЗАПНО стала безопасной, а потому что это элементарно выгодней, чем покупать отдельное железо и лицензию Windows Server, даже если посчитать все риски. Плюс, экономия на административных издержках. Т.е. это случаи, когда компрометация PKI не ведёт к краху всего бизнеса, хотя это не очень приятно.

Для сравнения можно представить, сколько администраторов не делает бакупов. Бакупы — это вообще отдельная тема и ситуация с ними катастрофическая. Вы просто не представляете сколько компаний не делают бакупы. А когда один единственный (или парочка) выходят из строя, теряя всю финансовую отчётность и вообще всё, чем занималась компания — этот фейл более реальный и более эпический.

Когда применяем 2-уровневую иерархию?

Если вы интегрируете PKI в свою сеть более тесно (вы внедряете цифровые подписи, устанавливаете VPN между сайтами, появляются удалённые SCCM/OpsMgr клиенты и т.д.), вы скорее всего будете более благоразумны и примените 2-х или 3-х уровневую иерархию. На этом этапе у вас PKI может начать делиться, потому что сферы применения PKI становятся шире. И вот здесь может появиться желание вбахать выделенный Policy CA, который опишет политику применения (CPS) сертификатов в вашей организации. С одной стороны это выглядит идеологически правильно. Но с другой стороны это не очень практично. Дело в том, что CPS можно прикрутить и к издающим CA, совместив роль Policy и Issuing CA. Об этом я уже писал в предыдущей статье.

Даже если у вас на уровне шаблонов сертификатов действуют разные политики, их вполне возможно описать в пределах одного CPS. Политики на уровне шаблонов могут быть очень разнообразные: например, чтобы получить сертификат для шифрования данных достаточно залогониться в систему. А чтобы получить логонный сертификат на смарт-карте, нужно оформить соответствующую заявку и нотариально заверить у руководителя отделом. Для получения сертификата цифровой подписи (для подписи документов), нужно в должности быть руководителем какого-то отдела. Это наиболее распространённые примеры из реальной жизни.

Учитывая, что в этих случаях у вас будет один CPS, вы можете на уровне издающего CA применить OID = All Issuance Policies (2.5.29.32.0) в CAPolicy.inf:

[PolicyStatementExtension]
Policies = SomeCPS

[SomeCPS]
URL = Some URL 
OID = 2.5.29.32.0

Т.е. CA может выдавать сертификаты с использованием любых политик выдачи и использования сертификатов, которые более конкретно определены в CPS. Так же, данный сценарий позволяет провести последующую кросс-сертификацию с другой PKI (см. Что в OID'е тебе моём?). Если CA может издавать сертификаты только по конкретным политикам, вы можете ограничить CA только ими, применив следующий шаблон для CAPolicy.inf:

[PolicyStatementExtension]
Policies = CPS1, CPS2, CPS3

[CPS1]
URL = URL1
OID = 1.3.6.1.4.1.12345.1

[CPS2]
URL = URL2
OID = 1.3.6.1.4.1.12345.2

[CPS3]
URL = URL3
OID = 1.3.6.1.4.1.12345.3

В результате, CA сможет выдавать сертификаты на основе тех шаблонов (здесь я имею ввиду применение в Windows PKI), где эти политики определены.

Заметка: всякие верисайны, тафты и прочие коммерческие CA как правило применяют 1-2 уровневые (хотя есть и 3-х уровневые) иерархии. Но у них специфика другая.

Если всё так просто умещается в 2-х уровневой иерархии, когда же нам может понадобиться выделенный Policy CA?

Когда применяем 3-х уровневую иерархию?

Наконец-то добрались до цели нашей экскурсии. В реальной жизни выделенный Policy CA потребуется только когда у вас будут две и более совершенно разных политик выдачи и использования сертификатов. Наиболее классический случай — когда вы ведёте бизнес в разных странах.

Например, в России у вас головной офис, а в Европе у вас находится филиал. В этом случае у вас скорее всего политики выдачи для родной страны и Европы будут очень сильно отличаться, потому что законодательства в этих странах тоже разные. Но и здесь возможны варианты. Если все CA находятся в головном офисе (и европейский офис подключается к головному через VPN), вы можете рассмотреть предыдущий раздел. Это означает, что вы сделаете 2 издающих CA: один для локального офиса, второй для европейского. Естественно, на каждом CA будут описаны различные политики сертификатов.

Если же в европейском филиале находится свой CA и им управляет местный персонал, тогда понадобится выделенный Policy CA. Т.е. вы в головном офисе установите Policy CA, ограничите его на уровне CPS и тогда европейский офис может спокойно управлять своими издающими CA без риска нарушить политики сертификатов. При этом, для головного офиса вы можете использовать 2-х уровневую иерархию. Разумеется, в этом случае для Policy CA вы не сможете использовать All Issuance Policies, а нужно применить свой кастомный OID (или несколько, см предыдущий раздел).

Схожий сценарий: у вас есть большое количество филиалов, в каждом установлен свой издающий CA (но все они подчинаются одному корневому CA), т.к. интернеты между ними не очень шустрые и стабильные. И каждым CA в филиале управляет своя команда администраторов. В этом случае есть смысл (но совершенно не обязательно) под корнем установить Policy CA, на нём определить CPS и уже под ним размещать издающие CA филиалов. В этом случае от администраторов филиалов не требуется лишних телодвижений по прописыванию CPS в CAPolicy.inf, потому что CPS определённые на Policy CA будут наследоваться на сертификаты издающих CA.

Следующий сценарий, более специфический: вы хотите сделать root signing. Root signing — это когда коммерческий CA (VeriSign, Thawte, etc) выдаёт сертификат для вашего CA. В этом случае вы исключаете проблему организации доверия вашим сертификатам, потому что все сертификаты в этом случае будут заканчиваться корневым CA верисайна или какого-нибудь другого well-known коммерческого CA. В этом случае коммерческий CA выдаст сертификат для вашего выделенного Policy CA, который не может быть совмещён с издающим (это одно из требований к root signing).

Ещё один специфический сценарий: в вашей компании несколько лесов Active Directory. Если вы не применяете cross-forest enrollment, вам вероятнее всего придётся сделать выделенный Policy CA, который определит общую политику сертификатов для всех лесов Active Directory. И в каждом лесу уже устанавливаете издающие CA. Если же каждый лес будет иметь свой независимый набор политик сертификатов, можно ограничиться двумя уровнями.

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

Итоги

Про 4-х уровневую иерархию я ничего рассказывать не буду, потому что не посчастливилось лицезреть такое. Если что, можете прочитать об этом в книге Комара —http://www.sysadmins.lv/pkibookshelf.aspx. А мы, в свою очередь, немного освежили память об иерархиях в PKI и более детально рассмотрели некоторые аспекты, касающиеся Policy CA и разрушили миф о бест-практичности 3-х уровневой иерархии. Т.е. каждая PKI строится с учётом требований бизнеса и управления, а не бизнес и управление строятся под конкретную выбранную иерархию и этот пост лишь раскрывает некоторые аспекты, которыми можно руководствоваться для проектировании PKI.

В любом случае, как сделаете — так и будет хорошо. Лишь бы вы (как проектировщик PKI) подошли к делу с головой и ваше решение заработало, как запланировало.


Share this article:

Comments:

Comments are closed.