Проектирования Инфраструктуры Открытых Ключей.
Часть № 2

Исходная информация, требуемая при проектировании

Какие приложения требуют наличия PKI?
Мы говорим о потребности внедрения инфраструктуры PKI, когда речь идет о приложениях, требующих ее наличия. Что же это за приложения?

Если нам необходимо

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

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

Требования безопасности

При разработке политики безопасности организации следует учитывать и требования, которые должны предъявляться к инфраструктуре PKI.
Одним из ключевых аспектов защиты является обеспечение физической безопасности отключенных (Offline) Удостоверяющих Центров. Речь идет о Root и Policy CA. Обычно для этих целей просто снимаются диски указанных серверов и помещаются в сейф.
Тем самым, обеспечивается возможность использования оборудования для других целей при сохранении безопасности хранимых данных. Безопасность издающих центров, работающих непосредственно в сети компании, обеспечивается следующим образом:

• Необходимо разместить серверы в специально отведенном для этих целей помещении, физический доступ в которое разрешен специально выделенному кругу лиц;
• Не использовать совмещение ролей на таких серверах, так как это снижает безопасность системы.
• В ряде организаций, использующих строгую политику безопасности, целесообразно дополнительно обеспечить защиту ключей УЦ, прибегнув к хранению их не на жестком диске сервера, куда они помещаются по-умолчанию. В качестве такого хранилища рекомендуется использовать специализированный аппаратный модуль HSM (hardware security module), обеспечивающий надежное и безопасное хранение ключей. Преимуществами такого решения, является хранение ключевой информации непосредственно на плате, надежный безопасный канал обмена, защита криптографических ключей от различного вида атак.

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

Технические требования

Технические требования также оказывают влияние на архитектуру инфраструктуры открытых ключей. К техническим требованиям относятся:

• Требования ролевого разделения пользователей на сервере сертификатов;
• Требования к отказоустойчивости серверов;
• Срок жизни сертификата открытого ключа;
• Длина ключа;
• Параметры публикации сертификата УЦ и списков отзыва сертификатов.

Служба сертификации Windows Server 2012 предоставляет возможность определения ролей на каждом сервере сертификатов. Если возникает потребность в делегировании определенных полномочий на уровне площадки или офиса, то, следует рассмотреть возможность размещения издающего сервера на соответствующем уровне и выполнить делегирование полномочий требуемым группам пользователей.
Сервер сертификатов Windows 2012 предоставляет нам определенный набор стандартных ролей, которые могут быть нами использованы для делегирования полномочий.
CA Administrator – администратор УЦ. Обладание этой ролью предусматривает возможности по управлению конфигурацией УЦ, включая настройку параметров службы и назначение менеджеров сертификатов. Назначение этой роли осуществляется посредством назначения прав Manage CA на УЦ. Для этого откройте консоль сервера сертификатов «Start->Administrative Tools ->Certification Authority». Выберите требуемый УЦ, нажмите правую клавишу мыши и выберите пункт «Properties». В открывшемся окне перейдите на вкладку «Security» и добавьте в список группу, права которой вы делегируете. Назначьте ей право «Manage CA».

См. рис 4.


Certificate Manager – пользователи, обладающие этой ролью, отвечают за управление сертификатами (выдача, отзыв, удаление). Кроме этого, у них есть возможность извлечения частного ключа при процедурах восстановления (функционал агентов восстановления ключей). Роль назначается с помощью задания разрешения «Issue and Manage Certificates» на УЦ. Чтобы это сделать, откройте консоль сервера сертификатов «Start->Administrative Tools ->Certification Authority». Выберите требуемый УЦ, нажмите правую клавишу мыши и выберите пункт «Properties». В открывшемся окне перейдите на вкладку «Security» и добавьте в список группу, права которой вы делегируете. Назначьте ей право «Issue and Manage Certificates».
См. рис 5.


Backup Operators. Роль этих пользователей – выполнение процедур резервного копирования и восстановления БД сервера сертификатов и его конфигурации. Назначение этих полномочий может быть осуществлено с помощью локальных или групповых политик (Backup files and directories, Restore file and directories). Для этого необходимо в консоли управления групповыми политиками GPMC [3] выбрать требуемый объект групповой политики раздел Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment->Backup up files and directories и добавить требуемую группу. См. рис. 6.



Auditors – задача этой роли выполнение процедур аудита УЦ, назначение этой роли выполняется с помощью локальных или групповых политик (Manage Auditing and Security Logs). Этот также выполняется в консоли управления групповыми политиками. Откройте GPMC выберите требуемый объект групповой политики раздел Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment->Manage auditing and security log и добавьте требуемую группу. См. рис. 7.



Предусматривается возможность задания ролей индивидуально для каждого из УЦ. Windows 2012 дает возможность жесткого разделения ролей, то есть обладая одной ролью, теряется возможность обладания другой.
При проектировании инфраструктуры PKI не следует забывать о надежности ее функционирования. Здесь мы можем рассмотреть решение на основе отказоустойчивого кластера серверов УЦ или, как более простой вариант, использовать отказоустойчивые дисковые массивы. Разумеется, требования к издающим online CA с точки зрения отказоустойчивости выше, чем к offline CA, где, в сущности, нам будет достаточно обычного резервного копирования. Это может быть выполнено как с помощью консоли управления сервера сертификатов (тогда речь идет о сохранении базы данных сервера, ключей и настроек службы), так и с помощью копирования встроенными средствами операционной системы (Windows Server Backup). В этом случае, может быть сохранена не только информация, относящаяся к функционированию PKI, а полностью все содержимое сервера).
Срок жизни сертификата определяется его шаблоном. Изменение этого параметра после выдачи невозможно.
При определении сроков жизни, следует иметь ввиду, что для выдаваемого сертификата недопустимо превышать срок жизни сертификата УЦ.
Целесообразно, чтобы срок жизни сертификата УЦ, по меньшей мере, в два раза превосходил этот параметр для выдаваемых им сертификатов. Рекомендуется проводить обновление сертификата УЦ по истечении половины срока жизни.
При обновлении сертификата УЦ допустимо придерживаться двух стратегий:

Сохранение исходного частного ключа на весь период жизни УЦ.
Замена частного ключа при обновлении сертификата УЦ.

Срок жизни корневого УЦ должен быть в два раза больше, чем у Policy CA.
Например, RootCA – 20 лет, PolicyCA – 10 лет, IssuingCA – 5 лет.
Не следует задавать срок жизни корневого CA более чем 20 лет, так как большие сроки увеличивают вероятность компрометации ключа.
При выборе длины ключа, основным ограничивающим фактором являются возможности приложений по работе с ключом определенной длины. В любом случае для повышения уровня безопасности рекомендуется использовать длинные ключи. В частности MS-PKI поддерживает ключи до 4096 бит. Имеет смысл использовать ключи размером 4096 бит для RootCA и PolicyCA. Для IssuingCA в целях совместимости можно предложить использовать ключи длиной 2048 бит.
Не следует забывать о защите частного ключа. Существует ряд подходов к решению этой проблемы. По умолчанию УЦ использует Microsoft собственный криптопровайдер и защищает его закрытый ключ УЦ с помощью встроенных API защиты данных (DPAPI). Это создает проблему с точки зрения безопасности, поскольку все члены группы локальных администраторов обладают возможностью доступа к закрытому ключу УЦ и любой член этой группы имеет возможность выполнить экспорт закрытого ключа и тем самым создать новые поддельные центры, который смогут выдавать поддельные сертификаты. Более надежными способами хранения частных ключей являются использование смарт карты или токена, использование зашифрованных виртуальных машин, и, наконец, применение аппаратных модулей безопасности (HSM).
Следует найти баланс требований безопасности с затратами на внедрение более защищенных решений. Положительные и отрицательные стороны того или иного варианта вы можете увидеть таблице. См. Рис. 8.



Последний раздел технических требований к инфраструктуре открытого ключа — расположение списков отзыва сертификатов (CRL) и сертификатов УЦ.
Допускается использование следующих протоколов для доступа к точкам распространения:

HTTP;
LDAP (обычно речь идет о Active Directory Domain Services);
FTP;
File share (SMB);

Основными являются протоколы HTTP и LDAP, именно их следует рассматривать.
HTTP подходит как для внешних, так и для внутренних точек публикации, поскольку временные задержки между временем публикации и тем моментом, когда эта информация становится доступной для пользователей, минимальны. Как только опубликован новый список отзыва сертификатов или обновленный сертификат, пользователи могут загружать эту информацию. Кроме того, нельзя не отметить, возможность без каких бы то ни было трудностей разместить точку публикации списка отзыва и сертификат за брандмауэром, используя доступ только по 80 порту. И наконец, такое решение универсально, так как не требует клиента службы каталога. (Это может быть актуальным для старых версий операционных систем Microsoft и для клиентов на основе иных систем.)
Протокол LDAP предоставляет возможности поиска для клиентов AD. Таким образом, в основном речь идет о внутренних клиентах сети, так как если планируется предоставлять возможность внешним клиентам, использовать LDAP, то потребуется предоставить возможность выполнения LDAP запросов к службе каталога.
Временные задержки между публикацией списка отзыва и моментом его доступности зависят от структуры репликации службы каталога, особенно когда мы говорим о многосайтовых структурах. Кроме того, следует учитывать что если первым в списке стоит LDAP путь, а клиент не поддерживает такие запросы, то прежде чем клиент получит доступ к точке распространения, используя другой способ, пройдет 10 секунд.
Принимая решение о том, какой способ публикации выбрать, следует учесть:

• необходимую частоту публикации,
• возможности по прохождению через брандмауер,
• используемую клиентом операционную систему.

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

Бизнес требования

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

Рассмотрим примеры таких ситуаций:

Требуется, чтобы сторонняя организация могла использовать сертификаты сотрудников исходной.
Существуют различные решения для такого сценария.
Вполне допустимо не разворачивать внутренний УЦ, а воспользоваться сертификатами, полученными от внешнего коммерческого УЦ, например VeriSign [6] Другой вариант: настроить кросс сертификацию между исходной структурой и сторонней организацией.

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

Требования законодательства

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

Выводы

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

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

[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

[3] Здесь и далее приводится пример назначения роли с помощью групповой политики, однако следует иметь в виду, что такое назначение роли выполняется также и с помощью политик локальных, действующих только на указанный сервер, что в ряде ситуаций является предпочтительным способом.

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