Gère clés, certificats, TLS et limites de la confiance

01Distingue les fonctions

Chiffrement symétrique
→ même secret pour chiffrer et déchiffrer

Cryptographie asymétrique
→ paire clé publique / clé privée

Hachage
→ empreinte non réversible pour intégrité ou dérivation

Signature numérique
→ intégrité, origine et preuve liée à une clé privée

Aucun mécanisme ne remplit automatiquement toutes les fonctions.

02Comprends le certificat

Un certificat lie notamment :

une identité ou un nom
une clé publique
une période de validité
un usage autorisé
une signature d'autorité

Le client doit valider la chaîne jusqu’à une trust anchor qu’il accepte.

03Valide le bon pair

Certificat signé
+ chaîne valide
+ période valide
+ usage correct
+ nom demandé présent
= identité TLS vérifiée selon la politique du client

Désactiver la vérification du hostname permet une interception même si la connexion reste chiffrée.

04Gère le cycle de vie

Génération
→ source d'aléa et algorithme approuvés

Stockage
→ coffre, HSM ou secret manager adapté

Distribution
→ canal et identité contrôlés

Usage
→ périmètre et durée minimaux

Rotation
→ renouvellement planifié ou après compromission

Révocation
→ rendre une clé ou un certificat inutilisable

Archivage/destruction
→ selon besoin et politique

La clé ne doit pas partager le même domaine de défaillance que les données qu’elle protège.

05Observe la revue crypto

lab=/tmp/soria-cyber-data-network-cloud-$USER
bash module4-cyber-data-network-cloud.sh setup "$lab"
bash module4-cyber-data-network-cloud.sh run "$lab"
column -s, -t "$lab/output/crypto-review.csv"

Résultats clés :

CRYPTO-103 → BLOCK_LEGACY_TLS
CRYPTO-104 → BLOCK_KEY_COLOCATION

Le portail legacy combine TLS 1.0 et validation du nom désactivée. Le dépôt de sauvegarde conserve sa clé sur le même serveur.

06Sépare chiffrement et confiance

Chiffrement sans identité du pair
→ canal potentiellement intercepté

Certificat valide pour un autre nom
→ mauvais pair

Clé correctement stockée sans rotation
→ dette de cycle de vie

TLS correct vers une application vulnérable
→ données protégées en transit mais application toujours exposée

07Prépare expiration et compromission

Inventaire des certificats et clés
Propriétaire
Date d'expiration
Dépendances
Renouvellement automatisé
Alerte avant expiration
Procédure de révocation
Remplacement et rollback
Preuve après rotation

08Surveille les évolutions

Les recommandations cryptographiques évoluent. NIST a engagé en 2026 une revue de SP 800-52 Rev. 2 et prépare de nouvelles révisions de ses guides de gestion des clés. Une organisation doit suivre les publications finales et planifier les migrations sans adopter aveuglément un draft.