S2S-аутентифікація

S2S-аутентифікація доводить, який саме сервіс/ворклоад робить запит, і дає йому мінімально необхідні права на обмежений час. На відміну від користувацьких потоків, тут немає людини - тому критичні короткий термін життя облікових даних, криптографічна прив'язка до ворклоаду/каналу і чітка спостережуваність.

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

Zero Trust за замовчуванням: не довіряти мережі, тільки атестації ворклоада і криптографії.
Короткоживучі креденшли: хвилини, а не дні/місяці.
Прив'язка до контексту: tenant/region/licence/audience/scopes.
Централізована видача, децентралізована перевірка: STS/IdP + локальна верифікація.
Мінімальні привілеї та явне делегування: тільки потрібні скоупи і аудит.
Ротація «без болю»: dual-key/dual-cert вікна та автоматизація.

2) Модель загроз (мінімум)

Крадіжка довговічних секретів (API-keys, long-lived RT).
Підміна сервісу всередині VPC/кластера.
Міжрегійні атаки при зламаній сегментації.
Replay/підміна трафіку на проксі.
Supply-chain/підміна образу контейнера.
Помилки конфігурації (широкі правила firewall/mesh, загальний JWKS для всіх).

3) Базові патерни S2S

3. 1 mTLS (взаємні сертифікати)

Хто ви: доводить каналом.
Сертифікати короткоживучі (година-доба) з внутрішньої PKI; випуском/ротацією управляє mesh/sidecar або SPIRE-агент.
Хороший для «сусідів» в одному trust-домені і для binding токенів.

3. 2 Сервісні JWT (STS)

Хто ви: доводить повідомленням.
Короткий Access JWT (2-5 хв) з'aud','scp','tenant','region'.
Підписує KMS/HSM, публічні ключі - через JWKS з'kid'і ротацією.
Перевірка локально (без мережевого виклику IdP).

3. 3 SPIFFE/SPIRE (SVID)

Універсальна ідентичність ворклоадів: `spiffe://trust-domain/ns/<ns>/sa/<sa>`.
Автоматичний issuance/rotation X.509/JWT-SVID, інтеграція з Istio/Linkerd.

3. 4 OAuth 2. 1 Client Credentials / Token Exchange (RFC 8693)

Машинні клієнти отримують токен від STS; для дій «від імені» користувача - OBO (token exchange).

Комбінуємо: mTLS для каналу, JWT для повідомлення, SPIFFE - для стійких ідентичностей.

4) Референс-архітектура

[KMS/HSM]       [Policy Store / PDP]

[STS/IdP (issuer)] ── JWKS ──[Gateway/PEP] ─────[Services/PEP]
│
SVID/JWT │         │    │      │
(SPIRE/Istio)│      mTLS/DPoP  │    mTLS/DPoP
│         │    │      │
[Workload/Sidecar]─────────┴───────┴────────────┘

Issuer (STS/IdP): випускає короткі сервісні JWT/CVID, публікує JWKS.
Gateway (PEP): термін мережі, валідує mTLS/JWT, збагачує контекстом, запитує PDP.
Services (PEP): повторна перевірка (defense in depth), кеш рішень PDP.
SPIRE/mesh: авто-сертифікати та SVID для mTLS.

5) Формат сервісного JWT (приклад)

json
{
"iss": "https://sts. core",
"sub": "svc. catalog, "//service identity
"aud": ["svc. search"] ,//target service/domain
"exp": 1730390100, "iat": 1730389800,
"tenant": "brand_eu",
"region": "EE",
"scp": ["catalog:read:public","catalog:read:tenant"],
"mtls": { "bound": true, "spiffe": "spiffe://core/ns/prod/sa/catalog" }
}

Підписаний ES256/EdDSA,'kid'вказує активний ключ.
Опціонально binding до каналу: прапор, hash cert, SVID.

6) Політики видачі (STS) і верифікація

• Subject береться з SVID/клієнтського сертифіката/регістра клієнта.
• Термін життя 2-5 хв, refresh немає - замість цього заново просити STS.
• Скоупи/аудиторії беруться з Policy Store (GitOps), а не із запиту клієнта.

1. Перевірити mTLS (опціонально) і валідність ланцюжка.

2. Перевірити підпис JWT по JWKS (по'kid').

3. Звірити'exp/nbf/iss/aud', tenant/region/licence.

4. Збагатити контекст і запитати PDP (RBAC/ABAC/ReBAC).

5. Кешувати рішення PDP (TTL 30-120 c), інвалідація по подіям.

7) Мульти-тенант і регіони (trust domains)

Розділяйте trust-domain'и: `spiffe://eu. core`, `spiffe://latam. core`.
Роздільні JWKS/PKI по регіонах; міжрегіон - тільки через довірені шлюзи.
Включайте в клейми'tenant/region/licence'і перевіряйте відповідність ресурсу.
Логи/аудит сегментуйте по тенантах і регіонах.

8) Mesh/sidecar і без-mesh режим

Istio/Linkerd: mTLS «з коробки», policy-enforcement на рівні L4/L7, інтеграція зі SPIRE.
Без mesh: бібліотека-клієнт + mutual TLS в додатку; складніше управляти ротацією - автоматизуйте через агента.

9) Ключі, JWKS і ротація

Приватні ключі тільки в KMS/HSM; підпис - віддаленим викликом/апаратом.
Rotation кожні N днів; dual-key: старий + новий приймаються, issuer підписує новим після прогріву кешів.
Моніторинг: частка споживання по'kid', «завислі» клієнти на старому ключі.

yaml issuer:
jwks:
alg: ES256 rotation_days: 30 publish_cache_ttl: 60s sts:
access_ttl: 5m audience_policies:
- subject: "svc. catalog"
allow: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
tenancy:
claims: ["tenant","region","licence"]
jwks_per_region: true

10) Прив'язка до каналу (DPoP/mTLS-bound)

mTLS-bound tokens: в JWT додавати hash клієнтського сертифіката; на прийомі звіряти.
DPoP: для HTTP-клієнтів без mTLS - підписувати кожен запит DPoP-ключем, в AT поміщати thumbprint DPoP.

11) Помилки і політика повернення

• `401 INVALID_TOKEN`/`EXPIRED_TOKEN`/`AUD_MISMATCH`.
• `401 MTLS_REQUIRED`/`MTLS_CERT_INVALID`.
• `403 INSUFFICIENT_SCOPE`/`POLICY_DENY`.
• `429 RATE_LIMITED`.

Відповідь містить machine-readable'error _ code'і'as _ of'( версія ключа/політики).

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

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• споживання по'kid', частка mTLS-bound запитів.

• `subject`, `aud`, `tenant`, `region`, `scp`, `kid`, `sid/svid`, `decision`, `policy_version`, `trace_id`.

• Видача токенів, ротації ключів, зміни політик, відхилені запити.

13) Продуктивність

Верифікація JWT - локально, JWKS кешуйте (TTL 30-60 с) з фоновим оновленням.
X.509-ланцюжки - пінінг CA і кеш OCSP/CRL.
Винесіть дороге валідаційне I/O на gateway/sidecar.
Використовуйте prefetch токенів/сертифікатів (за 10-20 с до закінчення).

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

Contract/interop: різні ЯП/бібліотеки, clock skew ± 300 с.
Negative: прострочений/підроблений токен, невірний'aud', не той регіон/тенант, зламаний cert-chain.
Chaos: раптова ротація'kid', недоступність JWKS, експірація масово, обрив mTLS.
Load: пік видачі на STS, сплеск verify на gateway.
E2E: mTLS-only, JWT-only, комбінований режим, Token Exchange (OBO).

15) Плейбуки (runbooks)

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

Негайний revoke'kid', випуск нового, укорочений TTL токенів, аудит, пошук «завислих» клієнтів, примусовий deny для старого'kid'.

2. Масові'INVALID _ TOKEN '

Перевірити JWKS-кеш, розсинхрон годинника, витоки токенів (TTL занадто короткий), тимчасово розширити допуск skew, прогріти JWKS.

3. mTLS-відмови

Перевірка ланцюжка CA, термінів SVID, часу хоста; emergency-перевипуск через SPIRE/Istio, включити fallback-маршрути тільки всередині регіону.

4. Зростання'AUD _ MISMATCH '

Дрейф політик audience: порівняти STS-policy з фактичними викликами, тимчасово додати потрібний'aud', запланувати коригування архітектури викликів.

5. STS недоступний/сповільнений

Збільшити TTL вже виданих токенів (grace), включити prefetch/refresh-раніше, scale-out STS.

16) Типові помилки

Довгоживучі API-ключі/секрети в env/коді.
Загальний JWKS/PKI «на всі регіони і на всі часи».
Відсутність binding (mTLS/DPoP) → токен легко відвести.
Широкі'aud ='і «адмінські» scopes за замовчуванням.
Ротація без dual-key періоду → масові 401.
Перевірка токенів тільки на gateway (немає defense in depth).
«Німий» відмова (ні'error _ code'і'reason') - складно дебажити і навчати команди.

17) Міні-шаблони конфігурацій

yaml auth:
require_mtls: true jwks:
url: https://sts. core/.well-known/jwks. json cache_ttl: 60s claims:
required: ["iss","sub","aud","exp","tenant","region"]
tenant_in_header: "x-tenant"
pdp:
endpoint: "opa:8181/v1/data/policy/allow"
decision_cache_ttl: 60s

yaml subjects:
- id: "svc. catalog"
spiffe: "spiffe://core/ns/prod/sa/catalog"
audiences: ["svc. search","svc. wallet"]
scopes: ["catalog:read:"]
ttl: "5m"

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

• Короткі сервісні JWT (≤5 хв), локальна верифікація, кеш JWKS.
• mTLS (або DPoP) включений; пріоритетно - mTLS-bound tokens.
• SPIFFE/SPIRE або еквівалент для авто-видачі/ротації сертифікатів.
• STS з політиками audience/scope; видача тільки за довіреною ідентичністю.
• Розділення trust-domains і JWKS по регіонах; клейми tenant/region/licence перевіряються.
• PDP/PEP інтегровані, кеш рішень + інвалідація по подіям.
• Dual-key вікна, моніторинг споживання'kid', алерти на invalid/aud mismatch.
• Повні логи/аудит S2S, включені метрики продуктивності/помилок.
• Плейбуки на компрометацію ключа, падіння STS, збій mTLS.
• Набір contract/negative/chaos/load/E2E тестів пройдено.

Висновок

S2S-аутентифікація - це комбінація канал-довіри (mTLS), повідомлення-довіри (короткі JWT) і стійкої ідентичності ворклоада (SPIFFE), керована централізованим STS і перевіряється локально. Додайте розділення trust-доменів, строгі audience/scopes, автоматичну ротацію і спостережуваність - і отримаєте контур, який надійний, пояснимо і масштабується разом з платформою і її географією.