ACME
2025
Статья Максима Артюхина из Clearway Integration. Сравнительный анализ двух подходов к автоматизации управления технологическими сертификатами в современных ИТ-инфраструктурах: решений на базе открытого протокола ACME v2.0 и отечественной Единой Системы Автоматического Управления Сертификатами (ЕСАУС) на платформе ЦУГИ.
Контекст и новые вызовы
Заголовок раздела «Контекст и новые вызовы»Сокращение сроков действия TLS-сертификатов (к 2029 году до 47 дней), переход к архитектуре Zero Trust и массовое внедрение mTLS-аутентификации в микросервисных средах (Kubernetes, Istio) кардинально меняют требования к PKI. Возникает потребность в выпуске десятков тысяч сертификатов в минуту, что делает ручное управление невозможным, а традиционные PKI-решения — непригодными из-за низкой производительности и отсутствия автоматизации.
Протокол ACME v2.0: возможности и ограничения
Заголовок раздела «Протокол ACME v2.0: возможности и ограничения»ACME — открытый стандарт для автоматизации выпуска и обновления SSL/TLS-сертификатов, лежащий в основе Let’s Encrypt. Он основан на подтверждении владения доменом через методы HTTP-01, DNS-01 или TLS-ALPN-01. Однако его применение в корпоративных и контейнерных средах сталкивается с серьёзными ограничениями:
Методы проверки (особенно HTTP-01 и DNS-01) не адаптированы к динамической маршрутизации Kubernetes, создают риски безопасности и требуют открытия дополнительных портов или доступа к DNS-API.
Отсутствует нативная поддержка сервисной идентичности (SPIFFE/SPIRE) и интеграция с корпоративными политиками безопасности.
Для построения полноценной PKI на базе ACME требуется фрагментированный стек из разнородных компонентов (ACME-сервер, cert-manager, CSI-драйверы, istio-csr), каждый из которых имеет свои ограничения, уязвимости и проблемы с масштабируемостью.
Основные проблемы ACME-подхода в корпоративной среде
Заголовок раздела «Основные проблемы ACME-подхода в корпоративной среде»Импортозависимость и нормативные ограничения: коммерческие решения (Venafi, HashiCorp Vault) недоступны в РФ, а open-source компоненты не поддерживают ГОСТ и не включены в реестр ПО.
Архитектурная сложность: разрозненные логи, отсутствие сквозной наблюдаемости и единых метрик, что осложняет мониторинг и аудит.
Несовместимость с Zero Trust: доверие строится на владении доменом, а не на аттестации устройств или сервисов.
Высокая квалификация персонала и эксплуатационные трудности: поддержка стека требует глубоких знаний всех компонентов, а разные темпы их развития ведут к несовместимости и уязвимостям.
Отсутствие разделения ролей: контроль за выпуском сертификатов фактически сосредоточен у DevOps, без участия ИБ-службы.
Проблемы масштабируемости: компоненты (особенно cert-manager) не выдерживают нагрузку в больших кластерах (>10,000 подов), что приводит к сбоям и тайм-аутам.
Единая Система Автоматического Управления Сертификатами (ЕСАУС)
Заголовок раздела «Единая Система Автоматического Управления Сертификатами (ЕСАУС)»ЕСАУС — это отечественное комплексное решение на платформе ЦУГИ (реестровый №13033), созданное для централизованного управления жизненным циклом технологических сертификатов в гетерогенных средах. Ключевые характеристики:
Модульная архитектура, включающая агенты для классических ОС (Windows, Linux, macOS), операторы и компонент “Цитадель” для Kubernetes/Istio, а также драйверы для подключения к различным УЦ (Microsoft CA, MiniCA, КриптоПро PKI-кластер, SafeTech CA, Aladdin eCA).
Поддержка отечественных криптоалгоритмов (ГОСТ) и изоляция УЦ от прямого доступа клиентов.
Принцип Zero Trust: агенты передают не только запрос на сертификат, но и контекстную информацию об окружении, которая проверяется на соответствие политикам безопасности.
Централизованный аудит и сквозная наблюдаемость всех операций.
Высокая производительность и масштабируемость, позволяющая выдерживать пиковые нагрузки в больших кластерах Kubernetes.
Возможность гибкой миграции между УЦ разных производителей без перестройки архитектуры и чёткое разделение функций между ИБ-службой и администраторами Kubernetes.
Заключение
Заголовок раздела «Заключение»PKI в современных средах Kubernetes и Istio перестала быть просто вспомогательным инструментом и превратилась в стратегическую компетенцию. Удобные на первый взгляд ACME-решения обещают “один клик — и готово”, но за этим стоит хрупкая архитектура: разрозненные компоненты, разные жизненные циклы ПО, отсутствие единого управления. Только комплексный подход, сочетающий автоматизацию, контроль, аудит и интеграцию с корпоративными системами, позволит создать по-настоящему надёжную и масштабируемую инфраструктуру доверия для современных облачных платформ.
Это краткая аннотация статьи, полную версию читайте в первоисточнике.
Первоисточник: BIS Journal, №3 (58), 2025
Эксперт: Максим Артюхин, Clearway
Репринт