Шифрування та захист 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 і «подвійні вікна» при зміні ключів - і ви зведете до мінімуму ризики перехоплення, даунгрейду і зловживання втраченими секретами, не ламаючи доступність і швидкість продукту.