Вынос функции УЦ из Istio Service Mesh на доверенный УЦ вашей организации – разделение ролей ИТ и ИБ администраторов для Istio Service Mesh

Система предупреждает об изменении статуса политик выпуска сертификатов, уведомляет о выпуске и обновлении сертификатов, ведет независимый мониторинг срока действия сертификатов

ЕСАУС обеспечивает балансировку нагрузки по выпуску сертификатов между несколькими УЦ одного вендора

Прозрачное переключение между УЦ от различных производителей: Microsoft CA, MiniCA (ссылка), CryptoPro, SafeTech CA, Aladdin eCA и других.

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

Для доставки сертификатов не обязательно организовывать полноценное развертывание ЕСАУС в каждом сетевом сегменте, достаточно разместить лишь отдельный компонент (мосты)

Одним из важных критериев поддержания безопасности и доступности IT-инфраструктуры является своевременное обновление сертификатов, их доставка и установка на конечных системах и сервисах.

ЕСАУС не только обеспечивает Linux, MacOS и кластеры Kubernetes возможностями аналогичными тем, что предоставляет Microsoft ИОК для Windows, но и расширить их:

• Балансировка выпуска сертификатов между несколькими экземплярами Удостоверяющих Центров с поддержкой георезервирования и приоритизацией сетевых вызовов внутри одного ЦОД (Центра Обработки Данных)
• Автоматический повтор вызовов при временных сбоях и отключение неисправных УЦ
• Доставка цепочки сертификатов доверенных УЦ до потребителей
• Автоматизированное отслеживание срока жизни сертификата и его замена по расписанию
• Сохранение сертификатов, закрытых ключей и доверенных сертификатов в форматах PEM, PFX, JKS
• Доставка сертификата и настройка конечного приложения (потребителя сертификата) для его использования
• Контроль выпуска сертификата – известно, на каком хосте, с каким IP адресом и с какими параметрами осуществлялся запрос сертификата. Выпуск сертификата производится только на разрешенных хостах
• Построение цепочки мостов в сложно сегментированных сетях, что позволяет подключать удаленные или изолированные сегменты к корпоративному УЦ

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

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

• Одновременно работать с УЦ различных производителей - Microsoft CA, MiniCA (на базе OpenSSL), CryptoPro, SafeTech CA, Aladdin eCA
• Осуществлять балансировку выпуска сертификатов между несколькими экземплярами Удостоверяющих Центров
• Осуществлять прозрачное переключение клиентов на выпуск сертификатов на УЦ разных вендоров

Пример использования:
В рамках импортозамещения Clearway Integration предлагает отечественный аналог Microsoft CA – УЦ MiniCA (на базе OpenSSL):

• В панели управления ЕСАУС остановить исходную политику выпуска на УЦ Microsoft CA
• Создать политику выпуска сертификата, в которой указан УЦ MiniCA и шаблон MiniCA, по которому выпускать сертификат
• При следующем обновлении сертификатов Агент доставит и установит сертификат, выпущенный на УЦ MiniCA

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

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

• Координировать действия Агентов в распределенных сценариях обновления сертификатов на различных хостах при помощи флагов-семафоров
• Использовать распределенное централизованное хранилище сертификатов для возможности скачивания сертификата на другие хосты в сценариях использования единого сертификата в распределенных приложениях

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

• Агент на сервере PostgreSQL получает сертификат и «поднимает флаг», что готов к дальнейшему конфигурированию
• Агент на втором сервере PostgreSQL также получает сертификат и «поднимает флаг» готовности
• Агенты считывают готовность друг друга и выполняют скрипт конфигурирования PostgreSQL Patroni Cluster на использование SSL/TLS

В Istio Service Mesh используется компонент istiod (ранее Citadel). По умолчанию это УЦ с самоподписанным сертификатом, к которому нет доверия. Поэтому настройка и поддержание доверенного взаимодействия кластера Kubernetes с другими кластерами или внешними системами достаточно трудоемкая задача.

Istiod может использовать промежуточные сертификаты корпоративного УЦ, то есть получить роль дочернего выпускающего УЦ. Однако контроль выпуска (вернее его полное отсутствие со стороны ИБ) сертификатов уходит к администраторам Kubernetes (или получившего соответствующие права) – появляется доступ к закрытому ключу УЦ. Это риски для неконтролируемого выпуска любого сертификата, например, с «*». Это для ИБ еще хуже.

Есаус позволяет:
• Модернизировать механизм выпуска сертификатов в Istio при помощи компонента Цитадель ЦУГИ, что позволит вынести функции УЦ и логику выпуска сертификатов из Kubernetes Istio на доверенный УЦ. Контроль за выпуском сертификатов остается у администраторов ИБ.

Пример использования:
• Защищенное соединение между сервисами, взаимодействующих через Istio в кластере Kubenetes, основано на сертификатах, выпущенных на общих корпоративных УЦ, и служба безопасности может осуществлять контроль за выпуском таких сертификатами.
• В панели управления ЕСАУС видно, что сертификаты для Istio выпускаются по заданной политики выпуска сертификатов

Кластеры микросервисов не имеют функционала проверки списка отзыва сертификата, поэтому для mTLS используются сертификаты, срок действия которых исчисляется несколькими днями.

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

В связи с количеством и частотой выпуска сертификатов рекомендуется не хранить выпущенные сертификаты в базе данных УЦ. В противном случае, база УЦ будет быстро разрастаться, что будет очень сильно сказываться на производительности УЦ. Получается, что администраторы УЦ не будут ничего знать о сертификатах для Kubernetes?

ЕСАУС позволяет:
• Контролировать и журналировать факт выпуска сертификата

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