Sécuriser les données en mémoire dans le cloud

Le chiffrement au repos protège un disque volé, le chiffrement en transit protège un flux intercepté. Entre les deux, une application déchiffre, calcule et charge des secrets en mémoire, souvent sur une infrastructure exploitée par un tiers. Le confidential computing réduit cette exposition, à condition de le traiter comme une architecture de confiance mesurable, pas comme un autocollant sur une machine virtuelle.

→ Lire l’explication complète de la marmotte

Confidential computing : le périmètre réellement protégé

Le confidential computing repose sur un environnement d’exécution isolé matériellement, appelé TEE (Trusted Execution Environment). Le processeur chiffre les pages mémoire attribuées à une machine virtuelle ou à un conteneur protégé, puis limite leur déchiffrement au code exécuté dans cet environnement. L’hyperviseur, le système d’exploitation hôte et l’administrateur de la plateforme restent capables d’arrêter, planifier ou observer le workload, mais ne doivent pas pouvoir lire directement sa mémoire.

Le compromis central est net : on gagne une protection contre l’opérateur de l’infrastructure et contre une compromission de l’hôte, mais on paie en contraintes d’exploitation, en compatibilité et en complexité de gestion des secrets. Cette approche est justifiée pour des données dont l’exposition en mémoire est le risque dominant : modèles propriétaires, clés applicatives, traitements inter-organisations ou données soumises à une séparation de responsabilité forte.

Elle ne justifie pas de déplacer une application banale dans une machine virtuelle prétendument sacrée. Un TEE ne corrige ni les injections SQL, ni l’exfiltration par une API légitime, ni un développeur qui journalise le mot de passe de production parce que « c’était pour diagnostiquer ». Les slides vendeurs appellent cela une forteresse ; en pratique, c’est une pièce blindée avec une fenêtre applicative qu’il faut encore fermer.

Les mécanismes matériels diffèrent selon le fournisseur : AMD Secure Encrypted Virtualization with Secure Nested Paging, souvent abrégé SEV-SNP, protège des machines virtuelles complètes ; Intel Trust Domain Extensions, ou TDX, vise un modèle comparable ; les enclaves telles que Intel Software Guard Extensions, ou SGX, isolent plutôt un processus ou une partie de processus. Les fondations matérielles sont traitées dans les fondations cryptographiques et matérielles. Pour les workloads cloud, le choix utile est rarement entre deux noms de processeurs : il dépend du niveau d’isolation nécessaire et de la capacité à intégrer une attestation vérifiable dans la livraison des secrets.

Attestation distante et libération conditionnelle des secrets

L’attestation distante permet de vérifier qu’un workload tourne dans un environnement protégé et attendu avant de lui remettre une clé. Le matériel produit une preuve signée contenant des mesures : version du firmware, configuration de sécurité, identité du workload ou empreinte de son image. Un service de vérification contrôle la chaîne de certificats, les valeurs mesurées et les politiques de sécurité, puis autorise ou refuse une opération.

La règle d’architecture est stricte : ne jamais fournir le secret métier au démarrage sur la foi d’une identité de machine virtuelle ou d’un jeton de déploiement. Le secret doit être libéré après validation de l’attestation, avec une politique qui lie au minimum le type de TEE, la version minimale de firmware, l’image approuvée et l’environnement cible. Sans ce lien, l’attestation devient un joli rapport cryptographique qui ne décide rien. Une relique de conformité, donc.

Un KMS (Key Management Service) peut conserver une KEK (Key Encryption Key), utilisée pour déchiffrer ou déverrouiller une DEK (Data Encryption Key). La DEK chiffre les données applicatives et ne doit entrer dans la mémoire protégée qu’après attestation. Le KMS doit exiger une identité de workload courte durée, elle-même émise après vérification de la preuve matérielle. Une identité Kubernetes seule ne suffit pas : l’administrateur du cluster contrôle généralement les jetons de service et peut créer un pod homonyme avec une conviction admirable.

L’attestation doit être fraîche. Accepter une preuve sans défi aléatoire, ou nonce, permet la relecture d’une ancienne preuve valide. Le vérificateur génère ce nonce, le retrouve dans l’attestation et refuse toute réponse expirée. Les politiques doivent également rejeter les versions de firmware vulnérables, même si leurs mesures applicatives restent identiques. Une image saine exécutée sur une fondation connue comme compromise ne devient pas saine par optimisme.

L’identité applicative reste nécessaire après l’attestation. Pour les autorisations métier, utiliser une fédération fondée sur OpenID Connect, ou OIDC, avec des jetons courts, une audience précise et une vérification côté ressource. Les mécanismes de gestion des identités cloud couvrent la partie identité et délégation. Le TEE prouve où le code s’exécute ; il ne prouve pas que le code est autorisé à consulter chaque enregistrement.

Prérequis de plateforme pour les workloads confidentiels

Un déploiement fiable commence par vérifier la chaîne entière, pas seulement l’option activée dans la console cloud. Il faut un type d’instance exposant un TEE, un firmware et un microcode pris en charge, un hyperviseur compatible, une image système prévue pour ce mode et un service d’attestation accessible depuis le workload. Le fournisseur doit documenter l’état de protection contre les attaques de remappage mémoire, pas seulement le chiffrement de mémoire.

Dans Kubernetes, prévoir au minimum Kubernetes 1.26 ou une version compatible avec le runtime choisi, containerd 1.7 ou ultérieur, et Kata Containers 3.x lorsqu’un conteneur doit être exécuté dans une machine virtuelle isolée. Le runtime doit être installé sur un pool de nœuds dédié. Mélanger des nœuds confidentiels et ordinaires sous le même sélecteur de planification revient à tirer au sort le niveau de sécurité à chaque redémarrage. Ce n’est pas de l’élasticité, c’est une tombola.

L’image du workload doit être immuable et mesurée. Référencer une image par étiquette mutable, par exemple latest, interdit de savoir ce qui a réellement été attesté. Utiliser un digest, signer l’image et vérifier cette signature avant l’exécution. La chaîne de livraison doit également produire un manifeste des composants, ou SBOM (Software Bill of Materials), afin d’associer les mesures attendues à une version reconstruisible.

Les dépendances réseau sont souvent oubliées. Le workload doit joindre le service d’attestation, le KMS et les services métier nécessaires, via Transport Layer Security, ou TLS, avec validation stricte des certificats. Une autorité de certification compromise ou un proxy d’entreprise capable d’intercepter TLS déplace la frontière de confiance. Les principes de sécurisation des réseaux restent applicables : filtrage sortant, résolution de noms contrôlée, journalisation des flux et séparation des plans d’administration.

Exemple Kubernetes avec RuntimeClass isolée

L’exemple suivant force un pod à utiliser un runtime Kata Containers déclaré pour les workloads confidentiels. Il ne crée pas la protection matérielle à lui seul : le runtime, les nœuds et l’attestation doivent déjà exister. Cette distinction évite le folklore habituel où trois annotations sont censées résoudre un problème de processeur.

# Le handler doit correspondre au runtime installé sur chaque nœud concerné.
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: confidential
handler: kata-cc
scheduling:
  nodeSelector:
    workload-security: confidential
---
# workload-confidential.yaml
apiVersion: v1
kind: Pod
metadata:
  name: traitement-confidentiel
spec:
  runtimeClassName: confidential
  containers:
    - name: application
      # Un digest fige l'image mesurée, contrairement à une étiquette mutable.
      image: registry.example.net/traitement@sha256:REMPLACER_PAR_DIGEST
      env:
        - name: ATTESTATION_ENDPOINT
          value: https://attestation.example.net/verify
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true

Appliquer le manifeste ne suffit pas à démontrer l’isolation. Vérifier que le pod est planifié sur le bon pool, que le runtime lance réellement une machine virtuelle protégée, puis déclencher une demande de secret auprès du KMS avec une attestation invalide. Le refus est le test qui compte. Une réponse positive sur le chemin heureux valide surtout la connectivité, ce qui est charmant mais insuffisant.

Surface d’attaque et limites du chiffrement mémoire

Le confidential computing protège principalement contre la lecture ou la modification arbitraire de la mémoire par l’hôte. Il ne masque pas nécessairement les métadonnées : taille des machines virtuelles, fréquence des appels réseau, durée d’exécution, volume de stockage et parfois motifs d’accès mémoire. Une analyse de trafic peut révéler une activité sensible même lorsque le contenu reste chiffré.

Les canaux auxiliaires constituent la limite la plus difficile. Temps d’exécution, défauts de cache, contention mémoire, pagination ou observation des accès peuvent divulguer des informations selon le modèle matériel. Les garanties exactes dépendent du TEE et de sa génération. Pour un traitement à haut risque, réduire les données sensibles sorties du TEE, éviter les algorithmes à temps variable, désactiver le débogage et évaluer les interfaces de mémoire partagée. Le chiffrement mémoire n’est pas une gomme magique pour les fuites latérales.

Les attaques de rejeu et de rollback visent l’état persistant. Un opérateur malveillant peut restaurer un disque ou un instantané antérieur, même sans lire son contenu. Chiffrer l’état avec une clé protégée ne détecte pas cette restauration. Il faut un compteur monotone externe, un journal append-only vérifié, ou un service de versionnement auquel le workload compare son état. Sans anti-rollback, une base chiffrée peut revenir à une version où un compte supprimé existait encore.

Enfin, l’hôte conserve un pouvoir de déni de service : arrêt, suspension, saturation réseau, suppression de volume, refus de planification. Le TEE ne garantit ni disponibilité ni reprise. Cette limite doit alimenter l’architecture de résilience décrite dans les stratégies cloud, pas être dissimulée sous un terme marketing à consonance spatiale.

Rotation, supervision et reprise contrôlée

Les clés de données doivent être éphémères autant que possible. Une DEK par objet, lot ou session limite le rayon d’exposition et permet une rotation sélective. La KEK reste dans un KMS ou dans un HSM (Hardware Security Module) lorsque le niveau d’assurance requis impose que la clé maîtresse ne quitte pas un matériel dédié. La page sur le module cryptographique matériel et PKCS#11 détaille les contraintes de ce type d’intégration.

Une rotation de clé doit inclure les anciennes versions tant que des données chiffrées avec elles existent. Révoquer brutalement une KEK sans inventaire des objets dépendants transforme une opération de sécurité en exercice de destruction de données. Prévoir une période de recouvrement, réenvelopper progressivement les DEK, puis désactiver la version retirée après contrôle d’achèvement.

Journaliser les décisions, jamais les secrets : identité de workload, mesure attestée, version de politique, identifiant de clé, résultat et motif du refus. Les journaux doivent être exportés hors du domaine administré par l’hôte, sinon l’opérateur capable d’attaquer le workload peut aussi effacer sa trace. Surveiller les échecs d’attestation, les changements de mesure, les demandes de clés inhabituelles et les restaurations d’état.

La reprise exige une procédure de réattestation complète. Une sauvegarde chiffrée doit contenir les métadonnées nécessaires pour retrouver la bonne version de clé, mais jamais la clé elle-même. Restaurer un workload sur une autre région ou un autre fournisseur peut modifier les mesures attendues : la politique doit prévoir ce cas explicitement, avec une approbation contrôlée. La disponibilité se construit avec des sauvegardes testées ; elle ne se déduit pas d’un chiffrement mémoire.

🐝 Ce qui arrive si on s’en passe

Sans TEE, la mémoire d’une machine virtuelle reste lisible en clair par l’hyperviseur, et cette lecture ne produit aucun événement observable depuis l’invité : aucun journal applicatif, aucune alerte système ne signale qu’une DEK ou un jeu de données a été copié. Les opérations d’exploitation courantes deviennent alors des canaux de fuite : un instantané avec état mémoire, une suspension sur disque, une migration à chaud ou un vidage mémoire collecté pour diagnostic écrivent les clés déchiffrées et les données en cours de traitement sur le stockage de l’hôte, hors de tout chiffrement applicatif et hors de la politique de rotation. Une clé ainsi recopiée reste exploitable après sa révocation dans le KMS pour toutes les données qu’elle a déjà chiffrées.

🦫 Explication de la marmotte 🍫

Pendant qu’un programme travaille, ses données doivent être déchiffrées dans la mémoire de la machine. Le confidential computing utilise une protection intégrée au processeur pour empêcher le système qui héberge le programme de lire directement cette mémoire. Cette protection peut couvrir une machine virtuelle entière ou une zone réservée à un programme.

Avant de donner une clé de déchiffrement au programme, un service vérifie une preuve produite par la machine. Cette preuve indique quel programme est lancé, avec quelle configuration et sur quel matériel. Le service compare ces informations à des règles prévues à l’avance. Si la version du programme, la protection matérielle ou les réglages ne correspondent pas, la clé reste bloquée et le traitement échoue.

Les données restent chiffrées sur les disques et pendant les échanges réseau. La clé n’est déchiffrée qu’après la vérification, puis doit être remplacée régulièrement. Les décisions de refus et d’autorisation sont enregistrées pour détecter les anomalies.

Cette protection ne rend pas le programme infaillible. Un programme mal conçu peut toujours envoyer ses propres données à un attaquant. L’hébergeur peut aussi arrêter la machine, couper le réseau ou restaurer une ancienne sauvegarde. Il faut donc contrôler le code, limiter les accès, surveiller les demandes de clés et prévoir des sauvegardes vérifiées.

Pages voisines

La citent

Sécuriser les données en mémoire dans le cloud

Elle cite

Sécuriser les données en mémoire dans le cloud

Sécuriser les données en mémoire dans le cloud

Confidential computing : le périmètre réellement protégé

Attestation distante et libération conditionnelle des secrets

Prérequis de plateforme pour les workloads confidentiels

Exemple Kubernetes avec RuntimeClass isolée

Surface d’attaque et limites du chiffrement mémoire

Rotation, supervision et reprise contrôlée

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines