Przekazanie dostępu do testów bezpieczeństwa: zakres, konta i odbiór

Tester prosi o adres bramy, szczegóły wewnętrznego DNS i dane logowania VPN, a wniosek jest przekazywany do ciebie z tematem „potrzebny dostęp”. Sam wniosek nie mówi, czy to ocena wewnętrzna, test aplikacji z uwierzytelnianiem, czy praca na publicznej stronie, w której ktoś źle zrozumiał zakres. Przeprowadź przekazanie jako sekwencję z bramką na każdym kroku i zatrzymaj się na pierwszej bramce, która się nie otwiera. To zamienia niejasny wniosek w coś, co możesz autoryzować, przekazać i później odebrać.

Zacznij od autoryzacji, a nie od danych logowania

Zanim jakikolwiek adres opuści twoją skrzynkę, ustal, kto jest właścicielem celów i kto może zatwierdzać na nich testy. Zweryfikuj testera przez kontakt do projektu, którego twoja organizacja już używa, a nie przez osobę, która przesłała e-mail. Relacja z klientem nie jest zgodą na testowanie każdego systemu dostępnego z konta, a zamówienie zakupu nie jest dokumentem zakresu.

Zapisz zatwierdzony cel w jednym zdaniu i trzymaj je obok przekazania. „Oceń uwierzytelnianie portalu klienta” i „oceń sieć wewnętrzną” prowadzą do zupełnie różnych pakietów, a różnicę trzeba rozstrzygnąć przed przygotowaniem dostępu, a nie po zgłoszeniu znaleziska. Zdanie daje ci też coś, na co możesz wskazać, gdy wniosek rośnie w trakcie pracy.

Jeśli na drodze jest dostawca hostingu lub inna strona trzecia, jej wymagania idą przed twoją wygodą. Testowanie cudzej infrastruktury bez jej zgody to odrębny problem od testowania aplikacji, która na niej działa.

Nazwij punkt widzenia i cele

Punkt widzenia to pytanie, na które próbuje odpowiedzieć ocena, i określa pakiet dostępu bardziej niż jakiekolwiek narzędzie, które tester planuje użyć. Publiczny nieuwierzytelniony test wymaga adresu URL i okna czasowego. Test uwierzytelniony wymaga dedykowanych kont dla konkretnych ról w zakresie, a ocena wewnętrzna wymaga zdefiniowanego punktu wejścia z jawnymi zakresami celów.

To, gdzie wchodzi tunel, nie jest tym samym faktem co aplikacja, która za nim stoi, i z pewnością nie upoważnia do sondowania punktu wejścia. Powiedz to wprost w przekazaniu, bo zdanie „dałeś mi dostęp do tej podsieci” pojawia się szybko, gdy znalezisko jest kwestionowane. Pisemna lista celów to jedyna rzecz, która to później rozstrzyga.

Podaj nazwę hosta TLS razem z adresem URL. Sam adres IP zmusza testera do zgadywania nazwy, a zgadnięta nazwa powoduje błędy certyfikatu, które są zgłaszane jako znaleziska, a nie jako błąd w przekazaniu.

Wydaj dedykowane tożsamości z terminem ważności

Przygotuj konta istniejące tylko na potrzeby tej pracy; nie pożyczaj codziennego logowania pracownika. Ustaw osiągalność sieci i uprawnienia aplikacji według uzgodnionych zadań, zorganizuj rejestrację uwierzytelniania wspieraną ścieżką i dołącz termin ważności wraz z imiennie wskazaną osobą odpowiedzialną za odebranie. Przekaż dane logowania uzgodnionym bezpiecznym kanałem, oddzielnie od dokumentu zakresu, który krąży dalej.

sudo useradd -m -e 2026-12-31 tester01
sudo passwd -S tester01
id tester01
lastlog -u tester01

Zapisuj, kto co otrzymał i kiedy. Ten rejestr to różnica między kontrolowanym przekazaniem a współdzielonym hasłem, którego nikt nie potrafi prześledzić, i to pierwsza rzecz, o którą każdy pyta po incydencie. Trzymaj go przy dokumencie zakresu, a nie w wątku czatu, i zanotuj kanał przekazania obok odbiorcy. Wiersz z datą i godziną zawsze wygrywa z pamięcią.

Pole terminu ważności to ostatnia siatka bezpieczeństwa, a nie plan. Ktoś na końcu i tak musi usunąć ścieżkę sieciową i rolę aplikacji, bo wygasłe logowanie w sieci wciąż osiągalnej nie jest odebranym dostępem.

Udowodnij, że przekazanie działa, zanim otworzy się okno

Wykonaj pierwszy skok testera sam, z pozycji tak blisko jego pozycji, jak to możliwe. Rozwiąż nazwę, sprawdź tożsamość certyfikatu i potwierdź, że ścieżka dociera do zamierzonego adresu, a nie sąsiedniego.

dig +short app.example.com
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates
ip route get 10.60.0.25

Jeśli ścieżka nie dociera do celu, zatrzymaj się i uzgodnij przekazanie, zamiast pozwalać testerowi odkryć alternatywną trasę. Improwizowana osiągalność to sposób, w jaki ocena po cichu wykracza poza swój zakres, i prawie nigdy nie jest to później dokumentowane.

Wyślij wraz z danymi logowania kontakt operacyjny, dozwolone godziny, wykluczone działania i warunki zatrzymania. Tester, który o 02:00 nie może się z nikim skontaktować, podejmie decyzję, której nie autoryzowałeś, a ta decyzja zostanie opisana w raporcie tak, jakby mieściła się w zakresie.

NIST SP 800-115 ujmuje ocenę techniczną jako zaplanowane testy, po których następuje analiza i łagodzenie, i taki właśnie kształt ma to przekazanie. Bramki powyżej to redakcyjne decyzje projektowe dla inżyniera wsparcia, a nie lista kontrolna cytowana z tej publikacji.

Zamknij pracę, usuwając dostęp

Odbieraj w odwrotnej kolejności do przygotowania: role aplikacji, potem dostęp sieciowy, potem sama tożsamość. Potwierdzaj każdy krok, zamiast zakładać, że konsola zrobiła to, co obiecywał przycisk. Zablokuj konto, zanim zabijesz jego sesje, inaczej sesja po prostu ponownie uwierzytelni się starą ścieżką. Następnie sprawdź jeszcze raz ustanowione połączenia, zanim uznasz to za zamknięte.

sudo passwd -l tester01
sudo pkill -u tester01
ss -tn state established '( sport = :443 )'

Rozlicz wszelkie zatrzymane dane testowe, a następnie śledź naprawę przez proces raportowania uzgodniony na początku. Raport powinien podawać środowisko, poziom dostępu, zakres i ograniczenia, bo rejestruje znaleziska jednej oceny i nie jest trwałym stwierdzeniem, że strona jest bezpieczna.

Trzymaj rejestr odebrania razem z rejestrem przekazania. Gdy otworzy się następna praca, chcesz dokładnie wiedzieć, co usunięto ostatnim razem i kto to zatwierdził, zamiast odtwarzać obraz z pamięci.