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

Ключи — это «корни доверия» платформы. Надежная система управления ключами (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-шифрование и наблюдаемость. Следуя этим правилам, вы получаете криптоконтур, который масштабируется, устойчив к инцидентам и легко объясним аудитору — а разработчики и интеграторы переживают любые изменения без боли.