W chmurze nie trzeba łamać serwera.
Wystarczy znaleźć złą politykę IAM.
Pentest AWS to test architektury uprawnień, ekspozycji usług i procesów wdrożeniowych. Publiczny bucket S3, zbyt szeroka rola, źle spięte trust policy albo sekret w artefakcie CI/CD potrafią dać większy efekt niż klasyczna podatność webowa.
Co testujemy najpierw
Zaczynamy od zewnętrznej ekspozycji: buckety, CloudFront, ELB, API Gateway, publiczne endpointy i nazewnictwo zasobów. Następnie przechodzimy do IAM: użytkownicy, role, trust relationships, permission boundaries i polityki dające możliwość eskalacji.
Dlaczego S3 nadal wraca w raportach
Problemem rzadko jest sam S3. Problemem jest proces: szybka publikacja plików, testowe buckety, źle rozumiane ACL-e, publiczne listowanie lub artefakty z sekretami. Dlatego testujemy zarówno konfigurację, jak i realną zawartość.
Pentest konta z dostępem wewnętrznym
Jeśli klient udostępnia rolę audytową, mapujemy możliwe ścieżki ruchu bocznego i eskalacji: PassRole, AssumeRole, polityki z wildcardami, dostęp do Secrets Managera, ECR, Lambda i logów.
Jak wygląda praktyczna weryfikacja
Zespoły zakładają, że „brak publicznego IP” oznacza bezpieczeństwo. W AWS największe ryzyko często wynika z relacji uprawnień, nie z otwartego portu.
Na co zwracamy uwagę w raporcie
Publiczny dostęp
Listowanie lub odczyt obiektów ujawnia backupy, logi, eksporty i dane klientów.
Privilege escalation
Zbyt szerokie uprawnienia pozwalają przejąć role albo wykonywać akcje poza pierwotnym zakresem.
Brak widoczności
Jeśli CloudTrail i alerty nie działają, incydent może przejść bez śladu operacyjnego.
Chcesz sprawdzić konfigurację AWS?
Robimy pentesty i audyty AWS: IAM, S3, sieć, kontenery, serverless, logowanie, sekrety oraz rekomendacje hardeningu.
Zapytaj o wycenę →