Построение ИОК для гетерогенных сетей

Постановка задания Агенту на обновление сертификатов, используемых на серверах Samba DC (контроллер домена) с указанием технологических окон в формате cron;

При достижении 80% срока жизни сертификата Агенты выполняют обновление сертификатов по расписанию в разрешенные часы (технологические окна);

Администратору приходит оповещение об успехе или возникших ошибках.

Cпециализированные агенты передают не только запрос на сертификат (CSR), но и сведения об окружении, в котором он был сформирован;

Принцип защиты закрытых ключей: закрытые ключи создаются на стороне клиента, который их использует, и не передаются по сети;

Балансировка выпуска сертификатов между несколькими экземплярами Удостоверяющих Центров с поддержкой георезервирования и приоритезацией сетевых вызовов;

Поддержка широкого спектра ЦС (Clearway CA, Microsoft CA, КриптоПро PKI-кластер, SafeTech CA, Aladdin eCA). Поддержка Validata, VipNet, Notary-Pro, DigiCert, Globalsign запланированы в дорожной карте (2026−2027 годы);

Постоянная проверка доступности компонентов друг другом; автоматический возврат к восстановившемуся компоненту после его отказа; механизмы коммуникации между компонентами для управления пропускной способностью системы;

Актуализация и распространение списков доверенных корневых и промежуточных ЦС в рамках всей организации;

Отслеживание срока жизни, доставка сертификата и настройка конечного приложения (потребителя сертификата) для его использования с учетом расписания технологических окон;

Поддержка современных протоколов ACMEv2, EST, SCEP, CMP и MS-WSTEP обеспечивает интеграцию с широким спектром устройств и разнородными IT-инфраструктурами. Для обратной совместимости с устаревшими системами Windows дополнительно реализована поддержка интерфейсов DCOM;

Изоляция ЦС от прямого доступа по сети клиентов и потребителей сертификатов;

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

Пример использования:

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

Сертификаты нужны на серверах, рабочих станциях, в контейнерах и сервисах: для TLS, аутентификации, подписи, почты. При этом у каждой платформы — Windows, Linux, macOS, Kubernetes — свой способ запросить, получить и установить сертификат.

Если ИОК строится по частям, появляются разрозненные процедуры, разные ЦС и ручной контроль сроков. Ошибка при выпуске или просроченный сертификат оборачивается простоем сервисов и рисками для доступа к системам.

ЕСАУС объединяет выпуск, обновление и доставку сертификатов в гетерогенной среде, проверяя каждый запрос по политикам с учётом контекста окружения. Это опора для модели Zero Trust: доверие к сертификату опирается на правила и проверку, а не ограничивается проверкой прав на шаблон в ЦС.

ЕСАУС работает в Linux, Windows, macOS, кластерах Kubernetes и Istio Service Mesh. По возможностям превосходит Microsoft Enterprise PKI для Windows:

Прозрачная миграция на ЦС другого производителя

При следующем обновлении сертификатов Агент доставит и установит сертификат, выпущенный на ЦС Clearway CA.

Создать политику выпуска сертификата, в которой указать Clearway CA и шаблон выпуска сертификата;

В панели управления ЕСАУС остановить исходную политику выпуска на Microsoft CA;

В рамках импортозамещения Clearway Integration предлагает отечественный аналог Microsoft CA — ЦС Clearway CA (на базе Openssl):

Прозрачное переключение клиентов на выпуск сертификатов на ЦС другого производителя.

Балансировку выпуска сертификатов между несколькими экземплярами Центров Сертификации;

Одновременно работать с ЦС различных производителей — Clearway CA, Microsoft CA, CryptoPro, SafeTech CA, Aladdin eCA;

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

ЕСАУС позволяет:

Обновление сертификатов в распределенных системах

Агенты считывают готовность друг друга и выполняют скрипт конфигурирования PostgreSQL Patroni Cluster на использование SSL/TLS.

Агент на втором сервере PostgreSQL также получает сертификат и «поднимает флаг» готовности;

Агент на сервере PostgreSQL получает сертификат и «поднимает флаг», что готов к дальнейшему конфигурированию;

Пример использования: Конфигурирование PostgreSQL Patroni Cluster

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

Координация действий агентов через флаги готовности: агенты на разных хостах получают сертификаты параллельно, фиксируют готовность и ждут друг друга перед финальной конфигурацией кластера;

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

ЕСАУС позволяет настроить автоматические сценарии скоординированного обновления сертификатов в кластерах серверов
и распределенных информационных системах:

Выпуск сертификатов для Kubernetes с mTLS

В панели управления ЕСАУС видно, что сертификаты для кластера Kubernetes выпускаются по заданной политике выпуска сертификатов, можно посмотреть параметры этих сертификатов;

Выдерживать пиковые нагрузки по выпуску сертификатов в больших кластерах Kubernetes, предотвращая перегрузки на ЦС;

Пример использования:

ЕСАУС позволяет:

Контролировать и журналировать факт выпуска сертификата согласно с утвержденными политиками выпуска сертификатов;

В контейнеризированных средах, с использованием mTLS срок жизни сертификата должен примерно соответствовать среднему времени жизни пода или сервиса — от нескольких часов до нескольких дней. В этом случае необходимость списков отзыва (CRL/OCSP) сильно снижается, поскольку скомпрометированный сертификат быстро теряет актуальность даже без явного отзыва.

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

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

Выпускать и размещать сертификаты в секретах кластеров микросервисов;

Актуализировать в секретах список доверенных корневых и промежуточных сертификатов всех Удостоверяющих Центров;

Перевыпускать сертификаты при изменении или удалении секретов Kubernetes;

Сохранять сертификаты, закрытые ключи и сертификаты ЦС в форматах PEM в TLS Secret,CombinedPEM, PKCS8, PKCS12, JKS.

Реализация различных сценариев выпуска и обновления сертификатов с учетом расписания, событий или по команде
от Администратора;

Операторы предоставляют метрики, отражающие состояние и работу с сертификатами, а также сведения о самих сертификатах, в формате Prometheus.

Выпуск сертификатов для Istio Service Mesh

В панели управления ЕСАУС в заданных политиках отображаются сертификаты для Istio.

Защищённое соединение между сервисами в Istio (Kubernetes) основано на сертификатах корпоративного ЦС. Политики выпуска согласованы с администраторами информационной безопасности;

Пример использования:

Выносить логику ЦС за пределы микросервисных платформ, возвращая контроль службе информационной безопасности, разделяя функций ИБ и администраторов Kubernetes/Istio.

В Istio Service Mesh используется компонент istiod, который по умолчанию является центром сертификации с самоподписанным корневым сертификатом. Внешние системы не доверяют этому сертификату. Настройка и поддержка доверенного взаимодействия с другими кластерами и внешними сервисами требует значительных усилий.

Istiod может использовать промежуточные сертификаты корпоративного ЦС, то есть выполнять роль дочернего выпускающего ЦС. Однако при этом контроль над выпуском сертификатов переходит к администраторам Kubernetes или лицам с соответствующими правами, что влечет за собой отсутствие контроля за их действиями со стороны ИБ. Администраторы Kubernetes получают доступ к закрытому ключу центра сертификации, что создаёт риск неконтролируемого выпуска любых сертификатов. Для информационной безопасности это представляет серьёзную угрозу.

ЕСАУС позволяет:

Управление SSH-ключами

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

Инвентаризация: централизованный контроль SSH-ключей на хостах для выявления несоответствий требованиям ИБ
(отсутствие passphrase, недостаточная длина ключа и другие параметры);

Пример использования:

Централизованная инвентаризация, генерация, распространение и обновление SSH-ключей;

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

ЕСАУС позволяет:

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

Актуализация и распространение списков доверенных корневых и промежуточных ЦС

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

ЕСАУС позволяет:

Запрос доверенных сертификатов в папку в сценарии автоматического обновления сертификата.

Централизованное назначение задания на обновление списка доверенных сертификатов в хранилище ОС на коллекцию агентов;

Пример использования:

Вести централизованный список доверенных сертификатов;

Централизованно распространять список доверенных сертификатов в хранилища ОС или в указанный каталог.

Обновление сертификатов на токенах, смарт-картах, TPM и HSM

Аппаратные и USB-токены: Rutoken, JaCarta и другие совместимые устройства

Смарт-карты

TPM-модули

HSM

Примеры использования:

ЕСАУС позволяет:

Данный функционал находится в разработке

В организациях, где закрытые ключи хранятся на токенах, смарт-картах, TPM и HSM, обновление сертификатов часто остаётся разрозненным процессом: разные подразделения, разные процедуры, ручной контроль сроков. Закрытый ключ при этом создаётся и используется внутри аппаратного носителя через соответствующий криптопровайдер. Продление сертификата — это сценарий записи нового сертификата на носитель с использованием существующей или новой ключевой пары в защищённом контуре устройства. При этом важно снижать риск просрочки, обеспечивать прозрачность операций в рамках жизненного цикла сертификата и возможность инициировать обновление как со стороны администратора, так и со стороны пользователя, в пределах утверждённых политик.

Примечание: Полноценный учёт средств криптографической защиты информации, в том числе по Инструкции по учёту СКЗИ (приказ ФАПСИ № 152) реализует СУУ СКЗИ 2.0.

Поддерживаемые устройства:

Smart card logon — администратор записывает на смарт-карту временный сертификат ограниченного срока действия; пользователь выполняет вход в инфраструктуру организации и обязан выпустить на эту же смарт-карту свой постоянный сертификат

Обновление сертификата на TPM — выпуск и продление сертификата для ключа, созданного и хранящегося в модуле доверенной платформы, в рамках утверждённых политик организации

Заблаговременное оповещение владельца носителя о необходимости обновления сертификата.

Автоматизировать выпуск и обновление сертификатов для аппаратных носителей (токенах, смарт-картах, TPM и HSM) по согласованным политикам

Направлять автоматические уведомления пользователям и администраторам о приближении истечения срока действия сертификатов

Инициировать обновление централизованно администратором, или пользователем самостоятельно при подключённом носителе

Реализовывать сценарии первичной выдачи и последующего самостоятельного выпуска сертификата пользователем на смарт-карте.

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

Инвентаризация сертификатов

Несоответствие политике: система-потребитель может использовать сертификат, не соответствующий назначенной для неё политике выпуска;

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

Затруднённое реагирование: при замене или отзыве сертификата сложно определить затронутые системы-потребители.

Контроль соответствия политикам: по результатам сверки формируется перечень систем-потребителей, на которых применяемые сертификаты не соответствуют назначенным политикам выпуска;

Подготовка к отзыву сертификата: поиск систем-потребителей, на которых учтён сертификат, подлежащий отзыву.

Вести поиск и учёт используемых TLS/SSL-сертификатов;

Хранить сведения по учтённым сертификатам с возможностью просмотра, сортировки и фильтрации;

Сверять используемые сертификаты с политиками, заданными для системы-потребителя.

Пример использования:

ЕСАУС позволяет:

Данный функционал находится в разработке

ЕСАУС автоматизирует выпуск и обновление сертификатов по согласованным политикам. Для контроля жизненного цикла недостаточно знать, что сертификат выпущен: важно понимать, какой сертификат фактически используется конкретной системой-потребителем и соответствует ли он политике, заданной для этой системы. Без централизованного учёта используемых сертификатов остаётся разрыв между автоматизированным выпуском и реальным состоянием инфраструктуры.

Отсутствие инвентаризации и сверки с политиками влечёт типовые риски:

Реализация сценария безопасного KRA

Утеря носителя: при утере токена уполномоченный сотрудник инициирует запрос на восстановление, восстановленный ключ устанавливается на новый носитель;

Смена носителя сотрудника: по утверждённому запросу закрытый ключ с помощью KRA переносится на новый токен или смарт-карту в рамках регламента и с фиксацией в журнале аудита.

Безвозвратная потеря данных: почта, файлы и резервные копии, зашифрованные утраченным ключом, не подлежат расшифровке;

Остановка сервисов: при утрате ключа шифрования критичного приложения или HSM восстановление работы без архива невозможно;

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

Пример использования:

Архивировать закрытые ключи шифрования в момент выпуска сертификата;

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

Вести аудит операций архивации и восстановления ключа.

ЕСАУС позволяет:

Данный функционал находится в разработке.

При шифровании закрытый ключ обычно хранится на токене, смарт-карте или в HSM. Если носитель утерян, повреждён или вышел из строя, доступ к уже зашифрованным данным теряется. Новый сертификат ситуацию не исправит: расшифровать старые файлы и почту можно только тем ключом, которым их изначально зашифровали.

KRA (Key Recovery Agent, агент восстановления ключей) — это механизм, при котором копия закрытого ключа шифрования сохраняется в защищённом хранилище в момент выпуска сертификата. Это защищает от ситуации потери исходного закрытого ключа, как следствие от безвозвратной потери данных.

Типовые последствия отсутствия KRA: