Cryptage At Rest

Cryptage At Rest

1) Pourquoi cela est nécessaire et ce que nous défendons exactement

Définition. Le cryptage at rest est la protection des données enregistrées sur le support (disques, snapshots, backups, objets, logs, vides de mémoire) afin que l'accès non autorisé au support physique ou au stockage « brut » ne révèle pas le contenu.

• Volumes de fichiers/blocs, référentiels d'objets, bases de données, files d'attente/cawell, cache-vides, logs/trajets, sauvegardes, exportations/importations, snapshots VM/conteneurs, vides de noyau/processus, alimentation/swap.
• Scénarios multi-classes : isolation entre les clients/projets/environnements.

Ce que nous ne couvrons pas complètement : vol de sessions en mémoire, attaques sur le processus en direct, vulnérabilités de l'application, compromission des informations d'identification. Cela nécessite le chiffrement « en vol », l'authentification/autorisation stricte, la minimisation des droits et la surveillance (voir les articles connexes : « Authentification et autorisation », « Signature et vérification des demandes »).

2) Modèle de menace et objectifs de contrôle

• Perte/vol de support (disque, bande, USB, dispositif de développement).
• Accès non autorisé aux backaps/snapshots/logs.
• Abus de privilèges au niveau de la plate-forme/hyperviseur/scorage.
• Intersection des locataires en cas d'erreurs de configuration.
• Les fichiers temporaires « débris » et les vides qui tombent dans les artefacts et les images.

1. Confidentialité des données sur le support.

2. Isolation cryptographique des locataires/environnements.

3. Gestion des clés (création, stockage, rotation, révocation).

4. Vérifiable (qui et quand a utilisé la clé).

5. Minimisez les risques opérationnels en cas d'incident.

3) Principes de base de l'architecture

Crypter tout par défaut. L'opt-out est interdit sans exception au niveau du risque.
Hiérarchie des clés (envelope encryption). Root/KEK → DEK (data encryption keys) → objets/fichiers/pages OBD.
KMS/HSM comme source de confiance. La génération et le stockage de KEK dans KMS/HSM, les opérations d'emballage/déploiement de clés sont effectuées au même endroit.
Clés per-tenant/per-dataset. Granularité aux exigences d'isolement et de rotation.
Partage des responsabilités. Commandes de la plate-forme ≠ propriétaires des clés du locataire ; minimum de privilèges (PoLP).
Crypto-agility. Possibilité de migrer en toute sécurité les algorithmes/longueurs de clés.
La rotation est un processus, pas un événement. Les clés et les données doivent supporter un remplacement « glissant ».

4) Algorithmes et modes de cryptage

Pour les objets/fichiers/enregistrements : AES-256-GCM ou AES-256-SIV (AEAD avec authentification).
Pour les blocs/volumes : AES-XTS-256/512 (protection contre les permutations de blocs ; ne pas AEAD - utiliser au-dessus des formats de fichiers avec MAC lorsque l'intégrité est importante).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Cryptographie de champ/minuscule (FPE/cryptage déterministe) - pour les capacités de recherche/joyaux sur les champs cryptés ; appliquer prudemment.
• Génération et stockage de clés : KEK - dans KMS/HSM ; DEK - dans la mémoire des applications à courte durée de vie, lors du stockage - seulement sous forme enveloppée.

5) Hiérarchie des clés et KMS/HSM

1. Root key (statutaire, en HSM/KMS). Ne quitte pas le périmètre HSM/KMS.

2. KEK (Key Encryption Key). Pour le projet/environnement/locataire. Gère le cycle de vie DEK.

3. DEK (Data Encryption Key). Par objet/fichier/table/segment. Courte vie, rotation sans arrêt.

• Toutes les opérations d'emballage/de déploiement - via l'API KMS avec audit.
• Politiques : qui peut « utiliser » la clé ≠ qui peut « contrôler » la clé.
• Géo-distribution des clés : pin-to-region + dual-control pour la interrégionale.
• Un modèle « à deux couches » (deux opérateurs) est possible pour les opérations à haut risque.
• Pour isoler un niveau fort - des clés individuelles par locataire.

6) Rotation, rappel et conformité

Rotation DEK : transparente et permanente (rolling re-encryption au niveau des objets/pages).
Rotation KEK : périodique (par exemple tous les 6 à 12 mois) + révocation immédiate en cas de suspicion de compromission.
Révocation de l'accès : via les politiques KMS ; blocage des opérations unwrap = « crypto-destruction » instantanée des données.
Journaux d'audit : qui, quand, avec quels droits ont utilisé les clés ; stocker séparément et crypter aussi.
Réglementations et normes : nous nous concentrons sur les exigences de l'industrie (par exemple, les tolérances GDPR/PCI/régulateurs locaux), utilisons des cryptomodules certifiés (par exemple, conformité aux niveaux de certification).

7) Modèles par type de stockage

7. 1 Volumes de blocs/fichiers et VM/conteneurs

Chiffrement complet (XTS) + gestion des clés via KMS (initialisation du volume lors du montage).
Protéger swap, crash-dump, tmp-répertoire, conteneur overlay-calques, images/AMI.
Snapshots/snapshots - toujours sous forme cryptée avec des DEK distincts.

7. 2 Stockage d'objets

Encryption Envelope : Un DEK unique par objet ; titres/métadonnées - pas de fuites PII.
Contrôle de l'accès à la clé KMS par locataire et environnement.
Cryptage serveur-site (SSE avec son propre KMS) ou client-site (CSE) : Sélectionnez le modèle de confiance.

7. 3 Bases de données

Inclure les TDE lorsqu'ils sont disponibles ; Lier les clés OBD au KMS via le plugin/extatique.
Pour les champs particulièrement sensibles - le cryptage d'application (AEAD) avant l'entrée dans l'OBD.
Logs redo/transactionnels, logs archivés, vides - chiffrer séparément, clés séparées.

7. 4 Logs/Tracks/métriques

Format des logs - pas de données sensibles par défaut (assainissement).
Les archives de logs sont des clés individuelles et des TTL de stockage courts.
L'accès à la lecture des logs est via un service proxy avec A&A et un audit.

7. 5 Sauvegardes et médias hors ligne

Toujours crypter côté client avant d'écrire sur bande/cloud.
Stocker les clés séparément (out-of-band), escrow avec contrôle séparé.
Pour les cas d'urgence, la séparation du secret (p. ex. m-of-n) pour rétablir l'accès maître.

8) Polyvalence (multi-tenant)

Clé sur le locataire : KEK-per-tenant + DEK-per-dataset.
Isolation par les politiques : espaces de noms KMS, frontières IAM, rôles IDP distincts.
Suppression à la demande du client : « crypto-effacer » - rappeler le KEK du locataire et détruire le DEK.
Reporting pour le client : artefacts de conformité, logs d'accès aux clés, confirmation de rotation.

9) Performance et fonctionnement

Accélérations matérielles (AES-NI/x86, ARMv8 Crypto Extensions).
Profilage des chemins chauds : cryptage aux frontières I/O, éviter le double cryptage sans besoin.
Pools de session KMS, mise en cache des DEK enveloppés en mémoire (avec TTL et protection contre les décharges).
SLO/métriques : latence unwrap, proportion d'objets « transcryptés », erreurs KMS, taux de chiffrement backup.

10) Processus de mise en œuvre (guide de référence)

Étape 0 - Inventaire des données. Répertorier tous les entrepôts et chemins de fuite (tmp, vides, exportations, bouquets analytiques).
Étape 1 - conception de la hiérarchie clé. Nous déterminons les niveaux KEK/DEK, la granularité, les régions, les rôles.
Étape 2 - sélection des modes/bibliothèques. Algorithmes approuvés, crypto-bibliothèques, politiques de version.
Étape 3 - intégration avec KMS/HSM. Génération/emballage/audit, politiques IAM, géo-pinning.
Étape 4 - chiffrement par écriture. Activer la migration par défaut des données existantes via le background-reenkript.
Étape 5 - rotation et scénarios d'urgence. Règlements, tests « key compromise », « KMS non disponible ».
Étape 6 - Surveillance et vérification. Dashboards, alertes, rapports de conformité réguliers.
Étape 7 - formation et « codage sécurisé ». Hydes pour les ingénieurs, interdiction des secrets dans les logs/vides.

11) Test et vérification

Tests crypto-unit : exactitude de l'AEAD (Tag Check), validation de l'échec lorsque l'octet change.
Failure-tests : Désactivation de KMS, versions obsolètes des clés, révocation forcée de KEK.
Tests Red/Blue : essayer de lire le disque/snapshot/backup « brut ».
Vérification de compatibilité : migration des algorithmes/longueurs de clés (crypto-agility).
Certification des bibliothèques : n'utiliser que des cryptomoduli validés ; Enregistrer les versions.

12) Erreurs fréquentes et comment les éviter

Double chiffrement sans aucun sens. Latence et complexité superflues. Tenez une couche qui donne la granularité et l'isolation souhaitées.
Stockage des clés à côté des données. Les clés sont toujours séparées, sous un autre modèle d'accès.
Des artefacts oubliés. Fichiers temporaires non cryptés, exportation CSV, vidages de support. Activer le contrôle dans CI/CD et Data Loss Prevention.
Pas de rotation. Faites de la rotation une partie de pipeline/cron, pas une procédure manuelle.
Logs avec données sensibles. Entrez un contrat pour le format des logs et des désinfectants automatiques.

13) Mini recettes (pseudo-code)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Chèques-feuilles

• Le chiffrement par défaut est activé sur tous les types de stockage.
• La hiérarchie des clés est décrite et mise en œuvre ; les rôles et les politiques IAM sont configurés.
• KMS/HSM est intégré, l'audit des opérations clés est inclus.
• La rotation DEK/KEK est automatisée ; les scénarios de compromission ont été mis au point.
• Backups, snapshots, logs et vides - cryptés ; les clés sont conservées séparément.
• Configurés pour les erreurs KMS, les rejets d'étiquettes AEAD, la proportion d'artefacts non chiffrés.
• Les tests d'indisponibilité KMS et de révocation de clés ont été passés.

• Rapport mensuel sur l'utilisation des clés et les tentatives d'accès.
• Plan crypto-agility et fenêtre pour la migration indolore des algorithmes.
• Red-team périodique pour extraire les données des médias « bruts ».

15) Questions et réponses (FAQ)

Q : Le chiffrement complet est-il suffisant ?
R : Pour les risques physiques - oui, mais pour l'isolation des locataires et la rotation flexible est préférable envelope avec DEK-on-objet/recrutement.

Q : Que faire quand on compromet KEK ?
R : Retirer immédiatement KEK à KMS, en transférer un nouveau, effectuer la réécriture de tous les DEK, vérifier les journaux et effectuer un RCA.

Q : Comment chiffrer les champs que vous recherchez ?
R : Utiliser des schémas déterministes ou FPE uniquement dans le cadre d'une évaluation rigoureuse des risques (leks de patterns). Il est préférable de concevoir les requêtes de sorte que les champs sensibles ne nécessitent pas une vue ouverte indexable.

Q : Ai-je besoin d'une commande distincte pour les clés ?
R : Il est recommandé que « Crypto/KMS Operator » soit un rôle avec des droits et des procédures distincts.

• Gestion des clés et rotation
• Authentification S2S
• Signature et vérification des demandes
• OAuth2/OpenID Connect dans le noyau
• « Garantie de livraison des webhooks »