ontslag

Toen een voormalig senior developer onlangs toegang probeerde te krijgen tot onze productieomgeving, 72 uur na zijn ontslag, had hij al geen actieve credentials meer - en dat was geen toeval, maar een volledig geautomatiseerd proces. Het technische fundament van ontslag is veel meer dan een HR-formulier; het is een hard realtime integratievraagstuk tussen HR-platforms - identity providers, infrastructuurcode en compliance-automatisering. In dit artikel duik ik diep in de engineering achter ontslag: hoe je Identity lifecycle management, zero-touch deprovisioning en audit-trails ontwerpt die menselijke fouten elimineren en bedrijfsrisico's tot bijna nul reduceren.

Een ontslagprocedure die niet direct alle digitale toegang intrekt, opent de deur naar datalekken, saboterende ex-werknemers en boetes van toezichthouders. In productieomgevingen heb ik meerdere keren gezien hoe organisaties pas na een incident beseffen dat een ontslagen medewerker nog SSH-sleutels of API-tokens had. Vanuit mijn ervaring als infrastructure engineer bij meerdere SaaS-bedrijven, is het antwoord niet meer policies schrijven, maar het afdwingen van een technische architectuur waarin ontslag een event is dat onmiddellijk cascades van acties triggert - van Okta-suspension tot Terraform-apply die IAM-bindings verwijdert.

Waarom handmatige offboarding faalt in moderne cloudarchitecturen

Wanneer een medewerker ontslag krijgt of neemt, moet de organisatie honderden digitale assets ontkoppelen: e-mailaccounts, VPN, SaaS-applicaties, CI/CD-pipelines, databases, cloud IAM-rollen en soms zelfs fysieke badge-systemen. Het klassieke model van een IT-medewerker die een checklist afloopt, schaalt niet en is foutgevoelig. Uit een survey van het Ponemon Institute (2022) bleek dat 56% van de organisaties incidenten heeft meegemaakt waarbij ex-medewerkers nog toegang hadden na hun ontslag. Vooral engineeringteams met privileged access (AWS Administrator, database root) vormen een kritiek risico.

In onze staging-omgeving ontdekten we na een reorganisatie dat een vertrokken DevOps-engineer nog steeds een actief GitHub Personal Access Token had dat gekoppeld was aan productie-terraform state. Het token was niet opgenomen in de offboarding-runbook omdat het via een lokale machine was gegenereerd. Deze ontdekking leidde tot de fundamentele ontwerpregel: alle toegang moet via een centrale identity provider lopen en alle langlevende credentials moeten vervangen worden door just-in-time, kortlevende tokens, zoals HashiCorp Vault dynamic secrets. Alleen dan kan een ontslag gegarandeerd alle ingangen afsluiten.

De rol van SCIM en HR-IT-integraties bij geautomatiseerd ontslag

Het kloppend hart van elke robuuste offboarding is een HR-platform (Workday, BambooHR, Personio) dat als gezaghebbende bron voor werknemersstatus fungeert. Zodra HR de status van een medewerker wijzigt in 'uit dienst' - of dat nu vrijwillig of gedwongen ontslag is - start een SCIM (System for Cross-domain Identity Management) feed naar de identity provider (IdP). Wij gebruiken het Workday-connector voor Okta die via SCIM 2. 0 (RFC 7644) een 'deactivate' event stuurt. De IdP schorst dan onmiddellijk het primaire account, verwijdert het uit alle groepen en zet een workflows in gang voor downstream-applicaties.

Het is essentieel dat de integratie realtime of near-realtime is. Batching elk half uur kan een venster van 29 minuten openlaten waarin nog toegang bestaat. In onze architectuur hebben we een event-driven model geïmplementeerd: een webhook vanuit Workday triggert een AWS Lambda die de Okta API aanroept en tegelijkertijd een ticket in PagerDuty opent voor de post-ontslag validatie. Dit patroon, beschreven in de Okta SCIM developer docs, transformeert een ontslag van een handmatige handeling naar een technisch gegarandeerd proces.

Infrastructure-as-Code en het verwijderen van cloudprivileges na ontslag

Een HR-gedreven accountdeactivatie schakelt het menselijke login uit, maar cloudresources (EC2 instances toegang via IAM roles, Kubernetes service accounts) opereren vaak zonder directe menselijke sessie. Daarom moet infrastructure as code (IaC) een ontslag afhandelen door de IAM-bindings in een aparte terraform-configuratie aan te passen. Wij beheren een 'account-permissions' repository waarin elke gebruiker gekoppeld is aan AWS IAM-roles via een YAML-manifest. Bij ontslag verwijdert een GitOps-pipeline de gebruiker uit de manifesten en past Terraform automatisch de cloudomgeving aan.

Concreet: een engineer met ontslag uit de AWS-administratorgroep wordt uit de AWS SSO Identity Store verwijderd door Okta, maar om ook nog eventuele losse inline policies te verwijderen, draait een scheduled AWS Config rule die elke 15 minuten checkt of er IAM-principals zijn die niet meer in de autorisatieve identity database staan. Deze detectie-after-the-fact is een vangnet voor wat de IaC-pipeline niet afdekt. We combineren dus preventie (SCIM/IaC) met detectie (config drift scanning) - een typisch SRE-patroon voor betrouwbare systemen.

Zero Trust en session termination: ontslag dieper in de stack afdwingen

Zelfs als een account gedeactiveerd is, kunnen bestaande sessies nog minuten tot uren actief blijven, vooral in applicaties die stateful tokens gebruiken. In een zero trust-architectuur moet een ontslag leiden tot onmiddellijke sessievernietiging. Wij hebben hiervoor een combinatie ingezet van Okta's session management API en een reverse proxy (Pomerium) die bij elke request de gebruikerstoestand valideert. Wanneer Okta een pushes event stuurt naar de Pomerium-configurator, worden alle actieve sessions van die gebruiker in één keer revoked.

Een technische nuance: SAML-authenticaties bieden vaak geen native sessiebeëindiging, maar OAuth 2. 0 tokens kunnen via token introspection ongeldig worden verklaard. We migreren daarom alle interne applicaties naar OIDC met refresh token rotation en een korte levensduur van access tokens (5 minuten). Het intrekken van refresh tokens gebeurt via de authorization server zodra het ontslag verwerkt is. Dit zorgt ervoor dat een ex-medewerker nog maximaal 5 minuten services kan aanroepen - een aanvaardbaar risico dat we verder mitigeren met anomaly detection op basis van activiteitspatronen (zie volgende sectie).

Observability en detectie: anomalieën na een ontslag signaleren

Geen automatiseringssysteem is perfect; er kunnen edge cases zijn zoals een device dat nog een offline-gecachte token heeft. Daarom behandelen we elke ontslag-gebeurtenis als een high-priority observability event. Ons SIEM (Splunk) correleert de tijdstempels van het HR-event met alle loginpogingen van die gebruiker in de volgende 24 uur. Een enkele loginpoging na deactivatietijd resulteert in een critical alert naar het incident response team.

We hebben ook een ML-model getraind op normale gedragspatronen van vertrekkende medewerkers (zoals massale downloads van repositories in de laatste week) om proactief te alarmeren voorafgaand aan het ontslag. Technisch gebruiken we een combinatie van AWS CloudTrail logs en GitHub audit logs die via Kinesis Data Firehose in een feature store belanden. Dit model helpt niet alleen bij risico-reductie maar verschaft HR ook objectieve data in disputen rondom ontslag. Zoals beschreven in het paper "Detecting Insider Threats with Network and File Activity Data" is gedragsanalyse het sterkst als het focust op de transitiefase van een medewerker.

Datarecht en compliance in het ontslagproces: GDPR 'recht op vergetelheid'

In Europa heeft een ontslag niet alleen operationele, maar ook privacyrechtelijke gevolgen. Ex-medewerkers kunnen een beroep doen op het recht op wissing (artikel 17 AVG). Als softwareorganisatie moet je vooraf vastleggen welke systemen persoonsgegevens verwerken en binnen welke termijn deze gewist worden. Het is een misvatting dat je simpelweg het account deactiveert; logbestanden, backups en analytics-databases kunnen nog persoonsgegevens bevatten die onder het verzoek vallen.

Wij hebben een data inventory opgesteld met een retention policy per dataclassificatie. Bij een ontslag triggeren we niet alleen accountdeactivatie, maar ook een Jira-ticket voor de Data Protection Officer met een checklist: controleer of de ex-medewerker geïdentificeerde gegevens heeft in HR-archieven, CRM (bijv als contactpersoon bij klanten) en in git-commit histories (die weliswaar als functioneel worden beschouwd, maar alsnog onder de AVG kunnen vallen). We gebruiken GDPR-regelgeving en de bijbehorende richtlijnen van de European Data Protection Board om te bepalen wat bewaard mag worden voor legitieme doeleinden, zoals belastinggegevens.

Het bouwen van een "offboarding-as-code" framework

In plaats van elke applicatie apart te integreren, hebben we een intern framework gebouwd - codenaam "Desist" - dat als een state machine (AWS Step Functions) werkt. Het ontvangt een JSON-payload van HR met daarin de werknemers-ID, datum ontslag en type (vrijwillig, gedwongen, pensionering). Vervolgens voert het stappen uit in een vastgestelde orden: (1) schors Okta-account, (2) revoke alle langelevende API-sleutels via Vault, (3) verwijder uit speciale groepen (PagerDuty, Slack owner), (4) parkeer e-mail als shared mailbox voor overdracht, (5) plan device-wipe via MDM (Jamf of Intune), en (6) stuur een geverifieerd rapport naar HR en IT Security.

Deze aanpak, geïnspireerd door het "Runbook Automation" concept van Transposit, maakt het ontslagproces reproduceerbaar, auditeerbaar en testbaar. We draaien maandelijks een "offboarding-drill" met een dummy-account om te bevestigen dat alle stappen correct werken en dat de totale duur onder de 3 minuten blijft. Juist bij gedwongen ontslag is die snelheid cruciaal: een ontevreden ex-medewerker kan in een zeer korte tijdsspanne schade berokkenen. Daarmee wordt ontslag een gedisciplineerde technische operatie, net als een failover-test.

Lessons learned uit incidenten rondom ontslag

Uit een eigen post-mortem van een bijna-incident (een vertrokken engineer wiens GitHub-token nog 4 dagen live stond) trokken we drie harde conclusies. Ten eerste: ontslag moet de scope "all tokens, not just the user account" omvatten. Daarom scannen we nu wekelijks alle Git-repositories op tokens van ontslagen medewerkers via een script dat de GitHub API combineert met de HR-statuslijst. Ten tweede: developers die op persoonlijke titel bijdragen aan open source-repositories onder bedrijfsaccount moeten hun bijdragen overdragen vóór ontslag, anders ontstaan er juridische complicaties.

Ten derde is communicatie een onderschat onderdeel. We hebben een optionele "warm handover" feature waarbij de manager van de vertrekkende medewerker een rapport krijgt met alle openstaande pull requests en een lijst van services waarvoor de persoon de enige kennisbezitter was. Dit voorkomt dat het team na een ontslag plotseling ontdekt dat een kritieke microservice zonder maintainer zit. Technisch wordt dit opgelost via correlatie van Git blame data met PagerDuty rotaties en code ownership regels in CODEOWNERS bestanden.

De toekomst van geautomatiseerd ontslag in een AI-gedreven en remote-first wereld

Met de opkomst van AI-augmented development en het gebruik van persoonlijke devices in remote werk, wordt het afsluiten van alle digitale sporen steeds complexer. Stel je voor: een medewerker met ontslag heeft lokaal een fine-tuned LLM model met bedrijfsgegevens op de laptop. Ons endpoint-beheer kan de laptop wissen, maar als het model naar