Le chiffrement est partout dans le cloud — par défaut, gratuit, transparent. Mais cette banalité masque des nuances cruciales : at-rest, in-transit, in-use désignent trois états distincts, chacun avec ses mécanismes propres. La gestion des clés détermine qui peut réellement déchiffrer vos données — provider, vous via KMS, ou vous seul via HYOK. Cette page pose les concepts fondamentaux, explique l’architecture en enveloppe key + data key universelle aux KMS modernes, détaille les 4 modèles de gestion des clés du provider-managed au HYOK, et défend une opinion : pour des données vraiment sensibles, le customer-managed KMS est le minimum acceptable, et le HYOK est la voie pour la souveraineté technique.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les 3 états du chiffrement : at-rest, in-transit, in-use
- L’architecture en enveloppe universelle (master key + data key)
- Les 4 modèles de gestion des clés et leurs compromis
- Les services KMS par fournisseur (AWS KMS, Key Vault, Cloud KMS, Outscale KMS)
- Le défaut 2026 selon la sensibilité des données
Prérequis : avoir compris la responsabilité partagée. Si besoin, lisez d’abord Responsabilité partagée.
1. Les 3 états du chiffrement
Section intitulée « 1. Les 3 états du chiffrement »Une donnée peut être dans trois états distincts au cours de sa vie. Chaque état exige son propre mécanisme de protection.
At-rest — données stockées
Section intitulée « At-rest — données stockées »Les données au repos sont stockées sur disque, dans une base, dans un bucket. Elles sont chiffrées avant l’écriture sur le support physique, déchiffrées à la lecture.
Standard 2026 : AES-256 chez tous les hyperscalers et fournisseurs souverains, activé par défaut depuis 2020 sur la majorité des services. La clé de chiffrement est typiquement gérée par le service KMS du fournisseur.
Couverture typique : volumes EBS, snapshots, RDS, S3, DynamoDB, et leurs équivalents Azure/GCP/Outscale. Sur Outscale et OVHcloud, le chiffrement at-rest est inclus sans surcoût.
In-transit — données en transit
Section intitulée « In-transit — données en transit »Les données en transit circulent sur le réseau entre client et serveur, ou entre services. Elles sont protégées par des protocoles de transport sécurisé.
Standard 2026 : TLS 1.3 (RFC 8446, 2018), avec négociation forward secrecy obligatoire (ECDHE), suites de chiffrement modernes (AES-GCM, ChaCha20-Poly1305). TLS 1.2 reste accepté avec configurations strictes, TLS 1.0/1.1 sont interdits par les certifications PCI-DSS, HDS, SecNumCloud.
Cas particuliers :
- mTLS (mutual TLS) : le client authentifie aussi le serveur via certificat. Standard pour les communications service-to-service en service mesh.
- WireGuard : VPN moderne basé sur cryptographie publique, plus simple qu’IPsec, performances excellentes.
- HTTPS partout : aucune raison en 2026 d’avoir du HTTP non chiffré, même en interne.
In-use — données en cours de traitement
Section intitulée « In-use — données en cours de traitement »Les données en cours de traitement sont en mémoire vive, dans les registres CPU, durant l’exécution. Historiquement déchiffrées, donc accessibles à l’OS hôte et à l’hyperviseur. C’est le maillon faible classique du modèle de chiffrement.
Émergent 2026 : le confidential computing chiffre les données en mémoire et exécute le code dans une enclave matérielle isolée du système hôte. Trois technologies dominent.
| Technologie | Vendor | Maturité 2026 |
|---|---|---|
| Intel SGX | Intel | Mature, mais surface limitée (enclaves de quelques Mo) |
| AMD SEV-SNP | AMD | Mature, VMs entières chiffrées |
| AWS Nitro Enclaves | AWS | Stack Nitro, isolement renforcé |
| Confidential VMs Azure / GCP | Azure / GCP | GA depuis 2023, basé sur AMD SEV-SNP |
Cas d’usage : traitement de données médicales sur cloud public, calcul multipartite (deux entreprises analysent des données conjointes sans se les dévoiler), key management distribué.
2. L’architecture en enveloppe — comment fonctionnent les KMS
Section intitulée « 2. L’architecture en enveloppe — comment fonctionnent les KMS »Tous les services KMS modernes (AWS KMS, Azure Key Vault, Google Cloud KMS, Outscale KMS) suivent la même architecture en enveloppe (envelope encryption). Comprendre cette architecture est essentiel pour raisonner clairement sur la sécurité.
Le mécanisme
Section intitulée « Le mécanisme »L’idée est de ne jamais utiliser la clé maître (KEK — Key Encryption Key) directement pour chiffrer les données. À la place, on génère une clé éphémère par fichier (DEK — Data Encryption Key), on l’utilise pour chiffrer les données, puis on chiffre la DEK avec la KEK.
┌─────────────────┐│ Données claires │└────────┬────────┘ │ │ Chiffrées avec DEK (AES-256) ▼┌─────────────────┐ ┌─────────────────┐│ Données chiffrées│ │ DEK chiffrée │└─────────────────┘ │ (chiffrée avec │ │ KEK via KMS) │ └─────────────────┘
Stockage côte à côte : ciphertext + DEK chiffréePourquoi ce schéma
Section intitulée « Pourquoi ce schéma »Quatre bénéfices majeurs.
Performance : la KEK reste dans le KMS (matériel HSM dédié). Le chiffrement réel est fait par la DEK locale, sans aller-retour réseau au KMS pour chaque octet.
Rotation aisée : pour rotater la KEK, il suffit de re-chiffrer les DEK avec la nouvelle KEK. Les données elles-mêmes ne sont pas re-chiffrées — opération rapide même sur des To de données.
Audit centralisé : toute opération de déchiffrement passe par le KMS qui logue l’appel. CloudTrail, Activity Log, Cloud Audit Logs voient toutes les utilisations de clé.
Séparation des responsabilités : l’application ne voit jamais la KEK, seulement les DEK temporaires. Compromettre l’application ne compromet pas les autres clés du KMS.
3. Les 4 modèles de gestion des clés
Section intitulée « 3. Les 4 modèles de gestion des clés »Selon qui contrôle la KEK, quatre modèles existent. Plus on monte dans le tableau, plus la confiance dans le fournisseur diminue, plus l’effort opérationnel augmente.
Modèle 1 — Provider-managed keys
Section intitulée « Modèle 1 — Provider-managed keys »La KEK est entièrement gérée par le fournisseur. Vous activez le chiffrement, le fournisseur s’occupe de tout — création, stockage, rotation.
| Service | Désignation | Gestion |
|---|---|---|
| AWS S3 | SSE-S3 | AWS gère tout |
| Azure Storage | Microsoft-managed keys | Azure gère tout |
| GCP Cloud Storage | Google-managed encryption keys | Google gère tout |
Avantages : zéro effort, zéro coût, activation transparente.
Inconvénients : vous n’avez pas la maîtrise de la clé. En théorie, le fournisseur peut déchiffrer vos données s’il y est légalement contraint (CLOUD Act, FISA — voir Souveraineté technologique de la stack).
Usage : données non sensibles, environnements de dev/test, projets où la simplicité prime.
Modèle 2 — Customer-managed KMS keys
Section intitulée « Modèle 2 — Customer-managed KMS keys »Vous créez et gérez vos KEK dans le service KMS du fournisseur (CMK). Vous contrôlez les permissions IAM, la rotation, la révocation.
| Service KMS | Fournisseur |
|---|---|
| AWS KMS | AWS, FIPS 140-2 Level 3 sur les régions standards |
| Azure Key Vault | Azure, modules HSM dédiés (Premium) |
| Google Cloud KMS | GCP, intégration Cloud HSM |
| Outscale KMS | Outscale, conforme SecNumCloud sur cloudgouv-eu-west-1 |
Avantages : vous contrôlez les permissions et la révocation. En cas de compromission, vous pouvez désactiver la KEK et toutes les données qui en dépendent deviennent illisibles.
Inconvénients : la KEK reste physiquement dans l’infrastructure du fournisseur. Le fournisseur peut techniquement y accéder s’il y est légalement contraint, malgré le HSM.
Usage : production standard, conformité de base (RGPD, ISO 27001).
Modèle 3 — BYOK (Bring Your Own Key)
Section intitulée « Modèle 3 — BYOK (Bring Your Own Key) »Vous générez la KEK dans votre propre HSM (sur site ou cloud HSM dédié), vous l’importez dans le KMS du fournisseur. Vous gardez une copie de la clé chez vous, le fournisseur l’utilise pour chiffrer/déchiffrer.
Avantages : meilleure traçabilité de l’origine de la clé. En cas de problème, vous pouvez révoquer côté fournisseur et continuer à déchiffrer chez vous.
Inconvénients : la KEK réside quand même dans le KMS du fournisseur après import. La protection légale réelle n’est pas significativement meilleure que CMK pure.
Usage : exigences réglementaires spécifiques (assurance, banque), conformité à des audits qui demandent la « propriété de la clé ».
Modèle 4 — HYOK (Hold Your Own Key) ou External Key Manager
Section intitulée « Modèle 4 — HYOK (Hold Your Own Key) ou External Key Manager »La KEK ne quitte jamais votre HSM externe. Le fournisseur cloud appelle votre HSM via API HTTPS pour chaque opération de déchiffrement. Vous pouvez couper l’accès à tout moment, et le fournisseur n’a aucun moyen de déchiffrer vos données sans votre infrastructure.
| Service | Fournisseur |
|---|---|
| AWS KMS External Key Store (XKS) | AWS, depuis 2022 |
| Azure Key Vault Managed HSM + intégration externe | Azure |
| GCP External Key Manager (EKM) | GCP, depuis 2020 |
| Thales CipherTrust Cloud Key Manager | Solution tierce multi-cloud |
Avantages : souveraineté maximale. Le fournisseur ne peut techniquement pas déchiffrer sans votre coopération.
Inconvénients : complexité opérationnelle élevée, latence supplémentaire (chaque déchiffrement = appel réseau à votre HSM), HSM externe coûteux, point de défaillance supplémentaire.
Usage : données ultra-sensibles, exigences de souveraineté technologique (SecNumCloud niveau supérieur, secret défense).
4. Comparaison synthétique des 4 modèles
Section intitulée « 4. Comparaison synthétique des 4 modèles »| Critère | Provider-managed | Customer KMS | BYOK | HYOK |
|---|---|---|---|---|
| Effort opérationnel | Aucun | Faible | Moyen | Élevé |
| Coût | Inclus | KMS facturé (~1 €/clé/mois + utilisation) | KMS + HSM externe | HSM externe + bande passante |
| Souveraineté juridique | Faible | Moyenne | Moyenne | Élevée |
| Souveraineté technique | Faible | Faible | Faible | Maximale |
| Performance | Native | Native | Native | Latence réseau ajoutée |
| Disponibilité | SLA fournisseur | SLA fournisseur | SLA fournisseur | Dépend de votre HSM |
5. Patterns d’application concrets
Section intitulée « 5. Patterns d’application concrets »Chiffrement at-rest sur S3 (exemple AWS)
Section intitulée « Chiffrement at-rest sur S3 (exemple AWS) »# SSE-S3 (provider-managed) — par défautaws s3api put-bucket-encryption \ --bucket monbucket \ --server-side-encryption-configuration '{ "Rules": [{ "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "AES256" } }] }'
# SSE-KMS (customer-managed via AWS KMS)aws s3api put-bucket-encryption \ --bucket monbucket \ --server-side-encryption-configuration '{ "Rules": [{ "ApplyServerSideEncryptionByDefault": { "SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "alias/maClef" } }] }'La différence en facture est typiquement de l’ordre de 5 à 10 €/mois par bucket actif — négligeable comparé au gain de contrôle.
Chiffrement in-transit avec mTLS
Section intitulée « Chiffrement in-transit avec mTLS »Sur un service mesh comme Istio ou Linkerd, mTLS est automatique entre tous les pods sans modification du code applicatif. C’est l’un des arguments majeurs de service mesh pour les architectures microservices.
apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata: name: default namespace: productionspec: mtls: mode: STRICT # mTLS obligatoire pour tous les pods du namespaceConfidential VM sur Azure
Section intitulée « Confidential VM sur Azure »az vm create \ --resource-group monRG \ --name monVM-confidential \ --image Canonical:0001-com-ubuntu-confidential-vm-jammy:22_04-lts-cvm:latest \ --size Standard_DC2as_v5 \ --security-type ConfidentialVM \ --enable-vtpm true \ --enable-secure-boot trueLe surcoût d’une Confidential VM est de l’ordre de +15 à 20 % vs une VM standard équivalente. Acceptable pour des workloads sensibles, prohibitif pour des workloads génériques.
6. Comment choisir un modèle de gestion des clés
Section intitulée « 6. Comment choisir un modèle de gestion des clés »Le choix entre provider-managed, customer-managed, BYOK et HYOK dépend du niveau de contrôle souhaité, des obligations réglementaires applicables, et de la capacité opérationnelle à gérer les clés. Aucun modèle n’est meilleur dans l’absolu — ils répondent à des besoins différents.
Quand le provider-managed suffit. Pour une grande partie des charges (sites web vitrine, applications internes non critiques, données publiques ou peu sensibles), le provider-managed offre le meilleur compromis : chiffrement activé par défaut, aucune opération de rotation à gérer, coût nul. Si l’analyse de risque ne fait pas apparaître de contrainte particulière, ce modèle reste le défaut acceptable.
Quand passer au customer-managed. Dès que des données personnelles RGPD ou des secrets métier entrent en jeu, le customer-managed KMS apporte un bénéfice clair : possibilité de révoquer la clé, journal d’audit séparé, rotation maîtrisée. Le coût supplémentaire reste faible (de l’ordre de quelques euros par mois et par clé), et la friction opérationnelle est limitée. Ce modèle est aujourd’hui considéré comme une bonne pratique pour les charges traitant des données sensibles.
Comprendre les limites du BYOK. Le BYOK (Bring Your Own Key) consiste à importer une clé générée chez soi dans le KMS du fournisseur. Une fois importée, la clé réside physiquement dans le KMS et son cycle de vie est, en pratique, similaire au customer-managed standard. Le BYOK apporte donc un bénéfice limité par rapport au customer-managed pour un coût opérationnel comparable. Il a un sens lorsqu’une obligation réglementaire spécifique demande une preuve de provenance externe de la clé.
Quand HYOK devient nécessaire. Le HYOK (Hold Your Own Key) maintient la clé dans un HSM externe contrôlé par le client, le fournisseur cloud ne pouvant déchiffrer les données sans cette clé. Ce modèle protège contre des risques juridiques extraterritoriaux : si les données ne doivent jamais pouvoir être déchiffrées sans le consentement explicite du propriétaire, HYOK est la seule réponse technique. Le coût opérationnel est réel (latence, HSM externe à exploiter) et doit être mis en balance avec le niveau de protection visé. Sur les domaines sensibles (défense, certaines données de santé, secrets industriels stratégiques), ce modèle est parfois la seule option compatible avec les obligations applicables.
À retenir
Section intitulée « À retenir »- 3 états du chiffrement : at-rest (stockage), in-transit (réseau), in-use (mémoire).
- AES-256 at-rest est standard 2026 chez tous les fournisseurs, activé par défaut.
- TLS 1.3 in-transit est le minimum acceptable, mTLS pour les communications service-to-service critiques.
- Confidential computing (SGX, SEV-SNP) émerge pour le chiffrement in-use sur cloud public.
- Architecture en enveloppe universelle : KEK chiffre DEK, DEK chiffre données. Performance, rotation, audit, séparation.
- 4 modèles de gestion des clés du provider-managed (zéro effort) au HYOK (souveraineté technique maximale).
- Le modèle de gestion des clés se choisit selon le niveau de contrôle souhaité et les obligations applicables : provider-managed acceptable par défaut, customer-managed pour données sensibles, HYOK quand l’extraterritorialité est un sujet.