Amazon SCS-C02: Chiffrement, KMS et secrets — Guide d'étude
Fait partie du AWS Security Specialty SCS-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.
Types de clés, politiques et contrôle d’accès AWS KMS
AWS KMS prend en charge trois grandes catégories de clés, et le choix de la bonne catégorie détermine qui contrôle le matériel de clé, où il réside et comment il peut être alterné. Les clés appartenant à AWS (AWS-owned keys) sont invisibles pour vous, ne coûtent rien et sont utilisées par des services comme S3 lorsque vous activez SSE-S3. Les clés gérées par AWS (AWS-managed keys), avec l’alias aws/<service>, permettent à un service de chiffrer en votre nom, mais vous ne pouvez pas modifier leur politique de clé, ce qui les rend inadaptées à l’accès inter-comptes ou à une gouvernance affinée. Les clés gérées par le client (CMK) sont le pilier central : vous contrôlez la politique de clé, la rotation (annuelle automatique ou à la demande), les grants, les alias et la fenêtre de suppression.
Deux variantes spécialisées sont importantes. Le matériel de clé importé est utilisé lorsque des exigences réglementaires ou BYOK (Bring Your Own Key) vous obligent à générer le matériel de clé en dehors d’AWS et à l’importer dans une clé KMS. Le matériel importé est le seul moyen de configurer une expiration explicite du matériel de clé — les CMK générées par AWS n’expirent jamais. Vous ne pouvez pas activer la rotation annuelle automatique d’AWS sur les clés importées ; vous devez réimporter le matériel vous-même. Les clés multi-régions partagent le même ID de clé et le même matériel entre les régions via des clés répliquées, ainsi, un texte chiffré produit dans us-east-1 peut être déchiffré dans us-west-1 sans re-chiffrement. Chaque réplique a sa propre politique de clé et ses propres alias indépendants, mais le matériel cryptographique est synchronisé.
Le contrôle le plus souvent mal compris est la politique de clé KMS. Contrairement à la plupart des ressources AWS où les politiques IAM suffisent à accorder l’accès, les clés KMS utilisent leur politique de clé comme autorisation racine. Une politique IAM accordant kms:Decrypt sur une clé est inerte à moins que la politique de clé ne délègue également l’accès à IAM (via un Principal correspondant à la racine du compte avec une déclaration appropriée, ou en nommant directement le principal). C’est pourquoi un ingénieur avec AdministratorAccess peut toujours recevoir une erreur AccessDenied en appelant Decrypt sur une CMK dont la politique ne fait pas confiance au compte. La déclaration de délégation canonique ressemble à ceci :
{
"Sid": "EnableIAMPermissions",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "kms:*",
"Resource": "*"
}
Les grants et les conditions ViaService ajoutent des restrictions en couches — forçant par exemple une clé à n’être utilisée qu’à travers S3 dans une région spécifique avec kms:ViaService: s3.us-east-1.amazonaws.com.
Chiffrement côté serveur et côté client
Pour S3, les deux options courantes de chiffrement côté serveur diffèrent principalement en termes de contrôle et d’auditabilité :
- SSE-S3 (AES-256) : S3 gère entièrement les clés ; il n’y a pas de politique de clé visible par le client, pas d’événements de déchiffrement par clé dans CloudTrail, et pas de gouvernance inter-comptes. Adéquat pour un chiffrement au repos de base, mais insuffisant lorsque la conformité exige de prouver qui a déchiffré les données.
- SSE-KMS : Utilise une CMK que vous contrôlez ; chaque appel de déchiffrement est journalisé, la politique de clé applique l’accès, et vous pouvez restreindre par contexte de chiffrement. Le coût par requête est plus élevé et consomme les quotas de TPS de KMS, il faut donc activer les clés de compartiment (
BucketKeyEnabled: true) pour réduire considérablement les appels à KMS.
Le chiffrement côté client utilisant le AWS Encryption SDK est approprié lorsque les données doivent être chiffrées avant de quitter l’application, ou lorsque le service de stockage ne doit jamais voir le texte en clair. Les charges de travail à haut débit devraient envelopper le SDK avec le gestionnaire de matériaux cryptographiques avec mise en cache (CachingCryptoMaterialsManager), qui réutilise les clés de données pour de nombreux messages dans des limites configurables d’octets, de messages et de TTL. Sans mise en cache, chaque appel à encrypt déclenche une requête GenerateDataKey, saturant rapidement les quotas de requêtes KMS et augmentant les coûts.
from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
master_key_provider=mkp, cache=cache,
max_age=600.0, max_messages_encrypted=10000)
Secrets Manager et Parameter Store
Secrets Manager stocke les informations d’identification chiffrées avec une CMK KMS et prend en charge la rotation automatique via une fonction Lambda — AWS fournit des modèles pour RDS, Redshift et DocumentDB, et des Lambdas personnalisées gèrent tout le reste. La rotation exécute une machine à états en quatre étapes (createSecret, setSecret, testSecret, finishSecret) qui prépare les nouvelles informations d’identification sous l’étiquette AWSPENDING avant de les promouvoir en AWSCURRENT. Les applications doivent intercepter les échecs d’authentification, rafraîchir le secret et réessayer — ce modèle élimine les temps d’arrêt car les informations d’identification précédentes restent brièvement valides via AWSPREVIOUS.
Lorsque la Lambda de rotation s’exécute dans un VPC (typiquement pour atteindre une instance RDS privée), elle a besoin d’un accès réseau sortant vers le point de terminaison du service Secrets Manager. Dans un VPC privé sans NAT, vous devez déployer un point de terminaison d’interface VPC (com.amazonaws.<region>.secretsmanager) et autoriser le groupe de sécurité de la Lambda à atteindre le point de terminaison sur le port 443. Oublier cela est une erreur classique : la rotation semble configurée mais chaque invocation expire (timeout).
Pour la résilience inter-régions, utilisez une clé KMS multi-régions et la fonctionnalité de secret répliqué de Secrets Manager. Le secret principal dans us-east-1 est chiffré avec la CMK principale ; la réplique dans us-west-1 déchiffre en utilisant la CMK répliquée. Des alias comme alias/prod-db peuvent être pointés vers un nouvel ID de clé à la demande pour une rotation rapide des clés sans modifier le code de l’application.
Le type SecureString de Parameter Store est une alternative légère lorsque vous n’avez pas besoin de rotation. Les deux services exposent des références dynamiques dans CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}) afin que les modèles de pile n’intègrent jamais de texte en clair.
Chiffrement EBS, RDS, Aurora et Snapshot
Le chiffrement au repos est activé par volume ou par instance au moment de la création et ne peut pas être modifié sur place. Le modèle de remédiation pour une ressource non chiffrée et non conforme est une copie de snapshot avec chiffrement :
aws ec2 copy-snapshot --source-snapshot-id snap-abc \
--source-region us-east-1 --encrypted \
--kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...
Pour RDS et Aurora, restaurez le snapshot chiffré dans une nouvelle instance et basculez dessus. La restauration inter-comptes nécessite de partager le snapshot et d’accorder au compte de destination les permissions kms:CreateGrant et kms:Decrypt sur la CMK via la politique de clé — le simple partage du snapshot échouera car la destination ne peut pas déchiffrer la clé de données. Le chiffrement par défaut d’EBS au niveau du compte doit être activé afin que les volumes nouvellement créés soient toujours chiffrés, quel que soit le comportement de l’appelant.
TLS : Politiques ACM et ALB
ACM émet et renouvelle automatiquement et sans frais les certificats publics lorsqu’ils sont liés à des services intégrés (ALB, CloudFront, API Gateway). Les certificats ne peuvent pas être exportés, donc le TLS terminé sur EC2 nécessite soit ACM Private CA (pour les certificats privés que vous pouvez exporter), soit un certificat importé. Un modèle pragmatique : terminer le TLS public au niveau de l’ALB avec un certificat ACM, et utiliser un certificat auto-signé ou issu d’une CA privée pour le segment entre l’ALB et l’EC2 si un chiffrement de bout en bout est requis. Forcez les clients à utiliser des chiffrements modernes avec une politique de sécurité telle que ELBSecurityPolicy-TLS13-1-2-2021-06, qui désactive TLS 1.0/1.1 et les suites de chiffrement faibles.
Pièges courants
IAM sans politique de clé. Accorder kms:Decrypt dans une politique IAM alors que la politique de clé de la CMK omet le principal du compte produit une erreur AccessDenied. KMS considère la politique de clé comme faisant autorité ; les permissions IAM ne peuvent que restreindre davantage ce que la politique de clé autorise.
Lambda de rotation sans point de terminaison VPC. Si la fonction Lambda s’exécute dans des sous-réseaux privés et que le VPC n’a ni NAT ni point de terminaison d’interface secretsmanager, l’appel de rotation vers secretsmanager.<region>.amazonaws.com ne peut pas être résolu ou se connecter. Le groupe de sécurité du point de terminaison doit également autoriser le port 443 depuis le groupe de sécurité de la Lambda.
SSE-S3 assimilé à SSE-KMS. SSE-S3 utilise une clé appartenant à AWS sans politique modifiable par le client, sans journalisation du déchiffrement par objet dans CloudTrail, et sans partage de clé entre comptes. Il satisfait les exigences de base du « chiffrement au repos », mais ne peut pas imposer quels principaux peuvent déchiffrer des objets spécifiques — seul SSE-KMS avec une CMK offre cette gouvernance.
Problème pratique : Scénario d’utilisation
Scénario : Meridian Financial gère une AWS Organization multi-comptes avec un compte de sécurité, des comptes Prod/NonProd séparés, des microservices derrière un ALB dans ECS/EKS, des clusters RDS/Aurora, des instances EC2 avec des volumes EBS, et des lacs de données S3. Les développeurs et l’automatisation utilisent actuellement un mélange de clés gérées par AWS, de paramètres SSM en texte clair, et de partages manuels occasionnels de snapshots entre les comptes.
Défi : Un ingénieur a accidentellement partagé un snapshot RDS non chiffré avec un compte tiers et plusieurs identifiants d’API ont été découverts stockés en texte clair dans des paramètres SecureString, créant un risque d’exfiltration de données et d’accès non autorisé à la restauration.
Approche recommandée :
- Créer une CMK symétrique gérée par le client (customer-managed) AWS KMS dans le compte de sécurité, avec une portée au niveau de l’organisation, une politique de clé accordant l’utilisation via aws:PrincipalOrgID aux comptes membres et activer la rotation automatique ; utiliser des grants pour les opérations inter-comptes de courte durée.
- Remédier aux artefacts existants en copiant le snapshot RDS non chiffré et tous les snapshots EBS tout en sélectionnant la nouvelle CMK pour produire des copies chiffrées, puis supprimer les snapshots originaux non chiffrés ; définir les paramètres par défaut du compte pour que les nouvelles ressources RDS et EBS soient chiffrées par défaut.
- Migrer les secrets vers AWS Secrets Manager (ou SSM Parameter Store SecureString) chiffrés avec la CMK, activer la rotation automatique de Secrets Manager pour les identifiants de base de données via Lambda, et restreindre l’accès en utilisant des politiques basées sur les ressources et des rôles IAM de moindre privilège.
- Appliquer le chiffrement en transit en provisionnant des certificats TLS gérés par ACM et en les attachant aux ALB avec une politique TLS moderne (TLS 1.2/1.3), et configurer les bases de données et les clients pour exiger des connexions TLS.
- Prévenir la récurrence avec des garde-fous (guardrails) : appliquer des Service Control Policies (SCP) pour refuser la création/le partage de snapshots non chiffrés et les opérations Put non chiffrées sur S3, activer les règles AWS Config pour les ressources chiffrées, et surveiller l’utilisation de KMS et de Secrets Manager via CloudTrail et des alarmes CloudWatch.
Justification : Des CMK centralisées avec des politiques au niveau de l’organisation, le re-chiffrement automatisé, Secrets Manager pour le cycle de vie des secrets, l’application du TLS et des garde-fous préventifs suivent les meilleures pratiques AWS de moindre privilège et de défense en profondeur pour éliminer les secrets en texte clair et l’accès non autorisé aux snapshots.
CMK gérées par le client : multi-région, matériel importé et stratégies de clé
Une CMK gérée par le client est le plan de contrôle pour chaque opération cryptographique sur les données que vous possédez dans AWS. Les trois propriétés qui déterminent le plus souvent si une conception réussit ou provoque une panne sont la topologie régionale de la clé, l’origine de son matériel de clé et la stratégie qui y est attachée.
Les clés multi-régions sont un ensemble de clés KMS dans différentes régions qui partagent le même ID de clé et, surtout, le même matériel de clé sous-jacent. Elles ne sont pas répliquées automatiquement comme le sont les tables globales DynamoDB — vous créez explicitement des réplicas à partir d’une clé primaire en utilisant ReplicateKey. Comme le matériel de clé est identique entre les réplicas, un texte chiffré produit dans us-east-1 peut être déchiffré dans us-west-1 sans appels KMS inter-régionaux. C’est exactement la propriété requise lors de la réplication d’un secret Secrets Manager entre les régions : le secret réplica dans la région de basculement (failover) doit pouvoir être déchiffré localement, à la fois pour éliminer la latence inter-régionale sur chaque GetSecretValue et pour survivre à une panne régionale du primaire. Une CMK mono-région ne peut pas prendre en charge un réplica Secrets Manager dans une autre région, donc le modèle correct consiste à chiffrer le secret primaire avec une CMK multi-région, à répliquer la clé dans la région de destination, puis à répliquer le secret en pointant vers la CMK réplica.
aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
--replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
--secret-id prod/db \
--add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123
Le matériel de clé importé (origine externe, Origin=EXTERNAL) existe lorsque vous générez le matériel brut AES-256 en dehors d’AWS et que vous l’importez dans une coquille de clé KMS (key shell). AWS ne conserve jamais de copie de ce matériel en dehors de la mémoire protégée du HSM, et il n’y a aucune sauvegarde. Si vous supprimez le matériel importé — que ce soit via DeleteImportedKeyMaterial ou parce que sa date d’expiration est passée — la clé passe à l’état PendingImport et tout texte chiffré produit avec cette clé est irrécupérable à moins que vous ne réimportiez exactement les mêmes octets. C’est le chemin de récupération lorsque, par exemple, un volume EBS ne parvient pas à s’attacher parce que sa clé de données chiffrée ne peut pas être déchiffrée : réimportez le matériel de clé identique depuis votre dépôt hors ligne (offline escrow), et le volume redevient utilisable. Il n’y a pas de restauration côté AWS, pas d’astuce de rotation, et aucun ticket de support ne peut récupérer le matériel importé supprimé. Traitez la copie hors ligne comme une infrastructure de niveau zéro (tier-zero).
Les stratégies de clé sont la racine de confiance (root of trust) pour chaque clé KMS. Contrairement à IAM seul, KMS exige une autorisation explicite (allow) dans la stratégie de clé elle-même ; une stratégie IAM accordant kms:Decrypt est inefficace à moins que la stratégie de clé ne délègue à IAM ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} combiné avec une déclaration conditionnelle). Pour une utilisation inter-comptes, la stratégie de la clé doit nommer explicitement le compte ou le principal externe, et le compte externe doit ensuite accorder à ses propres utilisateurs la permission via IAM. Oublier la partie relative à la stratégie de clé est la cause la plus fréquente des échecs de Secrets Manager en inter-comptes — la stratégie de ressource de Secrets Manager autorise le principal externe à appeler GetSecretValue, mais le Decrypt sous-jacent échoue car la CMK refuse toujours l’appelant.
Modèles d’utilisation de Secrets Manager et Parameter Store SecureString
Secrets Manager et les SecureStrings de SSM Parameter Store délèguent tous deux le chiffrement à KMS, mais ils diffèrent en termes de coût, de sémantique de rotation et de comportement inter-régional. Secrets Manager prend en charge la réplication multi-région native, le versionnage avec des étiquettes de préproduction (staging labels) (AWSCURRENT, AWSPENDING), et la rotation basée sur Lambda. Parameter Store SecureString est moins cher, s’intègre avec des chemins hiérarchiques, et fonctionne bien pour les secrets de type configuration qui sont rarement renouvelés.
Pour l’accès inter-comptes, vous devez mettre à jour à la fois la stratégie de ressource sur le secret (ou la stratégie IAM dans le compte consommateur de Parameter Store) et la stratégie de clé KMS sur la CMK de chiffrement. Supposer que les permissions de Secrets Manager seules sont suffisantes est une erreur, car le flux de travail de récupération effectue toujours un kms:Decrypt implicite sur la CMK ; sans une autorisation (allow) dans la stratégie de clé pour le compte externe, l’appelant reçoit une AccessDeniedException à l’étape Decrypt même si la propre stratégie du secret est satisfaite.
- Secrets Manager : rotation gérée, structure JSON, ~$0.40/secret/mois, réplication multi-région intégrée
- Parameter Store SecureString (Advanced) : moins cher pour de nombreuses valeurs, 8 Ko par paramètre, pas de réplication inter-régionale intégrée
- Parameter Store SecureString (Standard) : niveau gratuit pour les paramètres chiffrés par KMS jusqu’à 4 Ko, pas de cadre de rotation
Chiffrement d’enveloppe, clés de compartiment et jetons d’autorisation
Le chiffrement d’enveloppe signifie que KMS ne touche jamais vos données en vrac. Vous appelez GenerateDataKey, qui retourne à la fois une clé de données en texte clair (utilisée localement pour chiffrer votre charge utile avec AES-GCM) et une copie chiffrée de cette clé de données (stockée à côté du texte chiffré). Pour déchiffrer, vous appelez Decrypt sur la clé de données encapsulée et redérivez localement la clé en texte clair. Ce modèle est essentiel car KMS a des quotas de requêtes (par région, par clé) et une tarification par appel d’API. Si vous chiffrez chaque enregistrement de 4 Ko avec un appel Encrypt direct, vous atteindrez des limites de régulation (throttling) et des pics de coûts ; si vous générez une seule clé de données par lot ou par fichier, le débit évolue de manière linéaire avec votre bibliothèque de cryptographie locale.
Les clés de compartiment S3 (S3 Bucket Keys) appliquent le même principe au sein de S3 pour SSE-KMS. Sans clé de compartiment, chaque PUT et GET d’un objet SSE-KMS génère un appel GenerateDataKey ou Decrypt. Sur un compartiment recevant des milliers d’objets par seconde, cela entraîne à la fois une régulation (throttling) de KMS et une facture KMS surprenante. L’activation d’une clé de compartiment amène S3 à générer une clé éphémère au niveau du compartiment et à la réutiliser pour de nombreux objets, réduisant le volume de requêtes KMS de plusieurs ordres de grandeur :
aws s3api put-bucket-encryption --bucket app-data \
--server-side-encryption-configuration '{
"Rules":[{
"ApplyServerSideEncryptionByDefault":{
"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
"BucketKeyEnabled":true}]}'
Les autorisations (Grants) sont une alternative aux stratégies de clé pour une délégation temporaire et affinée. Elles sont importantes sur le plan opérationnel en raison de la cohérence à terme (eventual consistency) : après le retour de CreateGrant, l’autorisation n’est pas immédiatement visible par tous les points de terminaison KMS de la région. Si un client tente un Encrypt quelques millisecondes plus tard, il peut recevoir une AccessDeniedException. Le corps de la réponse de CreateGrant inclut une chaîne GrantToken qui, lorsqu’elle est transmise lors des appels KMS ultérieurs via le paramètre --grant-tokens, force KMS à honorer l’autorisation immédiatement, quel que soit l’état de propagation.
TOKEN=$(aws kms create-grant --key-id $KEY \
--grantee-principal arn:aws:iam::111122223333:role/worker \
--operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
--grant-tokens "$TOKEN"
S’appuyer sur une nouvelle tentative avec backoff exponentiel (retry-with-backoff) au lieu du jeton d’autorisation est une atténuation valide mais inférieure — cela gaspille de la latence et échoue toujours sous charge. La réponse canonique est toujours : retourner le jeton d’autorisation depuis le service qui crée l’autorisation, et exiger des appelants qu’ils le présentent lors de leur première opération.
Problème pratique : Scénario d’utilisation
Scénario : Meridian Financial exploite un environnement AWS multi-comptes hébergeant des informations personnelles identifiables (PII) de clients dans S3, des bases de données transactionnelles dans RDS et des traitements sans serveur via Lambda. Ils utilisent des clés CMK gérées par le client avec du matériel de clé importé pour respecter les règles régionales de conservation des clés et répliquent les clés dans une deuxième région pour la reprise après sinistre.
Défi : Un audit récent a révélé une stratégie de clé KMS mal configurée qui autorisait les déchiffrements inter-comptes, et un auditeur externe a besoin d’un accès temporaire pour déchiffrer un sous-ensemble d’objets S3 ; Meridian a également besoin d’une rotation sécurisée des secrets et d’un chiffrement efficace pour les objets volumineux afin de maîtriser les coûts des requêtes KMS.
Approche recommandée :
- Effectuer la rotation de la stratégie de la CMK mal configurée dans AWS KMS vers une stratégie de moindre privilège qui n’accorde explicitement que les principaux et les rôles IAM requis, et créer une réplique de CMK multi-régions pour la reprise après sinistre (DR) en utilisant les clés multi-régions de KMS.
- Réimporter ou planifier la gestion du cycle de vie pour le matériel de clé importé conformément aux fenêtres de conformité et activer les notifications automatiques d’expiration/rotation du matériel de clé à l’aide d’AWS Config et d’EventBridge.
- Pour l’auditeur, créer une autorisation (grant) KMS avec une courte durée de vie (TTL) et utiliser immédiatement le jeton d’autorisation (grant token) dans la session assume-role de l’auditeur pour permettre des opérations de déchiffrement temporaires sans modifier la stratégie de clé.
- Déplacer les informations d’identification à longue durée de vie dans AWS Secrets Manager avec une rotation basée sur Lambda liée au service sous-jacent (clés RDS ou API) et stocker les paramètres d’infrastructure en tant que SecureString dans Systems Manager Parameter Store pour les éléments sans rotation, en appliquant le chiffrement avec la CMK et des stratégies strictes basées sur les ressources.
- Mettre en œuvre le chiffrement d’enveloppe pour les objets S3 volumineux en appelant KMS
GenerateDataKey(Encrypt/Decrypt) dans le code de l’application ou via le SDK AWS, et activer les clés de compartiment S3 (S3 Bucket Keys) pour réduire les requêtes KMS et le coût du chiffrement côté serveur des objets volumineux. - Activer la journalisation CloudTrail et la journalisation de l’utilisation des clés KMS, et créer des alarmes CloudWatch/règles GuardDuty pour alerter en cas de déchiffrements inattendus ou de créations d’autorisations (grants).
Justification : Cette approche applique un accès aux clés selon le principe du moindre privilège, préserve la conformité pour le matériel importé et la continuité multi-régions, utilise des autorisations temporaires pour un accès tiers sécurisé, centralise les secrets avec rotation, et optimise l’utilisation et les coûts de KMS conformément aux meilleures pratiques AWS.
← Journalisation · Tous les domaines · Protection des données et S3 →
Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Réussissez votre examen →