Компоненты домена безопасности информационной системы

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

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

За последние десятилетия на рынке сложилась ситуация, при которой в качестве ЦС, контроллера домена и службы каталогов использовались соответствующие службы в составе Microsoft Server: Certificate Services, Key Distribution Center и Active Directory. В данном документе мы рассмотрим вариант организации инфраструктуры открытых ключей на базе отечественных решений и, в частности, решений компании АО «Аладдин Р.Д.».

В качестве контроллера домена и службы каталогов будет рассмотрен SambaDC. В качестве центра сертификации – Aladdin Enterprise CA. Отдельно стоит отметить, что в рамках переходного периода миграции информационной системы на отечественные решения возможна интеграция Aladdin Enterprise CA со службой Microsoft AD и KDC, и возможно использование Microsoft CS в качестве корневого центра сертификации.

Третий компонент домена безопасности – Центр валидации. В составе Aladdin Enterprise CA есть такой компонент. Он предоставляет следующие службы: точку распространения списков отзыва сертификатов (CRL DP), точку распространения сертификатов промежуточных ЦС (AIA) и онлайн-службу предоставления статусов сертификатов (OCSP). При планировании инфраструктуры необходимо учитывать возможность развертывания и регистрации нескольких Центров валидации на одном Центре сертификации с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный, и отказоустойчивости: равномерного распределения нагрузки между серверами.

В рамках данного документа мы рассмотрим возможность развертывания инфраструктуры открытых ключей в гетерогенной среде, где клиентские подключения могут осуществляться с операционных систем разного типа - семейства Microsoft Windows и семейства Linux. Для обеспечения аутентификации и предоставления доступа к работе с ОС семейства Linux необходимо использовать ПО Aladdin SecurLogon, для ОС семейства Windows аутентификация и доступ к ОС производится штатными средствами, входящими в состав ОС. Для хранения закрытых ключей и сертификатов пользователей для аутентификации рекомендуем использовать USB-токены или смарт-карты из линейки JaCarta PKI, JaCarta PRO или JaCarta 2 PKI/PRO.

Пользователи, сервера, сервисы, рабочие места и устройства являются участниками (субъектами) инфраструктуры открытых ключей. Они владеют закрытым ключом и сертификатом открытого ключа, который издается в одном из центров сертификации информационной системы. 

Все технические средства должны иметь доступ к центру валидации для обеспечения работы PKI-компонентов. 

Планирование инфраструктуры

Любая организация, определяя цели развертывания PKI, должна руководствоваться своей политикой безопасности, учитывать специфику ведения бизнеса или характер деятельности, юридические и административные ограничения. Не менее важен при принятии решения о развертывании PKI и учет потребностей безопасности, например, необходимость повысить уровень защищенности корпоративной системы, связанной с Интернетом, или следовать требованиям безопасности, установленными государственными органами. Кроме того, условия импортозамещения программного обеспечения вынуждают многие компании использовать новые отечественные технологии и open source в условиях цифровой трансформации в соответствии с государственными задачами, чтобы соответствовать ожиданиям клиентов в отношении безопасности используемой ими системы. Выбирая ПО для импортозамещения, важно проверить его включение в российский реестр программного обеспечения, которое подтверждает, что оно действительно разработано и внедрено в России. Именно поэтому реализовать стратегию импортозамещения следует поручить надёжным партнёрам, каким и является АО «Аладдин Р.Д.».

В данном документе рассмотрено развёртывание инфраструктуры PKI с помощью «Центра сертификатов доступа Aladdin Enterprise Certificate Authority», включённого в реестр программного обеспечения, о чём свидетельствует запись в реестре №14433
https://reestr.digital.gov.ru/reestr/901298/.

Развёртывание инфраструктуры PKI на базе «Центра сертификатов доступа Aladdin Enterprise Certificate Authority» возможно в уже существующем домене под управлением MS AD, ALD PRO, Samba DC или после развертывания новой доменной структуры.

Поскольку сценарии использования ПО «Центра сертификатов доступа Aladdin Enterprise Certificate Authority» продолжают расширяться и усложняться, проиллюстрируем наиболее распространённые (см. Рисунок 1). 

Рисунок 1 – Развёртывание инфраструктуры PKI на базе ПО АЕСА

В данной инфраструктуре возможно выполнение следующих сценариев:

1. Администрирование доменов. Инфраструктура открытого ключа позволяет распределить права на централизованное создание, распространение и аннулирование ключей для выбранных групп безопасности или членов этих групп – доменных пользователей и субъектов, между назначенными операторами. Оператор принимает решение о выдаче сертификатов, об отказе в его выдаче или о переводе сертификата в статус «Приостановлен» или «Отозван». Реализуются правила политики, в соответствии с выставленными администратором установками, путём выдачи сертификатов, предназначенных для Web-аутентификации операторов, и запуска «Центра сертификации» с ограниченным интерфейсом и в соответствии с назначенными политиками.

2. Публикация данных. Настройка осуществляется с помощью оснастки ПО «Центр сертификации» посредством регистрации Центров валидации для автоматического определения узлов CDP (CRL Distribution Point) и узлов AIA (Authority Information Access), создания OCSP-сервиса, а также производится настройка параметров публикации для полных списков CRL и списков изменений CRL. Центр сертификации в необходимом количестве публикует полные списки аннулированных сертификатов CRL (Сertificate Revocation Lists) и списки изменений CRL (Delta CRL), цепочку сертификатов, а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL.

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

• при выпуске сертификатов для субъектов доменной структуры ПО «Центр сертификации» поддерживается автоматическое заполнение определённых полей шаблона сертификата данными, полученными из ресурсной системы, источниками которой являются контроллеры домена инфраструктуры;
• при выпуске сертификата есть возможность установить его на электронный носитель;
• отзыв сертификата;
• приостановление действия сертификата, выпущенного для пользователя;
• возобновление сертификата пользователя после выхода на работу из отпуска;
• поиск всех сертификатов пользователя;
• контроль сроков действия сертификатов путём автоматического оповещения пользователей по истечению срока действия сертификата, с возможностью настройки шаблона рассылки оповещений.

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

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

• количество сотрудников предприятия. Жестких критериев не существует. Как правило, многоуровневая структура включает от 2 до 4 уровней;
• количество удаленных филиалов или отделений. При небольшой численности сотрудников, но наличии большого количества филиалов, удаленных друг от друга, можно порекомендовать создание нескольких ЦС;
• структуру управления предприятием. Отдельный ЦС может понадобиться для каждого филиала, если филиалы имеют собственные органы управления;
• выделенный бюджет. Многоуровневая структура подразумевает большое количество оборудования и лицензий для операционных систем. 

Иерархии PKI

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

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

Проверка статуса отзыва сертификатов может выполняться несколькими способами – онлайн и оффлайн. В онлайн-протоколе OCSP – запрос на сервер позволяет проверяющей стороне узнать текущее состояние сертификата. Сервер возвращает окончательный ответ с цифровой подписью, указывающий статус сертификата. В оффлайновом режиме респондент получает свои данные из опубликованных списков отозванных сертификатов CRL и, следовательно, зависят от частоты публикации ЦС. Базовый список CRL включает полный список отзыва, в связи с чем трафик списков отзыва будет существенным по размеру. Для уменьшения трафика предусматривается возможность публикации дифференциального списка отзывов DeltaCRL. Это позволяет публиковать базовый CRL реже и на более длительный срок, а для ускорения времени реакции пользователей на отозванные сертификаты в промежутке выпускать несколько дифференциальных CRL.

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

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

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

В одноуровневой иерархии PKI центр сертификации обеспечивает весь требуемый функционал. Данный вариант приемлем для небольших компаний. При необходимости может быть совмещен с сервером центра сертификации. 

Рисунок 2 – Одноуровневая иерархия PKI 

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

Рекомендуемая конфигурация. Корневой сервер используется только для выдачи сертификатов одному или нескольким промежуточным центрам сертификации. Корневой центр сертификации находится в режиме offline и может не входить в Active Directory. При необходимости центр валидации может быть совмещен с сервером промежуточного центра сертификации.

Рисунок 3 - Двухуровневая иерархия PKI