🔐 Storage Systems — Chapitre 32 : Chiffrement

Première page de la Partie 10 — Sécurité du stockage. Ce chapitre couvre le chiffrement au repos, en transit, côté client, KMS, gestion des clés, HSM, SED, TDE, object storage, NAS, VM, Kubernetes, backups, multi-cloud, envelope encryption, rotation, IAM/RBAC, audit, performance, crypto-shredding, erreurs classiques, conformité, runbooks et checklist production.

Chiffrement au reposChiffrement en transitClient-side encryptionKMSGestion des clésHSM

32.1

Chiffrement au repos

Disk encryption, volume encryption, array encryption, database TDE, object encryption et self-encrypting drives.

At restDiskVolume

32.2

Chiffrement en transit

TLS, IPsec, SMB encryption, NFS/TLS, iSCSI/IPsec, NVMe/TCP/TLS, VPN et private links.

TLSIPsecSMB

32.3

Chiffrement côté client

Client-side encryption : les données sont chiffrées avant de quitter l’application, le poste ou le serveur.

Client-sideZero trustApp keys

32.4

KMS

AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault, KMIP, HSM et gestion centralisée des clés.

KMSVaultKMIP

32.5

Gestion des clés

Rotation, séparation des rôles, HSM, escrow, dual control, séparation tenant/admin et lifecycle des secrets.

RotationHSMRoles

32.6

HSM et racines de confiance

Hardware Security Module, FIPS, clés non exportables, signature, root of trust et conformité forte.

HSMFIPSTrust

32.7

Self-Encrypting Drives

SED, TCG Opal, FIPS drives, instant secure erase, gestion firmware et limites face aux attaques OS.

SEDTCG OpalFIPS

32.8

Database TDE

Transparent Data Encryption pour Oracle, SQL Server, PostgreSQL extensions, MySQL/MariaDB et clés master.

TDEDatabaseMaster key

32.9

Chiffrement object storage

SSE-S3, SSE-KMS, SSE-C, Object Lock, bucket policies, client-side encryption et enveloppe cryptographique.

S3SSE-KMSObject

32.10

Chiffrement file/NAS

SMB encryption, NFS avec Kerberos/TLS, EFS-like, ZFS encryption, permissions et risques ransomwares.

NASSMBNFS

32.11

Chiffrement VM et hyperviseurs

VM encryption, vTPM, BitLocker, LUKS, vSAN encryption, KVM, Hyper-V Shielded VMs et snapshots.

VMvTPMBitLocker

32.12

Chiffrement Kubernetes

Secrets encryption at rest, KMS providers, CSI encryption, sealed-secrets, external secrets et etcd.

K8sSecretsetcd

32.13

Chiffrement backups et archives

Backups chiffrés, immutables, clés séparées, recovery keys, restore tests et risque de clé perdue.

BackupArchiveRecovery

32.14

Chiffrement multi-cloud

BYOK, HYOK, external key manager, cloud KMS, sovereign key control, cross-cloud restore et audits.

BYOKHYOKMulti-cloud

32.15

Envelope encryption

Data Encryption Key, Key Encryption Key, wrapping, rotation efficace et séparation des données et clés.

DEKKEKEnvelope

32.16

Rotation et révocation

Rotation de clés, rewrapping, revoke, disable, destroy, key versioning et impact sur données historiques.

RotationRevokeVersions

32.17

IAM, RBAC et séparation des rôles

Le chiffrement ne sert à rien si les droits sont trop larges : least privilege, MFA, break-glass et audit.

IAMRBACMFA

32.18

Audit cryptographique

Logs KMS, accès clés, decrypt events, key usage, anomalies, SIEM, preuves conformité et alertes.

AuditSIEMKey usage

32.19

Performance et accélération

AES-NI, CPU offload, TLS acceleration, QAT, impact latence, overhead DB et coûts cloud KMS.

AES-NIQATLatency

32.20

Crypto-shredding

Destruction logique par suppression de clés : rapide, mais exige preuves, gouvernance et compréhension des copies.

Destroy keyEraseEvidence

32.21

Menaces et erreurs classiques

Clé dans le même backup, secrets dans Git, KMS admin trop large, snapshots non chiffrés, logs exposés.

ThreatsSecretsMistakes

32.22

Conformité et standards

FIPS 140-3, ISO 27001, SOC 2, PCI DSS, HIPAA/HDS, RGPD, NIS2/DORA selon secteur.

FIPSPCIRGPD

32.23

Runbooks chiffrement

Créer, tourner, suspendre, restaurer, auditer, révoquer une clé et tester une restauration chiffrée.

RunbookKey opsRestore

32.24

Checklist production chiffrement

GO/NO-GO : données classifiées, clés séparées, rotation testée, logs KMS, backups restaurables, break-glass.

ChecklistProd-readyGO/NO-GO

32.1 Chiffrement au repos

Définition opérationnelle

Disk encryption, volume encryption, array encryption, database TDE, object encryption et self-encrypting drives.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.2 Chiffrement en transit

Définition opérationnelle

TLS, IPsec, SMB encryption, NFS/TLS, iSCSI/IPsec, NVMe/TCP/TLS, VPN et private links.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.3 Chiffrement côté client

Définition opérationnelle

Client-side encryption : les données sont chiffrées avant de quitter l’application, le poste ou le serveur.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.4 KMS

Définition opérationnelle

AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault, KMIP, HSM et gestion centralisée des clés.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.5 Gestion des clés

Définition opérationnelle

Rotation, séparation des rôles, HSM, escrow, dual control, séparation tenant/admin et lifecycle des secrets.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.6 HSM et racines de confiance

Définition opérationnelle

Hardware Security Module, FIPS, clés non exportables, signature, root of trust et conformité forte.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.7 Self-Encrypting Drives

Définition opérationnelle

SED, TCG Opal, FIPS drives, instant secure erase, gestion firmware et limites face aux attaques OS.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.8 Database TDE

Définition opérationnelle

Transparent Data Encryption pour Oracle, SQL Server, PostgreSQL extensions, MySQL/MariaDB et clés master.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.9 Chiffrement object storage

Définition opérationnelle

SSE-S3, SSE-KMS, SSE-C, Object Lock, bucket policies, client-side encryption et enveloppe cryptographique.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.10 Chiffrement file/NAS

Définition opérationnelle

SMB encryption, NFS avec Kerberos/TLS, EFS-like, ZFS encryption, permissions et risques ransomwares.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.11 Chiffrement VM et hyperviseurs

Définition opérationnelle

VM encryption, vTPM, BitLocker, LUKS, vSAN encryption, KVM, Hyper-V Shielded VMs et snapshots.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.12 Chiffrement Kubernetes

Définition opérationnelle

Secrets encryption at rest, KMS providers, CSI encryption, sealed-secrets, external secrets et etcd.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.13 Chiffrement backups et archives

Définition opérationnelle

Backups chiffrés, immutables, clés séparées, recovery keys, restore tests et risque de clé perdue.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.14 Chiffrement multi-cloud

Définition opérationnelle

BYOK, HYOK, external key manager, cloud KMS, sovereign key control, cross-cloud restore et audits.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.15 Envelope encryption

Définition opérationnelle

Data Encryption Key, Key Encryption Key, wrapping, rotation efficace et séparation des données et clés.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.16 Rotation et révocation

Définition opérationnelle

Rotation de clés, rewrapping, revoke, disable, destroy, key versioning et impact sur données historiques.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.17 IAM, RBAC et séparation des rôles

Définition opérationnelle

Le chiffrement ne sert à rien si les droits sont trop larges : least privilege, MFA, break-glass et audit.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.18 Audit cryptographique

Définition opérationnelle

Logs KMS, accès clés, decrypt events, key usage, anomalies, SIEM, preuves conformité et alertes.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.19 Performance et accélération

Définition opérationnelle

AES-NI, CPU offload, TLS acceleration, QAT, impact latence, overhead DB et coûts cloud KMS.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.20 Crypto-shredding

Définition opérationnelle

Destruction logique par suppression de clés : rapide, mais exige preuves, gouvernance et compréhension des copies.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.21 Menaces et erreurs classiques

Définition opérationnelle

Clé dans le même backup, secrets dans Git, KMS admin trop large, snapshots non chiffrés, logs exposés.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.22 Conformité et standards

Définition opérationnelle

FIPS 140-3, ISO 27001, SOC 2, PCI DSS, HIPAA/HDS, RGPD, NIS2/DORA selon secteur.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.23 Runbooks chiffrement

Définition opérationnelle

Créer, tourner, suspendre, restaurer, auditer, révoquer une clé et tester une restauration chiffrée.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.

32.24 Checklist production chiffrement

Définition opérationnelle

GO/NO-GO : données classifiées, clés séparées, rotation testée, logs KMS, backups restaurables, break-glass.

Point clé : le chiffrement protège surtout contre la lecture non autorisée. Il ne remplace jamais IAM, sauvegarde, immutabilité, monitoring, patching et gouvernance des accès.

Chaîne cryptographique

Plain data→DEK→Ciphertext→KEK / KMS→Audit + policy

AlgoAES

Standard symétrique.

TransitTLS

Chiffrement réseau.

KeysKMS

Gestion centralisée.

RiskLoss

Clé perdue = données perdues.

Composants

Composant	Rôle / explication
Données	Volumes, fichiers, objets, bases, snapshots, backups, logs, métadonnées et archives.
Algorithme	AES-256-GCM/XTS, TLS 1.2/1.3, RSA/ECC pour échange ou signature selon contexte.
DEK	Data Encryption Key : clé qui chiffre réellement les données.
KEK / master key	Key Encryption Key : clé qui protège les DEK, souvent stockée dans KMS/HSM.
KMS / HSM	Service de gestion, rotation, audit, disable, destroy, policies et accès aux clés.
Audit trail	Preuves d’accès aux clés, opérations de decrypt, rotation, erreurs et actions administratives.

Cas d’usage

Protection contre perte ou vol de support
Conformité réglementaire et audit
Cloud storage avec contrôle des clés
Backups et archives hors site
Multi-tenant, SaaS, données sensibles
Réduction impact fuite disque, snapshot ou bucket

Classification→Key policy→Encrypt→Monitor→Rotate→Restore test

Avantages

Réduit exposition en cas de fuite physique/logique
Permet contrôle d’accès par clé et policy
Facilite conformité si bien documenté
Supporte crypto-shredding et révocation
Renforce séparation des rôles et auditabilité

Risques / limites

Clé perdue = données perdues
Clé stockée avec données = protection faible
KMS indisponible = service indisponible
Rotation mal testée = panne
Droits admin trop larges contournent le chiffrement

Matrice de décision chiffrement

Question	Décision à prendre
Quelles données ?	Classer par sensibilité : public, interne, confidentiel, secret, santé, finance, client.
Où chiffrer ?	Disque, volume, filesystem, base, application, object storage, backup, archive ou client-side.
Qui détient la clé ?	Provider-managed, customer-managed, BYOK, HYOK, HSM ou application-owned.
Comment restaurer ?	Tester backup/restauration avec clés, KMS, permissions, rotation et scénario KMS indisponible.
Comment auditer ?	Logs KMS, accès decrypt, usages anormaux, suppression, rotation, disable/destroy.
Comment sortir ?	Export des données, export/rewrap des clés, format portable, documentation et réversibilité.

Règle pratique : les données chiffrées valent exactement ce que vaut la gouvernance de leurs clés.

Runbook chiffrement de référence

Classifier les données et définir propriétaire, durée de vie, niveau de risque et exigences réglementaires.
Créer une clé dédiée par environnement, application ou domaine de données selon criticité.
Définir IAM/RBAC : usage de clé séparé de l’administration stockage.
Activer logs, alertes, MFA, break-glass et procédures dual control.
Chiffrer les volumes, buckets, bases, backups et archives concernés.
Tester rotation, disable, restore, perte de permission et reprise après incident.
Documenter version de clé, owner, rotation, escrow et destruction éventuelle.

# Examples: Linux storage encryption and checks
cryptsetup luksFormat /dev/sdb
cryptsetup open /dev/sdb secure_data
mkfs.xfs /dev/mapper/secure_data
openssl s_client -connect storage.example.com:443 -tls1_3
aws kms list-keys
aws kms describe-key --key-id alias/prod-storage
aws s3api get-bucket-encryption --bucket my-secure-bucket

NO-GO : clés dans le même backup que les données, aucun test de restauration, absence de logs KMS, admins trop larges, ou rotation jamais testée.