Инфраструктура открытых ключей в Windows Server 2016. Часть 1. Предварительный этап
Внедрение собственной инфраструктуры открытых ключей часто становится одной из задач, которую приходится решать ИТ-отделам предприятия
Причины этого вполне объяснимы: тут и вопросы безопасной аутентификации, защиты передаваемых и хранимых данных, потребность в использовании электронной цифровой подписи и другое. Далеко не всегда эти задачи могут быть решены средствами внешних поставщиков, несмотря на очевидную тенденцию развития облачных решений.
Как бы там ни было, задача внедрения и поддержания собственных инфраструктур осталась, а раз так, то стоит разобраться с особенностями ее внедрения. Впрочем, прежде чем говорить о внедрении, имеет смысл обсудить вопросы правильного использования и проектирования. Журнал не раз затрагивал эту тему в своих публикациях, поэтому мы можем просто сослаться на ранее опубликованную статью, которая поможет читателю ознакомиться с этой темой [1]. Великолепным источником является руководство Брайана Комара [3], которое поможет получить глубокие знания предмета.
Кроме того, разумно ознакомиться и с первоисточником, если мы говорим о внедрении решения на основе PKI Microsoft, так как разработчик предлагает полное руководство по проектированию [2].
Мы же продолжим эту тему рассказом о внедрении инфраструктуры открытых ключей для некоторой организации и предложим читателю некоторый бизнес-кейс из реальной практики, который поможет лучше понять процедуру внедрения и пройти все ее шаги.
Типовой сценарий
Пусть у нас есть организация, имеющая два основных центра обработки данных и несколько филиалов. Современные тенденции ведения бизнеса предполагают наличие не только стационарных пользователей, но и мобильных. Многие сотрудники компании применяют в своей работе не только обычные рабочие места, но и мобильные устройства. Предполагается необходимость взаимодействия с партнерами и заказчиками, с предоставлением им доступа к некоторым ресурсам компании. Служба каталога предприятия традиционно использует службу каталога на основе Microsoft Active Directory Domain Services. Структурная схема типового ЦОД предприятия может выглядеть так, как это показано на рис. 1. Конечно, говоря о центре обработки данных, мы делаем некоторое преувеличение, скорее здесь мы можем говорить о штаб-квартире и крупных филиалах. Поддержка собственного дата-центра в настоящем понимании этого термина оказывается под силу далеко не всем, но в некотором приближении будем считать, что говорим о ЦОД.
Внедрение корпоративной PKI обусловлено ростом потребности в обеспечении безопасности внутри предприятия. Подобное краткое описание нередко оказывается типовой историей для многих компаний. Так как же внедрить PKI для такой организации?
Как я уже упоминал выше, с проектированием решения можно познакомиться в статьях [1] и [2]. Обычно в подобной ситуации мы будем говорить о двухуровневой иерархии, состоящей из корневого отключенного от сети центра сертификации (Stand-Alone Root CA) и подчиненного издающего корпоративного центра сертификации. Не исключено, а скорее всего обязательно будет присутствовать потребность в использовании и публичных удостоверяющих центров, например, для обеспечения возможности работы внешних клиентов компании.
Разумеется, возможны и другие варианты, которые мы обсудим в этом цикле статей, но в качестве, скажем так, типового и наиболее часто встречающегося имеет смысл рассматривать именно этот. Более сложные иерархии с использованием дополнительных уровней иерархии с использованием промежуточных серверов политик Policy CA встречаются только для крупных компаний, где требования к политикам сертификатов могут варьироваться, что и приводит к усложнению структуры. Таким образом, типовая структурная схема может выглядеть так, как это показано на рис. 2.
Предварительный этап
Этап подготовки развертывания, с точки зрения практических аспектов, будет состоять из настройки точек распространения (Distribution Point), добавления дополнительной записи на сервере DNS и подготовки файлов capolicy.inf, определяющих начальную настройку и параметры работы серверов сертификатов. Наиболее часто используемыми точками распространения являются HTTP и LDAP. Первый вариант обусловлен его универсальностью для любого типа клиента, второй – удобством поиска и доступа для типового клиента Active Directory. Соответственно, администратор сталкивается с задачами:
- настройки места хранения файлов сертификатов, списка отзыва и заявления поставщика, прав доступа на этот или эти ресурсы;
- установки и настройки сервера веб для выполнения роли Distribution Point для PKI;
- добавления специальной записи на корпоративном DNS-сервере, которая обеспечит поиск необходимых ресурсов;
- обеспечения отказоустойчивости и доступности как самих издающих серверов сертификатов, так и точек распространения, причем, говоря о них, не следует забывать о необходимости своевременной синхронизации данных между веб-серверами, выполняющими эту роль. Например, публикация нового CRL-файла означает необходимость предоставления доступа к нему с помощью любого сервера веб-фермы, выполняющего роль Distribution Point, но к этому мы еще вернемся несколько позже.
Администратору необходимо создать каталог для хранения вышеуказанных файлов и предоставить к нему доступ требуемым группам пользователей, то есть если предполагается «внутреннее» использование, то выбираются соответствующие группы, обычно речь идет о группе Users, поскольку, как правило, работают с сертификатами все пользователи компании, если же мы говорим о необходимости работы внешних пользователей, то придется использовать группу everyone.
Кроме того, встроенной группе Cert Publishers [4] необходимо предоставить права для изменений внутри этой папки. Это требуется для правильного подхода при построении строгой ролевой модели.
На веб-сервере создается виртуальный каталог, указывающий на соответствующий ресурс в хранилище. Необходимо удостовериться в том, что активна опция Directory Browsing (см. рис. 3), и если предусматривается использование разностных списков отзыва (Delta CRL), которые в имени файлов используют символ «+», то потребуется обеспечить так называемый Double Escaping, что также подразумевает дополнительную настройку на веб-сервере (см. рис. 4).
Наконец, необходимо создать на сервере DNS запись CNAME [5], которая позволит клиенту находить требуемый ресурс (см. рис. 5).
Следующий шаг предварительного этапа настройки – подготовка файла начальной конфигурации удостоверяющего центра – capolicy.inf [6].
Файл capolicy.inf
Если нас не устраивают параметры по умолчанию, а обычно они нас не устраивают, нам нужно создать файл capolicy.inf на всех удостоверяющих центрах еще до развертывания самой службы сервера сертификатов. Именно этот файл и будет определять параметры начальной настройки, а также параметры поведения при обновлении сертификата самого сервера сертификатов. Этот файл обязательно должен быть размещен в папке %Systemroot% (обычно это C:\Windows) еще до установки сервиса. Использование иного имени или места размещения приведет к игнорированию этого файла, и сервер сертификатов будет установлен с параметрами «по умолчанию».
Рассмотрим структуру и внутреннее содержание файла. Capolicy.inf состоит из нескольких разделов.
- Version – семейство используемой операционной системы удостоверяющего центра
- PolicyStatementExtension – заявление поставщика
- BasicConstrainsExtension – ограничение глубины иерархии УЦ
- EnhancedKeyUsageExtension – ограничение на выдаваемые типы сертификатов
- Certsrv_server – параметры обновления сертификата, настройки сертификата УЦ, параметры обновления и срок жизни сертификата, период публикации списка отзыва
Version
Первый раздел [Version] содержит одну строку, говорящую о том, что используется формат Windows NT, он-то нам и нужен, если мы базируемся на Windows Server. Эта строка будет всегда присутствовать в файле, и неважно какой УЦ (корневой или подчиненный) мы разворачиваем.
PolicyStatementExtention
В этом разделе указан путь к заявлению поставщика (Certification Practice Statement или CPS) и определены политики, которые служат для безопасности.
Certification Practice Statement – просто документ, который можно загрузить по заданной ссылке, чтобы с ними ознакомиться. В нашем примере это файл cps.txt.
Обычно в нем указывается, какие меры обеспечения безопасности работы сервиса предприняты его владельцем. В сущности, это своего рода соглашение между потребителем и владельцем сервиса. Наличие этого раздела необязательно с точки зрения функционирования сервера, но правила хорошего тона подразумевают необходимость что-то рассказать о себе.
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://pki.nwtraders.msft/PKI/cps.txt
Внутри политики содержится Object identifier (OID). Мы не будем останавливаться на этом подробно. С OID вы можете познакомиться по следующей ссылке: https://www.networkworld.com/article/2231566/microsoft-subnet/obtaining-an-oid-for-a-certificate-issuing-policy--capolicy-inf----.html.
В нашем примере OID предоставлен Microsoft: https://technet.microsoft.com/en-us/library/jj125373%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396.
EnhancedKeyUsageExtension
В разделе EnhancedKeyUsageExtension можно ограничить применимость сертификатов, издаваемых центром сертификации. Пример такого раздела представлен ниже.
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
OID = 1.3.6.1.5.5.7.3.4 ; Secure Email
Перечисляется, какие сертификаты может выдавать данный центр сертификации.
В сертификате это выглядит так, как это представлено на рис. 6.
Дополнительную информацию по данному разделу можно найти по ссылке: https://technet.microsoft.com/en-us/library/cc725621%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396 описание Application Policies.
Конечно, этот раздел не обязателен, по умолчанию центр сертификации может выпускать любые типы сертификатов.
BasicConstraintsExtension
В разделе BasicConstraintsExtension можно ограничить глубину иерархии центров сертификации, так, например, раздел может иметь следующий вид:
[BasicConstraintsExtension]
Pathlength=1
Это означает, что после этого центра сертификации может быть только один уровень подчиненных. Если ограничение иерархии не требуется, то раздел BasicConstraintsExtension должен иметь вид:
[BasicConstraintsExtension]
Pathlength=0
Не стоит ограничивать глубину иерархии удостоверяющих центров на корневом, поскольку это приводит к снижению гибкости инфраструктуры. Время жизни инфраструктуры обычно весьма значительно, и за этот период многое может измениться. В трехуровневой иерархии центров ее глубина может быть ограничена, например, на втором уровне, и, если даже раздел BasicConstraintsExtension будет отсутствовать в файле УЦ capolicy.inf третьего уровня (издающем), выдать сертификат еще одному УЦ с него будет нельзя. При попытке обработать запрос нижестоящего центра сертификации на получение им сертификата будет выдаваться сообщение об ошибке.
certsrv_server
В разделе certsrv_server представлены параметры сертификата самого удостоверяющего центра.
- RenewalKeyLength=4096 – указатель размера ключа центра сертификации, в нашем случае 4096 бит.
- RenewalValidityPeriodUnits=20 – устанавливается срок действия сертификата УЦ (20 лет).
- RenewalValidityPeriod=Years – устанавливаются единицы измерения для параметра RenewalValidityPeriodUnits.
- CRLPeriodUnits=26 – устанавливается периодичность публикации CRL-сертификата УЦ (в представленном примере 26 недель).
- CRLPeriod=Weeks – устанавливаются единицы измерения для параметра CRLPeriodUnits.
- CRLOverlapUnits=2 – устанавливается время, в течение которого CRL еще действительны, после наступления момента публикации следующего CRL. Дополнительное время действия CRL, а следовательно, валидности сертификата.
- CRLOverlapPeriod=Weeks – устанавливаются единицы измерения для параметра CRLOverlapUnit.
- CRLDeltaPeriodUnits=0 – устанавливается периодичность публикации Delta CRL, 0 означает, что публикация производиться не будет.
- CRLDeltaPeriod=Hours – устанавливаются единицы измерения для параметра CRLDeltaPeriodUnits
- LoadDefaultTemplates=0 – 0 означает, что не нужно производить публикацию шаблонов сертификатов, а следовательно, не будет производиться выдача сертификатов на основе этих шаблонов (в том числе автоматическая).
- AlternateSignatureAlgorithm=1 – настройка УЦ для включения улучшенного алгоритма шифрования, включение поддержки стандарта PKCS#1 V2.1 [7], используемого при подписи сертификата и создании запросов. Нужно учитывать, что данный стандарт не поддерживается старыми операционными системами, такими как Windows 2000, Windows XP, Windows Server 2003.
Ниже представлены примеры содержимого файлов capolicy.inf для двухуровневой архитектуры PKI корневого и издающего удостоверяющих центров
Корневой УЦ
[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://pki.nwtraders.msft/PKI/cps.txt
[BasicConstraintsExtension]
Pathlength=1
[certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=Years
CRLPeriodUnits=26
CRLPeriod=Weeks
CRLOverlapUnits=2
CRLOverlapPeriod=Weeks
CRLDeltaPeriodUnits=0
CRLDeltaPeriod=Hours
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
Подчиненный издающий УЦ
[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
URL=http://pki.nwtraders.msft/PKI/cps.txt
[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=Years
CRLPeriodUnits=1
CRLPeriod=Weeks
CRLOverlapUnits=1
CRLOverlapPeriod=Days
CRLDeltaPeriodUnits=1
CRLDeltaPeriod=Days
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
Продолжение следует.
- Шапиро Л. Проектирование инфраструктуры открытых ключей. Часть 1. Теоретические основы. // «Системный администратор», № 10, 2010 г. – С. 80-87. URL: http://samag.ru/archive/article/1132.
- Brian Komar Windows Server 2008 PKI and Certificate Security.
- Active Directory Certificate Services (AD CS) Public Key Infrastructure (PKI) Design Guide – https://social.technet.microsoft.com/wiki/contents/articles/7421.active-directory-certificate-services-ad-cs-public-key-infrastructure-pki-design-guide.aspx.
- Configure Certificate Publishing in Active Directory Domain Services – https://technet.microsoft.com/en-us/library/cc730861(v=ws.11).aspx.
- Add an Alias (CNAME) Resource Record to a Zone – https://technet.microsoft.com/en-us/library/cc772053(v=ws.11).aspx.
- Prepare the CAPolicy.inf File – https://technet.microsoft.com/en-us/library/jj125373(v=ws.11).aspx.
- Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 – https://www.ietf.org/rfc/rfc3447.txt.
Ключевые слова: инфраструктура открытых ключей, Windows Server 2016.