Testy penetracyjne – czym są, na czym polegają i kiedy warto je przeprowadzać?

Czym są testy penetracyjne i jaki jest ich cel

Testy penetracyjne, nazywane również pentestami, to autoryzowane próby przełamania zabezpieczeń systemu, aplikacji lub infrastruktury IT. Specjaliści działający za zgodą właściciela sprawdzają, czy mogą wykorzystać istniejące słabości w sposób zbliżony do rzeczywistego napastnika. Nie chodzi przy tym o wyrządzenie szkody, lecz o ustalenie, jak skutecznie organizacja chroni swoje dane i usługi.

Pentest odpowiada na praktyczne pytanie: co atakujący mógłby faktycznie osiągnąć i jakie byłyby tego konsekwencje? Samo wykrycie błędu nie zawsze pozwala to ocenić. Dopiero jego kontrolowana weryfikacja może pokazać, czy umożliwia on na przykład dostęp do cudzych dokumentów, przejęcie konta z podwyższonymi uprawnieniami albo dotarcie do zasobów, które powinny być odizolowane. Znaczenie ma również to, czy kilka pozornie drobnych słabości można połączyć w skuteczną ścieżkę ataku.

Przedmiotem testów mogą być między innymi aplikacje internetowe i mobilne, interfejsy API, sieci wewnętrzne oraz środowiska chmurowe. W zależności od badanego obszaru sprawdza się różne mechanizmy ochrony — od kontroli dostępu do danych po ograniczenia komunikacji między systemami. W odróżnieniu od samego przeglądu konfiguracji czy automatycznego wykrywania potencjalnych podatności pentest koncentruje się na praktycznej możliwości ich wykorzystania w uzgodnionych warunkach.

Podstawą testu penetracyjnego jest wyraźna zgoda oraz określone granice działania. To one odróżniają legalną ocenę bezpieczeństwa od nieuprawnionego ataku. Testerzy nie mają dowolności w ingerowaniu w środowisko: ich działania muszą respektować ustalony zakres i ograniczenia służące ochronie danych oraz ciągłości pracy. Kontrolowany charakter testów nie oznacza jednak całkowitego braku ryzyka operacyjnego.

Celem biznesowym pentestu jest ograniczenie ryzyka incydentu i lepsze ukierunkowanie prac nad bezpieczeństwem. Organizacja zyskuje podstawę do oceny, które słabości rzeczywiście zagrażają jej działalności i gdzie poprawa ochrony jest najpilniejsza. Pentest nie stanowi gwarancji, że system jest bezpieczny: przedstawia wynik badania konkretnego zakresu, w określonym czasie i przy przyjętych założeniach. Brak wykrytych możliwości włamania nie jest więc dowodem braku wszystkich podatności.

Pentest a skanowanie podatności – kluczowe różnice

Skanowanie podatności i test penetracyjny odpowiadają na różne pytania. Skanowanie wskazuje potencjalne słabości zabezpieczeń, a pentest sprawdza, czy i w jakim stopniu można je wykorzystać w praktyce. W Cognity często spotykamy się z pytaniami o tę różnicę podczas szkoleń, dlatego wyjaśniamy ją również na blogu. Wynik skanowania nie jest bowiem równoznaczny z potwierdzeniem, że atak się powiedzie. Z kolei brak wykrytych podatności nie oznacza, że system jest bezpieczny.

Skaner automatycznie sprawdza wybrane zasoby pod kątem m.in. znanych luk w oprogramowaniu, niebezpiecznych konfiguracji czy niepotrzebnie udostępnionych usług. Pozwala stosunkowo szybko objąć kontrolą wiele systemów i wskazać obszary wymagające uwagi. Jego skuteczność zależy jednak od konfiguracji, uprawnień dostępu oraz zastosowanych reguł wykrywania. Część alertów może okazać się fałszywie dodatnia, czyli sygnalizować problem, który w rzeczywistości nie występuje.

W pentestach narzędzia automatyczne wspierają pracę specjalisty, ale jej nie zastępują. Tester interpretuje wyniki w kontekście konkretnego środowiska, weryfikuje możliwość nadużycia i szuka zależności między słabościami. Może także rozpoznać błędy, których typowy skaner nie oceni trafnie — na przykład sytuację, w której użytkownik uzyskuje dostęp do cudzych dokumentów mimo prawidłowego zalogowania. Istotna jest tu nie tylko obecność pojedynczej luki, lecz także sposób działania aplikacji i jej mechanizmów uprawnień.

Różnica dotyczy również oceny znaczenia wykrytego problemu. Skaner często przypisuje mu wagę na podstawie ogólnych cech podatności. Pentest pozwala lepiej uwzględnić rzeczywiste warunki: dostępność danego zasobu, istniejące zabezpieczenia oraz możliwe skutki dla danych i procesów biznesowych. Nie oznacza to jednak, że podczas testu wykorzystuje się każdą znalezioną lukę — weryfikację ograniczają uzgodniony zakres i zasady bezpieczeństwa.

Skanowanie sprawdza się przede wszystkim jako powtarzalny element zarządzania podatnościami: pomaga wychwytywać znane problemy i kontrolować postęp ich usuwania. Pentest służy pogłębionej ocenie odporności wybranego środowiska na atak. Te metody uzupełniają się, zamiast wzajemnie zastępować: skanowanie zapewnia szeroki przegląd potencjalnych słabości, a test penetracyjny pozwala zweryfikować możliwość ich wykorzystania w konkretnych warunkach.

Rodzaje testów penetracyjnych: black box, grey box, white box

Podział na black box, grey box i white box określa przede wszystkim ilość informacji oraz poziom dostępu, które tester otrzymuje przed rozpoczęciem pracy. Nie dotyczy natomiast samego obiektu badania: w każdym z tych modeli można testować na przykład aplikację internetową lub infrastrukturę sieciową. Wybór zależy od tego, jaki scenariusz zagrożenia firma chce sprawdzić i jak szerokiego wglądu w zabezpieczenia potrzebuje.

Black box — perspektywa osoby z zewnątrz

W modelu black box tester nie otrzymuje szczegółowej wiedzy o wewnętrznej budowie badanego środowiska ani kont użytkowników. Punktem wyjścia mogą być jedynie wskazane domeny, adresy IP lub adres aplikacji. Taki wariant pozwala sprawdzić, co może osiągnąć osoba, która początkowo dysponuje wyłącznie informacjami dostępnymi z zewnątrz.

Black box sprawdza się przy ocenie zabezpieczeń usług dostępnych publicznie, gdy istotna jest perspektywa zewnętrznego atakującego bez uprzywilejowanej wiedzy. Ma jednak ograniczenie: część czasu tester poświęca na poznanie środowiska, co przy ustalonym budżecie może zmniejszyć zakres sprawdzonych funkcji. Brak wykrytych problemów w tym modelu nie oznacza więc, że wewnętrzne mechanizmy aplikacji są bezpieczne.

Grey box — częściowa wiedza i dostęp użytkownika

Grey box zakłada przekazanie testerowi wybranych informacji lub uprawnień, na przykład konta zwykłego użytkownika, kont o różnych rolach czy dokumentacji API. Tester zna część środowiska, ale nie ma pełnego wglądu w jego implementację.

Ten model jest szczególnie przydatny w aplikacjach z logowaniem i zróżnicowanymi uprawnieniami. Pozwala ocenić między innymi, czy użytkownik może uzyskać dostęp do cudzych danych albo funkcji zastrzeżonych dla innej roli. Grey box dobrze odpowiada scenariuszowi nadużycia legalnego konta lub przejęcia danych logowania. Ogranicza też czas potrzebny na zdobycie dostępu do funkcji, które mają zostać zbadane.

White box — szeroki wgląd w badane rozwiązanie

W modelu white box tester otrzymuje szeroką wiedzę o systemie. Zależnie od uzgodnień może ona obejmować kod źródłowy, dokumentację architektury, konfigurację oraz konta z odpowiednimi uprawnieniami. Dzięki temu może zestawić zachowanie aplikacji z tym, jak została zaprojektowana i zaimplementowana.

White box warto wybrać, gdy priorytetem jest dogłębna ocena zabezpieczeń, szczególnie w rozwiązaniach o złożonej logice biznesowej lub rozbudowanych mechanizmach kontroli dostępu. Wiedza o implementacji ułatwia dotarcie do problemów, które trudno zauważyć wyłącznie na podstawie działania interfejsu. Nie oznacza to jednak automatycznie pełnego audytu całego kodu — zakres takiej analizy trzeba określić osobno.

Jak dobrać model do celu badania?

Jeśli firma chce poznać możliwości atakującego bez konta i wiedzy wewnętrznej, odpowiedni będzie black box. Gdy najważniejsze są uprawnienia i bezpieczeństwo funkcji po zalogowaniu, użyteczny będzie grey box. Jeżeli celem jest możliwie głębokie sprawdzenie rozwiązania z wykorzystaniem wiedzy o jego budowie, warto rozważyć white box. Żaden model nie jest bezwarunkowo najlepszy: można je również łączyć, na przykład badając publiczną część aplikacji w podejściu black box, a funkcje dostępne po zalogowaniu — w grey box.

Typowy proces pentestu krok po kroku: uzgodnienia, zakres i przygotowanie

Pentest zaczyna się od ustalenia, co zespół ma sprawdzić, na jakich zasobach może działać i jakie ograniczenia musi respektować. Te decyzje wpływają zarówno na użyteczność testu, jak i bezpieczeństwo badanych usług. Nieprecyzyjny zakres może sprawić, że istotny obszar pozostanie poza oceną, a nieuzgodnione działania zakłócą pracę systemów. W Cognity omawiamy przygotowanie pentestu zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników szkoleń.

1. Ustalenie celu biznesowego i przedmiotu testu

Na początku zleceniodawca i wykonawca określają, na jakie pytania ma odpowiedzieć badanie. Celem może być sprawdzenie, czy użytkownik aplikacji uzyska dostęp do cudzych danych, czy zasoby dostępne z internetu pozwolą dotrzeć do systemów wewnętrznych albo czy odseparowanie wybranych środowisk działa zgodnie z założeniami. Cel powinien być konkretny — samo „sprawdzenie bezpieczeństwa firmy” nie wystarcza do zaplanowania prac.

W rozmowie warto uwzględnić właścicieli biznesowych usług oraz osoby odpowiedzialne za IT i bezpieczeństwo. Pozwala to wskazać najważniejsze procesy, wrażliwe dane i systemy, których niedostępność miałaby największe konsekwencje.

2. Wyznaczenie zakresu i wyłączeń

Zakres pentestu powinien jednoznacznie identyfikować zasoby objęte badaniem: na przykład domeny, adresy IP, aplikacje, interfejsy API, segmenty sieci czy konta w środowisku chmurowym. Równie ważne jest zapisanie wyłączeń — elementów, których testerzy nie mogą badać, nawet jeśli natrafią na nie podczas pracy.

Powiązanie techniczne nie oznacza automatycznie zgody na testowanie. Integracja z systemem płatności, usługą partnera lub infrastrukturą dostawcy wymaga sprawdzenia uprawnień zleceniodawcy, warunków świadczenia usług oraz ewentualnej konieczności uzyskania dodatkowej zgody. Dotyczy to szczególnie środowisk współdzielonych.

Na tym etapie wybiera się także środowisko. Produkcja pozwala ocenić rzeczywiste wdrożenie, ale wymaga większej ostrożności ze względu na użytkowników i ciągłość działania. Środowisko testowe ogranicza ryzyko dla bieżącej działalności, jednak jego konfiguracja, uprawnienia i integracje mogą różnić się od produkcyjnych, co ogranicza możliwość przenoszenia wniosków.

3. Pisemna autoryzacja i zasady prowadzenia prac

Przed rozpoczęciem działań technicznych wykonawca powinien otrzymać pisemną zgodę od podmiotu uprawnionego do jej udzielenia. Dokumentacja ustala też reguły testu, często określane jako Rules of Engagement. Powinna obejmować przede wszystkim:

• terminy i godziny prowadzenia prac oraz dopuszczalne obciążenie systemów;
• dozwolone działania i ograniczenia, w tym zasady dotyczące testów dostępności, socjotechniki i modyfikowania danych;
• osoby kontaktowe, kanał pilnej komunikacji oraz warunki wstrzymania i wznowienia testu;
• sposób postępowania po wykryciu krytycznego zagrożenia lub oznak rzeczywistego incydentu;
• zasady dostępu do danych, ich przechowywania, przekazywania i usuwania.

Warto również ustalić, czy zespół monitorujący bezpieczeństwo zostanie uprzedzony o badaniu. Zależy to od celu zlecenia, ale po stronie organizacji zawsze powinny być dostępne osoby upoważnione do reagowania i podejmowania decyzji.

4. Przygotowanie dostępów i zabezpieczenie ciągłości działania

Ostatnim krokiem jest sprawdzenie gotowości operacyjnej. Zależnie od uzgodnionego zakresu przygotowuje się konta z odpowiednimi rolami, bezpieczny dostęp zdalny, dokumentację oraz dane testowe. Dane uwierzytelniające należy przekazać uzgodnionym, bezpiecznym kanałem, a po zakończeniu prac odebrać tymczasowe uprawnienia.

Właściciele systemów powinni potwierdzić dostępność aktualnych kopii zapasowych i procedur odtworzenia, działanie monitoringu oraz gotowość administratorów w ustalonym oknie testowym. Kopia zapasowa nie zastępuje jednak ostrożności: nawet autoryzowany i dobrze przygotowany pentest nie jest całkowicie pozbawiony ryzyka. Dlatego przed startem obie strony potwierdzają zakres, kontakty awaryjne i warunki bezpiecznego prowadzenia prac.

Fazy techniczne: rekonesans, skanowanie, eksploatacja i post-exploitation

Techniczna część pentestu prowadzi od rozpoznania badanego środowiska do sprawdzenia, jakie skutki może mieć wykorzystanie jego słabości. Każda faza odpowiada na inne pytanie: co jest dostępne, gdzie mogą występować podatności, czy da się je wykorzystać i jak daleko pozwala sięgnąć uzyskany dostęp. Działania odbywają się wyłącznie w zatwierdzonym zakresie i z uwzględnieniem ustalonych ograniczeń bezpieczeństwa.

Rekonesans — rozpoznanie powierzchni ataku

Rekonesans służy zebraniu informacji o systemach, aplikacjach i ich otoczeniu. W zależności od celu testu obejmuje m.in. identyfikację domen, publicznie dostępnych usług, używanych technologii oraz powiązań między elementami infrastruktury. Pozwala ustalić, które zasoby mogą stanowić punkt wejścia i gdzie warto skoncentrować dalsze działania.

Rozpoznanie pasywne korzysta ze źródeł, które nie wymagają bezpośredniej interakcji z badanym systemem, np. publicznych rejestrów i wyszukiwarek. Rozpoznanie aktywne wiąże się już z wysyłaniem zapytań do infrastruktury objętej testem. Różnica ma znaczenie praktyczne: aktywne działania mogą zostać odnotowane przez mechanizmy monitorowania i wymagają kontroli intensywności ruchu.

Skanowanie — identyfikacja usług i potencjalnych słabości

Na tym etapie testerzy dokładniej badają dostępne zasoby: sprawdzają otwarte porty, rozpoznają usługi i analizują konfigurację oraz zachowanie aplikacji. Szukają przesłanek wskazujących na podatności, takich jak nieaktualne komponenty, niewłaściwe ustawienia zabezpieczeń czy niepotrzebnie udostępnione funkcje.

Wynik skanowania jest wskazówką do dalszej weryfikacji, a nie automatycznym potwierdzeniem luki. Sam numer wersji oprogramowania nie przesądza o możliwości ataku — znaczenie mają również zastosowane poprawki, konfiguracja i dodatkowe zabezpieczenia. Tester ocenia więc wyniki w kontekście konkretnego środowiska, zamiast traktować wszystkie alerty jako równie istotne.

Eksploatacja — kontrolowane potwierdzenie podatności

Eksploatacja polega na sprawdzeniu, czy rozpoznaną słabość można rzeczywiście wykorzystać do naruszenia bezpieczeństwa. Może to oznaczać próbę obejścia kontroli dostępu, wykonania niedozwolonej operacji albo uzyskania dostępu do zasobu, który powinien pozostawać chroniony. W aplikacji biznesowej takim sprawdzianem może być weryfikacja, czy użytkownik potrafi odczytać dokument należący do innego konta.

Celem nie jest wywołanie możliwie dużych szkód, lecz uzyskanie wystarczającego potwierdzenia przy minimalnej ingerencji. Jeśli skuteczność ataku można wykazać na danych testowych lub pojedynczym, uzgodnionym przykładzie, nie ma potrzeby pobierania całych zbiorów informacji. Próby grożące zakłóceniem dostępności wymagają odrębnej zgody i odpowiednich warunków.

Post-exploitation — ocena skutków uzyskanego dostępu

Po skutecznym wykorzystaniu podatności tester sprawdza, co faktycznie umożliwia zdobyty dostęp. W granicach upoważnienia może zweryfikować możliwość podniesienia uprawnień, dotarcia do innych systemów lub uzyskania dostępu do wrażliwych informacji. Ten etap pomaga odróżnić błąd o ograniczonym wpływie od słabości, która otwiera drogę do poważniejszego naruszenia.

Istotne są także zależności między podatnościami: kilka pozornie mniej znaczących problemów może razem stworzyć skuteczną ścieżkę ataku. Fazy techniczne nie zawsze przebiegają więc liniowo — nowe ustalenia mogą wymagać ponownego rozpoznania lub dodatkowej weryfikacji. Uzyskanie dostępu nie oznacza jednak zgody na nieograniczone działania, a pozostawianie mechanizmów trwałego dostępu nie jest domyślnym elementem pentestu.

Raport z pentestu: dowody, ocena ryzyka i rekomendacje naprawcze

Raport z testu penetracyjnego powinien odpowiadać na trzy pytania: co udało się potwierdzić, jakie zagrożenie wynika z tego dla organizacji i jak je ograniczyć. Sama lista podatności nie wystarcza. Wartość dokumentu polega na przełożeniu ustaleń technicznych na konkretne decyzje: które poprawki wdrożyć najpierw, komu je przypisać i jak sprawdzić ich skuteczność.

Dobry raport uwzględnia potrzeby dwóch grup odbiorców. Część zarządcza przedstawia najważniejsze zagrożenia oraz ich możliwe konsekwencje biznesowe, np. ujawnienie danych klientów lub przerwę w działaniu usługi. Część techniczna dostarcza administratorom i programistom informacji potrzebnych do odtworzenia problemu oraz jego usunięcia. Dokument powinien też jasno wskazywać zakres i ograniczenia badania — brak wykrytych podatności nie jest gwarancją pełnego bezpieczeństwa.

Dowody potwierdzające podatność

Każde ustalenie powinno być poparte materiałem, który pokazuje rzeczywiste zachowanie badanego systemu. Mogą to być zanonimizowane zrzuty ekranu, fragmenty odpowiedzi aplikacji, zapisy żądań HTTP lub odpowiednie wyciągi z logów. Kluczowa jest możliwość odróżnienia potwierdzonej podatności od przypuszczenia wymagającego dalszej weryfikacji.

Opis pojedynczego ustalenia powinien obejmować:

• Miejsce występowania problemu — konkretny komponent, zasób lub funkcję aplikacji.
• Warunki wykorzystania — np. wymagane uprawnienia użytkownika albo dostęp do sieci wewnętrznej.
• Kroki odtworzenia i dowód — informacje wystarczające do kontrolowanego potwierdzenia błędu przez uprawniony zespół.
• Wykazany skutek — co tester faktycznie osiągnął, z wyraźnym oddzieleniem tego od potencjalnych, nieweryfikowanych konsekwencji.

Materiał dowodowy nie powinien ujawniać więcej danych, niż jest to niezbędne. Hasła, tokeny i dane osobowe należy odpowiednio zamaskować, a sam raport przekazać bezpiecznym kanałem i udostępnić wyłącznie upoważnionym osobom.

Ocena ryzyka i priorytety napraw

Ocena techniczna, np. punktacja CVSS, pomaga porównywać wagę podatności, ale nie zastępuje oceny ryzyka w kontekście konkretnej organizacji. Priorytet naprawy zależy również od dostępności systemu z internetu, znaczenia przetwarzanych danych, wymaganych uprawnień i istniejących zabezpieczeń. Znaczenie ma także możliwość połączenia kilku pozornie mniej istotnych błędów w jeden skuteczny scenariusz ataku.

Raport powinien uzasadniać przyznany poziom ryzyka, zamiast ograniczać się do etykiet „krytyczne”, „wysokie” czy „średnie”. Dzięki temu zespół może ustalać kolejność prac na podstawie rzeczywistego zagrożenia, a nie wyłącznie wartości liczbowej.

Rekomendacje, które można wdrożyć i zweryfikować

Zalecenie „poprawić zabezpieczenia” nie daje podstaw do działania. Rekomendacja powinna wskazywać przyczynę problemu i sposób jej usunięcia, np. wdrożenie kontroli uprawnień po stronie serwera dla każdego dostępu do wskazanego zasobu. Jeśli trwała poprawka wymaga czasu, warto osobno opisać zabezpieczenie tymczasowe i wyjaśnić jego ograniczenia.

Istotne są również kryteria potwierdzenia naprawy. Retest, czyli ponowna weryfikacja wskazanych ustaleń, sprawdza skuteczność wdrożonych zmian — samo zgłoszenie zakończenia prac nie dowodzi usunięcia podatności. Wynik takiej weryfikacji powinien jasno wskazywać, które problemy usunięto, które rozwiązano częściowo, a które nadal występują.

Kiedy i jak często firma powinna zlecać pentesty?

Termin testu penetracyjnego warto powiązać z momentem, w którym jego wyniki pozwolą jeszcze ograniczyć ryzyko: przed uruchomieniem ważnej usługi, po istotnej zmianie w systemie lub podczas okresowej oceny bezpieczeństwa. Sam kalendarz nie wystarczy — aplikacja rozwijana co tydzień wymaga innego harmonogramu weryfikacji niż rzadko modyfikowany system wewnętrzny.

Jak ustalić częstotliwość testów?

Dla wielu organizacji rozsądnym punktem wyjścia jest pentest kluczowych systemów raz w roku, uzupełniany testami po zmianach istotnych dla bezpieczeństwa. Nie jest to jednak uniwersalna norma ani gwarancja wystarczającej ochrony. Częstotliwość należy uzależnić od dostępności systemu z internetu, wrażliwości przetwarzanych danych, tempa rozwoju oprogramowania oraz skutków ewentualnego włamania lub przestoju.

Usługi obsługujące płatności, dane klientów czy procesy krytyczne dla działalności mogą wymagać częstszych testów, na przykład co pół roku lub co kwartał. W stabilnych środowiskach o niższym ryzyku harmonogram może wyglądać inaczej, ale powinien wynikać z udokumentowanej oceny ryzyka, a nie wyłącznie z ograniczeń budżetowych. Trzeba też sprawdzić wymagania właściwe dla organizacji: branżowe, umowne i regulacyjne. Mogą one określać zarówno częstotliwość badań, jak i zdarzenia wymagające dodatkowej weryfikacji.

Kiedy nie warto czekać na kolejny zaplanowany pentest?

• Przed wdrożeniem nowej aplikacji lub usługi — najlepiej wtedy, gdy jest już gotowa do miarodajnych testów, ale pozostaje czas na poprawki przed udostępnieniem jej użytkownikom.
• Po istotnych zmianach technicznych — na przykład migracji do chmury, przebudowie mechanizmu logowania, zmianie uprawnień lub dodaniu integracji z zewnętrznym systemem.
• Po przejęciu firmy lub połączeniu środowisk IT — nowe połączenia i zależności mogą zmienić poziom ryzyka, nawet jeśli poszczególne systemy były wcześniej badane.
• Po incydencie bezpieczeństwa — gdy sytuacja została opanowana, a przyczyny rozpoznane. Pentest może pomóc zweryfikować skuteczność zabezpieczeń, ale nie zastępuje obsługi incydentu ani analizy powłamaniowej.

Osobny termin należy przewidzieć na retest po usunięciu wykrytych podatności. Nie trzeba z nim czekać do następnego corocznego badania: jego celem jest sprawdzenie, czy konkretne poprawki rzeczywiście wyeliminowały problem. Przy podatnościach wysokiego ryzyka taka weryfikacja powinna mieć odpowiednio wysoki priorytet.

Najbardziej praktyczne podejście łączy więc stały harmonogram z testami uruchamianymi po ważnych zmianach. Wynik pentestu opisuje bezpieczeństwo badanego środowiska w określonym czasie — nie daje bezterminowego potwierdzenia odporności na atak.

Aspekty prawne, zgody i odpowiedzialność – jak zadbać o bezpieczeństwo testów penetracyjnych?

O tym, czy test penetracyjny jest uprawnionym działaniem, nie decyduje sam zamiar poprawy bezpieczeństwa. Kluczowe jest uzyskanie zgody podmiotu uprawnionego do jej udzielenia oraz przestrzeganie granic tej zgody. Dostęp do panelu administracyjnego czy zlecenie od pracownika firmy nie oznaczają automatycznie prawa do testowania wszystkich powiązanych systemów. W Polsce działania podejmowane bez uprawnienia mogą, zależnie od okoliczności, prowadzić do odpowiedzialności karnej, między innymi na podstawie przepisów dotyczących nieuprawnionego dostępu do informacji i zakłócania pracy systemów informatycznych.

Umowa, upoważnienie i ROE – różne funkcje dokumentów

Dokumentacja powinna jednoznacznie określać, kto zleca testy, kto może je wykonywać i jakie działania są dozwolone. Umowa reguluje współpracę, w tym poufność i odpowiedzialność stron. Upoważnienie potwierdza zgodę na konkretne czynności wobec wskazanych zasobów. Z kolei ROE (Rules of Engagement) określa operacyjne zasady prowadzenia testów. Te ustalenia mogą znajdować się w jednym dokumencie lub w powiązanych załącznikach — istotna jest ich treść, a nie sama nazwa.

Z perspektywy bezpieczeństwa i odpowiedzialności ROE powinno rozstrzygać przede wszystkim:

• jakie działania są zabronione lub wymagają dodatkowej zgody, np. próby przeciążenia usług, socjotechnika czy modyfikacja danych;
• kiedy należy natychmiast przerwać testy i kto może podjąć taką decyzję;
• jak zgłaszać awarie, nieoczekiwany dostęp do danych lub oznaki rzeczywistego włamania;
• jak zabezpieczać, przekazywać i usuwać informacje pozyskane podczas prac.

Jeśli przygotowanie bezpiecznych testów penetracyjnych jest dla Ciebie ważne – w Cognity pokazujemy, jak przełożyć te zasady na praktyczne działania.

Zasoby zewnętrzne i dane osobowe

Zgoda klienta nie musi obejmować infrastruktury dostawcy chmury, operatora hostingu ani zewnętrznej usługi połączonej z badaną aplikacją. Przed rozpoczęciem działań trzeba zweryfikować uprawnienia zlecającego oraz warunki dostawców. Niektórzy dopuszczają określone testy na zasadach opisanych w regulaminie, inni wymagają zgłoszenia lub osobnej akceptacji. Powiązanie techniczne z testowanym systemem nie jest równoznaczne z objęciem zasobu zgodą.

Jeżeli pentest wiąże się z przetwarzaniem danych osobowych, należy ustalić role stron i obowiązki wynikające z RODO. Gdy wykonawca działa jako podmiot przetwarzający, potrzebna jest umowa powierzenia zgodna z art. 28 RODO. Niezależnie od tego należy ograniczać dostęp do danych do niezbędnego minimum, zabezpieczać materiał dowodowy oraz ustalić okres jego przechowywania. Sama zgoda na pentest nie zastępuje podstawy prawnej przetwarzania danych.

Odpowiedzialność za skutki testów

Nawet autoryzowany pentest może spowodować zakłócenia. Umowa powinna jasno określać obowiązki stron, zasady reagowania na szkody i odpowiedzialność za przekroczenie uzgodnionych granic. Nie należy traktować ogólnej klauzuli o „testowaniu na ryzyko klienta” jako pełnego wyłączenia odpowiedzialności. Bezpieczna praktyka polega na wykazaniu podatności przy możliwie małej ingerencji: uprawnienie do sprawdzenia zabezpieczeń nie oznacza przyzwolenia na dowolne kopiowanie danych czy powodowanie przestojów.

DOE w Six Sigma – jak planowanie eksperymentów wspiera doskonalenie procesów? 24 października 2026

Metodyka DMAIC – pięć etapów doskonalenia procesów krok po kroku 22 października 2026