S2S autentifikatsiyasi

S2S-autentifikatsiya qaysi xizmat/vorkload so’rov qilishini isbotlaydi va unga cheklangan vaqt uchun minimal zarur huquqlarni beradi. Foydalanuvchi oqimlaridan farqli o’laroq, bu yerda hech kim yo’q, shuning uchun hisob ma’lumotlarining qisqa umr ko’rish muddati, ish joyiga/kanalga kriptografik bog’lanish va aniq kuzatish juda muhimdir.

1) Maqsad va prinsiplar

Zero Trust andoza: tarmoqqa ishonmaslik, faqat vorkload va kriptografiyani sertifikatlash.
Qisqa umr ko’rish mumkin: kunlar/oylar emas, daqiqalar.
Kontekstga bogʻlash: tenant/region/licence/audience/scopes.
Markazlashtirilgan berish, markazlashtirilmagan tekshirish: STS/IdP + lokal verifikatsiya.
Eng kam imtiyozlar va aniq topshirish: faqat kerakli sotib olish va audit.
Og’riqsiz rotatsiya: dual-key/dual-cert derazalar va avtomatlashtirish.

2) Tahdidlar modeli (minimal)

Uzoq muddatli sirlarni o’g "irlash (API-keys, long-lived RT).
VPC/klaster ichida xizmatni almashtirish.
Segmentatsiya buzilganda mintaqalararo hujumlar.
Proksi uchun trafikni replay/almashtirish.
Supply-chain/konteyner tasvirini almashtirish.
Konfiguratsiya xatolari (keng firewall/mesh qoidalari, hamma uchun umumiy JWKS).

3) Bazaviy patternlar S2S

3. 1 mTLS (o’zaro sertifikatlar)

Siz kimsiz: buni kanal isbotlaydi.
Ichki PKI dan qisqa umr ko’rish sertifikatlari (soat-sutka); chiqarishni/rotatsiyani mesh/sidecar yoki SPIRE-agent boshqaradi.
Bitta trust domenidagi «qo’shnilar» va binding tokenlari uchun yaxshi.

3. 2 Servis JWT (STS)

Siz kimsiz: buni xabar bilan isbotlaysiz.
Qisqa Access JWT (2-5 daqiqa) s’aud’,’scp’,’tenant’,’region’.
KMS/HSM, ochiq kalitlarni «kid» va rotatsiya bilan JWKS orqali imzolaydi.
Lokal tekshirish (IdP tarmoq chaqiruvisiz).

3. 3 SPIFFE/SPIRE (SVID)

Vorkloadlarning universal identifikatsiyasi:’spiffe ://trust-domain/ns/< ns >/sa/< sa>’.
Avtomatik issuance/rotation X.509/JWT-SVID, Istio/Linkerd bilan integratsiya.

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

Mashina mijozlari STSdan token oladilar; OBO (token exchange).

mTLS - kanal uchun, JWT - xabar uchun, SPIFFE - barqaror identifikatsiyalar uchun.

4) Referens arxitektura

[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): qisqa xizmat JWT/CVID chiqaradi, JWKS nashr etadi.
Gateway (PEP): tarmoq atamasi, mTLS/JWTni tasdiqlaydi, kontekstni boyitadi, PDPni so’raydi.
Services (PEP): qayta tekshirish (defense in depth), PDP yechimlari keshini.
SPIRE/mesh: mTLS uchun avto sertifikatlar va SVID.

5) Servis JWT formati (misol)

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 imzolangan,’kid’aktiv kalitni koʻrsatadi.
Kanalga qoʻshimcha ravishda binding: bayroq, hash cert, SVID.

6) Berish siyosati (STS) va verifikatsiya

• Subject SVID/mijoz sertifikati/mijoz registridan olinadi.
• Umr ko’rish muddati 2-5 daqiqa, refresh yo’q - buning o’rniga yana STS so’rash.
• Xaridlar/auditoriyalar mijozning so’rovidan emas, balki Policy Store (GitOps) dan olinadi.

1. mTLS (ixtiyoriy) va zanjirning haqiqiyligini tekshirish.

2. JWKS (’kid’) boʻyicha JWT imzosini tekshirish.

3. Solishtirish’exp/nbf/iss/aud’, tenant/region/licence.

4. Kontekstni boyitish va PDP (RBAC/ABAC/ReBAC) ni so’rash.

5. PDP (TTL 30-120 c) yechimini keshlash, voqealar bo’yicha nogironlik.

7) Multi-tenant va mintaqalar (trust domains)

Trust-domain’larni ajrating:’spiffe ://eu. core`, `spiffe://latam. core`.
Mintaqalar bo’yicha alohida JWKS/PKI; mintaqalararo - faqat ishonchli shlyuzlar orqali.
’tenant/region/licence’ tamgʻalarini kiriting va resursga muvofiqligini tekshiring.
Logi/auditni tenantlar va mintaqalar bo’yicha segmentlang.

8) Mesh/sidecar va bez-mesh rejimi

Istio/Linkerd: mTLS «qutidan», L4/L7 darajasida policy-enforcement, SPIRE bilan integratsiya.
Mesh’siz: ilovadagi kutubxona-mijoz + mutual TLS; rotatsiyani boshqarish qiyinroq - agent orqali avtomatlashtiring.

9) Kalitlar, JWKS va rotatsiya

Maxfiy kalitlar faqat KMS/HSM; imzo - masofadan chaqiruv/apparat orqali.
Rotation har N kunda; dual-key: eski + yangi qabul qilinadi, issuer yangi imzo chekadi.
Monitoring: «kid» bo’yicha iste’mol ulushi, eski kalitdagi «osilgan» mijozlar.

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) Kanalga bog’lash (DPoP/mTLS-bound)

mTLS-bound tokens: JWTga xash mijoz sertifikatini qo’shish; qabulda tekshirish.
DPoP: mTLSsiz HTTP mijozlar uchun - har bir DPoP soʻrovini kalit bilan imzolash, ATga DPoP thumbprint joylashtirish.

11) Xatolar va qaytarish siyosati

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

Javobda machine-readable’error _ code’va’as _ of’(kalit/siyosat versiyasi) mavjud.

12) Kuzatuv va audit

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• ’kid’ bo’yicha iste’mol, so’rovlarning mTLS-bound ulushi.

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

• Tokenlarni berish, kalitlarni almashtirish, siyosatni o’zgartirish, rad etilgan so’rovlar.

13) Unumdorlik

JWT verifikatsiyasi - lokal, JWKSni orqa fon yangilanishi bilan kesh qiling (TTL 30-60 s).
X.509-zanjirlar - CA pinning va OCSP/CRL kesh.
Qimmatbaho I/O validatsiyasini gateway/sidecar ga olib chiqing.
Prefetch token/sertifikatlardan foydalaning (tugashidan 10-20 s oldin).

14) Test sinovlari

Contract/interop: turli YE/kutubxonalar, clock skew ± 300 s.
Negative: muddati oʻtgan/soxta token, notoʻgʻri’aud’, notoʻgʻri mintaqa/tenant, singan cert-chain.
Chaos:’kid’ning to’satdan aylanishi, JWKSning mavjud emasligi, ommaviy ekspiratsiya, mTLS uzilishi.
Load: STSda chiqarishning eng yuqori choʻqqisi, gateway’da verify koʻtarilishi.
E2E: mTLS-only, JWT-only, kombinatsiyalangan rejim, Token Exchange (OBO).

15) Pleybuklar (runbooks)

1. Imzo kalitini buzish

Darhol revoke’kid’, yangi, qisqartirilgan TTL tokenlarini chiqarish, audit, «osilgan» mijozlarni qidirish, eski’kid’uchun majburiy deny.

2. Ommaviy’INVALID _ TOKEN ’

JWKS keshini, soatlarning rasinxronini, tokenlarning kelib chiqishini (TTL juda qisqa) tekshirish, vaqtincha skew’ni kengaytirish, JWKS’ni isitish.

3. mTLS-nosozliklar

CA zanjirini, SVID muddatlarini, xost vaqtini tekshirish; SPIRE/Istio orqali emergency-qayta chiqarish, fallback-yo’nalishlarni faqat mintaqa ichida o’z ichiga oladi.

4. ’AUD _ MISMATCH’ ning o’sishi

Dreyf audience siyosatchisi: STS-policy’ni haqiqiy qo’ng’iroqlar bilan solishtirish, vaqtincha kerakli’aud’qo’shish, qo’ng’iroqlar arxitekturasini tuzatishni rejalashtirish.

5. STS mavjud emas/sekinlashtirildi

Allaqachon berilgan TTLni kattalashtirish (grace), prefetch/refresh-erta, scale-out STSni yoqish.

16) Tipik xatolar

env/koddagi uzoq umr ko’radigan API-kalitlar/sirlar.
Umumiy JWKS/PKI «barcha hududlar va barcha davrlar uchun».
Binding yo’qligi (mTLS/DPoP) → tokenni olib tashlash oson.
Andoza’aud =’va’admin’scopes.
Dual-key davrisiz rotatsiya → ommaviy 401.
Faqat gateway orqali tokenlarni tekshirish (defense in depth yoʻq).
«Soqov» rad etish (no’error _ code’va’reason’) - jamoalarni tortishish va o’qitish qiyin.

17) Konfiguratsiyaning mini-shablonlari

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) Sotishdan oldingi chek-varaq

• Qisqa servis JWT (≤ 5 daqiqa), mahalliy tekshirish, JWKS kesh.
• mTLS (yoki DPoP) kiritilgan; ustuvor - mTLS-bound tokens.
• SPIFFE/SPIRE yoki sertifikatlarni avtomatik berish/rotatsiya qilish uchun ekvivalent.
• STS audience/scope siyosati bilan; faqat ishonchli identifikatsiya bo’yicha berish.
• Trust-domains va JWKSni mintaqalar bo’yicha bo’lish; tenant/region/licence tamgʻalari tekshirilmoqda.
• PDP/PEP integratsiyalashgan, yechimlar keshi + voqealar bo’yicha nogironlik.
• Dual-key derazalar, iste’mol monitoringi’kid’, invalid/aud mismatch.
• To’liq logi/audit S2S, ishlash/xato ko’rsatkichlari kiritilgan.
• Kalitni buzish uchun pleybuklar, STS qulashi, mTLS nosozligi.
• contract/negative/chaos/load/E2E testlar to’plami o’tdi.

Xulosa

S2S-autentifikatsiya - bu markazlashtirilgan STS tomonidan boshqariladigan va mahalliy tekshiriladigan ishonch kanali (mTLS), ishonch xabari (qisqa JWT) va barqaror vorkload identifikatsiyasi (SPIFFE) kombinatsiyasi. Trust-domenlar bo’linishi, qattiq audience/scopes, avtomatik rotatsiya va kuzatuvni qo’shing va platforma va uning geografiyasi bilan birga ishonchli, tushunarli va kattalashtirilgan konturni oling.