Açarların və tokenlərin rotasiyası

1) Niyə rotasiya lazımdır

Açarlar və tokenlər qaçılmaz olaraq «qocalır»: log/backup ekspozisiyası, insayder riskləri, kitabxanaların zəifliyi, tərəfdaşların sızması. Rotasiya «risk ömrünü» azaldır və insidentlərin idarə olunmasını təmin edir. Məqsəd proqnozlaşdırıla bilən rotasiya dövrləri və fasiləsiz sürətli geri çağırma mexanizmləri qurmaqdır.

2) Sahə: tam olaraq nə çeviririk

İmza/şifrələmə açarları: JWT (JWS/JWE), OAuth/OIDC, SAML, webhucks (HMAC), lisenziyalar.
İnteqrasiya sirləri: API açarları, client secret, texniki parollar. istifadəçilər.
TLS/mTLS: server/müştəri sertifikatları, kök/aralıq CA.
Məlumat açarları: KMS/HSM-də KEK/CMK, DEK (envelope encryption).
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.

3) Saxlama, versiyalar, etiketlər

KMS/HSM/Vault həqiqət mənbəyi kimi. Şəxsi açarları git/ENV/görüntü fayllarında saxlamaq qadağandır.
Version: 'key _ id '/' version' + etiketlər: 'purpose = jwt-sign', 'env = prod', 'alg = ES256', 'created _ at', 'rotates _ at'.
Giriş siyasəti: minimum zəruri hüquqlar prinsipi (least privilege), vəzifə bölgüsü (SoD).
Audit: kim yaratdı/oxudu/imzaladı; dəyişməz jurnallar.

4) Əsas rotasiya nümunələri

4. 1 Üst-üstə düşən pəncərələr (graceful rollover)

Yeni açar → JWKS-də dərc/sertifikatı paylayın.
Örtük pəncərəsi: köhnə və yeni açarlarla validasiya, imza - yalnız yeni.
grace müddəti başa çatdıqdan sonra - etibarlı dəstdən köhnə silinir.

4. 2 Cüt buraxılış (dual-run)

Bəzi instansiyaların köhnə, bəziləri yeni (böyük flitlər üçün) imzaladığı qısa müddət.
Ciddi sinxronlaşdırılmış JWKS və 'kid' üzrə validasiya payının monitorinqini tələb edir.

4. 3 Rotate-on-schedule vs rotate-on-use

Cədvələ görə: N gün/həftədə bir dəfə (imza açarları, TLS).
Istifadə edildikdə: refresh-tokenlər - birdəfəlik, hər mübadilə üçün yeni («sürüşkən» rotasiya).

5) JWT/JWKS: təcrübə

5. 1 Başlıqlar və identifikatorlar

Yoxlama açarını seçmək üçün JWS başlığında 'kid' istifadə edin.
Minimum terminal, qısa 'exp', düzgün 'aud/iss/nbf'.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

5. 2 Nəşr JWKS

JWKS bütün aktiv yoxlama açarlarını (grace pəncərəsində köhnə + yeni) ehtiva etməlidir.
Müştərilərdə JWKS caching: qısa TTL (məsələn, 5-15 dəq).
Güzəşt zamanı - JWKS-dən güzəştli açarı silmək (kəskin), fors-əlil cache.

json
{
"keys": [
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-10","use":"sig","alg":"ES256","x":"...","y":"..." },
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-07","use":"sig","alg":"ES256","x":"...","y":"..." }
]
}

5. 3 Kadens və şərtlər

JWT imzası: hər 3-6 ayda bir açarın rotasiyası (və ya yüksək risk üçün daha tez-tez).
'exp' access-token: 5-30 dəq; refresh - 7-30 gün («rotate-on-use» ilə).
Qaçırma riskini azaltmaq üçün PoP/DPoP ilə məcburi «yapışdırma» (bax § 8).

6) HMAC rotasiyası (vebhuk/imza)

Aktiv və kanarya sirlərini saxlayın; hər iki imza qəbul edin.
Başlıqlar: 'X-Signature' + 'X-Timestamp'; pəncərə məhdudiyyəti ± 300s.
Köhnə tam bağlanması - göndərici təsdiqləndikdən sonra.
Tərəfdaşlar üçün: keçid tarixi-vaxtı və end-point yoxlamasını dərc edin.

7) TLS/mTLS və etimad zəncirləri

ACME/auto-renew ictimai server sertifikatları üçün (Let 's Encrypt və ya korporativ CA).
mTLS: qısa müştəri sertifikatları (7-30 gün), avtomatik kanal rotasiyası (SPIFFE/SPIRE/mesh).
Ara/kök CA rotasiyası - yalnız üst-üstə düşən güvən lövbərləri (trust bundle) və uzun canary vasitəsilə.
OCSP/CRL və clock-skew-i izləyin. Loqidə - validasiya uğursuzluğunun səbəbləri.

8) PoP/DPoP və Client Token açarı

DPoP (Demonstration of Proof-of-Possession): token müştərinin public-key ilə bağlıdır; replay riskini azaldır.
Müştəri açarının rotasiyası = yeni DPoP açarının, tokenlərin buraxılışı - qısa müddətə.
Xidmət üçün mTLS üstünlük verilir (cihaz/vorker HSM/TPM-də açarı «daşıyır»).

9) Refresh-tokenlər: rotate-on-use

Birdəfəlik refresh tokenləri: hər mübadilə → yeni refresh + access.
Geri çağırılan 'jti '/' sid' siyahısı TTL ilə saxlamaq = refresh ömrü.
Təkrar istifadə detekti (re-play): sessiyanın/cihazın dərhal geri çağırılması, alert.

10) Baxış və kilid siyahıları

JWT heç bir introspektsiya: qısa 'exp' + 'qara siyahıları' kritik hallar üçün 'jti' istifadə edin (yerli/Redis, hashtaging).
OAuth introspection: mərkəzləşdirilmiş status server; qısa TTL ilə «active = false/true» cache.
API açarları: açar hash (parollar kimi), sahibi/tenant etiketləri, scope, yaradılma/son giriş tarixi; baxış - dərhal.

11) Data açarları: envelope-şifrələmə

CMK/KEK (KMS/HSM) DEK qoruyur; CMK rotasiyası məlumatların yenidən açılması olmadan baş verir: DEK pere-wrap.
Hər bir obyekt/tenant/partiya üçün DEK; KDF/HKDF törəmə açarları üçün.
Məhv etmə siyasəti (crypto-shredding): KEK-in silinməsi = güzəşt zamanı məlumatların oxunmazlığı.

12) Hadisə prosedurları (kompromasiya)

1. Dondurun: güzəştli açarda tokenlərin buraxılmasını dayandırın, emissiyanı yenisinə keçirin.
2. Geri çağırın: JWKS-dən 'kid' silmək, sertifikatları geri götürmək (OCSP/CRL), siyahıda API açarlarını bloklamaq.
3. TTL-i qısaltın: 'exp' tokenlərini müvəqqəti olaraq azaltın, PoP/DPoP yoxlamasını gücləndirin.
4. Məcburi logout: sessiyaları əlil etmək (revoke 'sid '/' jti').
5. Forensika və hesabat: time layns, əhatə, kim/nə zərər; playbook yeniləmək.

13) Paypline və rollout

13. 1 Nəsil və nəşr

HSM/KMS-də açarlar yaradın; xüsusi açar ixracı - qadağandır.
Yoxlama və testlərlə JWKS/sertifikatların avtomatik yayımı.
Kanarya Release: 1-5% müştərilər → 100%.

13. 2 Sağlamlıq nəzarəti

Metriklər: 'kid' üzrə validasiyaların payı, imza/sertifikat səhvləri, saat sürüklənməsi.
Alerts: 401/403 imzaya görə sıçrayış, OCSP/CRL mövcud deyil, müddəti bitən sertifikatlar (T-30/T-7/T-1).

14) Konfiqilər və nümunələr

14. 1 Vault/KMS siyasəti nümunəsi (psevdo)

hcl path "transit/keys/jwt-prod" {
capabilities = ["read," "update," "list"] # signature/rotation
}
path "transit/keys/jwt-prod/rotate" {
capabilities = ["update"]
}

14. 2 JWT rotasiya planının nümunəsi

T0: create a new version of the key (kid = jwt-2025-10), add to JWKS
T0 + 15m: start signing with a new kid; validate with old and new
T0 + 7d: remove old kid from JWKS
T0 + 30d: delete old private key from KMS (schedule purge)

14. 3 Envoy: JWKS-in məcburi yenilənməsi (psevdo)

yaml jwt_authn:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster timeout: 2s cache_duration: 300s # короткий TTL

15) Müşahidə və audit

Метрики: `jwt_verify_fail_total{reason}`, `jwks_refresh_total`, `jwks_kid_share{kid}`, `token_revoked_total`, `refresh_rotations_total`, `dpop_fail_total`.
Логи: `kid`, `jti`, `sid`, `reason`, `client_id`, `tenant`, `trace_id` (без PII).
Daşbordlar: 'kid' paylarının xəritəsi, müddəti bitən sertifikatlar, geri çağırma tezliyi, bölgələr üzrə qeyri-sabit imzalar.

16) Antipattern

Uzun ömürlü JWT geri çağırılmadan və qısa 'exp' olmadan.
Yoxlama açarının 'kid' və 'manual' seçilməməsi.
KMS olmadan və etcd səviyyəsində şifrələmə olmadan ENV/k8s-Secret gizli saxlamaq.
Qeyri-rotasiya refresh tokenləri; refresh detektor olmadan təkrar istifadə.
«Hamı üçün» vahid qlobal API açarı.
JWKS yayımı və monitorinqi olmadan yeni açarların «sakit» buraxılması.
Sıfır tavan pəncərələri (ani əvəz) → kütləvi 401/403.

17) iGaming/Maliyyə Xüsusiyyətləri

Tənzimləyicilər və audit: dəyişməz rotasiya/rəy qeydləri; zamanın və aktyorların sübuta yetirilməsi.
Partnyor PSP/KYC: partnyor/yurisdiksiya üçün fərdi açarlar; SLA/təhlükəsizlik pozuntuları halında sürətli geri çağırış.
Multi-icarə: scope ilə per-tenant API-açarları; brendlərin/bölgələrin açarlarının izolyasiyası.
Yüksək risk: Kritik əməliyyatlar üçün PoP/DPoP, qısa 'exp', daxili xidmətlər arasında mTLS.
Backoffice: SSO/OIDC, qısa sessiyalar, avadanlıq tokenləri (FIDO2), hər yerdə rotate-on-schedule.

18) Prod hazırlıq yoxlama siyahısı

• KMS/HSM/Vault-da bütün xüsusi açarlar; ixrac qadağandır.
• JWKS nəşr və qısa TTL ilə cached; JWT başlıqlarında 'kid' var.
• Üst-üstə düşən pəncərə və avtomatik rollout ilə rotasiya planı.
• Refresh-tokenlər birdəfəlik; TTL ilə geri çağırılmış 'jti' siyahısı.
• HMAC sirləri: aktiv + kanarya; hər ikisi qəbul; T-keçid vaxt elan.
• TLS/mTLS: auto-renew, alert T-30/T-7/T-1, CA dəyişdirmək üçün trust bundle.
• Envelope-şifrələmə: KEK/CMK fasiləsiz rotasiya, DEK per-obyekt/tenant.
• İmza, JWKS, rəylər üzrə metriklər/alertlər; dashbord 'kid' -dollar.
• Hadisələrin playbook (güzəşt) və müntəzəm təlimlər.
• Yeni/SA açarları ilə canary testləri və validasiya replikaları.

19) TL; DR

Açarları KMS/HSM-də saxlayın, JWT-ni 'kid' ilə imzalayın və JWKS-i dərc edin. Üst üstə düşən açarları və sertifikatları rotasiya edin, 'kid' üzrə validasiya paylarını izləyin. Refresh - rotate-on-use və qısa 'exp'; kritik əməliyyatlar üçün - PoP/DPoP və mTLS. Məlumatlar üçün KEK rotasiyası ilə envelope şifrələməsindən istifadə edin. Metriklər/alertlər, hadisə pleybukları və müntəzəm kanarya rotasiyaları tətbiq edin.