Инфраструктура открытых ключей на платформе Windows Server 2003

Введение

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

Центр Сертификации в составе Windows Server 2003

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

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

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

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