Pentest chmury AWS, Azure i GCP: zakres oraz zasady
Jak zaplanować pentest chmury bez naruszenia zasad dostawcy? Zakres IAM, storage, sieci, Kubernetes, serverless, logi i bezpieczne reguły testu.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 7 lipca 2026
- CZAS CZYTANIA
- 12 min czytania
- TEMAT
- Pentest
Pentest chmury AWS, Azure lub GCP musi objąć konfigurację klienta, tożsamość, ścieżki między usługami i warstwę aplikacji, a jednocześnie respektować zasady dostawcy. Fakt, że organizacja płaci za zasób, nie daje automatycznego prawa do testowania współdzielonej infrastruktury, innych tenantów ani usług SaaS.
Dobry zakres rozdziela odpowiedzialność dostawcy od elementów konfigurowanych przez klienta i opisuje działania, których tester nie wykona bez dodatkowej zgody.
Najpierw polityka dostawcy
AWS, Microsoft Azure i Google Cloud publikują zasady testów oraz usług zabronionych. Warunki zmieniają się, dlatego w dniu rozpoczęcia zapisz aktualną wersję polityki.
Zwykle można testować własne instancje, aplikacje i konfigurację bez wcześniejszego zgłoszenia, ale zabronione pozostają DoS, zakłócanie innych klientów, masowe obciążenie usług zarządzanych, socjotechnika wobec pracowników dostawcy i próby wyjścia z przydzielonego tenanta.
Co powinno znaleźć się w zakresie
Tożsamość i IAM
Zbadaj role, trust policy, service principals, managed identities, klucze dostępowe, MFA i możliwości AssumeRole. Najważniejsze są łańcuchy: pojedyncze uprawnienie może wyglądać niewinnie, ale wraz z PassRole, możliwością uruchomienia funkcji albo zmianą polityki prowadzić do administratora.
Storage i dane
Sprawdź publiczny dostęp, polityki bucketów, podpisane URL, szyfrowanie, backupy, snapshoty i dostęp między kontami. Sam status „private” nie dowodzi, że każda rola ma właściwe prawa.
Sieć i usługi brzegowe
Oceń security groups, NSG, firewalle, load balancery, private endpoints, DNS i dostęp administracyjny. Szukaj ścieżek z internetu oraz z przejętego workloadu do warstwy zarządzającej.
Kontenery, serverless i CI/CD
Testuj role podów i funkcji, sekrety, rejestry obrazów, metadata service, pipeline deployment i możliwość podmiany artefaktu. Uprawniona funkcja serverless często posiada szerszą rolę niż użytkownik, który może zmienić jej kod.
Logi i detekcja
Zweryfikuj CloudTrail, Azure Activity Logs, GCP Audit Logs, logi danych i retencję. Przeprowadź uzgodnione techniki i sprawdź, czy generują alarm, a nie tylko surowe zdarzenie.
Reguły zaangażowania
Dokument powinien podać konta/subskrypcje/projekty, regiony, adresy źródłowe, godziny, limity API, dane testowe, zakazane akcje i awaryjny kontakt. Oddziel operacje odczytu od zapisu. Usuwanie, zatrzymanie produkcji, dostęp do realnych danych i kosztowne obciążenie wymagają dodatkowej zgody.
Tester potrzebuje osobnej tożsamości, nie współdzielonego konta administratora. Logi powinny jednoznacznie identyfikować działania testowe.
Grey box daje więcej wartości
Udostępnienie diagramu, listy kont, Terraformu i ról nie zmniejsza realizmu. Pozwala szybciej znaleźć złożone ścieżki. Black box dobrze sprawdza ekspozycję zewnętrzną, ale nie pokryje skutecznie tysięcy relacji IAM.
Najlepszy model łączy perspektywę zewnętrzną, konto zwykłego użytkownika, ograniczoną rolę workloadu i przegląd konfiguracji. Praktyki przygotowania opisujemy w checkliście przed pentestem.
Raport i retest
Każde znalezisko powinno wskazywać zasób, warunek, ścieżkę uprawnień, dowód, wpływ i poprawkę IaC lub polityki. Screenshot z konsoli bez ARN/ID i regionu utrudnia naprawę.
Retest musi sprawdzić alternatywną ścieżkę. Usunięcie jednej policy nie rozwiązuje problemu, jeśli to samo uprawnienie wraca przez grupę, rolę albo pipeline.
Dowody i bezpieczne konto testowe
Utwórz oddzielną tożsamość pentestera z czasowym dostępem i pełnym logowaniem, zamiast przekazywać stały klucz administratora. Zakres opisuje konta, subskrypcje, projekty, regiony, usługi zarządzane i elementy SaaS, których klient chmury nie kontroluje. Przed testem potwierdź aktualne zasady dostawcy — różnią się one usługą i mogą się zmieniać.
Raport powinien odtworzyć ścieżkę od publicznej ekspozycji lub niskiego uprawnienia do danych i kontroli nad zasobem. Zapisuj identyfikatory polityk, role, trust policy oraz zdarzenia audytowe, ale nie pobieraj więcej danych niż potrzeba do dowodu. Po teście usuń zasoby, tokeny i wyjątki sieciowe oraz potwierdź ten stan w logach i IaC.
Źródła: AWS Penetration Testing, Microsoft Cloud Penetration Testing Rules, Google Cloud AUP.
