Главная Networks, Security, Windows Внедрение Инфраструктуры Открытых Ключей на основе Windows Server 2016
  • Внедрение Инфраструктуры Открытых Ключей на основе Windows Server 2016

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

    Как бы там ни было, задача внедрения и поддержания собственных инфраструктур осталась, а раз так, то стоит разобраться с особенностями ее внедрения. Впрочем, прежде, чем говорить о внедрении имеет обсудить вопросы правильного использования и проектирования. Журнал не раз затрагивал эту тему в своих публикациях, поэтому мы можем просто сослаться на ранее опубликованную статью, которая поможет читателю ознакомиться с этой темой [1]. Великолепным источником является руководство Брайана Комара [3], которое поможет получить глубокие знания предмета. Кроме того, разумно ознакомиться и с первоисточником, если мы говорим о внедрении решения на основе PKI Microsoft, так разработчик предлагает полное руководство по проектированию [2]. Мы же продолжим эту тему рассказом о внедрении инфраструктуры открытых ключей для некоторой организации и предложим читателю некоторый бизнес-кейс из реальной практики, который поможет лучше понять процедуру внедрения и пройти все ее шаги.

     

    Типовой сценарий

    Пусть у нас есть организация, имеющая два основных центра обработки данных и несколько филиалов. Современные тенденции ведения бизнеса предполагают наличие не только стационарных пользователей, но и мобильных. Многие сотрудники компании применяют в своей работе не только обычные рабочие места, но и мобильные устройства. Предполагается необходимость взаимодействия с партнерами и заказчиками, с предоставлением им доступа к некоторым ресурсам компании. Служба каталога предприятия традиционно использует службу каталога на основе Microsoft Active Directory Domain Services. Структурная схема типового ЦОД предприятия может выглядеть так, как это показано на рис. 1.
    Конечно, говоря о центре обработки данных, мы делаем некоторое преувеличение, скорее здесь мы можем говорить о штаб-квартире и крупных филиалах. Поддержка собственного дата-центра в настоящем понимании этого термина оказывается под силу далеко не всем, но в некотором приближении будем считать, что говорим о ЦОД.

    Рисунок 1

     

    Внедрение корпоративной PKI обусловлено ростом потребности в обеспечении безопасности внутри предприятия. Подобное краткое описание нередко оказывается типовой историей для многих компаний. Так как же внедрить PKI для такой организации? Как я уже упоминал выше с проектированием решения можно познакомиться в статьях [1] и [2]. Обычно в подобной ситуации мы будем говорить о двухуровневой иерархии, состоящей из корневого отключенного от сети центра сертификации (Stand-Alone Root CA) и подчиненного издающего корпоративного центра сертификации. Не исключено, а скорей всего обязательно будет присутствовать потребность в использовании и публичных удостоверяющих центров, например, для обеспечения возможности работы внешних клиентов компании. Разумеется, возможны и другие варианты, которые мы обсудим в этом цикле статей, но, в качестве, скажем так, типового и наиболее часто встречающегося, имеет смысл рассматривать именно этот. Более сложные иерархии с использованием дополнительных уровней иерархии с использованием промежуточных серверов политик Policy CA встречаются только для крупных компаний, где требования к политикам сертификатов могут варьироваться, что и приводит к усложнению структуры. Таким образом, типовая структурная схема, может выглядеть так как это показано на рис. 2.

     

    Рисунок 2

     

    Предварительный этап

     

    Этап подготовки развертывания, с точки зрения практических аспектов, будет состоять из настройки точек распространения (Distribution Point), добавления дополнительной записи на сервере DNS и подготовки файлов capolicy.inf, определяющих начальную настройку и параметры работы серверов сертификатов. Наиболее часто используемыми точками распространения являются HTTP и LDAP. Первый вариант обусловлен его универсальностью для любого типа клиента, второй удобством поиска и доступа для типового клиента Active Directory. Соответственно, администратор сталкивается с задачами:

    • настройки места хранения файлов сертификатов, списка отзыва и заявления поставщика, прав доступа на этот или эти ресурсы,
    • установки и настройки сервера WEB для выполнения роли distribution point для PKI,
    • добавления специальной записи на корпоративном DNS сервере, которая обеспечит поиск необходимых ресурсов;
    • наконец обеспечения отказоустойчивости и доступности как самих издающих серверов сертификатов, так и точек распространения, причем говоря о них, не следует забывать о необходимости своевременной синхронизации данных между WEB-серверами, выполняющими эту роль. Например, публикация нового CRL файла означает необходимость предоставления доступа к нему с помощью любого сервера WEB – фермы, выполняющего роль Distribution point, но к этому мы еще вернемся несколько позже.

    Администратору необходимо создать каталог для хранения вышеуказанных файлов и предоставить к нему доступ требуемым группам пользователей, то есть если предполагается «внутреннее» использование, то выбираются соответствующие группы, обычно речь идет о группе «Users», поскольку, как правило, работают с сертификатами все пользователи компании, если же, мы говорим о необходимости работы внешних пользователей, то придется использовать группу «everyone». Кроме того, встроенной группе «Cert Publishers» [4] необходимо предоставить права для изменений внутри этой папки. Это требуется, для правильного подхода при построении строгой ролевой модели.

    На WEB сервере создается виртуальный каталог, указывающий на соответствующий ресурс в хранилище. Необходимо удостовериться в том, что активна опция «Directory Browsing», см. рис. 3, и, если предусматривается использование разностных списков отзыва (Delta CRL), которые в имени файлов используют символ «+», то потребуется обеспечить, так называемый «Double Escaping», что также подразумевает дополнительную настройку на WEB сервере. См. рис. 4.

     

    Рисунок 3

     

    Рисунок 4

     

    Наконец, необходимо создать на сервере DNS запись CNAME [5], которая позволит клиенту находить требуемый ресурс. См. рис. 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.

    Рисунок 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

     

    Продолжение следует

    Статья опубликована в журнале “Cистемный администратор” январь-февраль 2018

     

    Литература

    [1] Л. В. Шапиро Проектирование инфраструктуры Открытых Ключей. Часть 1. Теоретические основы.  Системный Администратор, выпуск № 10 (95) 2010 г. Стр. 80-87

    [2] Brian Komar Windows Server 2008 PKI and Certificate Security

    [3] 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

    [4] Configure Certificate Publishing in Active Directory Domain Services https://technet.microsoft.com/en-us/library/cc730861(v=ws.11).aspx

    [5] Add an Alias (CNAME) Resource Record to a Zone https://technet.microsoft.com/en-us/library/cc772053(v=ws.11).aspx

    [6] Prepare the CAPolicy.inf File https://technet.microsoft.com/en-us/library/jj125373(v=ws.11).aspx

    [7] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 https://www.ietf.org/rfc/rfc3447.txt