Chiffrement S3 : réglages par défaut, clés KMS et contrôles

Amazon S3 chiffre par défaut les nouveaux objets au repos. Le choix porte surtout sur le contrôle des clés, les autorisations nécessaires à l’application et la vérification du chiffrement d’un objet précis.

Ce guide compare SSE-S3, SSE-KMS et DSSE-KMS, puis présente un test SSE-KMS pour un bucket S3 à usage général. Il aborde aussi SSE-C et le chiffrement côté client. Les buckets de répertoire ont d’autres restrictions et ne sont pas couverts par cet exemple. Les commandes ont été vérifiées localement à partir des modèles d’entrée du SDK AWS, sans être exécutées sur un compte AWS.

Ce que protège le chiffrement S3

Avec le chiffrement côté serveur, S3 chiffre les données pour leur stockage et les déchiffre lors d’un téléchargement autorisé. Le chiffrement au repos ne remplace ni les contrôles d’accès ni HTTPS pour le transport. Un lecteur disposant des autorisations nécessaires peut récupérer le contenu d’origine.

Le chiffrement par défaut du bucket et les métadonnées de chiffrement d’un objet répondent à deux questions différentes. Le premier indique ce que S3 applique à un nouvel envoi sans choix explicite de chiffrement. Les secondes indiquent ce qu’utilise un objet donné. Modifier la valeur par défaut ne réécrit pas les objets existants.

Comparer SSE-S3, SSE-KMS et DSSE-KMS

Option	Gestion des clés	Motif pratique	Point d’exploitation
SSE-S3	Amazon S3 gère les clés.	Chiffrement automatique au repos sans gérer les autorisations KMS.	Pas de stratégie de clé KMS gérée par le client.
SSE-KMS	AWS KMS, avec une clé gérée par AWS ou par le client.	Une clé gérée par le client permet de contrôler sa stratégie d’accès et son cycle de vie.	Prévoir les autorisations, frais de requêtes et quotas KMS.
DSSE-KMS	KMS et S3 appliquent deux couches indépendantes.	Répondre à une exigence documentée de double chiffrement côté serveur.	Frais supplémentaires ; les clés de compartiment S3 ne sont pas prises en charge.

SSE-S3 est la base pour les nouveaux envois. SSE-KMS apporte des choix de gestion des clés, tandis que DSSE-KMS ajoute une seconde couche. Choisissez selon les besoins d’accès et de gestion des clés de la charge de travail. Le mode de chiffrement seul ne démontre pas la conformité.

SSE-C et chiffrement côté client : deux mécanismes distincts

Avec SSE-C, vous fournissez une clé avec les requêtes concernées et S3 effectue le chiffrement. Depuis avril 2026, SSE-C est bloqué pour les nouveaux buckets à usage général et pour les buckets existants des comptes sans objet chiffré avec SSE-C. Les applications qui en ont besoin doivent l’activer explicitement. Ce n’est pas un mode de chiffrement par défaut du bucket.

Avec le chiffrement côté client, l’application chiffre le contenu avant son envoi. S3 reçoit des données chiffrées. Il faut prévoir l’accès des clients autorisés aux clés et la récupération des données. Choisir SSE-KMS seul ne fournit pas ce modèle.

Préparer un petit test SSE-KMS

Utilisez un bucket de test vide à usage général et une clé KMS symétrique gérée par le client, dans la même Région AWS. L’exemple utilise eu-west-1. Remplacez partout le nom du bucket, l’identifiant de compte, la Région et l’ARN de clé avant toute exécution. Utilisez une version actuelle d’AWS CLI prenant en charge les champs ci-dessous.

Confirmez votre identité, examinez la clé et conservez la configuration actuelle du bucket :

aws sts get-caller-identity
aws kms describe-key --key-id arn:aws:kms:eu-west-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab --region eu-west-1
aws s3api get-bucket-encryption --bucket amzn-s3-demo-encryption --expected-bucket-owner 123456789012 --region eu-west-1

Vérifiez que la clé est activée et destinée au chiffrement symétrique. L’identité de test doit disposer des droits S3 nécessaires pour la configuration, l’écriture et la lecture, ainsi que des droits permettant de décrire et d’utiliser la clé KMS. Vérifiez IAM et la stratégie de clé. Pour cet exercice d’envoi et de téléchargement, autorisez les opérations nécessaires kms:GenerateDataKey et kms:Decrypt sur cette clé.

N’utilisez pas une destination de journaux d’accès serveur : AWS exige SSE-S3 pour cette destination. N’appliquez pas l’exemple à un bucket applicatif partagé sans examiner ses règles de chiffrement, ses clients d’écriture et ses stratégies.

Définir puis relire le chiffrement par défaut

Enregistrez le document suivant sous encryption.json. Il choisit SSE-KMS, active une clé de compartiment S3 et bloque explicitement les nouvelles écritures SSE-C. Remplacez l’ARN fictif par celui de votre clé de test.

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:eu-west-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"
      },
      "BucketKeyEnabled": true,
      "BlockedEncryptionTypes": {
        "EncryptionType": [
          "SSE-C"
        ]
      }
    }
  ]
}

La commande put-bucket-encryption écrit la configuration fournie dans le fichier. Relisez-la après application :

aws s3api put-bucket-encryption --bucket amzn-s3-demo-encryption --server-side-encryption-configuration file://encryption.json --expected-bucket-owner 123456789012 --region eu-west-1
aws s3api get-bucket-encryption --bucket amzn-s3-demo-encryption --expected-bucket-owner 123456789012 --region eu-west-1

Comparez l’algorithme, l’ARN complet, l’option Bucket Key et les types bloqués avec le fichier. La documentation de l’API précise que S3 ne valide pas l’identifiant de clé KMS lors de la définition du chiffrement par défaut d’un bucket à usage général. Une réponse de configuration réussie ne prouve donc pas que l’envoi ou la lecture fonctionnera.

Comprendre l’option Bucket Key

Les clés de compartiment S3 réduisent les requêtes de S3 vers KMS pour SSE-KMS. Les économies dépendent des demandeurs et des accès, sans constituer une remise fixe sur le stockage. Le contexte de chiffrement KMS utilise alors l’ARN du bucket plutôt que celui de l’objet. Examinez les stratégies fondées sur un contexte propre à l’objet avant d’activer cette option. DSSE-KMS ne la prend pas en charge.

Envoyer un échantillon et vérifier l’objet

Créez un petit fichier local encryption-check.txt contenant du texte sans données sensibles. Cette requête put-object omet les en-têtes de chiffrement pour tester la valeur par défaut :

aws s3api put-object --bucket amzn-s3-demo-encryption --key encryption-check/sample.txt --body encryption-check.txt --if-none-match "*" --expected-bucket-owner 123456789012 --region eu-west-1

L’option --if-none-match "*", avec ses guillemets, évite l’écrasement ordinaire d’une clé déjà présente. Un statut 412 indique l’échec de cette précondition : choisissez une nouvelle clé de test et utilisez-la dans toutes les commandes suivantes. L’envoi peut aussi échouer si une stratégie exige des en-têtes de chiffrement explicites. Testez alors séparément le comportement prévu du client au lieu de retirer cette stratégie.

Examinez les métadonnées de chiffrement de l’objet :

aws s3api head-object --bucket amzn-s3-demo-encryption --key encryption-check/sample.txt --expected-bucket-owner 123456789012 --region eu-west-1 --query "{Algorithm:ServerSideEncryption,Key:SSEKMSKeyId,BucketKey:BucketKeyEnabled}"

Les valeurs attendues sont aws:kms, l’ARN complet de votre clé et BucketKey: true. Il s’agit de résultats attendus, pas de la sortie d’un déploiement effectué par nos soins. La référence HeadObject décrit les champs. N’envoyez pas d’en-têtes de chiffrement destinés à l’écriture dans une requête HEAD SSE-KMS.

Récupérez ensuite l’objet avec l’identité prévue pour la lecture, en utilisant un autre profil CLI si l’application emploie des rôles distincts :

aws s3api get-object --bucket amzn-s3-demo-encryption --key encryption-check/sample.txt --expected-bucket-owner 123456789012 --region eu-west-1 downloaded-encryption-check.txt

Comparez le contenu téléchargé avec l’original. Une vérification des métadonnées ne remplace pas une lecture réussie avec les droits du lecteur réel. Conservez ensemble la clé de test, l’identité, le chiffrement attendu et le résultat pour permettre de reproduire le contrôle.

Une valeur par défaut n’impose pas une règle à tous les clients

Dans un bucket à usage général, une requête demandant explicitement un autre chiffrement autorisé peut remplacer le choix par défaut. Si tous les clients doivent utiliser une même clé KMS, examinez ensemble le comportement du chiffrement par défaut et la stratégie du bucket.

Une stratégie exigeant des en-têtes peut rejeter une requête qui aurait autrement hérité du bon chiffrement. Testez les clients réels, les intégrations de services et l’envoi multipart. Notre guide des bucket policies S3 explique les actions, ressources et conditions. Ne remplacez pas une stratégie complète sans préserver ses instructions existantes.

Traiter les objets existants séparément

AWS propose désormais UpdateObjectEncryption pour les objets admissibles : passage de SSE-S3 à SSE-KMS, changement de clé KMS ou activation des Bucket Keys, sans copier le contenu. Les objets source non chiffrés, chiffrés avec SSE-C ou DSSE-KMS, ou soumis à une rétention Object Lock ou à un legal hold sont exclus. Examinez les restrictions de version, de compte et de réplication avant une migration. Ne retirez pas de protection de conservation pour exécuter cet exemple.

Identifiez les versions à modifier. Notre guide des versions S3 explique pourquoi la version courante et les précédentes demandent une attention distincte. Vérifiez un petit ensemble représentatif avant toute opération en masse et conservez un rapport de traitement.

La réplication chiffrée a aussi ses exigences de configuration et d’autorisations. Consultez la documentation AWS sur les objets chiffrés avec notre guide de réplication S3. Vérifiez le chiffrement de la copie et les droits du lecteur. Modifier le chiffrement de la source ne prouve pas que la destination a été mise à jour.

Diagnostiquer les échecs avant d’élargir les droits

• Configuration réussie, envoi en échec : vérifiez l’ARN complet, la Région, l’état de la clé, les droits d’écriture et les refus explicites.
• Envoi réussi, lecture en échec : vérifiez les droits S3 du lecteur et le déchiffrement KMS, y compris les exigences entre comptes.
• Un ancien objet utilise la précédente clé : examinez cet objet ou cette version ; une nouvelle valeur par défaut ne le migre pas.
• Les envois SSE-C renvoient 403 : examinez les types de chiffrement bloqués avant de conclure à une erreur de stratégie d’objet.
• Les frais KMS dépassent les attentes : vérifiez le volume de requêtes, l’admissibilité aux Bucket Keys et les accès réels avant d’estimer les économies.

Conservez la clé tant que des objets, versions ou copies de récupération en dépendent. La documentation de suppression des clés explique pourquoi retirer une clé nécessaire peut rendre les données irrécupérables. Un contrôle utile porte sur la configuration enregistrée et sur une lecture autorisée, avec les responsabilités de gestion et de récupération des clés documentées.