Gestion des clés et rotation

Les clés sont les « racines de la confiance » de la plate-forme. Un système de gestion des clés robuste (KMS/HSM + processus + télémétrie) transforme la cryptographie d'une intégration ponctuelle à une opération quotidienne : les clés sont régulièrement mises à jour, leur utilisation est transparente, les compromissions sont localisées et les clients vivent un changement de clé sans downtime.

1) Objectifs et principes

Crypto agility : possibilité de changer l'algorithme/la longueur de la clé sans grandes migrations.
Least exposure : les clés privées ne quittent pas KMS/HSM ; les opérations de signature/décryptage sont supprimées.
Short-lived artifacts : jetons/clés de session vivent minutes-heures, pas semaines.
Fenêtres Dual-key/Dual-cert : rotations libres.
Isolation régionale et tenante : les clés sont réparties par région et par locataire.
Full auditability : journal des opérations immuable, certification HSM, contrôle d'accès.

2) Classification des clés

Racine (Root CA/Master Key) : utilisation extrêmement rare, maintenue dans le HSM, utilisée pour libérer des clés intermédiaires ou des emballages de clé de données.
Opérations : signature JWT/événements, TLS, signature webhooks, cryptage des configues/PII.
Session/temporaire : DPoP, mTLS-binding, sortie ECDH pour canal/dialogue.
Intégration : clés des partenaires (publiques) et secrets de l'AMCC.
Data Keys (DEK) : utilisent le cryptage envelope sous KEK, ne sont pas stockés explicitement.

3) Identification des clés et politique d'utilisation

yaml key:
kid: "eu-core-es256-2025-10"
alg: "ES256"         # или EdDSA, RSA-PSS, AES-GCM, XChaCha20-Poly1305 purpose: ["jwt-sign","webhook-sign"]
scope: ["tenant:brand_eu","region:EE"]
status: "active"       # active      next      retiring      revoked created_at: "2025-10-15T08:00:00Z"
valid_to:  "2026-01-15T08:00:00Z"

Règles : « un objectif est une clé » (minimum de boule), domaines d'application explicites et délais.

4) Le cycle de vie de la clé (KMS/HSM)

1. Generate : dans HSM/KMS, avec la politique d'exportation = interdite.
2. Publish : pour l'asymétrie - JWKS/certificat avec 'kid'.
3. Use : Opérations distantes (δ/decrypt) avec IAM contrôlé.
4. Rotate : exécutez 'next'la clé et activez le dual-accept.
5. Retire : traduisez l'ancien par « retiring », puis « revoked ».
6. Destroy : détruire le matériel (avec le protocole purge) après la fenêtre de controverse.

5) Rotation : Stratégies

Planifié : calendrier (par exemple, tous les 1-3 mois pour la signature JWT, 6-12 mois pour les serts TLS).
Rolling : changement progressif des consommateurs (JWKS contient déjà une nouvelle clé ; l'émetteur commence à signer de nouvelles cases après avoir chauffé).
Forced (security) : rotation immédiate en cas de compromission ; courte fenêtre dual-accept, expiration agressive des artefacts.
Staggered per region/tenant : pour ne pas « claquer » le monde entier en même temps.

La règle d'or : d'abord la publication, puis la signature est nouvelle, et seulement après l'expiration - la révocation de l'ancien.

6) Double-clé fenêtre (changement irréprochable)

Nous publions JWKS avec l'ancien et le nouveau 'kid'.
Les vérificateurs acceptent les deux.
L'émetteur commence à signer nouveau après N minutes/heures.
Nous surveillons la part des contrôles de l'ancien/nouveau 'kid'.
Quand la part cible est atteinte, le retairim est vieux.

yaml jwks:
keys:
- kid: "eu-core-es256-2025-10" # new alg: "ES256"
use: "sig"
crv: "P-256"
x: "<...>"; y: "<...>"
- kid: "eu-core-es256-2025-07" # old alg: "ES256"
use: "sig"
...

7) Politiques de signature et de validation

Algorithmes par défaut : ES256/EdDSA pour la signature ; RSA-PSS lorsque nécessaire.
Interdiction des algorithmes « none »/faibles ; whitelisting du côté de la vérification.
Clock skew : nous admettons ± 300 c, nous enregistrons les écarts.
Key pinning (services internes) et court TTL JWKS-cache (30-60 s).

8) Encryptage Envelope et KDF

ciphertext = AEAD_Encrypt(DEK, plaintext, AAD=tenant    region    table    row_id)
DEK = KMS. Decrypt (KEK, EncryptedDEK )//on access
EncryptedDEK = KMS. Encrypt (KEK, DEK )//on write

Le KEK (Key Encryption Key) est stocké dans le KMS/HSM, en rotation régulière.
Le DEK est créé par objet/lot ; lors de la rotation KEK, nous exécutons re-wrap (rapidement, sans re-cryptage des données).
Pour les flux - ECDH + HKDF pour la sortie des clés de canal à courte durée de vie.

9) La régionalité et le multi-tenant

Les clés et JWKS sont surrégionales : 'eu-core', 'latam-core' sont des jeux de clés différents.
La division IAM/audit par tenant/région ; les clés ne « coulent » pas entre les résidents.
'kid' encodez avec le préfixe de domaine de confiance : 'eu-core-es256-2025-10'.

10) Secrets d'intégration (HMAC, clés API)

Stocker dans le KMS-backed Secret Store, en envoyant via short-lived client secrets (politique de rotation ≤ 90 jours).
Prise en charge de deux secrets actifs (dual-secret) lors de la rotation.
Pour les webhooks - timestamp + HMAC signature du corps ; fenêtre temporelle ≤ 5 min.

11) Contrôle d'accès et processus

Matrice IAM : qui peut « generate », « sing », « decrypt », « rotate », « destroy » (minimum de rôles).
Principe 4 yeux : les opérations sensibles nécessitent deux confirmations.
Change Windows : fenêtres d'activation de la nouvelle clé et régions canaries de test.
Runbooks : modèles de procédures pour les rotations schedulées et forcées.

12) Observation et audit

• `sign_p95_ms`, `decrypt_p95_ms`, `jwks_skew_ms`,
• consommation par 'kid', 'old _ kid _ usage _ ratio',
• `invalid_signature_rate`, `decrypt_failure_rate`.

• Chaque opération de signature/décryptage : 'who/what/when/where/kid/purpose'.
• Historique des états des clés et des demandes de rotation/revo.
• Certification HSM, journaux d'accès aux matériaux clés.

13) Pleybooks (incidents)

1. Compromis de la clé de signature

Revoke immédiat de l'ancien « kid » (ou traduction en « retiring » avec une fenêtre minimale), publication du nouveau JWKS, raccourcis TTL tokens, force-logout/handicap RT, communications aux integrations, audit rétro.

2. Masse 'INVALID _ SIGNATURE' après rotation

Vérifiez le cache JWKS/clock skew, retournez le double-accept, étendez la fenêtre, envoyez aux clients.

3. Augmentation de la latence KMS/HSM

Le cache de signature local n'est pas activé ; au lieu de cela - batch/queue chez l'émetteur, autoscaling HSM proxy, priorité des flux critiques.

4. Refus d'une région

Activer les procédures d'isolement régional ; ne pas « tirer » les clés d'autres régions ; dégrader les fonctions attachées à la signature dans une région déchue.

14) Tests

Contrat : correct JWKS, correct 'kid '/alg/use, compatibilité client.
Negative : fausse signature, obsolète 'kid', faux alg, clock skew.
Chaos : rotation instantanée, indisponibilité KMS, « dérive » du temps.
Load : pic de signatures (JWT/webhooks), pic de décryptages (PII/paiements).
E2E : double-clé fenêtre : sortie - vérification - transfert du trafic - rejet de l'ancien.

15) Exemple de configuration (YAML)

yaml crypto:
regions:
- id: "eu-core"
jwks_url: "https://sts. eu/.well-known/jwks. json"
rotation:
jwt_sign: { interval_days: 30, window_dual: "48h" }
webhook: { interval_days: 60, window_dual: "72h" }
kek:   { interval_days: 90, action: "rewrap" }
alg_policy:
sign: ["ES256","EdDSA"]
tls: ["TLS1. 2+","ECDSA_P256"]
publish:
jwks_cache_ttl: "60s"
audit:
hsm_attestation_required: true two_person_rule: true

16) Exemple de JWKS et de marqueurs dans les artefacts

json
{ "alg":"ES256", "kid":"eu-core-es256-2025-10", "typ":"JWT" }

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

17) Anti-modèles

Clés de longue durée « pour les années » et communes à toutes les régions.
Rotation « à un moment » sans double acceptation.
Exporte les clés privées de KMS/HSM « pour la rapidité ».
Mixer les tâches : une clé pour signer le JWT et chiffrer les données.
Absence de logs/certifications HSM et IAM restrictions.
Il n'y a pas de mécanisme re-wrap pour DEK lors de la rotation KEK.
Des « secrets » à la main dans le bou au lieu du Secret Store.

18) Chèque-liste avant la vente

• Toutes les clés privées dans KMS/HSM ; La matrice IAM et le principe 4 yeux sont personnalisés.
• Les politiques sur les algorithmes, la longueur des clés et la durée de vie sont approuvées.
• Un processus dual-key avec surveillance des parts de 'kid' est inclus.
• JWKS est publié avec un court TTL et un chauffage des cachets ; les clients acceptent la clé ≥2.
• Encryptage Envelope : KEK en rotation, DEK re-wrap sans interruption de service.
• Isolement régional et jeux de clés séparés par tenants.
• Pleybooks de compromission/roulage/rotation de force ; les courses d'entraînement.
• Les métriques ('old _ kid _ usage _ ratio', 'invalid _ signature _ rate') et les alertes sont incluses.
• Jeu de tests contract/negative/chaos/load/E2E réussi.
• Documentation pour les intégrations : comment gérer le changement 'kid', quelles fenêtres et codes d'erreur.

Conclusion

La gestion des clés est une discipline opérationnelle : KMS/HSM comme source de vérité, rotations régulières et sécurisées avec double clé, isolation régionale et tenante, encryptage et observabilité. En suivant ces règles, vous obtenez un circuit cryptographique qui s'adapte, résiste aux incidents et explique facilement à l'auditeur - et les développeurs et les intégrateurs vivent tous les changements sans douleur.