Bezpieczne delegowanie tworzenia ról

Zespoły pracują szybciej, gdy mogą tworzyć własne role i polityki IAM, ale nieograniczony dostęp do IAM jest niebezpieczny: deweloper mógłby przyznać sobie uprawnienia administratora. Wyzwaniem jest umożliwienie zespołom tworzenia ról przy jednoczesnym zagwarantowaniu, że role te pozostaną w bezpiecznych granicach. Granice uprawnień to umożliwiają — jest to często sprawdzany scenariusz egzaminacyjny.

Bez zabezpieczeń przyznanie komuś iam:CreateRole i iam:AttachRolePolicy jest w praktyce równoznaczne z przyznaniem mu uprawnień administratora. Taka osoba może utworzyć rolę z AdministratorAccess i przyjąć ją. Tę ścieżkę eskalacji uprawnień należy zamknąć w ramach bezpiecznego delegowania, jednocześnie zachowując możliwość prawidłowego tworzenia ról.

Rozwiązanie polega na wymaganiu, aby każda rola tworzona przez delegowanego użytkownika miała dołączoną określoną granicę uprawnień. Nawet jeśli użytkownik dołączy do nowej roli AdministratorAccess, granica ograniczy jej efektywne uprawnienia. Utworzona rola nigdy nie przekroczy zakresu dozwolonego przez granicę, co neutralizuje ryzyko eskalacji.

Bezpieczna polityka delegowania wykorzystuje dwa sprawdzenia warunków: jedno gwarantuje, że nowa rola ma wymaganą granicę (za pomocą iam:PermissionsBoundary), a drugie uniemożliwia użytkownikowi modyfikowanie lub usuwanie samej granicy. Oba są potrzebne, ponieważ pomysłowy deweloper mógłby po prostu usunąć granicę później.

Ten warunek wymusza dołączanie wskazanej granicy do każdego wywołania CreateRole. Bez niej działanie tworzenia zostanie odrzucone.

Należy także uniemożliwić delegowanemu użytkownikowi edytowanie polityki granicy lub odłączanie jej od ról. Należy dodać jawne instrukcje Deny dla działań takich jak iam:DeleteRolePermissionsBoundary i iam:CreatePolicyVersion, skierowane przeciwko ARN granicy. W przeciwnym razie zabezpieczenie można po cichu usunąć, niwecząc cały projekt.

Polityki delegowania często ograniczają ścieżkę lub nazewnictwo ról, które użytkownik może tworzyć, na przykład zezwalają na tworzenie wyłącznie w /developers/. Umieszcza to role w znanej przestrzeni nazw, ułatwia ich audyt i zapobiega ingerencji w uprzywilejowane role znajdujące się w innym miejscu konta.

Nawet w przypadku granicy należy sprawdzić politykę zaufania nowej roli. Deweloper mógłby utworzyć rolę, której ufa zewnętrzne konto. Należy ograniczyć podmioty, które mogą zostać ustawione jako zaufane, albo połączyć delegowanie z SCP i Access Analyzer, aby wykrywać i blokować nieoczekiwane zaufanie zewnętrzne.

Prawidłowo wdrożone delegowanie zapewnia zespołom rzeczywistą samodzielność: mogą one swobodnie tworzyć role i zarządzać nimi w granicach, a zespół bezpieczeństwa może mieć pewność, że żadna rola nie przekroczy ustalonego limitu. Ta równowaga między szybkością a bezpieczeństwem jest dokładnie tym, co należy zaprojektować na egzaminie SCS-C02.

W środowiskach obejmujących wiele kont należy łączyć granice dla poszczególnych tożsamości z obowiązującymi dla całych kont SCP. SCP wyznacza górny limit dla całego konta, a granice doprecyzowują ograniczenia dla poszczególnych delegowanych użytkowników. Warstwowe zastosowanie obu mechanizmów zapewnia obronę w głąb, dzięki czemu luka w jednej kontroli jest wychwytywana przez drugą.

Bezpieczne delegowanie tworzenia ról wymaga: wymagania granicy uprawnień dla każdej tworzonej roli, ochrony granicy przed modyfikacją lub usunięciem za pomocą jawnych odmów, ograniczenia ścieżek i nazw oraz ograniczenia zaufania w nowych rolach. W przypadku górnych limitów dla całych kont należy zastosować warstwę SCP. Pozwala to zamknąć ścieżki eskalacji uprawnień, zachowując samodzielność zespołów.

Bezpieczne delegowanie tworzenia ról IAM oznacza wymaganie granicy uprawnień dla każdej tworzonej roli za pomocą warunku iam:PermissionsBoundary, odmawianie zmian tej granicy, ograniczanie ścieżek i nazw ról oraz ograniczanie polityk zaufania nowych ról. Należy połączyć je z SCP wyznaczającymi górne limity dla całych kont, aby zamknąć ścieżki eskalacji uprawnień i jednocześnie umożliwić samodzielną obsługę.