ƒл€ авторов
јрхив рассылки
–усский
English
   ѕуть: Panvasoft / Ѕлог / »нфраструктура PKI и службы сертификатов в Windows Server 2003
[Ќовости] [Linux] [Windows XP] [Windows Vista] [Windows Server] [Windows 7] [јдминистрирование] [—еть и интернет] [Ѕезопасность] [Tricks & Tips] [ћультимедиа] [∆елезо] [ ниги] [ѕроечее] 20:21:55, ѕ€тница, 27 Ќо€бр€ 2020 

|

–абота с корпоративными и автономными центрами сертификации CA

÷ентр сертификации Certification Authority (CA), называемый компанией Microsoft сервером сертификатов (Certificate Server) или службами сертификатов (Certificate Services), €вл€етс€ ключевым компонентом программного обеспечени€ инфраструктуры открытых ключей PKI (Public Pey Infrastructure) в среде Windows Server 2003. ÷ентр CA принимает и обрабатывает запросы на получение сертификатов от пользователей PKI, идентифицирует эти запросы и провер€ет их правомерность, выдает сертификаты в соответствии с политикой безопасности PKI, обновл€ет и аннулирует сертификаты, размещает сертификаты на различных узлах хранени€, создает и публикует списки аннулированных сертификатов CRL (—ertificate Revocation Lists), а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL.

÷ентр сертификации Windows 2003 CA может выполн€ть в безопасном режиме архивирование и восстановление секретных ключей. „тобы оценить степень развити€ возможностей центров CA и PKI в среде Windows 2003, в этой статье мы рассмотрим компоненты архитектуры последней реализации служб Certificate Services, а также различи€ в процедурах развертывани€ корпоративного и автономного центра CA в среде Windows 2003.

јрхитектура Windows 2003 Certificate Services.

јрхитектура Windows 2003 Certificate Services почти идентична той, котора€ использовалась Microsoft при реализации предыдущих версий названных служб. ќсновное различие состоит в том, что здесь Microsoft изменила структуру базы данных CA дл€ реализации поддержки процедур архивировани€ и восстановлени€ секретных ключей пользователей. —хема данной архитектуры показана на рисунке. ќна включает в себ€ различные модули, базы данных, инструментальные средства администрировани€, посредников и прикладной интерфейс CryptoAPI.

»нфраструктура PKI и службы сертификатов в Windows Server 2003


ћодули.

—ердцем Certificate Services €вл€етс€ исполнительный механизм CA (certsrv.exe), который генерирует сертификаты и занимаетс€ управлением потоками сообщений между CA и другими компонентами служб Certificate Services. —ерверный механизм CA взаимодействует с другими компонентами архитектуры через входные модули, модули политики и выходные модули.

¬ходной модуль принимает запросы на сертификаты, соответствующие формату криптографического стандарта открытых ключей є 10 (Public-Key Cryptography Standards, PKCS #10) или криптографического протокола управлени€, использующего синтаксис криптографических сообщений (Cryptographic Management protocol using Cryptographic Message Syntax, CMS). ѕосле приема запроса входной модуль помещает его в очередь дл€ дальнейшей обработки модулем политики.

ћодуль политики реализует правила политики центра CA в соответствии с установками, заданными администратором CA. ƒанный модуль передает исполнительному механизму CA информацию о структуре сертификата и принимает решение о выдаче сертификата, об отказе в его выдаче или о переводе запроса сертификата в режим ожидани€. ƒл€ обновлени€ информации о структуре сертификата модуль политики может обращатьс€ к информации, хран€щейс€ в каком-либо каталоге (например, Active Directory) либо в базе данных. ћодуль политики, имеющийс€ в Windows 2003, называетс€ certpdef.dll. ќн поддерживает два типа политики: режим корпоративной политики и режим автономной политики. Ёти режимы будут подробно рассмотрены ниже. „тобы убедитьс€ в том, что на данном центре CA установлен модуль политики, следует запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Policy Module, показанной на экране 1.

»нфраструктура PKI и службы сертификатов в Windows Server 2003
Ёкран 1. ¬кладка Policy Module в свойствах объекта


¬ыходные модули занимаютс€ распространением и публикацией сертификатов, цепочек сертификатов, а также полных списков CRL и списков изменений CRL. ¬ыходной модуль может записывать данные PKI в файл или передавать эти данные на удаленный узел, использу€ в качестве транспорта протокол HTTP или механизм удаленного вызова процедур RPC. Windows 2003 CA может поддерживать несколько выходных модулей, соответственно распространение и публикаци€ сертификатов, цепочек сертификатов, полных cписков CRL и списков изменений CRL может выполн€тьс€ одновременно в различные пункты назначени€, включа€ каталоги LDAP, файловые ресурсы совместного пользовани€, каталоги Web и, наконец, ODBC-совместимые базы данных. ѕо умолчанию в Windows 2003 CA входит выходной модуль, называемый certxds.dll, в котором реализована поддержка LDAP, FTP, HTTP и SMTP (в центрах Windows 2000 CA также поддерживаютс€ все эти протоколы, за исключением последнего). ¬ыходной модуль позвол€ет организовать автоматическую рассылку уведомлений от центра CA пользовател€м PKI и администраторам. „тобы убедитьс€ в том, что на данном центре CA установлен модуль политики, нужно запустить оснастку Certification Authority консоли MMC, щелкнуть правой кнопкой на объекте CA, выбрать в контекстном меню пункт Properties и перейти к закладке Exit Module, показанной на экране 2.

»нфраструктура PKI и службы сертификатов в Windows Server 2003
Ёкран 2. ¬кладка Exit Module в свойствах объекта


ћодули политики и выходные модули €вл€ютс€ настраиваемыми и замен€емыми компонентами, поэтому люба€ организаци€ может разработать на €зыках C++ или Visual Basic (VB) собственные модули и интегрировать их в архитектуру Certificate Services. ¬с€ необходима€ информаци€ о процессах создани€ и замещени€ модулей имеетс€ в комплекте документации Software Development Kit (SDK) дл€ платформы Windows 2003.

Ќастройка модулей политики и выходных модулей осуществл€етс€ с помощью оснастки Certification Authority или через утилиту командной строки certutil.exe. »спользу€ окно свойств объекта CA оснастки Certification Authority, можно добавл€ть выходные модули, настраивать расширени€ X.509 дл€ сертификатов (например, определ€ть узлы CDP (CRL Distribution Points) и узлы AIA (Authority Information Access)), а также настраивать параметры публикации дл€ полных списков CRL и списков изменений CRL.

Ѕазы данных.

÷ентр CA имеет собственную базу данных, котора€ называетс€ CAname.edb. ¬ этой базе хранитс€ информаци€ по транзакци€м, св€занным с сертификатами, и собственно сертификаты. «десь же хран€тс€ архивированные секретные ключи. ѕо умолчанию эта база данных хранитс€ в каталоге \%systemroot%\system32\certlog. »сполнительный механизм центра CA взаимодействует с базой данных с помощью файла certdb.dll. — по€влением службы Windows 2000 Certificate Services изменилась используема€ Microsoft технологи€ работы с базами данных. “еперь здесь используетс€ процессор баз данных Jet, что позволило сделать архитектуру Windows 2000 CA масштабируемой. ќтметим, что аналогична€ технологи€ используетс€ в базах данных AD и Microsoft Exchange Server.

—редства администрировани€.

¬ большинстве случаев дл€ администрировани€ центра сертификации Windows 2003 CA используетс€ оснастка Certification Authority, но это можно делать и с помощью утилиты командной строки certutil.exe. ќба средства взаимодействуют с исполнительным механизмом центра CA через библиотеку certadm.dll.

ѕосредники (intermediaries).

ѕрикладные программы, помогающие клиенту корректно сформировать запрос сертификата, соответствующий формату PKCS #10 или CMS, называютс€ посредниками или Registration Authorities (RA). Ёти программы собирают специальные данные о пользователе и о запросе, которые необходимы дл€ формировани€ корректного запроса сертификата. Ќапример, любой запрос, направл€емый корпоративному центру Windows 2003 CA, должен содержать ссылку на шаблон сертификата. ѕрограммы RA могут добавл€ть к запросу описание шаблона. —ледует отметить, что эти программы используют определенные транспортные протоколы (например, HTTP и RPC), соответственно при этом и исполнительный механизм CA не должен использовать дл€ работы другие типы транспорта.

ѕримерами посредников в Windows 2003 могут служить Web-страницы регистрации сертификатов, которые €вл€ютс€ посредниками HTTP, а также оснастка Certificates консоли MMC, вызывающа€ мастер Certificate Request Wizard, котора€ играет роль RPC-посредника. ѕри генерации секретных ключей на клиентской машине посредник HTTP обращаетс€ к библиотеке xenroll.dll, а при генерации секретных ключей на смарт-картах он использует библиотеку scenroll.dll. ѕосредник RPC дл€ выполнени€ данных процедур вызывает библиотеку certcli.dll.

ѕрикладной интерфейс CryptoAPI.

ƒл€ реализации всех криптографических функций, включа€ доступ и использование секретных ключей CA, центр сертификации задействует вызовы интерфейса CryptoAPI. ÷ентр CA может хранить свой секретный ключ на жестком диске или на специальном аппаратном устройстве (например, на аппаратном модуле безопасности Hardware Security Module, HSM).

”становка Windows 2003 Certificate Services

ѕри выполнении установки Windows 2003 Certificate Services может быть развернут корневой CA, подчиненный CA, корпоративный CA (интегрированный в AD) или автономный CA (не интегрированный в AD). ≈сли служба Certificate Services устанавливаетс€ в корпоративном режиме, то в этом случае активируетс€ аналогичный режим и дл€ модул€ политики центра Windows 2003 CA. –ассмотрим, чем отличаютс€ корпоративный и автономный режимы. ¬ таблице приведены сравнительные характеристики параметров, установленных по умолчанию, дл€ автономного и корпоративного центров Windows 2003 CA.

ѕри установке корпоративного центра CA та учетна€ запись, от имени которой выполн€етс€ установка, должна иметь привилегии Enterprise administrator и Domain administrator в корневом домене леса AD.  роме того, сервер, на который устанавливаетс€ корпоративный CA, должен €вл€тьс€ членом домена с функционирующей в нем службой AD. ≈сли эти услови€ не выполнены, в CA installation Wizard будут недоступны возможности перехода в режим установки enterprise CA, соответственно развернуть центр CA можно будет только в автономном режиме.

ƒл€ того чтобы установить автономный центр CA, использовать AD необ€зательно. CA может устанавливатьс€ как на автономный сервер, так и на сервер, вход€щий в домен, или на контроллер домена (DC). ѕри такой установке не требуютс€ и полномочи€ Enterprise administrator и Domain administrator, вполне достаточно прав локального администратора на данном сервере. ≈сли при установке автономного центра CA все-таки использовать привилегии Enterprise administrator, в этом случае данный центр будет обладать некоторой дополнительной функциональностью. ¬ частности, если пользователь с правами Enterprise administrator устанавливает автономный центр CA на сервер, вход€щий в состав домена, то в этом случае центр CA сможет публиковать выпущенные им сертификаты в AD.

Ўаблоны сертификатов

 орпоративный центр CA использует шаблоны сертификатов, которые хран€тс€ в структуре AD в контексте имен конфигурации. Ўаблон определ€ет содержание и характеристики сертификата.  роме того, с помощью шаблонов можно контролировать типы выпускаемых центром CA сертификатов и определ€ть, какие пользователи могут запрашивать сертификаты у корпоративного центра CA, а также сертификаты какого типа могут им выдаватьс€. ¬ инфраструктуре PKI среды Windows 2003 поддерживаютс€ шаблоны сертификатов версии 2, которые, в отличие от шаблонов версии 1, €вл€ютс€ полностью настраиваемыми. Ќастройка шаблонов осуществл€етс€ с помощью оснастки Certificate Templates консоли MMC.

јвтономный центр CA не может использовать шаблоны сертификатов AD, в этом случае нельз€ выполн€ть контроль типов сертификатов и пользователей, их получающих. ѕо умолчанию автономный CA может выдавать только сертификаты, предназначенные дл€ Web-аутентификации (Secure Sockets Layer, SSL; или Transport Layer Security, TLS), защиты электронной почты (Secure MIME, S/MIME), аутентификации сервера, цифровой подписи и дл€ работы с протоколом IP Security (IPSec). “ем не менее можно модифицировать Web-интерфейс автономного центра CA (например, дл€ того чтобы в списке отображались другие типы сертификатов) или запрашивать другие типы сертификатов, использу€ дл€ этого значени€ специальных идентификаторов объектов (OID), которые хран€тс€ в X.509-расширении сертификата Extended Key Usage.

ѕолучение дополнительной информации при запросе сертификата

¬ процессе регистрации сертификата корпоративный центр CA ищет в структуре Active Directory информацию о пользователе, котора€ потребуетс€ центру дл€ заполнени€ определенных полей сертификата. Ќапример, в поле X.509 SubjectAltName сертификата, выданного корпоративным центром CA, содержитс€ ссылка на им€ пользовател€, определ€ющее его в AD, — User Principal Name (UPN). ≈сли центр CA €вл€етс€ автономным, он не имеет доступа к AD, поэтому информаци€, идентифицирующа€ пользовател€ и необходима€ дл€ получени€ сертификата с Web-сайта регистрации, должна вводитьс€ пользователем вручную.

 ак в корпоративных, так и в автономных центрах CA можно измен€ть установленные по умолчанию параметры, добавл€емые центром CA к запросу сертификата. Ёто делаетс€ в процессе регистрации сертификатов путем редактировани€ файла certdat.inc, который находитс€ в каталоге \%systemroot%\system32\certsrv. ƒопускаетс€ изменение значений, установленных по умолчанию, дл€ следующих параметров сертификата: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, и sDefaultCountry. ≈сли привести значени€ этих параметров в соответствие с используемыми в организации наименовани€ми, можно будет сократить объем вводимой пользователем информации при запросе сертификата.

јвтоматическа€ регистраци€ сертификатов

÷ентр CA корпоративного типа поддерживает технологию автоматической регистрации сертификатов, причем в Windows 2003 возможности данной технологии расширены и теперь распростран€ютс€ как на пользовательские сертификаты, так и на сертификаты компьютеров. ќтметим, что если пользователь запрашивает сертификат от автономного центра CA, процесс регистрации должен быть запущен вручную, так как в данном случае какие-либо процедуры автоматизации отсутствуют.

÷ентрализованное архивирование ключей

 орпоративный центр CA поддерживает механизмы централизованного архивировани€ ключей в базе данных CA, а автономный центр — нет.

”тверждение запроса сертификата

¬ корпоративных центрах CA имеетс€ поддержка механизмов автоматического и ручного утверждени€ запросов сертификатов. ƒл€ того чтобы настроить свойства режима обработки запросов сертификатов, можно воспользоватьс€ либо свойствами корпоративного CA (через свойства модул€ политики), либо свойствами шаблона сертификата версии 2 (с помощью вкладки Issuance Requirements окна свойств шаблона сертификата). ≈сли настройка режима обработки запросов выполн€етс€ через свойства шаблона сертификата версии 2, то следует иметь в виду, что внесенные при этом изменени€ будут применены только к сертификатам того типа, который определ€етс€ данным шаблоном. ћожно задать настройку, об€зывающую администратора утверждать все поступающие запросы сертификатов вручную, независимо от установок в шаблоне сертификата. ƒл€ этого при настройке режима обработки запросов в свойствах CA нужно выбрать пункт Set the certificate request status to pending. The administrator must explicitly issue the certificate. Ёти же пункты доступны и дл€ автономного центра CA, с той лишь разницей, что автономный CA не может использовать шаблоны сертификатов, и, следовательно, не удастс€ настроить свойства обработки запросов дл€ отдельного шаблона сертификата. ¬ отличие от корпоративного центра, автономный CA при аутентификации поступающих запросов не использует внутренние механизмы аутентификации Windows, соответственно компани€ Microsoft не рекомендует устанавливать режим автоматического утверждени€ в свойствах обработки запросов дл€ автономных центров CA. ¬ этих случа€х всегда следует оставл€ть установку, сделанную по умолчанию, в соответствии с которой каждый поступающий запрос сертификата должен утверждатьс€ администратором вручную.

ќпубликование сертификатов и списков CRL

 орпоративные центры CA хран€т и публикуют сертификаты, а также полные списки CRL и списки изменений CRL в Active Directory. ¬ то же врем€ как корпоративные центры, так и автономные CA могут осуществл€ть размещение данных в файловой системе.  аждый размещенный в AD сертификат автоматически отображаетс€ на учетную запись того, кто его запрашивал. —лужба Active Directory добавл€ет сертификат к многозначному атрибуту UserCertificate пользовател€ или объекта AD inetOrgPerson. ќтметим, что не каждый выданный корпоративным центром CA сертификат автоматически публикуетс€ в AD. ѕримерами сертификатов, которые не будут публиковатьс€ автоматически, могут служить сертификат агента регистрации или сертификат дл€ подписи списка CTL (certificate trust list).

¬ принципе автономный центр CA тоже может публиковать выпущенные им сертификаты в AD, но по умолчанию этот режим не поддерживаетс€. ƒанна€ возможность может быть реализована только при развертывании автономного центра CA на сервере, который €вл€етс€ членом домена. ќтметим, что всегда можно €вно размещать сертификаты в AD в ручном режиме.

¬ыбор типа CA, оптимального дл€ решаемых задач

»так, мы определили различи€ между корпоративным и автономным центром CA и теперь, на основании полученных знаний, можем выбирать конфигурацию центра CA, оптимальную дл€ конкретной ситуации. –азвертывание корпоративного центра Windows 2003 CA будет наилучшим решением дл€ работы с сертификатами пользователей, имеющих учетные записи в AD и использующих протокол Kerberos дл€ их аутентификации в инфраструктуре AD. ƒл€ внешних пользователей (например, пользователей из внешней сети, не имеющих учетных записей в инфраструктуре Windows внутренней сет) оптимальным решением будет использование автономного центра Windows 2003 —A.

“аблица. —равнение основных характеристик автономного и корпоративного центров сертификатов Windows2003 CA

—войство јвтономный Windows 2003 CA  орпоративный Windows 2003 CA
¬озможность интеграции в AD ѕо умолчанию отсутствует »нтегрированный в AD
ѕротоколы взаимодействи€ с CA  лиенты взаимодействуют с CA по протоколам HTTP или HTTP Secure (HTTPS) ¬заимодействие клиентов с CA может осуществл€тьс€ через RPC или Distributed COM DCOM), а также по протоколам HTTP или HTTPS
–аспространение сертификатов ÷ентр CA загружает CA в пользовательский профиль, когда пользователь получает в ручном режиме сертификат с Web-сайта центра CA. ≈сть возможность автоматического размещени€ списков CRL и сертификатов в AD ¬ зависимости от настройки шаблона сертификата центр CA может автоматически загрузить сертификат в пользовательский профиль, поместить сертификат в AD либо выполнить оба действи€
”тверждение запросов сертификатов ѕроцедура выдачи разрешений на регистрацию сертификатов может быть автоматической или ручной. –ежим работы данной процедуры контролируетс€ в центре CA с помощью одной общей настройки дл€ всех типов сертификатов ѕроцедура выдачи разрешений на регистрацию может быть автоматической или ручной. ≈сть возможность как глобального контрол€ данного режима на уровне центра CA, так и задани€ различных режимов дл€ разных типов сертификатов, что достигаетс€ соответствующей настройкой шаблонов сертификатов. ¬ процессе выдачи разрешений на регистрацию сертификатов могут также использоватьс€ имеющиес€ в AD механизмы аутентификации и контрол€ доступа, базирующиес€ на списках контрол€ доступа (ACL), которые могут быть заданы в шаблонах сертификатов
ќграничени€ по типам пользователей инфраструктуры PKI ќриентируетс€ на работу с инфраструктурой PKI пользователей Internet и внешних сетей ќриентируетс€ на работу с инфраструктурой PKI пользователей корпоративной сети
“ребовани€ по платформе ƒанна€ верси€ может устанавливатьс€ на контроллер домена (DC) Windows 2003, на сервер домена или на авто- номный сервер, не €вл€ющийс€ членом какого-либо домена. ƒанна€ верси€ устанавливаетс€ только на контроллер домена (DC) Windows 2003 или на сервер домена
ѕоддерживаемые типы сертификатов ћожет выдавать ограниченный набор типов сертификатов и сертификаты, требующие наличи€ специального идентификатора OID в расширении Extended Key Usage. –абота с шаблонами сертификатов не поддерживаетс€ ћожет выпускать дл€ среды Windows 2003 сертификаты любых типов из тех, которые представлены в оснастке Windows 2003 Certificate Templates. ѕоддерживаютс€ шаблоны сертификатов версии 1 (Windows 2000 PKI) и версии 2 (Windows 2003 PKI)
»дентификаци€ пользователей ѕри запросе сертификата пользователь должен ввести идентифицирующую его информацию вручную ÷ентр CA автоматически получает информацию, идентифицирующую пользовател€, из AD
”правление пользовател€ми ѕользователь регистрируетс€ через Web-интерфейс. ћожно также использовать утилиту командной строки c ertreq.exe ѕользователь регистрируетс€ через Web-интерфейс или с помощью оснастки Certificates. “акже существуют возможности автоматической регистрации сертификатов и регистрации с помощью утилиты командной строки certreq.exe


јвтор: ∆ан де  лерк

 атегори€: Windows Server
»сточник: osp.ru ќпубликовал: Feeder, ƒата: 27.11.2006, ѕросмотров сегодн€: 0, ѕросмотров всего: 33163, –ейтинг: 1.80 (ѕроголосовало: 10) “еги:

–асскажи друзь€м:


≈ще статьи на угад:
“ранспортные агенты(часть 1)
“ранспортные агенты (часть 2)
—мена паролей через WEB
»нфраструктура PKI и службы сертификатов в Windows Server 2003
ƒелегирование доступа в AD
¬озьмемс€ за дело с помощью Dfs
”правление доступом на основе ролей.

¬аши комментарии:

Ќет ни одного сообщени€, воспользуйтесь формой, расположенной ниже дл€ добавлени€ сообщени€

ƒобавить свое мнение о данной программе:
»м€
Email
—ообщение:
¬ведите символы:
вверх страницы

  ѕодпишитесь на лист рассылки и стань одним из 16412, кто узнает о новых программах по почте!!

 ¬ведтите ваш e-mail:

ѕодписатьс€
ќтписатьс€



© 1999 - 2020 Panva Web Studio
(0.02257 секунд) Ќаписать письмо вебмастеру