Часть № 1
Теоретические основы.

Безопасность сети формируется из комплекса элементов, один из важнейших – инфраструктура открытых ключей. Теоретические основы проектирования PKI [1] рассматривается в этой статье.

Введение. Знакомство с ключевыми понятиями.

Полагаю, что всем хорошо известно: внедрение инфраструктуры открытых ключей все чаще становится насущной необходимостью огромного числа компаний.
Требуется обеспечить конфиденциальность переписки, есть необходимость зашифровать данные пользователя, внедрить мультифакторную аутентификацию при доступе пользователей к службам каталога, решить вопрос безопасной аутентификации в беспроводных сетях, реализовать безопасный обмен информацией по сети, и. т. д.
Все эти задачи решаются на основе технологий асимметричной криптографии.
Windows Server 2012 предоставляет все возможности для решения перечисленных выше задач.
В своей статье я хотел бы: рассмотреть различные виды иерархий удостоверяющих центров, выяснить в каком случае следует отдавать предпочтение тому или иному варианту, определить какая информация нам потребуется для проектирования.
Для обеспечения возможности использования криптографии с открытым ключом, необходимо гарантировать, что каждый закрытый и открытый ключ управляется корректным образом.
Инфраструктура открытых ключей (PKI) — инфраструктура, предназначенная для управления открытыми ключами и сертификатами с целью поддержки услуг аутентификации, шифрования, целостности и неотрицания авторства.
Открытый ключ, связанный с определенным пользователем, должен быть удостоверен сертификатом, подлинность которого должна проверяться доверенным учреждением — Центром Сертификации (Certification Authority).
Другой термин, принятый для именования такого объекта — Удостоверяющий Центр (УЦ). По сути, такое именование более корректно, однако менее распространено в технической литературе.
Сертификат открытого ключа — структура данных, состоящая из раздела данных и раздела подписи. В первом содержатся открытые данные, включающие, как минимум, открытый ключ и строку, идентифицирующую сторону (представляемый объект). Во втором — цифровая подпись органа сертификации. На практике наиболее часто используются сертификаты формата Х.509.
Термин «инфраструктура открытых ключей» встречается довольно часто как в технической литературе, так и в документации по продуктам. Можно сказать, что инфраструктура открытых ключей представляет собой совокупность цифровых сертификатов, центров регистрации и удостоверяющих центров, цель которых проверка подлинности участников обмена зашифрованными сообщениями.
Собственно говоря, инфраструктура открытых ключей определяет механизмы подтверждения того, что участник безопасности, например, пользователь, взаимодействующий с другими, является именно тем, за кого он себя выдает.
Реализации PKI могут быть как простыми, так и сложными. Таким образом, каждая организация, планирующая развертывание указанных служб, должна разобраться в существующих сценариях внедрения и принять решения, какой вариант использовать для решения собственных задач.
Windows 2012 также как и предыдущие версии операционных систем, имеет в своем составе Удостоверяющий Центр.
Эта служба отвечает за создание сертификатов, проверку их подлинности и последующее управление.
Удостоверяющий Центр (УЦ). Центр сертификации (CA) — доверенная третья сторона, чья подпись под сертификатом подтверждает подлинность открытого ключа, связанного с представляемым объектом.
Простейшую модель PKI можно построить из одного компонента, называемого издателем (Issuer), который выполнял бы все необходимые функции. Пользователи использовали бы криптографию с открытым ключом в своих приложениях через получение и обработку сертификатов и списков отзыва сертификатов (CRL) [2].
Сложно обеспечить в рамках одного сервера необходимый уровень защищенности при выполнении всех задач, связанных с созданием и распространением сертификатов и CRL. Поэтому обычно PKI представляет собой более сложную структуру, каждый из элементов, которой предназначен для выполнения специализированных функций.
Функции Удостоверяющего Центра

1. Список функций Удостоверяющего Центра может показаться не слишком значительным, однако важность их весьма существенна.
2. Подтверждение аутентичности объекта, запрашивающего сертификат. Механизмы проверки зависят от типа CA
3. Выдача сертификатов. Информация в сертификате определяется его шаблоном.
4. Управление отзывом сертификатов. Список отзыва сертификатов (CRL) гарантирует невозможность использования «неправильных» сертификатов.

• Принятие решения о структуре Удостоверяющих Центров (выбор иерархии) – задача, которая требует вдумчивого отношения, так как неправильный выбор может привести к серьезным проблемам в области безопасности. Отдавая предпочтение тому или иному варианту архитектуры, учитывают следующие факторы: потребности приложений, необходимый уровень безопасности, бизнес-требования компании.
• В результате проектирования инфраструктуры PKI необходимо определить:
• Кол-во уровней иерархии и структуру УЦ;
• Типы используемых цифровых сертификатов;
• Виды УЦ, работающих на каждом из уровней иерархии;
• Необходимость интеграции со службой каталога;
• Методы защиты УЦ;
• Потребности в различных политиках сертификатов.

Итак, сколько же уровней иерархии использовать? Какое количество УЦ расположить на каждом из уровней иерархии?

Модели иерархий УЦ и критерии выбора

Одноуровневая модель

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

Двухуровневая модель

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


При этом на издающие УЦ ложится функционал по управлению политиками сертификатов. Для обеспечения безопасности инфраструктуры корневой центр является отдельностоящим (stand-alone) и автономным (offline), то есть не входит в состав домена не подключается к сети предприятия, и, практически, постоянно находится в отключенном состоянии. Тем самым, мы избегаем атак на корневой сервер. Что касается издающих центров, то они получают сертификат, подписанный корневым сервером, которому доверяют все участники взаимодействия, то есть обладатели сертификатов, полученных с любого УЦ предприятия.
Для повышения уровня доступности и отказоустойчивости сервиса предусматривается развертывания более чем одного издающего сервера. Что касается количества издающих центров, то оно определяется бизнес-требованиями компании. Необходимо также предусмотреть отказоустойчивость списков отозванных сертификатов. Чуть позже мы рассмотрим механизмы решения проблемы отказоустойчивости.

Трехуровневая модель

Трехуровневая архитектура обеспечивает наилучшие характеристики безопасности, масштабируемости инфраструктуры. В этом варианте осуществляется развертывание корневого центра на отдельностоящем сервере, не входящем в состав корпоративной сети.
Дополнительно выполняется внедрение серверов политик (Policy CA), являющихся подчиненными к корневому УЦ. Эти серверы, также, не входят в состав корпоративной сети, и являются отдельностоящими. И корневой, и подчиненные ему Policy CA, являются отключенными (Offline). Издающие сертификаты серверы являются подчиненными к Policy CA и могут быть как корпоративными (Enterprise), так и отдельностоящими (Standalone). См. рис. 2.

Рекомендуется использовать трехуровневую архитектуру в следующих ситуациях:

• Компания предъявляет высокие требования к безопасности. За счет использования отключенных УЦ, удается избежать сетевых атак.
• Существует потребность в различных политиках сертификатов. Например, в зависимости от принадлежности к тому или иному филиалу предъявляются различные требования к используемым сертификатам.
• Есть необходимость в раздельном управлении, например поддержка УЦ и управление сертификатами для представительств компании в Москве и Петербурге должна осуществляться разными командами.

Четырехуровневая модель

В ряде случаев может потребоваться более сложная модель, состоящая из 4-х уровней иерархии. Пример такой модели показан на рис. 3, однако, следует иметь ввиду, что такой вариант архитектуры более сложен в реализации. И, как правило, трех уровней иерархии будет достаточно. Реализация моделей, состоящих из более, чем 4-х уровней, не рекомендуется Microsoft ввиду ее избыточной сложности и неочевидной полезности.

Особенности выбора архитектуры издающих центров

Выбор структуры издающих УЦ определяется исходя из следующих факторов:
Количество издаваемых сертификатов.
Чем большее количество сертификатов выдается пользователям, компьютерам, службам, сетевым устройством, тем больше издающих серверов вам может потребоваться. Кроме того увеличение числа издающих центров, приводит к повышению отказоустойчивости, так как при выходе из строя одного сервера, сертификат может быть запрошен у другого.
Требования доступности для пользователей.
Если компания представляет собой географически распределенную структуру, то появляются линии связи глобальных вычислительных сетей. Следовательно, повышается вероятность перебоев в работе сети. Поэтому, для снижения влияния особенностей сети на возможности пользователей работать с сертификатами, имеет смысл размещать издающие УЦ на всех основных географических площадках.
Модель администрирования инфраструктуры открытых ключей.
В ряде компаний для администрирования разных приложений, связанных с PKI, используются разные команды специалистов. Например, за безопасный почтовый обмен в организации отвечает одна группа, а за VPN доступ другая. Это может потребовать использования разных серверов для обеспечения разделения ролей.
Структура компании.
Довольно часто, компания, в которой требуется внедрить инфраструктуру PKI, представляет собой холдинг, объединяющий несколько автономных предприятий. Которые при этом могут иметь потребность во взаимодействии и общие цели. Например, речь может идти об издательском холдинге, объединяющем, собственно, издательство и компанию с сетью книжных магазинов в разных городах. В данном случае мы можем рассматривать вариант использования двух Policy CA, соответственно определяющих политику сертификатов для каждой из компаний, входящих в состав холдинга, и нескольких выдающих сертификаты серверов, подчиненных соответствующим Policy CA. Критерии для выбора подчиненных издающих УЦ могут быть различными, например, в основу может быть положен принцип ролевого или функционального разделения.
Что влияет на выбор архитектуры PKI?
Сложно предложить простой алгоритм для выбора того или иного вида архитектуры PKI, однако мы можем привести факторы, влияющие на нее.
Одним из них является географическое распределение площадок организации. Очевидно, что размещение издающих серверов сертификатов на каждой площадке, повышает доступность системы в целом.
Принятая модель управления безопасностью оказывает влияние на иерархию УЦ, например, при децентрализованной схеме, может потребоваться большее количество серверов.
Различные требования законодательства также оказывают влияние на инфраструктуру PKI, например, для финансового банковского сектора могут существовать специализированные правила к длине ключа, к криптопровайдеру, и. т. п., что влияет на политики сертификатов.
Перед началом процесса проектирования инфраструктуры PKI, необходимо провести соответствующий аудит организации. Следует выяснить какие приложения, будут использовать PKI, понять какие ограничения безопасности и бизнес требования существуют в компании, определиться с вопросами обеспечения надежности и отказоустойчивости системы.

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

Список литературы

[1] Brian Komar Windows Server 2008 PKI and Certificate Security
[2] www.microsoft.com/pki
[3] technet.microsoft.com/en-us/magazine/2009.05.pki.aspx
[4] www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part1.html
[5] www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part2.html
[6] www.verisign.com

[1] PKI — Public Key Infrastructure (Инфраструктура Открытых Ключей)
[2] CRL – Certificate Revocation List (Список отозванных сертификатов)

Статья опубликована в журнале «Системный Администратор»