Настройка центра сертификации windows server 2003

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

ЦС предприятия

• Требует наличия ActiveDirectory
• Автоматическое подтверждение сертификатов
• Автоматическое развертывание сертификатов
• Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

• Не требует наличия ActiveDirectory
• Ручное подтверждение сертификатов
• Отсутствие возможности автоматического развертывания
• Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

Windows Server 2008 R2

Проверка работы ЦС

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Работа с корпоративными и автономными центрами сертификации 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.

Рисунок. Архитектура CA

Модули. Сердцем 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.

Экран 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.

Экран 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%system32certlog. Исполнительный механизм центра 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%system32certsrv. Допускается изменение значений, установленных по умолчанию, для следующих параметров сертификата: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, и sDefaultCountry. Если привести значения этих параметров в соответствие с используемыми в организации наименованиями, можно будет сократить объем вводимой пользователем информации при запросе сертификата.

Автоматическая регистрация сертификатов

Центр CA корпоративного типа поддерживает технологию автоматической регистрации сертификатов, причем в Windows 2003 возможности данной технологии расширены и теперь распространяются как на пользовательские сертификаты, так и на сертификаты компьютеров. Более подробно эти вопросы рассматриваются в статье «Технология регистрации PKI сертификатов в Windows 2003 Server», опубликованной на сайте журнала Windows IT Pro/RE (http://www.osp.ru/win2000/safety/511_29.htm). Отметим, что если пользователь запрашивает сертификат от автономного центра CA, процесс регистрации должен быть запущен вручную, так как в данном случае какие-либо процедуры автоматизации отсутствуют.

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

Корпоративный центр CA поддерживает механизмы централизованного архивирования ключей в базе данных CA, а автономный центр — нет. Возможности технологии архивирования и восстановления ключей CA более подробно обсуждаются в статье «Автоматическое архивирование и восстановление ключей в инфраструктуре Windows Server 2003 PKI», опубликованной в № 3 журнала Windows IT Pro/RE за 2006 г.

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

В корпоративных центрах 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.

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

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

Как вы уже должны знать, поддержка Windows Server 2003 и Windows Server 2003 R2 заканчивается 14 июля 2015 года. Зная это, ИТ профессионалы либо уже провели миграцию, либо этот процесс должен находиться в самом разгаре. В этой статье будут описаны шаги, необходимые для миграции Active Directory Certificate Service с Windows Server 2003 на Windows Server 2012 R2.

Для демонстрации будут использованы следующие установки:

Шаг 1. Резервная копия конфигурации и базы данных центра сертификации Windows Server 2003

Заходим в Windows Server 2003 под учетной записью из группы локальных администраторов.
Выбираем Start – Administrative Tools – Certificate Authority

Щелкаем правой кнопкой мыши по узлу сервера. Выбираем All Tasks, затем Back up CA

Откроется “Certification Authority Backup Wizard” и нажимаем “Next” для продолжения.

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

Далее вам будет предложено ввести пароль для того, чтобы защитить закрытый ключ и файл сертификата центра сертификации. После того, как введете пароль, нажмите “Next”.

В следующем окне будет запрошено подтверждение. Если все в порядке – нажмите “Finish” для завершения процесса.

Шаг 2. Резервирование параметров реестра центра сертификации

Нажмите Start, затем Run. Напечатайте regedit и нажмите ОК.

Затем откройте HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvc
Щелкните правой кнопкой мыши по ключу “Configuration” и выберите “Export”

В следующем окне укажите путь, по которому вы хотите сохранить резервный файл и укажите его имя. Затем нажмите “Save”, чтобы закончить резервирование.

Теперь у нас есть резервные файлы центра сертификации и мы можем переместить эти файлы на новый сервер Windows Server 2012 R2.

Шаг 3. Удаление службы центра сертификации с Windows Server 2003

Теперь, когда готовы резервные файлы и прежде, чем настроить службы сертификации на новом Windows Server 2012 R2, мы можем удалить службы центра сертификации с Windows Server 2003. Для этого нужно проделать следующие шаги.
Щёлкаем Start > Control Panel > Add or Remove Programs

Затем выбираем “Add/Remove Windows Components”

В следующем окне уберите галочку с пункта “Certificate Services” и нажмите “Next” для продолжения

После завершения процесса, вы увидите подтверждение и можете нажать “Finish”

На этом этапе мы закончили работу со службами центра сертификации на Windows Server 2003 и следующим шагом будем настраивать и конфигурировать центра сертификации на Windows Server 2012 R2.

Шаг 4. Установка служб сертификации на Windows Server 2012 R2

Зайдите на Windows Server 2012 R2 под учетной записью или администратора домена, или локального администратора.
Перейдите в Server Manager > Add roles and features.

Запустится “Add roles and features”, нажмите “Next” для продолжения.
В следующем окне выберите “Role-based or Feature-based installation”, нажмите “Next” для продолжения.
Из списка доступных серверов выберите ваш, и нажмите “Next” для продолжения.
В следующем окне выберите роль “Active Directory Certificate Services”, установите все сопутсвующие компоненты и нажмите “Next”.

В следующих двух окнах нажимайте “Next”. После этого вы увидите варианты выбора служб для установки. Мы выбираем Certificate Authority и Certification Authority Web Enrollment и нажимаем “Next” для продолжения.

Для установки Certification Authority Web Enrollment необходимо установить IIS. Поэтому в следующих двух окнах посмотрите краткое описание роли, выберите нужные компоненты и нажмите “Next”.
Далее вы увидите окно подтверждения. Если все в порядке, нажмите “Install” для того, чтобы начать процесс установки.

После того, как установка завершена, вы можете закрывать мастер установки и переходить к следующему шагу.

Шаг 5. Настройка AD CS

В этом шаге мы рассмотрим как настроить и восстановить те файлы резервирования, которые мы создали.
Зайдите на сервере с правами Enterprise Administrator
Перейдите в Server Manager > AD CS

C правой стороны на панели вы увидите всплывающее окно, как на скриншоте и нажмите “More”

Откроется окно, в котором вам нужно нажать “Configure Active Directory Certification Service…”

Откроется окно мастера настройки роли, в котором появится возможность изменить учетную запись. Т.к. мы уже вошли в систему с учетной записью Enterprise Administrator, то мы оставим то, что указано по умолчанию и нажмем “Next”

В следующем окне спросят, каким службы мы хотим настроить. Выберите Certificate Authority и Certification Authority Web Enrollment и нажимаем “Next” для продолжения.

Это будет Enterprise CA, поэтому в следующем окне выберите в качестве типа установки Enterprise CA и нажмите “Next” для продолжения.

В следующем окне выберите “Root CA” в качестве типа CA и нажмите “Next” для продолжения.

Следующая настройка очень важна. Если бы это была новая установка, то мы могли бы просто создать новый закрытый ключ. Но так как это процесс миграции, у нас уже есть зарезервированный закрытый ключ. Поэтому здесь выберите вариант, который отмечен на скриншоте и нажмите “Next” для продолжения.

В следующем окне нажмите кнопку “Import”.

Здесь у нас появляется возможность выбрать тот ключ, который мы зарезервировали с Windows Server 2003. Указываем путь к этому ключу и вводим пароль, который мы использовали. Затем нажимаем OK.

Далее, если импорт прошел успешно, то мы увидим наш сертификат. Выбираем его и нажимаем “Next” для продолжения.

В следующем окне мы можем определить путь к базе данных сертификата. Я оставил то, что указано по умолчанию и нажимаю “Next” для продолжения.

В следующем окне будет предоставлена вся информация для настройки. Если все нормально, то нажимаем “Configuration” для запуска процесса.

После того, как процесс завершен, закрываем мастера конфигурации.

Шаг 6. Восстановление зарезервированного CA

Теперь мы переходим к наиболее важной части всего процесса миграции, в которой мы восстановим зарезервированный в Windows Server 2003 CA.
Открываем Server Manager > Tools > Certification Authority

Щелкаете правой кнопкой мыши по имени сервера и выбираете All Tasks > Restore CA

Далее появится предупреждение о том, что служба сертификатов должна быть установлена для продолжения. Нажмите ОК.

Запустится Certification Authority Restore Wizard, нажмите “Next” для продолжения.
В следующем окне укажите путь к папке, в которой находится резервная копия. Затем выберите теже настройки, что и я на скриншоте. Нажмите “Next” для продолжения.

В следующем окне вы можете ввести пароль, который мы использовали для того, чтобы защитить закрытый ключ в процессе резервирования. После ввода, нажмите “Next” для продолжения.

В следующем окне нажмите “Finish” для завершения процесса импорта.
После успешного завершения процесса, система спросит, можно ли запустить центр сертификации. Запустите службу.

Шаг 7. Восстановление информации в реестре

Во время создания резервной копии CA мы также создали резервную копию ключа реестра. Теперь нужно ее восстановить. Для этого откройте папку, которая содержит зарезервированный ключ реестра. Щелкните по нему дважды левой кнопкой мыши.
Появится предупреждающее окно. Нажмите “Yes” для восстановления ключа реестра.

По окончании вы получите подтверждение об успешном восстановлении.

Шаг 8. Перевыпуск шаблона сертификата

Мы завершили процесс миграции, и сейчас нужно перевыпустить сертификаты. У меня были настройки шаблона в окружении Windows Server 2003, который назывался “PC Certificate”, с помощью которого выпускались сертификаты для компьютеров, включенных в домен. Теперь посмотрим, как я перевыпущу шаблон.
Открывает консоль Certification Authority
Щелкаем правой кнопкой мышки по Certificate Templates Folder > New > Certificate Template to Reissue.

Из списка шаблонов сертификатов выберите подходящий шаблон сертификата и нажмите ОК.

Шаг 9. Тестируем CA

Теперь, когда шаблон сертификата установлен на компьютер, его нужно установить на автоматический режим. Для проверки я установил компьютер с операционной системой Windows 8.1, назвал его demo1 и добавил в домен canitpro.local. После его первой загрузки, на сервере я открываю консоль центра сертификации и разворачиваю раздел “Issued Certificate”. Там я могу увидеть новый сертификат, который выпущен для компьютера.

На этом процесс миграции успешно завершен.

Введение

Даная статья описывает инфраструктуру открытых ключей (PKI — Public Key Infrastructure), реализованную на платформе Microsoft Windows Server 2003. В статье рассмотрены основные понятия и концепции PKI, а также те новые возможности, которые предоставляет Windows Server 2003 в плане использования PKI для решения прикладных задач.

Рассмотрение PKI следует начать с таких фундаментальных основ, как центр сертификации. Прежде всего, необходимо выяснить, что собой представляет центр сертификации в составе Windows Server 2003, какова его структура и, конечно же, какие новые возможности реализованы в самой новой версии серверной операционной системы от компании Microsoft. Уже несколько лет Microsoft движется четким курсом, который подразумевает реализацию средств и концепций безопасности во всех продуктах и проектах. Концепция безопасности платформы Windows — это реализация технологии защиты информации на всех уровнях информационной системы. Если выделить вертикальные уровни (то есть посмотреть вглубь), то можно увидеть три основных направления, на которых покоится система защиты информации: аутентификация субъектов, контроль доступа к объектам и защита потоков данных с помощью средств шифрования. Это хорошо известная профессионалам азбука безопасности. Далее мы не будем рассматривать аутентификацию и контроль доступа, а остановимся лишь на средствах шифрования. Чтобы разобраться с PKI, необходимо выяснить, как реализованы средства шифрования, а также какую роль они играют в системе безопасности.

Значение средств шифрования трудно переоценить. На рисунке выше можно видеть довольно много прямоугольников, каждый из которых обозначает определенную службу. Например, службы удаленного доступа, аутентификации с помощью смарт-карт, шифрующая файловая система, аутентификация в рамках IP Security. Все это использует инфраструктуру открытых ключей, а фундаментом всех этих служб выступает набор программных интерфейсов CryptoAPI. В основе представленной выше модели лежат так называемые криптопровайдеры — слой модулей, которые, собственно, и выполняют операции шифрования, а также создания и хранения ключей. Таким образом, из всех служб, отвечающих за безопасность в рамках Microsoft Windows, на рисунке не представлена только одна — система контроля доступа. Дело в том, что система контроля доступа оперирует понятием списка контроля доступа и не использует криптографию. Все остальные службы, напротив, так или иначе, используют средства шифрования. Большая часть этих служб использует шифрование именно на основе инфраструктуры открытых ключей, то есть с PKI начинается управление системой безопасности на платформе Windows Server 2003. Именно поэтому инфраструктуре открытых ключей уделяется такое большое внимание.

Мы не будем останавливаться на теоретических аспектах: что такое PKI, цифровые сертификаты, открытые и личные ключи. Предполагается, что читатель либо уже хорошо знаком с этими понятиями, либо представляет себе, по крайней мере, как эти объекты устроены. Таким образом, мы пропустим начальный уровень, на котором рассказывают про двух известных людей — абонентов Алису и Боба, которые обмениваются между собой различными сообщениями, а противник Ева их перехватывает и пытается расшифровать. Теоретические протоколы и технологии, которые используются при таком рассмотрении, представляют интерес для научной криптографии. На практике же почти всегда с самого начала известно, что на предприятии необходимо развернуть инфраструктуру открытых ключей. Какие преимущества получит информационная инфрастуктура от использования PKI, рассмотрено в следующей главе.

Что следует сделать, чтобы развернуть PKI? Прежде всего, нужно иметь центр сертификации. Центр сертификации отвечает за выдачу сертификатов клиентам, контролирует жизненный цикл этих сертификатов (то есть отзывает сертификаты, которые уже недействительны), гарантирует публикацию информации об отозванных сертификатах, хранит историю всех выданных сертификатов, предоставляет интерфейсы, позволяющие запросить и получить сертификат. Функций довольно много, а так как центры сертификации в большой организации могут охватывать достаточно распределенную инфраструктуру, стандарт PKI подразумевает возможность построить иерархию из нескольких центров сертификации. В этом случае мы получаем дерево, дерево доверий центров сертификации. Данное дерево обязательно содержит один корневой центр, самый главный. С него начинается инфраструктура, и им же она может и заканчиваться. В простейшем случае в системе есть один единственный центр сертификации, который выполняет все вышеперечисленные функции. В более сложном случае уровней может быть два, три и больше, но рекомендуется ограничить свое дерево не более чем тремя уровнями.

Служба «Центр Сертификации» или Microsoft Certification Authority, как она называется в оригинале, реализована в виде сервиса, который включен в состав операционной системы. Центр сертификации построен по модульному принципу. Архитектура модулей схематически представлена на рисунке выше.

Модульность логично рассматривать в виде четырех компонентов. Первый компонент, вероятно, самый важный — это криптопровайдер (CSP — Crypto Service Provider), который определяет, какой алгоритм шифрования используется, и как хранятся ключи. По умолчанию, центр сертификации Microsoft использует криптопровайдер, реализующий алгоритм RSA. Для России есть реализация ГОСТов — это решения компании «Крипто-Про»: КриптоПро CSP и Удостоверяющий Центр.

Удостоверяющий Центр — это центр сертификации в составе Microsoft Windows, использующий КриптоПро CSP. В самом криптопровайдере КриптоПро реализованы алгоритмы ГОСТ и дополнительные возможности для ведения бизнес-процессов (их часто называют «бизнес-обвязка»).

Следующий важный модуль — это модуль политики (Policy Module). Он определяет то, каким образом центр сертификации обрабатывает запросы, приходящие от пользователя. По умолчанию в составе Microsoft Windows поставляются два модуля политики — первый называется Standalone Policy, а второй — Enterprise Policy. В соответствии с тем, какая политика установлена, центр сертификации выбирается один из этих двух.

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

Рассмотрим теперь корпоративный центр сертификации, в котором используется модуль Policy Module Enterprise. С его помощью можно полностью автоматизировать процесс выдачи сертификатов и произвести интеграцию с Active Directory. Благодаря этому все действия, начиная от запроса сертификата и заканчивая его применением, будут полностью прозрачны для пользователя. Пользователю не понадобится совершать вообще никаких дополнительных действий, он будет работать со своими данными, не замечая того, что операционная система защищает информацию с помощью шифрования.

Policy Module может быть написан самостоятельно: можно придумать самые разнообразные механизмы обслуживания запросов. Другими словами, Policy Module, который по умолчанию встроен в центр сертификации, может быть заменен другим.

Еще два важных компонента — Entry Module и Exit Module. Это, соответственно, входящий и выходящий модули. Entry Module принимает запросы от клиентов. По большому счету этот компонент не требует аутентификации, хотя при желании его тоже можно заменить (все же в большинстве случаев стандартного входящего модуля вполне достаточно). Exit Module отвечает за доставку сертификата пользователю и за публикацию такой информации, как список отозванных сертификатов. Задачи выходящего модуля зависят еще и от инфраструктуры предприятия и тех механизмов, которые там задействованы. Опять же, всегда остается возможность написать свой Exit Module и использовать его вместо стандартного.

Таким образом, установив центр сертификации в Windows Server 2003, заказчик получает, в какой-то степени, конструктор. Конструктор выполняет базовый функционал, но его можно сколь угодно сложно модифицировать, настроить и даже перестроить.

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

По умолчанию, клиентом PKI является любая операционная система семейства Windows 2000, Windows XP и Windows 2003. Клиент встроен в операционную систему.

Клиент PKI состоит из того же стандартного набора средств шифрования, который входит в любую систему Microsoft Windows. Это тот же Crypto Service Provider, который отвечает за создание и хранение ключей, а также некоторое хранилище, в котором в соответствии со стандартом PKI хранятся сертификаты. Сертификаты могут быть выданы конкретному клиенту, могут быть сертификатами корневых центров (которым клиент доверяет) и т.д. В различных хранилищах хранятся различные сертификаты, применяемые для различных целей.

Инфраструктура, представленная на рисунке выше, состоит из двух центров. Один из них — корневой. Он специально все время находится в режиме offline, это стандартная рекомендация. Построение PKI рекомендуется делать в виде двух уровневой системы. Наверху корневой центр является наиболее ответственным участником инфраструктуры, поэтому обычно его используют для того, чтобы выдать сертификат подчиненному центру, а потом переводят в режим offline и «запирают где-нибудь в бункере». Дело в том, что если будет скомпрометирован личный ключ корневого центра сертификации, то вся инфраструктура потеряет доверие. Именно поэтому на рисунке корневой центр сертификации показан в режиме offline. Реальную же работу выполняет выдающий центр сертификации, на рисунке он работает в режиме Enterprise и интегрирован с Active Directory. Выдающий центр сертификации использует шаблоны сертификатов, для формирования сертификатов для каждой задачи своего клиента. Также он отвечает за публикацию списков отозванных сертификатов.

Таким образом, когда возникает необходимость получить сертификат, клиент производит все действия полностью автоматически. Прежде всего, формируется запрос на получение сертификата. В этот запрос включается в соответствии со стандартом PKCS открытый ключ клиента. Запрос посылается центру сертификации с указанием, для какой задачи клиенту требуется данный сертификат. На самом деле, выбор задачи клиент осуществляет из списка доступных ему шаблонов. То есть клиенту не нужно «объяснять» центру сертификации, какой в действительности сертификат он хочет и что в этом сертификате ему нужно. Клиент, например, сообщает: «Необходим сертификат для аутентификации сервера по протоколу SSL». Этого достаточно. Сервер знает, какой должен быть сертификат и что в нем должно быть. Его интересует лишь личная информация клиента.

Получив запрос, центр сертификации аутентифицирует его в Active Directory. Это нужно для того, чтобы убедиться в подлинности запроса (что прислал запрос тот самый пользователь, который прописан в Active Directory и о котором есть информация). Далее центр сертификации выдает сертификат, который помещается в персональное хранилище клиента. С этого момента клиент является полноценным участником инфраструктуры открытых ключей и может полноправно работать.

Теперь посмотрим, что нового в данном контексте привнесла операционная система Windows Server 2003. Прежде всего, система делает работу пользователей комфортнее, позволяя автоматизировать процесс получения сертификатов абсолютно для всех служб, которые их используют. В Windows 2000 такая опция была возможна только для получения сертификатов машин при установлении IP Security. Во всех остальных случаях запрос сертификата и обновление (если его срок истекал) клиент должен был делать вручную. В случае с Windows Server 2003 и Windows XP у каждой службы есть очень простая настройка Enroll Certificates Automatically (смотрите рисунок ниже).

Достаточно лишь активизировать эту опцию и можно забыть о том, как все дальше будет функционировать. Таким образом, клиент полностью избавлен от забот о получении и обновлении сертификатов.

Стоит немного остановиться на шаблонах (на рисунке выше можно видеть слово «templates»). Что такое шаблон? Шаблон в общем виде представляет собой некий документ или некую заготовку. Для каждой задачи существует своя собственная заготовка, но все заготовки хранятся в Active Directory. Типичный пример задачи, для которой существует шаблон — идентификация сервера или идентификация клиента. Вообще же есть шаблоны для шифрующей файловой системы, IP Security, смарт-карт и т.д. Widows Server 2003 вводит новую версию шаблонов (версию 2), при этом все старые шаблоны из Windows 2000 остаются. Набор шаблонов в Windows 2000 был фиксированным и неизменяемым. Версия 2, реализованная в Windows Server 2003, представляет расширенные шаблоны, которые можно модифицировать и копировать. На базе новых шаблонов можно создавать свои собственные шаблоны.

Если открыть консоль Active Directory Sites and Services, раздел Services и далее Public Key Services, то можно найти место, где на самом деле хранится и зарегистрирована вся информация, касающаяся центра сертификации.

Там есть специальный раздел, который показывает список шаблонов сертификатов. Часть из них относится к версии 1, часть — к версии 2. Например, сертификат под названием Work Station — это сертификат по шаблону версии 2. Можно вносить информацию в него и модифицировать его параметры. Администратор имеет право самостоятельно выбрать алгоритм, ключи, имена, особенности выдачи и т.д.

Сертификат по шаблону версии 1 выглядит значительно проще. Его нельзя изменять, можно лишь просматривать имеющиеся у него значения.

Таким образом, для получения сертификата на конкретную задачу клиент должен указать имя шаблона. На каждый из шаблонов администратор может установить права: на закладке Security есть специальное правило, которое называется Enroll. Соответственно, если у пользователя эта опция (правило) активирована, значит, он имеет право запрашивать сертификат по данному шаблону. Если нет, то данный сертификат клиент никогда не получит.

Когда клиент обращается к центру сертификации с запросом на сертификат, центр сертификации аутентифицирует клиента и выдает список доступных данному конкретному клиенту шаблонов. Лишь из этого списка клиент выбирает тот сертификат, который ему нужен.

В самом центре сертификации есть дополнительная градация (закладка под названием Certificate Template). В отличие от шаблонов, которые были показаны в закладке Services, в Certificate Template показаны те шаблоны, которые выдает данный центр сертификации. Иными словами, клиент может запрашивать сертификаты именно из этого списка (данный список меньше, чем список всех существующих шаблонов). Администратор может добавлять какие-то новые шаблоны и расширять список шаблонов центра сертификации.

Следующим важным компонентом инфраструктуры открытых ключей является список отозванных сертификатов (CRL, Certificate Revocation List). Если клиенту выдан сертификат, то «отобрать» его обратно невозможно. Но бывают случаи, когда пользоваться данным сертификатом больше нельзя. Например, это может быть не безопасно, так как личный ключ пользователя скомпрометирован. В этом случае информация об отзыве сертификата помещается в специальный список, который называется CRL — список отозванных сертификатов. Одной из обязанностей центра сертификации является поместить серийный номер отзываемого сертификата в список CRL и обеспечить его целостность с помощью цифровой подписи на основе личного ключа центра сертификации. В этом случае неавторизованные клиенты не смогут модифицировать список отозванных сертификатов. Между тем сам список помещается в общедоступном месте.

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

Windows Server 2003 предлагает еще одну дополнительную возможность, предназначенную для публикации отозванных сертификатов. Речь идет о Delta CRL. Для чего нужно публиковать Delta CRL? Дело в том, что когда у предприятия много клиентов инфраструктуры открытых ключей и, следовательно, используется много сертификатов, вполне логично предположить, что и список отозванных сертификатов тоже окажется достаточно большим. На рисунке выше представлен интерфейс, позволяющий настраивать параметры публикации списка отозванных сертификатов. На рисунке видно, что срок публикации полного списка измеряется неделями. Что делать, если CRL публикуется раз в неделю, например, по понедельникам, а во вторник центр сертификации отозвал чей-то сертификат? Хотя формально сертификат отозван, но информация об этом будет опубликована только через неделю, когда выйдет следующая версия списка CRL. Получается, что целых 6 дней клиент потенциально может продолжать работу со своим сертификатом (которому уже нельзя доверять).

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

Еще одной важной возможностью центра сертификации в Windows Server 2003 по сравнению с Windows Server 2000 является архивирование личных ключей. На рисунке выше представлен фрагмент графического интерфейса шаблона сертификата, позволяющего архивировать личный ключ пользователя. В настройках же самого центра сертификации есть еще одна опция, которая определяет, будет ли архивирование ключей работать вообще. По умолчанию архивирование ключей отключено, но его можно включить. Тогда для тех запросов на сертификаты, которые используют шаблон с отмеченной опцией архивирования, личный ключ клиента будет попадать в защищенный архив (откуда его потом можно извлечь по необходимости). Для работы этого архива используется специальная учетная запись, которой присваивается статус «Агент восстановления ключей». Агент восстановления ключей (KRA — Key Recovery Agent) должен получить соответствующий сертификат и иметь свой личный ключ. Сертификат, принадлежащий агенту восстановления ключей, должен быть занесен в политику восстановления в настройках центра сертификации.

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

Для того чтобы ключ попал в архив, клиент должен обратиться к центру сертификации с запросом несколько иного формата. По протоколу CMS он посылает серверу не просто свой открытый ключ (с информацией о себе), но еще и свой личный ключ. Для этого используется дополнительный формат этого запроса. Центр сертификации получает оба ключа вместе с запросом и проводит дополнительную проверку. Понятно, что открытый и личный ключи должны взаимнооднозначно друг другу соответствовать. Не бывает так, что одному личному ключу соответствуют два открытых. Поэтому проверка, осуществляемая центром сертификации, проводится с помощью элементарных вычислений. После того, как появилась уверенность, что личный и открытый ключи соответствуют друг другу и образуют пару, генерируется 128-битный ключ для алгоритма 3DES. Это симметричный алгоритм и ключ для него создается индивидуальным образом для каждого запроса. Далее с помощью алгоритма 3DES и уникального ключа происходит процесс шифрования личного ключа пользователя. Результат шифрования представляет собой первый блок данных, помещаемый в архив. Следующий этап защиты заключается в том, чтобы защитить сам симметричный ключ. Для этого используется открытый ключ агента восстановления из его (агента) сертификата, который в свою очередь был занесен в политику центра сертификации. Таким образом, в архив укладывается два блока: симметричный ключ, которым зашифрован личный ключ пользователя, и симметричный ключ, который сам зашифрован открытым ключом агента восстановления. Для того чтобы извлечь данные из архива, нужно взять личный ключ агента восстановления, расшифровать симметричный ключ, а уже с помощью симметричного ключа расшифровать личный ключ пользователя.

Получается следующая ситуация. Есть компьютер, на нем расположен архив, но нет личного ключа агента восстановления. Этот личный ключ хранится где-то на смарт-карте или дискете — где угодно, но только не на этом самом компьютере с архивом. Поэтому даже если эту машину украдут, извлечь данные из архива без агента восстановления (без его личного ключа) — невозможно.

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

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

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

Промежуточные центры сертификации выполняют только одну функцию — они сертифицируют нижестоящий уровень, хотя при этом, конечно же, могут выдавать сертификаты и клиентам. Типовой является следующая иерархия: для того чтобы построить PKI на всей территории предприятия, создается трехуровневая инфраструктура. На выходе последним элементом в этой инфраструктуре является выдающий центр сертификации. Цепочка от корневого центра до выдающего — может быть достаточно длинной. Конечных пользователей обслуживает именно выдающий центр сертификации. Важно, что в каждый сертификат обязательно включается вся цепочка всех центров сертификации. Эта цепь называется «Certification Path» и показывает имена центров, которые были задействованы во всей иерархии от конкретного пользователя до корневого центра сертификации. Этот путь обязательно отслеживается, когда идет проверка сертификатов. Если участник инфраструктуры прислал сертификат на проверку, то проверяющий должен, на самом деле, убедиться в том, что он может доверять каждому участнику Certification Path. Иными словами, он должен проверить все центры, которые в этой иерархии задействованы. Для этого ему, естественно, нужно знать цепочку сертификации.

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

С помощью механизма ограниченной субординации и механизма маркирования политик, можно построить так называемую кросс-сертификацию инфраструктур. Она уместна в том случае, когда есть, например, два независимых предприятия (у каждого своя инфраструктура). Необходимо, чтобы клиенты одной инфраструктуры доверяли клиентам другой инфраструктуры. Такое доверие выполняется с помощью механизма кросс-сертификации, который в Windows 2003 реализован посредством ограниченной субординации и маркирования политик в рамках этого механизма.

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

Службы защиты информации Windows Server 2003, использующие PKI

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

Прежде всего, служба аутентификации, которая реализована в системах Windows (разные версии системы могут использовать разные протоколы для разных ситуаций), может использовать цифровые сертификаты в том или ином режиме своей работы.

Любой учетной записи пользователя можно сопоставить сертификат. Соответственно, каждый, кто предъявит этот сертификат и подтвердит свое знание личного ключа (соответствующего именно этому сертификату), будет аутентифицирован в системе в контексте той учетной записи, к которой этот сертификат приписан. Формально можно одной учетной записи приписать много сертификатов и раздать их, например, партнерам информационной системы. Тогда эти партнеры, не имея своей персональной учетной записи в системе, смогут заходить в систему и регистрироваться в ней. Работать же они будут в строго ограниченном контексте той учетной записи, которая им была приписана.

Когда между хостами устанавливается соединение по IP Security, то в соответствии с протоколом IP Security выполняется взаимная аутентификация хостов. Она может проводиться либо по протоколу Kerberos, либо по цифровым сертификатам. Во втором варианте, чтобы получить сертификаты, потребуется PKI.

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

Аутентификация удаленного пользователя по протоколу EAP-TLS (EAP, Extensible Authentication Protocol) — наиболее мощный механизм аутентификации с использованием цифровых сертификатов. Фактически, по этому протоколу клиент аутентифицируется так же, как и в рамках протокола SSL, но только происходит это не при установлении web-сеанса, а при подключении к службе удаленного доступа.

Чрезвычайно важным применением PKI в службе аутентификации является аутентификация пользователя в домене с использованием смарт-карт. Этот механизм построен на базе стандарта Kerberos PKINIT. Что касается поддержки смарт-карт, то она встроена во все операционные системы, начиная с Windows 2000. В состав системы также входят криптопровайдеры и драйверы для смарт-карт Schlumberger, Gem-Plus и других крупных поставщиков. К этому набору всегда можно подключить и другие решения. Например, компания Aladdin выпускает e-token, которые по своей природе и являются смарт-картами, только в другом оформлении — в виде USB-ключа. Для этих смарт-карт тоже нужен криптопровайдер. Механизм работы при аутентификации с использованием e-token абсолютно тот же, что и при использовании смарт-карт.

Понятно, что аутентификация по смарт-картам является более надежной по сравнению с простой аутентификацией по паролю. Дело в том, что смарт-карта предполагает двухфакторную аутентификацию. Нужно иметь смарт-карту с защищенным микрочипом, в который встроен в шифровальный механизм и на котором надежно хранятся личный ключ и сертификат пользователя. Единственное, что остается пользователю — запомнить свой pin-код. Таким образом, аутентификация проходит в два этапа: сначала пользователь должен подтвердить свое владение смарт-картой и ввести правильный pin-код, а уже потом в системе он будет аутентифицирован в соответствии со стандартом PKINIT.

Kerberos PKINIT

Рассмотрим процесс аутентификации по смарт-карте подробнее (предполагается, что читатель знаком с тем, как работает протокол Kerberos). На первом этапе аутентификации по Kerberos клиент должен получить билет TGT (Ticket Grand Ticket). Для этого требуется пройти долгий путь. Пользователь вставляет смарт-карту в считывающее устройство и вводит pin-код. Если pin-код — правильный, то смарт-карта выходит из состояния блокировки и модуль Kerberos формирует стандартный запрос к центру распределения ключей. Запрос включает в себя специальный аутентификатор, который представляет собой некий набор информации, уникальной для данного пользователя. В этот аутентификатор входит штамп текущего времени, а сам аутентификатор подписывается личным ключом пользователя (личный ключ находится на смарт-карте). Вторая составляющая этого запроса — это сертификат пользователя. Вся эта информация отсылается на центр распределения ключей. Центр распределения ключей получает сертификат, который ему прислали, и проверяет его правомочность. Для этого требуется обратиться к Active Directory, проверить наличие там учетной записи, потом проверить целостность сертификата и цифровую подпись, которой был подписан этот сертификат, найти центр сертификации, который выдал данный сертификат и проверить валидность уже самого центра и т.д. Цепочка очень длинная, но важен итог. Если все завершилось успешно и сертификат проверен, значит можно ему доверять. После этого KDC берет открытый ключ пользователя из сертификата и проверяет аутентификатор.

Цифровая подпись, которая была создана с помощью личного ключа пользователя, может быть проверена его открытым ключом. Если проверка проходит успешно, то центр распределения ключей считает, что информация, которая была прислана от имени пользователя, на самом деле является правильной и тот, кто прислал свой сертификат, действительно владеет личным ключом, соответствующим данному сертификату. Поэтому в ответ центр распределения ключей посылает клиенту билет TGT (Ticket Grand Ticket). В этот же ответ входит сеансовый ключ для дальнейшего взаимодействия клиента с данным сервером. Естественно, сеансовый ключ зашифровывается с помощью открытого ключа пользователя, который берется из сертификата. В ответ включается и собственный сертификат сервера. Все эти сведения подписываются личным ключом сервера.

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

Для дальнейшего взаимодействия с сервером клиент посылает билет TGT, а данные зашифровываются с помощью сеансового ключа, который знает теперь только клиент. Сервер всегда может извлечь ключ из билета TGT, так как тот всегда присылается при дальнейшем взаимодействии.

Приведенный выше протокол — это стандартный механизм аутентификации по смарт-карте. Этот алгоритм точно также функционировал в Windows 2000, ничего принципиально нового в этом контексте Windows Server 2003 не принес.

Улучшение, касающиеся смарт-карт, представляют собой некоторое развитие интерфейса взаимодействия. В частности, Windows XP и Windows 2003 поддерживают аутентификацию по смарт-картам в терминальной сессии, правда, при условии, что терминальным сервером является Windows 2003, а терминальным клиентом — Windows XP. Кроме того, утилита Run As позволяет теперь задать пользователя, не вводя его имя и пароль. Эти данные замещаются сертификатом. Утилита Run As позволяет запускать приложения от имени другого пользователя, то есть не того, который в данный момент зарегистрирован на станции.

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

Но не одна лишь служба аутентификации использует инфраструктуру открытых ключей. Следующее очень важное приложение PKI — это шифрующая файловая система (EFS). Смысл EFS заключается в том, чтобы обеспечить шифрование данных прямо на уровне файловых операций. Такой подход избавляет пользователя от необходимости запускать команды «Зашифровать файл» и «Расшифровать файл». Пользователю надо лишь активизировать свойство файла: «Шифровать файл». Все остальные операции будут проходить прозрачно и пользователь даже не заметит, что операционная система работает с файлом как-то по-другому.

Все операции выполняются на уровне кластеров файловой системы. При этом нужно понимать, что файл будет зашифрован в тот момент, когда он будет помещен на диск. Во время того, как пользователь открывает файл, операционная система расшифровывает его на лету. Таким образом, загружается уже расшифрованный файл. Соответственно, перемещение файла куда-либо за пределы тома NTFS приведет к передаче файлов в открытом виде. Если файл зашифрован на диске, а необходимо его скопировать на дискету, то операционная система сначала расшифрует файл (абсолютно прозрачно для пользователя), а потом перенесет его на другую файловую систему. То же самое происходит, когда пользователь пересылает файл по сети. В сеть этот файл попадает уже в расшифрованном виде.

Новая возможность Windows Server 2003 и Windows XP заключается в появлении графического интерфейса для подключения других пользователей к зашифрованному файлу. Windows 2000 позволяла работать с зашифрованным файлом только его владельцу. Никто другой никаким образом доступа к этому файлу не имел (за исключением агента восстановления файлов, который прописывался в политике восстановления файлов). Windows XP и Windows 2003 позволяют не использовать агента восстановления зашифрованных файлов. В этом случае единственный способ сохранить (спасти) зашифрованную информацию при потере ключа — это использование архива ключей. Если не велся архив ключей и не был включен агент восстановления файлов, то при потере личного ключа пользователь безвозвратно теряет данные, которые он зашифровал в EFS.

Рассмотрим теперь процессы шифрования и расшифрования. Здесь нет коренных изменений по сравнению с Windows 2000. Единственная новинка заключается в небольшом дополнении под словами «Шифрование данных». Раньше использовались только алгоритмы DESX, а сейчас Windows XP и Windows Server 2003 могут использовать алгоритм AES (Advanced Encryption Standard) — современный стандарт шифрования в США с ключом 128 бит. На картинке выше (процесс шифрования) можно видеть слева незашифрованный файл и внизу шифровальные модули, которые генерируют индивидуальный ключ File Encryption Key (FEK) специально для данного файла. С помощью этого ключа файл зашифровывается по алгоритму DESX или AES. Далее из шаблона EFS извлекается открытый ключ пользователя, с его помощью шифруется секретный симметричный ключ File Encryption Key. Получается заголовок расшифрования файлов, который называется Data Decryption Field. Этот процесс повторяется еще раз, но уже симметричный ключ шифруется на открытом ключе агента восстановления, получается поле восстановления Data Recovery Field. На этом этапе уже становится ясно, где на самом деле есть возможности для добавления еще одного пользователя. В Windows 2000 на этом процедура заканчивалась (было только два поля). Windows Server 2003 позволяет повторить процесс и для других пользователей. В этом случае будет создано несколько заголовков Data Decryption Field. Соответственно, тот, кто на этом этапе был подключен, сможет с этим файлом полноправно работать.

Для полноты описания рассмотрим процесс расшифрования файла, который выполняется, естественно, в обратном порядке. Сначала с помощью личного ключа пользователя расшифровывается заголовок DDF, из него извлекается File Encryption Key, с помощью которого расшифровываются данные. Если личный ключ пользователя недоступен, то можно провести ту же процедуру, но используя личный ключ агента восстановления. Если агент восстановления не был определен, но было организовано архивирование ключей, можно восстановить личный ключ пользователя из архива. Если архивирование ключей тоже не работает, то доступ к файлу получить не удастся.

Выбор алгоритма, который используется для шифрования файла, производится путем перевода системы из стандартного режима в так называемый режим «FIPS 140-1 Compliant». В этом режиме система начинает использовать шифровальные модули уровня ядра. Это переключение делается в настройках локальной политики безопасности и требует указать всего один-единственный параметр «Enable». После этого система переходит в режим поддержки совместимости с требованиями FIPS 140-1. В этом случае симметричным алгоритмом шифрования файла будет AES.

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

Ссылки

В заключение хочется порекомендовать список ресурсов, позволяющих детально ознакомиться с возможностями PKI в Windows Server 2003.

Механизм выдачи сертификатов (AutoEnrollment)

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

Архивирование ключей

Руководство по управлению всей инфраструктурой

В командной строке вводим:

Signature Algorithm:Algorithm ObjectId: 1.2.840.113549.1.1.5  sha1RSAIssuer:  CN=CorporateRootCANotBefore: 6/5/2002 7:47 PMNotAfter: 6/5/2012 7:54 PMSubject:  CN=CorporateRootCA

CA type: 3 -- Stand-alone Root CAENUM_STANDALONE_ROOTCA -- 3

ConfigurationDirectory   REG_SZ =  \concorp-ca-00CertConfigDBDirectory              REG_SZ =  C:WINDOWSsystem32CertLogDBLogDirectory           REG_SZ =  C:WINDOWSsystem32CertLogDBSystemDirectory        REG_SZ =  C:WINDOWSsystem32CertLogDBTempDirectory          REG_SZ =  C:WINDOWSsystem32CertLog

CRLPublicationURLs REG_MULTI_SZ =    0: 65:C:WINDOWSsystem32CertSrvCertEnroll%3%8%9.crl    CSURL_SERVERPUBLISH -- 1    CSURL_SERVERPUBLISHDELTA -- 40 (64)     1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10    CSURL_SERVERPUBLISH -- 1    CSURL_ADDTOCERTCDP -- 2    CSURL_ADDTOFRESHESTCRL -- 4    CSURL_ADDTOCRLCDP -- 8    CSURL_SERVERPUBLISHDELTA -- 40 (64)     2: 6:http://%1/CertEnroll/%3%8%9.crl    CSURL_ADDTOCERTCDP -- 2    CSURL_ADDTOFRESHESTCRL -- 4     3: 0:file://\%1CertEnroll%3%8%9.crl

Для начала, необходимо удалить все точки распространения CRL , кроме локальной.

1. На вкладке Extensions в Select extension выбираем CRL Distribution Point (CDP).

2. В Specify location from which users can obtain a certificate revocation list (CRL) выбираем LDAP, и кликаем по Remove.
3. Удаляем все, кроме локальной CRL.

Так, поудаляли все ненужное, теперь пришла пора создать новые точки распространения. Заполняем все, согласно таблице ниже, единственное что, в протоколе HTTP заменяем на имя своего внешнего домена. Также желательно www заменять на crl, чтобы не делать алиас www на контроллере домена. Итак, таблица:
List of CRL Distribution Points for CorporateRootCA

Путь [local] должен указывать текущий каталог Windows

Чтобы добавить точки распространения, необходимо нажать кнопку Add, и скопировать пути из таблицы.
После того, как пути введены, надо расставить птички из таблицы ниже:

Table 15 CRL Distribution Point Properties

Настройка точек распространения для AIA
1. Заходим туда, куда и в предыдущем пункте, только выбираем Authority Information Access (AIA).
2. В Specify locations from which users can obtain the certificate for this CA выбрать LDAP и нажать кнопку Remove.
3. Удалить все, кроме локального пути.
4. Далее, создаем новые пути, согласно таблице, но заменяя на свои реальные имена.

List of AIA CRL Distribution Points for Contoso

5. Далее, ставим птички в созданных точках распространения, согласно таблице:

AIA Properties

Проверка правильности настройки CorporateRootCA CRL и AIA
Поскольку конфигурация точек распространения CRL и AIA очень важна, проверьте свою конфигурацию, сделав одно из следующих действий:

Далее сверяем вывод с тем, что мы ввели в предыдущем разделе.

Если все правильно, то продолжаем:

Проверяем, что вывод схож с тем, как на примере:

CACertPublicationURLs REG_MULTI_SZ =    0: 1:D:WINDOWSsystem32CertSrvCertEnroll%1_%3%4.crt    CSURL_SERVERPUBLISH -- 1    1: 2:ldap:///CN=%7,CN=AIA,CN=Public KeyServices,CN=Services,%6%11    CSURL_ADDTOCERTCDP -- 2    2: 2:http://www.contoso.com/pki/%1_%3%4.crt    CSURL_ADDTOCERTCDP -- 2

Настройка интервала рубликации CRL
После настройки точки распространения CRL, мы должны сконфигурировать интервал публикации CRL. Чтобы это сделать, надо:
1. Нажать Start, Programs, Administrative Tools, и выбрать Certification Authority.
2. В дереве консоли слева, делаем правый клик по Revoked Certificates, и выбираем Properties.
3. В секции CRL publication interval, необходимо интервал, и выбрать единицу измерения времени. В моем случае это 6 месяцев.
4. Проверить, что напротив пункта Publish Delta CRLs не стоит птичка.

Переиздание CorporateRootCA CRL
В консоли Certification Authority делаем правый клик по Revoked Certificates и в меню All Tasks нажимаем Publish. В открывшемся окне выбираем New CRL. Новый CRL опубликован.
Также можно опубликовать CRL с командной строки, надо ввести

certutil -CRL

Вот