Проект внедрения PKI – базовая инфраструктура

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

Сразу хочу предупредить, данная тема из разряда «офф-топик» для этого блога, плюсом, данный проект разрабатывался для конкретной организации с определенными условиями и входными данными, так что он НЕ является универсальным и «правильным» в определенных моментах. Информация предоставляется «как есть» лишь для ознакомления.

Введение

Инфраструктура открытых ключей (англ. PKI - Public Key Infrastructure) - технология аутентификации с помощью открытых ключей. Это комплексная система, которая связывает открытые ключи с личностью пользователя посредством удостоверяющего центра (Certificate Authority - CA).

В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных принципов:

1. закрытый ключ известен только его владельцу;
2. удостоверяющий центр (CA) создает сертификат открытого ключа, таким образом удостоверяя этот ключ;
3. никто не доверяет друг другу, но все доверяют удостоверяющему центру (CA);
4. удостоверяющий центр (CA) подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом.

Фактически, PKI представляет собой систему, основным компонентом которой является удостоверяющий центр (CA) и пользователи, взаимодействующие между собой посредством удостоверяющего центра (CA).

Цели

Основными целями развертывания инфраструктуры PKI являются:

• Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN;
• Внедрение защищённых механизмов сетевого взаимодействия — L2TP, SSL, IPsec;
• Обеспечение не отрицания авторства, неизменности передаваемых по сети данных:
  • Внедрение защищённой почты с шифрованием и/или подписью писем;
  • Внедрение цифровых подписей документов и файлов;
• Внедрение защищённых файловых хранилищ с шифрованием особо конфиденциальной информации.

Терминология и особенности

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

• CA (Certificate Authority) - центр сертификации;
• Root CA — корневой CA, является наиболее критической точкой в инфраструктуре;
• Policy CA — определяет политику сертификации на данном CA и на всех последующих CA в цепочке (при помощи уникального OID`a и CPS). Может быть совмещён с ролью Issuing CA и Root CA;
• Issuing CA — издающий CA, который выдаёт сертификаты конечным потребителям — пользователям, компьютерам, различным сетевым устройствам;
• Standalone СА – тип СА, который характеризуются нетребовательностью к наличию домена Active Directory, не использует шаблоны, следовательно нет возможности запрашивать сертификаты через оснастку Certificates консоли MMC. Не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера;
• Enterprise СА - требует наличия домена для хранения там своей информации и шаблонов сертификатов, может публиковать сертификаты в свойства учётных записей пользователей и компьютеров;
• CDP (CRL Distribution Points) - хранит ссылки на CRL издавшего конкретный сертификат CA;
• AIA (Authority Information Access) - хранит ссылки на сертификат CA, издавшего конкретный сертификат;
• CRL (Certificate Revocation List) - список отозванных сертификатов.
  

Общее описание схемы

В данном проекте внедряется двухуровневая схема построения инфраструктуры центров сертификации (рис.1):

Рис.1: Схема построения СА и публикации CRL.

Корневой СА (Root-CA) устанавливается в режиме Enterprise Root CA. Срок действия сертификата СА устанавливается в 15 лет, срок действия издаваемых им сертификатов – 10 лет, при этом срок действия Base CRL – 90 дней, а Delta CRL публиковать не будем. Также, на нем удаляются все шаблоны сертификатов, кроме Subordinate Certification Authority, с той целью, чтобы он мог выдавать сертификаты только подчиненным СА и не участвовал бы в обработке запросов всех остальных клиентов.

Издающие СА (Issuing-CA) подписываются сертификатом корневого СА. Для начала, планируется развернуть только один издающий СА, но в будущем, в случае необходимости, их количество может быть увеличено. Срок действия сертификата издающих СА устанавливается в 5 лет, срок действия издаваемых ими сертификатов – 1 год, при этом срок действия Base CRL – 5 дней, а Delta CRL – 12 часов.

Как на корневом, так и на издающих СА, для публикации информации об отозванных сертификатах (CRL), а также CRT-файлов (для формирования цепочки центров сертификации), следует полностью отказаться от LDAP-ссылок, и использовать в сертификатах только ссылки на HTTP-ресурсы. Для публикации CRL и CRT файлов потребуется веб-сервер, который будет предоставлять доступ к файлам CRL/CRT как внутри локальной сети, так из сети Интернет. Сами CRL/CRT файлы будут храниться на файловом сервере.

Примечание: Что касается Policy CA, то его отдельно выделять не будем. Хотя это и не является рекомендуемым решением, но в рамках данного проекта это уместно.

Также мы используем Online Enterprise CA в качестве корневого, что не является рекомендуемым решением с точки зрения Microsoft`a (они настоятельно рекомендуют Offline Standalone CA для корневых). Опять же в рамках данного проекта это умышленное и обдуманное решение.

Системные требования

Root-CA и Issuing-CA-N

• CPU – 1
• Memory – 1024 Mb
• Storage – 40 Gb
• ОС – Windows Server 2008 R2 Standard/Enterprise

File Server и Web Server

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

Отказоустойчивость

Для достижения высокой доступность инфраструктуры следует:

• Сконфигурировать не менее двух выдающих центров СА (Issuing CA), для того, чтобы клиенты могли запросить сертификат даже в случае отказа одного из СА;
• Обеспечить постоянную доступность точек распространения, указанных в расширениях CDP/AIA выданных сертификатов. Для этого необходимо использовать отказоустойчивое решение для файлового хранилища на котором расположены CRT/CRL фалы и настроить кластеризацию веб-сервера, указанного в настройках CDP/AIA.

Резервное копирование

Резервное копирование СА осуществляется путем:

1. Архивирование базы выданных/отозванных сертификатов;

2. Архивирование Private Key самого СА (делается один раз);

3. Архивирование настроек СА путем экспорта соответствующей ветки реестра (делается один раз).

Конфигурирование вспомогательных серверов и служб

Прежде чем перейти к настройке серверов СА, нужно выполнить настройку других служб.

Настройка DNS-сервера

Для адреса PKI.alexxhost.ru создаем в DNS следующие записи:

• Локальная зона – CNAME-запись PKI = Issuing-CA-1.alexxhost.ru
• Внешняя зона – A-запись PKI = 111.111.111.111

Примечание: Подробнее про настройку DNS можно посмотреть здесь.

Настройка файлового сервера

В качестве файлового сервера будет выступать S-Web-01 . На сервере S-Web-01 создаем папку PKI на диске C:, организуем общий доступ и настраиваем следующие права:

• Shared Permissions:
  • Everyone – read/write;
• Security Permissions:
  • Серверы СА – Read + Modify;
  • Everyone – read.

Настройка Web-сервера

В качестве web-сервера будет выступать S-Web-01 . На нем в оснастке IIS Manager создадим новый веб-сайт pki.alexxhost.ru и указываем для него физический путь c:\PKI

Для того, чтобы разрешить IIS принимать запросы у которых в адресе указан знак “+” (для Delta CRL) откроем командную строку (cmd) и выполняем команду:

%windir%\system32\inetsrv\appcmd set config /section:requestfiltering /allowdoubleescaping:true

Конфигурирование серверов с ролью СА

Для реализации поставленных задач будут использоваться виртуальные машины на базе виртуальной инфраструктуры VMware VSphere.

Настройка виртуальной машины

Для всех серверов с ролью СА могут использоваться сервера одинаковой конфигурации:

• CPU – 1
• Memory – 1024 Mb
• Storage – 40 Gb (thin)
• ОС – Windows Server 2008 R2 SP1 Standard/Enterprise Eng
• OU - alexxhost.ru/CA

После установки ОС необходимо установить все существующие на данный момент обновления и антивирус.

Защита закрытого ключа СА

Поскольку экспортировать закрытый ключ СА могут только члены локальной группы Администраторы, то следует обеспечить минимальный набор пользователей, включенных в эту группу. Поэтому мы исключаем из группы локальных администраторов на серверах СА, доменные группу Domain Admins и Enterprise Admins и оставляем только CA Admins (при помощи Restricted Groups), а также переименовываем и отключаем учетную запись локального Администратора.

Настройки безопасности

К OU, в которой расположены сервера CA (alexxhost.ru/CA/) должна быть применена отдельная групповая политика со следующими параметрами (см.рис.2):

1. Отключить удаленный доступ к серверу;

2. Включить Firewall;

3. Запретить вход с консоли для всех пользователей кроме группы CA Admins;

4. Заменить членов группы локальных Администраторов на глобальную группу CA Admins;

5. Настроить автоматическое завершение сеанса при простое более 5 мин.;

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

Наследование для всех остальных групповых политик следует оставить, но для этой политики указать статус Enforced (Принудительный).

Рис.2: Параметры групповой политики Certificate Authority.

На этом с базовой инфраструктурой всё, далее давайте поговорим непосредственно про конфигурирование серверов СА - Проект внедрения PKI – конфигурирование серверов