Testy penetracyjne · Infrastruktura
Infrastruktura i sieci
Testy penetracyjne infrastruktury i sieci - perymetr widoczny z internetu, VPN, sieć wewnętrzna i Active Directory. Według NIST SP 800-115, bez testów DoS.
Testy penetracyjne · Chmura
Testy penetracyjne i przegląd bezpieczeństwa chmury
Testy penetracyjne chmury łączą przegląd konfiguracji z testem tego, co da się z niej wykorzystać - uprawnień IAM, sieci, magazynów danych, logowania i szyfrowania. Sprawdzamy środowiska AWS, Microsoft Azure i Google Cloud według CIS Benchmarks i zasad testów każdego dostawcy, razem z kontenerami i Kubernetes.
01Podział odpowiedzialności
Model współodpowiedzialności w chmurze
Dostawca odpowiada za bezpieczeństwo chmury, a Ty - za bezpieczeństwo w chmurze. Testujemy tę drugą część.
| Obszar | Kto odpowiada | Czy testujemy |
|---|---|---|
| Centra danych, sprzęt, sieć szkieletowa | Dostawca chmury | Nie - poza zakresem i zasadami dostawców |
| Warstwa platformy usług zarządzanych | Dostawca chmury | Nie |
| Konfiguracja usług i sieci wirtualnych | Ty | Tak |
| Tożsamości, role i uprawnienia (IAM) | Ty | Tak |
| Dane, ich szyfrowanie i kopie zapasowe | Ty (dostawca daje narzędzia) | Tak |
| Systemy maszyn wirtualnych, kontenery, aplikacje | Ty | Tak |
Dokładny podział zależy od rodzaju usługi: w maszynach wirtualnych odpowiadasz także za system operacyjny, w usługach zarządzanych - głównie za konfigurację i uprawnienia. Dlatego zakres testu ustalamy na podstawie listy usług, z których faktycznie korzystasz.
02Zakres
Zakres: testy penetracyjne chmury i przegląd konfiguracji
Punkt odniesienia dla przeglądu to CIS Benchmarks dla danego dostawcy. Test ataku pokazuje, które odstępstwa da się realnie wykorzystać.
| Obszar | Co sprawdzamy |
|---|---|
| Tożsamość i uprawnienia (IAM) | Role z nadmiarowymi uprawnieniami, długoterminowe klucze dostępu, konta bez MFA, ścieżki eskalacji uprawnień, zaufanie między kontami i subskrypcjami. |
| Sieć | Grupy bezpieczeństwa i reguły zapór, publiczne adresy, porty zarządzania otwarte do internetu, oddzielenie środowisk produkcyjnych od testowych. |
| Magazyny danych | Publicznie dostępne zasobniki i bazy, linki z podpisem bez ograniczeń, migawki i kopie zapasowe dostępne zbyt szeroko. |
| Logowanie i monitoring | Dzienniki audytu we wszystkich regionach i kontach, retencja, alerty na zmiany uprawnień i konfiguracji. |
| Szyfrowanie i sekrety | Szyfrowanie danych w spoczynku i w tranzycie, zarządzanie kluczami, sekrety w zmiennych środowiskowych, szablonach i potokach CI/CD. |
| Usługi bezserwerowe i API | Uprawnienia funkcji, wyzwalacze, bramki API i ich uwierzytelnianie. |
03Metodyka
Przegląd konfiguracji i test ataku
Przegląd konfiguracji
Z kontem tylko do odczytu przeglądamy konfigurację wszystkich kont, subskrypcji lub projektów w zakresie - automatycznie i ręcznie. Narzędzia znajdują odstępstwa od CIS Benchmarks, a my oceniamy, które z nich mają znaczenie w Twoim środowisku, a które są świadomym wyborem.
Test ataku
Zaczynamy od uzgodnionego scenariusza: przejęty klucz aplikacji, konto zwykłego użytkownika albo podatność w aplikacji, która pozwala sięgnąć do metadanych instancji (SSRF). Sprawdzamy, jak daleko da się z tego punktu dojść - do danych, innych kont i uprawnień administratora.
04Kontenery
Kontenery i Kubernetes
W klastrach Kubernetes (także zarządzanych: EKS, AKS, GKE) i środowiskach kontenerowych sprawdzamy:
- uprawnienia RBAC i konta serwisowe - czy aplikacja w podzie może zarządzać klastrem,
- izolację - kontenery uprzywilejowane, montowanie systemu plików hosta, dostęp do API serwera klastra,
- sieć - polityki sieciowe między przestrzeniami nazw, usługi wystawione na zewnątrz,
- sekrety - sposób przechowywania i przekazywania do aplikacji,
- obrazy - bazowe obrazy ze znanymi podatnościami, zbędne narzędzia, uruchamianie jako root.
05Zasady dostawców
Zasady testów u dostawców chmury
Każdy dostawca określa, co wolno testować w jego chmurze. Stan na 2026-10-06 - przed testem zawsze sprawdzamy aktualną wersję.
| Dostawca | Zgoda przed testem | Najważniejsze ograniczenia |
|---|---|---|
| AWS | Niewymagana dla usług wymienionych w polityce (m.in. EC2, RDS, Lambda, CloudFront, API Gateway). Testy symulujące zdarzenia, np. DDoS, wymagają wcześniejszego zgłoszenia. | Zakaz DoS i DDoS, zalewania żądaniami, przejmowania subdomen i zasobników S3, przeglądania stref DNS w Route 53. |
| Microsoft Azure | Niewymagana - obowiązują Rules of Engagement Microsoft. | Testy tylko własnych zasobów, zakaz DoS, testowania cudzych dzierżawców, phishingu pracowników Microsoft i działań po przełamaniu zabezpieczeń usług Microsoft. |
| Google Cloud | Niewymagana. | Testy tylko własnych projektów, zgodnie z Acceptable Use Policy i warunkami usługi. |
06Dane w UE
Gdzie naprawdę są Twoje dane
Wybór regionu w Unii Europejskiej to dopiero początek. W przeglądzie sprawdzamy też, gdzie trafiają kopie zapasowe i migawki, czy replikacja między regionami nie wychodzi poza UE, gdzie przechowywane są logi oraz które usługi globalne przetwarzają dane poza wybranym regionem.
Sami budujemy systemy z zasadą, że dane klientów zostają w centrach danych w UE - dlatego patrzymy na to tak samo w środowiskach, które testujemy.
Najczęściej zadawane pytania
Czy na test potrzebna jest zgoda dostawcy chmury?
Według zasad obowiązujących w październiku 2026 r. ani AWS (dla wymienionych w polityce usług), ani Microsoft, ani Google nie wymagają wcześniejszej zgody na test własnych zasobów. Każdy dostawca zakazuje jednak m.in. ataków DoS, a AWS wymaga wcześniejszego zgłoszenia testów symulujących takie zdarzenia. Zasady sprawdzamy przed każdym testem, bo dostawcy je aktualizują.
Jakiego dostępu potrzebujecie?
Do przeglądu konfiguracji - konta z uprawnieniami tylko do odczytu (np. role audytowe dostawcy) dla wszystkich kont, subskrypcji lub projektów w zakresie. Do testu ataku - uzgodnionego scenariusza startowego, np. konta zwykłego użytkownika, klucza o ograniczonych uprawnieniach albo podatnej aplikacji w środowisku testowym.
Czy test chmury obejmuje aplikacje, które w niej działają?
Nie w pełni - sprawdzamy, jak aplikacje korzystają z chmury (uprawnienia, sekrety, dostęp do metadanych), ale ich logikę testujemy osobno: testy aplikacji webowych i testy bezpieczeństwa API. Oba testy dobrze jest połączyć w jednym projekcie.
Czym przegląd konfiguracji różni się od testu penetracyjnego chmury?
Przegląd pokazuje odstępstwa od dobrych praktyk, np. publiczny magazyn danych czy konto bez MFA. Test penetracyjny sprawdza, co atakujący może z nimi zrobić - np. czy przejęty klucz aplikacji pozwala dojść do uprawnień administratora. Łączymy oba podejścia, bo dopiero razem pokazują, które ustawienia są naprawdę groźne.
Źródła
Powiązane usługi
Testy penetracyjne · API
API
Testy bezpieczeństwa API według OWASP API Security Top 10 2023 - autoryzacja obiektów, OAuth 2.0, JWT, GraphQL i webhooki. Raport z dowodami i retestem.
Testy penetracyjne · Cennik
Cennik
Ile kosztują testy penetracyjne? Od czego zależy cena pentestu, pakiety, checklista zapytania i na co uważać przy najtańszej ofercie.