Une entreprise utilise AWS Organizations pour gérer plusieurs comptes et traite un volume important de données sensibles. Les données sont stockées dans Amazon S3 et Amazon DynamoDB, et sont accédées par des fonctions AWS Lambda et des services conteneurisés sur Amazon EKS sur AWS Fargate. L'entreprise doit chiffrer toutes les données au repos et appliquer le principe du moindre privilège pour l'accès aux données. L'entreprise a créé une clé AWS KMS gérée par le client. Que doit faire l'entreprise ensuite pour répondre à ces exigences ?

La bonne approche consiste à restreindre l'accès à la clé KMS et à appliquer le chiffrement. La politique de clé KMS doit autoriser kms:Decrypt uniquement aux services qui ont besoin d'accéder aux données chiffrées (S3, DynamoDB, Lambda, EKS), garantissant ainsi le principe du moindre privilège. Une SCP (Service Control Policy) est essentielle pour empêcher la création de nouvelles ressources (buckets S3, tables DynamoDB) qui ne sont pas chiffrées avec la clé KMS spécifiée, renforçant ainsi la conformité au chiffrement à l'échelle de l'organisation. Les autres options sont moins efficaces : Restreindre kms:Decrypt uniquement à S3 et DynamoDB est trop restrictif, car Lambda et EKS ont également besoin de déchiffrer les données. Utiliser une politique IAM pour refuser kms:Decrypt et une fonction Lambda planifiée est une approche réactive et complexe, moins robuste qu'une politique de clé préventive. Une règle AWS Config n'alerte que sur les non-conformités existantes, elle ne prévient pas leur création, ce qui est moins efficace qu'une SCP.