Eskalacja uprawnień AWS IAM: techniczny pentest i hardening

Eskalacja uprawnień AWS IAM nie jest pojedynczą podatnością ani listą „niebezpiecznych akcji”. To wynik złożenia polityk tożsamości, polityk zasobów, relacji zaufania ról, granic uprawnień, polityk organizacji i możliwości przekazania roli usłudze AWS. Dobry pentest IAM odpowiada zatem nie tylko na pytanie „co ta tożsamość może wywołać?”, lecz przede wszystkim: jaki najwyższy skutek może osiągnąć przez dozwolony łańcuch działań i w jakich warunkach kontrola ma go zatrzymać.

Najbezpieczniejsza metoda łączy analizę grafu uprawnień, walidację polityk, kontrolowane testy w odizolowanym koncie oraz obserwację CloudTrail. Nie trzeba tworzyć trwałego administratora ani pobierać danych produkcyjnych. Wystarczy uzgodniony dowód, na przykład możliwość przyjęcia roli testowej z nieszkodliwym uprawnieniem, wraz z pełnym śladem audytowym i procedurą cofnięcia zmian.

Najważniejsza odpowiedź: kiedy IAM pozwala na eskalację

Do eskalacji dochodzi, gdy tożsamość o ograniczonym poziomie zaufania może zmienić własny efektywny zestaw uprawnień, wpłynąć na bardziej uprzywilejowaną tożsamość albo uruchomić usługę z rolą, której sama nie może bezpośrednio przyjąć. Źródłem problemu może być pojedyncza szeroka polityka, lecz częściej jest nim ścieżka z kilku pozornie uzasadnionych uprawnień.

Typowe klasy ścieżek obejmują:

• zmianę polityki zarządzanej, polityki inline, członkostwa w grupie lub permissions boundary;
• modyfikację trust policy roli albo warunków umożliwiających sts:AssumeRole;
• utworzenie lub aktualizację poświadczeń innej tożsamości;
• przekazanie uprzywilejowanej roli przez iam:PassRole do usługi wykonującej kontrolowany kod lub zadanie;
• zmianę kodu, obrazu, konfiguracji startowej albo automatyzacji zasobu działającego z mocniejszą rolą;
• wykorzystanie polityki zasobu, klucza KMS, kolejki, funkcji lub bucketa jako mostu między kontami;
• ominięcie zamierzonego ograniczenia przez brak warunku dotyczącego zasobu, regionu, taga, organizacji albo źródła żądania.

Nie każda taka możliwość oznacza od razu AdministratorAccess. Eskalacją jest również przejście z odczytu jednego środowiska do modyfikacji pipeline’u, możliwość pozyskania sekretu produkcyjnego albo uzyskanie prawa do wykonywania operacji jako rola deploymentowa.

Jak AWS wylicza efektywne uprawnienia

Analiza musi odtwarzać oficjalną logikę oceny polityk IAM. Najpierw AWS uwierzytelnia principal i buduje kontekst żądania. Następnie ocenia wszystkie odpowiednie instrukcje Allow oraz Deny, ich zasoby, akcje, principal i warunki. Jawny Deny ma pierwszeństwo przed Allow.

W obrębie konta polityki tożsamości i polityki zasobu mogą tworzyć sumę dozwolonych operacji, ale permissions boundary oraz polityka sesji ograniczają tę sumę przez część wspólną. W AWS Organizations polityki SCP wyznaczają maksymalny zakres dla kont członkowskich; same nie przyznają uprawnień. Podobnie trzeba uwzględnić resource control policies, jeśli organizacja ich używa. Dodatkową warstwę tworzą warunki, na przykład aws:PrincipalOrgID, aws:SourceArn, aws:SourceAccount, tagi principal i zasobu, MFA czy ograniczenie regionu.

To wyjaśnia, dlaczego przegląd pojedynczego dokumentu JSON bywa mylący. Instrukcja z Action: "*" może być skutecznie ograniczona boundary i SCP, a wąska polityka może otworzyć drogę do roli posiadającej szerokie prawa. Pentester powinien zapisać dla każdego wniosku pełny kontekst: principal, konto, sesję, boundary, SCP, politykę zasobu, trust policy oraz warunki.

Model techniczny: principal, ścieżka i skutek

Praktyczny model ma trzy warstwy. Pierwsza to principal: użytkownik, rola, sesja federacyjna, workload, usługa AWS lub principal zewnętrznego konta. Druga to krawędzie grafu: możliwość przyjęcia roli, zmiany polityki, przekazania roli, aktualizacji kodu lub odczytu poświadczenia. Trzecia to skutek biznesowy: dostęp do danych, zmiana infrastruktury, wpływ na CI/CD, przejęcie tożsamości albo utrata rozliczalności.

Każda krawędź powinna mieć warunki:

Element	Pytanie kontrolne
Akcja	Czy principal rzeczywiście może wykonać operację?
Zasób	Czy ARN jest ograniczony, czy użyto wildcardu?
Trust	Czy rola ufa właściwemu principalowi i właściwej organizacji?
Warunek	Czy tag, source ARN, external ID lub MFA są wymagane i osiągalne?
Granica	Czy boundary, session policy, SCP albo RCP blokują rezultat?
Stan	Czy atakujący może utworzyć brakujący zasób albo zmienić jego konfigurację?
Dowód	Jak potwierdzić ścieżkę bez trwałej lub destrukcyjnej zmiany?

Tak zbudowany graf ujawnia zależności, których nie pokazuje skaner działający wyłącznie na poziomie pojedynczej polityki.

Dlaczego iam:PassRole wymaga osobnego testu

iam:PassRole nie jest osobnym wywołaniem API. AWS sprawdza je, gdy principal przekazuje rolę obsługiwanej usłudze podczas tworzenia lub zmiany zasobu. Ryzyko zależy więc od połączenia trzech faktów: jaką rolę można przekazać, jakiej usłudze oraz jaki element działania usługi kontroluje tester.

Samo iam:PassRole bez możliwości utworzenia lub modyfikacji zasobu może nie tworzyć ścieżki. Z kolei prawo do uruchomienia funkcji, zadania kontenerowego, instancji, automatyzacji albo joba z dowolną rolą może pozwolić uzyskać jej zdolności pośrednio. Dobra polityka ogranicza Resource do nazwanych ról, używa iam:PassedToService, rozdziela role runtime od ról administracyjnych i nie pozwala użytkownikowi modyfikować roli, którą może przekazać.

W bezpiecznym teście nie trzeba uruchamiać powłoki ani pobierać sekretów. Można przekazać specjalnie przygotowaną rolę laboratoryjną i potwierdzić nieszkodliwą operację, na przykład odczyt znacznika w dedykowanym zasobie. Dowód powinien pokazać kontrolowaną konfigurację, zdarzenia CloudTrail i skuteczne sprzątnięcie.

Relacje zaufania ról i dostęp między kontami

Trust policy odpowiada na pytanie kto może przyjąć rolę, natomiast polityki uprawnień określają, co rola zrobi po jej przyjęciu. Obie strony muszą zostać ocenione razem. Niebezpieczne są relacje ufające całemu kontu bez dalszych warunków, wildcardy w principalach, brak ograniczenia organizacji oraz niewłaściwe użycie external ID w integracjach zewnętrznych.

W środowisku wielokontowym trzeba śledzić ścieżkę przez konto tożsamości, konto narzędziowe, workload i produkcję. Warto sprawdzić również role tworzone przez CloudFormation, Terraform, rozwiązania backupowe i platformę CI/CD. Tożsamość o małych prawach w jednym koncie może zarządzać kodem lub stanem wdrożenia używanym przez uprzywilejowaną rolę w innym.

Taki przegląd naturalnie uzupełnia pentest chmury AWS, Azure i GCP oraz analizę najczęstszych błędów konfiguracji chmury.

Bezpieczna metodologia pentestu AWS IAM

1. Ustal reguły i granice dowodu

Zakres powinien wskazać konta, organizację, regiony, role wyłączone z testu, dozwolone godziny i sposób awaryjnego unieważnienia sesji. Trzeba uzgodnić, czy wolno tworzyć zasoby testowe, przyjmować role, zmieniać tagi i generować zdarzenia detekcyjne. Dane klientów, produkcyjne sekrety i operacje kosztowne powinny być wyłączone.

2. Zbuduj inwentaryzację

Zbieramy użytkowników, role, grupy, polityki zarządzane i inline, boundaries, dostawców tożsamości, profile instancji, role usługowe, polityki zasobów oraz strukturę Organizations. Osobno identyfikujemy long-lived access keys, nieużywane uprawnienia i role bez właściciela.

3. Przeprowadź analizę statyczną

AWS IAM Access Analyzer potrafi walidować polityki i wskazywać dostęp zewnętrzny oraz nieużywane uprawnienia. Wyniki trzeba uzupełnić grafem zależności i ręcznym przeglądem warunków. Symulator polityk pomaga potwierdzić wybrane decyzje, ale nie modeluje każdego efektu ubocznego usługi i nie zastępuje kontroli stanu zasobów.

4. Wybierz minimalny dowód dynamiczny

Dla każdej potencjalnej ścieżki definiujemy najmniejszą odwracalną akcję. Zamiast nadawać administratora można użyć dedykowanej roli testowej, krótkiej sesji i zasobu-canary. Nie modyfikujemy polityk produkcyjnych, jeśli ten sam wniosek potwierdza analiza i harmless proof.

5. Cofnij zmiany i wykonaj retest

Sprzątnięcie obejmuje role, polityki, wersje polityk, klucze, zasoby usługowe, sesje i artefakty. Retest ma wykazać, że konkretna krawędź grafu została usunięta, a nie tylko że zmieniła się nazwa roli.

Detekcja w CloudTrail i warstwie tożsamości

AWS CloudTrail powinien obejmować wszystkie konta i regiony, mieć centralny, odporny na modyfikację magazyn oraz alerty dla zmian IAM. Szczególnej obserwacji wymagają operacje tworzące nowe wersje polityk, zmieniające trust policy, dołączające polityki, tworzące klucze, aktualizujące boundaries i przekazujące role do nowych zasobów.

Detekcja powinna korelować:

• tożsamość i źródło sesji, w tym federację oraz łańcuch AssumeRole;
• nietypowy region, adres źródłowy, user agent i porę;
• zmianę polityki z późniejszym dostępem do sekretu, KMS, S3 lub mechanizmu wdrożenia;
• utworzenie zasobu z uprzywilejowaną rolą i następujące po nim wywołania z tej roli;
• błędy AccessDenied, które poprzedzają skuteczną zmianę uprawnień;
• wyłączenie traila, zmianę bucket policy albo ingerencję w system alertowania.

Ważna jest ochrona samych logów. Principal zdolny zmienić IAM i jednocześnie usunąć ślady posiada podwójne ryzyko.

Hardening: jak usuwać ścieżki zamiast pojedynczych akcji

AWS rekomenduje poświadczenia tymczasowe, federację, MFA, least privilege i regularne usuwanie nieużywanych praw w swoich dobrych praktykach IAM. W praktyce należy:

1. rozdzielić role człowieka, CI/CD, administracji i runtime;
2. ograniczyć iam:PassRole konkretnymi ARN oraz usługą docelową;
3. chronić tworzenie wersji polityk, zmianę trust i boundaries;
4. stosować SCP jako guardrail dla skutków niedopuszczalnych w całej organizacji;
5. wymagać zatwierdzenia dla zmian ról uprzywilejowanych;
6. wiązać dostęp z tagami tylko wtedy, gdy użytkownik nie może sam dowolnie zmienić tych tagów;
7. usuwać statyczne klucze i skracać sesje administracyjne;
8. separować możliwość wdrożenia kodu od możliwości wyboru roli wykonawczej;
9. chronić sekrety zgodnie z procesem rotacji Vault, KMS i poświadczeń;
10. objąć konta break-glass kontrolami PAM i dostępu uprzywilejowanego.

Architektura powinna zakładać naruszenie jednej sesji i ograniczać jej ruch zgodnie z zasadami Zero Trust.

Checklista audytu eskalacji AWS IAM

• Każde konto i rola mają właściciela, przeznaczenie oraz poziom zaufania.
• Analiza obejmuje polityki identity, resource, trust, boundary, session, SCP i RCP.
• iam:PassRole jest ograniczone rolą i usługą docelową.
• Użytkownik nie może zmieniać roli lub tagów, które poszerzają jego własny dostęp.
• Role cross-account wymagają właściwych principal, warunków organizacji i mechanizmu dla dostawcy.
• Pipeline nie pozwala jednocześnie podmienić kodu i wybrać dowolnej roli runtime.
• Test dynamiczny używa osobnego zasobu, krótkiej sesji i odwracalnego skutku.
• CloudTrail działa organizacyjnie, wieloregionowo i trafia do chronionego konta logowego.
• Alerty korelują zmianę IAM z późniejszym użyciem nowych uprawnień.
• Po teście usunięto wszystkie artefakty i potwierdzono to w inwentaryzacji.
• Remediacja usuwa całą ścieżkę grafu, a retest potwierdza brak alternatywnej krawędzi.

Jak raportować wynik, aby zespół mógł go naprawić

Raport powinien zawierać principal początkowy, wymagane warunki, kolejne krawędzie, rolę lub usługę docelową, maksymalny skutek, dowód CloudTrail, ograniczenia testu i rekomendację. Ocena ważności musi uwzględniać osiągalność principal, czas życia sesji, produkcyjność konta, dostęp do danych i możliwość ukrycia śladów.

Najbardziej użyteczny diagram pokazuje ścieżkę „tożsamość → dozwolona zmiana → rola/usługa → skutek”. Dzięki temu właściciel nie łata przypadkowej akcji, lecz usuwa przyczynę: wildcard, błędny trust, zbyt szerokie PassRole albo połączenie obowiązków.

Źródła pierwotne

• AWS IAM — Policy evaluation logic
• AWS IAM — Security best practices
• AWS IAM Access Analyzer — Policy validation
• AWS IAM — Permissions boundaries
• AWS IAM — Granting permission to pass a role
• AWS CloudTrail User Guide