Testy bezpieczeństwa IT: rodzaje, przebieg i jak zamówić pentest

Testy bezpieczeństwa IT polegają na kontrolowanym, uzgodnionym z właścicielem sprawdzaniu systemów, aplikacji, sieci i procedur pod kątem luk, zanim znajdą je prawdziwi atakujący. W zależności od celu może to być automatyczny skan podatności, ręczny test penetracyjny konkretnej aplikacji albo symulacja pełnego ataku na organizację, sprawdzająca także, czy zespół bezpieczeństwa go wykryje.

Wynikiem każdego testu jest raport: jakie luki znaleziono, jak poważne są, jak je wykorzystać i — najważniejsze — jak je naprawić. Poniżej wyjaśniam rodzaje testów, ich przebieg, wymogi prawne i to, na co zwrócić uwagę, zamawiając test w swojej firmie.

Rodzaje testów bezpieczeństwa IT

Obszary testów penetracyjnych

Test penetracyjny zawsze dotyczy konkretnego zakresu. Najczęściej zamawiane są:

• aplikacje webowe i API — kontrola dostępu, uwierzytelnianie, wstrzykiwanie kodu, logika biznesowa (metodyka OWASP WSTG, wymagania OWASP ASVS),
• infrastruktura zewnętrzna — wszystko, co firma wystawia do internetu: VPN, poczta, panele administracyjne, zapomniane serwery,
• sieć wewnętrzna i Active Directory — co zrobi atakujący, który dostał się do jednego komputera (np. przez phishing),
• aplikacje mobilne — przechowywanie danych na urządzeniu, komunikacja z serwerem,
• chmura — konfiguracja kont, uprawnień i usług w AWS, Azure czy Google Cloud,
• sieci bezprzewodowe — separacja sieci gości, konfiguracja WPA2/WPA3-Enterprise.

Black box, gray box, white box

To, ile tester wie na starcie, zmienia charakter testu. W black box zna tylko adres celu — to najbliższe sytuacji zewnętrznego atakującego, ale dużą część czasu zajmuje rozpoznanie. W gray box dostaje konta testowe i dokumentację, w white box także kod źródłowy i konfigurację.

Przy ograniczonym budżecie (a test zawsze trwa określoną liczbę dni) gray i white box zwykle znajdują więcej istotnych problemów. Prawdziwy atakujący ma przecież miesiące na rozpoznanie, którego tester w black box nie ma.

Jak przebiega test penetracyjny krok po kroku

1. Ustalenie zakresu i celów. Które systemy, adresy IP, domeny, aplikacje i konta są w zakresie, a co jest wyłączone. Jaki jest cel: znalezienie jak największej liczby luk w aplikacji czy sprawdzenie, czy da się dojść do konkretnych danych.
2. Zasady prowadzenia testu (rules of engagement). Okno czasowe, dozwolone techniki (np. czy wolno testować odporność na przeciążenie), kontakty awaryjne po obu stronach, sposób postępowania przy znalezieniu krytycznej luki lub śladów prawdziwego włamania.
3. Formalności. Pisemna zgoda właściciela systemów, umowa o poufności, zgoda dostawców usług (np. hostingu czy chmury, jeśli ich regulamin tego wymaga).
4. Rozpoznanie. Zbieranie informacji o celu: usługi, wersje oprogramowania, struktura aplikacji, publicznie dostępne dane.
5. Wyszukiwanie i weryfikacja podatności. Połączenie narzędzi automatycznych z ręczną analizą, odsiewanie fałszywych alarmów.
6. Kontrolowane wykorzystanie. Potwierdzenie, że luka jest realna, i sprawdzenie, dokąd prowadzi — bez szkody dla danych i dostępności systemów.
7. Raport. Opis każdej podatności, jej wagi, sposobu odtworzenia i rekomendacji.
8. Naprawa i retest. Zespół IT usuwa luki, a tester sprawdza, czy poprawki są skuteczne.

Ważne: Przed testem infrastruktury zrób aktualną kopię zapasową i poinformuj osoby, które powinny wiedzieć (administratorów, dostawcę usług zarządzanych, SOC). Jeśli celem jest sprawdzenie wykrywania, wiedzę o teście ogranicza się do wąskiej grupy, ale zawsze ktoś po stronie firmy musi móc go natychmiast przerwać.

Co powinien zawierać dobry raport z testów

Raport to produkt, za który płacisz. Dobry raport zawiera:

• podsumowanie dla zarządu — bez żargonu: jak źle jest, co jest najpilniejsze, jakie jest ryzyko biznesowe,
• zakres, metodykę i ograniczenia — co sprawdzono, czego nie i dlaczego,
• listę podatności z oceną wagi — zwykle w skali CVSS lub opisowej (krytyczna, wysoka, średnia, niska), z uwzględnieniem kontekstu firmy,
• dowody — kroki odtworzenia, zrzuty ekranu, żądania i odpowiedzi,
• konkretne rekomendacje — nie „zaktualizuj oprogramowanie”, tylko co, gdzie i w jakiej kolejności zmienić,
• ścieżki ataku — jak drobne słabości łączą się w poważny scenariusz.

Raport zawierający głównie przeklejony wynik skanera, bez weryfikacji i kontekstu, to sygnał, że zamiast testu penetracyjnego dostałeś skan podatności.

Najczęstsze problemy wykrywane podczas testów

Wyniki testów w wielu firmach powtarzają się. Typowe kategorie:

• brakujące aktualizacje systemów, urządzeń brzegowych (VPN, firewalle) i aplikacji,
• słabe, domyślne lub powtarzające się hasła, w tym konta serwisowe ze starymi hasłami — audyt siły haseł w kontrolowanych warunkach opisuje tekst o Hashcat,
• brak MFA na poczcie, VPN i panelach administracyjnych,
• wadliwa kontrola dostępu w aplikacjach — użytkownik widzi lub zmienia cudze dane, zmieniając identyfikator w adresie lub żądaniu,
• podatności typu injection i XSS — szczegóły w artykule o cross-site scripting,
• wystawione do internetu usługi administracyjne, np. pulpit zdalny — jak to naprawić, opisuje poradnik bezpieczny RDP w organizacji,
• przestarzałe protokoły w sieci wewnętrznej, np. SMBv1,
• błędy konfiguracji chmury — publicznie dostępne zasoby, zbyt szerokie uprawnienia,
• brak separacji środowisk — dane produkcyjne na serwerach testowych, wspólne hasła.

Testy bezpieczeństwa a wymogi prawne i regulacyjne

W wielu organizacjach regularne testy nie są tylko dobrą praktyką:

• RODO — art. 32 wymaga m.in. regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych zabezpieczających przetwarzanie danych osobowych.
• NIS2 — dyrektywa wdrożona w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa (obowiązuje od 3 kwietnia 2026 r.) wymaga od podmiotów kluczowych i ważnych zarządzania ryzykiem, w tym oceny skuteczności zabezpieczeń.
• DORA — od 17 stycznia 2025 r. sektor finansowy musi regularnie testować odporność cyfrową, a wybrane instytucje — przeprowadzać zaawansowane testy penetracyjne oparte na analizie zagrożeń (TLPT).
• PCI DSS 4.0 — dla podmiotów przetwarzających dane kart: testy penetracyjne co najmniej raz w roku i po istotnych zmianach oraz kwartalne skany podatności.
• ISO/IEC 27001 — zarządzanie podatnościami technicznymi i testy bezpieczeństwa w procesie wytwarzania oprogramowania jako elementy systemu zarządzania bezpieczeństwem informacji.

Uwaga: Testy prowadzi się wyłącznie na podstawie pisemnej zgody właściciela systemu. Nieuprawniony dostęp do systemu informatycznego i przełamywanie zabezpieczeń to w Polsce przestępstwa z Kodeksu karnego — dobre intencje nie zwalniają z odpowiedzialności, jeśli nie ma zgody i jasno ustalonego zakresu.

Jak wybrać wykonawcę testów penetracyjnych

1. Poproś o przykładowy, zanonimizowany raport. To najlepszy sposób, by ocenić jakość pracy.
2. Zapytaj o metodykę — np. OWASP WSTG dla aplikacji, PTES lub NIST SP 800-115 dla infrastruktury, MITRE ATT&CK dla red teamingu.
3. Sprawdź kompetencje zespołu — doświadczenie w podobnych projektach, uznane certyfikaty praktyczne (np. OSCP, OSWE, CRTO, certyfikaty CREST), ale przede wszystkim konkretne realizacje.
4. Ustal, czy retest jest w cenie i w jakim terminie po raporcie.
5. Doprecyzuj liczbę dni testowych. Cena testu zależy głównie od zakresu i czasu pracy specjalistów; zbyt niska wycena przy dużym zakresie zwykle oznacza automatyczny skan.
6. Zadbaj o kwestie formalne — umowa, NDA, ubezpieczenie OC wykonawcy, sposób przekazania i przechowywania raportu (to dokument opisujący, jak włamać się do Twojej firmy).

Jeśli zespół IT chce rozwijać kompetencje we własnym zakresie, przyda się środowisko z gotowymi narzędziami — porównanie popularnych dystrybucji znajdziesz w tekście Kali Linux czy ParrotOS. Wewnętrzne testy nie zastąpią jednak niezależnego spojrzenia z zewnątrz.

Od czego zacząć w małej firmie

Pełny program testów to wydatek, na który nie każda firma jest gotowa. Rozsądna kolejność:

1. Zinwentaryzuj, co firma wystawia do internetu (domeny, adresy IP, usługi), i usuń to, co zbędne.
2. Uruchom regularne skanowanie podatności zasobów zewnętrznych i wewnętrznych.
3. Włącz MFA wszędzie, gdzie się da, i zadbaj o aktualizacje.
4. Zamów test penetracyjny najważniejszego systemu — zwykle aplikacji przetwarzającej dane klientów lub infrastruktury zewnętrznej.
5. Napraw znalezione luki według priorytetów i zrób retest.
6. Powtarzaj testy co najmniej raz w roku i po większych zmianach, stopniowo rozszerzając zakres.

Test bezpieczeństwa pokazuje stan na dzień jego wykonania. Prawdziwą wartość daje dopiero cykl: test, naprawa, retest, a pomiędzy nimi — ciągłe aktualizacje, monitoring i ludzie, którzy reagują na alerty.