Przygotowanie organizacji do testu penetracyjnego¶

Test penetracyjny, potocznie nazywany pentestem, to kontrolowane i autoryzowane badanie bezpieczeństwa systemu. Tester sprawdza, czy wykryte słabości można wykorzystać do uzyskania dostępu do cudzych danych, przejęcia konta, podniesienia uprawnień albo zakłócenia ważnego procesu. W zależności od celu może także łączyć kilka pozornie mniej istotnych problemów w jeden scenariusz ataku. Testerzy działają za zgodą organizacji, w ustalonym czasie i według wcześniej przyjętych zasad. Dlatego wartość pentestu zależy nie tylko od wiedzy wykonawcy, ale również od przygotowania zamawiającego. Przed rozpoczęciem prac trzeba ustalić cel, zakres i ograniczenia testu, wskazać osoby kontaktowe, przygotować dostępy oraz uzgodnić sposób zgłaszania i obsługi wykrytych podatności.

Poniższy artykuł "Przygotowanie organizacji do testu penetracyjnego" omawia cały ten proces - od określenia celu i wyboru wykonawcy po wykonanie raportu, wprowadzenie poprawek i przeprowadzenie retestów. Przykłady dotyczą aplikacji webowych, API, aplikacji mobilnych oraz infrastruktury, ale opisane zasady można dostosować także do innych technologii. Tekst jest przeznaczony przede wszystkim dla właścicieli systemów, osób zamawiających usługę, zespołów IT, działów prawnych oraz osób odpowiedzialnych za bezpieczeństwo.

Pentest nie potwierdza bezpieczeństwa całej organizacji

Wynik dotyczy konkretnych systemów, wersji i środowisk objętych zakresem w czasie prowadzenia testu. Brak wykrytych podatności nie gwarantuje, że system pozostanie bezpieczny ani że nie zawiera innych, niewykrytych słabości. Pentest nie zastępuje aktualizacji, monitoringu, bezpiecznego tworzenia oprogramowania ani regularnego zarządzania podatnościami.

Nomenklatura

Ocena bezpieczeństwa (ang. security assessment) to szerokie pojęcie, które może obejmować między innymi przegląd architektury, konfiguracji, kodu i dokumentacji. Test penetracyjny jest jedną z form takiej oceny. Polega na aktywnym sprawdzaniu, czy zabezpieczenia można obejść, a wykryte słabości wykorzystać w uzgodnionym zakresie. Skanowanie podatności jest natomiast w dużej mierze zautomatyzowane. Skaner może potwierdzić występowanie niektórych problemów, ale zwykle nie ocenia logiki biznesowej ani nie łączy ustaleń tak jak tester. Dlatego przy zamawianiu usługi nie wystarczy jej nazwa. Trzeba jasno ustalić, czy przedmiotem prac jest pentest, skanowanie podatności, przegląd konfiguracji, analiza kodu czy połączenie kilku metod.

Cel i kryteria testu¶

Pierwszym krokiem jest odpowiedź na pytanie, w jakim celu organizacja zleca pentest. Ogólna informacja „chcemy sprawdzić bezpieczeństwo” nie wystarcza do dobrania właściwego zakresu, czasu ani sposobu prowadzenia prac.

Przykładowe cele:

sprawdzenie aplikacji przed jej uruchomieniem,
ocena usług dostępnych z Internetu,
sprawdzenie, czy użytkownik może zobaczyć dane innej osoby,
ocena możliwości uzyskania uprawnień administratora,
sprawdzenie skutków przejęcia zwykłego konta pracownika,
ocena bezpieczeństwa po dużej zmianie systemu,
potwierdzenie usunięcia problemów z wcześniejszego raportu.

Dobry cel wskazuje nie tylko badany system, lecz także najważniejszy skutek, któremu organizacja chce zapobiec. W przypadku portalu klienta może nim być na przykład sprawdzenie, czy zwykły użytkownik jest w stanie odczytać lub zmienić dane innego klienta. Tak sformułowany cel ułatwia później ocenę, czy zakres i dostępny czas wystarczą do zbadania najważniejszych scenariuszy. Trzeba również uwzględnić zależności między systemami. Aplikacja mobilna może korzystać z tego samego komponentu co portal webowy, a logowanie może obsługiwać osobna usługa weryfikacji tożsamości. Pominięcie takiej zależności może sprawić, że test nie obejmie elementu kluczowego dla bezpieczeństwa całej usługi. Przy ograniczonym budżecie priorytet powinien wynikać z ryzyka. Znaczenie ma nie tylko dostępność systemu z Internetu, ale także rodzaj przetwarzanych danych, poziom uprawnień, krytyczność procesu, ostatnie zmiany oraz możliwy wpływ awarii lub przejęcia systemu na organizację.

Zakres testu¶

Zakres wyznacza granice zlecenia: określa zasoby, środowiska, funkcje i czas prowadzenia testu. Powinien być jednoznaczny zarówno dla właściciela systemu, jak i dla wykonawcy.

Zakres może zawierać:

nazwy aplikacji i numery wersji,
adresy stron, API i paneli administracyjnych,
domeny, subdomeny i publiczne adresy IP,
zakresy adresów sieci wewnętrznej,
aplikacje Android i iOS,
konta lub projekty chmurowe,
sieci bezprzewodowe,
środowisko testowe lub produkcyjne,
okres i godziny prowadzenia prac.

W tym samym dokumencie należy wymienić elementy wyłączone z badania. Mogą to być szczególnie wrażliwe systemy, urządzenia przemysłowe, zasoby dostawców albo funkcje, których nie wolno uruchamiać podczas testu. Należy unikać określeń takich jak „cała infrastruktura”, „wszystkie aplikacje” albo „domena organizacji”. Nie wyjaśniają one, czy test obejmuje subdomeny, usługi chmurowe, systemy dostawców i środowiska testowe. Jeżeli tester odkryje problem w systemie spoza zakresu, powinien przerwać działania dotyczące tego zasobu i skontaktować się z koordynatorem. Rozszerzenie zakresu wymaga pisemnej zgody upoważnionej osoby.

Modele black box, gray box i white box¶

Określenia black box, gray box i white box opisują ilość informacji oraz rodzaj dostępu przekazanego testerowi. Ich znaczenie może się różnić, dlatego w zleceniu trzeba opisać konkretne materiały i konta, a nie polegać wyłącznie na nazwie modelu.

Black box oznacza test z niewielką ilością informacji o systemie. Pozwala rozpocząć pracę z perspektywy osoby z Internetu, która nie ma konta ani dokumentacji. Trzeba jednak pamiętać, że część czasu zostanie przeznaczona na rozpoznanie, więc mniej czasu pozostanie na badanie funkcji dostępnych po zalogowaniu i logiki biznesowej.

Gray box daje testerowi wybrane informacje, dokumentację i konta testowe. Ten model dobrze sprawdza się wtedy, gdy ważne są role użytkowników, uprawnienia i procesy dostępne po zalogowaniu. Jest często stosowany np. w testach aplikacji webowych i API, ponieważ pozwala wykorzystać czas na dokładniejsze sprawdzenie istotnych funkcji.

White box zapewnia szeroki dostęp do wiedzy o systemie, na przykład do opisu architektury, konfiguracji lub kodu źródłowego. Ułatwia znalezienie problemów trudnych do zauważenia z zewnątrz. Samo przekazanie kodu nie oznacza jednak, że wykonawca przeprowadzi pełny przegląd kodu lub konfiguracji. Jeżeli organizacja tego oczekuje, trzeba zapisać takie zadanie w zakresie i przeznaczyć na nie odpowiedni czas.

Uwaga

Black box nie jest automatycznie lepszym ani bardziej realistycznym modelem testu. Model należy dobrać do celu, a w ramach jednego zlecenia można je łączyć. Test może zacząć się krótkim etapem black box, a następnie przejść do gray box z kontami użytkowników i dokumentacją API.

Wybór środowiska pod przeprowadzenie testów¶

Środowisko testowe ogranicza ryzyko zakłócenia usługi i pozwala korzystać z danych testowych. Musi jednak możliwie dobrze odzwierciedlać środowisko produkcyjne w obszarach istotnych dla bezpieczeństwa, takich jak wersja aplikacji, konfiguracja, uwierzytelnianie, reguły sieciowe i ważne integracje. Test starej lub uproszczonej kopii systemu może dać fałszywe poczucie bezpieczeństwa.

Środowisko produkcyjne pokazuje rzeczywisty stan zabezpieczeń, ale zwiększa ryzyko operacyjne. Test może wywołać alarmy, zablokować konta, wysyłać wiadomości, utworzyć dane albo zwiększyć obciążenie. Często rozsądnym rozwiązaniem jest dokładny test na reprezentatywnym środowisku testowym oraz ograniczona weryfikacja najważniejszych elementów na produkcji. Wybór powinien wynikać z celu i zostać zapisany w zakresie.

Przed testem systemu produkcyjnego

Przed rozpoczęciem prac na produkcji trzeba sprawdzić aktualność kopii zapasowych i możliwość odtworzenia usługi, uruchomić monitoring oraz wskazać osobę, która może zatrzymać test lub rozpocząć przywracanie systemu. Samo stwierdzenie „mamy backup” nie wystarcza, jeżeli procedura odtworzenia nie została sprawdzona.

Uczestnicy¶

W przygotowaniu pentestu powinni uczestniczyć przedstawiciele zespołu bezpieczeństwa, zespołu technicznego oraz gdy wymaga tego sytuacja działu prawnego i osób odpowiedzialnych za ochronę danych. W mniejszej organizacji te zadania mogą wykonywać te same osoby albo zewnętrzny dostawca. Najważniejsze jest jasne przypisanie odpowiedzialności.

Minimalne role po stronie organizacji¶

osoba koordynująca i decyzyjna - zatwierdza cel i zakres, utrzymuje kontakt z wykonawcą oraz może zatrzymać test,
kontakt techniczny - przygotowuje konta i dostęp, zna badany system i pomaga usuwać przeszkody podczas testu.

Informacyjnie

Obie role może pełnić jedna osoba, jeżeli ma odpowiednią wiedzę i upoważnienie do podejmowania decyzji.

Role zależne od sytuacji¶

właściciel biznesowy - gdy test może wpłynąć na ważną usługę,
osoba odpowiedzialna za kwestie prawne lub ochronę danych - gdy test dotyczy danych chronionych albo umów z dostawcami,
osoba odpowiedzialna za monitoring lub obsługę incydentów - gdy test może generować alarmy w systemach organizacji,
dostawca systemu - jeżeli organizacja nie zarządza nim samodzielnie.

Jeżeli pentest może wywołać alerty, osoby obsługujące monitoring powinny znać termin testu, jego zakres i uzgodnione adresy źródłowe. Dzięki temu mogą oznaczyć pasujące alerty jako autoryzowaną aktywność, wyciszyć ściśle wskazane powiadomienia albo obsłużyć je zgodnie z wewnętrzną procedurą. Nie powinny jednak z góry ignorować wszystkich zdarzeń. Alert, który nie pasuje do ustaleń, może oznaczać prawdziwy incydent.

Jeżeli jednym z celów jest sprawdzenie zdolności wykrywania i reagowania, krąg poinformowanych osób może być mniejszy. Taki wariant trzeba jednak wyraźnie uzgodnić. Zwykły pentest nie jest automatycznie ćwiczeniem red team (symulacją pełnego ataku na organizacje).

Ważne

Przed rozpoczęciem prac trzeba ustalić podstawowy i awaryjny sposób kontaktu. Krytycznej podatności ani niedostępności usługi nie należy zgłaszać wyłącznie drogą mailową. W takim przypadku wykonawca powinien użyć również uzgodnionego kanału bezpośredniego, na przykład telefonu.

Wybór wykonawcy i wymagania wobec raportu¶

Doświadczenie wykonawcy powinno odpowiadać zakresowi zlecenia. Test aplikacji mobilnej, infrastruktury sieciowej i systemu przemysłowego wymaga różnych kompetencji. Przed podpisaniem umowy warto zapytać wykonawcę o:

doświadczenie osób, które rzeczywiście przeprowadzą test,
stosowaną metodykę,
udział analizy manualnej, a nie tylko automatycznego skanowania,
zanonimizowany przykład raportu,
sposób ochrony danych i materiałów,
sposób oceny podatności,
czas zgłoszenia krytycznego problemu,
warunki retestu.

W testach aplikacji webowych i usług HTTP punktem odniesienia może być OWASP Web Security Testing Guide (WSTG), a w przypadku aplikacji mobilnych OWASP Mobile Application Security Testing Guide (MASTG). W umowie lub planie testu warto podać nazwę i wersję uzgodnionego materiału. Metodyka porządkuje pracę, ale nie może być "mechaniczną" listą wykonywaną w identyczny sposób dla każdego systemu. Tester powinien dostosować techniki do architektury, technologii i najważniejszych procesów organizacji.

Wymagania wobec raportu¶

Zakres i format raportu należy uzgodnić przed podpisaniem umowy. Dokument powinien być czytelny zarówno dla osób podejmujących decyzje, jak i dla zespołów wdrażających poprawki. Powinien zawierać:

podsumowanie dla kierownictwa opisujące najważniejsze problemy i ich możliwy wpływ na organizację,
cel, zakres, wyłączenia, daty, badane wersje i środowiska,
opis metodyki, ograniczeń oraz zmian zakresu wprowadzonych podczas testu,
zestawienie ustaleń według ważności,
opis każdej podatności wraz z warunkami wykorzystania, dowodami i krokami odtworzenia,
ocenę techniczną wraz z uzasadnieniem oraz opisem możliwego wpływu,
jasne zalecenia naprawcze,
opis połączonych ścieżek ataku, jeżeli w wyniku połączenia kilku błędów/problemów udaje się utworzyć wektor ataku,
informację o obszarach, których nie udało się sprawdzić.

Ocena wykonawcy jest ważnym wkładem, ale nie zastępuje decyzji organizacji

Właściciel systemu zna znaczenie danych i procesów oraz istniejące zabezpieczenia, które mogą zmniejszać albo zwiększać rzeczywisty wpływ problemu. Raport z przeprowadzonych testów zawiera informacje, które mogą ułatwić atak, dlatego powinien zostać przekazany szyfrowanym kanałem i udostępniony tylko osobom, które go potrzebują i podejmą decyzję odnośnie propozycji poprawek dla problemów w nim zawartych.

Uzgodnienia prawne i formalne¶

Test penetracyjny obejmuje działania, które bez zgody podmiotu uprawnionego do decydowania o systemie mogłyby zostać uznane za nieuprawnione. Pisemne upoważnienie jest więc podstawą rozpoczęcia prac. Dokładny zestaw dokumentów zależy od organizacji, rodzaju danych, umów i właściwych przepisów. Powinien go potwierdzić dział prawny lub inna upoważniona osoba. Zwykle przygotowanie obejmuje poniższe elementy.

Pisemna zgoda na test powinna zawierać:

organizację zlecającą test,
wykonawcę i osoby upoważnione do prowadzenia prac,
systemy objęte zakresem,
termin oraz dozwolone godziny,
działania dozwolone i zabronione,
osobę mogącą zatwierdzić zmianę zakresu.

Zgody musi udzielić podmiot, który ma prawo decydować o danym systemie. Organizacja może zlecić na przykład test własnej aplikacji działającej w chmurze, ale nie może bez odpowiedniej zgody rozszerzyć go na wspólną infrastrukturę operatora ani systemy dostawcy płatności, hostingu lub innej usługi.

Poufność, odpowiedzialność i ochrona materiałów. Umowa powinna opisywać zakres usługi, termin, sposób raportowania i zasady odpowiedzialności. W zależności od sytuacji potrzebne będzie również zobowiązanie do zachowania poufności.

Umowa powinna zawierać zapisy dotyczące:

osób mających dostęp do raportu i materiałów roboczych,
sposobu szyfrowania i przekazywania dokumentów,
miejsca przetwarzania dokumentów,
czasu ich przechowywania,
sposobu i terminu usunięcia materiałów,
postępowania w razie przypadkowego ujawnienia danych lub informacji.

Dostęp do danych osobowych a testy penetracyjne

Jeżeli tester może uzyskać dostęp do danych osobowych, organizacja powinna uzgodnić z osobą odpowiedzialną za ochronę danych, jakie dodatkowe zasady są potrzebne. Tam, gdzie to możliwe, warto korzystać z danych testowych. Jeżeli test może dotknąć danych rzeczywistych, należy ograniczyć ich przeglądanie i utrwalanie do minimum potrzebnego do wykazania problemu oraz ustalić sposób anonimizacji dowodów.

Zgody dostawców zewnętrznych. Przed testem trzeba sprawdzić umowy i regulaminy dostawców chmury, hostingu, CDN, usług pocztowych i innych komponentów. Niektórzy dostawcy wymagają wcześniejszego zgłoszenia, ograniczają wybrane techniki albo oczekują podania adresów, z których połączy się tester.

Reguły prowadzenia testu. Rules of Engagement określają sposób prowadzenia prac, dozwolone metody i ograniczenia. Techniki podwyższonego ryzyka, takie jak testy DoS, password spraying, socjotechnika lub testy fizyczne, mogą być użyte tylko wtedy, gdy zostały wyraźnie uzgodnione. Reguły powinny zawierać:

dokładne cele i funkcje wyłączone z testów,
adresy sieciowe używane przez testerów,
dokładny termin,
dopuszczalną granicę wykorzystania podatności,
zakaz niszczenia danych i instalowania trwałego dostępu, jeżeli nie uzgodniono inaczej,
zasady testów mogących zablokować konta lub zwiększyć obciążenie,
warunki natychmiastowego zatrzymania prac,
kanał zgłaszania krytycznej podatności oraz kanał którym przesłany będzie raport z wykonanych prac,
zasady zakończenia i porządkowania środowiska po teście.

Granica wykorzystania podatności powinna być opisana konkretnie. Może oznaczać na przykład odczyt jednego rekordu zamiast pobrania całej bazy albo utworzenie pliku kontrolnego zamiast instalowania trwałego dostępu.

Przygotowanie materiałów dla wykonawcy¶

Zakres przekazywanych materiałów zależy od wybranego modelu testu. Nawet w wariancie black box organizacja powinna jednak przygotować te informacje wewnętrznie, aby móc szybko odpowiedzieć na problemy i upewnić się, że wykonawca nie przekroczy granic zlecenia.

Najczęściej potrzebne będą:

krótki opis systemu i jego znaczenia dla organizacji,
prosty diagram pokazujący główne elementy i połączenia,
lista technologii i dostawców, jeśli ma zostać przekazana w wybranym modelu,
opis najważniejszych funkcji oraz procesów,
instrukcja logowania,
konta testowe dla potrzebnych ról,
dane testowe,
wyniki wcześniejszych testów lub skanów,
informacje o znanych ograniczeniach i systemach wrażliwych,
bezpieczny sposób przekazania haseł, kluczy i innych sekretów.

Do testów uprawnień zwykle potrzebne są co najmniej dwa konta tej samej roli oraz konta ról o różnych poziomach dostępu. Pozwala to sprawdzić zarówno dostęp między użytkownikami, jak i możliwość podniesienia uprawnień. Hasła i klucze powinny mieć ograniczoną ważność, zostać przekazane bezpiecznym kanałem i unieważnione po zakończeniu prac.

Przygotowanie bezpośrednio przed startem¶

Kilka dni przed testem warto zorganizować krótkie spotkanie otwierające. Wykonawca i organizacja powinni potwierdzić:

ostateczny zakres i wyłączenia,
termin, godziny i strefę czasową,
działanie kont, VPN i aplikacji testowych,
adresy, z których połączy się tester,
gotowość danych i integracji testowych,
stan kopii zapasowych i monitoringu,
kontakty podstawowe oraz awaryjne,
sposób zgłaszania krytycznych problemów,
sposób klasyfikowania alertów wywołanych przez pentest,
warunki natychmiastowego przerwania prac.

Na czas testu warto uzgodnić okno bez wdrożeń i zmian konfiguracji w badanym środowisku. Każdą konieczną zmianę trzeba zgłosić wykonawcy, ponieważ może wpłynąć na wynik lub utrudnić odtworzenie znalezionego problemu.

Wymagane działania po przeprowadzonych testach¶

Po otrzymaniu raportu organizacja powinna:

zweryfikować ustalenia z wykonawcą i ocenić ich wpływ na własne procesy oraz dane,
przypisać każdej poprawce właściciela, priorytet i termin,
zapisać decyzje o akceptacji ryzyka wraz z uzasadnieniem i terminem ponownego przeglądu,
sprawdzić, czy ten sam rodzaj problemu występuje w innych systemach,
zamówić retest po wprowadzeniu poprawek,
zamknąć konta i dostępy testowe oraz usunąć pozostałe artefakty,
uzyskać potwierdzenie usunięcia materiałów przez wykonawcę, jeżeli przewiduje to umowa.

Retest dotyczy ustaleń z wcześniejszego raportu i nie jest automatycznie ponownym wykonaniem całego pentestu. Powinien jednak sprawdzić istotne warianty naprawionego problemu oraz połączone ścieżki ataku, jeżeli kilka podatności prowadziło do wspólnego skutku. Wynik retestu powinien jednoznacznie wskazywać, które ustalenia naprawiono, które naprawiono częściowo, które pozostają aktualne, a których nie można było zweryfikować.

Dodatkowe działania

Warto również ustalić, dlaczego problem nie został wykryty wcześniej. Czasem potrzebna będzie zmiana procesu tworzenia oprogramowania, częstsze skanowanie, przegląd konfiguracji albo lepszy monitoring. W ten sposób wyniki testu pomagają poprawić cały proces, a raport nie trafia po prostu do archiwum.

Lista kontrolna przed rozpoczęciem¶

Organizacja jest przygotowana, gdy:

określono cel testu i najważniejsze scenariusze,
zapisano dokładny zakres i wyłączenia,
wybrano model black box, gray box, white box albo ich połączenie,
wybrano środowisko testowe, produkcyjne lub oba,
wskazano osobę koordynującą i kontakt techniczny,
potwierdzono doświadczenie wykonawcy i uzgodniono zawartość raportu,
potwierdzono prawo do testowania wszystkich zasobów,
uzyskano zgody dostawców, jeżeli są wymagane,
podpisano upoważnienie i uzgodniono Rules of Engagement,
ustalono poufność, ochronę danych i termin usunięcia materiałów,
przygotowano informacje, dostępy i dane potrzebne w wybranym modelu,
sprawdzono VPN i inne potrzebne połączenia (jeśli wymagane),
potwierdzono aktualność kopii zapasowych oraz możliwość odtworzenia systemu lub środowiska,
uruchomiono monitoring i przygotowano kontakty awaryjne,
poinformowano właściwe osoby, jak rozpoznawać i klasyfikować alerty związane z testem,
ustalono sposób zgłaszania krytycznych problemów,
uzgodniono bezpieczny sposób przekazania raportu,
zaplanowano obsługę poprawek oraz retest.

Podsumowanie¶

Dobre przygotowanie do pentestu obejmuje znacznie więcej niż przekazanie listy adresów. Organizacja musi wiedzieć, czego chce się dowiedzieć, jakie systemy oddaje do sprawdzenia i kto może podejmować decyzje w czasie prac. Potrzebne są również pisemne zgody, jasne reguły, działające kontakty, przygotowane dostępy oraz plan obsługi wyników. Jeżeli dokładnego zakresu nie da się ustalić samodzielnie, warto przeprowadzić warsztat z potencjalnym wykonawcą i właścicielami systemów. Jego wynikiem powinien być opis usługi, granice testu, wymagane materiały, harmonogram i oczekiwany raport. Dopiero wtedy można rzetelnie wycenić prace i rozpocząć pentest, którego wynik będzie rzeczywiście użyteczny dla organizacji.

Ostatnia aktualizacja artykułu: 2026-09-02.