PKI для КИИ: ФСТЭК требует отечественных ЦС для машинного TLS - разбираемся с внутренним CA в Kubernetes

На прошлой неделе ФСТЭК опубликовал требования к национальным доверенным центрам сертификации (НДЦ) для объектов КИИ. Документ ждали - регулятор анонсировал его ещё в начале года как часть уточнения требований к криптографической защите. Теперь, когда текст опубликован, стало понятно, что ряд наших заказчиков с контейнерными рабочими нагрузками получает конкретную задачу: мигрировать внутреннее PKI под отечественные алгоритмы.

Мы занимаемся аудитом КИИ, поэтому сразу пошли разбираться, что это значит на практике в Kubernetes.

Что требует документ

Ключевое требование звучит так: машинное TLS-взаимодействие компонентов внутри объекта КИИ должно обеспечиваться сертификатами, выданными ЦС, входящим в реестр НДЦ ФСТЭК, либо созданным на основе сертифицированного СКЗИ с отечественными алгоритмами.

Под «машинным взаимодействием» документ понимает в том числе: взаимодействие между микросервисами, компонентами оркестратора, агентами мониторинга, базами данных - то есть весь service-to-service трафик, который в Kubernetes закрывают через mTLS.

Let's Encrypt и коммерческие зарубежные ЦС для этого класса применений выбывают явно. Собственный внутренний CA на OpenSSL с RSA - тоже вопрос, потому что ФСТЭК ориентирует на ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012.

Откуда растёт задача

У нескольких наших заказчиков внутренние сервисы в Kubernetes исторически работали с self-signed сертификатами RSA-2048, выданными локальным CA на основе OpenSSL. Это работало - никто особо не думал о PKI внутри кластера, cert-manager раскатывал ротацию, операторы не беспокоились.

После январских методрекомендаций криптографическая часть формально оставалась в серой зоне: требования к алгоритмам были, но чёткой нормы про ЦС для машинного TLS не было. Теперь она есть.

Параллельно мы видим, что в DevSecOps-практике для КИИ подписание образов и артефактов уже пошло в сторону отечественных инструментов - мы писали об этом в июне. PKI для сервисного трафика - следующий логичный уровень.

Как это выглядит в Kubernetes

Разберём архитектуру внутреннего CA на отечественных алгоритмах для кластера.

Корневой CA на ГОСТ. Для создания корневого CA нужна реализация ГОСТ Р 34.10-2012 на эллиптических кривых. Из доступных инструментов - КриптоПро CSP с набором утилит командной строки: csptest, certutil. Альтернатива - OpenSSL с движком gost (пакет openssl-gost-engine), сборки которого есть в РедОС 9.x и Astra Linux SE 2.x. КриптоПро даёт сертифицированное СКЗИ, что закрывает требование о сертификации. openssl-gost-engine - нет, поэтому для строгого исполнения требований НДЦ он не подходит.

Промежуточный CA для кластера. Практика здесь стандартная: root CA держать офлайн или в аппаратном HSM, для кластера выпускать отдельный intermediate CA с ограниченным сроком действия. Это снижает радиус поражения при компрометации кластерного компонента.

cert-manager и ГОСТ. Это место наибольшего трения. cert-manager умеет работать с внешними issuer через CustomResourceDefinition и spec.issuerRef.kind: Issuer. Есть два подхода:

• Vault PKI Secrets Engine - HashiCorp Vault поддерживает внешние PKCS#11-провайдеры; при подключении КриптоПро через PKCS#11-интерфейс Vault может подписывать сертификаты ГОСТ-ключом. cert-manager взаимодействует с Vault через стандартный Vault Issuer. Это рабочая схема, но требует Vault в кластере или рядом с ним.
• Самописный external issuer - cert-manager имеет спецификацию External Issuer, позволяющую написать отдельный контроллер, который обрабатывает CertificateRequest и подписывает их любым бэкендом. Несколько команд уже публиковали такие реализации для КриптоПро CSP.

На практике мы сейчас смотрим в сторону Vault PKI - он даёт аудит-лог выдачи сертификатов, что само по себе полезно для КИИ. Для кластеров поменьше external issuer с прямым вызовом CSP - проще в операционном плане.

Что делать с сервисными mesh. Если в кластере работает Istio или аналог с mTLS, там своя CA (istiod). Istio поддерживает подключение внешнего CA через pluggedInCerts - нужно переключить на тот же intermediate CA. Это требует перезапуска sidecar-ов, планируем это как отдельное окно.

Что не решается быстро

Есть несколько вещей, которые мы видим как реальные сложности на ближайшие месяцы.

Ротация существующих сертификатов. В продуктивных кластерах за годы накапливается много сертификатов: ingress-контроллеры, webhooks, etcd, kubelet. Полная миграция на ГОСТ - это ротация всего этого стека, причём координированно. Один неучтённый webhook с истёкшим старым сертификатом может положить API-сервер в самый неудобный момент.

Доверие клиентов. Корневой ГОСТ-сертификат нужно добавить в trust store на всех узлах кластера, во все контейнеры, которые делают TLS-соединения, и в те внешние системы, которые обращаются к сервисам кластера. Это не автоматизируется за один день.

Инструментарий разработчиков. Если команда использует curl, wget, клиентские SDK - они должны поддерживать ГОСТ. Большинство стандартных linux-утилит на дистрибутивах с поддержкой ГОСТ работают корректно, но это нужно проверять для каждого компонента.

Сроки по документу

Требования вступают в силу для объектов первой категории через шесть месяцев с даты публикации, для второй и третьей - через двенадцать. Это даёт время на подготовку, но с учётом того, что нужно пройти выбор инструментария, пилот, документирование и согласование изменений в ОРД - откладывать на последний месяц не стоит.

Для наших заказчиков ближайший шаг - инвентаризация текущего PKI в кластерах: что выдаёт сертификаты, какие алгоритмы используются, где root CA, какой срок действия у intermediate. Без этой картины разговор о миграции абстрактный.