среда, 25 мая 2011 г.

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

imageТак получилось, что мне посчастливилось поучаствовать в проекте внедрения 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):

clip_image001

Рис.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 (Принудительный).

clip_image003

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

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

3 комментария:

Скилов Владимир комментирует...

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

Могу предположить, что данное решение передавалось заказчику и требовалось, чтобы CRL'ы обновлялись сами, без участия админа, а с Offline такое не прокатит.

Полезные ссылки на данную тему:

Ролики от Шапиро Леонида, если честно мне не очень, но кому-то может и понравится
http://www.techdays.ru/videos/2812.html
http://www.techdays.ru/videos/3689.html
http://www.techdays.ru/videos/3742.html

Блог Vadims Podāns - детальное описание для тех, кто хочет разобраться в теме PKI:
http://www.sysadmins.lv/PermaLink,guid,0e4b6657-b932-4fec-b51e-1ef55fda034f.aspx

Алексей Богомолов (Alexx) комментирует...

>Странное решение сделать RootCA в режиме Enterpris
С первого взгляда - да, странное. Но решение такое сделано умышленно и об этом я в статье написал. Задача - автоматизировать процесс обновления CRL.

Скилов Владимир комментирует...

Ну собственно именно это я и предположил :)
К сожалению требования заказчика не всегда совпадают с требованиями безопасности.

PS: Большое спасибо за статьи, очень помогают в работе.

Отправить комментарий