Předání přístupu pro bezpečnostní testování: rozsah, účty a odvolání

Tester žádá adresu brány, podrobnosti o interním DNS a přihlašovací údaje k VPN a žádost vám přijde s předmětem „je potřeba přístup“. Samotná žádost vám neřekne, zda jde o interní hodnocení, test autentizované aplikace, nebo zakázku na veřejný web, kde někdo špatně pochopil rozsah. Veďte předání jako sled kroků s branou v každém z nich a zastavte se u první brány, která se neotevře. Tím se z neurčité žádosti stane něco, co můžete autorizovat, vydat a později odvolat.

Začněte autorizací, ne přihlašovacími údaji

Než z vaší schránky odejde jakákoli adresa, určete, komu patří cíle a kdo smí schválit testování na nich. Ověřte testera přes kontakt na zakázku, který vaše organizace už používá, ne přes osobu, která e-mail přeposlala. Vztah se zákazníkem není oprávnění testovat každý systém dostupný z účtu a objednávka není dokumentem o rozsahu.

Schválený cíl napište jednou větou a mějte ji u předání. „Posuďte autentizaci klientského portálu“ a „posuďte interní síť“ vedou ke zcela odlišným balíčkům a rozdíl je nutné vyřešit před zřízením přístupů, ne až po nálezu. Věta vám také dává něco, na co můžete ukázat, když žádost uprostřed zakázky naroste.

Pokud je v cestě poskytovatel hostingu nebo jiná třetí strana, jejich požadavky mají přednost před vaším pohodlím. Testovat cizí infrastrukturu bez jejich svolení je jiný problém než testovat aplikaci, která na ní běží.

Pojmenujte pohled a cíle

Pohled je otázka, na kterou se hodnocení snaží odpovědět, a určuje balíček přístupu víc než jakýkoli nástroj, který tester plánuje použít. Veřejný neautentizovaný test potřebuje URL a časové okno. Autentizovaný test potřebuje vyhrazené účty pro konkrétní role v rozsahu a interní hodnocení potřebuje definovaný vstupní bod s výslovnými rozsahy cílů.

Kde tunel vstupuje, není stejný fakt jako která aplikace za ním stojí, a rozhodně to neopravňuje sondovat vstupní bod. Řekněte to v předání výslovně, protože věta „dal jsi mi přístup do té podsítě“ přijde rychle, jakmile je nález zpochybněn. Písemný seznam cílů je jediná věc, která to potom vyřeší.

Uveďte spolu s URL i jméno hostitele TLS. Samotná IP adresa nutí testera hádat jméno a uhodnuté jméno vytváří chyby certifikátu, které se hlásí jako nálezy, ne jako chyba předání.

Vystavte vyhrazené identity s platností

Zřiďte účty, které existují jen pro tuto zakázku; nepůjčujte každodenní přihlášení zaměstnance. Nastavte síťovou dostupnost a oprávnění aplikace podle dohodnutých úkolů, zajistěte registraci autentizace podporovanou cestou a připojte datum vypršení platnosti s jmenovanou osobou odpovědnou za odvolání. Předejte přihlašovací údaje dohodnutým bezpečným kanálem, odděleně od dokumentu o rozsahu, který se přeposílá kolem.

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

Zaznamenejte, kdo co dostal a kdy. Tento záznam je rozdíl mezi řízeným předáním a sdíleným heslem, které nikdo nedokáže vysledovat, a je to první věc, kterou po incidentu každý žádá. Uchovávejte ho u dokumentu o rozsahu, ne ve vlákně chatu, a poznamenejte kanál doručení vedle příjemce. Řádek s časovým razítkem vždy porazí vzpomínku.

Pole platnosti je poslední pojistka, ne plán. Na konci ještě někdo musí odstranit síťovou cestu a roli aplikace, protože prošlé přihlášení v dosud dostupné síti není odvolaný přístup.

Dokažte, že předání funguje, než se okno otevře

Proveďte první skok testera sami, z pozice co nejblíže té jeho. Přeložte jméno, zkontrolujte identitu certifikátu a potvrďte, že cesta vede k zamýšlené adrese, ne k sousední.

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

Pokud se cesta k cíli nedostane, zastavte se a předání slaďte, místo abyste testerovi nechali objevit alternativní trasu. Improvizovaná dostupnost je způsob, jak hodnocení tiše přesáhne svůj rozsah, a téměř nikdy se to potom nedokumentuje.

Pošlete s přihlašovacími údaji provozní kontakt, povolené hodiny, vyloučené akce a podmínky zastavení. Tester, který ve 02:00 nikoho nezastihne, učiní rozhodnutí, které jste neschválili, a toto rozhodnutí bude ve zprávě popsáno, jako by bylo v rozsahu.

NIST SP 800-115 rámuje technické hodnocení jako plánované testování následované analýzou a zmírněním, což je tvar, který toto předání sleduje. Brány výše jsou redakční designová rozhodnutí pro inženýra podpory, ne kontrolní seznam citovaný z této publikace.

Uzavřete zakázku odstraněním přístupu

Odvolávejte v opačném pořadí, než jste zřizovali: role aplikace, potom síťový přístup, potom samotnou identitu. Každý krok potvrďte, místo abyste předpokládali, že konzole udělala, co tlačítko slibovalo. Zamkněte účet dřív, než zabijete jeho relace, jinak se relace prostě znovu autentizuje starou cestou. Potom ještě jednou zkontrolujte navázaná spojení, než to prohlásíte za uzavřené.

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

Vyřešte případná zadržená testovací data a potom sledujte nápravu přes proces hlášení, na kterém jste se dohodli na začátku. Zpráva má uvést prostředí, úroveň přístupu, rozsah a omezení, protože zaznamenává nálezy z jednoho hodnocení a není trvalým tvrzením, že je web bezpečný.

Uchovávejte záznam o odvolání spolu se záznamem o předání. Když se otevře další zakázka, chcete přesně vědět, co bylo minule odstraněno a kdo to odsouhlasil, místo abyste obraz rekonstruovali z paměti.