Zakres testów

Testy penetracyjne
środowisk chmurowych

W chmurze rzadko wchodzi się przez podatność w oprogramowaniu. Wystarczy jedna rola z nadmiarowymi uprawnieniami, jeden publiczny kontener na pliki i jeden token, który wyciekł z procesu budowania. Sprawdzamy konfigurację AWS, Azure i Google Cloud oraz to, jak daleko da się zajść, mając dostęp do jednego zasobu.

  • AWS, Azure i Google Cloud oraz klastry Kubernetes
  • Ścieżki eskalacji uprawnień w IAM, nie tylko lista braków w konfiguracji
  • Weryfikacja, czy Wasze logowanie zdarzeń w ogóle zauważa nasze działania

Środowiska chmurowe

Czas trwania
zwykle 5-12 dni roboczych
Pracujemy według
  • CIS Benchmarks dla AWS, Azure, GCP i Kubernetes
  • MITRE ATT&CK for Cloud
  • OWASP Kubernetes Top 10
  • PTES

Co dokładnie sprawdzamy

Zakres dopasowujemy do Twojego środowiska, ale te obszary bierzemy pod lupę zawsze.

1

Tożsamości i uprawnienia (IAM)

Role i polityki szersze niż potrzeba, klucze długoterminowe zamiast poświadczeń tymczasowych, konta bez drugiego składnika, ścieżki eskalacji uprawnień w obrębie konta i między kontami.

2

Dane i magazyny

Publiczne i nadmiernie udostępnione kontenery S3, Blob i GCS, szyfrowanie danych oraz kluczy, dostęp do baz i migawek, kopie zapasowe i zasady ich przechowywania.

3

Sieć i ekspozycja

Reguły grup zabezpieczeń otwarte na cały internet, publiczne adresy tam, gdzie wystarczy łącze prywatne, konfiguracja usług brzegowych, dostęp administracyjny do maszyn wirtualnych.

4

Kontenery i Kubernetes

Uprawnienia RBAC, konta usługowe podów, kontenery uprzywilejowane i możliwość wyjścia z poda na węzeł, sekrety w zmiennych środowiskowych, podatności i pochodzenie obrazów.

5

Serverless i CI/CD

Uprawnienia funkcji i zmienne środowiskowe z sekretami, uprawnienia procesu budowania i możliwość wstrzyknięcia w niego własnego kroku, zaufanie do zewnętrznych zależności i rejestrów.

6

Logowanie i wykrywanie

Kompletność logów CloudTrail i odpowiedników, ich ochrona przed skasowaniem, konfiguracja usług detekcyjnych oraz sprawdzenie, które z naszych działań wywołały realny alert.

Co najczęściej znajdujemy

Przykłady z naszych projektów w tym zakresie. Nazwy klientów i szczegóły techniczne zostają w raportach.

  • Rola z polityką dającą pełne uprawnienia, przypisana funkcji o wąskim zadaniu
  • Kontener S3 z dokumentami klientów dostępny publicznie do odczytu
  • Klucz dostępowy w zmiennej środowiskowej procesu budowania, widoczny w logach
  • Ścieżka eskalacji: uprawnienie do zmiany polityki prowadzące do roli administratora
  • Baza danych z adresem publicznym i grupą zabezpieczeń otwartą na świat
  • Konto usługowe Kubernetes z uprawnieniami do odczytu wszystkich sekretów
  • Wyłączone logowanie zdarzeń w części regionów i subskrypcji
  • Migawki dysków udostępnione poza organizację

Wybrane narzędzia

ProwlerScoutSuitePacutrivykubectl i narzędzia do RBACnatywne CLI dostawcy

Narzędzia skracają pracę powtarzalną. Wnioski i łańcuchy ataku budujemy ręcznie.

Przebieg testu i raport

Proces testowy, forma raportu oraz zasady retestów są wspólne dla wszystkich zakresów.

Zobacz pełny proces i zawartość raportu

Najczęstsze pytania

Czy trzeba zgłaszać testy dostawcy chmury?

Przy standardowym zakresie zwykle nie, bo AWS, Azure i Google dopuszczają testy własnych zasobów w ramach swoich zasad. Pilnujemy tych zasad za Ciebie i informujemy, jeśli któryś element zakresu wymaga zgłoszenia.

Jakiego dostępu potrzebujecie?

Do przeglądu konfiguracji wystarczy konto z uprawnieniami tylko do odczytu. Do sprawdzenia ścieżek eskalacji przydaje się dodatkowo konto o typowych uprawnieniach użytkownika, żeby zobaczyć środowisko jego oczami.

Czy to to samo co audyt zgodności?

Nie. Audyt sprawdza zgodność z listą wymagań. My szukamy działających ścieżek ataku i pokazujemy skutek. Najlepiej wypadają razem, bo część naszych ustaleń wprost wspiera przygotowanie do certyfikacji.

Czy testujecie środowiska hybrydowe?

Tak. Najciekawsze bywa właśnie połączenie: konto w chmurze dające dostęp do sieci lokalnej albo domena rozciągnięta na oba środowiska. Taki zakres łączymy z testami infrastruktury wewnętrznej.

Pozostałe zakresy testów

Zakresy łączymy w jeden projekt, jeśli tak wychodzi lepiej dla Twojego środowiska.

Aplikacje webowe i API

Wykrywamy podatności z listy OWASP Top 10 (m.in. SQL Injection, XSS, SSRF, BOLA). Audytujemy panele klienta, systemy e-commerce, CRM oraz złożone środowiska oparte o mikroserwisy i API (REST, GraphQL).

Zobacz zakres

Aplikacje mobilne

Reverse engineering aplikacji iOS i Android (w tym Flutter i React Native). Sprawdzamy bezpieczne przechowywanie danych na urządzeniu, poprawność komunikacji z serwerem i luki w logice autoryzacji.

Zobacz zakres

Infrastruktura wewnętrzna

Symulujemy atak np. z perspektywy złośliwego pracownika lub przejętej stacji roboczej. Badamy segmentację sieci (VLAN), Active Directory, serwery plików i polityki haseł.

Zobacz zakres

Infrastruktura zewnętrzna

Atakujemy wystawione do internetu systemy i usługi. Weryfikujemy konfigurację firewalli, podatności serwerów VPN, nieaktualne wersje oprogramowania czy błędne konfiguracje DNS.

Zobacz zakres

Sieci bezprzewodowe

Analizujemy zabezpieczenia firmowych sieci Wi-Fi, izolację sieci dla gości, podatności na przechwytywanie haseł, ataki Evil Twin oraz Rogue Access Point.

Zobacz zakres

Sprawdźmy to zanim zrobi to ktoś inny

Napisz, co chcesz przetestować. Odpowiemy z zakresem, terminem i ceną, bez zobowiązań.