Orion Retail slaat databasegegevens op in AWS Secrets Manager in Account B, versleuteld met een door de klant beheerde KMS-sleutel in Account B. Een microservice die draait in Account A (rol: arn:aws:iam::111111111111:role/OrdersAppRole) heeft alleen-lezen toegang nodig tot het geheim. Het team heeft een IAM-beleid aan de rol toegevoegd dat secretsmanager:GetSecretValue toestaat op de geheime ARN, maar ontvangt nog steeds AccessDenied-fouten van KMS. Wat moet het beveiligingsteam doen om least-privilege cross-account toegang te verlenen?

De correcte optie beschrijft de twee noodzakelijke stappen voor cross-account toegang tot een Secrets Manager-geheim dat versleuteld is met een door de klant beheerde KMS-sleutel. Ten eerste moet een resource-based beleid (resource policy) op het geheim in Account B de OrdersAppRole in Account A expliciet toestaan om secretsmanager:GetSecretValue uit te voeren. Ten tweede, omdat het geheim versleuteld is met een KMS-sleutel in Account B, moet het sleutelbeleid (key policy) van die KMS-sleutel de OrdersAppRole toestaan om kms:Decrypt uit te voeren. Zonder beide beleidsregels zal de toegang mislukken. De andere opties zijn onjuist: Het repliceren van het geheim naar Account A vermijdt cross-account permissies, maar is geen least-privilege oplossing en introduceert redundantie en synchronisatieproblemen. VPC interface-endpoints zijn voor netwerkconnectiviteit, niet voor autorisatie, en lossen het AccessDenied probleem van KMS niet op. Alleen het bijwerken van het IAM-beleid van de OrdersAppRole is onvoldoende. Voor cross-account toegang tot Secrets Manager en KMS-sleutels zijn resource-based beleidsregels op de resources zelf (het geheim en de KMS-sleutel) vereist om de toegang vanuit een ander account expliciet toe te staan.