Доверительные отношения между центрами сертификации CA в Windows Server 2003 PKI

Один из фундаментальных вопросов, касающихся инфраструктуры открытых ключей (PKI), формулируется следующим образом: «Каким открытым ключам можно доверять?» Чтобы ответить на этот вопрос, следует сначала рассмотреть принципы доверия удостоверяющих центров Certification Authority (CA). Если вы доверяете центру сертификации CA, то при этом предполагается, что CA создает легитимные сертификаты, посредством которых осуществляется привязка уникальной информации о пользователе к открытому ключу. Также предполагается, что перед выдачей сертификата центр CA выполняет его идентификацию и проверяет наличие секретного ключа данного пользователя в соответствующем защищенном хранилище.

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

Инфраструктура Windows Server 2003 PKI поддерживает две основные модели доверительных отношений: иерархическую и сетевую. Кроме того, существует возможность установления регулируемых ограниченных доверительных отношений, что позволяет администратору модифицировать доверительные отношения между центрами CA.

Иерархическая модель доверительных отношений

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

В данной модели между центрами CA, находящимися на различных ярусах иерархии, в явном виде существуют отношения типа «вышестоящий — подчиненный». На вершине иерархии располагается корневой центр CA, который является в этом случае центром доверия. Внутри данной иерархии только сам корневой центр CA имеет право подписывать собственный сертификат, что исключает для других членов иерархии возможность претендовать на то, чтобы стать корневым CA. Это обусловлено тем, что только корневой центр CA знает свой секретный ключ и является его единственным владельцем. Корневой центр сертификации выдает сертификаты центрам CA первого яруса (располагающимся на уровень ниже по иерархии), те в свою очередь сертифицируют центры CA второго яруса и т. д.

Рисунок 1. Иерархическая модель доверия

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

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

Установление иерархических доверительных отношений между вышестоящим и подчиненным центрами CA осуществляется в процессе развертывания Windows 2003 CA. В показанном на экране диалоговом окне CA Type программы Windows Components Wizard можно выбрать тип устанавливаемого центра CA: корневой (root CA) или подчиненный (subordinate CA). Если строится иерархическая структура центров CA, то при установке корневых и промежуточных (т. е. не оконечных) центров следует применять тип установки standalone (независимый), что упростит использование этих центров в автономном режиме. Оконечные центры лучше устанавливать как Windows 2003 enterprise CA, при этом они смогут интегрироваться в структуру Active Directory (AD).

Экран. Выбор типа CA

При развертывании подчиненного центра CA программа установки предлагает два варианта. В первом случае запрос сертификата предоставляется на рассмотрение родительскому центру CA (если он размещается в AD и доступен) в виде файла с расширением *.req. Данный файл содержит блок данных (blob) запроса и имеет формат криптографического стандарта открытых ключей №10 (PKCS #10) или протокола управления сертификатами CMS (Certificate Management protocol with Cryptographic Message Syntax). Второй вариант заключается в том, чтобы вручную (например, с помощью дискеты) передать запрос на сертификат родительскому центру CA.

Сетевая модель доверительных отношений

В сетевой модели доверительных отношений (также называемой моделью «точка-точка» (P2P) или распределенной моделью доверительных отношений) между центрами CA отсутствуют отношения типа «вышестоящий — подчиненный», здесь все центры сертификации рассматриваются как равноправные точки. Данная модель обычно используется в PKI при установлении доверительных отношений между организациями. В модели P2P существует два метода установления доверительных отношений: с помощью списков сертификатов, заслуживающих доверия (Сertificate Trust List, CTL), и кросссертификатов. Инфраструктура Windows 2003 PKI поддерживает оба метода, в Windows 2000 PKI поддерживаются только списки CTL.

Список CTL представляет собой заверенный перечень сертификатов, которым доверяет центр CA. Администратор PKI осуществляет централизованное управление этим списком и распространяет его по всем клиентам инфраструктуры PKI организации. Списки CTL могут быть определены с помощью установки параметров объекта групповой политики (GPO). В инфраструктурах PKI систем Windows 2003 и Windows 2000 можно задавать срок действия CTL, а также ограничивать его применение определенным набором приложений, работающих с PKI.

Кросс-сертификация представляет собой не что иное, как возможность обмена сертификатами между двумя центрами CA,которые являются точками в сетевой модели доверительных отношений, т. е. один центр CA может выдавать сертификат другому центру и, соответственно, получать от него сертификат. При кросс-сертификации допускаются как односторонние, так и двусторонние доверительные отношения (т. е. когда оба CA могут сертифицировать друг друга). Пример построения доверительных отношений между организациями в соответствии с сетевой моделью показан на рис. 2.

Рисунок 2. Сетевая модель прямого доверия

В клиентах PKI систем Windows 2003 и Windows XP реализована поддержка механизмов обнаружения путей доверия и отслеживания связей, необходимых для построения сетевой модели доверительных отношений с несколькими связями кросс-сертификации. В клиентах PKI системы Windows 2000 такие механизмы не поддерживаются. При проверке подлинности сертификата, выданного центром CA, который является точкой сетевой модели, программное обеспечение PKI клиента пытается выстроить путь доверия, который связывает центр CA, выдавший сертификат, с центром доверия локального CA.

В отличие от иерархических доверительных отношений, доверительные отношения на базе кросс-сертификатов могут быть установлены в любой момент после установки центра CA. Следует отметить, что доверительные отношения на базе кросс-сертификатов не могут устанавливаться через графический интерфейс Windows PKI, для этого придется воспользоваться утилитой командной строки certreq.exe. Инструкции по установке доверительных отношений на базе кросс-сертификатов содержатся в документации на Windows 2003 и в официальных документах Microsoft по адресу: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/ws03qswp.mspx.

Регулируемые доверительные отношения

В рамках инфраструктуры PKI среды Windows 2003 реализована поддержка регулируемых доверительных отношений (в Microsoft такой тип отношений называют «ограниченное подчинение»). С помощью этой технологии администраторы центров CA могут управлять доверительными отношениями между вышестоящим центром CA и его подчиненными центрами (для иерархической модели) или воздействовать на отношения между центрами-точками (для сетевой модели). Возможность регулирования отношений доверия, имеющаяся в PKI, придает им некоторое сходство с доверительными отношениями в реальной жизни: они редко бывают полными и обычно зависят от ряда условий.

Регулирование степени доверия может осуществляться с помощью внедрения специальных расширений X.509 в сертификат подчиненного центра CA или в кросс-сертификат центра CA, который является точкой сетевой модели. В Windows 2003 PKI поддерживаются следующие типы расширений сертификатов для регулирования степени доверия: базовые, по именам, политика выдачи и политика приложений.

Базовые ограничения. Эти параметры регулирования основываются на расширениях сертификата X.509, называемых Basic Constraints и содержащих поле с именем pathLenConstraint (или path-length constraint). Эти поля можно использовать только в том случае, если в поле СА расширения X.509 Basic Constraint сертификата установлено значение true, что имеет место только в сертификатах центров CA. С помощью параметра path-length constraint задается максимально допустимое количество сертификатов, выпущенных независимыми центрами CA, которые могут следовать в пути сертификации за данным сертификатом. Таким образом, изменяя значение данного параметра, можно ограничивать длину цепочки сертификатов, образующих путь сертификации.

Рисунок 3. Пример базовых ограничений

На рис. 3 показано два примера иерархических отношений доверия: Config 1 и Config 2. В примере Config 1 установка параметра базового ограничения в сертификате подчиненного центра CA уровня 1 ограничивает длину пути сертификата до 1. В результате центр CA, расположенный на уровень ниже, сможет выдавать пользовательские сертификаты, но он лишен возможности выдавать сертификаты центрам CA. В примере Config 2 аналогичный результат достигается путем добавления параметра длины пути, равного 2, в сертификат корневого центра CA. В этом случае программное обеспечение PKI автоматически добавит параметр длины пути, равный 1, во все сертификаты подчиненных CA, которые были выданы корневым центром.

Ограничения по именам. Расширение сертификата типа ограничения по именам может устанавливаться только для сертификатов центров CA. Данная возможность позволяет ограничить количество субъектов, которым могут выдавать сертификаты подчиненные центры CA или СA, работающие по кросс-сертификатам. С помощью расширений типа ограничения по именам можно задавать то пространство имен, в пределах которого должны находиться имена и дублирующие имена или IP-адреса субъектов, посылающих запросы на сертификацию. Параметры ограничения доверия данного типа размещаются в расширении Name Constraints сертификата центра CA. В табл. 1 приведен перечень поддерживаемых инфраструктурой Windows 2003 PKI ограничений типа Name Constraints. Данная таблица также содержит ссылки на выпускаемые IETF стандарты RFC, в которых регламентируются эти типы ограничений.

В соответствии с RFC 3280, расширение сертификата типа Name Constraint определяет то пространство имен, в пределах которого должны находиться имена всех субъектов в последовательности сертификатов, формирующих путь сертификации. Следовательно, подчиненный центр CA может только ужесточать (но не ослаблять) те установки пространства имен, которые он получает от вышестоящего центра. Например, если подчиненному центру CA разрешено выдавать сертификаты только пользователям домена DNS research.hp.com, отсюда следует, что он не сможет выдать сертификат для подчиненного центра CA, позволяющий тому выдавать пользовательские сертификаты в домене DNS hp.com.

Рисунок 4. Пример ограничения по именам

Если рассмотреть иерархическую модель доверительных отношений, показанную на рис. 4, можно увидеть, что параметры ограничения по именам содержат как правила исключения, так и правила включения. При проверке подлинности параметров ограничения по именам правила исключения всегда имеют преимущества перед правилами включения. В рассматриваемом примере в установках параметра ограничения по именам введено исключение для пользовательского UPN-имени @abc.com и разрешения для имен DNS .hp.com и .compaq.com. Соответственно, если центр CA 1 принимает запрос на сертификат для пользователя joe@abc.com, то такой запрос будет отклонен. Если же приходит запрос для webserver1.hp.com, то в этом случае центр CA 1 принимает данный запрос. Пространство имен подчиненного центра CA 2 является еще более ограниченным: он может выдавать сертификаты только для имен DNS из пространства .compaq.com. Таким образом, если на CA 2 поступает запрос сертификата для webserver2 .hp.com, то этот запрос отклоняется, в то время как запрос, поступивший на CA 2 для mail.compaq .com, будет им принят.

Ограничения по политике выдачи сертификатов. В ограничениях данного типа задаются условия, которые должны выполняться при выдаче сертификатов. В сертификате среды Windows 2003 в качестве идентификатора политики ограничения по выдаче применяется соответствующий идентификатор объекта (OID), который хранится в расширении сертификата Certificate policies.

При добавлении в сертификат центра CA параметров ограничения по выдаче определяется набор правил, которые будут включаться в каждый сертификат, выданный этим центром. Эти параметры могут быть включены, в частности, в сертификаты тех центров CA, работа с которыми ведется по кросс-сертификатам, за счет чего можно ограничивать степень доверия к сертификатам, выданным этими центрами. Возможность применения расширений ограничений по выдаче зависит от наличия логики проверки подлинности цепочки сертификатов. Данная логика поддерживается только в Windows 2003 и Windows XP.

При включении параметров ограничения по выдаче в сертификат, выдаваемый пользователю PKI, эта политика должна применяться на уровне приложения, использующего PKI, т. е. приложение должно само проверять, следует ли ему принимать сертификат, подчиняющийся данным требованиям ограничения по выдаче. Таким образом, это приложение должно быть достаточно интеллектуальным, чтобы понимать, какие типы политик ограничений по выдаче им поддерживаются.

В Windows 2003 PKI имеется набор предустановленных политик ограничения по выдаче, перечень которых вместе с их идентификаторами OID и описаниями функций приведен в табл. 2. Переменные a, b, c и d, присутствующие в идентификаторах OID политик с уровнями защищенности low (низкий), medium (средний) и high (высокий), представляют собой случайным образом генерируемые величины, которые являются уникальными в пределах каждого леса Windows 2003. При необходимости могут быть разработаны и собственные политики, отвечающие требованиям конкретной среды PKI или приложения. На рис. 5 показан пример установки политики ограничения по выдаче в сертификате конечного пользователя. В данном случае определена политика с низким уровнем защищенности (low assurance), которая наследуется от оконечного центра CA на уровне 1. Если попытаться задействовать данный сертификат для работы с PKIприложением, требующим применения политики с высоким уровнем защищенности, данный сертификат будет отклонен, поскольку он может применяться только для приложений с низким уровнем защищенности.

Рисунок 5. Ограничения по выдаче сертификатов

Ограничения по политике приложений. С помощью параметров регулирования степени доверия типа ограничения по политике приложений можно задать круг приложений, для которых могут использоваться сертификаты. Данные параметры могут задаваться как в сертификатах центров CA (для иерархической модели или модели с кросс-сертификацией), так и для сертификатов конечных пользователей. Здесь, как и в предыдущем случае, для идентификации политики применяется ее соответствующий идентификатор объекта (OID), который хранится в расширении сертификата Application policies. Перечень предустановленных в Windows 2003 PKI политик приложений и соответствующие OID приведены в табл. 3.

В сертификатах версии 2, которые впервые появились в Windows 2003, политика для приложений реализует ту же функцию, что и расширение сертификата Extended Key Usage (EKU) в среде Windows 2000. Сертификаты версии 2 выпускаются корпоративным центром и строятся на базе шаблонов сертификатов версии 2. Для того чтобы обеспечить совместимость с предыдущими версиями в центрах CA на базе Windows 2003, а также в клиентах Windows 2003 и Windows XP, сохранены возможности работы с расширениями сертификатов EKU.

Как отмечалось выше, установку параметров политики приложений можно выполнять как в сертификатах пользователей, так и в сертификатах центров CA. Если данная установка выполняется в сертификате пользователя, то ограничивается количество приложений, для которых может применяться данный сертификат. Если же эта установка выполняется в сертификате CA, тогда установленная политика будет распространена на все сертификаты, выпущенные данным центром, включая сертификаты конечных пользователей и центров CA. Таким образом, будет ограничен набор используемых приложений для всех этих сертификатов. Установка данной политики в сертификате центра CA также приведет к сокращению количества типов сертификатов, которые могут выпускаться этим центром. Для корпоративного центра CA установки данной политики имеют более высокий приоритет, чем настройки шаблонов сертификатов данного центра, хранящихся в его контейнере Certificate Templates. Например, если нужно предоставить возможность подчиненному центру CA выдавать сертификаты конечным пользователям, следует убедиться, что были добавлены идентификаторы политики приложений OID для шифрующей файловой системы Encrypting File System (EFS), защищенной почты и аутентификации клиента. Все эти три типа политик приложений предусматриваются шаблоном User.

Политики приложений, устанавливаемые в кросс-сертификатах, предназначены для ограничения набора приложений, доступных для тех сертификатов, в цепочке сертификации которых есть кросс-сертификаты. При этом ответственность за реализацию данной политики лежит на программном обеспечении, выполняющем проверку подлинности цепочки сертификатов. Отметим, что, как и в предыдущем случае, программная реализация проверки политики приложений имеется только в системах Windows 2003 и Windows XP. На рис. 6 показаны результаты установки политики приложений в сертификатах центров CA. На рисунке видно, что в сертификатах подчиненных центров CA 1 и CA 2 была установлена политика приложений. В результате подчиненный центр CA 1 может принимать запросы на сертификаты для электронной почты и для Secure Sockets Layer (SSL), в то время как подчиненный центр CA 2 принимает запросы для сертификатов электронной почты, но отклоняет запросы сертификатов SSL.

Рисунок 6. Пример ограничения по именам

Настройка регулируемых доверительных отношений

Для установки параметров регулируемых доверительных отношений в инфраструктуре Windows 2003 PKI имеется три средства: конфигурационный файл capolicy.inf, конфигурационный файл policy.inf и оснастка Certificate Templates консоли MMC.

В процессе установки центра CA с помощью файла capolicy.inf можно устанавливать параметры регулируемых доверительных отношений для сертификатов CA инфраструктуры PKI, а также изменять другие параметры настройки центра CA. Например, можно задать местонахождение узлов распространения списков сертификатов, подлежащих аннулированию (Certificate Revocation List (CRL) Distribution Points) и узлов Authority Information Access (AIA). Проверка содержимого файла capolicy.inf на наличие параметров регулируемых доверительных отношений производится при установке центра CA, а также при каждом обновлении его сертификата. Данный файл следует хранить в каталоге %systemroot% того компьютера, на который устанавливается центр CA, причем имя этого файла изменять нельзя. В файле capolicy.inf можно задавать только параметры ограничения типа basic и issuance policy.

С помощью конфигурационного файла policy.inf можно определять те параметры ограничения степени доверия, которые записываются в файл запросов сертификатов центра CA (утилита Certreq использует данный файл в качестве параметра). Файл policy.inf предоставляет наиболее полные возможности конфигурирования отношений с регулируемой степенью доверия; здесь, в отличие от файла capolicy.inf, могут настраиваться параметры регулирования степени доверия всех категорий. Отметим также, что, в противоположность файлу capolicy.inf, имя файла policy.inf может быть изменено.

Через оснастку Certificate Templates могут создаваться, редактироваться и удаляться шаблоны сертификатов. Шаблоны сертификатов определяют свойства сертификатов (в том числе относящиеся к регулируемым доверительным отношениям), выдаваемых центрами сертификации Windows CA. Шаблоны сертификатов версии 2 предусматривают редактирование, шаблоны версии 1 не редактируются. Следует отметить, что редактирование шаблонов сертификатов предоставляет менее полные возможности настройки регулируемых доверительных отношений, чем работа с файлом policy.inf: с помощью шаблонов сертификатов могут настраиваться только те параметры ограничения степени доверия, которые относятся к категориям basic, application policy и issuance policy.

Гибкость управления доверием в PKI

Принципы доверия являются фундаментальной концепцией инфраструктуры PKI. Расширенные возможности доверительных отношений, реализованные в Windows 2003 PKI, с одной стороны, делают данную инфраструктуру более мощной и гибкой, а с другой — вносят дополнительную сложность в процессы построения и администрирования доверительных отношений. Тем не менее на данный момент не существует какого-либо другого защищенного протокола или технологии с аналогичными возможностями работы с доверительными отношениями. В следующей статье будут рассмотрены методики управления доверительными отношениями на стороне пользователя инфраструктуры Windows PKI.

Жан де Клерк - Член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press). jan.declercq@hp.com