Azure Databricks: Personal Access Token Beperkingen Instellen

Databricks Personal Access Tokens zijn krachtige authenticatiemiddelen die volledige API-toegang tot een werkruimte bieden. Ze hebben dezelfde machtigingen als de gebruiker die ze heeft aangemaakt, maar zonder de bescherming van meervoudige authenticatie. Standaard hebben PATs geen vervaldatum, wat betekent dat ze onbeperkt geldig blijven. Deze eigenschappen maken PATs zeer gevoelig voor misbruik. De risico's van onbeperkte PATs zijn aanzienlijk: gestolen tokens geven aanvallers volledige werkruimte-toegang zonder aanvullende authenticatie, tokens die per ongeluk in GitHub-repositories of logbestanden worden opgeslagen worden publiek toegankelijk, tokens zonder vervaldatum creëren permanente achterdeuren zelfs nadat gebruikers uit dienst zijn getreden, en tokens zonder IP-restricties kunnen vanaf elke locatie wereldwijd worden gebruikt bij diefstal. Deze risico's worden versterkt doordat PATs regelmatig worden gelekt in coderepositories, configuratiebestanden, of CI/CD-logbestanden. Met PAT-restricties kunt u deze risico's aanzienlijk verminderen door een maximale levensduur af te dwingen (90 dagen wordt aanbevolen in lijn met aanbevolen praktijken), IP-toegangslijsten te configureren zodat tokens alleen vanaf geautoriseerde locaties kunnen worden gebruikt, token-gebruik te monitoren om verdachte patronen te detecteren, automatische intrekking bij detectie van afwijkend gebruik mogelijk te maken, en in Premium tier-omgevingen het aanmaken van PATs te beperken tot alleen beheerders. Deze maatregelen zijn essentieel voor naleving met ISO 27001 en NIS2, die strikte eisen stellen aan credential management en toegangscontrole.

Implementatie

Deze maatregel implementeert beperkingen voor Personal Access Tokens in Azure Databricks om het risico van token-misbruik te minimaliseren. De configuratie omvat het instellen van een maximale token-levensduur van 90 dagen, waarna tokens automatisch verlopen en moeten worden vernieuwd. Dit voorkomt dat oude, mogelijk gecompromitteerde tokens onbeperkt geldig blijven. IP-toegangslijsten worden geconfigureerd die specificeren vanaf welke IP-adressen of IP-bereiken tokens mogen worden gebruikt, bijvoorbeeld alleen vanaf het bedrijfs-VPN of specifieke automatiseringsservers. Token-gebruiksmonitoring wordt ingeschakeld via diagnostische logging, waarmee alle token-gebruik wordt geregistreerd en verdachte patronen kunnen worden gedetecteerd, zoals gebruik vanaf ongebruikelijke locaties of op ongebruikelijke tijden. Een formeel token-rotatiebeleid wordt geïmplementeerd dat gebruikers verplicht om tokens elke 90 dagen te vernieuwen. In Databricks Premium tier-omgevingen kan het aanmaken van PATs worden beperkt tot alleen beheerder-gebruikers, waardoor de proliferatie van tokens wordt beperkt. Bestaande tokens worden gecontroleerd en lang-levende of ongebruikte tokens worden ingetrokken. Belangrijk is ook om waar mogelijk Service Principal-authenticatie te verkiezen boven PATs voor automatiseringsscenario's, omdat Service Principals door Microsoft Entra ID worden beheerd, geen statische geheimen vereisen, en betere auditsporen bieden. Deze benadering elimineert de noodzaak voor PATs in automatiseringsworkflows en vermindert het risico van credential-lekken aanzienlijk.

Vereisten

Voor het implementeren van Personal Access Token beperkingen in Azure Databricks zijn diverse technische en organisatorische vereisten noodzakelijk. Deze vereisten vormen de basis voor een succesvolle implementatie en zorgen ervoor dat alle benodigde componenten op hun plaats zijn voordat met de configuratie wordt begonnen. De technische vereisten omvatten toegang tot de Databricks-werkruimte, de juiste licentie-niveaus voor geavanceerde beveiligingsfuncties, en geconfigureerde netwerkinfrastructuur voor IP-toegangslijsten. Organisatorische vereisten omvatten gedocumenteerde beleidsdocumenten, goedgekeurde processen, en beschikbare middelen voor implementatie en beheer.

Allereerst is toegang tot een Azure Databricks-werkruimte vereist, waarbij de organisatie moet beschikken over werkruimte-beheerdersrechten. Voor de meest geavanceerde beveiligingscontroles, met name de mogelijkheid om het aanmaken van Personal Access Tokens te beperken tot alleen beheerders, is een Databricks Premium tier-licentie vereist. Organisaties met een Standard tier kunnen nog steeds de meeste beperkingen implementeren, maar missen de mogelijkheid om token-aanmaak te centraliseren. De werkruimte-beheerder moet volledige toegang hebben tot de beheerconsole en alle instellingen voor toegangscontrole en beveiliging.

Voor het configureren van IP-toegangslijsten is het essentieel dat de organisatie beschikt over gedocumenteerde IP-adresbereiken voor alle legitieme toegangspunten. Dit omvat het bedrijfs-VPN met de publieke IP-adresbereiken, de publieke IP-adressen van kantoorlocaties, en de IP-adressen van alle CI/CD en automatiseringsservers die Databricks API's gebruiken. Deze informatie moet actueel en nauwkeurig zijn, omdat onjuiste configuraties kunnen leiden tot het blokkeren van legitieme gebruikers. Voor grote organisaties met gedistribueerde netwerken kan dit een complexe inventarisatie zijn die coördinatie vereist met netwerk- en IT-afdelingen.

Een goed gedocumenteerd token management beleid is cruciaal voor succesvolle implementatie. Dit beleid moet duidelijke richtlijnen bevatten over wanneer Personal Access Tokens mogen worden gebruikt, welke gebruikers tokens mogen aanmaken, wat de maximale levensduur is, en welke processen gelden voor token-aanvragen en goedkeuringen. Het beleid moet ook procedures bevatten voor token-rotatie, noodintrekking bij vermoedelijke compromittering, en regelmatige audits van actieve tokens. Deze documentatie dient als basis voor gebruikerscommunicatie en training, en zorgt voor consistentie in de aanpak binnen de organisatie.

Voor automatiseringsworkloads die momenteel Personal Access Tokens gebruiken, moeten organisaties een migratieplan ontwikkelen naar Service Principal-authenticatie. Dit vereist toegang tot Microsoft Entra ID (voorheen Azure Active Directory) voor het aanmaken en beheren van Service Principals, en coördinatie met ontwikkelaars en DevOps-teams die automatiseringsscripts en CI/CD-pipelines beheren. De migratie vereist technische kennis van OAuth-authenticatieflows en mogelijk code-wijzigingen in bestaande automatiseringen. Organisaties moeten ook beslissen over de opslag van Service Principal-geheimen, waarbij Azure Key Vault de aanbevolen optie is voor beveiligde opslag.

Implementatie

Gebruik PowerShell-script databricks-pat-restrictions.ps1 (functie Invoke-Remediation) – Automatiseert PAT-beperkingsconfiguratie en voert token-inventarisatiecontrole uit.

**FASE 1: Bestaande Token-inventaris en Risicobeoordeling (Duur: 1 uur)**

De eerste fase van de implementatie bestaat uit het uitvoeren van een grondige inventarisatie van alle bestaande Personal Access Tokens in de Databricks-werkruimte. Dit proces is essentieel om een volledig inzicht te krijgen in de huidige staat van token-gebruik en om hoog-risico tokens te identificeren die onmiddellijke aandacht vereisen. Begin met het openen van de Databricks Beheerconsole en navigeer naar Toegangscontrole, vervolgens naar Persoonlijke Toegangstokens, en selecteer de optie om alle tokens van alle gebruikers te bekijken. Dit geeft een compleet overzicht van alle actieve tokens in de werkruimte.

Tijdens de inventarisatie moeten beheerders systematisch alle tokens analyseren en identificeren welke tokens als hoog-risico kunnen worden beschouwd. Tokens zonder vervaldatum vormen een permanent achterdeurtje-risico omdat ze oneindig geldig blijven, zelfs nadat de eigenaar de organisatie heeft verlaten of de noodzaak voor het token is verdwenen. Tokens die ouder zijn dan 90 dagen en nog steeds actief zijn, hebben mogelijk hun nut overleefd of zijn vergeten door hun eigenaren. Tokens van voormalige medewerkers of vertrokken externe medewerkers vormen verweesde credentials die niet langer worden bewaakt maar nog steeds actief zijn. Tokens met werkruimte-beheerdersbereik hebben te ruime machtigingen en kunnen significante schade veroorzaken bij compromittering. Tokens die lang niet zijn gebruikt, waarbij de laatste gebruik meer dan 180 dagen geleden was, suggereren vergeten tokens die waarschijnlijk niet meer nodig zijn.

Voor elk geïdentificeerd hoog-risico token moet contact worden opgenomen met de token-eigenaar om zakelijke rechtvaardiging te verkrijgen. Belangrijke vragen die gesteld moeten worden zijn: Waarom is dit token nodig? Kan het worden vervangen door een Service Principal die beter wordt beheerd? Is een vervaldatum acceptabel? Deze gesprekken helpen bij het bepalen welke tokens legitieme zakelijke doeleinden dienen en welke mogelijk onnodig zijn. Voor tokens zonder geldige zakelijke onderbouwing moet een token-intrekkingsbijeenkomst worden gepland met alle belanghebbenden. Het is cruciaal om 30 dagen van tevoren te communiceren voordat de daadwerkelijke intrekking plaatsvindt om onverwachte bedrijfsverstoringen te voorkomen en eigenaren de gelegenheid te geven om alternatieve oplossingen te implementeren.

Alle goedgekeurde tokens moeten worden gedocumenteerd in een Token-inventaris spreadsheet voor governance-doeleinden. Deze inventaris moet voor elk token bevatten: het unieke token-ID, de naam van de eigenaar, het doel van het token, de vervaldatum indien van toepassing, en eventuele IP-beperkingen. Deze documentatie dient als auditspoor en maakt het mogelijk om regelmatig tokens te controleren en te roteren volgens het beleid. De spreadsheet moet regelmatig worden bijgewerkt wanneer nieuwe tokens worden aangemaakt of oude tokens worden ingetrokken. Het bijhouden van een complete token-inventaris is essentieel voor compliance-doeleinden en maakt het mogelijk om snel te reageren op beveiligingsincidenten waarbij tokens mogelijk zijn gecompromitteerd.

**FASE 2: Configuratie van Maximale Token Levensduur Beleid (Duur: 15 minuten)**

De tweede fase bestaat uit het configureren van de maximale token-levensduur in de Databricks-werkruimte. Navigeer naar de Databricks Beheerconsole, ga naar Instellingen, vervolgens naar Werkruimte-instellingen, en selecteer Personal Access Tokens. Hier bevindt zich de instelling voor de maximale token-levensduur die bepaalt hoe lang nieuwe tokens geldig kunnen blijven.

Configureer de instelling 'Maximum token lifetime' en stel deze in op 90 dagen, wat de aanbevolen balans is tussen beveiliging en operationele overhead. Deze periode is lang genoeg om gebruikers niet onnodig te belasten met frequente token-rotatie, maar kort genoeg om het risico van lang-levende, gecompromitteerde tokens aanzienlijk te verminderen. Organisaties met zeer hoge beveiligingsvereisten kunnen ervoor kiezen om een kortere periode van 30 tot 45 dagen in te stellen, maar dit creëert aanzienlijke gebruikerslast vanwege de frequente token-rotatie die vereist is. Een periode langer dan 90 dagen wordt niet aanbevolen omdat dit het beveiligingsrisico verhoogt zonder significante operationele voordelen.

Het is belangrijk om te begrijpen dat dit beleid alleen vooruitkijkend is, wat betekent dat bestaande tokens met langere levensduren niet automatisch worden ingetrokken. Het beleid geldt alleen voor nieuwe tokens die na de configuratie worden aangemaakt. Organisaties moeten bestaande lang-levende tokens handmatig intrekken zoals beschreven in Fase 1 van de implementatie. Dit is een kritisch punt omdat anders het beleid niet volledig effectief is.

Na configuratie van het beleid moet de functionaliteit worden getest om te verifiëren dat deze correct werkt. Probeer een nieuwe Personal Access Token aan te maken met een vervaldatum langer dan 90 dagen. Databricks moet dit blokkeren met een foutmelding die aangeeft dat de maximale levensduur is overschreden. Verifieer daarnaast dat tokens met een vervaldatum van maximaal 90 dagen wel succesvol kunnen worden aangemaakt. Deze tests bevestigen dat het beleid correct is geconfigureerd en werkt zoals verwacht.

Na succesvolle configuratie en testen moet het nieuwe beleid organisatiebreed worden gecommuniceerd. Informeer alle gebruikers dat alle nieuwe tokens maximaal 90 dagen geldig zijn en dat token-rotatie vereist is. Bied duidelijke documentatie aan over hoe tokens moeten worden geroteerd zonder serviceverstoring. Dit kan bijvoorbeeld betekenen dat gebruikers eerst een nieuw token moeten aanmaken, dit moeten gebruiken om bestaande applicaties en scripts bij te werken, en pas daarna het oude token moeten intrekken. Goede communicatie voorkomt verrassingen en zorgt voor een soepele implementatie.

**FASE 3: Configuratie van IP-toegangslijsten voor Token Gebruiksbeperking (Duur: 1-2 uur)**

De derde fase betreft het configureren van IP-toegangslijsten, een werkruimte-brede beveiligingsfunctie die bepaalt vanaf welke IP-adressen of IP-bereiken tokens mogen worden gebruikt. Navigeer naar de Databricks Beheerconsole, ga naar Instellingen, vervolgens naar Werkruimte-instellingen, en selecteer IP-toegangslijsten. Hier kan de functionaliteit worden ingeschakeld die token-gebruik beperkt tot geautoriseerde netwerken.

Voordat IP-toegangslijsten worden geconfigureerd, moeten organisaties eerst de toegestane IP-bereiken definiëren voor legitieme Databricks API-toegang. Dit omvat het bedrijfs-VPN met de publieke IP-adresbereiken die worden gebruikt door thuiswerkers, de publieke IP-adressen van kantoornetwerken, de IP-adressen van CI/CD automatiseringsservers zoals Jenkins of Azure DevOps agents, de IP-adressen van data pipeline orchestration-tools zoals Azure Data Factory of Airflow, en de IP-adressen van monitoring-tools die Databricks API's gebruiken. Deze inventarisatie vereist coördinatie met netwerk- en IT-afdelingen om nauwkeurige en actuele informatie te verkrijgen.

Voor elk geïdentificeerd legitiem bronnetwerk moeten IP-toegangslijst entries worden aangemaakt. Geef elk entry een duidelijke naam zoals 'Bedrijfs-VPN', specificeer het IP-bereik in CIDR-notatie zoals 203.0.113.0/24, schakel de entry in door 'Ingeschakeld' op 'Ja' te zetten, en voeg een beschrijving toe zoals 'Bedrijfs-VPN voor thuiswerkers'. Herhaal dit proces voor elke legitieme bron. Het is essentieel om voorzichtig te plannen omdat te restrictieve IP-lijsten legitieme gebruikers kunnen blokkeren en bedrijfsoperaties kunnen verstoren. Voer daarom grondige tests uit voordat de handhaving wordt ingeschakeld.

Als veiligheidsmaatregel moet een fallback worden geconfigureerd waarbij minimaal één beheerdersaccount is vrijgesteld van IP-restricties voor noodtoegang. Dit noodscenario is essentieel voor het geval een IP-lijst misconfiguratie alle toegang blokkeert, waardoor normale gebruikers niet meer kunnen inloggen. De beheerder kan dan de configuratie corrigeren zonder volledig buitengesloten te zijn. Deze vrijstelling moet zorgvuldig worden beheerd en alleen worden gebruikt in noodsituaties.

Na grondige planning, configuratie en testen kan de handhaving worden ingeschakeld door IP-toegangslijsten te schakelen van 'Uitgeschakeld' naar 'Ingeschakeld'. Deze wijziging heeft onmiddellijk effect: alle token-gebaseerde toegang vanaf niet-geautoriseerde IP-adressen wordt geblokkeerd met een HTTP 403 Forbidden foutmelding. Gebruikers die proberen toegang te krijgen vanaf niet-geautoriseerde locaties zullen niet kunnen verbinden met de Databricks-werkruimte, zelfs met een geldig token. Dit biedt een belangrijke extra beveiligingslaag tegen token-misbruik bij diefstal of lekken.

**FASE 4: Uitschakelen van PAT-aanmaak voor Niet-beheerders (Alleen Premium, Duur: 30 minuten)**

De vierde fase is alleen beschikbaar voor organisaties met een Databricks Premium tier licentie en betreft het beperken van het aanmaken van Personal Access Tokens tot alleen werkruimte-beheerders. Navigeer naar de Beheerconsole, ga naar Instellingen, vervolgens naar Werkruimte-instellingen, selecteer Personal Access Tokens, en schakel de optie 'Allow users to create tokens' uit door deze te schakelen naar 'Disabled'.

Met deze instelling kunnen alleen werkruimte-beheerders Personal Access Tokens aanmaken, terwijl reguliere gebruikers deze mogelijkheid niet meer hebben. Dit centraliseert token management volledig en voorkomt shadow IT waarbij gebruikers ongemerkt ongeautoriseerde tokens aanmaken buiten het zicht van beveiligings- en IT-afdelingen. Deze centralisatie maakt het eenvoudiger om token-gebruik te monitoren, te auditen en te controleren, en zorgt ervoor dat alle tokens voldoen aan organisatiebeleid voordat ze worden aangemaakt.

Voor dit proces moet een uitzonderingsworkflow worden geïmplementeerd waarbij gebruikers kunnen aanvragen dat een beheerder een token voor hen aanmaakt. Deze workflow kan worden geïmplementeerd via bestaande servicemanagementtools zoals ServiceNow of Jira, of via een gestructureerd e-mailproces. Wanneer een gebruiker een token-aanvraag indient, moet de beheerder eerst de zakelijke noodzaak verifiëren voordat het token wordt aangemaakt. Dit proces zorgt ervoor dat tokens alleen worden aangemaakt wanneer er een legitieme zakelijke behoefte is, en niet voor persoonlijk gemak of experimentele doeleinden.

Een alternatieve aanbeveling is om in plaats van het volledig uitschakelen van PAT-aanmaak voor gebruikers, een goedkeuringsworkflow te implementeren waarbij gebruikers wel tokens kunnen aanmaken, maar waarbij beheerder-goedkeuring vereist is voordat het token actief wordt. Deze benadering biedt een balans tussen gebruikersgemak en beveiligingscontrole, maar vereist een aangepaste implementatie via Databricks APIs omdat deze functionaliteit niet standaard beschikbaar is. Organisaties moeten beslissen welke aanpak het beste past bij hun beveiligingsvereisten en organisatiecultuur.

Ongeacht welke aanpak wordt gekozen, deze wijziging moet organisatiebreed worden gecommuniceerd met een adequate kennisgevingsperiode van minimaal 30 dagen voordat de wijziging wordt doorgevoerd. Dit geeft gebruikers de tijd om zich voor te bereiden en eventuele bestaande workflows aan te passen. Bied daarnaast training aan over hoe token-aanvragen moeten worden ingediend, wat de verwachte verwerkingstijd is, en wat de criteria zijn voor goedkeuring. Goede communicatie en training verminderen gebruikersfrustratie en zorgen voor een soepele overgang.

**FASE 5: Service Principal Migratie voor Automatiseringsworkloads (Duur: 2-4 uur per automatisering)**

De vijfde fase betreft het migreren van automatiseringsworkloads die momenteel Personal Access Tokens gebruiken naar Azure AD Service Principal authenticatie. Service Principals zijn centraal beheerde identiteiten die beter geschikt zijn voor automatiseringsscenario's omdat ze door Microsoft Entra ID worden beheerd, geen statische geheimen vereisen wanneer certificaat-authenticatie wordt gebruikt, en betere audit trails bieden. Begin met het identificeren van alle automatiseringsworkloads die momenteel PATs gebruiken, zoals CI/CD pipelines in Azure DevOps of Jenkins, data orchestration-tools zoals Azure Data Factory of Airflow, monitoring-scripts, en geplande notebooks.

Voor elke geïdentificeerde automatisering moet een Azure AD Service Principal worden aangemaakt. Open Microsoft Entra ID (voorheen Azure Active Directory), ga naar App-registraties, selecteer Nieuwe registratie, en geef de Service Principal een duidelijke naam zoals 'svc-databricks-cicd' die het doel weergeeft. Registreer de toepassing en noteer de Application ID die wordt gegenereerd, want deze is nodig voor de configuratie in Databricks.

De volgende stap is het verlenen van toegang aan de Service Principal in Databricks. Open de Databricks Beheerconsole, ga naar Instellingen, selecteer Service Principals, en klik op Toevoegen. Plak de Application ID van de Service Principal en wijs de juiste rechten toe op basis van wat de automatisering nodig heeft. Mogelijke rechten zijn: het kunnen uitvoeren van jobs, het kunnen beheren van clusters, werkruimte-beheerdersrechten voor volledige toegang, of specifieke rechten voor alleen-lezen toegang. Het principe van minimale privileges moet worden toegepast: verleen alleen de rechten die absoluut noodzakelijk zijn voor de automatisering om te functioneren.

Voor de authenticatie van de Service Principal moet een clientgeheim worden gegenereerd in Azure AD, hoewel certificaat-authenticatie wordt aanbevolen voor hogere beveiliging. Ga naar Azure AD App-registraties, selecteer de Service Principal, ga naar Certificaten en geheimen, en klik op Nieuw clientgeheim. Genereer het geheim en sla het onmiddellijk op in Azure Key Vault voor beveiligde opslag. Het is kritisch dat dit geheim NOOIT wordt opgeslagen in code of configuratiebestanden, omdat dit een ernstig beveiligingsrisico vormt. Gebruik Azure Key Vault om het geheim veilig op te slaan en op te halen tijdens runtime.

De automatiseringscode moet worden bijgewerkt om Service Principal authenticatie te gebruiken in plaats van Personal Access Tokens. Dit vereist het implementeren van de OAuth client credentials flow waarbij de automatisering de Service Principal ID en het geheim uitwisselt voor een OAuth access token. Dit access token wordt vervolgens gebruikt voor alle Databricks API-calls. De implementatie vereist wijzigingen in de authenticatie-logica van de automatisering, wat mogelijk betekent dat bestaande code moet worden aangepast of dat nieuwe authenticatiebibliotheken moeten worden geïmplementeerd.

Voordat het oude Personal Access Token wordt ingetrokken, moet de automatisering grondig worden getest met de nieuwe Service Principal authenticatie. Verifieer dat jobs succesvol draaien, dat API-calls slagen, en dat de verleende rechten adequaat zijn voor de vereiste functionaliteit. Test alle gebruiksscenario's van de automatisering om er zeker van te zijn dat er geen regressie is opgetreden. Alleen na succesvolle tests en verificatie moet het oude PAT worden ingetrokken. Documenteer de migratie in een runbook voor toekomstige automatiseringen, inclusief de stappen die zijn genomen, eventuele problemen die zijn opgelost, en best practices die zijn geïdentificeerd.

**FASE 6: Token Rotatie Automatisering en Gebruikerscommunicatie (Duur: 2 uur)**

De zesde en laatste fase betreft het automatiseren van token-rotatie processen en het communiceren met gebruikers over token management. Dit omvat het implementeren van geautomatiseerde herinneringen voor token-vervalling, het verstrekken van gebruikersdocumentatie, het creëren van beheerdersrunbooks, en het plannen van regelmatige token-hygiëne reviews.

Implementeer geautomatiseerde herinneringen voor token-vervalling door een script te creëren dat regelmatig de Databricks API bevraagt voor tokens die binnen 14 dagen verlopen. Het script identificeert deze tokens, haalt de contactgegevens van de token-eigenaren op, en stuurt e-mailherinneringen met instructies om de vervanging te starten voordat de vervaldatum is bereikt. Deze proactieve benadering voorkomt dat tokens onverwacht verlopen en services verstoren. Het script moet dagelijks draaien en herinneringen moeten worden verstuurd op 14, 7, 3 en 1 dag voor vervaldatum om voldoende waarschuwing te geven.

Bied gebruikers duidelijke documentatie met stapsgewijze instructies over tokenbeheer. De documentatie moet uitleggen hoe gebruikers de vervaldatum van hun tokens kunnen controleren via de Databricks-beheerconsole, hoe ze oude tokens kunnen intrekken wanneer ze niet meer nodig zijn, hoe ze nieuwe tokens kunnen aanmaken met de juiste instellingen en rechten, en hoe ze tokens in applicaties en scripts kunnen bijwerken zonder downtime. Het proces voor zero-downtime token-rotatie is: maak eerst een nieuw token aan, update alle applicaties en scripts om het nieuwe token te gebruiken, test dat alles correct werkt, en trek pas daarna het oude token in. Deze documentatie moet beschikbaar zijn in een centrale locatie zoals een intranet of kennisbank.

Creëer een uitgebreid Token Management proceduredocument voor beheerders dat procedures bevat voor verschillende scenario's. Dit omvat procedures voor noodtoken-intrekking bij vermoedelijke compromittering, waarbij beheerders snel alle tokens van een gebruiker moeten kunnen intrekken bij een beveiligingsincident. Het proceduredocument moet ook bulk token analyse scripts bevatten voor beveiligingsaudits, waarmee beheerders snel kunnen identificeren welke tokens risico vormen. Daarnaast moeten noodprocedures worden gedocumenteerd voor situaties waarin IP-toegangslijsten legitieme gebruikers buitensluiten, inclusief het tijdelijk uitschakelen van IP-restricties of het toevoegen van nood-IP-adressen. Dit document moet regelmatig worden bijgewerkt op basis van geleerde lessen uit eerdere incidenten en moet beschikbaar zijn voor alle beheerders die verantwoordelijk zijn voor token management.

Plan kwartaalgewijze Token Hygiëne reviews waarbij beheerders een script uitvoeren dat ongebruikte tokens identificeert. Tokens waarvan de laatste gebruik meer dan 90 dagen geleden was, moeten als ongebruikt worden beschouwd. Voor deze tokens moeten intrekkingsnotificaties worden verstuurd naar de eigenaren met de vraag of het token nog nodig is. Als er na 30 dagen geen reactie komt, moeten deze tokens worden geforceerd ingetrokken. Deze regelmatige reviews houden de token-inventaris schoon en verminderen het risico van vergeten, ongebruikte tokens die als backdoors kunnen functioneren.

Monitor token-gebruikspatronen via Databricks audit logs om verdachte activiteiten te detecteren. Ongebruikelijke API-call volumes van specifieke tokens kunnen wijzen op compromittering waarbij een gelekt token wordt misbruikt. Token-gebruik vanaf onverwachte IP-adressen, zelfs ondanks IP Access Lists, kan wijzen op VPN- of proxy-misbruik of op een gecompromitteerd netwerk. Mislukte authenticatiepogingen met tokens kunnen wijzen op brute force-aanvallen of op pogingen om gelekt token te testen. Deze monitoring moet worden geautomatiseerd met waarschuwingen die worden gegenereerd wanneer verdachte patronen worden gedetecteerd, zodat beheerders snel kunnen reageren op potentiële beveiligingsincidenten.

**Totale Implementatietijd**: 2-3 uur voor basis PAT-beperkingen (token-inventaris, levensduurbeleid, basis IP-access lists). Aanvullende 3-5 uur voor uitgebreide implementatie (Service Principal migratie voor automation, geavanceerde IP-whitelisting, token-rotatie automatisering, gebruikersopleiding). Totaal: 5-8 uur voor complete PAT governance.

**Kosten**: PAT-beperkingen zelf zijn gratis (geen Databricks kosten). Doorlopende inspanning voor token management: 1-2 uur per kwartaal voor token audits en opruiming. Optioneel: Azure Key Vault voor het opslaan van Service Principal secrets (€0,03 per secret per maand - verwaarloosbaar).

Monitoring

Gebruik PowerShell-script databricks-pat-restrictions.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring van Personal Access Token activiteit is essentieel voor het detecteren van verdachte activiteiten en het handhaven van beveiligingshygiëne. Een uitgebreide monitoringstrategie omvat het bijhouden van token-aanmaakevents, het waarschuwen voor ongebruikelijk token-gebruik, het volgen van token-ouderdom en het uitvoeren van regelmatige audits. Deze monitoring moet worden geautomatiseerd waar mogelijk om tijdige detectie en reactie te garanderen.

Alle Personal Access Token aanmaakevents moeten worden gemonitord via diagnostische logs in Azure Databricks. Deze logs registreren wanneer nieuwe tokens worden aangemaakt, door welke gebruiker, met welke instellingen zoals vervaldatum en rechten. Monitoring van deze events helpt bij het detecteren van ongemerkte token-aanmaak, het identificeren van gebruikers die mogelijk niet op de hoogte zijn van het beleid, en het bijhouden van token-proliferatie. Configureer waarschuwingen voor token-aanmaak buiten normale werktijden of door gebruikers die normaal gesproken geen tokens aanmaken, wat kan wijzen op compromittering of policy-overtreding.

Waarschuwingen moeten worden geconfigureerd voor token-gebruik vanaf ongebruikelijke IP-adressen. Zelfs met IP Access Lists geconfigureerd, kunnen tokens worden gebruikt vanaf onverwachte locaties via gecompromitteerde netwerken, VPN-abuse, of omdat IP-lijsten niet volledig zijn geconfigureerd. Monitor alle token-gebaseerde API-calls en genereer waarschuwingen wanneer tokens worden gebruikt vanaf IP-adressen die niet in de geconfigureerde toegestane lijsten staan, of vanaf locaties die significant afwijken van het normale gebruikspatroon van de token-eigenaar. Deze waarschuwingen moeten prioriteit krijgen en onmiddellijk worden onderzocht omdat ze kunnen wijzen op token-compromittering of diefstal.

Het volgen van token-ouderdom is cruciaal voor het handhaven van het token-rotatiebeleid. Implementeer een systeem dat automatisch de leeftijd van alle actieve tokens bijhoudt en waarschuwingen genereert voordat tokens verlopen. Waarschuwingen moeten worden verstuurd op 14, 7, 3 en 1 dag voor vervaldatum om token-eigenaren voldoende tijd te geven om tokens te roteren. Voor tokens die de maximale leeftijd naderen zonder dat er een nieuwe token is aangemaakt, moeten extra waarschuwingen worden gegenereerd omdat deze tokens mogelijk worden gebruikt in kritieke automation-workloads die verstoring kunnen veroorzaken bij verlopen.

Kwartaalgewijze audits van actieve tokens moeten worden uitgevoerd om de token-inventaris te onderhouden en risico's te identificeren. Deze audits moeten ongebruikte tokens identificeren waarvan de laatste gebruik meer dan 90 dagen geleden was, lang-levende tokens die mogelijk zijn vergeten, tokens van voormalige medewerkers die nog steeds actief zijn, en tokens met ongebruikelijke rechten die mogelijk niet meer nodig zijn. Voor elk geïdentificeerd risico-token moeten eigenaren worden gecontacteerd voor verificatie en, indien nodig, moeten tokens worden ingetrokken. Documenteer alle audit-activiteiten voor compliance-doeleinden.

Automatische token-intrekking bij het uitschrijven van gebruikers is essentieel voor het voorkomen van verweesde credentials. Wanneer een medewerker de organisatie verlaat, moeten alle Personal Access Tokens die door die gebruiker zijn aangemaakt onmiddellijk worden ingetrokken, ongeacht de vervaldatum. Dit proces moet worden geautomatiseerd door het integreren van Databricks token management met de identity management-systemen van de organisatie, zodat wanneer een gebruiker wordt gedeactiveerd in het HR-systeem of Microsoft Entra ID, alle bijbehorende tokens automatisch worden ingetrokken. Dit elimineert het risico van vergeten tokens die blijven functioneren nadat gebruikers de organisatie hebben verlaten.

Compliance en auditing

Personal Access Token beperkingen voor Azure Databricks zijn essentieel voor compliance met diverse internationale en Nederlandse beveiligingsstandaarden en richtlijnen. Deze maatregel helpt organisaties te voldoen aan eisen voor credential management, toegangscontrole en authenticatie zoals vastgelegd in verschillende compliance-frameworks. Een goed geïmplementeerd token management systeem biedt het audit-evidence dat nodig is voor compliance-audits en certificeringen.

De ISO 27001 standaard stelt in controle A.9.4.3 eisen aan wachtwoordbeheersystemen, wat ook van toepassing is op authenticatie tokens zoals Personal Access Tokens. Deze controle vereist dat organisaties passende technische en organisatorische maatregelen nemen om credentials te beheren, inclusief het instellen van vervaldatums, het implementeren van rotatieprocedures, en het intrekken van credentials wanneer ze niet meer nodig zijn of wanneer compromittering wordt vermoed. De implementatie van PAT-beperkingen met maximale levensduren, IP-restricties, en regelmatige audits voldoen aan deze vereisten door ervoor te zorgen dat tokens worden beheerd volgens best practices voor credential management.

De NIS2-richtlijn (Network and Information Systems Directive 2) stelt in Artikel 21 specifieke eisen aan toegangscontrole en authenticatie voor essentiële en belangrijke entiteiten. Deze eis vereist dat organisaties passende maatregelen nemen om toegang tot informatie systemen te beheren en te controleren, inclusief het gebruik van sterke authenticatiemethoden en het beperken van toegang op basis van het principe van minimale privileges. Personal Access Token beperkingen dragen bij aan compliance met deze eis door token-gebruik te beperken tot geautoriseerde locaties via IP-restricties, door automatische vervaldatums af te dwingen, en door token-aanmaak te centraliseren en te controleren in Premium tier omgevingen. Deze maatregelen zorgen ervoor dat alleen geautoriseerde gebruikers vanuit geautoriseerde locaties toegang hebben tot Databricks-werkruimten.

Het BIO-beveiligingskader (Baseline Informatiebeveiliging Overheid) beschrijft in Thema 11.05 de eisen voor authenticatiebeheer voor Nederlandse overheidsorganisaties. Dit thema vereist dat organisaties authenticatiemiddelen op een veilige manier beheren, inclusief het instellen van vervaldatums, het implementeren van rotatieprocedures, en het monitoren van authenticatie-events. Voor Personal Access Tokens betekent dit dat organisaties moeten zorgen voor token-levensduurbeperkingen, regelmatige token-rotatie, en monitoring van token-gebruik via audit logs. De implementatie van PAT-beperkingen met 90-dagen maximale levensduur, IP-access lists, en kwartaalgewijze audits voldoen aan deze BIO-vereisten en helpen Nederlandse overheidsorganisaties te voldoen aan hun beveiligingsverplichtingen.

De OWASP Top 10 voor 2021 identificeert in categorie A07:2021 Identification and Authentication Failures als een van de meest kritieke beveiligingsrisico's voor webapplicaties. Dit risico omvat problemen met credential management zoals het gebruik van zwakke authenticatiemethoden, het ontbreken van rotatieprocedures, en het falen om gecompromitteerde credentials tijdig in te trekken. Personal Access Token beperkingen helpen organisaties te voldoen aan OWASP best practices door sterke token-management te implementeren met automatische vervaldatums, IP-restricties, en proactieve monitoring en revocatie van verdachte of gecompromitteerde tokens. Deze maatregelen verminderen het risico van Identification and Authentication Failures aanzienlijk en helpen organisaties hun beveiligingspostuur te verbeteren.

Voor compliance-audits moeten organisaties audit-evidence kunnen leveren van de geïmplementeerde token-beperkingen. Dit omvat documentatie van de PAT lifetime-configuratie, IP access list configuratie, actieve token-inventarissen, en token-rotatiebeleid documentatie. Deze documentatie moet minimaal 7 jaar worden bewaard in overeenstemming met veel compliance-vereisten. Regelmatige audits en documentatie-updates zorgen ervoor dat organisaties altijd up-to-date audit-evidence hebben wanneer dit wordt gevraagd door auditors of certificeringsinstanties.

Remediatie

Gebruik PowerShell-script databricks-pat-restrictions.ps1 (functie Invoke-Remediation) – Automatiseert de implementatie van PAT-beperkingen en voert herstelacties uit.

Remediatie van Personal Access Token beperkingen in Azure Databricks is een kritiek proces dat systematisch moet worden uitgevoerd om beveiligingsrisico's te elimineren zonder bedrijfsoperaties te verstoren. Het remediatieproces omvat het identificeren van niet-conforme token-configuraties, het implementeren van de vereiste beperkingen, en het verifiëren dat alle wijzigingen correct zijn toegepast. Een goed uitgevoerde remediatie zorgt ervoor dat de Databricks-werkruimte voldoet aan beveiligingsstandaarden en compliance-vereisten, terwijl de impact op gebruikers en automatiseringen wordt geminimaliseerd.

Het remediatieproces begint met een grondige assessment van de huidige staat van Personal Access Token configuraties in de Databricks-werkruimte. Beheerders moeten eerst controleren of er een maximale token-levensduur is geconfigureerd, en zo ja, wat de huidige waarde is. Tokens zonder vervaldatum of met een vervaldatum langer dan 90 dagen vormen een beveiligingsrisico en moeten worden aangepakt. De assessment moet ook controleren of IP-toegangslijsten zijn geconfigureerd en of deze correct zijn ingesteld voor alle legitieme toegangspunten. Daarnaast moet worden gecontroleerd of het aanmaken van tokens is beperkt tot beheerders in Premium tier omgevingen, en of er een actief token-rotatiebeleid bestaat.

Wanneer niet-conforme configuraties worden geïdentificeerd, moeten beheerders een prioriteringsstrategie ontwikkelen op basis van risiconiveau. Hoog-risico situaties zoals tokens zonder vervaldatum van voormalige medewerkers, tokens die ouder zijn dan 180 dagen, of tokens met beheerdersrechten die niet worden gebruikt, vereisen onmiddellijke aandacht en moeten binnen 24 uur worden aangepakt. Medium-risico situaties zoals tokens zonder vervaldatum van actieve medewerkers of tokens die ouder zijn dan 90 dagen maar nog regelmatig worden gebruikt, kunnen binnen een week worden aangepakt met adequate communicatie naar de eigenaren. Laag-risico situaties zoals tokens met een vervaldatum tussen 60 en 90 dagen kunnen worden aangepakt tijdens de volgende geplande token-rotatiecyclus.

Voor het implementeren van maximale token-levensduur beperkingen moeten beheerders eerst alle bestaande tokens inventariseren en categoriseren op basis van hun huidige vervaldatum en gebruikspatroon. Tokens zonder vervaldatum moeten worden geïdentificeerd en hun eigenaren moeten worden gecontacteerd om een nieuwe vervaldatum vast te stellen die binnen 90 dagen ligt. Voor tokens die nog regelmatig worden gebruikt, moet een nieuwe vervaldatum worden ingesteld die voldoende tijd geeft voor een soepele overgang, maar niet langer dan 90 dagen vanaf de remediatiedatum. Tokens die niet meer worden gebruikt of waarvan de eigenaar de organisatie heeft verlaten, moeten onmiddellijk worden ingetrokken zonder wachttijd.

Het configureren van IP-toegangslijsten vereist zorgvuldige planning om te voorkomen dat legitieme gebruikers worden geblokkeerd. Beheerders moeten eerst een complete inventaris maken van alle IP-adressen en IP-bereiken die legitieme toegang tot Databricks vereisen. Dit omvat het bedrijfs-VPN met alle bijbehorende publieke IP-adresbereiken, de publieke IP-adressen van alle kantoorlocaties, en de IP-adressen van alle CI/CD servers, automatiseringsservers, en monitoring-tools. Deze inventarisatie moet worden geverifieerd met netwerk- en IT-afdelingen om te zorgen voor volledigheid en nauwkeurigheid. Zodra de inventarisatie compleet is, kunnen IP-toegangslijst entries worden aangemaakt voor elk geïdentificeerd netwerk, waarbij elk entry een duidelijke naam en beschrijving krijgt voor toekomstig onderhoud.

Voordat IP-toegangslijsten worden geactiveerd, moeten uitgebreide tests worden uitgevoerd om te verifiëren dat alle legitieme toegangspunten correct zijn geconfigureerd. Beheerders moeten testen of tokens kunnen worden gebruikt vanaf elk geïdentificeerd netwerk, en moeten waarschuwingen configureren voor pogingen tot toegang vanaf niet-geautoriseerde IP-adressen. Het is essentieel om een fallback-mechanisme te hebben waarbij minimaal één beheerdersaccount is vrijgesteld van IP-restricties voor noodtoegang, zodat beheerders de configuratie kunnen corrigeren als er onverwachte problemen optreden. Alleen na succesvolle tests en verificatie moeten IP-toegangslijsten worden geactiveerd voor handhaving.

Voor organisaties met Databricks Premium tier die het aanmaken van tokens willen beperken tot alleen beheerders, moet een uitzonderingsworkflow worden geïmplementeerd voordat deze beperking wordt geactiveerd. Deze workflow moet gebruikers in staat stellen om token-aanvragen in te dienen via een gestructureerd proces, waarbij beheerders de zakelijke noodzaak kunnen verifiëren voordat tokens worden aangemaakt. De workflow moet duidelijke criteria bevatten voor wanneer token-aanvragen worden goedgekeurd, wat de verwachte verwerkingstijd is, en hoe gebruikers kunnen controleren op de status van hun aanvraag. Goede communicatie en training zijn essentieel om gebruikersfrustratie te voorkomen en te zorgen voor een soepele overgang naar het nieuwe proces.

Na implementatie van alle remediatiemaatregelen moeten beheerders verificatie uitvoeren om te bevestigen dat alle wijzigingen correct zijn toegepast en dat de beveiligingspostuur is verbeterd. Dit omvat het controleren dat het maximale token-levensduur beleid correct is geconfigureerd en dat nieuwe tokens niet langer kunnen worden aangemaakt met een levensduur langer dan 90 dagen. Beheerders moeten ook verifiëren dat IP-toegangslijsten correct zijn geactiveerd en dat tokens niet kunnen worden gebruikt vanaf niet-geautoriseerde locaties. Daarnaast moeten beheerders controleren dat alle hoog-risico tokens zijn aangepakt, ofwel door het instellen van een vervaldatum, ofwel door intrekking wanneer ze niet meer nodig zijn. Deze verificatie moet worden gedocumenteerd voor audit-doeleinden en compliance-rapportage.

Het remediatieproces moet worden afgerond met de implementatie van continue monitoring en automatisering om te voorkomen dat nieuwe niet-conforme configuraties ontstaan. Beheerders moeten geautomatiseerde scripts implementeren die regelmatig controleren op nieuwe tokens zonder vervaldatum, tokens die de maximale leeftijd naderen, en tokens die worden gebruikt vanaf niet-geautoriseerde IP-adressen. Deze scripts moeten waarschuwingen genereren wanneer niet-conforme situaties worden gedetecteerd, zodat beheerders snel kunnen reageren voordat beveiligingsrisico's ontstaan. Daarnaast moeten regelmatige token-hygiëne reviews worden gepland, bijvoorbeeld kwartaalgewijs, om de token-inventaris schoon te houden en te zorgen voor continue compliance met beveiligingsbeleid.

Compliance & Frameworks

• BIO: 11.05.02 - Authenticatiebeheer - token management
• ISO 27001:2022: A.9.4.3 - wachtwoordbeheer system (tokens)
• NIS2: Artikel - Toegangscontrole en authenticatie - token restrictions

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Configureer Personal Access Token beperkingen voor Azure Databricks door een maximale token-levensduur van 90 dagen af te dwingen (balans tussen beveiliging en operationele overhead), IP-toegangslijsten in te stellen die token-gebruik beperken tot vertrouwde netwerken zoals bedrijfs-VPN en automatiseringsservers, en gebruiksmonitoring te implementeren via auditlogs. Migreer bij voorkeur automatiseringsworkloads van PATs naar Azure AD Service Principals die centraal beheerde identiteiten gebruiken in plaats van lang-levende tokens. Voer regelmatige audits uit om ongebruikte tokens te identificeren en in te trekken. Deze maatregel is verplicht voor productie-werkruimten, vereist voor compliance met token management-vereisten, en vermindert de impact van gelekte tokens aanzienlijk. Implementatie: 2-3 uur voor basis-beperkingen, geen extra kosten, vermindert token-lekkage-impact met 80%+, essentiële beveiligingshygiëne voor Databricks API-toegang.

• Implementatietijd: 3 uur
• FTE required: 0.03 FTE