Overlevering av tilgang for sikkerhetstesting: omfang, kontoer og tilbakekalling

En tester ber om en gatewayadresse, interne DNS-detaljer og VPN-legitimasjon, og forespørselen videresendes til deg med emnet «tilgang trengs». Forespørselen alene forteller deg ikke om dette er en intern vurdering, en test av en autentisert applikasjon eller et oppdrag på et offentlig nettsted der noen har misforstått omfanget. Kjør overleveringen som en sekvens med en port ved hvert trinn, og stopp ved den første porten som ikke åpner seg. Det gjør en vag forespørsel om til noe du kan autorisere, levere og senere tilbakekalle.

Begynn med autorisasjonen, ikke legitimasjonen

Før noen adresse forlater innboksen din, må du fastslå hvem som eier målene og hvem som har lov til å godkjenne testing på dem. Verifiser testeren gjennom oppdrags kontakten organisasjonen din allerede bruker, ikke gjennom personen som videresendte e-posten. Et kundeforhold er ikke tillatelse til å teste hvert system som er tilgjengelig fra en konto, og en innkjøpsordre er ikke et omfangsdokument.

Skriv det godkjente målet i én setning og ha det ved siden av overleveringen. «Vurder autentiseringen til kundeportalen» og «vurder det interne nettverket» fører til helt forskjellige pakker, og forskjellen må avklares før klargjøringen, ikke etter at et funn har kommet inn. Setningen gir deg også noe å peke på når forespørselen vokser midt i oppdraget.

Hvis en hostingleverandør eller en annen tredjepart er i veien, kommer deres krav før din bekvemmelighet. Å teste andres infrastruktur uten deres tillatelse er et annet problem enn å teste applikasjonen som kjører på den.

Navngi synspunktet og målene

Synspunktet er spørsmålet vurderingen prøver å svare på, og det bestemmer tilgangspakken mer enn noe verktøy testeren planlegger å bruke. En offentlig uautentisert test trenger en URL og et tidsvindu. En autentisert test trenger dedikerte kontoer for de spesifikke rollene i omfanget, og en intern vurdering trenger et definert inngangspunkt med eksplisitte målområder.

Hvor en tunnel kommer inn er ikke det samme faktum som hvilken applikasjon som ligger bak den, og det autoriserer absolutt ikke å undersøke inngangspunktet. Si det eksplisitt i overleveringen, for setningen «du ga meg tilgang til det subnettet» kommer raskt så snart et funn bestrides. En skriftlig målliste er det eneste som avgjør det i etterkant.

Oppgi TLS-vertsnavnet sammen med URL-en. En bar IP-adresse tvinger testeren til å gjette navnet, og et gjettet navn gir sertifikatfeil som rapporteres som funn i stedet for som en feil i overleveringen.

Utsted dedikerte identiteter med en utløpsdato

Klargjør kontoer som bare finnes for dette oppdraget; ikke lån en ansatts daglige innlogging. Sett nettverkstilgjengelighet og applikasjonstillatelser til de avtalte oppgavene, ordn autentiseringsregistrering gjennom en støttet vei, og fest en utløpsdato med en navngitt person som er ansvarlig for tilbakekallingen. Lever legitomasjonen gjennom en avtalt sikker kanal, atskilt fra omfangsdokumentet som videresendes rundt.

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

Registrer hvem som mottok hva, og når. Den registreringen er forskjellen mellom en kontrollert overlevering og et delt passord ingen kan spore, og det er det første alle spør om etter en hendelse. Oppbevar den sammen med omfangsdokumentet i stedet for i en chat-tråd, og noter leveringskanalen ved siden av mottakeren. En linje med tidsstempel slår en erindring hver gang.

Utløpsfeltet er et sikkerhetsnett, ikke planen. Noen må fortsatt fjerne nettverksveien og applikasjonsrollen til slutt, fordi en utløpt innlogging på et nettverk som fortsatt er tilgjengelig ikke er tilbakekalt tilgang.

Bevis at overleveringen virker før vinduet åpnes

Kjør testerens første hopp selv, fra en posisjon så nær deres som mulig. Slå opp navnet, kontroller sertifikatets identitet, og bekreft at veien når den tiltenkte adressen og ikke en nabo.

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

Hvis veien ikke kan nå et mål, stopp og avstem overleveringen i stedet for å la testeren oppdage en alternativ rute. Improvisert tilgjengelighet er hvordan en vurdering stille vokser utover omfanget, og det blir nesten aldri dokumentert etterpå.

Send den operative kontakten, tillatte timer, utelukkede handlinger og stoppbetingelser sammen med legitomasjonen. En tester som ikke når noen klokken 02:00 vil ta en beslutning du ikke har autorisert, og den beslutningen vil bli beskrevet i rapporten som om den var innenfor omfanget.

NIST SP 800-115 rammer inn en teknisk vurdering som planlagt testing etterfulgt av analyse og avbøting, og det er formen denne overleveringen følger. Portene ovenfor er redaksjonelle designvalg for en støtteingeniør, ikke en sjekkliste sitert fra den publikasjonen.

Avslutt oppdraget ved å fjerne tilgangen

Tilbakekall i omvendt rekkefølge av klargjøringen: applikasjonsroller, deretter nettverkstilgang, deretter selve identiteten. Bekreft hvert trinn i stedet for å anta at konsollen gjorde det knappen lovet. Lås kontoen før du dreper sesjonene, ellers autentiserer sesjonen seg bare på nytt via den gamle veien. Kontroller deretter de etablerte forbindelsene en gang til før du kaller det lukket.

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

Avgjør eventuelle tilbakeholdte testdata, og følg deretter utbedringen gjennom rapporteringsprosessen dere ble enige om i starten. Rapporten bør oppgi miljøet, tilgangsnivået, omfanget og begrensningene, fordi den registrerer funn fra én vurdering og er ikke en permanent erklæring om at nettstedet er sikkert.

Oppbevar tilbakekallingsregistreringen sammen med overleveringsregistreringen. Når det neste oppdraget åpnes, vil du vite nøyaktig hva som ble fjernet sist og hvem som godkjente det, i stedet for å gjenoppbygge bildet fra hukommelsen.