Cryptage et protection des API : TLS, HSTS, PFS, rotation des secrets

1) Tableau des menaces et des objectifs

L'API est attaquée par MitM, l'interception du trafic, les attaques downgrade, la falsification de tokens, les fuites de clés et l'abus de secrets à longue durée de vie. Objectifs de la protection :

Confidentialité et intégrité (TLS 1. 3 + codes forts).
Protection contre le dérapage/strip (HSTS, versions/codes interdits).
Minimisation des dommages en cas de compromission (PFS, TTL courts, rotation rapide).
Authentification fiable du client/service (mTLS/tokens) et traçabilité.

2) TLS comme base (serveur et service-k-service)

Versions et codes :

Par défaut, TLS 1. 3; autoriser TLS 1. 2 seulement pour la compatibilité. Désactiver 1. 1/1. 0.

Chiffrements prioritaires TLS 1. 3:

`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
Pour TLS 1. 2 : ECDHE uniquement avec signature AES-GCM/ChaCha20 et ECDSA/RSA (par exemple 'ECDHE-ECDSA-AES128-GCM-SHA256').

Clés et certificats :

Clés serveur : ECDSA P-256/P-384 (plus rapide et plus court) ou RSA 2048 +/3072.
Clés client pour mTLS : ECDSA P-256 ; émission par l'intermédiaire de son propre CA ou d'un HSM/KMS payant.
Activer le stapling OCSP, de préférence avec le drapeau Must-Staple, et l'ALPN (HTTP/2/3).

PFS (Perfect Forward Secrecy):

Fourni par des échanges éphémères (ECDHE) - même si la clé de serveur des canards, les sessions passées ne sont pas décodées.
Désactivez de force les accords de clé DH/RSA statiques.

Ajouts modernes :

ECH (Encrypted Client Hello), si soutenu par Front/CDN, cache SNI.
HTTP/2/3 uniquement avec des codes forts ; interdiction de HTTP non protégé, redirect sur HTTPS.

3) HSTS vs TLS-stripping

Activer HTTP Strict Transport Security sur le domaine racine et les sous-domaines :


Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Placez le domaine dans la liste HSTS preload.

Assurez-vous que vous êtes correct avant la publication (le retour est difficile).

4) Authentification mutuelle : mTLS et/ou tokens

mTLS entre microservices/API internes : certificats bilatéraux, rotation automatique via service mesh (Istio/Linkerd) ou PKI natif.

Clients API (intégration mobile/partenaire) : tokens (OAuth2/OIDC, JWT), option mTLS pour les risques élevés.

Pour les fronts publics : TLS + jetons OAuth2/OIDC à courte durée de vie avec ancrage/DPoP.

5) Gestion des certificats et du cycle de vie

L'automatisation ACME (par exemple, Let's Encrypt/CA organisationnel) avec mise à jour automatique 30 jours avant l'expiration.

Courte durée de vie des certificats (≤ 90 jours) + suivi des délais, alertes et paquets de déplay canarien.

ICP centralisée : AC racine/intermédiaire, CRL/OCSP, vérification des rejets et des rappels.

Exemple nginx (fragment) :

nginx ssl_protocols TLSv1. 3 TLSv1. 2;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

6) Rotation des secrets : principes et schémas

Objectifs de rotation : limiter le « rayon explosif » des fuites, réduire le temps d'abus, fournir des rejets sans heurts.

Règles de base :

Stockez des secrets uniquement dans le gestionnaire de secrets (KMS/Vault/Cloud SM). Pas de secrets dans Git/images.
TTL court et rotation automatique : clés de signature, mots de passe OBD, clés API des fournisseurs.
Double publication (dual-key window) : les anciennes et les nouvelles clés sont actives simultanément pendant la période de reconfiguration.
Versioning + kid (pour JWT/JWKS), fenêtre « grace » pour valider les anciens tokens.

Que rouler régulièrement :

Clés JWT (signature/cryptage), secrets HMAC de webhooks et callback, Mots de passe/comptes OBD, crédits de cache (Redis), tokens CI/CD, Secrets des fournisseurs (KYC/AML, foulards, SMS/e-mail), clés SSH automatiques.

Déclencheurs de rotation non planifiée : soupçon de fuite, licenciement des employés ayant accès, changement de fournisseur, exigences du régulateur.

7) JWT/JWKS : overle de rôle sécurisé

Publiez JWKS endpoint avec la clé actuelle et future ('kid' obligatoire).

Procédure de rotation :

1. Générer une nouvelle clé → ajouter à JWKS en tant que « deuxième ».

2. Mettre à jour les signataires → lancer de nouveaux tokens avec une nouvelle clé.

3. Attendez la TTL des anciens tokens → supprimez l'ancienne clé de JWKS.

Réglez les jetons TTL courts (par exemple, 5-15 minutes) + flux refresh avec une vérification supplémentaire.

8) Gestion des secrets dans la pratique

Encryption KMS + envelope : clé principale dans HSM/KMS, les données sont cryptées par DEK « enroulé ».

Vault/Cloud Secret Manager : crédits dynamiques à la base de données (émission de scientifiques avec TTL), rotation périodique.

Kubernetes: External Secrets/Secrets Store CSI; chiffrement etcd ; RBAC; l'interdiction de l'enregistrement des secrets.

Accès par rôle : IAM/ABAC, principe des plus petits privilèges, frontières matérielles (HSM, TPM).

Audit complet : qui, quoi, quand, pourquoi lu/modifié.

9) Protection de transport à l'intérieur du périmètre

Ne faites pas confiance au « réseau interne » : partout TLS/mTLS (zero-trust).

Service mesh automatise les certificats, le redémarrage et la rotation, l'observabilité (mTLS par défaut).

Minimisez les terminaisons TLS : soit uniquement sur edge + crypté east-west, soit cryptage de bout en bout.

10) Stratégies de sécurité API sur TLS

Limite de taux/protection DoS, vérification de la signature des webhooks (HMAC avec rotation des secrets).

Content-Security-Policy/Referrer-Policy/X-Content-Type-Options для фронта.

mTLS pour les endpoint's critiques (paiements, administration), IP allow-list par partenaire.

Replay-protection : timestamp + nonce dans les requêtes signées, fenêtres pas plus de 5 minutes.

11) Suivi et tests

Observabilité TLS : versions/codes dans les métriques, alertes sur les tentatives de downgrade, augmentation des échecs de poignée de main.

Scanners (en CI/CD et régulièrement en vente) : vérification des codes pris en charge, certificats, HSTS, OCSP.

L'exercice Chaos/DR : l'expiration du certificat, la chute du gestionnaire secret, la compromission de la clé de signature - vérifiez les plans de réaction.

12) Procédures de réponse

Compromission de la clé : révocation immédiate du certificat/suppression de la clé du JWKS, inversion de secours, régénération forcée des tokens.

Expiration sans renouvellement : dégradation temporaire (trafic interne uniquement), réinstallation automatique des certificats.

Rapport d'incident : Temporisation, sujets touchés, technique. détails, mesures correctives.

13) Chèque de vérification rapide (prod-ready)

Seulement TLS 1. 3 (+ 1. 2 pour legasi), liste rigoureuse des codes.
HSTS с `preload`, OCSP stapling, ALPN.
ECDHE pour PFS ; ECDSA P-256/384 ou RSA 3072.
mTLS à l'intérieur du cluster/entre les services critiques.
JWKS + kid, tokens TTL courts, plan de rotation.
Secrets - seulement dans KMS/Vault, auto-rotation DB/fournisseurs.
Auto-renouvellement des certificats (ACME), alertes en 30 jours.
Vérification CI/CD des titres de sécurité et des codes vulnérables.
Runbook documenté "et : rotation, rappel, incidents.

Résumé

Une protection API fiable est une combinaison de TLS 1. 3 + HSTS + PFS comme un minimum obligatoire et des processus matures de gestion des clés et des secrets. Ajoutez mTLS entre les services, automatisez la sortie/rotation via KMS/Vault/mesh, gardez des TTL courts et des « fenêtres doubles » lorsque vous changez de clé - et vous réduirez au minimum les risques d'interception, de downgrade et d'abus de secrets perdus sans briser la disponibilité et la vitesse du produit.