2026-07-15 · PRAKTYKA · Zespół Offensive Technology

Dlaczego każdy projekt zaczyna się od podpisu

Jest dokładnie jedna rzecz, która odróżnia test penetracyjny od przestępstwa komputerowego, i nie są to umiejętności, narzędzia ani intencje. Jest to autoryzacja. To samo polecenie wykonane na tym samym serwerze we wtorek jest usługą profesjonalną, a w środę przestępstwem, a jedyną różnicą jest kartka papieru.

Zanim więc czegokolwiek dotkniemy, dbamy o formalności. Oto co to oznacza w praktyce i dlaczego nie pomijamy tego kroku, nawet gdy klientowi się spieszy.

Własność przed dostępem

Pierwsze pytanie nie brzmi „co chcesz przetestować”, ale „czy możesz udowodnić, że tym kontrolujesz”. Każdy może wpisać domenę w formularzu. Nie oznacza to, że jest jej właścicielem, a jeśli nim nie jest, jej testowanie stawia nas obu po złej stronie prawa.

Dlatego weryfikujemy. Zazwyczaj oznacza to umieszczenie tokena w rekordzie DNS, który możemy odczytać, lub potwierdzenie z adresu e-mail w danej domenie. Zajmuje to kilka minut i nie podlega negocjacjom. Jeśli nie możesz udowodnić kontroli nad celem, do projektu nie dojdzie.

Nie polegamy również na samym podpisie. Wymagamy pisemnej autoryzacji od imiennie wskazanej osoby, a i tak oczekujemy technicznego dowodu, ponieważ podpis na niewłaściwym papierze firmowym to prosty sposób, by tester skierował działania na niewłaściwy cel.

Zakres to ogrodzenie, a nie sugestia

Gdy kwestia własności jest ustalona, spisujemy dokładnie, co mieści się w zakresie, a co nie: które hosty, które aplikacje, które techniki, a które są jednoznacznie wykluczone. Ten dokument to ogrodzenie. Trzymamy się w jego granicach, nawet jeśli coś interesującego jest wyraźnie widoczne tuż za nim.

• Zasoby, które możemy testować, wymienione z nazwy.
• Zatwierdzone techniki oraz te, które zostały wykluczone.
• Przedziały czasowe, aby testy nigdy nie zaskoczyły Twojego zespołu ani Twoich klientów.
• Imienny kontakt, który może wstrzymać całość jedną wiadomością.

Ten sam dokument rozstrzyga dwie kwestie, o których ludzie zapominają, dopóki nie staną się one kluczowe. Po pierwsze, środowisko: czy testujemy produkcję, gdzie obciążające żądanie może wpłynąć na prawdziwych klientów, czy kopię stagingową, która ją odzwierciedla? Oba wybory są uzasadnione, ale decyzja musi być podjęta celowo, a nie odkryta w trakcie testu. Po drugie, warunek zatrzymania: kto może przerwać prace, jak się z nami kontaktuje i co dzieje się z uzyskanym już dostępem, jeśli to zrobi. To podpisana umowa przedprojektowa, a nie koleżeńska umowa. Gdy jest dobrze przygotowana, nikt nie musi improwizować pod presją.

Gdy cel nie należy całkowicie do Ciebie

Posiadanie nazwy domeny to nie to samo co posiadanie wszystkiego, na co ona wskazuje, i tu właśnie pojawiają się błędy w intencjonalnie dobrych zakresach. Częsty przykład: klient wskazuje app.clientco.com jako zasób w zakresie. Sprawdzamy to i okazuje się, że jest to CNAME do zewnętrznej platformy SaaS, którą klient subskrybuje, ale jej nie prowadzi. Klient kontroluje nazwę DNS, ale nie kontroluje serwerów za nią stojących. Testowanie tego hosta oznacza testowanie dostawcy, który na nic się nie godził. Trafia on więc poza zakres, chyba że klient najpierw uzyska pisemną zgodę od dostawcy.

Ta sama ostrożność dotyczy zasobów na współdzielonym hostingu lub za współdzielonym CDN, gdzie pojedynczy adres IP może obsługiwać tysiące niespokrewnionych podmiotów, a także domeny przejętej w ramach transakcji, której rekordy nadal kierują na infrastrukturę sprzedającego. Główni dostawcy chmury również publikują własne zasady dopuszczalnych testów, a niektóre działania, w szczególności testy denial-of-service i testy obciążeniowe, nadal wymagają ich wcześniejszego powiadomienia lub zgody nawet w przypadku zasobów będących Twoją własnością. Ustalenie, co naprawdę należy do Ciebie, jest częścią mapowania external attack surface, i odbywa się przed każdym testem, a nie w jego trakcie.

Prawo kryjące się za tą granicą

Powodem, dla którego jesteśmy w tej kwestii bezkompromisowi, nie jest nasza wewnętrzna polityka. Większość krajów traktuje nieautoryzowany dostęp do systemu komputerowego jako przestępstwo samo w sobie. W Stanach Zjednoczonych jest to Computer Fraud and Abuse Act; w Wielkiej Brytanii Computer Misuse Act 1990; w całej Unii Europejskiej państwa członkowskie penalizują nielegalny dostęp na mocy praw krajowych wdrażających unijną dyrektywę w sprawie ataków na systemy informatyczne. Szczegóły różnią się w zależności od jurysdykcji, ale myśl przewodnia jest taka sama: dostęp bez zgody właściciela jest przestępstwem, a dobre intencje nie stanowią linii obrony. To nie jest porada prawna, a Twój własny prawnik jest właściwą osobą do przeanalizowania przepisów, które Cię dotyczą. To po prostu wyjaśnienie, dlaczego ani jedno żądanie nie zostanie wysłane, dopóki autoryzacja i własność nie zostaną ustalone.

Dlaczego jesteśmy rygorystyczni w kwestii nudnych formalności

Klienci czasami odbierają to jako biurokrację. Jest wręcz przeciwnie. Ścisła autoryzacja pozwala nam działać agresywnie wewnątrz ogrodzenia bez obaw którejkolwiek ze stron. Gdy granice są spisane i podpisane, możemy sprawnie łączyć ataki i udowadniać realny wpływ, ponieważ wszyscy wcześniej zgodzili się co do tego, gdzie przebiegają granice.

Zespoły, które na tym cierpią, to te, które traktowały zakres jako formalność. My traktujemy go jako fundament, bo nim jest.

Najpierw autoryzacja: szybkie odpowiedzi

Czy potrzebuję pisemnej autoryzacji do testowania systemów, które już posiadam?

W praktyce tak. Pisemna autoryzacja dowodzi, że Twój własny zespół zatwierdził test, co chroni Cię wewnętrznie, a także chroni operatora wykonującego testy. Jeśli jakakolwiek część środowiska znajduje się na infrastrukturze, której nie kontrolujesz w pełni, takiej jak platforma chmurowa lub produkt SaaS, możesz również potrzebować zgody tego dostawcy. Uzyskaj wszystko na piśmie, zanim cokolwiek zostanie uruchomione.

Czym jest dokument zasad prowadzenia testów (rules of engagement)?

To pisemna umowa określająca test: dokładne cele w zakresie, dozwolone i zabronione techniki, okno testowe, imienne kontakty po obu stronach oraz warunki, w których testy zostają przerwane. Zmienia niejasne „przetestujcie nas” w coś, do czego obie strony mogą zostać pociągnięte do odpowiedzialności.

Czy skanowanie witryny internetowej, która nie należy do mnie, jest nielegalne?

Może być. Wiele jurysdykcji penalizuje nieautoryzowany dostęp do systemów komputerowych, a granica między skanowaniem a dostępem nie zawsze przebiega tam, gdzie ludzie przypuszczają. Bez autoryzacji i dowodu kontroli nad celem nie kieruj w jego stronę żadnych działań. To nie jest porada prawna; skonsultuj się z wykwalifikowanym prawnikiem właściwym dla Twojej jurysdykcji.

W jaki sposób potwierdzacie, że jestem właścicielem celu przed jego przetestowaniem?

Zazwyczaj jest to rekord, o którego opublikowanie prosimy w DNS celu, lub odpowiedź ze skrzynki pocztowej w samej domenie. Obie metody dowodzą kontroli w sposób, w jaki formularz internetowy nie potrafi. Dopóki ta weryfikacja nie przejdzie pomyślnie, do projektu nie dojdzie.

Powiązane artykuły

• Weryfikacja, skanowanie czy pełny pentest?
• Jak przygotować się do pierwszego testu penetracyjnego
• Co naprawdę udowadniają certyfikaty OSCP, OSEP i CRTO