2.2 - Chiffrement et autorisation (KMS, enveloppe, Deny explicite)
L'objectif 2.2 de l'AWS Certified Developer Associate couvre le chiffrement et l'autorisation pour les développeurs. Le chiffrement enveloppe chiffre une grande charge avec une clé de données, et cette clé de données est elle-même chiffrée par une clé KMS - efficace car on n'appelle KMS que pour la petite clé, pas toute la charge. Quand un développeur doit signer numériquement des messages et laisser d'autres les vérifier avec une clé publique, une clé KMS asymétrique configurée pour signer et vérifier est l'outil. Tu dois aussi connaître l'évaluation des politiques : quand deux politiques IAM s'appliquent, l'une autorisant s3:GetObject et l'autre avec un Deny explicite, l'accès est refusé car un Deny explicite l'emporte toujours sur tout Allow. Tu dois aussi connaître les politiques de clés KMS, les grants et le cache de clés de données. Attends-toi à des mises en situation demandant le bon mécanisme ou résultat.
Chiffrer une grande charge avec une clé de données que KMS chiffre = chiffrement enveloppe. Signer + vérifier avec une clé publique = clé KMS asymétrique. Allow + Deny explicite = le Deny gagne toujours.
Questions d'entraînement
1. Quelle technique chiffre une grosse charge utile avec une clé de données elle-même chiffrée par une clé KMS ?
- Chiffrement enveloppe (bonne réponse)
- Épinglage de certificat client
- Génération d'URL signée
- Hachage de mot de passe
Dans le chiffrement enveloppe, KMS génère une clé de données : vous chiffrez les données avec la clé de données en clair, puis stockez la clé de données chiffrée par KMS à côté. Seul KMS peut déchiffrer la clé de données.
2. Quelle affirmation sur l'évaluation des politiques IAM est correcte ?
- Un Deny explicite l'emporte toujours sur tout Allow (bonne réponse)
- Un Allow explicite l'emporte sur un Deny explicite
- L'accès est autorisé par défaut sans aucune politique
- Les politiques de ressource sont ignorées si un rôle existe
L'évaluation IAM est refus par défaut ; un Allow accorde l'accès, mais tout Deny explicite l'emporte toujours. Cet ordre sous-tend les garde-fous comme les SCP et les politiques de bucket.
3. Une application du compte A doit lire un bucket S3 du compte B. Quel modèle accorde l'accès le plus sûrement, sans clés de longue durée ?
- Copier les clés d'accès du compte B dans le compte A
- Rendre le bucket public avec une politique large
- Assumer un rôle IAM du compte B via STS AssumeRole (bonne réponse)
- Envoyer par e-mail une URL pré-signée pour chaque objet
L'accès inter-comptes se fait en définissant un rôle dans le compte B qui fait confiance au compte A, puis en appelant STS AssumeRole pour obtenir des identifiants temporaires. Cela évite de partager des clés durables et de rendre le bucket public.
4. Un secret chiffré par KMS doit être déchiffré par une Lambda dont le rôle d'exécution a kms:Decrypt, mais l'appel est refusé. Qu'est-ce qui doit probablement aussi autoriser le rôle ?
- Le réglage de concurrence réservée de la Lambda
- Un délai de fonction plus grand pour l'appel KMS
- Une passerelle Internet VPC pour le sous-réseau
- La politique de clé KMS accordant l'accès au rôle (bonne réponse)
L'accès KMS nécessite à la fois une permission IAM et une politique de clé autorisant le principal. La politique de clé fait autorité pour la clé KMS : même avec kms:Decrypt en IAM, la politique de clé (ou un grant) doit aussi autoriser le rôle.
5. Quelle opération KMS renvoie à la fois une clé de données en clair et sa copie chiffrée, pour le chiffrement enveloppe de grosses données ?
- Encrypt avec la clé KMS directement
- CreateGrant sur la clé KMS
- GenerateDataKey sur la clé KMS (bonne réponse)
- DescribeKey pour les métadonnées de la clé KMS
GenerateDataKey renvoie une clé de données en clair (pour chiffrer les données localement) et cette même clé chiffrée sous la clé KMS (à stocker). C'est le coeur du chiffrement enveloppe ; l'API Encrypt directe est limitée à 4 Ko.
6. Une équipe veut plafonner les permissions maximales qu'un rôle IAM de développeur peut avoir, même si de larges politiques sont attachées. Quelle fonctionnalité impose ce plafond ?
- Une politique basée sur la ressource sur chaque service
- Une politique en ligne dupliquée sur le rôle
- Un plus grand ensemble de politiques gérées attachées
- Une limite de permissions (permissions boundary) sur le rôle IAM (bonne réponse)
Une limite de permissions est une politique gérée qui définit les permissions maximales d'une identité ; les permissions effectives sont l'intersection de la limite et de ses politiques. Elle ne peut qu'imposer un plafond, jamais accorder.