Permanente productietoegang is als een tikkende tijdbom.

Waarom permanente toegang stiller gevaarlijker is dan het lijkt

Het probleem met permanente productierechten is niet dat ze worden misbruikt. Het probleem is dat je niet weet of ze worden misbruikt. Een engineer die zes maanden geleden rechten heeft gekregen voor een incident heeft die rechten waarschijnlijk nooit gebruikt sindsdien. Maar ze zijn er nog wel. En als ze er zijn, kunnen ze worden gebruikt, door die engineer, door iemand met toegang tot zijn account of via een key die ooit ergens in een config-bestand is terechtgekomen.

De risico's stapelen zich op in stilte. Niet als één groot incident, maar als een langzaam groeiende aanvalsoppervlakte die pas zichtbaar wordt als het al te laat is. Een goede JIT-aanpak maakt dat patroon structureel onmogelijk: wie geen actieve aanvraag heeft, heeft geen toegang. Punt.

De aanvraaglaag: structuur zonder bureaucratie

Een JIT-flow begint bij een aanvraag die gestructureerd genoeg is om automatisch te verwerken, maar laagdrempelig genoeg om de werkelijkheid te weerspiegelen. Dat klinkt eenvoudig, maar hier gaat het in de praktijk het vaakst mis. Teams bouwen een formulier, dat formulier wordt te uitgebreid, engineers slaan het over of gaan om het systeem heen, en je bent terug bij af.

De aanvraag moet aansluiten op hoe het team al werkt. Dat kan een intern portaal zijn, een ticketing-integratie, een CLI of een Slack-workflow. De interface is minder belangrijk dan wat erin staat: wie vraagt toegang aan, voor welke scope, voor welke duur en met welk doel. Die vier elementen zijn niet optioneel: ze zijn de invoer voor alles wat daarna komt.

• Scope en duur zijn verplichte velden, geen optionele metadata. Ze sturen provisioning en intrekking rechtstreeks aan
• De reden voor toegang moet bruikbaar zijn voor de approver, niet alleen voor de audit-trail achteraf
• Vrije tekst mag voor context, maar de technische kern moet gestructureerd en machineleesbaar zijn

Approvals die écht iets betekenen

Een approval-stap die neerkomt op een Slack-berichtje met een duimpje omhoog is geen control. Dit is eerder theater. Een goede approval-flow is technisch afdwingbaar: de provisioning start pas als de goedkeuring door het systeem is geregistreerd, door iemand die aantoonbaar bevoegd is voor de gevraagde scope.

Twee regels zijn daarin niet onderhandelbaar. De aanvrager mag zijn eigen aanvraag niet goedkeuren, ook niet als dat "even snel" beter uitkomt. En de beslissing zelf moet onderdeel zijn van dezelfde audit-trail als de rest van de flow, niet los in een chatgeschiedenis of mailarchief dat over twee jaar is verdwenen. Een approval die je niet kunt reconstrueren heeft geen waarde als er een audit komt.

Provisioning via bestaande automation-paden

Na een goedgekeurde aanvraag wil je geen handmatige stap meer. De provisioning hoort in dezelfde automation-paden te landen die je al gebruikt voor infrastructuur en platformwijzigingen. Of dat nu een CI/CD-systeem is, een internal developer platform, een workflow-runner of een combinatie van orchestration en infrastructure-as-code.

In de praktijk betekent dat meestal dat je meerdere lagen tegelijk tijdelijk activeert: een gecontroleerd toegangspunt naar productie, tijdelijke IAM-permissies, database-toegang via een named account, cluster-toegang of netwerkreachability naar een beschermde omgeving. Welke combinatie van toepassing is hangt af van je stack, maar het principe blijft overal gelijk: geef alleen wat nodig is voor de taak, en bind alles aan dezelfde eindtijd.

• Provisioning via bestaande deploy-mechanismen — reproduceerbaar, aantoonbaar, niet handmatig
• Scope toegang op taakniveau: geen brede permissies als een smaller alternatief volstaat
• Koppel identiteit, permissions en eventuele tijdelijke toegangspaden aan dezelfde access window

Credentials en toegangspaden horen niet informeel rond te gaan

Een veelgemaakte fout is dat teams de technische provisioning correct regelen, maar de bijbehorende credentials of connectiedetails alsnog informeel distribueren. Dan heb je op papier JIT, maar in de praktijk nog steeds een gat. Credentials, tokens of connection strings horen per gebruiker, per sessie of per aanvraag te worden uitgegeven en alleen toegankelijk te zijn voor de identiteit waaraan ze zijn gekoppeld.

Hetzelfde geldt voor toegangspaden. Als een bastion, jump host, session manager of tijdelijk netwerksegment onderdeel is van het model, dan valt ook dat pad binnen de gecontroleerde flow. Niet "hier is de toegang" — maar "hier is de tijdelijk geactiveerde route waarlang die toegang veilig en controleerbaar gebruikt kan worden".

Automatische intrekking: de eigenschap die het model sluitend maakt

Intrekking is het onderdeel waar de meeste JIT-implementaties falen. Niet omdat het technisch moeilijk is, maar omdat het als afterthought wordt behandeld. De toegang wordt verleend, en de cleanup "wordt later wel geregeld". Later komt niet, of komt te laat, en zo bouw je opnieuw een achterstand op van rechten die zijn blijven hangen.

In een goed model is intrekking geen aparte stap. Het is een ingebouwde eigenschap van het systeem. Op het moment dat provisioning plaatsvindt, staat de cleanup al gepland. Een scheduler of expiry-mechanisme ruimt op een vastgesteld tijdstip op: tijdelijke compute verwijderd, permissies ingetrokken, sessiepaden gesloten, auditstatus bijgewerkt. Niemand hoeft eraan te denken, want het systeem zorgt ervoor.

Een audit-trail die later ook echt bruikbaar is

"Access granted" is geen audit-trail. Een bruikbare log vertelt het complete verhaal: wie heeft aangevraagd, voor welke scope, hoe lang, met welke goedkeuring, welke resources zijn geactiveerd, wanneer de intrekking heeft plaatsgevonden en of die cleanup succesvol is afgerond. Pas dan kun je bij een audit niet alleen aantonen dat er controle was, maar ook hoe die controle technisch heeft gewerkt.

Die informatie is bij een audit waardevol, maar net zo goed bij incident response. Als er iets misgaat in productie, wil je binnen een minuut kunnen zien welke tijdelijke toegangspaden actief waren op dat moment, wie ze heeft aangevraagd en of ze correct zijn ingetrokken. Een goede log is geen overbodige luxe. Dat moet gewoon onderdeel zijn van de basisprincipes van je platfom.

Waarom teams dit sneller vinden dan de klassieke aanpak

Het tegenintuïtieve aan een goed JIT-model is dat het in de dagelijkse praktijk sneller aanvoelt dan het alternatief. Niet omdat er minder controle is, maar omdat de controle ín de flow zit in plaats van eromheen. Geen losse processen om te omzeilen, geen ad-hoc uitzonderingen die de uitzondering worden op de uitzondering. Wie toegang nodig heeft vraagt het aan, de flow doet de rest.

Voor teams in security, compliance en auditing betekent het dat productietoegang eindelijk uitlegbaar is. Voor de engineers die ermee werken betekent het dat de weg naar productie helder is en niet afhangt van de juiste persoon op de juiste dag. Dat is de winst van governance die technisch is ingebakken in plaats van handmatig afgedwongen.