Wiele zespołów programistycznych wdraża produkcyjne obciążenia robocze na współdzielonym koncie produkcyjnym AWS. Niedawno członkowie jednego zespołu programistycznego zakończyli działanie instancji EC2 należącej do innego zespołu. Deweloperzy używają federacji SAML za pośrednictwem AWS Organizations do przyjmowania ról. Musisz uniemożliwić deweloperom zarządzanie instancjami należącymi do innych zespołów, jednocześnie pozwalając im zarządzać własnymi instancjami. Która strategia spełnia te wymagania?

Poprawna odpowiedź wykorzystuje tagi sesji AWS STS i polityki IAM oparte na atrybutach (ABAC), aby zapewnić precyzyjną kontrolę dostępu. Przekazanie atrybutu DevelopmentUnit jako tagu sesji pozwala na dynamiczne przypisanie tożsamości użytkownika. Polityka IAM z warunkiem StringNotEquals dla tagu zasobu DevelopmentUnit i aws:PrincipalTag/DevelopmentUnit skutecznie uniemożliwia deweloperom zarządzanie zasobami, które nie są oznaczone jako należące do ich jednostki. Pierwsza niepoprawna opcja, używająca SCP z StringNotEquals na poziomie OU, jest mniej elastyczna i może być trudna do zarządzania w przypadku wielu zespołów na współdzielonym koncie. Trzecia opcja, używająca SCP z allow i StringEquals, nie zapewniłaby mechanizmu blokującego dostęp do zasobów innych zespołów, a raczej zezwalałaby tylko na dostęp do własnych, co nie jest wystarczające, aby zapobiec przypadkowemu usunięciu. Czwarta opcja, tworzenie oddzielnych polityk IAM dla każdej jednostki, jest skalowalna, ale nie wykorzystuje w pełni dynamicznych możliwości ABAC z tagami sesji, co jest bardziej efektywne w środowisku z wieloma zespołami.