За что отвечает центр сертификации в windows server

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Вторая часть серии

Третья часть серии

Введение

Целевая аудитория

ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа (ИОК), набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба, выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология, обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, являющийся частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.

Зачем нужен частный PKI?

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).

Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.

Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.

Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.

Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:

Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.

Общие положения

PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:

• Шифрование – защищает данные от несанкционированного доступа третьих лиц путём шифрования данных криптографическими ключами. Только пользователи, имеющие необходимые ключи, могут получить доступ к данным. Шифрование обеспечивает секретность данных, но не защищает от их подмены.
• Цифровая подпись – защищает данные от несанкционированного изменения или подделки путём применения к данным специальных алгоритмов, которые образуют цифровую подпись. Любые манипуляции по изменению данных будут немедленно обнаружены при проверке цифровой подписи. Цифровая подпись обеспечивает не конфиденциальность данных, а их целостность. Путём комбинирования шифрования и цифровой подписи можно организовать обеспечение конфиденциальности и защиты данных от несанкционированных изменений.

Типичная инфраструктура PKI состоит из следующих компонентов:

• Центр Сертификации (ЦС) – служба, предоставляющая цифровые сертификаты потребителям и обеспечивающая функционирование PKI.
• Сервер отзыва – служба, предоставляющая информацию о списках отозванных (скомпрометированных или недействительных) сертификатов, выпущенных конкретным ЦС.
• Клиент – получатель заверенного цифрового сертификата от центра сертификации. Клиентами могут выступать люди, устройства, программное обеспечение, а также другие ЦС.

Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:

• Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева. Важно отметить, что доверие транзитивно. Клиент при проверке конечного сертификата будет выстраивать цепочку (путь) от конечного сертификата до вершины иерархии (корневого сертификата). И если клиент доверяет вершине, то будут и основания доверять конечному сертификату на правах транзитивности.
• ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.
• Издающий ЦС – это ЦС общего назначения, который выполняет подпись и выдачу цифровых сертификатов потребителям.

Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine — how it works. Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.

Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.

Отзыв сертификатов

Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.

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

Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.

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

Типовые схемы развёртывания иерархии PKI

В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.

Одноуровневая иерархия

Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:

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

Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.

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

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

Двухуровневая иерархия

Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:

Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.

В двухуровневой иерархии уже возможно решить недостатки одноуровневой иерархии. Здесь корневой ЦС выпускает сертификаты только для подчинённых ЦС, а уже подчинённый ЦС выдаёт сертификаты конечным потребителям. Поскольку издающие ЦС развёртываются не так часто, и срок их действия достаточного велик, это позволяет изолировать корневой ЦС от сети. Это автоматически сводит к нулю шанс компрометации такого ЦС, поскольку без сети к нему не добраться. Более того, основное время жизни он может (и должен) проводить в выключенном состоянии. Включать его нужно только для обновления собственного сертификата, подчинённого ЦС или для публикации нового CRL. В остальное время он никому не нужен.

Другим достоинством двухуровневой иерархии является улучшенная гибкость в разбиении подчинённых ЦС на какие-то классы. Тот же типичный сценарий, когда два ЦС управляются разными подразделениями ИТ, и каждый ЦС выпускает сертификаты для своих групп потребителей. Например, для машин отдельно, для пользователей отдельно. Можно для корпоративных разработчиков (которые обычно живут в своих средах) выделить свой подчинённый ЦС.

Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи) и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.

Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.

Для небольших и средних предприятий такая схема является наиболее оптимальной, поскольку она позволяет обеспечить должный уровень безопасности и приемлемый уровень гибкости разделения ЦС на определённые функции.

Трёх- и более уровневые иерархии

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

В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:

Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.

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

В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

Введение

Даная статья описывает инфраструктуру открытых ключей (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)

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

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

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

Данный материал является переводом оригинальной статьи «ATA Learning : Michael Soule : Manage Certs with Windows Certificate Manager and PowerShell».

Работа с сертификатами обычно является одной из тех дополнительных задач, которые вынужден брать на себя системный администратор Windows. Диспетчер Сертификатов Windows (Windows Certificate Manager) — это один из основных инструментов, который позволяет выполнять эту работу.

В этой статье мы рассмотрим работу с сертификатами применительно к операционной системе Windows. Если же вы хотите узнать больше о том, как работают сертификаты в целом, ознакомьтесь с сопутствующей статьей «Your Guide to X509 Certificates».

Понимание хранилищ сертификатов

В диспетчере сертификатов Windows все сертификаты находятся в логических хранилищах, называемых «хранилищами сертификатов». Хранилища сертификатов – это «корзины», в которых Windows хранит все сертификаты, которые в настоящее время установлены, и сертификат может находиться более чем в одном хранилище.

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

Каждое хранилище находится в Реестре Windows и в файловой системе. При работе с сертификатом в хранилище вы взаимодействуете с логическим хранилищем, не изменяя напрямую реестр или файловую систему. Этот более простой способ позволяет вам работать с одним объектом, в то время как Windows заботится о том, как представить этот объект на диске.

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

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

Сертификаты пользователей

Если вы хотите, чтобы сертификат использовался одним пользователем, то идеальным вариантом будет хранилище пользовательских сертификатов внутри Диспетчера сертификатов Windows. Это общий вариант использования процессов аутентификации на основе сертификатов, таких как проводной IEEE 802.1x.

Сертификаты пользователей находятся в профиле текущего пользователя и логически отображаются только в контексте этого пользователя. Сертификаты пользователей «сопоставлены» и уникальны для каждого пользователя даже в одних и тех же системах.

Компьютерные сертификаты

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

Вы увидите, что хранилище сертификатов компьютера логически сопоставлено для всех пользовательских контекстов. Это позволяет всем пользователям использовать сертификаты в хранилище сертификатов компьютера в зависимости от разрешений, настроенных для закрытого ключа.

Сертификаты компьютера находятся в кусте реестра локального компьютера и в подкаталогах ProgramData. Сертификаты пользователя находятся в кусте реестра текущего пользователя и в подкаталогах AppData. Ниже вы можете увидеть, где каждый тип хранилища находится в реестре и файловой системе.

Предварительные требования

В оставшейся части этой статьи вы найдете несколько примеров, демонстрирующих взаимодействие с хранилищами сертификатов Windows. Чтобы воспроизвести эти примеры, убедитесь, что выполняются следующие требования:

• Windows Vista, Windows Server 2008 или более новая операционная система. В показанных примерах используется Windows 10 Корпоративная версии 1903.
• Знакомство с PowerShell. Хотя это и не обязательно, этот язык будет использоваться для ссылки на сертификаты, где это необходимо. Все показанные примеры были созданы с помощью Windows PowerShell 5.1.
• Вам не потребуется устанавливать какие-либо специальные сертификаты, но использование самозаверяющего сертификата полезно.

Управление сертификатами в Windows

В Windows есть три основных способа управления сертификатами:

• Оснастка консоли управления Microsoft (MMC) сертификатов (certmgr.msc)
• PowerShell
• Инструмент командной строки certutil

В этой статье вы узнаете, как управлять сертификатами с помощью оснастки Certificates MMC и PowerShell. Если вы хотите узнать больше о том, как использовать certutil, ознакомьтесь с документацией Microsoft.

PowerShell против диспетчера сертификатов Windows

Поскольку в Windows можно управлять сертификатами несколькими способами, встаёт вопрос выбора, что лучше использовать — GUI (MMC) или командную строку с PowerShell.

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

Давайте сначала посмотрим, как обнаружить сертификаты, установленные в Windows, с помощью диспетчера сертификатов и PowerShell.

Использование диспетчера сертификатов Windows (certmgr.msc)

Чтобы просмотреть сертификаты с помощью MMC, откройте Диспетчер сертификатов: откройте меню «Пуск» и введите certmgr.msc. Это вызовет Windows Certificates MMC. Это начальное представление предоставит обзор всех логических хранилищ, отображаемых в левом окне.

На снимке экрана ниже видно, что выбрано логическое хранилище доверенных корневых центров сертификации

Просмотр физических хранилищ

По умолчанию Диспетчер сертификатов Windows не отображает физические хранилища. Чтобы показать их, в верхнем меню оснастки выбирайте «View» > «Options«. Затем вы увидите варианты отображения физических хранилищ сертификатов. Включение этого параметра упрощает определение конкретных путей в Windows.

Теперь вы можете видеть, что дополнительные контейнеры показаны в примере логического хранилища доверенных корневых центров сертификации, показанном ранее. Сертификаты по-прежнему сгруппированы относительно их логических хранилищ, но теперь вы можете увидеть физическое хранилище «Реестр».

Проверка атрибутов в диспетчере сертификатов Windows

Есть много атрибутов сертификата, которые вы можете увидеть при просмотре их с помощью MMC. Например, вы, вероятно, захотите выбрать определенные сертификаты по их атрибутам. Самый простой способ сделать это — указать Serial Number сертификата или значение Thumbprint. Если сертификат был подписан центром сертификации (CA), при выдаче он будет иметь серийный номер. Thumbprint вычисляется каждый раз при просмотре сертификата.

Вы можете увидеть некоторые атрибуты сертификата, открыв его в MMC, как показано ниже.

Следует отметить одну важную особенность — встроенные закрытые ключи. Сертификаты в Windows также могут иметь соответствующий закрытый ключ. Эти закрытые ключи хранятся в соответствующих физических хранилищах в виде зашифрованных файлов.

Чтобы быстро отличать сертификаты с соответствующим закрытым ключом и без него, посмотрите на значок сертификата. В Диспетчере сертификатов Windows, если значок просто выглядит как лист бумаги с лентой, соответствующий закрытый ключ отсутствует. Если у сертификата есть закрытый ключ, вы увидите ключ на значке MMC, и ключ в нижней части вкладки «Общие» при открытии сертификата

Использование PowerShell по физическому хранилищу

Как и в случае с MMC, вы можете просматривать сертификаты и управлять ими с помощью PowerShell. Давайте сначала проверим сертификаты в их физических хранилищах (реестр и файловая система).

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

Get-ChildItem -Path 'HKCU:SoftwareMicrosoftSystemCertificatesCACertificates'

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

Другое распространенное хранилище — это Personal store. Ваши сертификаты для этого хранилища находятся в файловой системе, а не в реестре. В следующих командах мы покажем эти различные физические пути и их цели.

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

Get-ChildItem -Path $env:APPDATAMicrosoftSystemCertificatesMyCertificates

Каждый файл, возвращаемый в приведенной ниже команде, является ссылкой на объект для закрытого ключа, созданный поставщиком хранилища ключей (KSP). Имя файла соответствует идентификатору ключа субъекта сертификата. К каждому устанавливаемому вами закрытому ключу будет добавлен соответствующий файл.

Get-ChildItem -Path $env:APPDATAMicrosoftSystemCertificatesMyKeys

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

Get-ChildItem -Path $env:APPDATAMicrosoftCryptoKeys

Использование PowerShell по логическому хранилищу

Поскольку работа с сертификатами на их физических путях встречается редко, в остальных примерах вы будете работать с логическими хранилищами.

PowerShell может получить доступ к логическим хранилищам Windows с помощью PSDrive-объекта «Cert:«, который сопоставляет сертификаты с физическими хранилищами так же, как это делает MMC.

К сожалению, MMC и «Cert:» не маркируют логические хранилища одинаково. Ниже вы можете увидеть сравнительную таблицу общих хранилищ и их названий как в MMC, так и в «Cert:» PSDrive.

Выбор сертификатов

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

Для следующих примеров вам нужно начать с перечисления всех установленных сертификатов в хранилище корневого ЦС.

Get-ChildItem -Path 'Cert:CurrentUserRoot'

Возвращенные объекты будут объектами сертификатов, которые вы можете использовать в следующих примерах.

Общие расширения уже доступны как свойства объектов сертификата. В приведенном ниже примере вы используете Get-Member для вывода списка всех свойств возвращаемых объектов.

Get-ChildItem -Path 'Cert:CurrentUserRoot' | Get-Member -MemberType Properties

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

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

Покажем пример взаимодействия с свойствами типа ScriptProperty. В приведенной ниже команде вы извлекаете Key Usages.

((Get-ChildItem -Path 'Cert:CurrentUserRoot' | Select -First 1).Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Key Usage'}).format($true)

Новая часть, которую мы вводим в приведенной выше команде, — это метод форматирования, который выполняет декодирование ASN.1. Вы передаете ему логическое значение (например, $true), чтобы определить, хотим ли мы, чтобы возвращаемый объект был однострочным или многострочным.

Попробуем использовать значение Thumbprint из сертификата в приведенной ниже команде. Значение Thumbprint устанавливается как переменная PowerShell и используется для выбора конкретного сертификата в приведенных ниже командах.

$thumb = "cdd4eeae6000ac7f40c3802c171e30148030c072"
Get-ChildItem -Path 'Cert:CurrentUserRoot' | Where-Object {$_.Thumbprint -eq $thumb}

Создание самозаверяющих (self-signed) сертификатов с помощью PowerShell

PowerShell может создавать самозаверяющие (self-signed) сертификаты с помощью командлета New-SelfSignedCertificate. Самозаверяющие сертификаты полезны для тестирования, поскольку они позволяют генерировать пару открытого и закрытого ключей без использования центра сертификации.

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

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

New-SelfSignedCertificate -Subject 'User-Test' -CertStoreLocation 'Cert:CurrentUserMy'
New-SelfSignedCertificate -Subject 'Computer-Test' -CertStoreLocation 'Cert:LocalMachineMy'

Использование самозаверяющих сертификатов для продуктивных сервисов не рекомендуется, поскольку не существует всех механизмов, основанных на доверии.

Импорт и экспорт сертификатов в MMC

Криптография с открытым ключом основана на широкой доступности открытого ключа. Учитывая это, вам нужны стандартные способы эффективного обмена сертификатами. Не менее важна безопасность ваших личных ключей. Хранение закрытых ключей на недоступных носителях или с материалами для аварийного восстановления — обычная практика для определенных закрытых ключей.

Оба они требуют способов хранения этих криптографических объектов в стандартных форматах. Экспорт предоставляет функции для сохранения этих объектов и обеспечения использования широко распространенных стандартных форматов файлов. Импорт позволяет вам переносить криптографические объекты в операционные системы Windows.

Экспорт сертификатов из MMC относительно прост. Чтобы экспортировать сертификат без закрытого ключа, щелкните сертификат в MMC, выберите меню «Все задачи», а затем «Экспорт».

Во время экспорта вам будет предложено указать формат файла, как показано ниже. Наиболее распространены варианты кодирования — DER или Base-64

Экспорт закрытых ключей

Чтобы экспортировать сертификат с соответствующим закрытым ключом, вы должны соответствовать двум критериям:

• Вошедшая в систему учетная запись должна иметь разрешение на закрытый ключ (только для сертификатов компьютеров);
• Закрытый ключ должен быть помечен как экспортируемый.

Чтобы проверить разрешения для закрытых ключей локального компьютера, вы можете выбрать сертификат с закрытым ключом, выбрать «Все задачи» и «Управление закрытыми ключами» в MMC «Сертификаты». В открывшемся диалоговом окне отображаются записи управления доступом для закрытых ключей.

Когда выше обозначенные условия выполнены, вы можете выбрать сертификат, щелкнуть «Все задачи», а затем «Экспорт», как если бы вы использовали сертификат только с открытым ключом. При экспорте теперь у вас должна присутствовать возможность выбора экспорта закрытого ключа («Yes, export the private key»), как показано ниже.

Когда вы экспортируете закрытый ключ в Windows, вы можете сохранить файл только как PFX. Этот и другие типы файлов и форматы кодирования подробно описаны в этом посте.

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

Импорт сертификатов

Функция импорта одинакова для всех поддерживаемых типов файлов сертификатов. Единственная разница в том, что если файл содержит закрытый ключ, вы можете «Отметить этот ключ как экспортируемый», о чем вы узнаете подробнее ниже. Windows будет использовать мастер импорта сертификатов.

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

Сертификаты для подписи кода PowerShell — хороший вариант использования надежной защиты закрытого ключа.

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

Импорт и экспорт сертификатов в PowerShell

Теперь с помощью PowerShell экспортируйте один из самозаверяющих сертификатов, которые вы создали ранее. В этом примере вы выбираете сертификат в личном логическом хранилище CurrentUser, который был самозаверяющим.

$certificate = Get-Item (Get-ChildItem -Path 'Cert:CurrentUserMy' | Where-Object {$_.Subject -eq $_.Issuer}).PSPath

Теперь, когда вы выбрали сертификат, вы можете использовать команду Export-Certificate, чтобы сохранить файл в кодировке DER, используя команду ниже.

Export-Certificate -FilePath $env:USERPROFILEDesktopcertificate.cer -Cert $certificate

Теперь давайте посмотрим на экспорт закрытого ключа. Ниже вы проверяете, что у выбранного сертификата есть закрытый ключ. Если он не возвращает True, то команда Get-Item, скорее всего, выбрала неправильный сертификат.

$certificate.HasPrivateKey

Ниже вы установите пароль, который будет использоваться для шифрования закрытого ключа. Затем экспортируйте выбранный сертификат в файл PFX и используйте пароль, который вы ввели ранее, чтобы зашифровать файл.

$pfxPassword = "ComplexPassword!" | ConvertTo-SecureString -AsPlainText -Force
Export-PfxCertificate -FilePath $env:USERPROFILEDesktopcertificate.pfx -Password $pfxPassword -Cert $certificate

В случае, если необходимо выполнить импорт, как и при экспорте, есть две команды. Одна команда для импорта сертификатов и одна для импорта файлов PFX.

Ниже команда Import-Certificate импортирует файл в формате DER, который вы экспортировали ранее, в личное хранилище текущего пользователя.

Import-Certificate -FilePath $env:USERPROFILEDesktopcertificate.cer -CertStoreLocation 'Cert:CurrentUserMy'

Допустим, вы тоже хотите установить закрытый ключ этого сертификата.

$pfxPassword = "ComplexPassword!" | ConvertTo-SecureString -AsPlainText -Force
Import-PfxCertificate -Exportable -Password $pfxPassword -CertStoreLocation 'Cert:CurrentUserMy' -FilePath $env:USERPROFILEDesktopcertificate.pfx

Имейте в виду, что пароль должен быть защищенной строкой. Кроме того, если вы импортируете в хранилище локального компьютера (например, «Cert:LocalMachine«), вам нужно будет запустить команду из командной строки администратора с повышенными привилегиями.

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

Удаление сертификатов с помощью PowerShell

При удалении сертификатов помните, что понятие «Корзина Windows» в этом случае отсутствует. Как только вы удалите сертификат, он исчезнет! Это означает, что очень важно подтвердить, что вы удаляете правильный сертификат, путем проверки уникального идентификатора, такого как серийный номер или значение расширения Thumbprint.

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

$certificate = Get-Item (Get-ChildItem -Path 'Cert:CurrentUserMy' | Where-Object {$_.Subject -eq $_.Issuer}).PSPath

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

$certificate.Thumbprint
$certificate.SerialNumber
$certificate.Subject

Убедитесь, что вы выбрали правильный сертификат, который собираетесь удалить.

Приведенная ниже команда удаляет все выбранные объекты сертификата, используйте с осторожностью! Передав объект $certificate через конвейер в командлет Remove-Item в приведенной ниже команде, вы удалите все содержимое сертификата без каких-либо запросов на проверку.

$certificate | Remove-Item

Резюме

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

Всем привет, с вами Искандер Рустамов, младший системный администратор Cloud4Y. Сегодня мы будем покорять развертывание центра сертификации (ЦС). 

Из-за сложной геополитической обстановки резко усилился процесс импортозамещения, появилась необходимость в выстраивании инфраструктуры на базе государственных требований к решениям в области информационной безопасности. Одним из таких решений является организация доступа клиентов к веб-ресурсам через портал nGate по защищённому TLS соединению с использованием шифрования по ГОСТ криптопровайдера «КриптоПро». Для этого необходим собственный центр сертификации. 

В данной статье мы рассмотрим установку Standalone Center Authority на базе Windows Server 2019. Если вам будет интересно, могу описать процесс привязки нашего центра сертификации к порталу nGate (спойлер: на самом деле там нет ничего сложного). 

Вводные данные

КриптоПро NGate — это универсальное высокопроизводительное средство криптографической защиты сетевого трафика, объединяющее в себе функционал:

• TLS-сервера доступа к веб-сайтам;

• Сервера портального доступа;

• VPN-сервера.

NGate обладает широкими возможностями по управлению доступом удалённых пользователей как с обеспечением строгой многофакторной аутентификации, так и прозрачно, обеспечивая при этом гибкое разграничение прав доступа к ресурсам. КриптоПро NGate реализует российские криптографические алгоритмы, сертифицирован по требованиям к СКЗИ, имеет сертификаты ФСБ России по классам КС1, КС2 и КС3 и может использоваться для криптографической защиты конфиденциальной информации, в том числе персональных данных, в соответствии с требованиями российского законодательства по информационной безопасности.

Кроме того, NGate:

• Снижает нагрузку по обработке TLS-соединений с веб-серверов, позволяя им сосредоточиться на выполнении своих основных задач;

• Исключает необходимость установки на каждом веб-сервере отдельного СКЗИ и проведения исследований по оценке влияния ПО веб-серверов на СКЗИ.

Процесс настройки

Ранее я не сталкивался с центрами сертификациями. Поскольку ОС Windows Server мне ближе, решил развернуть ЦС с использованием Server Manager. Разворачивать контроллер домена не нужно, так как сертификаты будут выдаваться внешним пользователям. Соответственно, можно обойтись «автономным» центром сертификации, подробнее о нём расскажу позже. 

Перед развертыванием центра сертификации необходимо: 

• Установить СКЗИ КриптоПро CSP 5.0.12330:

• Установить КриптоПро ЭЦП Browser plug-in;

Инсталляцию производим через «Дополнительные опции»

1. Выбираем язык установки, уровень защиты КС1 (другие уровни защиты требуют дополнительных аппаратных средств защиты);

2. В разделе «Установка компонентов» проверяем, что добавлен «Криптопровайдер уровня ядра ОС»; (рис. 1)

Криптопровайдер уровня ядра ОС необходим для работы криптопровайдера
в службах и ядре Windows.

3.  В следующем окне оставляем пункты:

• Зарегистрировать считыватель «Реестр» (позволит сохранять контейнеры ключей в реестр);

• Усиленный контроль использования ключей;

• Не разрешать интерактивные сервисы Windows;

4. Также «КриптоПро» предложит добавить сертификаты своих центров сертификации;

5. Устанавливаем, перезагружаемся.

Установка центра сертификации (Standalone CA Windows Server 2019)

Непосредственно перед самой установкой коротко объясню особенности Standalone CA:

• Не интегрирован с Active Directory (а он нам и не нужен);

• Публикация сертификатов происходит через запрос на WEB-сайте. Путем автоматического или ручного подтверждения администратором ЦС (ЕМНИП, ЦС предприятия было добавлена такая возможность, не проверял её работу);

• Пользователь сам вводит идентификационную информацию во время запроса сертификата;

• Не поддерживает шаблоны сертификатов (из-за этого всплывут некоторые моменты, которые раскрою в процессе развертывания).

Начинаем:

1. Измените имя компьютера до установки роли, после это будет сделать невозможно. «Далее (Next)» (рис.2): 

2. Добавляем роль в «Диспетчере серверов» (Server Manager), «Далее (Next)» (рис. 3):

2.1. «Установка ролей и компонентов (Add roles and features wizard)». Нажимаем «Далее (Next)» — «Далее (Next)»;

2.2. «Тип установки: Установка ролей и компонентов (Installation type: Role-based or features-based installation». «Далее (Next)»;

2.3. «Выбор сервера (Server selection)». В нашем случае среди предложенных будет один сервер и имя компьютера. «Далее (Next)» (рис. 4);

2.4. «Роли сервера (Server roles). Здесь необходимо отметить две роли: Служба сертификатов Active Directory (Certificate Services Active Directory), Веб-сервер IIS (Web-server IIS);

Во всплывающем окне перечня нажимаем «Добавить компонент (Add features)» — «Далее (Next)»;

2.5. «Компоненты (Features) оставляем как есть — «Далее (Next)» ;

2.6. «Служба ролей (Role Services)» ЦС, необходимо выбрать:

• «Центр сертификации (Certification Authority)»,

• «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

Сетевой автоответчик (Online responder) добавим уже после развертывания ЦА, в противном случае могут возникнуть проблемы. 

2.7. В «Служба ролей (Role Services)» веб-сервера оставляем всё предложенное автоматически — «Далее (Next)»;

2.8. «Подтверждение (Confirmation).

На этом этапе запустится процесс установки роли.

3. После установки роли центра сертификации необходимо его настроить
(рис. 5). Выбираем: 

3.1. «Настроить службы сертификатов Active Directory (Configure Active Directory-Certificate Services)

3.2. Указываем учетные данные. Так как мы развертываем Standalone центр сертификации, не нужно состоять в группе «Администраторов предприятия (Enterprise Administrators)» — «Далее (Next)»;

3.3. Выбираем установленные службы ролей для настройки (Select role services to configure) ЦС: «Центр сертификации (Certification Authority)», «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

3.3.1. При выборе центра сертификации появится окно выбора ключевого носителя – КриптоПРО CSP, в качестве носителя для создания контейнера cngWorkAround используем хранилище ключей реестра Windows – Реестр. (рис. 6)

3.4. Указываем вариант установки ЦС (Specify the setup type of the CA):
Автономный центр сертификации (Standalone CA). «Далее (Next)»;

3.5. Указываем тип ЦС (Specify the type of CA) – Корневой ЦС (Root CA). «Далее (Next)»;

3.6. Необходимо создать закрытый ключ ЦС, чтобы он мог создавать и выдавать их клиентам. Для этого выбираем «Создать новый закрытый ключ (Create a new private key)».

В качестве поставщика службы шифрования выбираем один из трёх предложенных (не забывайте, что 2001 год уже устарел) Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider с длиной 512 и открытого ключа 1024 бита. (рис.7)

И обязательно подтверждаем: «Разрешить взаимодействие с администратором, если ЦС обращается к закрытому ключу (Allow administrator interaction when the private key is accessed by the CA)»;

3.7. Укажите имя центра сертификации и суффиксы различающего имени, данные суффиксы будут отображаться в составе сертификата в графе «Издатель (Issuer)».

СN = Certificate Name, O = Organization, L = Locale, S = Street, C = Country, E = E-mail; (рис.

3.8. Указываем необходимый «срок годности (validaty period)» корневого сертификата (в нашем случае было выбрано 15 лет). «Далее (Next)»;

3.9. Указываем расположение баз данных сертификатов (certificate database location). «Далее (Next)»;

3.10. В окне «Подтверждения (Confirmation) сверяем введённую информацию — «Настроить (Configure)»

3.11. Появится окно выбора носителя для создания контейнера нашего ЦС.

Где хранятся сами контейнеры ключей:

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

3.13. После введите пароль на доступ к закрытому ключу.

3.14. Далее появится окно результатов об успешной установке компонентов (рис.

Настройка веб-сервера IIS

Теперь необходимо выполнить некоторые настройки веб-сервера: прицепить сертификат (самоподписанный или выпущенный нашим же ЦА). Кстати, он уже работает. В качестве примера выпустим самоподписанный сертификат.

1. Откроем Диспетчер служб IIS (Manager IIS) — Сертификат сервера (Server Certificates) (рис. 9);

1.1. В открывшемся окне в панели «Действия (Actions)» выберем – «Создать самоподписанный сертификат (Create Self-Signed Certificate);

1.2. Выбираем тип «Личный (Personal) и указываем «Имя сертификата (Friendly Name)»

1.3. Теперь необходимо привязать этот сертификат для доступа по https к веб-серверу.

1.3.1. Переходим «Сайты (Sites)» — Default Web Site – Bindings – добавить (Add) — выбрать https – и выбрать самоподписанный SSL-сертификат.

Также сертификат вы можете выпустить следующим образом:
На этой же панели создайте запрос (Create certificate request) для выпуска сертификата через наш ЦА и дальнейшей его загрузки в IIS (Complete Certificate Request). Но это по желанию.

Пример запроса (request) для формирования запроса вручную

[NewRequest]
Subject="CN=ИмяСертификата ,O=Организация, L=Город, S=Улица, C=Страна, E=Почта"
ProviderName="Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
ProviderType=80
KeySpec=1
Exportable = TRUE
KeyUsage=0xf0
MachineKeySet=true
RequestType=Cert
SMIME=FALSE
ValidityPeriod=Years
ValidityPeriodUnits=2
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

В целом с веб-сервером мы закончили, в default web site вы можете увидеть, что были автоматически созданы virtual directory и applications «CertSrv». При желании можно создать отдельную виртуальную директорию под CRL’ки.

Установка сетевого ответчика (Online responder)

А вот мы и вернулись к установке автоответчика.

1. Добавляем роль в «Диспетчере серверов» (Server Manager) — «Далее (Next)» 

1.1. Установка ролей и компонентов (Add roles and features wizard)» — «Далее (Next)»;

1.2. «Роли сервера (Server roles), раскрываем роль: Служба сертификатов Active Directory (Certificate Services Active Directory); и устанавливаем галочку на «Сетевой ответчик» (Online Responder) 

1.3. Завершаем работу с мастером ролей и компонентов, путём односмысленных нажатий «Далее (Next)».

В IIS была добавлена Applications: ocsp. Только не пугайтесь, что сама по себе директория пустая. Так и должно быть. 

Нам осталось настроить центр сертификации и выпустить сертификат на OCSP.

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

1. В «Диспетчере серверов (Server manager)» — выбираем «Служба сертификации Active Directory (AD CS) – правой клавишей по вашему серверу и открываем: «Центр сертификации (Certification Authority).

1.1. Вы попали в оснастку управления центром сертификации: certsrv.

1.2. Выбираем ваш центр сертификации и открываем свойства (рис. 10):

1.3. Следующим важным шагом выступает настройка точек распространения CDP и AIA.

Authority Information Access (AIA) — содержит ссылки на корневой сертификат центра сертификации (Certification Authority)

CRL Distribution Point — содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. (рис. 11)

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

1.4. В разделе свойства переходим в «Расширения (Extensions):

 Удаляем ненужные точки распространения и оставляем локальную и внешнюю ссылку для CDP:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<CaName><CRLNAmeSuffix><DeltaCRLAllowed>.crl

Ставим галочки «Включить в CRL. Включить в CDP (Include in CRL. Include in the CDP)».

AIA:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

Ставим галочку: «Включать в AIA- расширение выданных сертификатов (Include in the AIA extension of issued certificates)»

OCSP:

https://<ip_address/dns_name>/ocsp

Ставим галочку: «Включать в расширение протокола OCSP (Include in the online certificate status protocol (OCSP) extension)»

В свойствах центра сертификации можно настроить автоматический выпуск сертификатов при поступившем запросе. Так вы исключаете возможность проверки указанных требуемых полей сертификатов. Для этого перейдите в «Модуль политик (Policy Module)» — «Свойства (Properties)» и выберите соответствующий пункт:

В первом случае сертификату присваивается режим ожидания, а одобрение выпуска сертификата остается за администратором;

Во втором случае из-за отсутствия шаблонов в Standalone CA сертификаты будут выпускаться автоматически. (рис. 12)

Да, центр сертификации уже функционирует и доступен по указанному dns-имени. Не забудьте открыть 80 и 443 порты для функционирования веб-сервера и online-reposnder’a, настройкой которого мы займёмся далее.

Проверить работу ЦС вы можете, перейдя в ChromiumGost или Internet Explorer или Edge (с поддержкой Internet Explorer(IE)): https://localhost/CertSrv.

При переходе по ссылке извне в IE необходимо добавить наш веб-сервер в «Надежные сайты (Trusted Sites)» в настройках в пункте «Безопасность».  Не забудьте, что должен быть установлен КриптоПро CSP, в ином случае при выпуске сертификата вам не будет доступен выбор ГОСТовского криптопровайдера (рис.13). 

Также вы можете здесь вручную скачать сертификат нашего ЦС, цепочку сертификатов, CRL и разностные CRL. Кстати говоря, их мы и забыли настроить. 

Вернёмся в оснастку certsrv к нашему центру сертификации и настроим выпуск разностных CRL. Для этого необходимо открыть «Свойства (Properties)» раздела «отозванных сертификатов (Revoked Certificates)» (рис. 14).

1. Задаём «Интервал публикации CRL (CRL Publications interval)».

1.1. Включаем публикацию разностных CRL и задаём интервал.

Кажется, что все хорошо. Но есть один момент:

«ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:»

Выполните следующую команду в power shell:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Настройка OCSP — сетевого ответчика (Online responder)

Так как у Standalone центра сертификации нет шаблонов, нам необходимо вручную сформировать запрос и выпуск сертификата для конфигурации отзыва (Array configuration) в «Управление сетевым ответчиком (Online responder management). Для это используйте следующую конфигурацию для формирования запроса 

1.1. Создайте: ocsp.txt cо следующим внутренним содержанием:

[NewRequest]
Subject = "CN=Имя"
PrivateKeyArchive = FALSE
Exportable = TRUE
UserProtected = FALSE
MachineKeySet = TRUE
ProviderName = "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
KeyLength = 512
UseExistingKeySet = FALSE
RequestType = PKCS10
[ApplicationPolicyStatementExtension]
Policies = OCSPSigning
Critical = false
[OCSPSigning]
OID = 1.3.6.1.5.5.7.3.9
[EnhancedKeyUsageExtension]
OID="1.3.6.1.5.5.7.3.9"
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty

1.2. Откройте командную строку cmd. Перейдите в директорию с текстовым файлом или в будущем просто укажите полный путь при формировании запроса.

1.3. Узнаем, на какой срок сейчас выпускаются сертификаты. Для этого воспользуемся командой - certutil –getreg cavalidityperiodunits  

Результат — на рис. 15.

1.4. Изменим длительность выпуска сертификата:

 #Изменение выпуска сертификатов с текущего состояния на длительность в 5 лет
 certutil -setreg caValidityPeriodUnits 5 
 #Перезапуск сервера
 net stop certsvc 
 net start certsvc 

1.5. Сформируем запрос и выпустим сертификат для сетевого автоответчика (рис 16.):

#Конфигурирование запроса
 certreq -new <имя>.inf <имя>.req 
 
#Формирование запроса в ЦС
 certreq -submit <имя>.req
 
#Одобрение запроса (Можно руками через оснастку управления центром сертификации)
 certutil.exe -Resubmit "Цифра запроса" 

Во время конфигурирования запроса выбираем место хранения контейнера ключа и проходим процедуру ДСЧ.

1.6. Экспортируем сертификат из центра сертификации и устанавливаем его в личные сертификаты локального компьютера.

1.6.1. После запроса сертификата открываем оснастку: Certificates (Run — MMC – Add or remove Snap-ins – Certificate),

1.6.2. Выбираем сертификат, выданный для сетевого ответчика. Нажимаем правой клавишей и открываем «Все задачи (Управление закрытыми ключами (All Tasks — Manage Private keys)». 

1.6.3. В открывшемся окне Permissions необходимо добавить в «Группы и пользователи (Group and Users):   Network Service и выдать право Read для этой учётной записи. (рис.16.1)

Это нужно сделать, так как служба OCSP работает от лица Network Service.

1.7. Далее переходим в настройки самого сетевого ответчика. (рис. 17)

1.8. Нам необходимо добавить «Конфигурацию отзыва (Revocation Configuration) – «Добавить»

2. Предстоит небольшой процесс настройки конфигурации отзыва.

2.1. «Далее».

2.2. Введите имя конфигурации – «Далее».

2.3. Выбираем второй пункт: «Выбрать сертификат в локальном хранилище сертификатов (Select a certificate from the local certificate store)» — «Далее».

2.4. В следующем окне нажимаем «Обзор (Browse)» и выбираем корневой сертификат нашего ЦА – «Больше вариантов (More choices)». (рис. 17) – «Далее».

2.5. В следующем окне выбираем «Выбрать сертификат подписи вручную (Manually a signing sertificate)

2.6. В последнем окне нажимаем «Поставщик (Provider)». Здесь необходимо указать источник, из которого будут браться базовые и разностные CRL. В нашем случае: http://localhost/CDP/CA-C4Y-VPN.crl (для базового) и  http://localhost/CDP/CA-C4Y-VPN+.crl (для разностного).

2.7. Осталось прицепить к нашей конфигурации выпускаемый ранее сертификат и проверить некоторые моменты.

2.7.1. Переходим в «Конфигурацию массива(array configuration)», выбираем конфигурацию и нажимаем «Назначить сертификат подписи (Assign Signing Certificate)». В появившемся окне нужно просто нажать «ОК».

2.7.2. Теперь необходимо «Обновить конфигурацию массива». Для этого выбираем «Конфигурация массива (Array configuration) – «Обновить (Refresh)»

2.7.3. После всех этих действий главное окно оснастки ocsp должно выглядеть так, как на рисунке 19.

В процессе самостоятельной настройки «сетевого ответчика» может возникнуть много вопросов, особенно если нет опыта работы с Standalone центром сертификации, в котором отсутствуют шаблоны, без которых можно обойтись, но пути становятся длиннее в исполнение.  Кстати говоря, если после прикрепления сертификата вы не получили заветное Working, то проверьте следующее (рис.20, 20.1):

Чтобы проверить работу центра сертификации и сетевого автоответчика, выпустите сертификат для конечного пользователя, установите его и экспортируйте в какую-нибудь директорию. А после воспользуйтесь утилитой: Certutil –url /patch/test.crt

Для подробного отчёта вы можете воспользоваться: certutil –verify –urlfetch /patch/test.crt

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

Дополнительно:

Что ещё интересного есть в блоге Cloud4Y

→ Малоизвестный компьютер SWTPC 6800

→ Сделайте Linux похожим на Windows 95

→ Бесплатные книги, полезные для IT-специалистов и DevOps

→ WD-40: средство, которое может почти всё

→ Игры для MS-DOS с открытым исходным кодом

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу.

Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (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 часов практики и доступ навсегда.

Служба сертификации Active Directory

Служба сертификации Active Directory (AD CS) в Windows Server 2008 R2

Windows Server 2008 R2 содержит встроенный центр сертификации (СА), называе­мый службой сертификации Active Directory (Active Directory Certificate Services — AD CS). Первый вариант AD CS появился в Windows Server 2008, а раньше эта технология называ­лась просто службой сертификации (Certificate Services). AD CS может использоваться для создания сертификатов и последующего управления ими и отвечает за обеспечение их под­линности. Зачастую AD CS в Windows Server 2008 R2 используется без особой необходимости проверки сертификатов организации какой-либо независимой стороной. Поэтому если сертификаты требуются только для участников внутри организации, часто применяется развертывание самостоятельного СА для шифрования сетевого трафика. Широко исполь­зуются и сторонние центры сертификации наподобие VeriSign, но они требуют дополни­тельного вложения средств.

Хотя в новом названии службы сертификации Windows упоминается Active Directory, сле­дует понимать, что для работы AD CS совсем не требуется интеграция с существующей средой леса доменной службы Active Directory (Active Directory Domain Services (AD DS)). Обычно это все же так, но важно понимать, что AD CS не зависит от структуры леса AD DS.

В Windows Server 2008 R2 добавлено несколько новых возможностей AD CS:

• Веб-служба развертывания сертификатов и веб-служба политики развертыва­ния сертификатов. Это наиболее значительное усовершенствование позволяет раз­вертывать сертификаты непосредственно по протоколу HTTP и дает возможность клиентам, не принадлежащим домену или подключенным к Интернету, обращаться к серверу СА и запрашивать сертификаты.
• Улучшенная поддержка объемных СА, используемых для NAP. В Windows Server 2008 R2 повышена скорость работы AD CS с базой данных, когда возникают ситуации массированной работы, как с NAP.
• Поддержка развертывания сертификатов между лесами. AD CS в Windows Server 2008 R2 позволяет консолидировать СА между несколькими лесами.

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