Rotation des clés et des tokens

1) Pourquoi la rotation est nécessaire

Les clés et les jetons « vieillissent » inévitablement : exposition dans les logs/backaps, risques d'initiés, vulnérabilités des bibliothèques, fuites chez les partenaires. La rotation réduit la « durée de vie du risque » et permet de gérer les incidents. L'objectif est de construire des cycles de rotation prévisibles et des mécanismes de rappel rapide sans interruption.

2) Zone : Exactement ce que nous tournons

Clés de signature/cryptage : JWT (JWS/JWE), OAuth/OIDC, SAML, webhooks (HMAC), licences.
Secrets d'intégration : clés API, client secret, mots de passe techniques. utilisateurs.
TLS/mTLS : certificats serveur/client, CA racine/intermédiaire.
Clés de données : KEK/CMK dans KMS/HSM, DEK (envelope encryption).
Токены: access/refresh, service-to-service (mTLS, HMAC), short-lived session.

3) Stockage, versions, étiquettes

KMS/HSM/Vault comme source de vérité. Il est interdit de stocker des clés privées dans les fichiers git/BOU/image.
Versioning : 'key _ id '/' version' + étiquette : 'purpose = jwt-sing', 'bou = prod',' alg = ES256 ',' created _ at ',' rotates _ at'.
Politiques d'accès : principe des droits minimaux requis (least privilège), partage des responsabilités (SoD).
Vérification : qui a créé/lu/signé ; revues immuables.

4) Modèles de rotation de base

4. 1 Fenêtres superposées (graceful rollover)

Nous publions → une nouvelle clé dans JWKS/distribuons le certificat.
Fenêtre de chevauchement : validation par les anciennes et nouvelles clés, signature par les nouvelles.
Après l'expiration de la période grace - nous supprimons l'ancien de l'ensemble de confiance.

4. 2 Double sortie (dual-run)

Une courte période où une partie des instances signe l'ancienne, la partie est nouvelle (pour les grands flots).
Nécessite un JWKS strictement synchronisé et la surveillance de la proportion de validation par 'kid'.

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

Horaire : une fois tous les N jours/semaines (clés de signature, TLS).
Lors de l'utilisation : les jetons refresh sont jetables, pour chaque échange d'une nouvelle sortie (rotation « glissante »).

5) JWT/JWKS : pratique

5. 1 Titres et identifiants

Utilisez 'kid' dans l'en-tête JWS pour sélectionner la clé de vérification.
Un minimum de clymes, court 'bou', correct 'aud/iss/nbf'.

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

5. 2 Publication du JWKS

Le JWKS doit contenir toutes les clés de vérification actives (ancienne + nouvelle dans la fenêtre grace).
Mise en cache JWKS chez les clients : court TTL (par exemple, 5-15 min).
En cas de compromission - supprimer la clé compromise de JWKS (brusquement), force-invalidation du 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 Cadens et échéances

Signature JWT : rotation de la clé tous les 3-6 mois (ou plus souvent pour le risque élevé).
Token d'accès : 5-30 min ; refresh - 7-30 jours (avec « rotate-on-use »).
« Collage forcé » avec PoP/DPoP (voir § 8) pour réduire le risque de vol.

6) Rotation HMAC (webhooks/signatures)

Gardez des secrets actifs et canariens ; acceptez les signatures des deux.
Titres : 'X-Signature' + 'X-Timestamp' ; limitation de la fenêtre ± 300c.
Désactivation totale de l'ancien - une fois que l'expéditeur a changé.
Pour les partenaires : publiez la date-heure de basculement et la validation endpoint.

7) TLS/mTLS et chaînes de confiance

ACME/auto-renew pour les certificats de serveur public (Let's Encrypt ou Corporate CA).
mTLS : certificats clients courts (7-30 jours), rotation automatique sur les canaux (SPIFFE/SPIRE/mesh).
Rotation du CA intermédiaire/racine - seulement par le chevauchement des ancres de confiance (trust bundle) et canary long.
Regardez OCSP/CRL et clock-skew. Les logs sont les raisons du refus de validation.

8) PoP/DPoP et ligament du client token↔klyuch

DPoP (Démonstration of Proof-of-Possession) : jeton lié à la clé publique du client ; réduit le risque de replay.
Rotation de la clé client = sortie d'une nouvelle clé DPoP, tokens - pour une courte durée.
Pour le service-k-service, mTLS est préféré (le périphérique/worker « porte » la clé dans HSM/TPM).

9) Jetons Refresh : rotate-on-use

Jetons de refresh jetables : chaque échange → un nouveau refresh + access.
Conserver la liste "jti "/" sid'rappelée avec TTL = durée de vie refresh.
Détail de la réutilisation (re-play) : révocation immédiate de la session/de l'appareil, alert.

10) Révocation et listes de verrouillage

JWT sans introspection : utilisez les listes brèves « bou » + « black lists » « jti » pour les cas critiques (localement/dans Redis, chardonnages par hachage).
OAuth introduction : serveur de statut centralisé ; mettez en cache « active = false/true » avec la TTL courte.
Clés API : stocker le hachage de la clé (comme les mots de passe), les étiquettes de propriétaire/tenant, scope, date de création/dernier accès ; rappel - instantanément.

11) Clés de données : encodage

Le CMK/KEK (KMS/HSM) protège le DEK ; la rotation du CMK se fait sans recadrer les données : le stylo-wrap DEK.
DEK pour chaque objet/tenant/lot ; KDF/HKDF pour les clés dérivées.
Stratégies de destruction (crypto-shredding) : supprimer KEK = illisibilité des données en cas de compromission.

12) Procédures d'incident (compromission)

1. Geler : désactiver l'émission de tokens sur la clé compromise, transférer l'émission à une nouvelle.
2. Révocation : supprimer 'kid' de JWKS, révoquer les certificats (OCSP/CRL), bloquer les clés API par liste.
3. Raccourcir la TTL : réduire temporairement les tokens « bou », renforcer la vérification PoP/DPoP.
4. Logout forcé : invalider les séances (revoke 'sid '/' jti').
5. Forensica et reporting : temps, couverture, qui/ce qui a été touché ; mettre à jour les playbooks.

13) Pipline et rollout

13. 1 Génération et publication

Générer des clés dans le HSM/KMS ; l'exportation d'une clé privée est interdite.
Publication automatique des certificats JWKS/avec vérification et tests.
Sortie Canaries : 1-5 % des clients → 100 %.

13. 2 Contrôles de santé

Métriques : proportion de validation par 'kid', erreurs de signature/certificat, dérive de l'horloge.
Alert : sursaut 401/403 en raison de la signature, OCSP/CRL non disponible, certificats expirés (T-30/T-7/T-1).

14) Configis et exemples

14. 1 Exemple de stratégie Vault/KMS (pseudo)

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

14. 2 Exemple de plan de rotation JWT

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 : mise à jour forcée de JWKS (pseudo)

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) Observation et 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).
Dashboards : carte des parts 'kid', certificats expirés, taux de révocation, signatures non valides par région.

16) Anti-modèles

JWT à longue durée de vie sans rappel et sans court « bou ».
Absence de 'kid' et sélection « manuelle » de la clé de vérification.
Stockez des secrets dans un ENV/k8s-Secret sans KMS et sans chiffrement au niveau etcd.
Jetons de refresh non rotatifs ; réutilisation refresh sans détail.
Une clé API globale unique « sur tous ».
Sortie « silencieuse » de nouvelles clés sans publication et surveillance JWKS.
Fenêtres de recouvrement zéro (remplacement instantané) → en masse 401/403.

17) Spécificités d'iGaming/Finance

Régulateurs et vérificateurs : logiques de rotation/rétroaction immuables ; la probabilité du temps et des acteurs.
Partenaires PSP/KYC : clés séparées par partenaire/juridiction ; rappel rapide en cas de violations de la SLA/sécurité.
Multifonctionnalité : clés API per-tenant avec scope ; isolation des clés de marque/régions.
Risque élevé : PoP/DPoP pour les opérations critiques, court « bou », mTLS entre les services internes.
Backoffice : SSO/OIDC, sessions courtes, jetons matériels (FIDO2), rotate-on-schedule omniprésent.

18) Chèque-liste prod-prêt

• Toutes les clés privées dans KMS/HSM/Vault ; l'exportation est interdite.
• JWKS est publié et mis en cache avec un court TTL ; dans les titres de JWT, il y a « kid ».
• Plan de rotation avec fenêtre se chevauchant et rollout automatique.
• Les jetons Refresh sont jetables ; liste des « jti » retirés avec TTL.
• Secrets HMAC : actif + canarien ; la réception par les deux ; Le temps de commutation T a été annoncé.
• TLS/mTLS : auto-renew, alertes T-30/T-7/T-1, trust bundle pour le changement de CA.
• Encryptage Envelope : KEK/CMK rotatif sans interruption, DEK par objet/tenant.
• Métriques/alertes par signature, JWKS, commentaires ; Dashboard 'kid' -doloi.
• Pleybuk d'incidents (compromission) et exercices réguliers.
• Tests de canary et de reverse de validation avec de nouvelles clés/SA.

19) TL; DR

Gardez les clés dans KMS/HSM, signez JWT avec 'kid' et publiez JWKS. Tournez les clés et les certificats avec le chevauchement, surveillez les parts de validation de 'kid'. Refresh - rotate-on-use et court « bou » ; pour les opérations critiques - PoP/DPoP et mTLS. Pour les données, utilisez le cryptage envelope avec rotation KEK sans interruption de service. Mettez en place des métriques/alertes, des pleybooks d'incident et des rotations canariennes régulières.