Jak SCP łączą się z uprawnieniami IAM

Dostęp w organizacji jest kontrolowany przez dwie warstwy: limit SCP ustalany przez AWS Organizations oraz uprawnienia IAM nadane na koncie. Zrozumienie ich współdziałania jest jednym z najczęściej sprawdzanych zagadnień w obszarze zarządzania, ponieważ wynik zależy od zgodności obu warstw.

Reguła jest prosta, ale rygorystyczna: działanie jest dozwolone tylko wtedy, gdy zezwalają na nie zarówno odpowiednie SCP, jak i polityki IAM konta. Efektywne uprawnienie jest ich częścią wspólną. SCP bez odpowiadającego mu zezwolenia IAM niczego nie nadaje; zezwolenie IAM zablokowane przez SCP również niczego nie nadaje.

Jeśli SCP zezwala na działanie, ale żadna polityka IAM go nie nadaje, wynik jest odmowny z powodu niejawnej odmowy IAM. SCP jedynie sprawiło, że działanie stało się możliwe; IAM nadal musi faktycznie na nie zezwolić. Wielu uczących się zapomina, że SCP wyznacza limit, a nie nadaje uprawnienia.

Odwrotnie, jeśli polityka IAM zezwala na działanie, ale SCP go zabrania, wynik jest odmowny. Odmowa zawarta w SCP ogranicza konto niezależnie od tego, jak szerokie uprawnienia nadaje IAM. W ten sposób organizacja wymusza twarde ograniczenia, których lokalni administratorzy nie mogą obejść.

Żądanie jest dozwolone tylko wtedy, gdy zarówno SCP, jak i polityka IAM zezwalają na działanie oraz nigdzie nie występuje jawna odmowa. Ta logika części wspólnej odpowiada zasadzie działania granic uprawnień; obie mechanizmy mogą obowiązywać jednocześnie i dodatkowo zawężać uprawnienia.

W środowisku w pełni objętym zarządzaniem nakłada się na siebie kilka limitów: SCP (na poziomie konta), permission boundary (na poziomie tożsamości), ewentualna session policy (na poziomie sesji) oraz identity policy (nadająca uprawnienia). Efektywne uprawnienie jest częścią wspólną wszystkich limitów powiększoną o nadane uprawnienia i pomniejszoną o każdą jawną odmowę.

Wyobraźmy sobie politykę IAM nadającą s3:* i ec2:*, granicę uprawnień zezwalającą wyłącznie na s3:* oraz SCP zezwalające tylko na s3:GetObject. Efektywne uprawnienie obejmuje jedynie s3:GetObject, czyli część wspólną wszystkich trzech warstw. Każdy kolejny limit dodatkowo zawęża uprawnienia.

W każdej warstwie jawna odmowa zawarta w dowolnej polityce, SCP, granicy, sesji, tożsamości lub zasobie natychmiast blokuje działanie. Żadna kombinacja zezwoleń nie może jej nadpisać. Analizując scenariusz, należy najpierw wyszukać jawną odmowę; jeśli występuje, odpowiedź brzmi: odmowa.

Polityki oparte na zasobach mogą niezależnie nadać dostęp w obrębie tego samego konta, ale SCP nadal ograniczają konto podmiotu. W przypadku dostępu między kontami obowiązują mechanizmy kontroli obu kont oraz polityki po obu stronach. Zasada części wspólnej zostaje rozszerzona, ale jej sedno pozostaje takie samo: każdy mający zastosowanie limit musi zezwalać na działanie.

Gdy dostęp w organizacji niespodziewanie nie działa, należy sprawdzać kolejne warstwy od zewnątrz: potwierdzić, że polityka tożsamości nadaje uprawnienie do działania, następnie sprawdzić granicę uprawnień, potem SCP na koncie i w każdym nadrzędnym OU, dalej ewentualną politykę sesji, a na końcu wyszukać jawną odmowę we wszystkich warstwach. Winny jest pierwszy limit, który nie obejmuje działania, lub dowolna odmowa.

SCP i IAM łączą się przez część wspólną: działanie wymaga zezwolenia z obu źródeł, a także przejścia przez limity granicy i sesji, bez jawnej odmowy w żadnym miejscu. SCP i granice uprawnień jedynie ograniczają; polityki IAM nadają uprawnienia. Aby zezwolić na działanie, każdy limit musi je dopuszczać i musi istnieć co najmniej jedno źródło nadanego uprawnienia.

Sprawdź logikę łączenia uprawnień.

SCP i IAM łączą się przez część wspólną: działanie jest dozwolone tylko wtedy, gdy zezwalają na nie oba mechanizmy, a także odpowiednie limity permission boundary i session policy, przy braku jawnej odmowy w dowolnym miejscu. SCP i granice uprawnień tylko ograniczają; polityki IAM nadają uprawnienia. Jawna odmowa w dowolnej warstwie zawsze ma pierwszeństwo przed każdym zezwoleniem.