Менеджмент секретов

Менеджмент секретов

1) Зачем и что именно считаем «секретом»

Секрет — любой материал, раскрытие которого ведет к компрометации системы или данных: пароли, API-токены, OAuth/JWT private keys, SSH-ключи, сертификаты, ключи шифрования (KEK/DEK), ключи подписи вебхуков, DSN баз/кэшей, ключи поставщиков (платежки, провайдеры почты/SMS), cookie-соли/pepper, токены ботов/чатов, лицензии.
Секреты живут в коде, конфиге, окружении, контейнерных образах, CI/CD, Terraform/Ansible, логах/дампах — задача менеджмента секретов: учет → хранение → доставка → использование → ротация → отзыв → аудит → утилизация.

2) Принципы архитектуры

Централизация. Один доверенный слой (Vault/Cloud Secret Manager/KMS) для хранения, выдачи и аудита.
Наименьшие привилегии (PoLP). Доступ только нужным сервисам/ролям, на минимальный срок.
Короткая жизнь. Предпочтительны динамические/временные секреты с TTL/lease.
Crypto-agility. Возможность смены алгоритмов/длин ключей без простоя.
Отделение секретов от кода/образов. Ни паролей в репозиториях, ни в Docker-образах.
Наблюдаемость и аудит. Каждая операция выдачи/чтения секретов логируется и алертится.
Автоматическая ротация. Ротация — процесс в pipeline, а не ручная акция.

3) Типовые решения и роли компонентов

KMS/HSM. Корневое доверие, операции шифрования/обертки ключей (envelope).
Secret Manager/Vault. Хранилище версий секретов, ACL, аудит, динамические секреты (DB, cloud-IAM, PKI), шаблоны ротации.
PKI/CA. Выдача краткоживущих сертификатов mTLS/SSH/JWT-подписей.
Агент/sidecar. Доставка секретов в рантайм (файлы tmpfs, in-memory k/v, hot-reload).
CSI-драйверы/операторы. Интеграция с Kubernetes (Secret Store CSI Driver, cert-manager).
Слой шифрования в Git. SOPS/age, git-crypt (для инфраструктурного кода).

4) Классификация и политика

• TTL/lease и частоту ротации;
• способ выдачи (динамика vs статик), формат, носитель;
• политику доступа (кто/где/когда/зачем), требования к mTLS и взаимной аутентификации;
• аудит (что логируем, сколько храним, кто ревьюит);
• процедуры break-glass и отзыв.

5) Жизненный цикл секрета

1. Создание: через API Secret Manager с метаданными (owner, tags, scope).
2. Хранение: в зашифрованном виде (envelope: DEK обернут KEK из KMS/HSM).
3. Доставка: по запросу авторизованного субъекта (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Использование: исключительно в памяти/в tmpfs; запрет логирования/дампов.
5. Ротация: по TTL или событию (компрометация); поддержка параллельных версий (N-1).
6. Отзыв/блокировка: немедленное истечение lease, дизабл аккаунта/ключа в целевой системе.
7. Утилизация: уничтожение версий/материала, четкая цепочка аудита.

6) Динамические секреты (рекомендуется по умолчанию)

• Учетные данные БД (Postgres/MySQL) с TTL 15–60 мин.
• Временные ключи облаков (AWS/GCP/Azure) по роли сервиса.
• SSH-сертификаты (срок 5–30 мин), X.509-сертификаты (час/день).
• Временные JWT для подписи запросов, session-tickets брокеров.
• Плюсы: минимальный blast radius, упрощенный отзыв (ничего не «останется» в мире).

7) Доставка секретов в рантайм

• Secret Store CSI Driver → монтирование секретов из внешнего менеджера в pod как файлы (tmpfs).
• Избегать Kubernetes Secret как единственный источник (base64 ≠ шифрование); при необходимости — включайте провайдер KMS для etcd.
• Sidecar-агент (Vault Agent/Secrets Store) с авто-реневалом lease и hot-reload.
• VM/Bare-metal: системный агент + mTLS к Vault/Secret Manager, кеш в памяти, минимальный TCB.
• Serverless: интеграции облака с прозрачной подстановкой секретов как переменных окружения/файлов, но избегать долгоживущих envvars — предпочтительно файлы/в памяти.

Пример (Kubernetes + CSI, концептуально)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) Интеграции CI/CD и IaC

CI: воркеры получают краткоживущие токены по OIDC (Workload Identity). Запрет на «маскированные» секреты, попадающие в логи; шаг «скан утечек» (trufflehog/gitleaks).
CD: деплой забирает секреты в момент выкладки, не записывает их в артефакты.
IaC: Terraform хранит переменные в Secret Manager; состояние (state) шифруется и ограничено по доступу.
SOPS/age: для репо — хранить зашифрованные манифесты, ключи — под управлением KMS.

Пример (SOPS-фрагмент)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Политики доступа и аутентификация рабочих нагрузок

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.
Временные токены: короткие TTL, узкий scope.
ABAC/RBAC в Secret Manager: «кто может читать секрет X в среде Y» отделен от «кто может создавать/ротировать».
Многоарендность: отдельные namespaces/key-rings на арендатора; отдельные политики и отчетность.

10) Ротация, версии и совместимость

Разделяйте идентификатор секрета и его версии (`secret/app/db#v17`).
Поддерживайте две активные версии (N и N-1) для безостановочной ротации.
Ротация событийно: при увольнении, компрометации, смене провайдера, миграции алгоритмов.
Автоматизируйте: cron/бэкенд ротации в Vault/Secret Manager + webhook-триггеры перезапуска приложений/реневала.

Мини-рецепт «двухключевая» ротация вебхука

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Хранение вне рантайма: резервные копии и артефакты

Никогда не попадать в артефакты (образы, архивы логов, дампы).
Бэкапы Secret Manager — шифровать, ключи хранения вне того же контура (separation of duties).
Метки и DLP-сканы: обнаружение секретов в S3/Blob/GCS, Git, артефактах CI.

12) Наблюдаемость, аудит и SLO

Метрики: число выдач/секрет/сервис, доля истекших lease, средний TTL, время ротации, время конвергенции (секунд/минут до «принятия» новой версии).
Аудит-логи: кто/что/когда/откуда/зачем; хранение отдельно, тоже шифрованно.
SLO: 99% выдач < 200 мс; 0 утечек в логах; 100% секретов имеют owner/TTL/теги; 100% критичных секретов — динамические или ротация ≤ 30 дней.
Алерты: секрет истекает < 7 дней (для статиков), всплеск отказов аутентификации к хранилищу, нет чтений секрета > N дней (мертвый), неожиданные гео/ASN источники.

13) Частые ошибки и как их избежать

Секреты в Git/образах. Используйте SOPS/age и сканеры; политикой запретить «голые» строки.
Envvars как долговременный носитель. Отдавайте предпочтение файлам tmpfs/in-memory; очищайте окружение при форках/дампах.
Одинаковые секреты для dev/stage/prod. Разделяйте по окружениям.
Долгоживущие статические пароли. Переходите на динамические/краткоживущие.
Единый мастер-ключ «на все». Делите по арендаторам/проектам/сервисам.
Нет hot-reload. Приложение требует рестарт → окна уязвимости при ротации.

14) Примеры интеграций (схематично)

Vault динамический доступ к Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

JWT-подпись запросов (краткий срок)

Приватный ключ хранится в Secret Manager; сервис запрашивает краткоживущий signing-token и локальный агент подписывает payload (ключ не передается в приложение как строка).

SSH-сертификаты для админов

Выдача SSH-cert на 10 минут по SSO (OIDC), без распространения постоянных ключей.

15) Безопасность по краям

Логи/трейсы/метрики: санитайзеры, фильтры для известных ключей/паттернов; «секретные» поля — маскирование в APM.
Дампы/краш-репорты: вырубить по умолчанию; если нужны — шифровать и чистить.
Клиентские приложения/мобила: минимизировать оффлайн-секреты, использовать платформенные хранилища (Keychain/Keystore), привязка к устройству, TLS-pinning с аварийной раскаткой.

16) Комплаенс

PCI DSS: запрет хранения PAN/секретов без шифрования; строгий контроль доступа и ротации.
ISO 27001/SOC 2: требования к управлению активами, журналированию, контролю доступа, изменению конфигураций.
GDPR/локальные регуляторы: минимизация, доступ по необходимости, аудит.

17) Процессы и runbook

Ввод в эксплуатацию

1. Инвентаризация секретов (репозитории, CI, образы, runtime, бэкапы).
2. Классификация и теги (owner, environment, tenant, rotation-policy).
3. Выбор хранилища (Vault/Cloud SM) + интеграция с KMS/HSM.
4. Настройка выдачи по workload identity (OIDC/SPIRE).
5. Включение динамических секретов для БД/облаков/PKI.
6. Авто-ротация и hot-reload; алерты на экспирации.
7. Настройка сканеров утечек и Data Catalog/ДС.

Аварийные сценарии

Подозрение на утечку: стоп-лист доступа, немедленная ротация, отзывать сертификаты/ключи, перевыпуск токенов, включение повышенного аудита, RCA.
Недоступен Secret Manager: локальный кеш в памяти с малым TTL, деградация функций, ограничение новых соединений, ручные break-glass шаги.
Компрометация корневого ключа: регенерация key-hierarchy, rewrap всех DEK, проверка всех выдач за окно риска.

18) Чек-листы

Перед продом

• Секреты удалены из кода/образов; включены сканеры утечек.
• Для критичных секретов включены динамические механизмы.
• Доставка через sidecar/CSI/tmpfs с hot-reload, без долговечных envvars.
• Настроены IAM/ABAC политики, привязка к workload identity.
• Авто-ротация и двойные версии (N, N-1) для совместимости.
• Метрики/алерты/аудит включены; тесты деградации пройдены.

Эксплуатация

• Ежемесячный отчет: владельцы, TTL, просроченные секреты, неиспользуемые.
• Периодические ротации и пентесты путей утечки (логи, дампы, артефакты).
• План crypto-agility и аварийная замена CA/корней.

19) FAQ

В: Достаточно ли Secret Manager без KMS?
О: Для базового уровня — да, но лучше использовать envelope-шифрование: KEK в KMS/HSM, секреты — обернуты. Это упрощает отзыв и комплаенс.

В: Что выбрать — статик или динамика?
О: По умолчанию — динамика. Статик оставляйте только там, где нет поддерживаемых провайдеров, и сжигайте TTL до дней/часов + автоматическую ротацию.

В: Как безопасно прокинуть секреты в микросервис?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. Без логов, без envvars «навсегда».

В: Можно ли хранить секреты в Kubernetes Secret?
О: Только при включенном шифровании etcd с KMS-провайдером и строгих политиках. Предпочитайте внешнее хранилище и CSI.

В: Как «крипто-стереть» доступ арендатора?
О: Отозвать/заблокировать его политики в Secret Manager, инвалидировать все leases, ротация/регенерация ключей; при использовании KMS — отключить unwrap соответствующих KEK.

• «Шифрование At Rest»
• «Шифрование In Transit»
• «Управление ключами и ротация»
• «S2S-аутентификация»
• «Подпись и верификация запросов»