Orion Retail przechowuje poświadczenia bazy danych w AWS Secrets Manager w Koncie B, zaszyfrowane kluczem KMS zarządzanym przez klienta w Koncie B. Mikroserwis działający w Koncie A (rola: arn:aws:iam::111111111111:role/OrdersAppRole) potrzebuje dostępu tylko do odczytu do sekretu. Zespół dodał politykę IAM do roli, zezwalającą na secretsmanager:GetSecretValue dla ARN sekretu, ale nadal otrzymuje błędy AccessDenied z KMS. Co powinien zrobić zespół ds. bezpieczeństwa, aby udzielić dostępu między kontami z najmniejszymi uprawnieniami?

Poprawna odpowiedź wymaga dwóch kroków, ponieważ dostęp między kontami do zaszyfrowanych sekretów Secrets Manager obejmuje zarówno uprawnienia Secrets Manager, jak i KMS. Dołączenie polityki opartej na zasobach do sekretu w Koncie B, zezwalającej OrdersAppRole na secretsmanager:GetSecretValue, umożliwia dostęp do samego sekretu. Dodatkowo, ponieważ sekret jest zaszyfrowany kluczem KMS zarządzanym przez klienta, polityka klucza KMS w Koncie B musi zostać zaktualizowana, aby zezwolić OrdersAppRole na kms:Decrypt. Bez tego drugiego kroku, nawet jeśli rola ma dostęp do sekretu, nie będzie mogła odszyfrować jego wartości, co skutkuje błędem AccessDenied z KMS. Pozostałe opcje są nieprawidłowe: Replikowanie sekretu do Konta A jest obejściem, a nie rozwiązaniem problemu dostępu między kontami i zwiększa złożoność zarządzania. Tworzenie punktów końcowych interfejsu VPC jest przydatne do prywatnej łączności, ale nie rozwiązuje problemu uprawnień do zasobów między kontami. Aktualizacja tylko polityki IAM OrdersAppRole o kms:Decrypt jest niewystarczająca, ponieważ polityka oparta na zasobach sekretu również musi zezwalać na dostęp.