Управління ключами та ротація

Ключі - це «коріння довіри» платформи. Надійна система управління ключами (KMS/HSM + процеси + телеметрія) перетворює криптографію з разової інтеграції в повсякденну операцію: ключі регулярно оновлюються, їх використання прозоро, компрометації локалізуються, а клієнти переживають зміну ключа без даунтайму.

1) Цілі та принципи

Crypto agility: можливість змінити алгоритм/довжину ключа без великих міграцій.
Least exposure: приватні ключі не залишають KMS/HSM; операції підпису/розшифровки - видалені.
Short-lived artifacts: токени/сесійні ключі живуть хвилини-години, а не тижні.
Dual-key/Dual-cert вікна: безвідмовні ротації.
Regional & tenant isolation: ключі розділені по регіонах і орендарях.
Full auditability: незмінний журнал операцій, атестація HSM, контроль доступу.

2) Класифікація ключів

Кореневі (Root CA/Master Key): вкрай рідкісне використання, тримаються в HSM, застосовуються для випуску проміжних ключів або data-key обгорток.
Операційні: підпис JWT/подій, TLS, підпис вебхуків, шифрування конфігів/PII.
Сесійні/тимчасові: DPoP, mTLS-binding, ECDH-вивід для каналу/діалогу.
Інтеграційні: ключі партнерів (публічні) і секрети HMAC.
Data Keys (DEK): використовують envelope-шифрування під KEK, не зберігаються в явному вигляді.

3) Ідентифікація ключів і політика використання

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

Правила: «одна мета - один ключ» (мінімум шарінга), явні області застосування і терміни.

4) Життєвий цикл ключа (KMS/HSM)

1. Generate: в HSM/KMS, з політикою експорту = заборонений.
2. Publish: для асиметрії - JWKS/сертифікат з'kid'.
3. Use: віддалені операції (sign/decrypt) з контрольованим IAM.
4. Rotate: запустити'next'ключ і включити dual-accept.
5. Retire: перевести старий в «retiring», потім «revoked».
6. Destroy: знищити матеріал (з протоколом purge) після вікна суперечок.

5) Ротація: стратегії

Scheduled: календарна (наприклад, кожен 1-3 місяці для підпису JWT, 6-12 міс для TLS-сертів).
Rolling: поступове перемикання споживачів (JWKS вже містить новий ключ; емітер починає підписувати новим після прогріву кешів).
Forced (security): негайна ротація при компрометації; коротке вікно dual-accept, агресивне закінчення артефактів.
Staggered per region/tenant: щоб не «плескати» весь світ одночасно.

Золоте правило: спочатку публікація, потім підпис новим, і тільки після закінчення - відгук старого.

6) Dual-key вікно (безвідмовна зміна)

Публікуємо JWKS зі старим і новим'kid'.
Верифікатори приймають обидва.
Емітер через N хвилин/годин починає підписувати новим.
Моніторимо частку перевірок за старим/новим'kid'.
Після досягнення цільової частки ретайрім старий.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) Політики підпису і валідації

Типові алгоритми: ES256/EdDSA для підпису; RSA-PSS там, де потрібно.
Заборона'none '/слабких алгоритмів; whitelisting на стороні верифікації.
Clock skew: допускаємо ± 300 c, логуємо відхилення.
Key pinning (внутрішні сервіси) і короткий TTL JWKS-кеша (30-60 с).

8) Envelope-шифрування та KDF

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

KEK (Key Encryption Key) зберігається в KMS/HSM, ротується регулярно.
DEK створюється на об'єкт/партію; при ротації KEK виконуємо re-wrap (швидко, без ре-шифрування даних).
Для потоків - ECDH + HKDF для виведення короткоживучих ключів каналу.

9) Регіональність і мульти-тенант

Ключі та JWKS перерегіональні: 'eu-core','latam-core'- різні набори ключів.
Розділення IAM/аудиту по tenant/region; ключі не «перетікають» між резидентностями.
'kid'кодуйте з префіксом домену довіри: `eu-core-es256-2025-10`.

10) Секрети інтеграцій (HMAC, API-ключі)

Зберігати в KMS-backed Secret Store, видача через short-lived client secrets (rotation policy ≤ 90 днів).
Підтримка двох активних секретів (dual-secret) при ротації.
Для вебхуків - timestamp + HMAC підпис тіла; вікно часу ≤ 5 хв.

11) Управління доступом і процеси

IAM-матриця: хто може «generate», «sign», «decrypt», «rotate», «destroy» (мінімум ролей).
4-очний принцип: чутливі операції вимагають двох підтверджень.
Change windows: вікна включення нового ключа і тестові канарські регіони.
Runbooks: шаблони процедур для scheduled і forced ротацій.

12) Спостережуваність і аудит

• `sign_p95_ms`, `decrypt_p95_ms`, `jwks_skew_ms`,
• споживання по'kid','old _ kid _ usage _ ratio',
• `invalid_signature_rate`, `decrypt_failure_rate`.

• Кожна операція підпису/розшифровки: `who/what/when/where/kid/purpose`.
• Історія статусів ключів і запитів на ротацію/ревокацію.
• Атестація HSM, журнали доступу до ключових матеріалів.

13) Плейбуки (інциденти)

1. Компрометація ключа підпису

Негайний revoke старого'kid'( або переклад в'retiring'з мінімальним вікном), публікація нового JWKS, укорочені TTL токенів, форс-logout/інвалідація RT, комунікації власникам інтеграцій, ретро-аудит.

2. Масові'INVALID _ SIGNATURE'після ротації

Перевірити кеш JWKS/clock skew, повернути dual-accept, продовжити вікно, розсилка клієнтам.

3. Зростання латентності KMS/HSM

Увімкнути локальний кеш підписів неприпустимо; замість цього - batch/queue у емітера, autoscaling HSM проксі, пріоритизація критичних потоків.

4. Відмова одного регіону

Активувати процедури регіональної ізоляції; не «тягнути» ключі з інших регіонів; деградувати функції, зав'язані на підписи в регіоні, що впав.

14) Тестування

Contract: коректність JWKS, правильні'kid '/alg/use, сумісність клієнтів.
Negative: підроблений підпис, застарілий'kid', невірний alg, clock skew.
Chaos: миттєва ротація, недоступність KMS, «дрейф» часу.
Load: пік підписів (JWT/webhooks), пік розшифровок (PII/виплати).
E2E: dual-key вікно: випуск - верифікація - перенесення трафіку - відбракування старого.

15) Приклад конфігурації (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) Приклад JWKS і маркерів в артефактах

json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }

json
{ "keys":[
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-10","x":"...","y":"..."},
{"kty":"EC","use":"sig","crv":"P-256","kid":"eu-core-es256-2025-07","x":"...","y":"..."}
]}

17) Анти-патерни

Довгоживучі ключі «на роки» і загальні для всіх регіонів.
Ротація «в один момент» без dual-accept.
Експорт приватних ключів з KMS/HSM «для швидкості».
Змішування завдань: одним ключем підписувати JWT і шифрувати дані.
Відсутність журналів/атестації HSM і IAM-обмежень.
Немає механізму re-wrap для DEK при ротації KEK.
Ручні «секрети» в env замість Secret Store.

18) Чек-лист перед продом

• Всі приватні ключі в KMS/HSM; IAM-матриця і 4-очний принцип налаштовані.
• Політики алгоритмів, довжини ключів і термінів життя затверджені.
• Включений dual-key процес з моніторингом часток по'kid'.
• JWKS публікується з коротким TTL і прогрівом кешів; клієнти приймають ≥2 ключа.
• Envelope-шифрування: KEK ротується, DEK re-wrap без простою.
• Регіональна ізоляція та роздільні набори ключів за тенантами.
• Плейбуки на компрометацію/ролінг/форс ротацію; тренувальні прогони.
• Метрики ('old _ kid _ usage _ ratio','invalid _ signature _ rate') і алерти включені.
• Набір contract/negative/chaos/load/E2E тестів пройдено.
• Документація для інтеграцій: як обробляти зміну'kid', які вікна і коди помилок.

Висновок

Управління ключами - це операційна дисципліна: KMS/HSM як джерело істини, регулярні і безпечні ротації з dual-key, регіональна і тенантна ізоляція, envelope-шифрування і спостережуваність. Дотримуючись цих правил, ви отримуєте криптоконтур, який масштабується, стійкий до інцидентів і легко пояснимо аудитору - а розробники та інтегратори переживають будь-які зміни без болю.