Test penetracyjny – proces polegający na przeprowadzeniu kontrolowanego ataku na system teleinformatyczny, mający na celu praktyczną ocenę bieżącego stanu bezpieczeństwa tego systemu, w szczególności obecności znanych podatności i odporności na próby przełamania zabezpieczeń. Polega na analizie systemu pod kątem występowania potencjalnych błędów bezpieczeństwa spowodowanych niewłaściwą konfiguracją, lukami w oprogramowaniu lub sprzęcie, słabościami w technicznych lub proceduralnych środkach zabezpieczeń, a nawet niewystarczającą świadomością użytkowników. Analiza ta jest przeprowadzana z perspektywy potencjalnego włamywacza i może zawierać aktywne wykorzystywanie podatności (np. poprzez użycie exploitów). Podstawową cechą odróżniającą test penetracyjny od włamania jest zgoda atakowanej strony na tego rodzaju działania, ponadto osoba przeprowadzająca test (zwana pentesterem) jest zobowiązana do przedstawienia raportu dokumentującego znalezione problemy (często wraz ze sposobami ich usunięcia i rekomendacjami podnoszącymi bezpieczeństwo testowanego systemu). Test penetracyjny ma na celu zbadanie odporności systemu na włamanie oraz skuteczności zabezpieczeń w rzeczywistej konfiguracji lub w środowisku możliwie do niej zbliżonym.
Test penetracyjny jest pracochłonny i wymaga dużej wiedzy fachowej. Badane systemy mogą w jego trakcie zostać uszkodzone lub unieruchomione, a ryzyka tego nie da się całkowicie wyeliminować, choć doświadczeni testerzy mogą je ograniczyć. Z tego względu test powinien być poprzedzony starannym planowaniem.
Historia W 1974 roku Siły Powietrzne Stanów Zjednoczonych opublikowały wyniki analizy podatności systemu Multics, uważanego wówczas za najbezpieczniejszy dostępny system operacyjny. Analizę przeprowadzono w latach 1972–1973 na potrzeby ośrodka obliczeniowego Sił Powietrznych, który miał świadczyć usługi użytkownikom w Pentagonie na wszystkich poziomach klauzuli tajności. Jej autorzy, Paul Karger i Roger Schell, nie tylko szukali podatności, ale także umieścili w systemie celowo nieszkodliwą tylną furtkę, aby sprawdzić, czy zostanie wykryta podczas kontroli jakości. W samym raporcie wspomniano o niej jedynie ogólnikowo. Producent systemu, firma Honeywell, przekazał ją następnie wraz z oprogramowaniem m.in. do ośrodka obliczeniowego Sił Powietrznych w Pentagonie, a wykryto ją dopiero około roku po publikacji raportu. Analizę prowadzono z zasadą niewyrządzania rzeczywistych szkód w atakowanych systemach, a publikację raportu wstrzymano do czasu usunięcia opisanych podatności.
Ataki najpierw sprawdzano na instalacji systemu w Rome Air Development Center, a następnie przeprowadzano na systemie w Massachusetts Institute of Technology, starając się, tak jak prawdziwy agent, uzyskać lub zmienić chronione dane bez wykrycia przez administratorów. Raport przypominał też, że zabezpieczenia innych ówczesnych systemów, m.in. GCOS i IBM OS/360/370, wielokrotnie przełamywano w ćwiczeniach penetracyjnych, i zwracał uwagę, że zespół ekspertów testujący zabezpieczenia (tzw. tiger team) może wykazać istnienie podatności, ale nie jest w stanie dowieść ich braku.
Opisany w raporcie pomysł furtki w kompilatorze, która odtwarza się przy kompilowaniu samego kompilatora, zainspirował Kena Thompsona. Zrealizował on taką furtkę we wczesnej wersji systemu Unix i opisał ją w artykule Reflections on Trusting Trust z 1984 roku, związanym z otrzymaniem Nagrody Turinga. W 2002 roku Karger i Schell powtórzyli, że test penetracyjny może wskazać część podatności do usunięcia, ale to, że zespół testujący ich nie znalazł, nie oznacza, że ich nie ma.
Fazy testu penetracyjnego Wytyczne NIST SP 800-115 przedstawiają przykładowy podział testu penetracyjnego na cztery fazy, zastrzegając, że dopuszczalne są również inne sposoby grupowania wykonywanych czynności: planowanie – ustalenie zasad testu, uzyskanie i udokumentowanie zgody kierownictwa oraz określenie celów. W tej fazie nie prowadzi się jeszcze testów. rozpoznanie – zbieranie informacji o badanym środowisku, m.in. przez identyfikację portów i usług, zapytania do systemu DNS i bazy WHOIS oraz odczytywanie informacji o wersjach oprogramowania, a następnie analiza podatności, czyli porównanie wykrytych usług i systemów z bazami znanych podatności. atak – próba wykorzystania zidentyfikowanych podatności w celu ich potwierdzenia. Udany atak może umożliwić eskalację uprawnień i dostęp do kolejnych systemów, co prowadzi do ponownego rozpoznania. raportowanie – przedstawienie wykrytych podatności wraz z zaleceniami dotyczącymi ograniczenia ryzyka.
Metodyki testów penetracyjnych Testy penetracyjne prowadzi się w oparciu o metodyki, które nadają im powtarzalny, ustalony przebieg i pozwalają ograniczyć związane z nimi ryzyko. Poszczególne metodyki różnią się szczegółowością. PTES opisuje przebieg i organizację testu bez wytycznych technicznych, a jego autorzy określają go jako minimum wymagane od podstawowego testu penetracyjnego. Przewodnik OWASP zawiera natomiast opisy konkretnych testów. Do stosowanych metodyk należą m.in.:
OWASP Web Security Testing Guide (WSTG) – testy aplikacji webowych OWASP ASVS (Application Security Verification Standard) – wymagania bezpieczeństwa stosowane przy projektowaniu, tworzeniu i testowaniu aplikacji webowych i usług sieciowych (aktualna wersja 5.0.0 z maja 2025 roku) OWASP MASVS (Mobile Application Security Verification Standard) – testy aplikacji mobilnych PTES (The Penetration Testing Execution Standard) – testy infrastruktury sieciowej OWASP Top 10 for Large Language Model Applications – lista dziesięciu najpoważniejszych zagrożeń dla aplikacji wykorzystujących duże modele językowe, stanowiąca dokument uświadamiający dla ich twórców i specjalistów ds. bezpieczeństwa (aktualne wydanie z 2026 roku) OSSTMM (Open Source Security Testing Methodology Manual) NIST SP 800-42 (Guideline on Network Security Testing, 2003) – zastąpiony w 2008 roku przez NIST SP 800-115 NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) PCI DSS Penetration Testing Guidance – wytyczne PCI Security Standards Council dotyczące testów penetracyjnych wymaganych przez standard bezpieczeństwa danych kart płatniczych PCI DSS ISSAF (Information Systems Security Assessment Framework) organizacji OISSG
PTES Penetration Testing Execution Standard (PTES) opracowała grupa praktyków z instytucji finansowych, firm świadczących usługi bezpieczeństwa i producentów zabezpieczeń. Prace rozpoczęto na początku 2009 roku, po dyskusji o wartości testów penetracyjnych w branży, a celem było wypracowanie wspólnego języka i zakresu testów zarówno dla zamawiających je firm, jak i dla wykonawców.
Standard dzieli test na siedem części: ustalenia poprzedzające test, zbieranie informacji, modelowanie zagrożeń, analizę podatności, wykorzystanie podatności, etap post-exploitation oraz raportowanie. Celem etapu post-exploitation jest ocena wartości przejętego systemu, o której decyduje wrażliwość przechowywanych na nim danych oraz jego przydatność do przejmowania kolejnych systemów w sieci. Raport ma obejmować zarówno część przeznaczoną dla kierownictwa, jak i część techniczną. Sam standard nie zawiera wytycznych technicznych dotyczących przeprowadzenia testu, dlatego uzupełnia go osobny dokument techniczny.
Standard określa również zasady postępowania z przejętymi systemami. Tester prowadzi wykaz wykonanych na nich działań wraz z czasem ich wykonania, dołączany do raportu końcowego, a po zakończeniu testu usuwa pozostawione przez siebie pliki i narzędzia oraz utworzone konta i przywraca zmienione ustawienia. Dzienników zdarzeń nie wolno usuwać ani modyfikować bez wyraźnej zgody zamawiającego, a hasła i inne dane wrażliwe umieszczane w raporcie muszą być zamaskowane. Jeżeli w badanym środowisku zostaną znalezione ślady wcześniejszego włamania, zapis działań testera zostaje zabezpieczony i przekazany zamawiającemu, który decyduje o dalszym postępowaniu.
OWASP Web Security Testing Guide Przewodnikiem OWASP dotyczącym testowania aplikacji internetowych jest Web Security Testing Guide (WSTG), opisujący testowanie bezpieczeństwa aplikacji internetowych i usług sieciowych i tworzony wspólnie przez specjalistów i wolontariuszy. Według OWASP stanowi on zbiór dobrych praktyk stosowanych przez pentesterów i organizacje na całym świecie. Aktualną stabilną wersją jest 4.2, wydana w grudniu 2020 roku, a trwają prace nad wersją 5.0.
Rodzaje testów penetracyjnych Test penetracyjny może być prowadzony przy różnym poziomie wiedzy zespołu testującego, z dwiema skrajnymi wartościami:
Test penetracyjny z minimalną wiedzą (black box) – w największym stopniu stara się odzwierciedlić rzeczywistą wiedzę potencjalnego włamywacza, w związku z czym zespół testujący otrzymuje np. wyłącznie adres serwisu i nic ponadto. Wadą tej metody jest możliwość poświęcenia przez zespół nieproporcjonalnie dużych ilości czasu na działania bezproduktywne, np. próbę złamania hasła na wejściu do serwisu w sytuacji, gdy autentyczny włamywacz mógłby tę wiedzę zdobyć innymi metodami (np. za pomocą phishingu lub metod wiążących się ze złamaniem prawa). Według wytycznych PCI SSC test black box może wymagać więcej czasu, pieniędzy i zasobów, a testy grey box i white box dają dokładniejsze wyniki i pełniej sprawdzają stan bezpieczeństwa środowiska. Testy penetracyjne grey box będące kompromisem pomiędzy black box i white box, zawierające elementy obu podejść np. jedynie konta użytkowników o różnych rolach. Konta te pozwalają sprawdzić, czy użytkownik danej roli może uzyskać dostęp do danych lub funkcji, do których nie jest uprawniony. Testuje się przy tym eskalację uprawnień pionową, czyli dostęp do zasobów kont o wyższych uprawnieniach, np. przejęcie uprawnień administratora aplikacji, oraz poziomą, czyli dostęp do zasobów innego użytkownika o podobnych uprawnieniach, np. danych innego klienta bankowości internetowej. Test penetracyjny z pełną wiedzą (white box lub crystal box) – zespół testujący ma pełny dostęp do dokumentacji projektowej, kodu źródłowego, konfiguracji urządzeń sieciowych itd. W przypadku opierania się wyłącznie na tej wiedzy można mówić o „przeglądzie kodu” lub „przeglądzie konfiguracji”. Wadą takiego podejścia jest możliwość pominięcia rozbieżności pomiędzy stanem udokumentowanym a stanem faktycznym.
Testy zewnętrzne i wewnętrzne Test zewnętrzny prowadzi się z internetu, z perspektywy napastnika z zewnątrz. Test wewnętrzny prowadzi się z sieci lokalnej (LAN) organizacji, z pozycji zaufanego pracownika albo napastnika, który przełamał już zabezpieczenia brzegowe.
Testy jawne i niejawne Test jawny prowadzi się za wiedzą i zgodą działu informatycznego organizacji, a niejawny bez jego wiedzy, lecz za zgodą najwyższego kierownictwa. Test niejawny pozwala sprawdzić także reakcję personelu na atak i ponieważ administratorzy nie są na niego przygotowani, lepiej oddaje codzienny stan bezpieczeństwa organizacji. Jest jednak bardziej czasochłonny i kosztowny, dlatego częściej stosuje się testy jawne.
Testy penetracyjne ukierunkowane przez analizę zagrożeń Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), stosowane od 17 stycznia 2025 roku, wymaga od podmiotów finansowych prowadzenia programu testowania, obejmującego m.in. testy penetracyjne. Podmioty wyznaczone przez właściwe organy nadzoru muszą ponadto przeprowadzać, co do zasady co trzy lata, zaawansowane testy w formie testów penetracyjnych ukierunkowanych przez analizę zagrożeń (ang. threat-led penetration testing, TLPT). Jeżeli podmiot korzysta przy tych testach z własnych testerów, co trzeci test musi zlecić testerom zewnętrznym.