Azure Databricks: Diagnostische Logging Inschakelen

Zonder diagnostische logging ontbreekt cruciale zichtbaarheid in uw Databricks-omgeving. U kunt niet zien wie toegang heeft gehad tot welke workspaces, clustermodificaties blijven ongeregistreerd, mislukte taken worden niet gedocumenteerd, beveiligingsincidenten blijven onopgemerkt, en compliance-audits mislukken door het ontbreken van een audittrail. Daarnaast wordt probleemoplossing vrijwel onmogelijk zonder historische gegevens. Diagnostische logs bieden daarentegen uitgebreide inzichten in uw Databricks-omgeving: u kunt precies zien wie wanneer toegang heeft gehad tot welke notebooks, alle clustercreaties en -verwijderingen worden geregistreerd, de volledige taakuitvoeringsgeschiedenis is beschikbaar, authenticatiegebeurtenissen worden vastgelegd, wijzigingen in machtigingen zijn traceerbaar, en alle API-aanroepen worden gelogd. Deze logging is essentieel voor effectieve beveiligingsmonitoring en vormt de basis voor compliance met frameworks zoals ISO 27001, NIS2 en de AVG. Zonder deze logging is het onmogelijk om beveiligingsincidenten achteraf te onderzoeken of aan te tonen dat uw organisatie voldoet aan wettelijke bewaarplichten voor audittrails.

Implementatie

Deze maatregel configureert diagnostische logging voor Azure Databricks waarbij alle relevante logs naar een Log Analytics-workspace worden verzonden. De implementatie omvat het inschakelen van verschillende logcategorieën die elk specifieke informatie vastleggen. Workspace-logs registreren toegang tot notebooks en workspace-resources, clusterlogs volgen de volledige levenscyclus van clusters inclusief aanmaak, configuratiewijzigingen en verwijdering, taaklogs documenteren alle taakuitvoeringen inclusief succesvolle en mislukte statussen, DBFS-logs registreren toegang tot het Databricks-bestandssysteem, accountlogs leggen authenticatiegebeurtenissen en inlogpogingen vast, en SSH-logs volgen directe clustertoegang via SSH. De logretentie moet worden ingesteld op minimaal 90 dagen voor operationele doeleinden, maar voor compliance-vereisten zoals ISO 27001 en de AVG is vaak een bewaarperiode van 7 jaar verplicht. Daarnaast kunnen waarschuwingen worden geconfigureerd op kritieke beveiligingsgebeurtenissen zoals mislukte inlogpogingen, ongeautoriseerde toegang of clusterverwijderingen. Voor geavanceerde beveiligingsmonitoring kan integratie met Microsoft Sentinel worden geconfigureerd voor centraal beveiligingsinformatie- en gebeurtenisbeheer, ook wel bekend als SIEM. De kosten bedragen circa €2 tot €5 per GB opgenomen data, afhankelijk van het gebruik van de Databricks-omgeving.

Vereisten

Voor het implementeren van diagnostische logging voor Azure Databricks zijn verschillende technische en organisatorische vereisten nodig. De primaire technische vereiste betreft de beschikbaarheid van een Log Analytics workspace binnen uw Azure-abonnement. Deze workspace fungeert als centrale verzamelplaats voor alle Databricks-logbestanden en moet zich bij voorkeur in dezelfde Azure-regio bevinden als uw Databricks-workspace om latentie te minimaliseren en data-transportkosten te beperken. De Log Analytics workspace kan worden aangemaakt tijdens de implementatiefase indien deze nog niet bestaat, of u kunt gebruikmaken van een bestaande centrale workspace voor beveiligingslogging. Het is belangrijk om te realiseren dat de workspace moet worden geconfigureerd met passende retentie-instellingen op basis van uw operationele en compliance-vereisten.

Wat betreft toegangsrechten is Contributor-toegang op de Databricks workspace essentieel voor het configureren van diagnostische instellingen. Deze rol stelt u in staat om diagnostische instellingen aan te maken, te wijzigen en te verwijderen. Daarnaast is de rol 'Monitoring Contributor' vereist op het niveau van de Databricks workspace-resource voor het configureren van diagnostische instellingen. Deze rol wordt gebruikt door Azure Monitor voor het verzamelen van diagnostische gegevens en moet expliciet worden toegewezen aan de service principal of gebruiker die de configuratie uitvoert. Het is belangrijk om te realiseren dat deze rollen minimaal nodig zijn volgens het principe van least privilege, en dat organisaties moeten overwegen om tijdelijke toegang te verlenen voor implementatiedoeleinden.

Voor organisaties die moeten voldoen aan langetermijnbewaarvereisten voor compliance-doeleinden, zoals de 7-jaar bewaarplicht voor auditlogs onder ISO 27001 of BIO, is een optioneel opslagaccount vereist voor archivering. Dit Storage Account moet worden geconfigureerd met immutable blob storage policies om te waarborgen dat logbestanden niet kunnen worden gewijzigd of verwijderd na archivering. Deze immutable policies zijn essentieel voor audittrails en compliance-doeleinden, omdat ze garanderen dat logbestanden authentiek blijven en niet kunnen worden gemanipuleerd. Het Storage Account kan worden gebruikt voor het archiveren van logs na een bepaalde periode, bijvoorbeeld na 90 dagen wanneer de kosten voor bewaring in Log Analytics te hoog worden.

Organisaties moeten ook rekening houden met de financiële vereisten voor logverwerking. De kosten voor logopname in Log Analytics bedragen circa €2 tot €5 per GB opgenomen data, afhankelijk van het datavolume en de gekozen pricing tier. Een typische Databricks-workspace genereert tussen de 5 en 20 GB aan logs per maand, afhankelijk van het activiteitsniveau, wat neerkomt op maandelijkse kosten van ongeveer €12 tot €45 voor logopname. Daarnaast zijn er kosten voor databewaring na de eerste 90 dagen, waarbij organisaties ongeveer €0,12 per GB per maand betalen voor retentie. Voor langetermijnarchivering in Storage Account zijn de kosten aanzienlijk lager, ongeveer €0,02 per GB per maand, wat het een kosteneffectieve oplossing maakt voor compliance-bewaring over periodes van 7 jaar of langer.

Implementatie

Gebruik PowerShell-script databricks-diagnostic-logs.ps1 (functie Invoke-Remediation) – Automatiseert de configuratie van diagnostische logging voor Databricks-workspaces en verifieert de integratie met Log Analytics.

**FASE 1: Log Analytics-workspace voorbereiding (Duur: 1 uur indien nieuw, 15 minuten indien bestaand)**

De eerste fase van de implementatie betreft de voorbereiding van de Log Analytics-workspace die zal dienen als centrale verzamelplaats voor alle Databricks-logbestanden. Deze fase is fundamenteel voor het succes van de gehele logging-implementatie omdat de workspace fungeert als de infrastructuur waarop alle verdere configuratie is gebaseerd. De implementatieduur bedraagt ongeveer 1 uur wanneer een nieuwe workspace moet worden aangemaakt, of 15 minuten wanneer een bestaande centrale beveiligingslogging-workspace kan worden gebruikt. Het is belangrijk om deze fase zorgvuldig uit te voeren omdat fouten in de workspace-configuratie kunnen leiden tot problemen in latere fasen, zoals onjuiste logopslag, ontoegankelijke loggegevens of onnodig hoge kosten. Een goed geconfigureerde workspace vormt de basis voor betrouwbare en kosteneffectieve logging die voldoet aan zowel operationele als compliance-vereisten.

De eerste stap omvat het creëren van een toegewijde Log Analytics-workspace specifiek voor Databricks-logs, of het gebruik van een bestaande centrale beveiligingslogging-workspace als uw organisatie al over een dergelijke centrale infrastructuur beschikt. Voor organisaties met meerdere Databricks-workspaces of andere Azure-services die logging vereisen, wordt aanbevolen om te werken met een centrale beveiligingslogging-workspace omdat dit kosten bespaart, consistentie waarborgt en centrale beheerbaarheid mogelijk maakt. Een centrale workspace maakt het mogelijk om logs van verschillende services op één locatie te verzamelen, wat het eenvoudiger maakt om correlaties te maken tussen gebeurtenissen in verschillende systemen en om een uniforme beveiligingsmonitoring-strategie te implementeren. Voor organisaties die beginnen met logging of die een geïsoleerde Databricks-omgeving hebben, kan een toegewijde workspace meer geschikt zijn omdat dit betere kostentoewijzing en isolatie mogelijk maakt. Bij het benoemen van de workspace is het belangrijk om een duidelijke en consistente naamgevingsconventie te volgen die de functie en locatie duidelijk maakt. Voorbeelden van geschikte namen zijn 'law-databricks-prod-westeu' voor een productieworkspace in West-Europa, of 'law-security-central' voor een centrale beveiligingslogging-workspace. Deze naamgevingsconventie maakt het eenvoudiger om de workspace later te identificeren en te beheren, vooral in omgevingen met meerdere workspaces waar duidelijkheid over de functie van elke workspace essentieel is voor effectief beheer.

De tweede stap betreft het configureren van de dataretentie in Log Analytics, wat een cruciaal onderdeel is van de workspace-configuratie omdat dit bepaalt hoe lang logbestanden beschikbaar blijven voor analyse en compliance-doeleinden. Retentie-instellingen hebben directe invloed op zowel de operationele capaciteit voor probleemoplossing als op de compliance-positie van de organisatie. Het minimale aanbevolen retentieperiode is 90 dagen voor operationele probleemoplossing, omdat dit een voldoende periode biedt om de meeste operationele problemen te onderzoeken en op te lossen zonder de kosten te hoog te laten oplopen. Deze periode van 90 dagen is vaak voldoende voor het oplossen van dagelijkse operationele problemen zoals mislukte taken, clusterproblemen of prestatieproblemen. Voor beveiligingsonderzoeken wordt een langere retentieperiode aanbevolen van 1 tot 2 jaar, omdat beveiligingsincidenten soms maanden of zelfs jaren na het incident aan het licht kunnen komen tijdens forensisch onderzoek of compliance-audits. Deze langere retentieperiode is essentieel omdat beveiligingsonderzoeken vaak complex zijn en tijd vergen om volledig te begrijpen, en omdat compliance-audits regelmatig terugkijken naar historische gebeurtenissen om te verifiëren dat beveiligingsmaatregelen consistent zijn toegepast. Voor organisaties die moeten voldoen aan specifieke compliance-vereisten zoals BIO of ISO 27001, is vaak een bewaarperiode van 7 jaar verplicht voor auditlogs. Deze langetermijnbewaring is vereist om te kunnen voldoen aan regelgevingsvereisten en om te kunnen aantonen dat organisaties gedurende langere perioden voldoen aan beveiligingsstandaarden. Het is belangrijk om te realiseren dat retentieperiodes langer dan 90 dagen extra kosten met zich meebrengen, ongeveer €0,10 tot €0,15 per GB per maand, wat betekent dat organisaties zorgvuldig moeten afwegen tussen compliance-vereisten en kostenoptimalisatie. Voor langetermijnbewaring over periodes van 7 jaar of langer wordt aanbevolen om gebruik te maken van Azure Storage Account-archivering, wat aanzienlijk goedkoper is dan langetermijnretentie in Log Analytics en wat organisaties in staat stelt om te voldoen aan compliance-vereisten zonder onnodig hoge kosten.

De derde stap omvat het inschakelen van Log Analytics workspace insights voor prestatiemonitoring van de workspace zelf, wat essentieel is om te waarborgen dat de workspace optimaal functioneert en om potentiële problemen vroegtijdig te detecteren. Workspace insights bieden uitgebreide inzichten in verschillende aspecten van de workspace-prestaties, inclusief queryprestaties die laten zien hoe snel queries worden uitgevoerd en welke queries mogelijk geoptimaliseerd moeten worden, opnamesnelheid die aangeeft hoe snel logbestanden worden opgenomen en of er mogelijk bottlenecks zijn in de opnamepijplijn, en datavolumetrends die laten zien hoeveel data wordt opgenomen over tijd en of er ongebruikelijke pieken of dalen zijn die mogelijk wijzen op problemen of beveiligingsincidenten. Deze inzichten zijn belangrijk voor het waarborgen van de betrouwbaarheid van de logging-infrastructuur en voor het vroegtijdig detecteren van problemen die kunnen leiden tot het verlies van loggegevens of vertragingen in de beschikbaarheid van logs voor analyse. Organisaties moeten regelmatig de workspace insights controleren om te zorgen dat de workspace optimaal functioneert en om potentiële problemen vroegtijdig te identificeren.

De vierde stap betreft het configureren van toegangscontroles op de Log Analytics workspace, wat cruciaal is voor het waarborgen van de beveiliging van loggegevens en voor het naleven van het principe van least privilege. Loggegevens bevatten vaak gevoelige informatie over gebruikersactiviteiten, systeemconfiguraties en beveiligingsgebeurtenissen, wat betekent dat toegang tot deze gegevens strikt moet worden gecontroleerd om te voorkomen dat onbevoegde personen toegang krijgen tot gevoelige informatie. Alleen het beveiligingsteam, compliance-officers en Databricks-beheerders zouden toegang moeten hebben tot loggegevens, waarbij elk van deze groepen alleen de toegang krijgt die nodig is voor hun specifieke rol. Voor alleen-lezentoegang moet de Azure RBAC-rol 'Log Analytics Reader' worden gebruikt, wat gebruikers in staat stelt om logs te lezen en queries uit te voeren zonder de mogelijkheid om configuraties te wijzigen of logs te verwijderen. Voor gebruikers die queries en waarschuwingen moeten kunnen aanmaken, moet de rol 'Log Analytics Contributor' worden gebruikt, wat naast leesrechten ook de mogelijkheid biedt om queries op te slaan, waarschuwingen te configureren en dashboards aan te maken. Het is belangrijk om regelmatig de toegangsrechten te controleren en te verwijderen voor gebruikers die deze rechten niet langer nodig hebben, bijvoorbeeld wanneer medewerkers van functie veranderen of de organisatie verlaten.

De vijfde en optionele stap betreft het opzetten van een Storage Account voor langetermijnarchivering wanneer de retentiekosten in Log Analytics te hoog worden voor lange periodes, wat met name relevant is voor organisaties die moeten voldoen aan compliance-vereisten met bewaarperiodes van 7 jaar of langer. Log Analytics is geoptimaliseerd voor operationele analyse en probleemoplossing, wat betekent dat de kosten voor langetermijnbewaring in Log Analytics aanzienlijk hoger kunnen zijn dan archivering in Azure Blob Storage. Voor langetermijnarchivering wordt aanbevolen om logs naar goedkopere blob storage te archiveren na 1 tot 2 jaar, waarbij organisaties gebruikmaken van Azure Storage Accounts die zijn geconfigureerd met immutable blob storage policies om te waarborgen dat gearchiveerde logbestanden niet kunnen worden gewijzigd of verwijderd. Deze immutable policies zijn essentieel voor compliance-doeleinden omdat ze garanderen dat logbestanden authentiek blijven en niet kunnen worden gemanipuleerd, wat vereist is voor audittrails en forensisch onderzoek. Het archiveringsproces kan worden geautomatiseerd met behulp van Logic Apps of Azure Data Factory-pijplijnen die regelmatig exports uitvoeren van logs die ouder zijn dan een bepaalde periode, waardoor organisaties kunnen voldoen aan langetermijnbewaarvereisten zonder de hoge kosten voor retentie in Log Analytics.

**FASE 2: Databricks-diagnostische instellingen configuratie (Duur: 30 minuten per workspace)**

De tweede fase omvat de configuratie van de diagnostische instellingen op de Databricks-workspace zelf. Deze fase is essentieel omdat hier wordt bepaald welke logs worden verzameld en waar deze naartoe worden gestuurd. De configuratie neemt ongeveer 30 minuten per workspace in beslag, afhankelijk van het aantal beschikbare logcategorieën en de gewenste bestemmingen. Deze fase is kritiek omdat onjuiste configuratie kan leiden tot het missen van belangrijke gebeurtenissen of tot het verzenden van logs naar verkeerde bestemmingen, wat zowel beveiligings- als compliance-risico's met zich meebrengt.

Begin met het navigeren in de Azure Portal naar de Azure Databricks-workspace en selecteer vervolgens Monitoring gevolgd door Diagnostische instellingen. Klik op 'Diagnostische instelling toevoegen' en geef een duidelijke beschrijvende naam, zoals 'Verzenden-naar-LogAnalytics-Beveiliging' of 'Databricks-Audit-Logs'. Deze naam maakt het eenvoudiger om de instelling later te identificeren en te beheren wanneer meerdere diagnostische instellingen worden geconfigureerd. Een duidelijke naamgevingsconventie is belangrijk omdat organisaties vaak meerdere diagnostische instellingen configureren voor verschillende doeleinden, zoals beveiligingsmonitoring, operationele monitoring of compliance-archivering, en het is essentieel om snel te kunnen identificeren welke instelling voor welk doel wordt gebruikt.

Selecteer alle beschikbare logcategorieën voor uitgebreide zichtbaarheid. Elke categorie legt specifieke aspecten van de Databricks-omgeving vast, en door alle categorieën te selecteren wordt een compleet beeld verkregen van alle activiteiten binnen de workspace. De workspace-categorie registreert workspaceconfiguratiewijzigingen en gebruikersbeheer, wat essentieel is voor het begrijpen van wijzigingen in de configuratie en toegangsrechten. De clusters-categorie houdt clusterevenementen bij, inclusief aanmaak, start, stop en verwijdering, wat belangrijk is voor het monitoren van resourcegebruik en het detecteren van ongebruikelijke clusteractiviteiten. De taak-categorie documenteert alle taakuitvoeringen, inclusief successen en fouten, wat cruciaal is voor operationele monitoring en probleemoplossing. De DBFS-categorie registreert bestandssysteembewerkingen en datatoegang, wat essentieel is voor het detecteren van ongeautoriseerde data-toegang of data-exfiltratie. De accounts-categorie legt authenticatiegebeurtenissen en tokengeneratie vast, wat belangrijk is voor beveiligingsmonitoring en het detecteren van brute force-aanvallen. De SSH-categorie houdt SSH-toegang tot clusters bij voor debugging, wat nuttig is voor het begrijpen van directe clustertoegang. De notebook-categorie documenteert notebookuitvoeringen en celruns, indien beschikbaar, wat belangrijk is voor het begrijpen van welke code wordt uitgevoerd en door wie. Het selecteren van alle categorieën zorgt ervoor dat er geen belangrijke gebeurtenissen worden gemist en dat een compleet audit trail wordt gecreëerd van alle activiteiten binnen de Databricks-workspace.

Kies vervolgens de bestemming door 'Verzenden naar Log Analytics-workspace' te selecteren en de in Fase 1 aangemaakte workspace te kiezen. Deze bestemming is essentieel omdat het de centrale locatie is waar alle logs worden verzameld voor analyse en monitoring. De categorie 'Alle metrische gegevens' is optioneel en kan worden ingeschakeld wanneer prestatiemetrieken ook nodig zijn. Het verzenden van metrische gegevens naast logs biedt aanvullende inzichten in de prestatie van de Databricks-omgeving en kan helpen bij het identificeren van mogelijke prestatieproblemen. Metrische gegevens kunnen informatie bevatten over clustergebruik, taakuitvoeringstijden, resourceverbruik en andere prestatie-indicatoren die nuttig zijn voor het optimaliseren van de Databricks-omgeving en het identificeren van mogelijke bottlenecks of prestatieproblemen.

Als optionele tweede bestemming kan 'Archiveren naar opslagaccount' worden gekozen voor compliancelangetermijnbewaring wanneer een bewaarperiode van 7 jaar vereist is. Deze archivering is belangrijk voor organisaties die moeten voldoen aan regelgevingsvereisten zoals ISO 27001, NIS2 of BIO, waarbij vaak langetermijnbewaring van auditlogs verplicht is. Selecteer een toegewijde opslagaccount met onveranderbare blobbeleidsregels voor manipulatiewerende archivering. Deze onveranderbare beleidsregels zorgen ervoor dat logs niet kunnen worden gewijzigd of verwijderd nadat ze zijn gearchiveerd, wat essentieel is voor compliance-audittrails en voor het waarborgen van de authenticiteit van logbestanden tijdens externe audits of juridische procedures. De onveranderbare beleidsregels voorkomen dat zelfs beheerders logbestanden kunnen wijzigen of verwijderen, wat cruciaal is voor het aantonen dat auditlogs authentiek zijn en niet zijn gemanipuleerd.

Klik op 'Opslaan' en wacht 5 tot 10 minuten tot de logopname begint. Deze wachttijd is nodig omdat Azure tijd nodig heeft om de diagnostische instellingen te activeren en om de eerste logs te verzamelen en te verzenden naar de Log Analytics-workspace. Verifieer via Log Analytics dat Databricks-logs verschijnen in tabellen zoals 'DatabricksClusters', 'DatabricksJobs' en 'DatabricksWorkspace'. Deze verificatie is belangrijk om te zorgen dat de configuratie correct werkt en dat logs daadwerkelijk worden verzameld en opgeslagen. Als logs niet verschijnen binnen 30 minuten na configuratie, moet de configuratie worden gereviewd om te identificeren waar het proces mogelijk is mislukt, bijvoorbeeld door problemen met toegangsrechten, onjuiste Log Analytics-workspace-configuratie, of problemen met de diagnostische instelling zelf.

**FASE 3: Waarschuwingsregels configuratie voor beveiligingsmonitoring (Duur: 2 tot 3 uur)**

De derde fase betreft de configuratie van waarschuwingsregels voor beveiligingsmonitoring. Deze regels zijn essentieel voor het detecteren van beveiligingsincidenten en verdachte activiteiten in real-time, waardoor organisaties snel kunnen reageren op potentiële bedreigingen voordat deze significante schade kunnen veroorzaken. Waarschuwingsregels maken het mogelijk om automatisch te worden geïnformeerd wanneer specifieke beveiligingsgebeurtenissen plaatsvinden, wat cruciaal is voor effectieve beveiligingsmonitoring en incidentresponse. De eerste waarschuwingsregel moet worden geconfigureerd voor ongeautoriseerde toegang. Deze regel gebruikt een KQL-query die mislukte inlogpogingen detecteert: 'DatabricksAccounts | where ResultType == "Failed" and EventName contains "login" | summarize FailedAttempts=count() by User, IP | where FailedAttempts > 5'. Een waarschuwing wordt gegenereerd wanneer meer dan 5 mislukte inlogpogingen binnen 1 uur worden gedetecteerd, wat kan wijzen op een brute force-aanval waarbij een aanvaller systematisch probeert toegang te krijgen tot accounts door verschillende wachtwoorden te proberen. De actie moet worden geconfigureerd om een e-mail te sturen naar het beveiligingsteam en een incident aan te maken in het SIEM-systeem, zoals Microsoft Sentinel, zodat het beveiligingsteam onmiddellijk kan reageren op de potentiële bedreiging.

Een tweede waarschuwingsregel moet worden geconfigureerd voor clustermodificaties door niet-beheerders. Deze regel gebruikt de query 'DatabricksClusters | where OperationName contains "delete" or OperationName contains "create" | where InitiatedBy !in ("admin@company.com", "svc-databricks@company.com")'. Deze regel is belangrijk omdat clustermodificaties, met name het verwijderen van clusters, significante impact kunnen hebben op de beschikbaarheid van data en applicaties. Onverwachte clusterverwijderingen kunnen dataverlies veroorzaken of wijzen op insider threats waarbij kwaadwillende medewerkers of gecompromitteerde accounts proberen schade aan te richten door kritieke resources te verwijderen. Deze waarschuwing is met name belangrijk omdat het verwijderen van clusters kan leiden tot verlies van kritieke data en configuraties, wat aanzienlijke bedrijfsimpact kan hebben. Door waarschuwingen te configureren voor clustermodificaties door niet-beheerders kunnen organisaties snel detecteren wanneer onbevoegde gebruikers proberen clusters te wijzigen of te verwijderen, wat essentieel is voor het voorkomen van dataverlies en het detecteren van insider threats.

Een derde waarschuwingsregel moet worden geconfigureerd voor excessieve datatoegang. Deze regel gebruikt de query 'DatabricksDBFS | summarize Operations=count() by User, bin(TimeGenerated, 1h) | where Operations > 1000'. Deze regel is belangrijk omdat abnormaal hoge bestandssysteemtoegang kan wijzen op data-exfiltratie, waarbij een aanvaller of gecompromitteerd account systematisch gevoelige data probeert te downloaden. Data-exfiltratie is een veelvoorkomende aanvalstechniek waarbij aanvallers grote hoeveelheden data proberen te stelen, vaak door geautomatiseerde scripts te gebruiken die systematisch door bestandssystemen navigeren en data downloaden. Deze waarschuwing helpt bij het detecteren van insider threats en gecompromitteerde accounts die worden gebruikt voor ongeautoriseerde datatoegang. Door waarschuwingen te configureren voor excessieve datatoegang kunnen organisaties snel detecteren wanneer ongebruikelijke toegangspatronen plaatsvinden, wat essentieel is voor het voorkomen van data-exfiltratie en het detecteren van gecompromitteerde accounts.

Een vierde waarschuwingsregel moet worden geconfigureerd voor privilege escalation-pogingen. Deze regel gebruikt de query 'DatabricksWorkspace | where EventName contains "permissions" or EventName contains "admin" | where ResultType == "Success"'. Deze regel volgt wie beheerdersrechten krijgt of wijzigt, wat essentieel is voor het detecteren van ongeautoriseerde privilege escalation. Privilege escalation is een veelvoorkomende aanvalstechniek waarbij aanvallers proberen hogere rechten te verkrijgen om toegang te krijgen tot gevoelige data en systemen. Door beheerdersrechten te verkrijgen kunnen aanvallers toegang krijgen tot alle data en configuraties binnen de Databricks-workspace, wat aanzienlijke beveiligingsrisico's met zich meebrengt. Deze waarschuwing is belangrijk omdat het detecteren van privilege escalation-pogingen essentieel is voor het voorkomen van ongeautoriseerde toegang tot gevoelige data en systemen. Door waarschuwingen te configureren voor privilege escalation-pogingen kunnen organisaties snel detecteren wanneer onbevoegde gebruikers proberen beheerdersrechten te verkrijgen, wat cruciaal is voor het voorkomen van beveiligingsincidenten.

Een vijfde waarschuwingsregel moet worden geconfigureerd voor spikes in mislukte authenticatie. Deze regel gebruikt de query 'DatabricksAccounts | where ResultType == "Failed" | summarize count() by bin(TimeGenerated, 5m) | where count_ > 20'. Deze regel is belangrijk omdat spikes in mislukte authenticatiepogingen vaak wijzen op geautomatiseerde aanvallen of gecompromitteerde accounts. Meer dan 20 mislukte authenticatiepogingen binnen 5 minuten is abnormaal en kan wijzen op een geautomatiseerde aanval of een gecompromitteerd account dat wordt gebruikt voor ongeautoriseerde toegangspogingen. Brute force-aanvallen zijn een veelvoorkomende aanvalstechniek waarbij aanvallers systematisch verschillende wachtwoorden proberen om toegang te krijgen tot accounts, en deze aanvallen worden vaak geautomatiseerd waardoor ze snel grote aantallen inlogpogingen kunnen genereren. Deze waarschuwing helpt bij het detecteren van brute force-aanvallen en andere authenticatie-gerelateerde bedreigingen, waardoor organisaties snel kunnen reageren op potentiële beveiligingsincidenten voordat aanvallers succesvol toegang kunnen krijgen tot accounts.

Voor elke waarschuwingsregel moeten actiegroepen worden geconfigureerd met e-mailnotificaties naar het beveiligingsteam, webhooks naar het SIEM-systeem zoals Microsoft Sentinel, en optioneel SMS voor kritieke waarschuwingen buiten kantooruren. Actiegroepen zijn essentieel omdat ze bepalen wie wordt geïnformeerd wanneer een waarschuwing wordt gegenereerd en welke acties automatisch worden uitgevoerd. E-mailnotificaties zorgen ervoor dat het beveiligingsteam onmiddellijk wordt geïnformeerd over potentiële beveiligingsincidenten, wat cruciaal is voor snelle respons. Webhooks naar SIEM-systemen maken het mogelijk om waarschuwingen automatisch te integreren in beveiligingsmonitoring-workflows, waardoor beveiligingsteams waarschuwingen kunnen analyseren in de context van andere beveiligingsgebeurtenissen. SMS-notificaties voor kritieke waarschuwingen buiten kantooruren zorgen ervoor dat beveiligingsteams ook buiten normale werktijden worden geïnformeerd over kritieke beveiligingsincidenten, wat belangrijk is voor 24/7 beveiligingsmonitoring. Deze configuratie zorgt ervoor dat beveiligingsincidenten snel worden gedetecteerd en geëscaleerd naar de juiste personen en systemen voor verdere analyse en respons, wat essentieel is voor effectieve beveiligingsmonitoring en incidentresponse.

**FASE 4: Log Analytics-queries en workbooks voor operationele inzichten (Duur: 2 uur)**

De vierde fase omvat de configuratie van Log Analytics-queries en workbooks voor operationele inzichten. Deze fase is belangrijk omdat queries en workbooks het eenvoudiger maken om inzicht te krijgen in de gezondheid en het gebruik van de Databricks-omgeving zonder telkens complexe queries te hoeven schrijven. Queries maken het mogelijk om specifieke vragen te beantwoorden over de Databricks-omgeving, zoals wie toegang heeft gehad tot specifieke notebooks, welke taken zijn mislukt, of welke clusters ongebruikt zijn. Workbooks bieden visuele dashboards die een overzicht geven van de gezondheid en het gebruik van de Databricks-omgeving, waardoor het eenvoudiger is om trends en patronen te identificeren. De configuratie neemt ongeveer 2 uur in beslag, afhankelijk van het aantal gewenste queries en de complexiteit van de workbooks. Deze fase is essentieel voor effectieve operationele monitoring en voor het maken van datagedreven beslissingen over de Databricks-omgeving.

Sla veelgebruikte KQL-queries op als functies in Log Analytics om ze eenvoudig te kunnen hergebruiken. Functies maken het mogelijk om complexe queries te encapsuleren in herbruikbare componenten, wat tijd bespaart en consistentie waarborgt bij het uitvoeren van regelmatige analyses. Maak bijvoorbeeld een functie 'Top 10 actieve gebruikers' met de query 'DatabricksWorkspace | summarize count() by User | top 10' om de tien meest actieve gebruikers te identificeren. Deze functie is nuttig voor het begrijpen van wie het meest gebruik maakt van de Databricks-omgeving en voor het identificeren van gebruikers die mogelijk extra training of ondersteuning nodig hebben. Maak een functie 'Clustergebruik' met de query 'DatabricksClusters | where State=="Running"' om te zien welke clusters actief zijn. Deze functie is belangrijk voor het monitoren van resourcegebruik en voor het identificeren van clusters die mogelijk ongebruikt zijn en kosten genereren zonder toegevoegde waarde. Maak een functie 'Taakfoutpercentage' met de query 'DatabricksJobs | summarize Total=count(), Failed=countif(ResultType=="Failed") | extend FailureRate = (Failed*100.0)/Total' om het percentage mislukte taken te berekenen. Deze functie is essentieel voor het monitoren van de betrouwbaarheid van taken en voor het identificeren van trends in taakfouten die mogelijk wijzen op structurele problemen. Deze functies maken het eenvoudiger om regelmatig gebruikte queries uit te voeren zonder telkens de volledige query te hoeven typen, wat tijd bespaart en consistentie waarborgt bij het uitvoeren van analyses.

Creëer een Azure Monitor Workbook-dashboard specifiek voor de operationele gezondheid van Databricks met visualisaties. Dashboards bieden een visueel overzicht van de gezondheid en het gebruik van de Databricks-omgeving, waardoor het eenvoudiger is om trends en patronen te identificeren zonder telkens complexe queries te hoeven uitvoeren. Maak een clusterlevenscyclus-tijdlijn die laat zien wanneer clusters zijn aangemaakt, gestart en gestopt in de loop van de tijd. Deze tijdlijn is nuttig voor het begrijpen van clustergebruikspatronen en voor het identificeren van perioden met hoge of lage clusteractiviteit. Voeg een taakuitvoering-succesgraadtendens toe die het percentage succesvolle taken over de tijd laat zien. Deze tendens is belangrijk voor het monitoren van de betrouwbaarheid van taken en voor het identificeren van trends in taakfouten die mogelijk wijzen op structurele problemen. Maak een overzicht van de topgebruikers op basis van activiteit om te zien wie het meest gebruik maakt van de Databricks-omgeving. Dit overzicht is nuttig voor het begrijpen van gebruikspatronen en voor het identificeren van gebruikers die mogelijk extra training of ondersteuning nodig hebben. Voeg authenticatiepatronen toe die het aantal inlogpogingen per uur laten zien. Deze patronen zijn belangrijk voor het detecteren van ongebruikelijke authenticatieactiviteit die mogelijk wijst op beveiligingsincidenten. Maak een DBFS-toegangsheatmap die laat zien welke delen van het bestandssysteem het meest worden benaderd. Deze heatmap is nuttig voor het begrijpen van datatoegangspatronen en voor het identificeren van gevoelige data die mogelijk extra beveiliging vereist. Deze visualisaties maken het eenvoudiger om patronen en trends te identificeren zonder telkens complexe queries te hoeven uitvoeren, wat tijd bespaart en inzicht verbetert.

Implementeer opgeslagen zoekacties voor veelvoorkomende probleemoplossingsscenario's. Opgeslagen zoekacties maken het mogelijk om veelgebruikte queries op te slaan en snel te kunnen uitvoeren wanneer ze nodig zijn, wat tijd bespaart en consistentie waarborgt bij het beantwoorden van veelvoorkomende vragen. Maak bijvoorbeeld een opgeslagen zoekactie 'Waarom is mijn taak mislukt?' met de query 'DatabricksJobs | where JobId == | project TimeGenerated, EventName, ResultDescription' om snel te zien waarom een specifieke taak is mislukt. Deze zoekactie is essentieel voor probleemoplossing omdat het data engineers in staat stelt om snel de oorzaak van taakfouten te identificeren zonder telkens complexe queries te hoeven schrijven. Maak een opgeslagen zoekactie 'Wie heeft toegang gehad tot deze notebook?' met de query 'DatabricksWorkspace | where NotebookPath contains ""' om te zien wie toegang heeft gehad tot een specifieke notebook. Deze zoekactie is belangrijk voor beveiligingsonderzoeken en compliance-doeleinden omdat het mogelijk maakt om snel te zien wie toegang heeft gehad tot specifieke notebooks, wat essentieel is voor het onderzoeken van beveiligingsincidenten en voor het voldoen aan compliance-vereisten. Deze opgeslagen zoekacties maken het eenvoudiger om veelvoorkomende vragen te beantwoorden zonder telkens dezelfde query te hoeven schrijven, wat tijd bespaart en consistentie waarborgt bij het uitvoeren van analyses.

Deel het workbook met Databricks-gebruikers, data-engineers en management voor zelfbedieningszichtbaarheid in Databricks-gebruik en gezondheid zonder direct Log Analytics-toegang te hoeven geven. Deze aanpak maakt het eenvoudiger om verschillende doelgroepen toegang te geven tot de informatie die ze nodig hebben zonder hen volledige toegang tot Log Analytics te hoeven verlenen. Door workbooks te delen kunnen organisaties self-service monitoring mogelijk maken, waardoor gebruikers zelf inzicht kunnen krijgen in de gezondheid en het gebruik van de Databricks-omgeving zonder dat ze complexe queries hoeven te schrijven of directe toegang tot Log Analytics nodig hebben. Werkbooks kunnen worden gedeeld op verschillende niveaus, waardoor gebruikers alleen de informatie kunnen zien die voor hen relevant is. Deze granulariteit is belangrijk voor beveiliging omdat het ervoor zorgt dat gebruikers alleen toegang hebben tot de informatie die ze nodig hebben voor hun werk, wat het principe van least privilege ondersteunt. Door workbooks te delen kunnen organisaties de adoptie van monitoring verbeteren en gebruikers in staat stellen om zelf problemen te identificeren en op te lossen, wat de efficiëntie verhoogt en de werklast voor beveiligingsteams vermindert.

**FASE 5: Compliance-auditlogretentie en export (Duur: 1 uur setup, doorlopend geautomatiseerd)**

De vijfde fase betreft de configuratie van langetermijnbewaring en export van auditlogs voor compliance-doeleinden. Deze fase is essentieel voor organisaties die moeten voldoen aan compliance-vereisten zoals ISO 27001 of NIS2, waarbij vaak een bewaarperiode van 7 jaar verplicht is. Langetermijnbewaring van auditlogs is vereist om te kunnen voldoen aan regelgevingsvereisten en om te kunnen aantonen dat organisaties gedurende langere perioden voldoen aan beveiligingsstandaarden. Voor organisaties die moeten voldoen aan deze compliance-vereisten is het essentieel om een geautomatiseerd exportproces te implementeren dat Databricks-logs naar een Azure Storage Account archiveert na 90 dagen, wanneer de Log Analytics-retentieperiode afloopt. Dit proces kan worden geautomatiseerd met behulp van een Logic App of een Azure Data Factory-pijplijn die maandelijks exports uitvoert. Automatisering is belangrijk omdat handmatige exports tijdrovend zijn en foutgevoelig, en omdat geautomatiseerde exports ervoor zorgen dat logs consistent en tijdig worden gearchiveerd zonder menselijke tussenkomst. De Logic App of Data Factory-pijplijn moet worden geconfigureerd om automatisch alle Databricks-logs te exporteren die ouder zijn dan 90 dagen, waardoor organisaties kunnen voldoen aan langetermijnbewaarvereisten zonder de hoge kosten voor retentie in Log Analytics. Deze aanpak maakt het mogelijk om te voldoen aan compliance-vereisten terwijl de kosten worden geminimaliseerd door gebruik te maken van goedkopere opslag voor langetermijnarchivering.

Het archief Storage Account moet worden geconfigureerd met onveranderbare blobopslagbeleidsregels om te waarborgen dat logbestanden niet kunnen worden gewijzigd of verwijderd na archivering. Deze onveranderlijke opslagbeleidsregels zijn essentieel voor het garanderen van fraudebestendige audittrails die vereist zijn voor juridische en compliance-doeleinden. Onveranderbare blobopslagbeleidsregels voorkomen dat logbestanden kunnen worden gemanipuleerd of verwijderd, zelfs door beheerders, wat cruciaal is voor het aantonen van de authenticiteit van auditlogs tijdens externe audits of juridische procedures. Deze authenticiteit is essentieel omdat auditors en regelgevers moeten kunnen vertrouwen op de integriteit van auditlogs om te kunnen verifiëren dat organisaties voldoen aan beveiligingsstandaarden en regelgevingsvereisten. De beleidsregels moeten worden geconfigureerd met een vergrendelingsperiode die overeenkomt met de vereiste bewaarperiode, bijvoorbeeld 7 jaar voor ISO 27001-compliance. Deze vergrendelingsperiode zorgt ervoor dat logbestanden gedurende de volledige vereiste bewaarperiode niet kunnen worden gewijzigd of verwijderd, wat essentieel is voor het voldoen aan compliance-vereisten en voor het waarborgen van de integriteit van auditlogs.

Geëxporteerde logbestanden moeten worden gelabeld met metadata die de eenvoudige terugvindbaarheid tijdens audits vergemakkelijken. Metadata is essentieel voor het effectief beheren van grote hoeveelheden gearchiveerde logs en voor het snel kunnen vinden van specifieke logbestanden wanneer ze nodig zijn voor audits of forensisch onderzoek. Deze labels moeten informatie bevatten zoals het jaar en de maand van export, de naam van de Databricks-workspace waarvan de logs afkomstig zijn, en de logcategorie zoals Clusters, Taken of Workspace. Deze metadata maakt het mogelijk om specifieke logbestanden snel te vinden tijdens audits of forensisch onderzoek, wat de effectiviteit van compliance-audits aanzienlijk verbetert. Zonder goede metadata kan het vinden van specifieke logbestanden in grote archieven tijdrovend en foutgevoelig zijn, wat de effectiviteit van audits kan verminderen. De labels moeten worden toegepast bij het exporteren van de logs, zodat elke geëxporteerde blob duidelijk kan worden geïdentificeerd en gerelateerd aan de oorspronkelijke Databricks-workspace en de periode waarin de logs zijn gegenereerd. Deze relatie is belangrijk omdat het mogelijk maakt om logs te traceren naar hun oorsprong, wat essentieel is voor forensisch onderzoek en voor het begrijpen van de context van gebeurtenissen.

Het logherstelproces moet worden getest om te verifiëren dat gearchiveerde logs indien nodig kunnen worden geïmporteerd terug in Log Analytics voor analyse tijdens onderzoeken of audits. Dit herstelproces is belangrijk omdat het soms nodig kan zijn om oude logs te analyseren tijdens beveiligingsincidentonderzoeken of compliance-audits. Tijdens beveiligingsincidentonderzoeken kan het nodig zijn om historische logs te analyseren om de oorsprong en omvang van een incident te begrijpen, en tijdens compliance-audits kunnen auditors vragen om specifieke historische logs te analyseren om te verifiëren dat beveiligingsmaatregelen consistent zijn toegepast. Het testen van het herstelproces moet worden uitgevoerd door een representatief logbestand te exporteren naar het archief Storage Account, vervolgens het logbestand te importeren terug in Log Analytics, en te verifiëren dat de geïmporteerde logs correct kunnen worden opgevraagd met behulp van standaard KQL-queries. Deze test is essentieel omdat het verifiëert dat het herstelproces correct werkt en dat gearchiveerde logs daadwerkelijk kunnen worden gebruikt voor analyse wanneer dat nodig is. Deze test moet regelmatig worden herhaald, bijvoorbeeld elk kwartaal, om te waarborgen dat het herstelproces blijft werken na wijzigingen in de Azure-omgeving of Log Analytics-configuratie. Regelmatige tests zijn belangrijk omdat wijzigingen in de Azure-omgeving of Log Analytics-configuratie kunnen leiden tot problemen met het herstelproces die alleen worden ontdekt wanneer het proces daadwerkelijk wordt getest.

De retentiebeleidsregels, het exportschema, de opslaglocatie en de herstelprocedures moeten worden gedocumenteerd in compliance-documentatie voor auditors. Deze documentatie is essentieel omdat auditors moeten kunnen begrijpen hoe logs worden bewaard en gearchiveerd om te kunnen verifiëren dat organisaties voldoen aan compliance-vereisten. De documentatie moet duidelijk beschrijven hoe lang logs worden bewaard, wanneer logs worden gearchiveerd, waar gearchiveerde logs worden opgeslagen, en hoe logs kunnen worden hersteld indien nodig. Deze informatie is belangrijk voor auditors omdat het hen in staat stelt om te verifiëren dat logs correct worden bewaard en gearchiveerd volgens de vereisten van verschillende compliance-frameworks. De documentatie moet ook de technische details bevatten die nodig zijn voor auditors om te verifiëren dat de logging en archivering correct zijn geïmplementeerd, zoals de configuratie van onveranderbare blobopslagbeleidsregels, de verificatie van geëxporteerde logs, en de procedures voor logherstel. Deze technische details zijn belangrijk omdat auditors moeten kunnen verifiëren dat de implementatie correct is en dat logs daadwerkelijk worden bewaard en gearchiveerd zoals beschreven. Deze documentatie is essentieel voor het succesvol doorstaan van externe audits en het aantonen van compliance met verschillende frameworks en regelgeving. Zonder goede documentatie kunnen auditors niet verifiëren dat organisaties voldoen aan compliance-vereisten, wat kan leiden tot auditbevindingen en mogelijke boetes of sancties.

**Totale implementatietijd**: 2 tot 3 uur voor basissetup van diagnostische logging inclusief Log Analytics-workspace, diagnostische instellingen en basiswaarschuwingen. Aanvullende 3 tot 4 uur voor uitgebreide waarschuwingsregels, workbooks en geautomatiseerde compliance-archivering. Totaal: 5 tot 7 uur voor volledige implementatie. Deze tijdsinvestering is essentieel voor het opzetten van een robuuste logging-infrastructuur die voldoet aan zowel operationele als compliance-vereisten.

**Kosten**: Log Analytics-data-opname: €2,30 per GB. Een typische Databricks-workspace genereert 5 tot 20 GB logs per maand afhankelijk van het activiteitsniveau, wat neerkomt op €12 tot €45 per maand. Databewaring: eerste 90 dagen gratis, daarna €0,12 per GB per maand. Storage Account-archivering: €0,02 per GB per maand, wat zeer goedkoop is voor langetermijnbewaring voor compliance. Totale kosten: €15 tot €60 per maand voor uitgebreide logging. Deze kosten zijn een investering in beveiliging en compliance die essentieel is voor het waarborgen van de beveiligingspositie en voor het voldoen aan regelgevingsvereisten.

Monitoring

Gebruik PowerShell-script databricks-diagnostic-logs.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Azure Databricks begint bij het besef dat diagnostische logging geen eindpunt is, maar het fundament onder een continu controleproces. Zodra logs naar een Log Analytics-workspace worden gestuurd, ontstaat de mogelijkheid om patronen, afwijkingen en incidenten zichtbaar te maken die anders onopgemerkt zouden blijven. Monitoring betekent in dit kader dat u dagelijks en wekelijks gericht naar deze gegevens kijkt met behulp van doordachte KQL-queries, dat u vaste rapportages en dashboardweergaven inricht, en dat u duidelijke procedures vastlegt voor wat er moet gebeuren wanneer een waarschuwing of afwijkend patroon wordt gevonden. Het doel is niet alleen om incidenten achteraf te reconstrueren, maar vooral om vroegtijdig signalen op te vangen dat er iets mis dreigt te gaan in uw Databricks-omgeving.

De informatie die hiervoor nodig is, ligt verspreid over meerdere Databricks-specifieke tabellen in Log Analytics. De tabel DatabricksClusters geeft inzicht in de volledige levenscyclus van clusters: aanmaak, start, stop en verwijdering. Door hier structureel op te rapporteren, krijgen beheerders grip op capaciteit, kosten en misbruik. Een veelgebruikte benadering is om elke dag een overzicht te genereren van clusters die uitzonderlijk lang actief zijn gebleven en mogelijk geen actieve taken meer draaien. Met een query die alle clusters in de status "Running" selecteert en de looptijd per cluster samenvat, ziet u direct welke resources waarschijnlijk onnodig kosten veroorzaken. Wanneer u deze informatie koppelt aan eigenaarschap (bijvoorbeeld door tags of naamgevingsconventies), ontstaat een duidelijk gesprek met workloads-eigenaren over opschonen, automatiseren van shutdowns en het voorkomen van onnodige uitgaven.

Waar DatabricksClusters vooral iets zegt over infrastructuur en capaciteit, richt de tabel DatabricksJobs zich op de feitelijke verwerking van workloads. Hierin is voor elke job-uitvoering zichtbaar of deze geslaagd of mislukt is, hoe lang de uitvoering duurde en welke patronen zich over de tijd aftekenen. In een volwassen monitoringproces wordt niet alleen gekeken naar individuele foutmeldingen, maar vooral naar trends: neemt het percentage mislukte jobs toe, vallen storingen steeds op dezelfde tijdstippen, of zijn er specifieke jobs die structureel problemen geven? Door bijvoorbeeld per job de verhouding tussen succesvolle en mislukte runs te berekenen en deze informatie te koppelen aan releasekalenders, ziet u snel of een nieuwe versie of configuratiewijziging tot instabiliteit heeft geleid. Deze analyses helpen data-engineeringteams om systematisch te verbeteren in plaats van ad‑hoc incidenten op te lossen.

Naast operationele stabiliteit speelt beveiliging een centrale rol in monitoring. De tabel DatabricksWorkspace laat zien wie wanneer welke notebooks of workspace-resources heeft geopend en uitgevoerd. Door deze gegevens periodiek te analyseren, kunnen organisaties gericht zoeken naar afwijkend gedrag, zoals toegang buiten reguliere kantoortijden, plotselinge activiteit vanaf ongebruikelijke locaties of gebruikers die notebooks openen waarvoor zij normaal geen functionele reden hebben. In plaats van enkel losse meldingen te bekijken, wordt in een volwassen aanpak gewerkt met vaste rapportages, bijvoorbeeld een wekelijks overzicht van toegang tot gevoelige notebooks, gekoppeld aan de functies of teams van de betrokken gebruikers. Deze inzichten zijn onmisbaar tijdens forensisch onderzoek, maar helpen ook om vroegtijdig signalen van mogelijke insider threats of gecompromitteerde accounts te herkennen.

Authenticatie vormt een tweede belangrijke pijler van beveiligingsmonitoring. De tabel DatabricksAccounts bevat alle inlogpogingen, tokenaanvragen en SSO‑gebeurtenissen. Door hier structureel op te monitoren, kunnen brute‑force‑aanvallen, wachtwoordspray‑pogingen en verdachte SSO‑flows snel worden herkend. In plaats van te vertrouwen op een enkele vaste drempelwaarde, is het raadzaam om zowel absolute aantallen mislukte pogingen als trends per gebruiker of IP-adres te volgen. Wanneer bijvoorbeeld voor één gebruiker in korte tijd tientallen mislukte pogingen zichtbaar worden, is dat een sterk signaal dat ofwel een geautomatiseerde aanval plaatsvindt, of dat een gebruiker moeite heeft met aanmelden en wellicht ondersteuning nodig heeft. In een volwassen proces leidt zo'n signaal tot een concrete opvolgactie: het tijdelijk blokkeren van het account, het afdwingen van een wachtwoordreset of het gericht benaderen van de gebruiker door het securityteam.

Tot slot is er het perspectief van gegevensbescherming. De tabel DatabricksDBFS registreert elke relevante bewerking op het Databricks File System en maakt zichtbaar welke gebruikers grote hoeveelheden data lezen of schrijven. Dit is cruciaal voor het tijdig signaleren van mogelijke data‑exfiltratie of ongeautoriseerde raadpleging van gevoelige datasets. In plaats van ruwe logregels te bekijken, richten volwassen organisaties vaste analyses in die bijvoorbeeld per uur het aantal bewerkingen en de totale hoeveelheid overgedragen data per gebruiker samenvatten. Wanneer voor één account plotseling een uitzonderlijk hoog volume aan leesbewerkingen zichtbaar wordt, of wanneer grote downloads plaatsvinden buiten normale werktijden, is dat een duidelijk signaal dat nader onderzoek vereist is. Door deze analyses te combineren met ingestelde waarschuwingsregels, dashboards in Azure Monitor en afspraken binnen het SOC of CIRT over opvolging, verandert logging van een passieve dataverzameling in een actief instrument voor beveiliging, compliance en continu inzicht in het daadwerkelijke gebruik van Azure Databricks.

Een volwassen monitoringsaanpak combineert deze tabelspecifieke inzichten met zorgvuldig ontworpen waarschuwingsregels en duidelijke rapportagelijnen. In Log Analytics en Azure Monitor worden KQL‑queries vastgelegd als herbruikbare queries en gekoppeld aan alerts die automatisch een incident aanmaken in bijvoorbeeld Microsoft Sentinel, een e‑mail versturen naar het beveiligingsteam en – waar nodig – een SMS of pushbericht naar de dienstdoende analist genereren. In de praktijk betekent dit dat kritieke signalen, zoals meerdere mislukte aanmeldingen in korte tijd, onverwachte clusterverwijderingen door niet‑beheerders of extreem hoge data‑leesvolumes vanuit DatabricksDBFS, niet alleen zichtbaar zijn in dashboards maar ook daadwerkelijk leiden tot actie. Door deze technische inrichting te koppelen aan procedures, runbooks en een heldere rolverdeling tussen beheer, security en datateams, ontstaat een doorlopende monitoringsketen waarin Databricks niet langer een blinde vlek is, maar een integraal onderdeel van de algehele beveiligings- en operations‑monitoring van de organisatie.

Compliance en auditing

Diagnostische logging voor Azure Databricks is essentieel voor het voldoen aan verschillende compliance-vereisten en regelgeving. Door uitgebreide logging te implementeren kunnen organisaties aantonen dat ze voldoen aan de vereisten van verschillende frameworks en regelgeving, wat cruciaal is voor het verkrijgen en behouden van certificeringen en het vermijden van boetes en sancties.

ISO 27001 vereist onder controle A.12.4.1 dat organisaties gebeurtenissen loggen en audittrails onderhouden. Deze controle vereist dat organisaties alle relevante beveiligingsgebeurtenissen loggen, inclusief toegang tot systemen, configuratiewijzigingen en beveiligingsincidenten. Diagnostische logging voor Databricks voldoet aan deze vereiste door alle workspace-activiteiten, cluster-gebeurtenissen, job-uitvoeringen en beveiligingsgebeurtenissen te loggen. De logs moeten worden bewaard voor een periode die voldoet aan de vereisten van de organisatie, meestal minimaal 1 jaar, maar vaak 7 jaar voor organisaties die moeten voldoen aan specifieke regelgeving.

NIS2 vereist onder artikel 21 dat organisaties logging en monitoring van beveiligingsgebeurtenissen implementeren. Deze vereiste is met name relevant voor organisaties die worden aangemerkt als essentiële entiteiten of belangrijke entiteiten onder NIS2. Diagnostische logging voor Databricks voldoet aan deze vereiste door uitgebreide logging te bieden van alle beveiligingsgebeurtenissen, inclusief authenticatiegebeurtenissen, toegangscontrole en beveiligingsincidenten. De logs moeten worden bewaard voor een periode die voldoet aan de vereisten van NIS2, meestal minimaal 1 jaar, maar vaak langer voor kritieke infrastructuur.

De AVG/GDPR vereist onder artikel 32 dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beveiligen, inclusief logging van verwerkingsactiviteiten. Diagnostische logging voor Databricks voldoet aan deze vereiste door alle activiteiten te loggen die betrekking hebben op de verwerking van persoonsgegevens, inclusief toegang tot data, data-bewerkingen en data-toegang. De logs moeten worden bewaard voor een periode die voldoet aan de vereisten van de AVG, meestal minimaal 1 jaar, maar vaak langer voor organisaties die moeten voldoen aan specifieke sectorale regelgeving.

BIO vereist onder thema 12.04 dat organisaties logregistratie implementeren voor alle relevante beveiligingsgebeurtenissen. Deze vereiste is met name relevant voor Nederlandse overheidsorganisaties die moeten voldoen aan de Baseline Informatiebeveiliging Overheid. Diagnostische logging voor Databricks voldoet aan deze vereiste door uitgebreide logging te bieden van alle beveiligingsgebeurtenissen, inclusief toegang tot systemen, configuratiewijzigingen en beveiligingsincidenten. De logs moeten worden bewaard voor een periode die voldoet aan de vereisten van BIO, meestal minimaal 1 jaar, maar vaak langer voor organisaties die moeten voldoen aan specifieke sectorale regelgeving.

SOC 2 vereist dat organisaties logging-vereisten implementeren voor alle relevante beveiligingsgebeurtenissen. Deze vereiste is met name relevant voor organisaties die moeten voldoen aan SOC 2 Type II-certificering. Diagnostische logging voor Databricks voldoet aan deze vereiste door uitgebreide logging te bieden van alle beveiligingsgebeurtenissen, inclusief toegang tot systemen, configuratiewijzigingen en beveiligingsincidenten. De logs moeten worden bewaard voor een periode die voldoet aan de vereisten van SOC 2, meestal minimaal 1 jaar, maar vaak langer voor organisaties die moeten voldoen aan specifieke sectorale regelgeving.

Tijdens audits moeten organisaties kunnen aantonen dat ze voldoen aan deze vereisten door auditbewijs te leveren, inclusief configuratie van diagnostische instellingen, Log Analytics workspace-integratie, log-retentieconfiguratie en voorbeeldlog-queries en waarschuwingsregels. Het is belangrijk om deze documentatie up-to-date te houden en regelmatig te testen om te waarborgen dat de logging correct functioneert en voldoet aan de vereisten.

Remediatie

Gebruik PowerShell-script databricks-diagnostic-logs.ps1 (functie Invoke-Remediation) – Automatiseert de configuratie van diagnostische logging voor Databricks workspaces en verifieert de integratie met Log Analytics.

Remediatie van diagnostische logging voor Azure Databricks omvat een gestructureerde aanpak waarbij organisaties systematisch werken aan het inschakelen en configureren van uitgebreide logging voor alle Databricks-workspaces binnen hun Azure-omgeving. Het remediatieproces begint met een grondige inventarisatie van alle bestaande Databricks-workspaces om te bepalen welke workspaces momenteel diagnostische logging hebben ingeschakeld en welke workspaces nog configuratie vereisen. Deze inventarisatie is essentieel omdat organisaties vaak meerdere Databricks-workspaces hebben voor verschillende omgevingen zoals ontwikkeling, test en productie, en elk van deze workspaces moet individueel worden geconfigureerd voor diagnostische logging.

Het eerste kritieke aspect van het remediatieproces betreft de voorbereiding van de Log Analytics-infrastructuur die zal dienen als centrale verzamelplaats voor alle Databricks-logbestanden. Organisaties moeten bepalen of zij reeds beschikken over een bestaande centrale beveiligingslogging-workspace die kan worden gebruikt voor Databricks-logs, of dat een nieuwe dedicated workspace moet worden aangemaakt specifiek voor Databricks-logging. Voor organisaties met meerdere Databricks-workspaces of andere Azure-services die uitgebreide logging vereisen, wordt sterk aanbevolen om te werken met een centrale beveiligingslogging-workspace omdat dit kostenbesparend werkt, consistentie waarborgt tussen verschillende services en centrale beheerbaarheid mogelijk maakt. De centrale workspace moet worden geconfigureerd met passende dataretentie-instellingen op basis van operationele en compliance-vereisten, waarbij organisaties rekening moeten houden met minimaal 90 dagen voor operationele probleemoplossing, maar vaak 7 jaar of langer voor compliance-doeleinden onder frameworks zoals ISO 27001, NIS2 of BIO.

Zodra de Log Analytics-infrastructuur is voorbereid, begint het daadwerkelijke remediatieproces voor elke individuele Databricks-workspace. Het remediatieproces voor een enkele workspace begint met het verifiëren van de beschikbaarheid van de juiste toegangsrechten op de Databricks-workspace. De persoon of service principal die de remediatie uitvoert moet beschikken over Contributor-toegang op de Databricks-workspace zelf, evenals de rol 'Monitoring Contributor' op het niveau van de Databricks-workspace-resource. Deze rollen zijn essentieel omdat ze de benodigde rechten bieden om diagnostische instellingen aan te maken, te wijzigen en te configureren. Het is belangrijk om deze rollen toe te kennen volgens het principe van least privilege, waarbij alleen de minimale benodigde rechten worden verleend voor de duur van het remediatieproces, waarna de toegang kan worden ingeperkt indien de configuratie niet meer hoeft te worden gewijzigd.

Het volgende kritieke aspect betreft het configureren van de diagnostische instellingen op de Databricks-workspace. Deze configuratie wordt uitgevoerd via de Azure Portal, Azure PowerShell, Azure CLI of via Infrastructure as Code tools zoals Azure Resource Manager-templates of Terraform. De diagnostische instelling moet worden geconfigureerd met alle beschikbare logcategorieën om uitgebreide zichtbaarheid te waarborgen, inclusief Workspace logs voor configuratiewijzigingen en gebruikersbeheer, Cluster logs voor volledige levenscyclusevents, Jobs logs voor job-uitvoeringen, DBFS logs voor bestandssysteembewerkingen, Accounts logs voor authenticatiegebeurtenissen, en SSH logs voor directe cluster-toegang. De bestemming moet worden ingesteld op de voorbereide Log Analytics workspace, en optioneel kan een Storage Account worden geconfigureerd voor langetermijnarchivering wanneer compliance-vereisten langetermijnbewaring vereisen die kosteneffectiever kan worden gerealiseerd via blob storage in plaats van langetermijnretentie in Log Analytics.

Na het configureren van de diagnostische instellingen moet het remediatieproces worden afgerond met verificatie om te waarborgen dat de configuratie correct werkt en dat logs daadwerkelijk worden verzameld en opgeslagen. Deze verificatie wordt uitgevoerd door het uitvoeren van KQL-queries in Log Analytics om te controleren of Databricks-logs verschijnen in de verwachte logtabellen zoals DatabricksClusters, DatabricksJobs, DatabricksWorkspace, DatabricksAccounts en DatabricksDBFS. Het kan 5 tot 10 minuten duren voordat logopname begint na het configureren van de diagnostische instellingen, dus organisaties moeten deze vertraging in gedachten houden tijdens verificatie. Als logs niet verschijnen binnen 30 minuten na configuratie, moet het remediatieproces worden gereviewd om te identificeren waar het proces mogelijk is mislukt, bijvoorbeeld door problemen met toegangsrechten, onjuiste Log Analytics workspace-configuratie, of problemen met de diagnostische instelling zelf.

Voor organisaties die op grote schaal moeten remediëren met tientallen of honderden Databricks-workspaces, is geautomatiseerde remediatie sterk aanbevolen om tijd te besparen, consistentie te waarborgen en menselijke fouten te voorkomen. Geautomatiseerde remediatie kan worden gerealiseerd via PowerShell-scripts die systematisch door alle workspaces in een Azure-abonnement of resource group itereren, de diagnostische instellingen configureren voor elke workspace, en verificatie uitvoeren om te waarborgen dat de configuratie correct is geïmplementeerd. Deze geautomatiseerde aanpak maakt het mogelijk om honderden workspaces te remediëren binnen enkele uren in plaats van dagen of weken wanneer handmatige configuratie zou worden toegepast. Het is belangrijk om geautomatiseerde remediatie uit te voeren in een gefaseerde aanpak, beginnend met test- en ontwikkelingsomgevingen voordat productie-workspaces worden geremediateerd, om te waarborgen dat het proces correct werkt voordat het wordt toegepast op kritieke productie-omgevingen.

Na voltooiing van het remediatieproces voor alle Databricks-workspaces moeten organisaties een periodiek reviewproces implementeren om te waarborgen dat nieuwe workspaces automatisch worden geconfigureerd met diagnostische logging wanneer ze worden aangemaakt, en dat bestaande configuraties niet worden gewijzigd of verwijderd zonder autorisatie. Dit kan worden gerealiseerd via Azure Policy die automatisch diagnostische instellingen toepast op nieuwe Databricks-workspaces, of via regelmatige compliance-scans die controleren of alle workspaces correct zijn geconfigureerd. Doorlopende monitoring van de diagnostische logging-configuratie is essentieel om te waarborgen dat de beveiligings- en compliance-vereisten continu worden nageleefd, zelfs na initiële remediatie.

Compliance & Frameworks

• BIO: 12.04.01, 12.04.03 - Logregistratie en monitoring
• ISO 27001:2022: A.12.4.1, A.12.4.2, A.12.4.3 - Gebeurtenissen logging en audittrails, loggen bescherming, administrator logs
• NIS2: Artikel - Logging en monitoring van security gebeurtenissen

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

Diagnostische logging voor Azure Databricks is een absolute must-have beveiligingscontrole die uitgebreide audittrails creëert van alle Databricks-activiteiten door logs te streamen naar een Azure Log Analytics workspace. Logging legt kritieke gebeurtenissen vast: workspaceconfiguratiewijzigingen (beheerderwijzigingen, machtigingstoekenningen), clusterlevenscyclusgebeurtenissen (aanmaak-, start-, stop- en verwijderingsbewerkingen met gebruikersattributie), taakuitvoeringen (succesvolle en mislukte uitvoeringen, uitvoeringstijden, resourceverbruik), notebooktoegang en uitvoeringen (wie draaide welke code wanneer), DBFS-bestandssysteembewerkingen (gegevenslees- en schrijfbewerkingen voor gegevenstoegangstracking), authenticatiegebeurtenissen (inlogpogingen, token-generatie, SSO-flows, mislukte authenticatiepogingen), SSH-toegang tot clusters (debugging-sessies), en machtigingswijzigingen (rechtstoename-detectie). Deze uitgebreide logging maakt mogelijk: (1) Beveiligingsincidentdetectie via real-time waarschuwingen op ongeautoriseerde toegang, abnormale gegevensexfiltratiepatronen, rechtstoenamepogingen, (2) Forensisch onderzoek waarbij complete activiteitsreconstructie mogelijk is na datalekken of interne dreigingen, (3) Compliance-audittrails vereist onder ISO 27001, NIS2, BIO, AVG voor gereguleerde gegevensverwerking, (4) Operationele probleemoplossing voor mislukte taken, clusterproblemen, prestatieproblemen via Log Analytics-queries, (5) Gebruikersactiviteitsauditing voor governance en kostentoewijzing. Deze maatregel is verplicht voor alle Databricks-productieworkspaces (geen uitzonderingen), vereist voor compliance met vrijwel alle beveiligingsframeworks en regelgeving, en kritiek voor de beveiligingspostuur omdat zonder logging Databricks een beveiligingsblinde vlek is. Implementatie-inspanning: 5-7 uur voor uitgebreide setup inclusief Log Analytics workspace-configuratie, diagnostische instellingen voor alle workspaces, beveiligingswaarschuwingsregels, operationele dashboards en compliance-archiveringsautomatisering. Kosten: €15-60 per workspace per maand voor logopname en retentie (5-20 GB logs typisch). Doorlopende inspanning: 2 uur per kwartaal voor waarschuwingsregelafstemming en logretentiebeleidsbeoordelingen. De return on investment komt voort uit: vermeden beveiligingslekken door vroege detectie, succesvolle compliance-audits zonder bevindingen, verminderde MTTR (Mean Time To Resolution) voor operationele problemen via loggebaseerde probleemoplossing, en regelgevingsgoedkeuring voor gegevensverwerkingsactiviteiten.

• Implementatietijd: 3 uur
• FTE required: 0.03 FTE