Nordic Bio exécute une fonction Lambda dans le compte A qui doit chiffrer des données à l'aide d'une clé KMS dans le compte B. En raison de contraintes de plateforme, le code Lambda ne peut pas assumer un rôle dans un autre compte. Que doit faire l'équipe de sécurité pour activer ce chiffrement inter-comptes sans modifier le code ?

La bonne réponse est de mettre à jour la politique de clé KMS dans le compte B et d'ajouter des autorisations au rôle d'exécution Lambda dans le compte A. Pour l'accès inter-comptes à une clé KMS, la politique de clé KMS (dans le compte propriétaire de la clé) doit explicitement autoriser l'entité du compte externe à effectuer des opérations KMS. De plus, l'entité appelante (le rôle Lambda dans le compte A) doit avoir les autorisations correspondantes attachées à sa politique d'identité. Cette approche permet une autorisation granulaire sans modifier le code Lambda. Les autres options sont incorrectes : Créer un point de terminaison d'interface VPC pour KMS dans le compte B n'est pas directement lié à l'autorisation d'accès inter-comptes à la clé KMS. Cela améliore la connectivité privée, mais ne gère pas les autorisations. Ajouter une relation d'approbation à la clé KMS n'est pas la méthode standard pour accorder des autorisations inter-comptes pour les clés KMS. La politique de clé est le mécanisme principal. Partager la clé KMS via AWS Resource Access Manager (RAM) n'est pas applicable aux clés KMS. RAM est utilisé pour partager certains types de ressources, mais pas les clés KMS elles-mêmes.