Шифрование и защита API: TLS, HSTS, PFS, ротация секретов

1) Картина угроз и цели

API под атакой MitM, перехвата трафика, даунгрейд-атак, подделки токенов, утечек ключей и злоупотребления долгоживущими секретами. Цели защиты:

Конфиденциальность и целостность (TLS 1.3 + сильные шифры).
Защита от даунгрейда/стриппинга (HSTS, запрещённые версии/шифры).
Минимизация ущерба при компрометации (PFS, короткие TTL, быстрая ротация).
Надёжная аутентификация клиента/сервиса (mTLS/токены) и трассируемость.

2) TLS как базис (серверная и сервис-к-сервису)

Версии и шифры:

По умолчанию TLS 1.3; разрешать TLS 1.2 только для совместимости. Отключить 1.1/1.0.

Приоритетные шифросuites TLS 1.3:

`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
Для TLS 1.2: только ECDHE с AES-GCM/ChaCha20 и ECDSA/RSA подписью (например, `ECDHE-ECDSA-AES128-GCM-SHA256`).

Ключи и сертификаты:

Серверные ключи: ECDSA P-256/P-384 (быстрее и короче) либо RSA 2048+/3072.
Клиентские ключи для mTLS: ECDSA P-256; выдача через собственный CA или платёжный HSM/KMS.
Включайте OCSP stapling, предпочтительно с флагом Must-Staple, и ALPN (HTTP/2/3).

PFS (Perfect Forward Secrecy):

Обеспечивается эфемерными обменами (ECDHE) — даже если серверный ключ утек, прошлые сессии не расшифровать.
Принудительно отключите статичные DH/ RSA-ключевую договорённость.

Современные дополнения:

ECH (Encrypted Client Hello), если поддерживается фронтом/CDN, скрывает SNI.
HTTP/2/3 только с сильными шифрами; запрет незащищённого HTTP, редирект на HTTPS.

3) HSTS против TLS-stripping

Включите HTTP Strict Transport Security на корневом домене и поддоменах:


Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Разместите домен в HSTS preload списке.

Следите за корректностью перед публикацией (откат затруднён).

4) Взаимная аутентификация: mTLS и/или токены

mTLS между микросервисами/внутренними API: двусторонние сертификаты, автоматическая ротация через service mesh (Istio/Linkerd) или собственный PKI.

API-клиенты (мобильные/партнёрские интеграции): токены (OAuth2/OIDC, JWT), опционально mTLS для high-risk.

Для публичных фронтов: TLS + короткоживущие OAuth2/OIDC токены с привязкой к устройству/DPoP.

5) Управление сертификатами и жизненным циклом

ACME-автоматизация (например, Let’s Encrypt/организационный CA) с авто-обновлением за 30 дней до истечения.

Короткая жизнь сертификатов (≤ 90 дней) + мониторинг сроков, алерты и канареечные деплой-пакеты.

Централизованный PKI: корневой/промежуточный CA, CRL/OCSP, аудит выпусков и отзыва.

Пример nginx (фрагмент):

nginx ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

6) Ротация секретов: принципы и паттерны

Цели ротации: ограничить «взрывной радиус» утечек, снизить время злоупотребления, обеспечить бесшовные релизы.

Базовые правила:

Хранение секретов только в секрет-менеджере (KMS/Vault/Cloud SM). Никаких секретов в Git/образах.
Короткие TTL и автоматическая ротация: ключи подписи, пароли БД, API-ключи провайдеров.
Двойная публикация (dual-key window): старый и новый ключи активны одновременно на период переката.
Версионирование + kid (для JWT/JWKS), «grace» окно для валидации старых токенов.

Что ротировать регулярно:

JWT-ключи (подпись/шифрование), HMAC-секреты вебхуков и callback’ов, Пароли/учётки БД, креды к кэшам (Redis), токены CI/CD, Секреты провайдеров (KYC/AML, платёжки, SMS/e-mail), SSH-ключи автоматики.

Триггеры внеплановой ротации: подозрение на утечку, увольнение сотрудников с доступом, смена поставщика, требования регулятора.

7) JWT/JWKS: безопасный ролевой оверлей

Публикуйте JWKS endpoint с текущим и будущим ключом (`kid` обязателен).

Процедура ротации:

1. Сгенерировать новый ключ → добавить в JWKS как «второй».

2. Обновить подписантов → выпуск новых токенов новым ключом.

3. Подождать TTL старых токенов → удалить старый ключ из JWKS.

Установите короткие TTL токенов (например, 5–15 минут) + refresh-потоки с дополнительной проверкой.

8) Секрет-менеджмент на практике

KMS + envelope encryption: мастер-ключ в HSM/KMS, данные шифруются «обёрнутыми» DEK.

Vault/Cloud Secret Manager: динамические креды к БД (выдача учёток с TTL), периодическая ротация.

Kubernetes: External Secrets/Secrets Store CSI; шифрование etcd; RBAC; запрет логирования секретов.

Доступ по ролям: IAM/ABAC, принцип наименьших привилегий, аппаратные границы (HSM, TPM).

Полный аудит: кто, что, когда, зачем прочитал/изменил.

9) Транспортная защита внутри периметра

Не доверяйте «внутренней сети»: везде TLS/mTLS (zero-trust).

Service mesh автоматизирует сертификаты, перезапуск и ротацию, наблюдаемость (mTLS по умолчанию).

Минимизируйте TLS-терминации: либо только на edge + зашифрованный east-west, либо сквозное шифрование.

10) Политики безопасности API поверх TLS

Rate limiting/DoS-защита, проверка подписи вебхуков (HMAC с ротацией секретов).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options для фронта.

mTLS для критичных endpoint’ов (выплаты, админка), IP allow-list по партнёрам.

Replay-защита: timestamp+nonce в подписанных запросах, окна не более 5 минут.

11) Мониторинг и тесты

Наблюдаемость TLS: версии/шифры в метриках, алерты на попытки даунгрейда, рост отказов рукопожатий.

Сканеры (в CI/CD и регулярно в проде): проверка поддерживаемых шифров, сертификатов, HSTS, OCSP.

Chaos/DR-учения: истечение сертификата, падение секрет-менеджера, компрометация ключа подписи — проверяйте планы реакции.

12) Процедуры реагирования

Компрометация ключа: немедленный отзыв сертификата/удаление ключа из JWKS, разворот на резервный, принудительная регенерация токенов.

Истечение без продления: временная деградация (только внутренний трафик), автоматическая переустановка сертификатов.

Инцидентный отчёт: таймлайн, затронутые субъекты, тех. детали, корректирующие меры.

13) Чек-лист быстрой проверки (prod-ready)

Только TLS 1.3 (+ 1.2 для легаси), строгий список шифров.
HSTS с `preload`, OCSP stapling, ALPN.
ECDHE для PFS; ECDSA P-256/384 или RSA 3072.
mTLS внутри кластера/между критичными сервисами.
JWKS + kid, короткие TTL токенов, план ротации.
Секреты — только в KMS/Vault, авто-ротация БД/провайдеров.
Авто-обновление сертификатов (ACME), алерты за 30 дней.
CI/CD-проверка заголовков безопасности и уязвимых шифров.
Документированные runbook’и: ротация, отзыв, инциденты.

Резюме

Надёжная защита API — это сочетание TLS 1.3 + HSTS + PFS как обязательного минимума и зрелых процессов управления ключами и секретами. Добавьте mTLS между сервисами, автоматизируйте выпуск/ротацию через KMS/Vault/mesh, держите короткие TTL и «двойные окна» при смене ключей — и вы сведёте к минимуму риски перехвата, даунгрейда и злоупотребления утёкшими секретами, не ломая доступность и скорость продукта.