S2S-autentifikasiya

S2S-autentifikasiyası hansı xidmət/workload sorğu etdiyini sübut edir və ona məhdud vaxt üçün minimum lazımi hüquqları verir. İstifadəçi axınlarından fərqli olaraq, burada heç bir insan yoxdur - buna görə də hesabat məlumatlarının ömrü, workload/kanal üçün kriptoqrafik bağlantı və aydın müşahidə vacibdir.

1) Məqsədlər və prinsiplər

Zero Trust default: şəbəkəyə etibar etməyin, yalnız workload və kriptoqrafiya sertifikatları.
Qısamüddətli kreditlər: günlər/aylar deyil, dəqiqələr.
Kontekstə bağlama: tenant/region/licence/audience/scopes.
Mərkəzləşdirilmiş emissiya, mərkəzləşdirilməmiş yoxlama: STS/IdP + lokal yoxlama.
Minimum imtiyazlar və açıq nümayəndəlik: yalnız lazımi alış-veriş və audit.
«Ağrısız» rotasiya: dual-key/dual-cert pəncərələr və avtomatlaşdırma.

2) Təhdid modeli (minimum)

Uzun ömürlü sirlərin oğurlanması (API-keys, uzun ömürlü RT).
VPC/klaster daxilində xidmətin dəyişdirilməsi.
Sınıq seqmentasiya zamanı bölgələrarası hücumlar.
Replay/proxy trafikin dəyişdirilməsi.
Supply-chain/konteyner şəklinin dəyişdirilməsi.
Konfiqurasiya səhvləri (geniş firewall/mesh qaydaları, hamı üçün ümumi JWKS).

3) Əsas nümunələr S2S

3. 1 mTLS (qarşılıqlı sertifikatlar)

Siz kimsiniz: kanal tərəfindən sübut olunur.
Daxili PKI-dən qısa ömürlü (saat-gün) sertifikatlar; mesh/sidecar və ya SPIRE agent tərəfindən idarə olunur.
Bir trust-domen və binding tokenləri üçün «qonşular» üçün yaxşıdır.

3. 2 Xidmət JWT (STS)

Siz kimsiniz: mesaj sübut edir.
Qısa Access JWT (2-5 dəq) ilə 'aud', 'scp', 'tenant', 'region'.
KMS/HSM, ictimai açarları 'kid' və rotasiya ilə JWKS vasitəsilə imzalayır.
Yerli yoxlama (IdP şəbəkə çağırışı olmadan).

3. 3 SPIFFE/SPIRE (SVID)

Workloadların universal kimliyi: 'spiffe ://trust-domain/ns/< ns >/sa/< sa>'.
Avtomatik issuance/rotation X.509/JWT-SVID, Istio/Linkerd ilə inteqrasiya.

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

Maşın müştəriləri STS-dən token alırlar; OBO (token exchange).

Birləşdirin: kanal üçün mTLS, mesaj üçün JWT, davamlı şəxsiyyət üçün SPIFFE.

4) istinad arxitekturası

[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 qısa xidmət buraxır, JWKS nəşr edir.
Gateway (PEP): şəbəkə termini, mTLS/JWT təsdiqləyir, kontekstlə zənginləşdirir, PDP tələb edir.
Services (PEP): yenidən yoxlama (defense in depth), PDP həll önbellək.
SPIRE/mesh: mTLS üçün avto sertifikatlar və SVID.

5) JWT xidmət formatı (nümunə)

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 tərəfindən imzalanmış, 'kid' aktiv açarı göstərir.
Kanala əlavə: bayraq, hash cert, SVID.

6) Ekstradisiya siyasəti (STS) və yoxlama

• Subject SVID/müştəri sertifikatı/müştəri reyestrindən götürülür.
• Ömrü 2-5 dəq, refresh yoxdur - bunun əvəzinə yenidən STS istəyin.
• Alış-veriş/auditoriya müştərinin tələbindən deyil, Policy Store-dan (GitOps) götürülür.

1. mTLS (isteğe bağlı) və zəncir etibarlılığını yoxlayın.

2. JWKS ('kid') üzrə JWT imzasını yoxlayın.

3. 'exp/nbf/iss/aud', tenant/region/licence.

4. Konteksti zənginləşdirin və PDP (RBAC/ABAC/ReBAC) soruşun.

5. PDP həllini (TTL 30-120 c), hadisələrə görə əlillik.

7) Multi-tenant və regionlar (trust domains)

trust-domain 'paylaşın:' spiffe ://eu. core`, `spiffe://latam. core`.
Bölgələr üzrə ayrı-ayrı JWKS/PKI; regionlararası - yalnız etibarlı şlüzlər vasitəsilə.
'tenant/region/licence' markalarına daxil edin və resursun uyğunluğunu yoxlayın.
Tenant və bölgələrə görə log/audit seqmentləri.

8) Mesh/sidecar və mesh olmadan rejimi

Istio/Linkerd: mTLS «qutudan», L4/L7 səviyyəsində policy-enforcement, SPIRE ilə inteqrasiya.
Mesh olmadan: kitabxana-müştəri + tətbiqdə mutual TLS; rotasiyanı idarə etmək daha çətindir - agent vasitəsilə avtomatlaşdırın.

9) Açarlar, JWKS və rotasiya

Şəxsi açarlar yalnız KMS/HSM-də; imza - uzaqdan zəng/cihaz.
Hər N gün Rotation; dual-key: köhnə + yeni qəbul, issuer cashes qızdırıldıqdan sonra yeni imzalayır.
Monitorinq: «kid» üzrə istehlak payı, köhnə açarda «asılı» müştərilər.

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) Kanal bağlantısı (DPoP/mTLS-bound)

mTLS-bound tokens: JWT-yə hash müştəri sertifikatı əlavə edin; qəbulda yoxlamaq.
DPoP: mTLS olmayan HTTP müştəriləri üçün - hər bir DPoP sorğusunu DPoP açarı ilə imzalayın, AT thumbprint DPoP yerləşdirin.

11) Səhvlər və geri qaytarma siyasəti

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

Cavab machine-readable 'error _ code' və 'as _ of' (açar/siyasət versiyası) daxildir.

12) Müşahidə və audit

• `s2s_auth_p95_ms`, `verify_jwt_p95_ms`, `jwks_skew_ms`,
• `invalid_token_rate`, `aud_mismatch_rate`, `insufficient_scope_rate`,
• 'kid' istehlakı, mTLS-bound sorğuların payı.

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

• Tokenlərin verilməsi, açarların rotasiyası, siyasətlərin dəyişdirilməsi, rədd edilmiş sorğular.

13) Performans

JWT doğrulama - yerli, JWKS fon yeniləmə ilə cache (TTL 30-60 s).
X.509 zəncirləri - CA pinning və OCSP/CRL cache.
gateway/sidecar-da bahalı I/O validasiya edin.
Prefetch token/sertifikatlardan istifadə edin (10-20 saniyə əvvəl).

14) Test

Contract/interop: müxtəlif YAP/kitabxanalar, saat skew ± 300 s.
Negative: vaxtı keçmiş/saxta token, səhv 'aud', yanlış bölgə/tenant, cert-chain.
Chaos: qəfil 'kid' rotasiyası, JWKS əlçatmazlığı, kütləvi ekspirasiya, mTLS qırılması.
Yükləmə: STS-də buraxılış zirvəsi, gateway-də verify sıçrayışı.
E2E: mTLS-only, JWT-only, kombinə rejimi, Token Exchange (OBO).

15) Playbooks (runbooks)

1. İmza açarının güzəşti

Dərhal revoke 'kid', yeni, qısaldılmış TTL tokenlərinin buraxılması, audit, «asılmış» müştərilərin axtarışı, köhnə 'kid' üçün məcburi deny.

2. Kütləvi 'INVALID _ TOKEN'

JWKS önbelleğini yoxlayın, saat rasinkronunu, tokenlərin mənşəyini (TTL çox qısa), müvəqqəti olaraq skew toleransını genişləndirin, JWKS-i qızdırın.

3. mTLS nasazlıqları

CA zəncirinin, SVID vaxtının, hostun vaxtının yoxlanılması; SPIRE/Istio vasitəsilə emergency-release, yalnız regionda fallback marşrutları daxil.

4. Böyümə 'AUD _ MISMATCH'

Drift audience siyasətçisi: STS-policy-ni faktiki çağırışlarla müqayisə edin, müvəqqəti olaraq 'aud' əlavə edin, çağırış arxitekturasının tənzimlənməsini planlaşdırın.

5. STS mövcud deyil/yavaşladı

Artıq verilmiş tokenlərin TTL-ni artırın (grace), prefetch/refresh-əvvəl, scale-out STS daxil edin.

16) Tipik səhvlər

env/kodda uzun ömürlü API açarları/sirləri.
Ümumi JWKS/PKI 'bütün regionlar və bütün dövrlər üçün ".
Heç bir binding (mTLS/DPoP) → token asandır.
Geniş 'aud =' və «admin» scopes default.
Dual-key dövrü → kütləvi 401 olmadan rotasiya.
Tokenləri yalnız gateway-də yoxlamaq (defense in depth yoxdur).
«Dilsiz» imtina (no 'error _ code' və 'reason') - komandaları debat etmək və öyrətmək çətindir.

17) Mini konfiqurasiya şablonları

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) Satış öncəsi yoxlama siyahısı

• Qısa xidmət JWT (≤ 5 dəq), yerli yoxlama, JWKS cache.
• mTLS (və ya DPoP) daxil; prioritet - mTLS-bound tokens.
• SPIFFE/SPIRE və ya avtomatik/rotasiya sertifikatları üçün ekvivalent.
• STS audience/scope siyasətləri ilə; yalnız etibarlı şəxsiyyətə görə verilir.
• Trust-domains və JWKS-in bölgələrə bölünməsi; tenant/region/licence markaları yoxlanılır.
• PDP/PEP inteqrasiya, cache həllər + hadisələr üçün əlillik.
• Dual-key pəncərələri, istehlak monitorinqi 'kid', invalid/aud mismatch.
• Tam log/audit S2S, performans/səhv metrikləri daxildir.
• Açar kompromasiyası, STS düşməsi, mTLS uğursuzluğu üçün playbook.
• contract/negative/chaos/load/E2E testlərin dəsti keçdi.

Nəticə

S2S-autentifikasiya mərkəzləşdirilmiş STS tərəfindən idarə olunan və yerli olaraq yoxlanılan etimad kanalı (mTLS), etimad mesajı (qısa JWT) və davamlı workload identity (SPIFFE) birləşməsidir. Trust-domain bölgüsü, ciddi audience/scopes, avtomatik rotasiya və müşahidə əlavə edin - və platforma və onun coğrafiyası ilə birlikdə etibarlı, izah edilə bilən və miqyaslı bir kontura sahib olun.