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

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

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 і аварійна заміна СА/коренів.

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-автентифікація»
• «Підпис і верифікація запитів»