Архивирование и восстановление — это службы инфраструктуры открытых ключей PKI, которые могут использоваться организацией для восстановления потерянных, похищенных или недоступных секретных ключей шифрования. Архивирование и восстановление ключей — актуальные функции для приложений, поддерживающих PKI, например приложений защищенной электронной почты, имеющих дело с данными постоянного хранения. Впервые технология централизованного автоматического архивирования и восстановления секретных ключей была предложена в службе Key Management Service (KMS), которая представляет собой часть почтовой системы Microsoft Exchange Server 4.0 и выше, базирующуюся на Secure MIME (S/MIME). В комплект поставки Exchange Server 2003 служба KMS не входит, поэтому, если в организации имеется работающая KMS в среде Exchange 2000 Server и планируется миграция на Exchange 2003, базу данных архивированных ключей KMS придется перенести в базу данных архивированных ключей центра сертификации Windows 2003 Server Certification Authority (CA). Более подробную информацию об этой процедуре можно найти во врезке «Миграция базы данных KMS Exchange». Имеющаяся в Windows 2003 технология архивирования и восстановления ключей построена на концепции KMS: каждый центр сертификации CA уровня предприятия в среде Windows 2003 имеет службу централизованного автоматического архивирования и восстановления ключей. Как описано во врезке «Ручное архивирование и обновление ключей», администраторы PKI могут выполнять соответствующие процедуры и вручную. В этой статье мы рассмотрим, как можно настроить в Windows 2003 процесс автоматического архивирования и восстановления ключей, а также познакомимся с принципами работы данной технологии.

Настройка автоматического архивирования и восстановления

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

Для настройки параметров архивирования ключей объекта CA используется оснастка Certification Authority консоли MMC. Необходимо открыть диалоговое окно Properties объекта CA и перейти на вкладку Recovery Agents. Чтобы включить функцию восстановления ключей, следует выбрать режим «Archive the key». Как и в KMS Exchange, в центрах CA среды Windows 2003 для восстановления ключей поддерживается фирменная технология: при восстановлении одного ключа из архивной базы данных можно затребовать несколько сертификатов ключа восстановления (Key Recovery certificate) и, соответственно, назначить несколько агентов ключа восстановления (Key Recovery Agent, KRA). KRA представляет собой учетную запись Windows, которая является владельцем сертификата ключа восстановления и секретного ключа, таким образом, данная учетная запись имеет право его восстанавливать. В инфраструктуре Windows 2003 PKI имеются предустановленные шаблоны сертификатов ключей восстановления, поэтому настройку сертификата ключа восстановления для конкретной учетной записи выполнить достаточно просто. Оптимальным с точки зрения безопасности решением является хранение сертификата KRA и секретного ключа на смарт-карте. Нужно указать в текстовом поле Number of recovery agents to use то количество агентов KRA, которое необходимо для ключа восстановления. Затем следует определить те сертификаты KRA, которые будут использоваться при архивировании ключа, для чего требуется нажать кнопку Add, расположенную в нижней части окна. Заметим, что можно задавать больше сертификатов KRA, чем требуется для ключа восстановления. При этом служба центра CA опрашивает контейнер KRA в контексте именования конфигурации Active Directory и возвращает список доступных сертификатов KRA (как показано на экране 1). Следует помнить, что после каждого добавления сертификата KRA необходимо перезапускать службу CA, в противном случае в колонке Status сертификата будет отображаться Not Loaded.

Чтобы разрешить архивирование ключей на уровне шаблона сертификата, требуется запустить оснастку Certificate Template консоли MMC. Для того чтобы включить процедуру автоматического архивирования секретного ключа пользователя PKI при запросе пользователем сертификата, соответствующего конкретному шаблону (например, шаблону New User), нужно открыть окно Properties данного шаблона и перейти на вкладку Request Handling. На этой вкладке необходимо установить флажок Archive subject?s encryption private key, как показано на экране 2. Следует иметь в виду, что это можно делать только в шаблонах сертификатов версии 2.

Экран 2. Вкладка Request Handling с флажком Archive subject?s encryption private key

Архитектура автоматического архивирования и восстановления

После того как было разрешено автоматическое архивирование ключей при каждом запросе архивирования секретного ключа, центр CA случайным образом генерирует симметричный ключ, соответствующий стандарту 3DES (Triple Data Encryption Standard), который используется для шифрования секретного ключа PKI клиента. Затем CA с помощью открытого ключа KRA, сконфигурированного для автоматического архивирования, производит шифрование симметричного ключа. Если было выбрано более одного агента KRA, то CA шифрует симметричный ключ, применяя ключи шифрования каждого из агентов KRA. Пошаговое описание процесса архивирования приведено ниже.

  1. Клиент PKI запрашивает AD о центре сертификации CA. Клиент выполняет целевой поиск записей CA в контейнере Enrollment Services в контексте именования конфигурации. В результате AD возвращает клиенту имя и расположение центра CA.
  2. Клиент PKI запрашивает у CA копию его сертификата CA Exchange. CA возвращает клиенту сертификат.
  3. Клиент PKI проверяет подлинность сертификата и его формат, проверяет подпись, а также удостоверяется в том, что сертификат не аннулирован.
  4. Клиент PKI шифрует клиентский секретный ключ, для чего используется открытый ключ сертификата CA Exchange. Используя протокол управления сертификатами с синтаксисом криптографических сообщений Certificate Management protocol with Cryptographic Message Syntax (CMC), клиент добавляет к данным шифрованный блок и направляет файл в формате CMC в центр CA.
  5. Центр CA дешифрует секретный ключ клиента с помощью секретного ключа, ассоциированного с сертификатом CA Exchange, а затем шифрует секретный ключ сформированным случайным образом симметричным 3DES-ключом.
  6. Центр CA проверяет, образуется ли криптографическая пара между секретным ключом в файле формата CMC и открытым ключом в запросе сертификата. При этом CA проверяет подлинность подписи в запросе, используя для этого открытый ключ, направленный вместе с запросом.
  7. Центр CA шифрует симметричный ключ, для чего используется один или несколько (в зависимости от конфигурации CA) открытых ключей агентов KRA.
  8. Центр CA сохраняет в своей базе данных шифрованный блок, содержащий шифрованный секретный ключ клиента и симметричный ключ шифрования.
  9. Центр CA обрабатывает запрос сертификата, высылает сертификат пользователю и помещает сертификат в соответствующий каталог (если этот параметр был выбран в шаблоне сертификата).

В этом процессе используется сертификат CA Exchange, с помощью которого обеспечивается конфиденциальность и защита целостности данных при передаче клиентом секретного ключа для его архивирования в CA. В новом шаблоне сертификата среды Windows 2003 задается содержимое сертификата. Сертификат CA Exchange физически размещается в атрибутах объекта AD CN=<имя CA>-Xchg, DC=<имя домена>. Секретный ключ сертификата находится в защищенной части реестра сервера CA. Из соображений безопасности пара «сертификат CA Exchange — ключ» имеет непродолжительное время жизни, равное 7 дням.

Клиентские секретные ключи и симметричные ключи хранятся в шифрованном виде в базе данных центра сертификации Windows 2003 CA. Клиентские секретные ключи отображаются в столбце RawArchivedKey, а симметричные ключи — в столбце KeyRecoveryHashes базы данных CA. Чтобы просмотреть эти столбцы и всю структуру схемы базы данных CA, нужно набрать в командной строке:

certutil -schema

Для того чтобы определить, имеются ли в базе данных CA секретные ключи сертификатов, можно воспользоваться оснасткой Certification Authority, как показано на экране 3. Для этого в контейнере CA Issue Certificates нужно добавить для отображения столбец Archived Key. Затем следует нажать правой кнопкой мыши на контейнере Certificates, выбрать View, Add/Remove columns из меню и добавить столбец Archived Key.

Восстановление ключей

Пользователь инфраструктуры PKI или приложения, использующего PKI, обычно инициирует процесс восстановления ключа, требующий использования хотя бы одного агента KRA (количество этих агентов задается в свойствах CA). В инфраструктуре Windows 2003 PKI поддерживаются механизмы разделения ролей, позволяющие разделять роли администратора CA (CA administrator), менеджера сертификатов (certificate manager) и KRA, поскольку при обновлении восстановленных из базы CA данных может потребоваться вмешательство менеджера сертификатов. В рассматриваемом ниже примере предполагается, что разделения ролей нет, и используется только один сертификат KRA. Для восстановления архивированного секретного ключа можно пользоваться как командной строкой, так и графическим интерфейсом.

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

  1. Агент KRA идентифицирует пользователя, запрашивающего восстановление секретного ключа.
  2. KRA записывает основное имя пользователя (User Principal Name, UPN), его общее имя (common name, CN), имя учетной записи (account name) - в формате доменимя пользователя, хеш Secure Hash Algorythm-1 (SHA-1), он же серийный номер, с целью нахождения уникального идентификатора ключа. Если у пользователя имеется более одного архивированного ключа, наиболее безопасным методом будет обновление списка всех архивированных ключей. Для обновления списка всех архивированных ключей конкретного пользователя агент KRA может применить следующую команду: 
    certutil -getkey
    Эта команда возвращает серийный номер каждого архивированного ключа, после чего KRA может идентифицировать ключ для последующего восстановления и в дальнейшем использовать соответствующий серийный номер в качестве идентификатора.
  3. выполнения экспорта восстановленных данных из базы данных CA KRA запускает командную строку, в которой вводит: 
    certutil -getkey <уникальный идентификатор>
 <выходной файл>
  4. Для того чтобы преобразовать выходной файл в файл, соответствующий криптографическому стандарту открытых ключей Public-Key Cryptography Standards (PKCS) #12, который содержит восстановленный секретный ключ и защищен паролем test, KRA вводит следующую команду: 
    certutil -p "test" -recoverkey <выходной
 файл> <файл PKCS#12>
    Если KRA выполняет восстановление нескольких ключей данного пользователя, потребуется объединить несколько файлов PKCS #12 в один. Это делается с помощью следующей команды: 
    certutil -p "test" -MergePFX -user
 ","
 ""
  5. KRA выдает пользователю окончательный файл PKCS #12, который затем может быть импортирован пользователем в свое хранилище сертификатов.

Восстановление ключей через графический интерфейс может производиться с помощью утилиты Key Recovery, или krt.exe, также называемой Certification Authority Key Recovery, из набора Microsoft Windows Server 2003 Resource Kit. Диалоговое окно этой утилиты показано на экране 4. Чтобы восстановить ключ с помощью утилиты Key Recovery, нужно выполнить следующие действия:

  1. KRA выбирает в раскрывающемся списке Certification Authority (CA) центр CA, из которого производится восстановление ключей.
  2. Чтобы найти секретные ключи и сертификаты заданного пользователя, KRA выбирает в раскрывающемся списке Search Criteria критерий поиска (например, Common Name, UPN, Serial Number, Hash или Account Name), затем вводит соответствующий идентификатор (например, для обеспечения соответствия критерию Common Name это может быть Administrator) и, наконец, нажимает кнопку Search.
  3. После получения результатов поиска KRA может либо восстановить сразу все архивированные ключи (для этого нужно нажать кнопку Recover), либо обновить только одну пару "ключ-сертификат" (для этого используются кнопки Retrieve Blob или Decrypt Blob).

Восстановление данных и восстановление ключей

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

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

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

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

Широкие возможности

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

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

Миграция базы данных KMS Exchange

Служба KMS (Key Management Service) не входит в комплект поставки Microsoft Exchange Server 2003, поэтому если имеется работающая KMS в среде Exchange 2000 Server и планируется миграция на Exchange 2003, базу данных архивированных ключей KMS потребуется перенести в базу данных архивированных ключей центра сертификации Windows 2003 Server. Если в организации используется Exchange 5.5 Server KMS, тогда сначала следует выполнить обновление до Exchange 2000, поскольку процесс переноса KMS в Windows 2003 CA может работать только с базой данных KMS из версии Exchange 2000.

Затем необходимо настроить Windows 2003 CA для архивирования ключей, как описано в основной статье. Для выполнения переноса базы необходимо также удостовериться, что сертификат Export Signing доступен. Сертификат Export Signing представляет собой копию сертификата сервера CA Machine Authentication, а секретный ключ, ассоциированный с этим сертификатом, потребуется для обеспечения защиты данных базы KMS в процессе ее экспорта и передачи в структуру Windows 2003 CA. Данный сертификат должен быть доступен на той системе KMS, с которой будет производиться миграция данных. Если сервер CA не имеет сертификата Machine Authentication, то его необходимо получить до запуска процесса миграции. Сертификат Machine Authentication размещается в локальном хранилище сертификатов компьютеров сервера CA. Для того чтобы скопировать данный сертификат на компьютер KMS, следует экспортировать его с сервера CA в формате Public-key Cryptography Standards (PKCS) #12 (данная процедура описана в основной статье), после чего сохранить файл в системном каталоге на компьютере KMS.

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

certutil setreg caKRAFlags +KRAF_ENABLEFOREIGN

Затем выполняется экспорт содержимого базы данных KMS Exchange. Для этого используется мастер Exchange KMS Key Export Wizard, который запускается через оснастку Exchange System Manager (ESM) консоли Microsoft Management Console (MMC) сервера Exchange 2000. Для запуска мастера нужно открыть консоль ESM, открыть диалоговое окно Properties объекта Key Manager, после чего выбрать All Tasks, Export Users. Мастер задаст вопросы о сертификате центра CA Export Signing и о том, пользовательские ключи каких групп администраторов Exchange 2000 следует экспортировать. По умолчанию мастер сохраняет результирующий файл экспорта в каталоге \%systemdrive%program filesexchsrvrkmsdata. Нужно найти этот файл и скопировать его на сервер CA.

Чтобы выполнить импорт экспортированных архивных данных KMS в центральную базу архивированных данных CA, используется следующая команда:

certutil -f -importKMS <имя файла>

С помощью этой команды можно обрабатывать как файлы формата Exchange KMS Export, так и файлы форматов .PFX и .EPF. Последние два формата используются при ручном архивировании сертификатов и секретных ключей. Более подробно этот процесс описан во врезке «Ручное архивирование и восстановление ключей». Если в базу данных добавляется сертификат, выпущенный другим центром CA, тогда в описанной выше команде необходимо использовать ключ -f; данная ситуация типична при миграции архивированной базы данных ключей KMS.

Ручное архивирование и обновление ключей

У пользователей инфраструктуры открытых ключей PKI среды Windows есть несколько возможностей резервного копирования своих секретных ключей шифрования вручную. Обычно для этих целей используют файлы формата Public-Key Cryptography Standards (PKCS) #12 (.PFX). Для разграничения доступа и обеспечения конфиденциальности данных содержимое файла .PFX может быть защищено паролем. Ручное резервное копирование секретных ключей в файл такого типа выполняется следующим образом.

  • Открыть с помощью оснастки Certificates консоли MMC соответствующее персональное хранилище сертификатов; щелкнуть правой кнопкой мыши на том сертификате или секретном ключе, для которого будет выполняться резервное копирование, затем выбрать из контекстного меню All Tasks, Export. При этом запускается мастер Certificate Export Wizard. Затем нужно установить флажки Yes, export the private key и Enable strong protection (requires IE 5.0 NT 4.0 SP4 and above). Если установлен второй флажок, тогда мастер попросит пользователя ввести пароль для защиты содержимого файла .PFX. Флажок Delete private key if export is successful устанавливать не следует.
  • Запустить Microsoft Internet Explorer (IE) 6.0 и выбрать из меню Tools пункт Internet Options. В диалоговом окне Internet Options следует выбрать вкладку Content, затем открыть диалоговое окно Certificates, для чего требуется нажать Certificates. Выберите сертификат секретного ключа, который пользователю необходимо экспортировать, затем нажмите Export (при этом запустится Cerftificate Export Wizard). Установите те же самые флажки, которые описаны выше.

Пользователи также могут архивировать свои секретные ключи шифрования через Microsoft Outlook. Программа Outlook не сохраняет ключи в файле .PFX, здесь используется специальный файл экспорта Outlook, который имеет расширение .EPF. Данное расширение исторически унаследовано из технологии защищенной почты: аббревиатура EPF означает Entrust Profile. Одна из причин, по которой Outlook до сих пор использует этот формат, заключается в том, что он поддерживает сертификаты X.509 версии 1, которые применялись в предыдущей реализации инфраструктуры Exchange Key Management Service (KMS). Как и для файлов .PFX, здесь можно использовать пароль для защиты содержимого файла .EPF.

Чтобы экспортировать секретные ключи шифрования из Outlook, нужно выбрать Tools, Options из меню Outlook и перейти на вкладку Security. Нажмите кнопку ImportExport в нижней части окна Security, чтобы открыть диалоговое окно ImportExport Digital ID. В этом окне следует выбрать Export your Digital ID to a file, после чего требуется выбрать Digital ID секретного ключа пользователя, который необходимо экспортировать, и ввести имя файла и пароль. Флажок Delete Digital ID from System устанавливать не следует.