AWS KMS : Clé Gérée AWS ou CMK pour chiffrer votre bucket S3 ?

Vous venez de créer un bucket S3 contenant des données sensibles et la console vous demande de choisir entre une clé gérée par AWS et une clé gérée par le client. Ce choix semble anodin, mais en production, il détermine qui contrôle réellement vos données, ce que vous payez chaque mois, et ce qui se passe si une clé est désactivée par erreur.

Résumé (TL;DR) : AWS KMS et chiffrement S3

Critère	Clé Gérée AWS (aws/s3)	Clé Gérée Client (CMK)
Création et rotation	Automatique, gérée par AWS	Manuelle ou automatique selon config
Contrôle des politiques	Aucun contrôle direct	Politique de clé personnalisable
Audit CloudTrail	Partiel (appels S3 visibles)	Complet (chaque appel KMS tracé)
Coût mensuel	Gratuit	Voir tarification officielle AWS KMS
Partage inter-comptes	Non supporté	Supporté via politique de clé
Désactivation possible	Non	Oui (risque opérationnel réel)

Comment fonctionne AWS KMS avec S3

AWS KMS ne chiffre pas directement vos objets S3. Il génère et protège des clés de données (data keys) que S3 utilise pour le chiffrement effectif. Ce modèle s'appelle le chiffrement d'enveloppe (envelope encryption) : chaque objet est chiffré avec une clé de données unique, et cette clé de données est elle-même chiffrée par votre clé KMS. S3 stocke la clé de données chiffrée aux côtés de l'objet.

À chaque lecture d'objet, S3 appelle KMS pour déchiffrer la clé de données, puis utilise cette clé en mémoire pour déchiffrer l'objet. C'est pourquoi chaque opération GetObject génère un appel KMS facturable si vous utilisez une CMK.

sequenceDiagram participant Client participant S3 participant KMS Client->>S3: PutObject (données en clair) S3->>KMS: GenerateDataKey(CMK-ARN) KMS-->>S3: Clé de données (en clair + chiffrée) S3->>S3: Chiffre l'objet avec clé en clair S3->>S3: Stocke clé chiffrée dans métadonnées S3->>S3: Efface clé en clair de la mémoire S3-->>Client: 200 OK Client->>S3: GetObject S3->>KMS: Decrypt(clé de données chiffrée) KMS-->>S3: Clé de données en clair S3->>S3: Déchiffre l'objet S3-->>Client: Données déchiffrées

PutObject : S3 demande à KMS de générer une clé de données via GenerateDataKey. KMS retourne la clé en clair et sa version chiffrée.
Chiffrement : S3 chiffre l'objet avec la clé en clair, stocke la clé chiffrée dans les métadonnées de l'objet, puis efface la clé en clair de la mémoire.
GetObject : S3 extrait la clé de données chiffrée, appelle KMS (Decrypt) pour l'obtenir en clair, déchiffre l'objet, puis retourne les données au client.
Contrôle d'accès : Si l'appelant n'a pas la permission kms:Decrypt sur la clé, l'opération échoue même si les permissions S3 sont correctes.

Types de clés KMS disponibles pour S3

Avant de choisir, il faut comprendre les trois catégories de clés que KMS propose, car elles ne se comportent pas de la même façon.

Clés Gérées AWS (AWS Managed Keys)

Ces clés sont créées automatiquement par AWS pour votre compte lorsque vous activez le chiffrement SSE-KMS sans spécifier de clé. Pour S3, l'alias est aws/s3. Vous ne pouvez pas modifier leur politique, les désactiver, ni les supprimer. La rotation est automatique tous les ans. Elles sont gratuites, mais vous n'avez aucun levier de contrôle dessus.

Clés Gérées par le Client (Customer Managed Keys — CMK)

Vous créez et gérez ces clés. Vous définissez qui peut les utiliser via une politique de clé, vous pouvez activer la rotation annuelle automatique, les désactiver temporairement, ou planifier leur suppression. Chaque CMK a un coût mensuel fixe, et chaque appel cryptographique est facturé au-delà d'un seuil gratuit mensuel. Consultez la page de tarification officielle AWS KMS pour les valeurs actuelles.

Clés Détenues par AWS (AWS Owned Keys)

Ces clés appartiennent à AWS et sont partagées entre plusieurs comptes clients. Elles sont utilisées en arrière-plan par certains services AWS. Vous n'avez aucune visibilité dessus dans CloudTrail et elles ne correspondent pas à SSE-KMS — elles correspondent à SSE-S3 (AES-256 géré par S3). Ne pas les confondre avec les clés gérées AWS.

graph TD A["Chiffrement S3
Quel type de clé ?"] --> B{"Besoin de contrôle
ou conformité ?"}; B -- Non --> C["Clé Gérée AWS
aws/s3 — Gratuit"]; B -- Oui --> D{"Accès inter-comptes
ou audit complet ?"}; D -- Non --> E["CMK simple
Rotation auto activée"]; D -- Oui --> F["CMK + politique de clé
+ S3 Bucket Key"]; C --> G["SSE-KMS sans coût KMS"]; E --> H["SSE-KMS avec traçabilité"]; F --> I["SSE-KMS avec contrôle total"];

Quand utiliser une Clé Gérée AWS pour S3

La clé gérée AWS (aws/s3) convient si votre seul objectif est de satisfaire une exigence de chiffrement au repos sans contrainte de conformité avancée. Les cas typiques :

Données internes non soumises à audit externe (logs applicatifs, artefacts de build)
Environnements de développement et de test
Équipes sans expertise KMS dédiée
Budgets serrés où le coût des appels CMK est une contrainte réelle

Ce que vous perdez : la capacité à restreindre l'accès à la clé indépendamment des permissions S3, la traçabilité fine des appels cryptographiques dans CloudTrail, et tout scénario inter-comptes.

Quand utiliser une CMK pour S3

La CMK devient nécessaire dès que l'un de ces cas s'applique :

Conformité réglementaire (PCI-DSS, HIPAA, SOC 2) exigeant un audit complet des accès cryptographiques
Accès inter-comptes : un autre compte AWS doit lire vos objets S3 chiffrés
Séparation des droits : vous voulez qu'un administrateur S3 ne puisse pas déchiffrer les données sans permission KMS explicite
Révocation d'accès immédiate : désactiver la clé coupe l'accès aux données sans modifier les politiques S3
Rotation contrôlée ou intégration avec un système de gestion de clés externe (CloudHSM, import de matériel de clé)

La CMK agit comme un second verrou indépendant de S3. Même si quelqu'un obtient un accès S3 complet, sans permission kms:Decrypt sur la clé, les objets restent illisibles.

Coûts associés à AWS KMS — ce qu'il faut savoir

Les clés gérées AWS ne génèrent aucun coût KMS direct. Les CMK, en revanche, ont deux composantes tarifaires : un coût fixe mensuel par clé active, et un coût par appel cryptographique au-delà d'un quota gratuit mensuel. Les tarifs exacts varient par région et évoluent — vérifiez toujours la page de tarification officielle AWS KMS.

Ce qui surprend en production : avec un bucket S3 à fort trafic, chaque GetObject sur un objet chiffré avec une CMK génère un appel kms:Decrypt. Sur des millions d'objets lus par jour, la facture KMS peut dépasser le coût du stockage S3 lui-même. C'est le point que la plupart des équipes découvrent trop tard.

Pour les workloads à fort volume de lectures, évaluez si le cache de clés de données côté client (via AWS Encryption SDK) peut réduire le nombre d'appels KMS. Mais attention : cette approche sort du périmètre du chiffrement natif S3 et ajoute de la complexité opérationnelle.

Créer et configurer une CMK pour S3 — étapes pratiques

Étape 1 : Créer la CMK

Créez une clé symétrique KMS dédiée à votre bucket. L'option --enable-key-rotation active la rotation annuelle automatique du matériel de clé — recommandé pour tous les environnements de production.

aws kms create-key \
  --description "CMK pour bucket S3 donnees-sensibles" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS \
  --enable-key-rotation \
  --region us-east-1

Notez le KeyId retourné dans la réponse. Créez ensuite un alias lisible :

aws kms create-alias \
  --alias-name alias/s3-donnees-sensibles \
  --target-key-id <KeyId-retourné> \
  --region us-east-1

Étape 2 : Définir la politique de clé

La politique de clé est le mécanisme de contrôle d'accès primaire pour une CMK. Une politique mal configurée peut verrouiller l'accès à votre clé — y compris pour les administrateurs. Vérifiez que la politique inclut toujours une entrée permettant au compte root de gérer la clé en cas d'urgence.

🔽 Exemple de politique de clé KMS pour S3 (cliquer pour développer)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Acces administrateur compte root",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Acces lecture S3 pour role applicatif",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AppReadRole"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*"
    }
  ]
}

Appliquez cette politique à votre clé :

aws kms put-key-policy \
  --key-id alias/s3-donnees-sensibles \
  --policy-name default \
  --policy file://kms-policy.json \
  --region us-east-1

Étape 3 : Activer le chiffrement SSE-KMS sur le bucket S3

Configurez le chiffrement par défaut du bucket pour utiliser votre CMK. Tout objet uploadé sans spécification de clé utilisera automatiquement cette CMK.

aws s3api put-bucket-encryption \
  --bucket mon-bucket-sensible \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:alias/s3-donnees-sensibles"
        },
        "BucketKeyEnabled": true
      }
    ]
  }'

Notez l'option BucketKeyEnabled: true — c'est le point que beaucoup d'équipes manquent.

Étape 4 : Activer S3 Bucket Key pour réduire les coûts KMS

Sans S3 Bucket Key, chaque objet génère un appel KMS individuel. Avec S3 Bucket Key activé, S3 génère une clé de bucket temporaire à partir de votre CMK et l'utilise pour chiffrer les clés de données des objets localement — réduisant significativement le nombre d'appels KMS directs. Cette fonctionnalité est déjà incluse dans la commande ci-dessus via BucketKeyEnabled: true.

Vérifiez que S3 Bucket Key est bien actif :

aws s3api get-bucket-encryption \
  --bucket mon-bucket-sensible

Étape 5 : Vérifier les permissions IAM du rôle applicatif

Les permissions S3 seules ne suffisent pas avec SSE-KMS. Le rôle ou l'utilisateur qui lit ou écrit des objets doit aussi avoir les permissions KMS correspondantes. L'absence de kms:Decrypt produit une erreur AccessDenied qui ne mentionne pas KMS dans le message S3 — source de confusion fréquente en débogage.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/<votre-key-id>"
    }
  ]
}

Diagnostic d'une erreur AccessDenied avec SSE-KMS — expérience terrain

Symptôme observé : un pipeline CI/CD qui uploadait des artefacts dans S3 depuis des mois commence à retourner des erreurs 403 AccessDenied sur PutObject après une migration vers une CMK. Les logs S3 ne mentionnent pas KMS. L'équipe passe deux heures à vérifier les politiques de bucket et les ACL.

Mauvaise piste : la politique de bucket a été modifiée lors de la migration. L'équipe ajoute des permissions S3 supplémentaires — sans effet.

Cause réelle : le rôle IAM du pipeline n'avait pas kms:GenerateDataKey dans sa politique. S3 ne peut pas chiffrer l'objet sans générer une clé de données via KMS. L'erreur remonte comme une erreur S3 générique parce que c'est S3 qui initie l'appel KMS en coulisse — pas le client directement.

Vérification rapide pour isoler le problème :

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GenerateDataKey \
  --region us-east-1 \
  --max-results 10

Si l'appel GenerateDataKey apparaît avec un statut AccessDenied dans CloudTrail, la cause est confirmée : permission KMS manquante, pas un problème S3.

Avec une CMK, CloudTrail devient votre premier outil de diagnostic — pas la console S3. Chaque appel KMS refusé y est enregistré avec le principal demandeur et la raison.

Comprendre AWS KMS : forcer le chiffrement et auditer l'utilisation

Forcer l'utilisation de la CMK via politique de bucket

Même avec un chiffrement par défaut configuré, un client peut uploader un objet sans chiffrement ou avec une clé différente. Pour l'interdire, ajoutez une condition de refus dans la politique de bucket :

🔽 Politique de bucket forçant SSE-KMS avec CMK spécifique (cliquer pour développer)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Refuser upload sans CMK specifique",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::mon-bucket-sensible/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/<votre-key-id>"
        }
      }
    }
  ]
}

Auditer les appels KMS via CloudTrail

Vérifiez les appels cryptographiques récents sur votre clé pour détecter des accès inattendus :

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=<votre-key-id> \
  --region us-east-1 \
  --max-results 20

Conclusion et prochaines étapes — AWS KMS et chiffrement S3

Le choix entre clé gérée AWS et CMK n'est pas une question de sécurité absolue — les deux chiffrent vos données correctement. C'est une question de contrôle, d'auditabilité et de coût opérationnel. Si vous gérez des données soumises à conformité, partagez des données inter-comptes, ou avez besoin de révoquer l'accès indépendamment de S3, la CMK est la bonne option. Pour tout le reste, la clé gérée AWS fait le travail sans friction.

Activez systématiquement S3 Bucket Key dès que vous utilisez une CMK — c'est la mesure la plus simple pour contenir les coûts KMS sur des buckets à fort trafic.

Ressources officielles :

Glossaire des termes clés

Terme	Définition
CMK (Customer Managed Key)	Clé KMS créée et gérée par le client, avec politique de clé personnalisable.
Chiffrement d'enveloppe	Modèle où une clé de données chiffre les données, et une clé maître chiffre la clé de données.
S3 Bucket Key	Clé temporaire dérivée de la CMK, utilisée par S3 pour réduire les appels directs à KMS.
SSE-KMS	Chiffrement côté serveur S3 utilisant AWS KMS pour la gestion des clés.
Politique de clé	Document JSON attaché à une CMK définissant qui peut l'utiliser et pour quelles opérations.

📄 Variables d'environnement Lambda : injection de configuration et chiffrement KMS

Rechercher dans ce blog

SW BBANG F