Zasady zaufania i osoby mogące przyjąć rolę

Zasada zaufania to dokument dołączony do roli, który dokładnie określa, które podmioty główne mogą ją przyjąć. Pełni funkcję strażnika: nawet jeśli zasada uprawnień przyznaje szeroki dostęp, nikt nie może użyć roli, jeśli zasada zaufania go nie wymienia. Na egzaminie błędy w zasadach zaufania często powodują zarówno niedziałający dostęp, jak i niebezpieczne nadmierne uprawnienia.

Element Principal zasady zaufania może wskazywać:

• AWS — konto, użytkownika lub ARN roli (Amazon Resource Name).
• Service — usługę AWS, taką jak lambda.amazonaws.com.
• Federated — dostawcę SAML lub dostawcę tożsamości internetowej.

Wybór właściwego typu podmiotu głównego i precyzyjne jego określenie są niezbędne, aby uniknąć przyznania szerszego zaufania, niż zamierzono.

Przyjęcie roli między kontami wymaga zgody obu stron. Zasada zaufania roli na koncie docelowym musi zezwalać wywołującemu podmiotowi głównemu, a ten podmiot musi mieć zasadę tożsamości zezwalającą na wykonanie sts:AssumeRole względem ARN roli. Brak któregokolwiek z tych elementów blokuje żądanie. To dwustronne uzgodnienie jest klasyczną pułapką egzaminacyjną.

Ta zasada zaufania pozwala określonej roli na koncie 111122223333 przyjąć daną rolę. Wskazanie dokładnego ARN zamiast całego konta jest bardziej restrykcyjne i bezpieczniejsze.

Określenie podmiotu głównego jako arn:aws:iam::ACCOUNT:root oznacza zaufanie do całego konta: każdy podmiot na tym koncie, który ma również uprawnienie sts:AssumeRole, może przyjąć rolę. Jest to szerokie ustawienie. Jeśli to możliwe, należy wskazać dokładny ARN użytkownika lub roli, aby stosować zasadę najmniejszych uprawnień i ograniczyć obszar zaufania.

Zasady zaufania obsługują bloki Condition, które precyzują, kto i w jaki sposób może przyjąć rolę. Typowe klucze to sts:ExternalId (aby zapobiegać problemowi zdezorientowanego zastępcy), aws:MultiFactorAuthPresent (wymaganie MFA) oraz aws:SourceIp. Warunki pozwalają zezwolić na przyjęcie roli wyłącznie w określonych, możliwych do zweryfikowania okolicznościach.

Skutecznym rozwiązaniem jest wymaganie MFA przed przyjęciem roli o wysokich uprawnieniach. Warunek w zasadzie zaufania sprawdza, czy sesja wywołująca została uwierzytelniona za pomocą MFA. Oznacza to, że nawet skradzione długoterminowe dane uwierzytelniające nie wystarczą do przyjęcia uprzywilejowanej roli bez drugiego składnika, co znacznie podnosi poprzeczkę atakującym.

Niektóre role to role powiązane z usługą, wstępnie zdefiniowane przez AWS i wyposażone w zasadę zaufania, której nie można edytować. Pozwalają one usłudze zarządzać zasobami w Państwa imieniu, z dokładnie takim zakresem zaufania, jakiego wymaga AWS. Ich rozpoznawanie jest istotne, ponieważ ich uprawnienia i zaufanie są ściśle kontrolowane oraz powiązane z cyklem życia usługi.

Zaufanie do wewnętrznego podmiotu głównego (na tym samym koncie) wiąże się zazwyczaj z mniejszym ryzykiem niż zaufanie do zewnętrznego konta lub dostawcy SaaS będącego stroną trzecią. W przypadku zaufania zewnętrznego należy zawsze połączyć konkretny podmiot główny z warunkami, takimi jak ExternalId. Każde zewnętrzne oświadczenie dotyczące zaufania należy traktować jako punkt wejścia, który atakujący z chęcią spróbuje wykorzystać.

IAM Access Analyzer automatycznie sprawdza zasady zaufania i zasady zasobów, aby znaleźć role, które mogą być przyjmowane przez zewnętrzne konta lub publicznie. Oznacza niezamierzone zaufanie między kontami lub zaufanie publiczne, aby mogli je Państwo zaostrzyć. Przeglądanie ustaleń Access Analyzer jest zalecaną i istotną z punktu widzenia egzaminu kontrolą, która pomaga wykrywać zbyt szerokie zaufanie.

Aby bezpiecznie zaprojektować zaufanie, należy wskazać możliwie najbardziej konkretny podmiot główny, dodać w razie potrzeby warunki, takie jak ExternalId i MFA, preferować role zamiast zaufania do konta root oraz przeprowadzić przegląd za pomocą Access Analyzer. Należy pamiętać, że zasada zaufania odpowiada na pytanie kto, a zasady uprawnień na pytanie co; oba elementy muszą być zgodne, aby dostęp działał i nadal spełniał zasadę najmniejszych uprawnień.

Proszę sprawdzić swoją wiedzę na temat zasad zaufania.

Zasada zaufania określa, które podmioty główne mogą przyjąć rolę, i pełni funkcję strażnika niezależnie od zasad uprawnień. Przyjęcie roli między kontami wymaga dwustronnego uzgodnienia: zasady zaufania oraz uprawnienia sts:AssumeRole wywołującego. Należy preferować konkretne ARN podmiotów głównych zamiast root konta, dodawać warunki, takie jak ExternalId i MFA, oraz przeprowadzać audyt za pomocą IAM Access Analyzer.