Zakres skanowania bezpieczeństwa określa, jakie systemy i usługi wolno testować, jakimi metodami i na jakich warunkach. Znaleziona nazwa hosta czy ustalony adres IP potwierdzają powiązanie techniczne. Zanim rozpoczniesz testy sieciowe, ustal, kto może zezwolić na te konkretne testy, co jest z nich wyłączone i kto może je wstrzymać, jeśli zmieni się cel lub zgoda.

To rozróżnienie jest istotne, gdy nazwa twojej firmy pojawia się w ruchu trafiającym na cudzy serwer. Narzędzie może poprawnie wykryć powiązanie, a mimo to błędnie wyznaczyć granice zleconych przez ciebie testów.

13 września operator prowadzonego społecznie serwera czasu [opisał nieoczekiwany ruch związany z testami bezpieczeństwa](https://dreamstation.systems/personal/tesla.html), zawierający nazwę hosta firmy Tesla i identyfikatory powiązane z Assetnote. Zasugerował, że za wyborem celu mógł stać alias DNS prowadzący do wspólnej puli serwerów czasu. Wyraźnie zaznaczył, że to przypuszczenie.

Obecnie na stronie widnieje informacja, że Assetnote skontaktowało się z operatorem, a sprawa została rozwiązana. Relacja nie potwierdza ani przyczyny ustalonej przez dostawcę, ani skutecznego włamania.

Dla twojego zespołu istotne jest szersze pytanie: **na jakiej podstawie znaleziony zasób staje się celem, który wolno skanować?** Poniżej proponujemy sposób postępowania zilustrowany fikcyjnymi przykładami. Ma pomóc w sprawdzeniu własnego procesu. Nie jest oceną wewnętrznych zabezpieczeń żadnej z tych firm.

## Co właściwie obejmuje zakres skanowania bezpieczeństwa?

Trzeba określić zarówno granice testowanej usługi, jak i dozwolone wobec niej działania. Sama lista zasobów nie wyjaśnia, co wolno z nimi robić.

Wyobraź sobie fikcyjną firmę Example Works z aplikacją pod adresem `app.example.com`. Zespół aplikacji może odpowiadać za jej kod i konfigurację klienta, podczas gdy sieć obsługuje dostawca.

Zgoda na testowanie aplikacji nie rozstrzyga, czy wolno sprawdzać inne usługi pod tym samym adresem, testować środowisko innego klienta albo stosować metody zakłócające działanie systemu.

Opisz zakres tak, żeby osoba wykonująca testy nie musiała zgadywać odpowiedzi na trzy pytania: dokąd wolno wysyłać ruch, jakie działania są dozwolone i co wymaga przerwania testów? Uwzględnij konkretne środowisko i konto.

Aplikacja produkcyjna i jej kopia testowa mogą mieć innych opiekunów, inne dane i inne ograniczenia, nawet jeśli nazwy wyglądają podobnie.

[NIST SP 800-115, sekcja 6.5](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf), opisuje planowanie testów z uwzględnieniem systemów objętych zakresem i wyłączonych z niego, metod, organizacji pracy, postępowania z danymi oraz procedur na wypadek incydentu.

Porusza też kwestię zgody stron trzecich i uprawnień do wznowienia przerwanych testów. To zalecenia opublikowane w 2008 roku, a nie nowy wymóg na rok 2026.

Dobierz poziom szczegółowości do zlecenia. Przy wąskim przeglądzie aplikacji może wystarczyć krótki opis. Cykliczne testy zmieniającej się infrastruktury wymagają aktualizowanego rejestru i sprawdzania zmian przed wykonaniem zadań. W obu przypadkach ktoś powinien umieć wyjaśnić, dlaczego kolejne żądanie mieści się w zakresie.

## Dokąd może prowadzić znaleziona nazwa hosta?

Nazwa hosta może wskazywać usługę, z której korzystasz, nie dowodząc kontroli nad całą infrastrukturą za tą nazwą. Zachowaj informacje o wykrytym powiązaniu, ale przed uruchomieniem aktywnych testów sprawdź, na czym ono polega.

Poniższe przykłady są fikcyjne. Pokazują pytania do wyjaśnienia, a nie reguły automatycznego dopuszczania lub odrzucania celów.

| Wykryte powiązanie | Czego jeszcze nie wiadomo | Co trzeba ustalić przed testami |
| --- | --- | --- |
| `app.example.com` prowadzi do współdzielonej sieci CDN | Jakie ścieżki aplikacji i metody obejmuje zgoda | Tożsamość aplikacji, zakres zlecenia i obowiązujące warunki dostawcy |
| `support.example.com` jest aliasem środowiska klienta u dostawcy | Czy dostawca pozwala na takie testy twojego środowiska | Granice środowiska klienta oraz odpowiednia polityka testowania lub zgoda dostawcy |
| `time.example.com` kieruje klientów do zewnętrznej usługi czasu | Kto obsługuje serwer docelowy i może zezwolić na jego testowanie | Zasady korzystania z usługi i zgoda właściwego operatora |
| W inwentaryzacji pozostał dawny adres zasobu chmurowego | Czy zasób nadal jest przypisany do twojego konta | Aktualna tożsamość zasobu i przypisanie do konta, sprawdzone względem konfiguracji skanera |

Współdzielona infrastruktura nie jest automatycznie wyłączona z testów. Możesz mieć ważną zgodę na sprawdzanie swojej aplikacji przez serwery brzegowe dostawcy.

Problem powstaje wtedy, gdy ta zgoda bez osobnej decyzji rozszerza się na innych klientów, porty lub usługi tylko dlatego, że korzystają z tego samego adresu.

[Wytyczne NTP Pool dla dostawców](https://www.ntppool.org/en/vendors.html) opisują zasady korzystania z puli jako domyślnej usługi czasu w produktach, w tym przydzielane dostawcom nazwy hostów. Te ustalenia dotyczą korzystania z usługi czasu. Same w sobie nie dają zgody na testy bezpieczeństwa serwerów utrzymywanych przez wolontariuszy.

Nie usuwaj wyłączonych zależności z inwentaryzacji. Zespół bezpieczeństwa może nadal potrzebować przeglądu ich konfiguracji, rozmowy z dostawcą o zabezpieczeniach albo informacji o planowanej zmianie usługi. Wyłączenie aktywnego testowania nie powinno sprawić, że zależność biznesowa zniknie z ewidencji.

## Co zapisać przed uruchomieniem aktywnych testów?

Prowadź prosty rejestr zgód obok inwentaryzacji zasobów. Powiąż każdy zasób z podstawą zezwolenia, ograniczeniami testów i osobą odpowiedzialną za ich prowadzenie.

Proponujemy poniższe pola. Dostosuj je do zlecenia, zamiast traktować jak formularz zgodności z przepisami:

- **Tożsamość usługi:** nazwa hosta, środowisko oraz właściwy identyfikator klienta, konta lub zasobu.
- **Osoby odpowiedzialne:** opiekun biznesowy, faktyczny operator i osoba odpowiedzialna za testy.
- **Podstawa wykrycia:** jak znaleziono zasób i jakie powiązanie potwierdza ta informacja.
- **Podstawa zgody:** zatwierdzone zlecenie, obowiązująca polityka dostawcy lub konkretna umowa wraz z ograniczeniami.
- **Dozwolone działania:** kategorie metod, wyłączenia, dopuszczone konta i zasady postępowania z danymi.
- **Warunki ważności:** okres lub okoliczności objęte zgodą oraz zmiany wymagające ponownego sprawdzenia.
- **Powiązanie z wykonaniem:** konfiguracja skanera lub zadanie realizujące zatwierdzony zakres.
- **Kontakt w sprawie wstrzymania:** kto może przerwać pracę i kto może zezwolić na jej wznowienie.

Nie wymagaj nowego maila ze zgodą przy każdym wpisie. Opublikowana polityka dostawcy może już dopuszczać określone testy na wskazanych warunkach. Na przykład [polityka testów penetracyjnych AWS](https://aws.amazon.com/security/penetration-testing/) rozróżnia testowanie własnej infrastruktury klienta objętej zezwoleniem od testowania infrastruktury lub usług samego AWS.

Liczą się konkretna usługa i warunki. Ogólne powołanie się na dostawcę chmury nie wystarczy.

Używaj jasnych statusów, żeby wykrycie zasobu nie oznaczało automatycznie uruchomienia testów. Proponujemy: **wykryty, czeka na weryfikację**; **zweryfikowany, bez zgody na te testy**; **dopuszczony z ograniczeniami**; **wstrzymany do wyjaśnienia**. To propozycja organizacji pracy, a nie wbudowane w Kit statusy zasobów.

Fikcyjne środowisko pomocy technicznej Example Works może pozostać zweryfikowane, ale niedopuszczone do testów, dopóki opiekun nie sprawdzi polityki dostawcy. Powiązanie jest potwierdzone, a wpis nadal jest przydatny. Brakuje po prostu podstawy do włączenia go do aktywnych testów. To normalny wynik weryfikacji, a nie zaległe porządki, które ktoś powinien zakończyć kliknięciem przycisku zatwierdzenia.

## Jak utrzymać trwający skan w granicach udzielonej zgody?

Trwające testy muszą przestrzegać zatwierdzonych granic usługi. Sprawdź, jak narzędzia zamieniają nazwy hostów, przekierowania i nowe znaleziska w zadania do wykonania.

Zacznij od przekazania danych z inwentaryzacji do skanera. Jeśli zatwierdzasz nazwę hosta aplikacji, sprawdź, czy kolejny etap testuje tę aplikację, czy rozszerza zadanie na adresy uzyskane z DNS. Ustalenie adresu na podstawie nazwy może być konieczne do nawiązania połączenia. Uznanie tego za zgodę na testowanie każdej usługi pod tym adresem to osobna decyzja.

To samo dotyczy przekierowań i automatycznego odkrywania kolejnych adresów. Link do strony logowania dostawcy może dostarczać przydatnych informacji, nie rozszerzając testów na tego dostawcę. Ustal, czy narzędzie ma się zatrzymać, zapisać cel do sprawdzenia, czy kontynuować na podstawie zgody, która już go obejmuje. Osoba zatwierdzająca uruchomienie powinna wiedzieć, jakie zachowanie wybrano.

Zmiany infrastruktury wymagają proporcjonalnej kontroli. Nowa instancja w ramach tego samego dopuszczonego konta i usługi może być objęta dotychczasową zgodą.

Nowy cel poza tymi granicami wymaga decyzji. Nie narzucaj ręcznego zatwierdzania każdej rutynowej zmiany adresu. Określ, jakie warunki dotyczące tożsamości i kontroli nad zasobem muszą nadal być spełnione.

Osobno sprawdź zadania w kolejce. Usunięcie celu z kolejnego eksportu inwentaryzacji nie mówi, co stanie się z zadaniami już zaplanowanymi lub uruchomionymi. Zweryfikuj, jak narzędzia anulują oczekujące zadania, obsługują ponowienia i stosują wyłączenia we wszystkich procesach roboczych. To kwestia implementacji i konfiguracji skanera, a nie gwarancja wynikająca z dokumentu opisującego zakres.

Zachowuj wersję zakresu używaną przy każdym uruchomieniu oraz dane z wykonania wystarczające do powiązania zgłoszonego żądania z konkretnymi testami. Ogranicz dostęp do wrażliwych próbek.

Chodzi o możliwość późniejszej odpowiedzi na konkretne pytanie: jaką zatwierdzoną usługę i na podstawie jakiej zgody to zadanie miało testować? Zrzut obecnej konfiguracji nie wyjaśni żądania wysłanego według wczorajszych ustawień.

## Jak reagować na zgłoszenie skanowania niewłaściwego celu?

Zapewnij bezpośredni kontakt z kimś, kto może wstrzymać niechciany ruch testowy. Zespół powinien sprawdzić cel nawet wtedy, gdy nadawca nie zgłasza podatności kwalifikującej się do nagrody.

Kontakt do zgłaszania podatności pomaga się z tobą porozumieć. [RFC 9116, sekcja 5.5](https://www.rfc-editor.org/rfc/rfc9116.html#section-5.5), wyraźnie wskazuje, że obecność lub brak pliku `security.txt` nie oznaczają zgody na testy. Oddziel sposób kontaktu od zasad udzielania zgody i opisz oba zrozumiale.

Zespołowi zlecającemu testy proponujemy taką kolejność działań:

1. **Wstrzymaj wskazane działania.** Ustal konkretne testy lub cel na tyle dokładnie, żeby zatrzymać zgłoszony ruch na czas wyjaśniania sprawy.
2. **Zachowaj niezbędną próbkę.** Poproś o znaczniki czasu i odpowiednie identyfikatory żądań. Nie rozsyłaj wrażliwych treści ani danych uwierzytelniających w szerokim gronie.
3. **Znajdź osobę odpowiedzialną za testy.** Ustal, kto zlecił zadanie i może zmienić jego zakres.
4. **Sprawdź cel.** Porównaj tożsamość usługi, faktycznego operatora i podstawę zgody z wykonanym zadaniem.
5. **Popraw wykonanie, nie tylko dokumentację.** Zmień cel lub wyłączenie i zajmij się żądaniami w kolejce, ponowieniami oraz cyklicznymi harmonogramami.
6. **Potwierdź zatrzymanie ruchu.** Potwierdź w zapisach wykonania, że wskazany ruch ustał. W razie potrzeby zapytaj operatora, czy jego obserwacje potwierdzają ustanie ruchu.
7. **Przekaż wynik.** Wyjaśnij, co wstrzymano lub poprawiono. Wznów wyłącznie działania, dla których potwierdzono zgodę.

Nie podawaj przyczyny, zanim jej nie zweryfikujesz. Dobra pierwsza odpowiedź może potwierdzić przyjęcie zgłoszenia, wskazać osobę prowadzącą sprawę i poinformować o wstrzymaniu odpowiednich testów.

W późniejszej odpowiedzi oddziel potwierdzone ustalenia od tego, co pozostaje niewiadome.

Ma to związek z [koordynowaniem ujawnienia podatności u kilku dostawców](/blog/coordinated-disclosure-multi-vendor-vulnerabilities), ale dotyczy wcześniejszej decyzji. Tutaj najpierw trzeba ustalić, dokąd powinien trafiać ruch zleconych przez ciebie testów. Badanie ewentualnej podatności można kontynuować w odpowiednim, osobno ustalonym zakresie.

## Jak sprawdzić granice bez testowania publicznych systemów?

Przeprowadź ćwiczenie scenariuszowe na fikcyjnych wpisach inwentaryzacji i kolejce testowej, która nie wysyła ruchu sieciowego. Zanim dołączysz prawdziwe zewnętrzne cele, sprawdź podejmowanie decyzji i zatrzymywanie pracy.

W proponowanym ćwiczeniu jedna osoba odgrywa rolę testera, druga opiekuna usługi. Niech korzystają z dokumentacji, której zespół faktycznie używa. Nie uzupełniaj braków ustnie. Notuj, gdzie uczestnicy muszą zgadywać.

**Zmień operatora.** Zacznij od dopuszczonej fikcyjnej aplikacji, a następnie zmień wpis na środowisko klienta obsługiwane przez dostawcę. Sprawdź, czy dotychczasowa zgoda obejmuje tę relację. Ćwiczenie jest zaliczone, jeśli zespół wskaże odpowiednią podstawę zgody albo wstrzyma nowy cel do wyjaśnienia.

**Wycofaj zadanie z kolejki.** Dodaj fikcyjny cel do kolejki testowej, a potem cofnij zgodę. Sprawdź zadania oczekujące i ponowienia, nie tylko następne zaplanowane wykrywanie zasobów.

Zapisz, jaki mechanizm zapobiega wykonaniu wycofanego zadania.

**Wyjdź poza dopuszczoną aplikację.** Dodaj fikcyjne przekierowanie do innej przykładowej nazwy hosta. Zapytaj, co tester zrobi dalej i gdzie zapisze decyzję. Odpowiedź powinna wynikać z granic zlecenia, niezależnie od tego, kto akurat nadzoruje pracę.

**Przyjmij skargę operatora.** Wyślij wewnętrzne przykładowe zgłoszenie z fikcyjnym znacznikiem czasu i identyfikatorem żądania. Sprawdź, czy odbiorcy potrafią znaleźć osobę odpowiedzialną za testy, wstrzymać właściwe zadania i udzielić jasnej odpowiedzi bez ujawniania wrażliwych materiałów.

Zapisz problemy jako konkretne rzeczy do poprawienia: brak osoby odpowiedzialnej, wyłączenie pomijające ponowienia lub formularz kierujący skargę do niewłaściwej kolejki. Następnie powtórz dany scenariusz. Ćwiczenie jest udane, gdy zespół pokaże, że potrafi reagować na te sytuacje. Nie dowodzi to wyeliminowania wszystkich możliwych błędów wyboru celu.

## Co najczęściej budzi wątpliwości przy zgodzie na skanowanie?

Powiązanie techniczne, dane kontaktowe i zgoda odpowiadają na różne pytania. Przypominaj o tych różnicach, gdy ktoś chce rozszerzyć skanowanie.

### Czy rekord CNAME włącza cel do zakresu?

Potwierdza powiązanie w DNS. Nie wyjaśnia, kto obsługuje cel ani jakie testy dopuszcza tam twoje zlecenie. Przed rozszerzeniem aktywnych testów sprawdź tożsamość usługi i odpowiednią zgodę.

Ważna umowa może już obejmować ten cel. Sam alias nie dowodzi jednak istnienia takiej umowy.

### Czy publiczna polityka ujawniania podatności zezwala na każdy test?

Przeczytaj jej zakres i warunki. Zaproszenie do zgłaszania podatności jest przydatne, ale opublikowane zasady mogą ograniczać zasoby, konta, metody lub sposób postępowania z danymi. Przed aktywnymi testami wyjaśnij niejasne granice z osobą kontaktową programu. Nasz [poradnik konfiguracji programu](/docs/configuring-your-program) opisuje publikowanie tych granic w Kit.

### Czy każdy dostawca musi osobno zatwierdzić każde testy?

Nie ma jednego trybu zatwierdzania dla wszystkich dostawców. Sprawdź aktualną politykę dla danej usługi i proponowanych działań. Część testów mieści się w opublikowanych warunkach, inne wymagają osobnych ustaleń. Zachowaj podstawę decyzji, żeby kolejna osoba nie musiała odtwarzać jej z ogólnej strony dostawcy.

## Jak Kit pomaga opisać zakres i obsługiwać zgłoszenia?

Zespół potrzebuje czytelnej publicznej polityki i sprawnego sposobu obsługi pytań o jej treść. Skaner potrzebuje też własnych, poprawnie wdrożonych mechanizmów kontroli wykonania.

W portalu programu ujawniania podatności (VDP) w Kit opublikujesz cele objęte zakresem, kategorie poza zakresem, wyłączone typy podatności oraz treść polityki ujawniania. Może wyświetlać zapis safe harbor twojego programu i umożliwia badaczom skopiowanie zakresu w formacie Markdown. Wyjaśnij tam granice dozwolonych testów usługi i wskaż kontakt do wyjaśniania wątpliwości.

[Portal badacza](/docs/the-researcher-portal) pozwala przesłać zgłoszenie i kontynuować kontakt. Zadbaj, żeby osoby obsługujące zgłoszenia mogły skontaktować się z opiekunem testów zlecanych przez twoją firmę. Informacja o niechcianym ruchu powinna trafić do kogoś, kto sprawdzi jego źródło i uzgodni wstrzymanie działań.

Opublikowanie zakresu w Kit nie weryfikuje własności infrastruktury, nie daje zgody na testowanie strony trzeciej, nie konfiguruje skanera i nie anuluje zadań w jego kolejce. Ustawienia zakresu nie odrzucają też automatycznie zgłoszeń spoza opublikowanych granic.

Za te decyzje nadal odpowiadają właściwe osoby i narzędzia.

Przed kolejnymi testami powiąż opublikowany zakres, rejestr zgód, konfigurację wykonania i kontakt do osoby, która może przerwać pracę. Sprawdź cały proces na fikcyjnej zmianie celu. Efekt powinien być prosty: zespół potrafi wyjaśnić, dlaczego wolno wykonać test, i zatrzymać go, gdy ta podstawa przestaje być aktualna.

> [!CTA]
> **Zadbaj, by granice testów w twoim programie były łatwe do znalezienia.** Opublikuj zakres i sposób zgłaszania spraw, a napływające pytania kieruj do osoby odpowiedzialnej za testy.
>
> [Wypróbuj za darmo](/users/sign_up)