Toegangsoverdracht voor beveiligingstests: scope, accounts en intrekking
Een tester die VPN-inloggegevens vraagt, heeft een afgebakende overdracht nodig, geen reserve-login. Controleer de autorisatie, benoem de doelen, verstrek accounts en trek daarna in.
Een tester vraagt om een gatewayadres, interne DNS-gegevens en VPN-inloggegevens, en het verzoek wordt met het onderwerp ‘toegang nodig’ naar u doorgestuurd. Het verzoek alleen vertelt u niet of dit een interne beoordeling, een test van een geauthenticeerde applicatie of een opdracht op een openbare website is waarbij iemand de scope verkeerd heeft begrepen. Voer de overdracht uit als een reeks met een poort bij elke stap, en stop bij de eerste poort die niet opengaat. Dat maakt van een vaag verzoek iets dat u kunt autoriseren, kunt leveren en later kunt intrekken.
Begin met de autorisatie, niet met de inloggegevens
Voordat er een adres uw inbox verlaat, stelt u vast wie de doelen bezit en wie toestemming mag geven voor tests erop. Verifieer de tester via het opdrachtcontact dat uw organisatie al gebruikt, niet via de persoon die de e-mail heeft doorgestuurd. Een klantrelatie is geen toestemming om elk systeem te testen dat vanaf een account bereikbaar is, en een inkooporder is geen scopedocument.
Schrijf het goedgekeurde doel in één zin en houd die naast de overdracht. ‘De authenticatie van het klantportaal beoordelen’ en ‘het interne netwerk beoordelen’ leiden tot totaal verschillende pakketten, en het verschil moet vóór de inrichting worden beslecht, niet nadat een bevinding binnenkomt. De zin geeft u ook iets om naar te wijzen wanneer het verzoek midden in de opdracht groeit.
Als een hostingprovider of een andere derde partij in de weg zit, gaan hun eisen voor uw gemak. De infrastructuur van iemand anders testen zonder diens toestemming is een ander probleem dan de applicatie testen die erop draait.
Benoem het gezichtspunt en de doelen
Het gezichtspunt is de vraag die de beoordeling probeert te beantwoorden, en het bepaalt het toegangspakket meer dan welk hulpmiddel de tester ook wil gebruiken. Een openbare niet-geauthenticeerde test heeft een URL en een tijdvenster nodig. Een geauthenticeerde test heeft toegewijde accounts nodig voor de specifieke rollen binnen de scope, en een interne beoordeling heeft een gedefinieerd toegangspunt nodig met expliciete doelbereiken.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
Waar een tunnel binnenkomt is niet hetzelfde feit als welke applicatie erachter zit, en het machtigt zeker niet tot het onderzoeken van het toegangspunt. Zeg dat expliciet in de overdracht, want de zin ‘je gaf me toegang tot dat subnet’ komt snel zodra een bevinding wordt betwist. Een schriftelijke doellijst is het enige dat dat achteraf beslecht.
Geef de TLS-hostnaam samen met de URL. Een kaal IP-adres dwingt de tester de naam te raden, en een geraden naam levert certificaatfouten op die als bevindingen worden gerapporteerd in plaats van als een fout in de overdracht.
Verstrek toegewijde identiteiten met een vervaldatum
Richt accounts in die alleen voor deze opdracht bestaan; leen niet het dagelijkse login van een medewerker. Stel netwerkbereikbaarheid en applicatierechten in op de afgesproken taken, regel authenticatie-inschrijving via een ondersteund pad, en voeg een vervaldatum toe met een genoemde persoon die verantwoordelijk is voor intrekking. Lever de inloggegevens via een afgesproken veilig kanaal, los van het scopedocument dat rondgestuurd wordt.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Leg vast wie wat heeft ontvangen, en wanneer. Dat overzicht is het verschil tussen een gecontroleerde overdracht en een gedeeld wachtwoord dat niemand kan traceren, en het is het eerste waar iedereen na een incident om vraagt. Bewaar het bij het scopedocument in plaats van in een chatthread, en noteer het leveringskanaal naast de ontvanger. Een regel met een tijdstempel wint het elke keer van een herinnering.
Het vervaldatumveld is een vangnet, niet het plan. Iemand moet aan het eind nog steeds het netwerkpad en de applicatierol verwijderen, want een verlopen login op een netwerk dat nog bereikbaar is, is geen ingetrokken toegang.
Bewijs dat de overdracht werkt voordat het venster opengaat
Voer de eerste hop van de tester zelf uit, vanaf een positie zo dicht mogelijk bij de zijne. Los de naam op, controleer de certificaatidentiteit en bevestig dat het pad het bedoelde adres bereikt en niet een naburig adres.
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
Als het pad een doel niet kan bereiken, pauzeer en stem de overdracht af in plaats van de tester een alternatieve route te laten ontdekken. Geïmproviseerde bereikbaarheid is hoe een beoordeling stilzwijgend buiten zijn scope groeit, en het wordt achteraf bijna nooit gedocumenteerd.
Stuur het operationele contact, de toegestane uren, uitgesloten handelingen en stopvoorwaarden mee met de inloggegevens. Een tester die om 02:00 niemand kan bereiken, neemt een beslissing die u niet hebt geautoriseerd, en die beslissing wordt in het rapport beschreven alsof zij binnen de scope viel.
NIST SP 800-115 kadert een technische beoordeling als geplande tests gevolgd door analyse en mitigatie, en dat is de vorm die deze overdracht volgt. De poorten hierboven zijn redactionele ontwerpkeuzes voor een supportengineer, geen checklist die uit die publicatie is geciteerd.
Sluit de opdracht af door de toegang te verwijderen
Trek in omgekeerde volgorde van de inrichting in: applicatierollen, dan netwerktoegang, dan de identiteit zelf. Bevestig elke stap in plaats van aan te nemen dat de console deed wat de knop beloofde. Vergrendel het account voordat u de sessies beëindigt, anders authenticeert de sessie zich gewoon opnieuw via het oude pad. Controleer daarna de bestaande verbindingen nog eens voordat u het als gesloten beschouwt.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Wikkel eventuele bewaarde testgegevens af en volg daarna de herstelactie via het rapportageproces dat u aan het begin hebt afgesproken. Het rapport moet de omgeving, het toegangsniveau, de scope en de beperkingen vermelden, omdat het bevindingen van één beoordeling vastlegt en geen permanente verklaring is dat de site veilig is.
Bewaar het intrekkingsrecord bij het overdrachtsrecord. Wanneer de volgende opdracht opengaat, wilt u precies weten wat de vorige keer is verwijderd en wie dat heeft goedgekeurd, in plaats van het beeld uit het geheugen te reconstrueren.