Överlämning av åtkomst för säkerhetstest: omfattning, konton och återkallande

En testare begär en gatewayadress, interna DNS-uppgifter och VPN-uppgifter, och begäran vidarebefordras till dig med ämnet ”åtkomst behövs”. Begäran i sig säger inte om det är en intern bedömning, ett test av en autentiserad applikation eller ett uppdrag på en offentlig webbplats där någon har missförstått omfattningen. Kör överlämningen som en sekvens med en port vid varje steg, och stanna vid den första port som inte öppnas. Det gör en vag begäran till något du kan auktorisera, leverera och senare återkalla.

Börja med auktorisationen, inte med uppgifterna

Innan någon adress lämnar din inkorg ska du fastställa vem som äger målen och vem som får godkänna testning på dem. Verifiera testaren genom uppdragets kontakt som din organisation redan använder, inte genom personen som vidarebefordrade e-postmeddelandet. En kundrelation är inte tillstånd att testa varje system som nås från ett konto, och en inköpsorder är inte ett omfattningsdokument.

Skriv det godkända målet i en mening och håll den bredvid överlämningen. ”Bedöm kundportalens autentisering” och ”bedöm det interna nätverket” leder till helt olika paket, och skillnaden måste avgöras före etableringen, inte efter att en iakttagelse har kommit in. Meningen ger dig också något att peka på när begäran växer mitt i uppdraget.

Om en webbhotelleverantör eller en annan tredje part finns i vägen kommer deras krav före din bekvämlighet. Att testa någon annans infrastruktur utan deras tillstånd är ett annat problem än att testa applikationen som körs på den.

Namnge synvinkeln och målen

Synvinkeln är frågan som bedömningen försöker besvara, och den bestämmer åtkomstpaketet mer än något verktyg som testaren planerar att använda. Ett offentligt oautentiserat test behöver en URL och ett tidsfönster. Ett autentiserat test behöver dedikerade konton för de specifika rollerna inom omfattningen, och en intern bedömning behöver en definierad ingångspunkt med uttryckliga målintervall.

Var en tunnel kommer in är inte samma faktum som vilken applikation som ligger bakom den, och det ger absolut inte tillstånd att undersöka ingångspunkten. Säg det uttryckligen i överlämningen, för meningen ”du gav mig åtkomst till det subnätet” kommer snabbt när en iakttagelse ifrågasätts. En skriftlig mållista är det enda som avgör det efteråt.

Ange TLS-värdnamnet tillsammans med URL:en. En bar IP-adress tvingar testaren att gissa namnet, och ett gissat namn ger certifikatfel som rapporteras som iakttagelser i stället för som ett fel i överlämningen.

Utfärda dedikerade identiteter med ett utgångsdatum

Etablera konton som bara finns för detta uppdrag; låna inte ut en medarbetares dagliga inloggning. Ställ in nätverksbarhet och applikationsbehörigheter efter de avtalade uppgifterna, ordna autentiseringsregistrering via en stödd väg, och bifoga ett utgångsdatum med en namngiven person som ansvarar för återkallandet. Leverera uppgifterna via en avtalad säker kanal, skilt från omfattningsdokumentet som vidarebefordras runt.

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

Registrera vem som fick vad, och när. Den registreringen är skillnaden mellan en kontrollerad överlämning och ett delat lösenord som ingen kan spåra, och det är det första alla frågar efter vid en incident. Förvara den tillsammans med omfattningsdokumentet i stället för i en chattråd, och notera leveranskanalen bredvid mottagaren. En rad med tidsstämpel slår en minnesbild varje gång.

Utgångsdatumfältet är ett skyddsnät, inte planen. Någon måste ändå ta bort nätverksvägen och applikationsrollen till slut, eftersom en utgången inloggning på ett nätverk som fortfarande är nåbart inte är återkallad åtkomst.

Bevisa att överlämningen fungerar innan fönstret öppnas

Kör testarens första hopp själv, från en position så nära hens som möjligt. Slå upp namnet, kontrollera certifikatets identitet och bekräfta att vägen når den avsedda adressen och inte en närliggande.

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

Om vägen inte kan nå ett mål ska du pausa och stämma av överlämningen i stället för att låta testaren hitta en alternativ väg. Improviserad nåbarhet är hur en bedömning tyst växer bortom sin omfattning, och det dokumenteras nästan aldrig efteråt.

Skicka den operativa kontakten, tillåtna timmar, uteslutna åtgärder och stoppvillkor tillsammans med uppgifterna. En testare som inte når någon klockan 02:00 fattar ett beslut som du inte har auktoriserat, och det beslutet kommer att beskrivas i rapporten som om det låg inom omfattningen.

NIST SP 800-115 ramar in en teknisk bedömning som planerad testning följd av analys och mildring, och det är den form som denna överlämning följer. Portarna ovan är redaktionella designval för en supportingenjör, inte en checklista citerad från den publikationen.

Avsluta uppdraget genom att ta bort åtkomsten

Återkalla i omvänd ordning mot etableringen: applikationsroller, sedan nätverksåtkomst, sedan identiteten själv. Bekräfta varje steg i stället för att anta att konsolen gjorde det knappen lovade. Lås kontot innan du dödar dess sessioner, annars autentiserar sessionen helt enkelt om via den gamla vägen. Kontrollera sedan de etablerade anslutningarna en gång till innan du kallar det stängt.

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

Gör upp eventuella kvarhållna testdata och följ sedan åtgärden genom rapportprocessen ni kom överens om i början. Rapporten ska ange miljön, åtkomstnivån, omfattningen och begränsningarna, eftersom den registrerar iakttagelser från en bedömning och inte är ett permanent uttalande om att webbplatsen är säker.

Förvara återkallanderegistreringen tillsammans med överlämningsregistreringen. När nästa uppdrag öppnas vill du veta exakt vad som togs bort förra gången och vem som godkände det, i stället för att bygga upp bilden ur minnet.