Points clés
- Le modèle de responsabilité partagée du cloud transfère la responsabilité du chiffrement en grande partie vers le client — pas vers le fournisseur cloud.
- Chiffrement au repos, en transit et en utilisation (confidential computing) représentent trois couches distinctes à adresser dans un environnement cloud.
- La gestion des clés dans le cloud impose des choix structurants : clés gérées par le fournisseur, par le client (CMK), ou via HSM dédié.
- Les environnements multi-cloud et hybrides multiplient la complexité de la gestion des clés et nécessitent une stratégie d'interopérabilité.
Le modèle de responsabilité partagée et le chiffrement
Dans le modèle de responsabilité partagée (Shared Responsibility Model) des clouds publics, le fournisseur assure la sécurité "du" cloud — infrastructure physique, hyperviseurs, réseaux sous-jacents. Le client est responsable de la sécurité "dans" le cloud — configuration des services, droits d'accès, chiffrement des données applicatives. Cette délimitation est souvent mal comprise, conduisant des organisations à supposer que leur fournisseur cloud chiffre et protège leurs données par défaut.
En réalité, si la plupart des services cloud offrent du chiffrement natif (S3, Azure Blob Storage, GCS chiffrent les données au repos par défaut), les clés de chiffrement utilisées par défaut sont gérées par le fournisseur. Une requête judiciaire ou une erreur d'accès peut donc permettre l'accès aux données même si elles sont techniquement "chiffrées". La protection réelle exige que le client contrôle ses propres clés.
Les trois couches de chiffrement cloud
Le chiffrement au repos protège les données stockées sur disque contre l'accès physique non autorisé aux médias de stockage. Dans le cloud, il est systématiquement assuré par les fournisseurs pour les services de stockage principaux, mais les bases de données créées sans configuration explicite, les volumes de disque temporaires ou les services tiers intégrés peuvent ne pas être couverts.
Le chiffrement en transit protège les données circulant entre composants. Dans le cloud, TLS est standard pour les communications externes, mais les communications inter-services internes au cloud (entre conteneurs dans un VPC, entre microservices) peuvent être en clair si le service mesh ou le mTLS n'est pas configuré. Le chiffrement en utilisation — ou confidential computing — protège les données pendant leur traitement en mémoire, via des enclaves sécurisées (Intel SGX, AMD SEV, ARM TrustZone). Cette technologie est encore émergente mais devient disponible chez les principaux fournisseurs cloud.
Options de gestion des clés dans le cloud
Trois modèles coexistent : les clés gérées par le fournisseur (SSE-S3 dans AWS, par exemple) où le fournisseur contrôle tout le cycle de vie de la clé ; les clés gérées par le client (CMK/SSE-KMS) où le client crée et contrôle la clé dans le KMS du fournisseur mais délègue les opérations cryptographiques ; et les clés gérées par le client hors du cloud du fournisseur (SSE-C dans AWS, BYOK — Bring Your Own Key) où la clé n'existe jamais dans l'infrastructure du fournisseur.
Ce dernier modèle offre la plus forte garantie de séparation mais impose au client de gérer l'infrastructure de stockage des clés (HSM physique ou virtuel), de transmettre les clés pour chaque opération de chiffrement/déchiffrement, et d'assumer les risques d'indisponibilité de son infrastructure de clés. Le choix entre ces modèles doit être guidé par le modèle de menace, les exigences réglementaires (souveraineté, CLOUD Act) et les contraintes opérationnelles.
Gestion des clés dans les environnements multi-cloud et hybrides
Les organisations qui utilisent plusieurs fournisseurs cloud (AWS, Azure, GCP) ou des environnements hybrides (cloud + on-premise) font face à un problème d'interopérabilité de la gestion des clés. Chaque fournisseur propose son propre KMS, avec des APIs et des modèles différents. La fragmentation de la gestion des clés crée des risques de perte de clés, des angles morts dans l'audit et une complexité opérationnelle qui favorise les erreurs.
Des solutions de KMS multi-cloud (HashiCorp Vault, Thales CipherTrust Manager, IBM Unified Key Orchestrator) permettent une gestion centralisée des clés quel que soit l'environnement de déploiement. Elles ajoutent une couche d'infrastructure critique qu'il faut elle-même hautement disponibiliser et sécuriser, mais permettent une politique de chiffrement cohérente et une piste d'audit unifiée.
Chiffrement et architecture serverless et conteneurisée
Les architectures serverless (fonctions AWS Lambda, Azure Functions) et conteneurisées (Kubernetes) introduisent des défis spécifiques : les secrets (clés de chiffrement, credentials) doivent être injectés dans les environnements d'exécution éphémères sans être stockés dans les images de conteneur ou les packages de déploiement. Les gestionnaires de secrets (AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets avec chiffrement etcd) adressent ce besoin mais nécessitent une configuration explicite et des tests réguliers.