Chiffrement au repos : les 4 couches techniques 2025

Le chiffrement au repos (encryption at rest, data-at-rest encryption) protège les données stockées sur disque, SSD, stockage cloud, ou backup contre un accès non-autorisé au medium physique. Il se décline en 4 couches techniques de granularité croissante : couche 1 disque entier (Full Disk Encryption : LUKS Linux, BitLocker Windows, FileVault macOS, AWS EBS encryption), couche 2 filesystem (fscrypt Linux, EFS Windows, eCryptfs), couche 3 base de données (Transparent Data Encryption : SQL Server TDE, Oracle TDE, MongoDB Queryable Encryption), couche 4 application (chiffrement de champs ou d'objets via envelope encryption + KMS). Les algorithmes varient selon la couche : AES-XTS (NIST SP 800-38E, 2010) pour le stockage bloc par bloc qui ne peut tolérer d'expansion ni de métadonnées additionnelles ; AES-GCM (NIST SP 800-38D, 2007) pour le chiffrement applicatif qui apporte authentification AEAD. Les KMS cloud (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault Transit) gèrent les KEK (Key Encryption Keys) via pattern envelope encryption, avec rotation automatique 90-365 jours. Les modèles de contrôle varient : CMK (Customer Managed Key, standard), BYOK (Bring Your Own Key, clé importée depuis HSM on-prem), HYOK / XKS (Hold Your Own Key, clé jamais copiée hors HSM on-prem). Les exigences réglementaires convergent en 2025 : RGPD art 32 (mesures appropriées), PCI-DSS v4.0 requirement 3.5 (PAN), ANSSI RGS v2.0 (données sensibles), DORA (finance UE, jan 2025), NIS 2 (services essentiels, oct 2024). Mais le chiffrement au repos a des limites strictes : il ne protège pas contre un attaquant avec accès runtime, contre les SQL injections, contre la compromission d'identité applicative. C'est un contrôle de défense en profondeur, jamais autoportant. Cet article détaille les 4 couches, les algorithmes par contexte, les implémentations cloud (EBS, S3, RDS, Azure Disk, GCP CMEK), les modèles KMS (CMK/BYOK/HYOK), la conformité, et surtout ce que le chiffrement au repos ne protège PAS. Pour le contexte des primitives, voir Chiffrement symétrique expliqué et Rotation de clés.

1. Définition et périmètre

1.1 Ce que le chiffrement au repos adresse

Le modèle de menace couvert :

1.2 Le principe cryptographique

Les données au repos sont chiffrées avant écriture sur medium de stockage et déchiffrées à la lecture dans un contexte où la clé est accessible (processus autorisé, machine allumée, mot de passe saisi). La clé est typiquement protégée par une couche KEK (Key Encryption Key) stockée dans un HSM, TPM, ou KMS cloud.

2. Les 4 couches de chiffrement au repos

Couches de chiffrement au repos — granularité croissante
─────────────────────────────────────────────────────────
 
Couche 4 — APPLICATION
  ┌──────────────────────────────────────┐
  │ Application chiffre champ/objet      │
  │ Ex: envelope encryption + AWS KMS    │
  │     pgp files, age, sops             │
  │ Granularité : par donnée             │
  │ Clé : KMS cloud, HSM, mot de passe   │
  └──────────────────────────────────────┘
                   │
                   ▼
Couche 3 — BASE DE DONNÉES
  ┌──────────────────────────────────────┐
  │ DB chiffre fichiers data + logs       │
  │ Ex: SQL Server TDE, Oracle TDE,      │
  │     MongoDB Queryable Encryption     │
  │ Granularité : tablespace ou instance │
  │ Clé : Master Key DB, KMS             │
  └──────────────────────────────────────┘
                   │
                   ▼
Couche 2 — FILESYSTEM
  ┌──────────────────────────────────────┐
  │ FS chiffre les fichiers de contenu    │
  │ Ex: fscrypt Linux (ext4, f2fs),      │
  │     EFS Windows, APFS FileVault      │
  │ Granularité : par fichier/dossier    │
  │ Clé : password user + keyring        │
  └──────────────────────────────────────┘
                   │
                   ▼
Couche 1 — DISQUE ENTIER
  ┌──────────────────────────────────────┐
  │ Chiffre tous les secteurs du disque  │
  │ Ex: LUKS/dm-crypt Linux, BitLocker   │
  │     Windows, FileVault macOS, EBS    │
  │ Granularité : tout ou rien           │
  │ Clé : TPM + PIN, passphrase, KMS    │
  └──────────────────────────────────────┘

Règle de combinaison : les couches se cumulent. Un workload production 2025 a typiquement FDE (couche 1) + TDE (couche 3) + app-level pour données ultra-sensibles (couche 4). Chaque couche protège contre un vecteur distinct.

3. Couche 1 — Full Disk Encryption (FDE)

3.1 Algorithme dominant : AES-XTS

AES-XTS (XEX-based Tweaked codebook mode with ciphertext Stealing) est le standard disque :

• NIST SP 800-38E (2010), IEEE Std 1619-2018.
• Clé de 256 ou 512 bits (XTS AES-128 + AES-128 pour tweak, ou XTS AES-256 + AES-256).
• Chiffrement bloc par bloc (512 ou 4096 octets secteur), pas d'expansion — la taille chiffrée = taille plaintext.
• Accès aléatoire à n'importe quel secteur sans déchiffrer tout le disque.
• Tweak basé sur le numéro de secteur empêche le pattern analysis à l'intérieur du disque.
• Pas d'authentification intégrée — repose sur les checksums filesystem pour détecter la corruption.

3.2 Implémentations par OS

3.3 LUKS2 — pattern Linux de référence

# Initialisation d'un volume LUKS2 (écrase tout)
sudo cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 \
    --key-size 512 \
    --hash sha256 \
    --pbkdf argon2id \
    --pbkdf-memory 1048576 \
    --pbkdf-parallel 4 \
    --pbkdf-force-iterations 10 \
    /dev/nvme0n1p2
 
# Ouverture (déchiffrement à l'amorçage ou après)
sudo cryptsetup luksOpen /dev/nvme0n1p2 encrypted-data
 
# Le volume déchiffré est accessible via /dev/mapper/encrypted-data
sudo mkfs.ext4 /dev/mapper/encrypted-data
sudo mount /dev/mapper/encrypted-data /mnt/data
 
# Ajouter un second slot (recovery key par exemple)
sudo cryptsetup luksAddKey /dev/nvme0n1p2
 
# Lister les slots (8 slots LUKS2)
sudo cryptsetup luksDump /dev/nvme0n1p2
 
# Fermeture
sudo umount /mnt/data
sudo cryptsetup luksClose encrypted-data

3.4 Cloud : EBS encryption AWS

# Terraform — EBS encryption par défaut + volume chiffré
resource "aws_ebs_encryption_by_default" "enable" {
  enabled = true
}
 
resource "aws_ebs_default_kms_key" "default" {
  key_arn = aws_kms_key.ebs_default.arn
}
 
resource "aws_kms_key" "ebs_default" {
  description             = "EBS default encryption key"
  enable_key_rotation     = true
  deletion_window_in_days = 30
  policy                  = data.aws_iam_policy_document.ebs_key.json
}
 
# Instance EC2 avec volume explicite chiffré avec CMK dédiée
resource "aws_ebs_volume" "data" {
  availability_zone = "eu-west-3a"
  size              = 100
  type              = "gp3"
  encrypted         = true
  kms_key_id        = aws_kms_key.app_data.arn
 
  tags = {
    Name        = "data-prod"
    Environment = "prod"
  }
}

Activation du default encryption au niveau compte AWS depuis 2021 garantit que tout nouveau volume EBS est chiffré — quick-win sécurité critique.

4. Couche 2 — Filesystem encryption

4.1 Linux fscrypt (ext4, f2fs)

fscrypt (kernel Linux 4.1+, 2015) chiffre au niveau fichier/dossier individuel, chaque utilisateur a ses clés propres via keyring. Usage typique : Chromebook, smartphones Android, serveurs multi-tenant.

# Initialisation fscrypt (Ubuntu 20.04+)
sudo fscrypt setup
 
# Chiffrer un dossier utilisateur
fscrypt encrypt /home/alice
 
# Verrouiller/déverrouiller session
fscrypt lock /home/alice
fscrypt unlock /home/alice

4.2 Avantages vs FDE

• Clés par utilisateur : un admin ne voit pas les données des autres utilisateurs sans leur password.
• Partiel : seuls certains dossiers chiffrés.
• Backup : les backups peuvent rester chiffrés.

4.3 Inconvénients

• Metadata (noms fichiers, tailles, dates) non-chiffrés par défaut.
• Partage plus complexe (clés à partager explicitement).
• Intégration plus fragile avec certains outils backup.

5. Couche 3 — Transparent Data Encryption (TDE)

5.1 SQL Server TDE

Depuis SQL Server 2008 Enterprise Edition (2019 Standard+). Structure :

Hiérarchie de clés SQL Server TDE
──────────────────────────────────────
 
DEK (Database Encryption Key)        ← chiffre les pages DB + transaction log
 │  chiffrée par
 ▼
Server Certificate                    ← stocké dans Master DB
 │  chiffré par
 ▼
Service Master Key                    ← protégée par Windows DPAPI ou EKM/HSM

-- Activer TDE sur une base SQL Server
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword123!';
 
CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate';
 
BACKUP CERTIFICATE TDECert TO FILE = 'C:\Backup\TDECert.cer'
  WITH PRIVATE KEY (
    FILE = 'C:\Backup\TDECert.pvk',
    ENCRYPTION BY PASSWORD = 'CertPrivateKeyPassword456!'
  );
 
USE MyDatabase;
CREATE DATABASE ENCRYPTION KEY
  WITH ALGORITHM = AES_256
  ENCRYPTION BY SERVER CERTIFICATE TDECert;
 
ALTER DATABASE MyDatabase SET ENCRYPTION ON;
 
-- Vérification
SELECT name, is_encrypted FROM sys.databases WHERE name = 'MyDatabase';

5.2 Oracle TDE

Oracle Database 11g+ (2007). Similaire : Master Encryption Key dans wallet/Oracle Key Vault, TDE Column Encryption pour colonnes spécifiques OU TDE Tablespace Encryption pour tablespaces entiers.

5.3 PostgreSQL — pas de TDE natif avant 2024

PostgreSQL n'a pas de TDE natif jusqu'à PostgreSQL 17 (2024). Travaux communautaires en cours. Alternatives :

• Chiffrement filesystem LUKS sous la DB.
• pgcrypto pour chiffrement colonne niveau SQL.
• Extensions tierces : Crunchy Data Postgres, Percona PostgreSQL avec TDE Open Source.

5.4 Cloud managed DB

5.5 Limites TDE

TDE ne protège pas contre :

• SQL injection — l'app déchiffre en répondant.
• DBA avec accès lecture aux tables — les pages sont déchiffrées à la requête.
• pg_dump / mysqldump — output en clair sauf chiffrement additionnel.
• Memory dump de la DB en cours d'exécution — les pages en mémoire sont en clair.

TDE = contrôle de compliance + vol disque, pas une panacée.

6. Couche 4 — Application-layer encryption

6.1 Pattern envelope encryption

Référence : voir Rotation de clés section 3 pour le détail envelope encryption avec code Python AWS KMS.

Principe :

• DEK unique par donnée (ou par tenant, ou par user) chiffre le contenu.
• DEK elle-même chiffrée par KEK en KMS cloud (AWS KMS, Azure Key Vault, GCP Cloud KMS).
• Ciphertext stocké = [DEK chiffrée] + [nonce] + [ciphertext AES-GCM] + [auth tag].

6.2 Exemple minimal Python

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import boto3, os, base64
 
kms = boto3.client("kms")
KEK_ARN = "arn:aws:kms:eu-west-3:123456789012:key/abcdef-1234-5678-90ab-cdef12345678"
 
def encrypt_field(plaintext: str) -> str:
    # Génère DEK AES-256 via KMS
    dek_response = kms.generate_data_key(KeyId=KEK_ARN, KeySpec="AES_256")
    dek_plaintext = dek_response["Plaintext"]
    dek_encrypted = dek_response["CiphertextBlob"]
 
    # Chiffre le champ en AES-256-GCM
    aesgcm = AESGCM(dek_plaintext)
    nonce = os.urandom(12)
    ciphertext = aesgcm.encrypt(nonce, plaintext.encode("utf-8"), None)
 
    # Sérialise pour stockage DB
    blob = {
        "v": 1,
        "edek": base64.b64encode(dek_encrypted).decode(),
        "nonce": base64.b64encode(nonce).decode(),
        "ct": base64.b64encode(ciphertext).decode(),
    }
    return base64.b64encode(str(blob).encode()).decode()

6.3 Formats et outils standardisés

7. AES-XTS vs AES-GCM : quel mode pour quoi

AES-XTS vs AES-GCM — matrice de choix
──────────────────────────────────────
 
Caractéristique               XTS           GCM
──────────────────────────────────────────────
Taille ciphertext              = plaintext   + 28 octets (nonce+tag)
Authentification               Non           Oui (AEAD)
Accès aléatoire secteur        Oui           Complexe (besoin offset)
Nonce unique requis            Non (tweak)   Oui (critique)
Hardware accel AES-NI          Oui           Oui
Usage recommandé               Stockage bloc Application/TLS
Exemple                        LUKS, EBS     HTTPS, envelope enc
Standard                       NIST 800-38E  NIST 800-38D
Premier draft                  2007          2004

Règle 2025 : XTS pour disque ou volume au niveau bloc ; GCM pour fichiers, champs, messages applicatifs au niveau objet. Jamais utiliser XTS au niveau applicatif (absence d'authentification + contraintes non-adaptées), jamais GCM au niveau disque (expansion incompatible).

8. Modèles de contrôle des clés : CMK / BYOK / HYOK

8.1 CMK — Customer Managed Key (standard)

La clé est générée dans le KMS cloud (AWS KMS, Azure Key Vault, GCP Cloud KMS), policies IAM contrôlées par le client, mais le cloud provider a eu accès matériel à la clé au moment de génération.

• Usage 2025 : 80 % des cas d'usage entreprises.
• Rotation automatique : oui (AWS 90-365 j, Azure/GCP configurable).
• Coût : faible (~1 $/mois/clé AWS).
• Performance : appel KMS par opération Encrypt/Decrypt (mitigé par cache DEK).

8.2 BYOK — Bring Your Own Key

La clé est générée dans un HSM on-prem (CloudHSM, Thales Luna, SafeNet) de l'organisation, puis importée dans le KMS cloud via cérémonie wrap/unwrap.

• Usage : banques avec exigences régulateur, secteur défense.
• Rotation automatique : désactivée (nécessite cérémonie import).
• Coût : 5-10x plus élevé (HSM on-prem + cérémonie + procédures).
• Performance : idem CMK après import.

8.3 HYOK / XKS — Hold Your Own Key / External Key Store

La clé reste physiquement dans un HSM on-prem, le KMS cloud fait des appels distants pour chaque opération Encrypt/Decrypt.

• Usage : souveraineté maximale (défense, secret médical strict).
• Rotation automatique : oui côté HSM local (XKS AWS depuis 2022).
• Coût : 10-20x CMK (HSM + réseau dédié + latence).
• Performance : latence additionnelle 10-100ms par opération crypto.

8.4 Tableau comparatif

9. Conformité réglementaire 2025

9.1 Textes de référence

9.2 Interprétation CNIL France 2022-2024

Plusieurs décisions de la CNIL ont considéré qu'une fuite de données personnelles non chiffrées était aggravante :

• Sanctions observées : amendes 50 k€ à 20 M€ selon gravité et taille entreprise.
• Notification 72h obligatoire (RGPD art 33) pour fuites de données non chiffrées.
• Pour fuites de données chiffrées correctement : notification souvent non requise si KMS non compromis.

9.3 Quick-wins conformité 2025

Checklist chiffrement au repos conformité 2025
───────────────────────────────────────────────
 
[ ] AWS/Azure/GCP : default encryption activé sur tous storages
[ ] Toutes instances DB production avec TDE ou équivalent natif
[ ] Backups stockés chiffrés avec rotation clé documentée
[ ] Laptops employés avec FDE (LUKS/BitLocker/FileVault) imposé via MDM
[ ] Bases contenant PII : chiffrement applicatif + envelope + KMS
[ ] Logs centralisés (SIEM) avec chiffrement S3/Azure Blob
[ ] Documentation politique cryptographique (ISO 27001 A.8.24)
[ ] Incident response plan incluant procédure clé compromise (voir Rotation de clés)
[ ] Revue annuelle des cryptopériodes et rotation
[ ] Audit chiffrement inclus dans program pentest interne

10. Les limites structurelles — ce que le chiffrement au repos ne protège pas

Classe n°1 de malentendu sécurité chez les équipes dev/ops. Le chiffrement au repos ne protège pas contre :

10.1 Attaquant avec accès runtime

Un attaquant qui obtient shell/RCE sur la machine allumée voit les données en clair car :

• FDE : le disque est déverrouillé, OS lit/écrit en clair via dm-crypt mapping.
• TDE : la DB déchiffre les pages pour répondre aux requêtes.
• App-layer : l'app a les permissions IAM pour appeler KMS et déchiffrer.

10.2 SQL injection et bugs applicatifs

Une SQL injection exfiltre les données déchiffrées par la DB pour la requête. TDE ne la détecte même pas.

10.3 Memory dump

Snapshot mémoire d'une machine allumée expose les données en clair. Attaques forensic type cold boot (gel de la RAM à -50°C pour extraire les clés).

10.4 Compromission des credentials applicatifs

Si l'app a l'IAM role kms:Decrypt, un attaquant qui vole le role via SSRF + IMDSv1 déchiffre tout.

10.5 Ransomware

Tes données chiffrées par toi, re-chiffrées par le ransomware = double chiffrement, incapacité de lire.

10.6 Insider threat avec privilèges legit

Un DBA ou admin qui a accès légitime déchiffrement applicatif peut tout lire. Le chiffrement au repos ne fait rien contre insider légitime.

Points clés à retenir

• Chiffrement au repos = 4 couches cumulatives : disque (FDE), filesystem, base de données (TDE), application (envelope encryption).
• AES-XTS pour disque (NIST SP 800-38E, pas d'expansion, accès aléatoire), AES-GCM pour application (NIST SP 800-38D, AEAD authentifié).
• FDE : LUKS2 Linux, BitLocker Windows, FileVault macOS, AWS EBS / Azure Disk / GCP PD encryption par défaut.
• TDE : SQL Server 2008+, Oracle 11g+, Azure SQL / AWS RDS / GCP Cloud SQL natif. PostgreSQL sans TDE natif jusqu'à PG 17.
• Envelope encryption = pattern standard application-layer : DEK unique par donnée chiffrée par KEK en KMS.
• CMK (80 % cas), BYOK (finance régulée), HYOK / XKS (souveraineté maximale) — coûts ×5 à ×20 entre CMK et HYOK.
• Conformité 2025 : RGPD art 32, PCI-DSS v4.0 requirement 3.5, ANSSI RGS v2.0, NIS 2, DORA, ISO 27001:2022 A.8.24.
• Limites critiques : ne protège pas contre attaquant runtime, SQL injection, memory dump, credentials IAM volés, ransomware, insider légitime.
• Règle opérationnelle : contrôle de défense en profondeur, jamais autoportant. S'articule OBLIGATOIREMENT avec IAM, secure coding, secrets management, detection runtime.

Pour les primitives sous-jacentes, voir Chiffrement symétrique expliqué, Pourquoi ECB est mauvais. Pour la rotation des KEK/DEK, Rotation de clés. Pour le stockage des secrets applicatifs, Où stocker les secrets et Secrets management dans le cloud. Pour les patterns secure coding crypto, Principes de secure coding.