В ожидании выпуска Windows .NET Server, известного ранее как Whistler, самое время поговорить о возможностях новой операционной системы, связанных с поддержкой инфраструктуры шифрования с открытым ключом PKI. Я полагаю, что читатели имеют некоторое представление о PKI и технологии шифрования. С кратким обзором возможностей .NET Server PKI и других усовершенствований системы безопасности .NET Server и Windows XP можно ознакомиться в статье «Защита данных в среде Windows .NET Server», опубликованной в предыдущем номере журнала. PKI базируется на асимметричной криптографии (т. е. криптографии, использующей для шифрования и дешифровки различные ключи) и обеспечивает высокую степень защиты для внутренних и внешних пользователей сети, компьютеров и приложений.
В эпоху всеобщей компьютеризации значение таких служб, как PKI, стремительно растет.
В ожидании выпуска Windows .NET Server, известного ранее как Whistler, самое время поговорить о возможностях новой операционной системы, связанных с поддержкой инфраструктуры шифрования с открытым ключом PKI. Я полагаю, что читатели имеют некоторое представление о PKI и технологии шифрования. С кратким обзором возможностей .NET Server PKI и других усовершенствований системы безопасности .NET Server и Windows XP можно ознакомиться в статье «Защита данных в среде Windows .NET Server», опубликованной в предыдущем номере журнала. PKI базируется на асимметричной криптографии (т. е. криптографии, использующей для шифрования и дешифровки различные ключи) и обеспечивает высокую степень защиты для внутренних и внешних пользователей сети, компьютеров и приложений.
Центр сертификации (Certification Authority, CA) от Microsoft, впервые появившийся в составе пакета Windows NT 4.0 Option Pack, все еще остается для многих администраторов основным средством создания сертификатов для Secure Sockets Layer (SSL). Дальнейшее развитие служба CA получила в Windows 2000, использующей Active Directory и обеспечивающей лучшую масштабируемость, интеграционные возможности и поддержку многоуровневых иерархий PKI. Однако и в CA Windows 2000 отсутствуют такие важные функции, как избирательное администрирование PKI (например, делегирование администратору права санкционировать выдачу сертификатов только определенной группе пользователей), дополнительные возможности конфигурирования сертификатов и CA (например, изменение формата сертификата или развитые возможности аудита CA), а также средства для быстрого создания собственных PKI-приложений для расширения платформы PKI. Из-за этих недостатков компании могут отказаться от внедрения PKI на базе Windows.
Новая инфраструктура PKI, реализованная Microsoft в .NET Server и предназначенная для работы с Windows XP в качестве клиента, свободна от большинства недостатков более ранних версий PKI. Сервер PKI в версии .NET поддерживает перекрестную сертификацию (в том числе иерархическую), обеспечивает ограничение полномочий подчиненного CA, усовершенствованное резервное копирование и восстановление ключей, автоматическую регистрацию пользователей и ведение дельта-списков аннулированных сертификатов (CRL).
Возможности PKI выходят за рамки одного предприятия
Ранние версии Windows PKI были основаны на иерархической модели доверия CA, состоящей из многочисленных уровней CA, связанных между собой доверительными отношениями главного и подчиненного центров сертификации CA. В этой модели подчиненные центры CA сертифицируются главным центром CA. В отличие от реализации PKI в NT, Windows 2000 PKI поддерживает неограниченное число уровней CA. Специалисты Microsoft проводили тестирование работы 35 уровней.
Иерархическая модель CA имеет существенный недостаток: дело в том, что распространить установление доверительных отношений за пределы одного предприятия нелегко. В первую очередь это происходит из-за отсутствия поддержки иерархической моделью механизма субординации компетенций (qualified subordination), при котором полномочия подчиненных CA ограничиваются политикой безопасности главных CA.
Благодаря кросс-сертификации и ограничению полномочий подчиненных CA, сервер .NET PKI обеспечивает эффективный метод установления отношений доверия с CA внешних партнеров компании. Центры CA различных организаций могут сертифицировать друг друга и применять по отношению друг к другу специальные правила для ограничения количества выдаваемых сертификатов и их области действия.
Кросс-сертификация и безопасность во внешних сетях. Иерархическая модель PKI создавалась без учета возможного установления отношений доверия за пределами одного предприятия. Поэтому ее достаточно трудно использовать для построения единой системы защиты сетей различных предприятий. Типовая схема безопасности предприятия учитывает использование собственного центра CA или даже иерархии CA. Политика безопасности CA в организациях тоже может различаться.
Чтобы предприятия могли взаимодействовать при помощи PKI в NT, они должны входить в состав единой иерархии. Поскольку все участники предстоящего объединения обычно эксплуатируют собственную иерархию или хотя бы один CA, это требование предполагает полную перестройку всей инфраструктуры доверительных отношений PKI. В реализации PKI в Windows 2000 используются доверительные списки сертификатов (CTL). CTL является объектом групповой политики Group Policy Object (GPO) и применяется для распространения сертификатов CA внутри леса Windows 2000, а также маркировки этих сертификатов как доверенных на указанный период времени или для указанных PKI-совместимых приложений.
Реализация кросс-сертификации в .NET PKI предоставляет более мощные возможности для защиты сетей предприятий и установления доверительных отношений PKI. В иерархии CA сертификация является однонаправленной операцией: главный CA выпускает сертификат для подчиненного CA. Кросс-сертификация является двусторонней операцией: оба CA выдают сертификаты друг другу. Сервер .NET PKI поддерживает кросс-сертификацию двух видов. Политика ограничения прав подчиненного центра сертификации осуществляется между CA, которые являются частью одной организации (или одного леса, если использовать терминологию AD); истинная кросс-сертификация осуществляется между CA, которые являются частью разных организаций (или принадлежат разным лесам). Информацию о влиянии кросс-сертификации на пользователей PKI можно найти во врезке «Кросс-сертификация и пользователь PKI».
Генерация кросс-сертификата на платформе .NET Server выполняется в три этапа. Сначала создается определение политики, которое описывается в файле конфигурации capolicy.inf. Capolicy.inf создается вручную и является текстовым файлом, для его редактирования можно пользоваться любым текстовым редактором, например Notepad, и хранить в любом месте, доступном для утилиты командной строки Certreq.
На втором этапе используется Certreq, файл capolicy.inf и стандарт шифрования с открытыми ключами PKCS
№10 — форматированный CA запрос сертификата для генерации форматированного сообщения Cryptographic Message Syntax (CMS). PKCS №10 и CMS являются стандартами, определяющими формат криптографических сообщений.
На третьем этапе CA генерирует кросс-сертификат при помощи форматированного сообщения CMS. Дополнительную, постоянно обновляемую информацию о кросс-сертификации и ограничении подчиненных CA, можно получить по адресу: http://www.microsoft.com/windows.netserver.
Ограничение полномочий подчиненного CA и управление правилами. Модели PKI в Windows 2000 и Windows NT предполагают полное доверие между главным и подчиненным CA. Это означает, что после выдачи главным CA сертификата подчиненному CA последний может выдавать сертификаты без каких-либо ограничений. Сервер .NET PKI позволяет модифицировать полномочия подчиненного CA и обеспечивать встроенную поддержку назначения и выполнения ограничений по именам и типам приложений, а также управление правилами. Эти правила кратко описаны во врезке «Управление правилами PKI в .NET Server».
Реализованные в сервере .NET шаблоны сертификатов второй версии позволяют определить политику ограничений по отношению к пользователю, компьютеру, подчиненному CA и службе сертификатов. Дополнительную информацию о второй версии шаблонов сертификата можно найти во врезке «Вторая версия шаблонов сертификата». Политика ограничений для кросс-сертификации реализуется при помощи настроек файла capolicy.inf.
Методы резервного копирования и восстановления ключей
PKI обладает способностью восстанавливать утраченные или недоступные личные ключи шифрования. Для успешного восстановления ключей требуется эффективная и защищенная система их резервного копирования. А после того, как ключ восстановлен, можно получить доступ и к данным: пользователь или уполномоченный администратор получает доступ к личному ключу, чтобы воспользоваться им для декодирования шифрованных симметричных ключей, при помощи которых была зашифрована конфиденциальная электронная почта или файлы.
Предыдущие версии Windows обеспечивали возможность восстановления ключей для двух приложений: Encrypting File System (EFS) и поставляемого с сервером Microsoft Exchange приложения защищенной электронной почты, основанной на Secure MIME (S/MIME). Эти приложения используют слегка отличающиеся механизмы резервного копирования ключей. EFS хранит ключи и шифрованные файлы в NTFS, а Exchange — в специальной базе данных. Версия PKI в .NET Server базируется на концепции централизованного хранения ключей в базе данных и специальной службе восстановления, которой может пользоваться любое совместимое с PKI приложение.
Необходимые для восстановления ключей данные хранятся в сервере .NET локально, в базе CA. CA шифрует архивируемый закрытый ключ симметричным ключом, а затем шифрует симметричный ключ открытым ключом агента восстановления (агент восстановления — это учетная запись с привилегиями восстановления ключей). CA сохраняет зашифрованный закрытый ключ в разделе RawArchivedKey базы данных CA, а зашифрованный симметричный ключ — в разделе KeyRecoveryHashes. Администратор имеет возможность просмотреть эти и другие разделы базы при помощи команды
certutil -schema
Для восстановления закрытых ключей из базы данных CA администратор должен обладать специальным сертификатом агента восстановления и закрытым ключом. Подобно службе Key Management Service (KMS) сервера Exchange, управляющей восстановлением ключей из базы S/MIME, .NET Server CA поддерживает систему многоуровневых разрешений: в системе с высокой степенью безопасности для восстановления ключа администратор CA должен обладать множеством сертификатов, разрешающих восстановление. Этот принцип защиты был позаимствован у военных, он состоит в том, что один человек не может самостоятельно запустить ракету, требуется одновременное действие двух ключей, которые расположены в разных местах. В применении к информационной безопасности это означает, что недобросовестный администратор не сможет в одиночку получить доступ к чужим конфиденциальным данным.
|
| Экран 1. Назначение агентов восстановления. |
Последовательность восстановления ключа .NET Server CA включает следующие шаги.
- Агент восстановления ключа записывает UPN-имя пользователя или серийный номер сертификата пользователя, чей закрытый ключ будет восстанавливаться.
- Для восстановления данных из базы CA агент восстановления ключа вводит в командной строкеcertutil -getkey <серийный номер или UPN> <файл вывода>.
- Для трансляции полученного файла вывода в формат PKCS №12 (который будет содержать восстанавливаемый закрытый ключ) агент вводитcertutil -recoverkey <файл вывода> .
- Агент передает файл PKCS №12 соответствующему пользователю, который импортирует его в свое хранилище сертификатов.
Можно использовать оснастку Certificate Templates для резервного копирования ключа на уровне шаблона сертификата. Для включения автоматического архивирования закрытого ключа в тот момент, когда пользователь запрашивает сертификат по определенному шаблону, следует открыть шаблон, перейти на закладку Request Handling, выбрать переключатель Archive subject's encryption private key. Данная возможность есть только у шаблонов сертификата версии 2.
Автоматическая регистрация пользователя
Windows 2000 поддерживает автоматическую регистрацию и продление срока действия компьютерных сертификатов. Это свойство используется компьютерами для доступа к контроллерам домена через туннель IPSec. Сервер .NET распространил действие автоматической регистрации на пользователей, что значительно упрощает работу с PKI. Для реализации этой функции необходима доработка операционной системы клиента, а на сегодня это сделано только в XP.
Автоматическая регистрация пользователей требует внесения конфигурационных изменений в оснастки MMC Certificate Templates и Group Policy. Для включения автоматической регистрации на уровне шаблона следует загрузить оснастку Certificate Templates, открыть шаблон, перейти на закладку Security и предоставить пользователям или группам право доступа Autoenroll. Чтобы включить автоматическую регистрацию на уровне GPO, следует открыть оснастку Group Policy, перейти по адресу Computer ConfigurationWindows SettingsSecurity SettingsPublic Key Policies, открыть диалоговое окно Autoenrollment Settings Properties (см. Экран 2). Как и в Windows 2000, настройка автоматической регистрации компьютеров здесь осуществляется в контейнере Automatic Certificate Request Settings из GPO Public Key Policies.
По умолчанию автоматическая регистрация выполняется, когда пользователь регистрируется в домене. Однако пользователь может затребовать регистрацию в любой момент. Для этого ему следует в оснастке MMC Certificates открыть личный контейнер сертификатов (т. е. контейнер Current User или My User Account), выбрать из меню Actions, All Tasks, Automatically Enroll Certificates. Каждый раз при выполнении автоматической регистрации в панели задач пользователя появляется предупреждающее сообщение. Если щелкнуть на нем мышью, появится диалоговое окно с предложением подтвердить начало процесса регистрации.
Дельта-списки CRL
Метод работы Windows 2000 PKI со списками отозванных сертификатов CRL имеет ряд недостатков. Списки CRL обладают постоянной тенденцией роста из-за накопления в них информации об аннулированных сертификатах. Это приводит к необходимости передавать по каналам связи большие объемы данных. Хотя в Windows 2000 списки CRL могут различаться по номеру версии, однако и новая версия наследует из предыдущей всю информацию об аннулированных сертификатах, поэтому CRL может стать меньше только по истечении срока действия сертификата. Итак, каждая новая версия CRL вынуждает клиента загрузить полный список CRL, что отрицательно сказывается на полосе пропускания каналов связи. В результате, увеличивая срок действия CRL, администраторы стремятся как можно реже запрашивать CRL (CRL хранятся в кэше клиента в течение всего срока действия списка). Однако это приводит к тому, что информация об аннулированных сертификатах не будет получена своевременно.
Для решения данной проблемы в .NET Server PKI включена поддержка дельта-списков CRL. Как показано на Рисунке 1, дельта-списки CRL невелики и содержат только изменения, появившиеся после того, как клиент последний раз загрузил полную версию CRL. Поскольку дельта-списки малы, клиенты PKI могут загружать их регулярно, чтобы всегда получать от CA актуальную информацию об аннулированных сертификатах. Конфигурирование дельта-списков производится при помощи оснастки Certification Authority в диалоговом окне Properties контейнера Revoked Certificates.
|
| Рисунок 1. Принцип работы дельта-списков CRL. |
PKI — в массы
Мы рассмотрели ряд важнейших свойств .NET Server PKI, обойдя вниманием немало других. Например, эта версия PKI позволяет осуществить гибкое разделение ролей и делегирование полномочий администрирования, в точном соответствии со стандартами США Common Criteria IT security. Центр сертификатов CA сервера .NET обладает расширенными возможностями аудита. В помощь разработчикам криптографических функций для совместимых с PKI приложений (например, электронной подписи, манипуляций с хранилищем сертификатов) предоставляется COM-объект, называемый CAPICOM.
Неизменным остается лишь одно (козырная карта Microsoft) — низкая стоимость продуктов Windows PKI. Следует только помнить, что программное обеспечение CA включено не во все продукты Microsoft, а только в Windows .NET Enterprise Server (бывший Windows 2000 Advanced Server) и Windows .NET Datacenter Server.
Жан де Клерк — консультант корпорации Compaq, специалист по проблемам безопасности продуктов семейства Microsoft BackOffice. С ним можно связаться по электронной почте по адресу: jan.declercq@compaq.com.
Кросс-сертификация и пользователь PKI
|
|
| Рисунок А. Иерархическая модель CA. |
Обратной стороной медали, с точки зрения пользователя, является усложнение маршрута, который проходит сертификат для получения подтверждения. Программы подтверждения полномочий сертификатов по-прежнему должны учитывать иерархию доверительных отношений организации, а также отношения доверия при кросс-сертификации. Из этого следует, что программный клиент, работающий с сервером .NET PKI, должен различать механизмы подтверждения в иерархической и перекрестной сертификациях. Таким требованиям удовлетворяет Windows XP. Компания Microsoft предоставляет специальные утилиты, добавляющие поддержку механизма перекрестной сертификации для ранних версий Windows.
Управление правилами в .NET Server PKI
Реализованная в сервере Windows .NET инфраструктура открытых ключей PKI поддерживает определение и установление ограничений по именам, типам приложений, а также управление правилами в соответствии с RFC 2459 (текст RFC доступен на сайте http://www.ietf.org). RFC 2459 определяет специальные дополнения для сертификата, описывающие правила управления PKI. Клиентская часть PKI должна уметь работать с сертификатами, содержащими правила. К моменту написания статьи этому требованию удовлетворяли только клиенты Windows XP. Однако проблема с более ранними системами Windows решается путем установки дополнительного программного обеспечения Microsoft.
Ограничения по именам применимы только к сертификатам CA. Эти правила определяют адресное пространство, которое содержит связанные с сертификатами имена, выпущенные главными или подчиненными CA. Адресное пространство может базироваться на формате имен DNS, полных именах X.500 (DN), SMTP-адресах или использовать адресацию IP. Подчиненный CA может только усилить ограничения, но не ослабить действие правил, полученных от главного CA.
Политика ограничений для приложений определяет список разрешенных приложений для конкретного сертификата. Идентификатор объекта (OID) определяет политику ограничений. Новое расширение сертификата, называемое Application policy, заменяет расширение сертификата Enhanced Key Usage (EKU) системы Windows 2000.
Правила, регулирующие выпуск сертификатов центрами сертификации .NET Server, описываются расширением Certificate policies. Подобно политике ограничения приложений, ограничения на выпуск сертификатов определяются объектом OID. Политика позволяет накладывать ограничения в зависимости от способа идентификации пользователя в момент запроса сертификата от CA или способа хранения закрытого ключа (например, на смарт-карте). В Таблице А приведены три предопределенных уровня политики выпуска сертификатов: низкий, средний и высокий. Низкий уровень подходит для типичных моделей внутренних сетей компаний. Использование следующих двух уровней ориентировано на совокупность внутренних сетей, Internet или локальные сети со сложной политикой выпуска сертификатов.
Подобно ранним версиям Windows PKI, сервер .NET PKI продолжает поддерживать базовые правила политики ограничения. Эти правила определяют, является ли CA объектом сертификата, а также могут ограничивать длину цепи сертификации, используемую программным обеспечением PKI при последовательном подтверждении.
Вторая версия шаблонов сертификата
Шаблоны сертификатов впервые появились в Windows 2000, имели номер версии 1 и содержали набор предопределенных свойств, используемых по умолчанию центром сертификации предприятия CA для выпуска сертификатов (CA предприятия интегрирован с каталогом AD). Как и в случае с шаблонами версии 1, версия 2 может использоваться PKI сервера .NET только с CA масштаба предприятия. Свойства шаблонов версии 2 можно изменять при помощи оснастки Certificate Templates консоли MMC. Изменить шаблоны версии 1 невозможно.
Первое, что бросается в глаза при запуске оснастки Certificate Templates, — это то, что часть значков шаблонов серая, а часть выделена цветом. Серые значки принадлежат шаблонам версии 1, цветные (отмечены на Рисунке А) — шаблонам версии 2. Двойной щелчок мыши на объекте шаблона версии 1 позволяет просмотреть свойства шаблона, но не изменить их. Из оснастки шаблонов сертификатов можно выполнять следующие задачи.
? Копировать имеющийся шаблон, чтобы создать новый. Для дублирования шаблона следует щелкнуть на нем правой кнопкой мыши и выбрать из контекстного меню All Tasks, Duplicate Template. Эта возможность позволяет модифицировать шаблоны версии 1 путем их дублирования, сохранения как шаблонов версии 2 и последующего изменения свойств.
? Изменение свойств шаблонов сертификатов. В отличие от PKI в Windows 2000, PKI в .NET позволяет настраивать свойства сертификата (например, срок действия сертификата, период обновления) и расширения. В версии 2 шаблонов можно определять требования по регистрации сертификатов, контролю процесса подписи, конфигурации резервного копирования закрытого ключа, назначения конкретного провайдера службы шифрования Cryptographic Service Provider (CSP).
? Указывать, какие учетные записи имеют право регистрации и автоматической регистрации для отдельного шаблона сертификата. Для этого следует щелкнуть правой кнопкой мыши на шаблоне версии 2, открыть окно свойств, перейти на закладку Security и там изменить права доступа Enroll или AutoEnroll учетной записи.
? Разрешить использование шаблона для автоматической регистрации учетных записей пользователя и компьютера. Для этого следует щелкнуть правой кнопкой мыши по шаблону и выбрать из контекстного меню пункт Allow AutoEnrollment. В колонке Autoenrollment оснастки Certificate Templates можно проверить, разрешена ли автоматическая регистрация в шаблоне (см. Экран А). Для отдельных шаблонов можно включить принудительную автоматическую регистрацию. Для этого следует щелкнуть правой кнопкой мыши по шаблону и выбрать из контекстного меню Re-enroll all certificate holders.
? Автоматическая замена старых версий сертификатов на последние версии, содержащие новые свойства. Это можно сделать при помощи закладки Superseded Templates, как показано на Экране Б. Автоматическая замена является очень мощным средством в сочетании с возможностью автоматической регистрации. Замечательным примером может служить шаблон Directory Email Replication, замещающий более старый шаблон Domain Controller. Поскольку автоматическая регистрация в шаблоне Directory Email Replication разрешена, все контроллеры доменов DC автоматически (т. е. без вмешательства какого-либо пользователя или администратора) получат новый сертификат Directory Email Replication.
|
| Экран Б. Автоматическая замена шаблонов. |
Многие другие свойства .NET Server PKI, обеспечивающие расширенные возможности шаблонов версии 2, требуют дополнительного программного кода. На сегодня такой дополнительный программный код поставляется только в составе Windows XP.