Компоненты домена безопасности информационной системы
Одним из вариантов построения единого пространства доверия в информационной системе является построение иерархической модели доверия1. Во главе всей структуры стоит один центр сертификации (ЦС), которому доверяют все субъекты информационной системы: пользователи, сервера, устройства и т.д. По сути, он является корневым ЦС. ЦС выпускает сертификаты для подчиненных центров, которые образовывают многоуровневую иерархию. Как правило, в корпоративных информационных системах развертывается двухуровневая иерархия: корневой и издающий ЦС. Трехуровневая иерархия: корневой, промежуточный и издающий используется реже и в рамках данного документа не рассматривается.
Второй компонент, не относящийся непосредственно к инфраструктуре открытых ключей, это контроллер домена в сочетании со службой каталогов пользователей и технических средств. Контроллер домена осуществляет аутентификацию в информационной системе (например, при помощи протокола Kerberos), а на основании учетных записей в каталоге осуществляется распределение полномочий в информационной системе.
За последние десятилетия на рынке сложилась ситуация, при которой в качестве ЦС, контроллера домена и службы каталогов использовались соответствующие службы в составе Microsoft Server: Certificate Services и Active Directory. В данном документе мы рассмотрим вариант организации инфраструктуры открытых ключей на базе отечественных решений и, в частности, решений компании АО «Аладдин Р.Д.».
В качестве контроллера домена и службы каталогов будет рассмотрен ALD PRO. В качестве центра сертификации – 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, FreeIPA или после развертывания новой доменной структуры.
Поскольку сценарии использования ПО «Центра сертификатов доступа Aladdin Enterprise Certificate Authority» продолжают расширяться и усложняться, проиллюстрируем наиболее распространённые (см. Рисунок 1).
Рисунок 1 – Развёртывание инфраструктуры PKI на базе ПО АЕСА
В данной инфраструктуре возможно выполнение следующих сценариев:
1.4.1 Администрирование доменов.
Инфраструктура открытого ключа позволяет распределить права на централизованное создание, распространение и аннулирование ключей для выбранных групп безопасности или членов этих групп – доменных пользователей и субъектов, между назначенными операторами. Оператор принимает решение о выдаче сертификатов, об отказе в его выдаче или о переводе сертификата в статус «Приостановлен» или «Отозван». Реализуются правила политики, в соответствии с выставленными администратором установками, путём выдачи сертификатов, предназначенных для Web-аутентификации операторов, и запуска «Центра сертификации» с ограниченным интерфейсом и в соответствии с назначенными политиками.
1.4.2 Публикация данных.
Настройка осуществляется с помощью оснастки ПО «Центр сертификации» посредством регистрации Центров валидации для автоматического определения узлов CDP (CRL Distribution Point) и узлов AIA (Authority Information Access), создания OCSP-сервиса, а также производится настройка параметров публикации для полных списков CRL и списков изменений CRL. Центр сертификации в необходимом количестве публикует полные списки аннулированных сертификатов CRL (Сertificate Revocation Lists) и списки изменений CRL (Delta CRL), цепочку сертификатов, а также регистрирует в соответствующей базе данных все транзакции по сертификатам и CRL.
1.4.3 Управление жизненным циклом сертификатов.
В данном сценарии выполняется ряд базовых операций, возникающих в течение жизненного цикла сертификата:
- при выпуске сертификатов для субъектов доменной структуры ПО «Центр сертификации» поддерживается автоматическое заполнение определённых полей шаблона сертификата данными, полученными из ресурсной системы, источниками которой являются контроллеры домена инфраструктуры;
- при выпуске сертификата есть возможность установить его на электронный носитель;
- отзыв сертификата;
- приостановление действия сертификата, выпущенного для пользователя;
- возобновление сертификата пользователя после выхода на работу из отпуска;
- поиск всех сертификатов пользователя;
- контроль сроков действия сертификатов путём автоматического оповещение пользователей по истечению срока действия сертификата, с возможностью настройки шаблона рассылки оповещений.
1.4.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