Just-in-Time Access Uitgelegd: Hoe u Permanente Privileges in uw Onderneming Elimineert

De meeste beveiligingsincidenten in de onderneming waarbij bevoorrechte toegang betrokken is, hebben een gemeenschappelijke oorzaak: het gecompromitteerde account had toegang die het niet nodig had, tot systemen waarmee het weken niet had gewerkt, met referenties die maanden geldig waren geweest. De aanvaller escaleerde privileges niet — de privileges waren al aanwezig, permanent, wachtend. Dit is het permanente-privileges-probleem, en dit is de specifieke lacune die just-in-time-toegang is ontworpen om op te vullen.

Wat Just-in-Time-Toegang Is — en Hoe het Verschilt van Traditionele PAM

Traditionele PAM werkt volgens een vault-en-checkout-model. Bevoorrechte referenties worden opgeslagen in een kluis. Wanneer een systeembeheerder toegang nodig heeft, checken zij referenties uit, verbinden zij zich met het doelsysteem en checken zij de referenties opnieuw in als zij klaar zijn. Dit is beter dan gedeelde spreadsheets en plaknotities, maar het heeft nog steeds een fundamenteel structureel probleem: het bevoorrechte account zelf bestaat permanent op het doelsysteem. Het Administrator-account op de Windows-server, het root-account op de Linux-host, het sa-account op de database — deze accounts zijn altijd aanwezig, altijd ingeschakeld, altijd een doelwit.

Just-in-time (JIT)-toegang hanteert een ander approach: elimineer het permanente account geheel, of zorg er op zijn minst voor dat het account is uitgeschakeld en dat referenties onmiddellijk voor en na elk gebruik worden geroteerd. Toegang wordt op aanvraag voorzien voor een specifieke gebruiker, een specifiek doel en een specifiek tijdvenster. Wanneer het venster verloopt, wordt de toegang automatisch ingetrokken — niet ingecheckt, maar verwijderd.

Het zero-standing-privileges (ZSP)-principe gaat nog verder: geen enkel bevoorrecht account mag permanente toegang tot enig productiesysteem hebben. Elke bevoorrechte sessie is een tijdelijke toekenning met een gedefinieerd begin, een gedefinieerd einde en een volledig audittrail. Wanneer geen sessie actief is, bestaat geen bevoorrechte toegang.

Het praktische verschil tussen traditionele PAM en JIT/ZSP:

• Traditionele PAM: De Domain Admins-groep heeft 15 leden. Referenties zijn in een kluis opgeslagen. Leden checken referenties uit wanneer nodig. De accounts bestaan 24/7 op elke domein-gekoppelde server.
• JIT PAM: Geen permanent Domain Admins-lidmaatschap. Wanneer een systeembeheerder verhoogde toegang nodig heeft, dienen zij een verzoek in dat is beperkt tot een specifieke server en een specifieke duur. Het systeem voorziet in de toegang, creëert de sessie, registreert deze en trekt deze in aan het einde van het tijdvenster.

Het aanvalsoppervlak in het traditionele model is elk moment dat het account bestaat, tegen elk systeem dat het kan bereiken. Het aanvalsoppervlak in het JIT-model is de duur van de goedgekeurde sessie, tegen het specifieke goedgekeurde doel.

Voor JIT versus Na JIT — Een Concreet Scenario

Voor JIT: Een senior systeembeheerder bij een bedrijf met 500 personen werkt al vier jaar in het team. Ze zijn een permanent lid van de Domain Admins-groep en hebben permanente RDP-beheertoegang tot ongeveer 200 servers — ontwikkelings-, staging- en productieservers. Ze gebruiken deze toegang actief voor misschien 20 servers op regelmatige basis. De andere 180 zijn infrastructuur die zij hebben opgezet tijdens migraties en waarmee zij sinds die tijd niet hebben gewerkt. Hun referenties bevinden zich in de bedrijfs-SSO, hun account is nooit gecontroleerd op scopevermindering, en hun toegang is niet veranderd sinds zij zich aansloten.

Wanneer hun laptop in een gerichte phishing-aanval wordt gehackt, heeft de aanvaller onmiddellijke, permanente, onbelemmerde toegang tot alle 200 servers. Het risico is de volledige infrastructuur.

Na JIT: Dezelfde systeembeheerder heeft geen permanente bevoorrechte toegang. Wanneer zij onderhoud moet uitvoeren op een specifieke productieserver, dienen zij een verzoek in: "Ik heb RDP-beheertoegang tot prod-db-03 voor 4 uur nodig om de driemaandelijkse patch toe te passen." Het verzoek wordt beoordeeld door hun manager en een lid van het beveiligingsteam via een Slack-goedkeuringswerkstroom. Eenmaal goedgekeurd voorziet het systeem in een aan tijd gebonden referentie die is beperkt tot die specifieke server. De sessie wordt automatisch van begin tot eind opgenomen. Na 4 uur wordt de toegang ingetrokken en wordt de referentie geroteerd.

Wanneer hun laptop wordt gehackt, heeft de aanvaller toegang tot alle actieve sessies die op dat moment bestaan. Indien geen sessie momenteel is goedgekeurd en actief, heeft de aanvaller geen bevoorrechte toegang tot enig productiesysteem. Het risico wordt beperkt door wat op het moment van het compromis was goedgekeurd en actief — niet de volledige infrastructuurvoetafdruk van de loopbaan van de systeembeheerder.

JIT-Toegang en Compliance — Hoe ZSP Verband Houdt met NIS2, SOC 2 en ISO 27001

JIT-toegang en zero-standing-privileges zijn niet alleen goede beveiligingspraktijk — zij zijn steeds expliciete vereisten in de compliance-kaders die ondernemingen in de CEE en Europa moeten naleven.

NIS2 Artikel 21 — Least Privilege: NIS2 vereist dat essentiële entiteiten toegangscontrole op basis van het least-privilege-beginsel implementeren. "Least privilege" in de NIS2-context betekent dat toegang alleen in de mate mag worden verleend die nodig is om een specifieke taak uit te voeren. Permanente beheertoegang tot 200 servers slaagt voor deze test niet per definitie — de systeembeheerder die regelmatig 20 van deze servers gebruikt, heeft permanente toegang tot 180 die zij niet nodig heeft. JIT-toegang zorgt ervoor dat least privilege structureel wordt afgedwongen: toegang is altijd beperkt tot het specifieke systeem en het tijdvenster van de werkelijke behoefte.

SOC 2 CC6.3 — Toegang Intrekken: De SOC 2 Trust Services Criteria vereisen dat toegang onmiddellijk wordt verwijderd wanneer deze niet meer nodig is. CC6.3 behandelt specifiek het intrekken van toegang voor beëindigde werknemers, rolveranderingen en projectbeëindigingen. JIT-toegang voldoet automatisch aan CC6.3: toegang verloopt aan het einde van het goedgekeurde tijdvenster zonder enige handmatige intrekkingsstap. De vraag van de auditor — "hoe zorgt u ervoor dat toegang wordt verwijderd wanneer deze niet meer nodig is?" — heeft een deterministische antwoord: "Het verloopt automatisch; hier is het audittrail van elke sessieverloop."

ISO 27001 Annex A.9.2 — Toegangsverlening: ISO 27001 A.9.2.2 vereist een formeel toegangsverleningsproces, en A.9.2.3 vereist dat bevoorrechte toegangsrechten op een need-to-use-basis worden toegewezen. "Need-to-use" is de ISO 27001-taal voor least privilege, en het verband met JIT is direct: toegang moet bestaan wanneer nodig en niet wanneer niet nodig. A.9.2.5 vereist periodieke controle van gebruikerstoegangrechten — met JIT-toegang is de controle continu in plaats van periodiek, omdat toegang voor elke sessie opnieuw wordt verleend vanaf nul.

Het compliance-argument voor JIT is eenvoudig: permanente privileges zijn structureel niet compliant met het least-privilege-beginsel dat NIS2, SOC 2 CC6.3 en ISO 27001 A.9.2 allemaal vereisen. JIT is het implementatiepatroon dat least privilege operationeel haalbaar maakt op schaal.

Hoe VaultPAM JIT-Toegang Implementeert

VaultPAM implementeert JIT-toegang via vier geïntegreerde mechanismen:

Goedkeuringswerkstromen: Wanneer een gebruiker bevoorrechte toegang tot een doelsysteem aanvraagt, stuurt VaultPAM het verzoek naar de passende fiatteur — manager, beveiligingsteam, of beide, afhankelijk van het toegangsniveau en de systeemgevoeligheid. Goedkeuringen kunnen via de VaultPAM-webinterface of geïntegreerde meldingskanalen worden voltooid. Het verzoek bevat het doelsysteem, de aangevraagde duur en rechtvaarding, waardoor de fiatteur de context heeft voor een geïnformeerde beslissing.

Aan tijd gebonden sessies: Elke goedgekeurde toegangsverlening bevat een harde vervaltijd. Het sessievenster wordt op goedkeuringstijd ingesteld — 1 uur, 4 uur, 8 uur, of een aangepaste duur tot het beleidsmaximum. Wanneer het sessievenster verloopt, trekt VaultPAM automatisch toegang in. Er is geen handmatige stap, geen herinneringsmail, geen afhankelijkheid van de gebruiker die zich afmeldt. De toegang houdt simpelweg op te bestaan.

Automatisch verlopen en referentierotatie: Voor RDP- en SSH-sessies voorziet VaultPAM aan het begin van het goedgekeurde venster in een sessiepecifieke referentie en roteert deze bij verlopen. De referentie die gedurende de goedgekeurde sessie bestond, werkt niet meer na verlopen. Een aanvaller die de referentie mid-sessie vastlegt, kan deze niet opnieuw gebruiken na sluitingstijd van het venster.

Audittrail: Elk JIT-verzoek — indiening, goedkeuring of afwijzing, sessiestart, sessiediaag, sessie-opname en verlopen — wordt geregistreerd in het onveranderbare auditlog van VaultPAM. Het audittrail bevat de identiteit van de fiatteur, de goedkeuringtijdstempel, de rechtvaardingstekst en een volledige opname van de sessieactiviteit. Dit is het bewijspakket dat voldoet aan NIS2-auditvragen, SOC 2-auditorsteekproeven en ISO 27001-steekproefcontroles.

Bekijk VaultPAM JIT-toegang in actie — elimineer permanente privileges in uw omgeving