Привет, Хабр! На связи Евгений Галкин, директор по кибербезопасности компании Avanpost. Сегодня мы поговорим про ‘’взрослый’’ autoenrollment сертификатов в Linux.

Современные IT-инфраструктуры всё чаще строятся на гибридных моделях, где Linux-системы сосуществуют с Windows-доменами, облачными сервисами и контейнерами. Однако автоматизация управления PKI (Public Key Infrastructure) в таких средах остаётся сложной задачей, особенно для Linux. В отличие от Windows, где Active Directory Certificate Services и Data Protection API обеспечивают централизованное и безопасное управление сертификатами, в Linux отсутствуют встроенные аналоги этих механизмов.

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

В этой статье рассмотрим подходы к организации autoenrollment-а сертификатов в linux-средах на основе открытых решений и протоколов (рассмотрим на примере SCEP и ACME, попробуем описать их плюсы и минусы), а также поделимся подробностями нашего собственного решения на базе продуктов Avanpost DS и Avanpost CA.

Определимся с терминологией

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

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

Проблематика и постановка задачи

В современных гибридных IT-инфраструктурах автоматизация выпуска и перевыпуска сертификатов для Linux-систем остаётся одной из самых недооценённых и при этом критичных проблем PKI: в отличие от Windows с её встроенными AD CS, Group Policy и DPAPI, в Linux отсутствует единый стандарт управления сертификатами, что приводит к использованию разных инструментов и отсутствию нативного механизма автоэнролмента через корпоративные CA. Интеграция с AD CS требует дополнительных прокси-решений и нестандартных сценариев, а автоматический перевыпуск чаще всего реализуется через скрипты и внешние планировщики.

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

На мой взгляд, причина этому понятна, для Windows всю инфраструктуру и все процессы обеспечила компания Microsoft (как моно-производитель), а дистрибутивы linux разные, производители разные. Да, разумеется, есть общие правила и подходы, но тем не менее, имеются и различия, о которых необходимо помнить.

Попробуем решить задачу автоэнролмента сертификатов для linux и рассмотрим на примере следующих процессов:

• Первичный выпуск сертификата

• Обновление сертификата

• Распространение доверенных корневых сертификатов

Учтем, что решение должно быть безопасным и масштабируемым, а также поддерживаться для различных дистрибутивов linux.

Как говорили выше, решение нашей задачи рассмотрим на примере применения открытых стандартов SCEP и ACME, а в конце расскажем про наше собственное решение на базе продуктов Avanpost DS и Avanpost CA.

SCEP

SCEP (Simple Certificate Enrollment Protocol) –- это открытый протокол, разработанный компанией Cisco, для автоматизации процесса выдачи X.509-сертификатов устройствам и системам без предварительно установленных сертификатов. Его основная задача - упростить первичную регистрацию клиента в инфраструктуре PKI, позволив автоматически сгенерировать ключевую пару, отправить запрос на сертификат (CSR) в центр сертификации и получить готовый сертификат по защищённому каналу. SCEP изначально задумывался для сетевого оборудования, но со временем стал де-факто стандартом для базового автоэнролмента в гетерогенных средах, включая Linux. Протокол работает поверх HTTP/HTTPS и использует механизм предварительного выработанного секрета (challenge password) для первичной аутентификации клиента на этапе запроса сертификата.

Концепция решения задачи автоэнролмента Linux через SCEP строится следующим образом. На стороне инфраструктуры разворачивается SCEP-совместимый сервер или шлюз к корпоративному CA (например, Microsoft AD CS с ролью NDES, OpenXPKI, EJBCA или Vault PKI с SCEP-плагинами). Linux-хост при первичной инициализации автоматически генерирует закрытый ключ, формирует CSR и отправляет его на SCEP-сервер с использованием одноразового или ограниченного по времени challenge-пароля. После прохождения проверки CA подписывает сертификат и возвращает его клиенту, который сохраняет его в локальное хранилище и применяет к целевым сервисам (nginx, postfix, docker, kubelet и т. д.). Для перевыпуска сертификатов используется тот же механизм, но уже с опорой на существующий сертификат или повторную авторизацию через challenge. Распространение доверенных корневых сертификатов реализуется централизованно через конфигурационные системы (Ansible, SaltStack, cloud-init) или через тот же SCEP/CA-интерфейс, обеспечивая единый уровень доверия между всеми узлами инфраструктуры.

Преимущества SCEP заключаются в его простоте, широкой поддержке и совместимости: он поддерживается большинством корпоративных CA, включая AD CS, работает на любых дистрибутивах Linux через утилиты sscep, certmonger и не требует сложной инфраструктуры. SCEP хорошо подходит для массового первичного энролмента серверов, сетевых устройств и виртуальных машин, легко автоматизируется через скрипты и системы управления конфигурациями, а также масштабируется в крупных инфраструктурах.

Однако у SCEP есть и существенные недостатки. Главный из них - слабая модель безопасности первичной аутентификации: использование одного общего challenge-пароля создаёт риск несанкционированной выдачи сертификатов при его утечке. В базовой реализации отсутствует полноценный RBAC, привязка сертификатов к учётным записям и гибкие политики выпуска. Протокол изначально не проектировался для short-lived сертификатов и динамических облачных сред, что делает его менее удобным для Kubernetes и микросервисных архитектур. Также SCEP слабо стандартизирован в части перевыпуска, отзыва и расширенного аудита, что требует дополнительных решений на уровне CA.

ACME

ACME (Automatic Certificate Management Environment) - это открытый стандарт автоматического управления жизненным циклом сертификатов, разработанный для полного исключения ручных операций при выпуске, перевыпуске и отзыве сертификатов. Наиболее известная реализация ACME - это Let's Encrypt, однако сегодня данный протокол поддерживается и корпоративными PKI-решениями: HashiCorp Vault, Smallstep, EJBCA, OpenXPKI и другими. В основе ACME лежит принцип криптографического доказательства владения доменом или хостом (challenge-response), что позволяет отказаться от предварительных секретов и статических паролей, характерных для SCEP.

Концепция решения задачи автоэнролмента Linux через ACME строится вокруг полной автоматизации выпуска и перевыпуска сертификатов без участия администратора. Linux-хост или сервис (nginx, apache, postfix и т. д.) с помощью ACME-клиента (certbot, lego, acme.sh, step-cli) автоматически генерирует ключевую пару и отправляет запрос в ACME-сервер. Центр сертификации проверяет право узла на получение сертификата через один из challenge-механизмов: HTTP-01, DNS-01 или TLS-ALPN-01. После успешной валидации сертификат автоматически выпускается, устанавливается в систему и применяется к сервису. Перевыпуск происходит автоматически по таймеру, за несколько дней до истечения срока действия, без остановки сервисов и без ручного вмешательства.

Преимущества ACME заключаются в высокой степени автоматизации и безопасности. Протокол изначально ориентирован на short-lived сертификаты (30–90 дней), что существенно снижает риски компрометации ключей. Отсутствие статических паролей и использование криптографических challenge-механизмов делает процесс выпуска более защищённым по сравнению с SCEP. ACME отлично подходит для облачных, динамических и контейнерных сред, легко интегрируется с Kubernetes и масштабируется практически без ограничений. Кроме того, ACME является де-факто стандартом для публичных и корпоративных PKI нового поколения.

Однако у ACME есть и ограничения. Он изначально ориентирован на работу с DNS-именами и веб-сервисами, поэтому его применение для внутренних сервисов без DNS или для аутентификации хостов и пользователей может быть затруднено. Использование DNS-01 challenge требует интеграции с DNS-провайдерами и наличия API-доступа, что увеличивает сложность внедрения. В Microsoft-ориентированных инфраструктурах ACME нативно не поддерживается AD CS, и его приходится внедрять через сторонние CA или прокси-решения (Vault, Smallstep). Также ACME не решает задачи разграничения прав доступа в рамках управления сертификатами и аудита «из коробки» - эти функции обычно выносятся на уровень корпоративного PKI.

Avanpost DS + Avanpost CA

Когда мы приступали к разработке DS + CA как единого доменного PKI-решения, перед нами стояла ‘’прикладная’’ задача: дать Linux-инфраструктурам тот же уровень автоматизации, управляемости и безопасности сертификатов, который многие годы считался нормой в Windows-мире с AD CS. Нашей целью было - сделать autoenrollment для Linux таким же удобным и безопасным, как в MS AD.

Первая фундаментальная задача, которую мы решили, - централизованное управление сертификатами в рамках всей инфраструктуры. В основу нашей архитектуры мы сразу заложили доменную модель: Avanpost CA стал полноценным сервисом сертификации для домена Avanpost DS, а все операции с сертификатами были привязаны не к отдельным хостам или скриптам, а к доменным политикам и шаблонам. Это позволило централизовать управление выпуском и перевыпуском сертификатов и завязать эти процессы на доменные политики.

Отдельный большой блок – безопасность. Работая в домене, мы не изобретали велосипед, весь доступ к функциям CA строится на доменной аутентификации через Kerberos и разграничении прав через доменные группы. Это позволило реализовать полноценную RBAC-модель на доступ к шаблонам сертификатов, аналогичную AD CS.

Если «на пальцах», Linux-компьютер, включённый в домен Avanpost DS, аутентифицируется в инфраструктуре через Kerberos и получает доступ в том числе к сервисам CA в строгом соответствии со своими доменными группами. Выпуск сертификатов выполняется автоматически, в рамках исполнения инструкций доменной политики, связанной с сертификатами. Перевыпуск также осуществляется централизованно по заданным срокам действия. Корневые и промежуточные сертификаты, а также CRL, автоматически публикуются в LDAP-каталоге и доставляются в локальные хранилища доверия Linux-хостов через доменный клиент (DS CLI), что решает задачу распространения доверенных цепочек без Ansible, scp и ручных операций.

Таким образом  мы попытались показать, как перенести лучшие практики доменной PKI из Windows-мира в Linux-инфраструктуры без компромиссов по безопасности и управляемости. Там, где SCEP слишком прост и небезопасен, а ACME слишком завязан на DNS и веб-сценарии, доменная модель даёт прогнозируемый, контролируемый и масштабируемый autoenrollment для enterprise-среды.