Azure Opslag: Schakel In Opslag Logging (Blobs/Queues/Tables)

Opslaglogging biedt uitgebreide gegevenstoegang auditing die onmisbaar is voor moderne cloudbeveiliging. Het primaire doel is het detecteren van aanvallen zoals massale blob-downloads die wijzen op gegevensexfiltratie, het identificeren van onbevoegde toegang door verkeerde configuraties van anonieme toegang, en het herkennen van ransomware-aanvallen door massale blob-verwijderingen. Daarnaast is logging verplicht voor AVG-compliance waarbij gegevenstoegang moet worden gelogd, en essentieel voor forensisch onderzoek om te achterhalen wie gevoelige bestanden heeft gedownload of gewijzigd. Zonder adequate logging kunnen organisaties niet voldoen aan hun wettelijke verplichtingen en lopen zij het risico op aanzienlijke boetes en reputatieschade. Voor Nederlandse overheidsorganisaties is logging niet alleen een technische maatregel, maar een fundamentele vereiste voor verantwoorde gegevensverwerking en transparantie naar burgers toe.

Implementatie

Azure Storage Logging registreert alle kritieke operaties op opslagaccounts, waaronder lees-, schrijf- en verwijderoperaties op blobs, wachtrijen en tabellen. Elke logentry bevat uitgebreide metadata zoals het IP-adres van de aanvrager, de gebruikte authenticatiemethode, een nauwkeurige timestamp, en details over de uitgevoerde actie. Deze logs worden opgeslagen in een apart opslagaccount, gescheiden van de daadwerkelijke gegevens, wat zorgt voor integriteit en beveiliging van de auditlogboeken zelf. De loggingfunctionaliteit werkt op basis van diagnostische instellingen die kunnen worden geconfigureerd voor verschillende logcategorieën, waarbij organisaties kunnen kiezen welke operaties worden vastgelegd en waar de logs worden opgeslagen. Deze flexibiliteit stelt organisaties in staat om logging af te stemmen op hun specifieke beveiligings- en compliance-vereisten, terwijl zij tegelijkertijd de kosten kunnen beheersen door alleen relevante logdata vast te leggen.

Vereisten

Voor het implementeren van Azure Storage Logging zijn enkele basisvereisten noodzakelijk die organisaties moeten overwegen voordat zij beginnen met de configuratie. Ten eerste moet er een Azure Storage Account aanwezig zijn waarop de logging moet worden ingeschakeld. Dit opslagaccount kan blobs, wachtrijen, tabellen of een combinatie hiervan bevatten. Het is belangrijk te realiseren dat logging kan worden geconfigureerd voor elk type opslagservice afzonderlijk, wat flexibiliteit biedt voor organisaties die gefaseerd willen implementeren. Deze gefaseerde aanpak kan nuttig zijn voor organisaties die beginnen met het meest kritieke opslagaccount en vervolgens geleidelijk uitbreiden naar andere accounts. Tijdens de voorbereidingsfase moeten organisaties ook nadenken over welke logcategorieën zij willen vastleggen, aangezien dit invloed heeft op zowel de beveiligingsdekking als de kosten. Voor de meeste organisaties is het aanbevolen om alle drie de logcategorieën te selecteren (StorageRead, StorageWrite, StorageDelete) om volledige zichtbaarheid te krijgen op alle activiteiten.

Daarnaast is toegang tot diagnostische instellingen vereist. Deze instellingen vormen het mechanisme waarmee logging wordt geconfigureerd en doorgestuurd naar de gewenste bestemming. Organisaties moeten beschikken over de juiste Azure RBAC-machtigingen, specifiek de rol van Storage Account Contributor of een aangepaste rol met machtigingen voor het wijzigen van diagnostische instellingen. Het is belangrijk om te begrijpen dat deze machtigingen nodig zijn omdat diagnostische instellingen wijzigingen aanbrengen in de configuratie van het opslagaccount zelf. Voor het opslaan van de logs is een apart opslagaccount of een Log Analytics-workspace nodig, afhankelijk van de gekozen bestemming voor de logdata. Deze scheiding tussen de operationele data en de logdata is een belangrijk beveiligingsprincipe dat ervoor zorgt dat auditlogboeken niet kunnen worden gewijzigd of verwijderd door personen die toegang hebben tot de operationele data.

Technisch gezien vereist de implementatie geen aanvullende software of agents, aangezien Storage Logging een native Azure-functie is die volledig wordt beheerd door Microsoft. Dit betekent dat organisaties geen extra infrastructuur hoeven te onderhouden voor het verzamelen en opslaan van logs. De enige operationele vereiste is dat de organisatie beschikt over een monitoring- en alertingstrategie om de gegenereerde logs effectief te kunnen gebruiken voor beveiligingsdoeleinden. Deze strategie moet bepalen wie verantwoordelijk is voor het analyseren van de logs, hoe vaak analyses worden uitgevoerd, en welke alerts moeten worden geconfigureerd voor verdachte activiteiten.

Voor organisaties die werken met gevoelige gegevens of die moeten voldoen aan specifieke compliance-eisen, zijn er aanvullende overwegingen. Ten eerste moet worden bepaald hoe lang de logs moeten worden bewaard. Voor Nederlandse overheidsorganisaties kan dit variëren van enkele maanden tot meerdere jaren, afhankelijk van de aard van de gegevens en de toepasselijke wet- en regelgeving. Ten tweede moet worden overwogen waar de logs worden opgeslagen, met name in het kader van gegevenslocatievereisten. Voor sommige organisaties is het belangrijk dat logs binnen de Europese Unie worden opgeslagen, wat kan worden gegarandeerd door het selecteren van de juiste Azure-regio voor het opslagaccount of de Log Analytics-workspace.

Een andere belangrijke overweging betreft de kosten. Hoewel Storage Logging zelf geen extra kosten met zich meebrengt voor de functionaliteit, zijn er wel kosten verbonden aan het opslaan van de logs. Deze kosten zijn afhankelijk van de hoeveelheid logdata die wordt gegenereerd, wat op zijn beurt afhankelijk is van de activiteit op het opslagaccount. Organisaties moeten daarom een inschatting maken van de verwachte logvolumes en de bijbehorende kosten, en deze opnemen in hun budgetplanning. Voor grote organisaties met veel opslagaccounts kan het nuttig zijn om te beginnen met een pilot op een beperkt aantal accounts om de werkelijke kosten te kunnen inschatten voordat de implementatie wordt uitgerold naar alle accounts.

Tot slot moeten organisaties nadenken over de integratie van Storage Logging met hun bestaande beveiligingsinfrastructuur. Dit kan betekenen dat logs moeten worden doorgestuurd naar een Security Information and Event Management (SIEM) systeem, of dat er integratie nodig is met bestaande monitoring- en alertingtools. Deze integraties kunnen complex zijn en vereisen mogelijk aanvullende configuratie of aangepaste scripts. Het is daarom aanbevolen om deze integraties te plannen voordat de logging wordt geïmplementeerd, zodat de volledige beveiligingswaarde van de logs kan worden benut.

Implementatie

Gebruik PowerShell-script storage-logging-enabled.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van Azure Storage Logging kan op verschillende manieren worden uitgevoerd, waarbij de keuze afhankelijk is van de organisatorische voorkeur en de schaal van de implementatie. Voor geautomatiseerde implementatie op meerdere opslagaccounts is het gebruik van PowerShell-scripts de meest efficiënte aanpak, terwijl handmatige configuratie via de Azure Portal geschikt is voor ad-hoc implementaties of testomgevingen. Ongeacht de gekozen methode, is het belangrijk om vooraf een duidelijk plan te hebben voor welke opslagaccounts logging nodig hebben, welke logcategorieën moeten worden vastgelegd, en waar de logs moeten worden opgeslagen.

Bij implementatie via de Azure Portal navigeert u naar het betreffende opslagaccount en selecteert u de optie Diagnostische instellingen in het menu onder de sectie Monitoring. Vervolgens klikt u op Diagnostische instelling toevoegen om een nieuwe loggingconfiguratie te maken. In de configuratie selecteert u de relevante logcategorieën: StorageRead voor alle leesoperaties, StorageWrite voor schrijfoperaties, en StorageDelete voor verwijderoperaties. Het is aanbevolen om alle drie de categorieën te selecteren voor volledige zichtbaarheid op alle activiteiten. Na het selecteren van de categorieën moet u een bestemming kiezen voor de logs, waarbij u kunt kiezen tussen een Log Analytics-workspace, een opslagaccount, of een Event Hub. Voor de meeste organisaties is een Log Analytics-workspace de aanbevolen keuze vanwege de geavanceerde analysefunctionaliteiten en de mogelijkheid om eenvoudig alerts te configureren. Na het configureren van alle instellingen klikt u op Opslaan om de configuratie te activeren. Het is belangrijk om direct na de implementatie te verifiëren dat de logging daadwerkelijk werkt door een testoperatie uit te voeren en te controleren of deze wordt vastgelegd in de logs.

Voor de bestemming van de logs heeft u de keuze tussen een Log Analytics-workspace, een opslagaccount, of een Event Hub. Voor beveiligingsdoeleinden en compliance is een Log Analytics-workspace de aanbevolen optie, omdat dit geavanceerde query- en analysefunctionaliteiten biedt via KQL (Kusto Query Language). Daarnaast kunnen vanuit Log Analytics eenvoudig waarschuwingen worden geconfigureerd voor verdachte activiteiten zoals massale downloads of onverwachte verwijderingen. Een Log Analytics-workspace biedt ook de mogelijkheid om logs te correleren met andere Azure-services, wat waardevol kan zijn voor uitgebreide beveiligingsanalyses. Voor organisaties die moeten voldoen aan strikte compliance-eisen kan een Log Analytics-workspace ook worden geconfigureerd met langetermijnretentie, waardoor logs voor meerdere jaren kunnen worden bewaard zonder dat er een apart opslagaccount nodig is. Als alternatief kan een opslagaccount worden gebruikt voor langetermijnopslag van logs tegen lagere kosten, hoewel dit minder analysefunctionaliteiten biedt. Een Event Hub kan worden gebruikt voor real-time streaming van logs naar externe systemen zoals SIEM-oplossingen, wat vooral waardevol is voor organisaties die al een gevestigde SIEM-infrastructuur hebben.

Bij grootschalige implementaties over meerdere opslagaccounts is het gebruik van Infrastructure as Code (IaC) aanbevolen, bijvoorbeeld via Azure Resource Manager-templates of Terraform. Dit zorgt voor consistentie, reproduceerbaarheid en versiebeheer van de loggingconfiguratie. De PowerShell-script die bij dit artikel hoort, biedt een geautomatiseerde oplossing die alle benodigde stappen uitvoert en geschikt is voor zowel eenmalige implementaties als herhaalde controles en updates. Het script kan worden uitgevoerd tegen een specifiek opslagaccount, een resourcegroep, of een volledig abonnement, wat het ideaal maakt voor organisaties met veel opslagaccounts.

Voor organisaties die gebruik maken van Azure Policy kunnen diagnostische instellingen ook worden geïmplementeerd via policy-definities. Dit zorgt ervoor dat alle nieuwe opslagaccounts automatisch logging hebben ingeschakeld, en dat bestaande accounts kunnen worden gecontroleerd en indien nodig worden bijgewerkt. Deze aanpak is bijzonder waardevol voor organisaties die willen zorgen dat logging altijd is ingeschakeld, ongeacht wie het opslagaccount aanmaakt. Azure Policy kan ook worden gebruikt om te controleren of logging correct is geconfigureerd, en om automatische remediatie uit te voeren wanneer logging ontbreekt of onjuist is geconfigureerd.

Na de implementatie is het belangrijk om te verifiëren dat de logging daadwerkelijk werkt. Dit kan worden gedaan door een testoperatie uit te voeren op het opslagaccount, bijvoorbeeld door een blob te lezen, te schrijven of te verwijderen, en vervolgens te controleren of deze operatie wordt vastgelegd in de logs. Voor Log Analytics-workspaces kan dit worden gedaan door een KQL-query uit te voeren om te zoeken naar recente logentries. Voor opslagaccounts kan dit worden gedaan door de logbestanden in het opslagaccount te bekijken. Deze verificatie moet worden uitgevoerd binnen enkele minuten na de implementatie, en vervolgens periodiek om te zorgen dat logging blijft werken.

Een belangrijke overweging bij de implementatie is de retentieperiode voor de logs. Standaard worden logs opgeslagen zolang het opslagaccount of de Log Analytics-workspace bestaat, maar organisaties kunnen kiezen voor een kortere retentieperiode om kosten te besparen. Het is echter belangrijk om te realiseren dat kortere retentieperioden kunnen leiden tot het verlies van waardevolle auditinformatie, wat problematisch kan zijn voor compliance-doeleinden of forensisch onderzoek. Organisaties moeten daarom een balans vinden tussen kosten en compliance-vereisten bij het bepalen van de retentieperiode.

Compliance

Azure Storage Logging is een verplichte beveiligingsmaatregel volgens meerdere belangrijke compliance-frameworks en normen die relevant zijn voor Nederlandse overheidsorganisaties. De implementatie van logging is niet alleen een best practice, maar vaak een expliciete vereiste voor het voldoen aan wettelijke en normatieve eisen. Het ontbreken van adequate logging kan leiden tot ernstige gevolgen, waaronder boetes, reputatieschade, en het verlies van vertrouwen van burgers en stakeholders. Daarom is het essentieel dat organisaties begrijpen welke compliance-vereisten van toepassing zijn en hoe Storage Logging helpt om aan deze vereisten te voldoen.

Volgens de CIS Azure Benchmark Level 2 is het inschakelen van Storage Logging een essentiële controle voor het monitoren van gegevenstoegang. Deze benchmark wordt wereldwijd erkend als de standaard voor cloudbeveiliging en is vaak een vereiste voor organisaties die werken met gevoelige gegevens. Specifiek vereist controle 3.6 van de CIS Azure Benchmark dat diagnostische logs zijn ingeschakeld voor alle relevante services, waaronder Azure Storage. De Nederlandse Baseline Informatiebeveiliging Overheid (BIO) vereist in norm 12.04 dat alle toegang tot gegevens wordt gelogd en gemonitord, wat direct wordt ondersteund door Storage Logging. Deze norm stelt dat organisaties moeten kunnen aantonen wie toegang heeft gehad tot welke gegevens, wanneer deze toegang heeft plaatsgevonden, en wat de reden was voor de toegang.

Voor de Algemene Verordening Gegevensbescherming (AVG) is artikel 30 van cruciaal belang, dat vereist dat organisaties een register bijhouden van verwerkingsactiviteiten. Storage Logging voorziet in deze vereiste door alle toegang tot persoonsgegevens vast te leggen, inclusief wie, wanneer en hoe de gegevens zijn benaderd. Dit is essentieel voor het kunnen voldoen aan verzoeken van betrokkenen en voor het aantonen van compliance tijdens audits. Daarnaast vereist artikel 32 van de AVG dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beveiligen, waarbij logging een belangrijke maatregel is voor het detecteren van onbevoegde toegang of datalekken. Artikel 33 vereist dat organisaties datalekken melden aan de Autoriteit Persoonsgegevens, waarbij logging essentieel is om te kunnen bepalen wat er is gebeurd en welke gegevens mogelijk zijn gecompromitteerd.

De ISO 27001-norm, specifiek controle A.12.4.1, vereist logging en monitoring van alle systemen om beveiligingsincidenten te kunnen detecteren en onderzoeken. Storage Logging vormt een directe implementatie van deze vereiste voor Azure Storage-omgevingen. Voor Nederlandse overheidsorganisaties die moeten voldoen aan de Baseline Informatiebeveiliging Rijksdienst (BIR) zijn vergelijkbare eisen van toepassing, waarbij logging van gegevenstoegang een fundamentele beveiligingsmaatregel is. De BIR vereist dat organisaties kunnen aantonen dat zij adequate beveiligingsmaatregelen hebben genomen, waarbij logging een belangrijk onderdeel is van deze maatregelen.

Naast deze algemene normen zijn er ook sectorspecifieke vereisten die van toepassing kunnen zijn. Voor organisaties in de gezondheidszorg kunnen bijvoorbeeld aanvullende eisen gelden voor het loggen van toegang tot medische gegevens. Voor financiële instellingen kunnen er specifieke eisen zijn voor het loggen van transacties en toegang tot financiële gegevens. Het is daarom belangrijk dat organisaties zich bewust zijn van alle toepasselijke normen en vereisten, en dat zij ervoor zorgen dat Storage Logging is geconfigureerd om aan al deze vereisten te voldoen.

Het niet implementeren van Storage Logging kan leiden tot non-compliance met deze normen, wat kan resulteren in boetes, reputatieschade, en het verlies van vertrouwen van burgers en stakeholders. Voor de AVG kunnen boetes oplopen tot 20 miljoen euro of 4% van de wereldwijde jaaromzet, wat voor grote organisaties aanzienlijke bedragen kunnen zijn. Daarnaast kan non-compliance leiden tot het verlies van contracten of het niet kunnen deelnemen aan aanbestedingen, wat voor overheidsorganisaties ernstige gevolgen kan hebben. Daarom is het implementeren van Storage Logging niet alleen een technische keuze, maar een verplichting voor organisaties die serieus omgaan met compliance en informatiebeveiliging.

Tijdens audits en compliance-controles zal worden gevraagd om bewijs te leveren dat logging correct is geconfigureerd en actief is. Dit betekent dat organisaties niet alleen logging moeten implementeren, maar ook moeten kunnen aantonen dat logging werkt en dat logs worden bewaard voor de vereiste periode. Het is daarom aanbevolen om regelmatig te controleren dat logging actief is, en om documentatie bij te houden die aantoont hoe logging is geconfigureerd en hoe logs worden beheerd. Deze documentatie kan waardevol zijn tijdens audits en kan helpen om te demonstreren dat de organisatie serieus omgaat met compliance en informatiebeveiliging.

Monitoring

Gebruik PowerShell-script storage-logging-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van Azure Storage Logging is een continu proces dat ervoor zorgt dat logging correct is geconfigureerd en actief blijft. Regelmatige controles zijn essentieel omdat configuratiewijzigingen, updates of menselijke fouten kunnen leiden tot het onbedoeld uitschakelen van logging, wat een kritieke beveiligingsgap creëert. Zonder adequate monitoring kan een organisatie onbewust opereren zonder logging, wat betekent dat belangrijke beveiligingsincidenten mogelijk niet worden gedetecteerd of onderzocht. Daarom moet monitoring worden gezien als een integraal onderdeel van de logging-implementatie, niet als een optionele toevoeging.

De monitoring moet controleren of diagnostische instellingen actief zijn voor alle relevante logcategorieën (StorageRead, StorageWrite, StorageDelete) en of de logs daadwerkelijk worden doorgestuurd naar de geconfigureerde bestemming. Daarnaast moet worden geverifieerd dat de bestemming zelf toegankelijk is en voldoende capaciteit heeft om de logs op te slaan. Het is aanbevolen om deze controles minimaal wekelijks uit te voeren, of vaker voor kritieke opslagaccounts met gevoelige gegevens. Voor zeer kritieke accounts kan dagelijkse monitoring worden overwogen, vooral in omgevingen waar er een hoog risico is op beveiligingsincidenten of waar compliance-vereisten zeer strikt zijn.

Naast het controleren van de configuratie is het analyseren van de gegenereerde logs zelf cruciaal voor beveiligingsdoeleinden. Beveiligingsteams moeten regelmatig KQL-queries uitvoeren om verdachte patronen te detecteren, zoals ongebruikelijk hoge aantallen leesoperaties van een specifiek IP-adres, verwijderoperaties buiten normale werkuren, of toegang vanaf onbekende locaties. Deze analyses kunnen handmatig worden uitgevoerd of geautomatiseerd via Azure Monitor waarschuwingen. Voor effectieve beveiligingsmonitoring is het belangrijk om baseline-patroon te begrijpen, zodat afwijkingen kunnen worden geïdentificeerd. Dit betekent dat beveiligingsteams moeten weten wat normale activiteit is voor elk opslagaccount, zodat zij ongebruikelijke activiteit kunnen herkennen. Het opstellen van baseline-patroon vereist dat beveiligingsteams gedurende een periode van enkele weken of maanden de normale activiteit observeren en documenteren, zodat zij vervolgens kunnen identificeren wanneer er afwijkingen optreden die mogelijk wijzen op beveiligingsincidenten.

Het PowerShell-script dat bij dit artikel hoort, biedt geautomatiseerde monitoringfunctionaliteit die de status van Storage Logging controleert voor alle opslagaccounts in een abonnement of resourcegroep. Dit script kan worden geïntegreerd in bestaande monitoring- en alertingworkflows, bijvoorbeeld via Azure Automation of als onderdeel van een grotere compliance-check. Voor organisaties met veel opslagaccounts is deze automatisering onmisbaar om consistentie en volledigheid te waarborgen. Het script kan worden geconfigureerd om automatisch alerts te genereren wanneer logging ontbreekt of onjuist is geconfigureerd, wat zorgt voor snelle detectie van problemen.

Een belangrijk aspect van monitoring is het bijhouden van trends en statistieken over logvolumes en activiteit. Dit kan helpen om te identificeren wanneer er ongebruikelijke activiteit plaatsvindt, zelfs als deze activiteit op zichzelf niet verdacht lijkt. Bijvoorbeeld, een plotselinge toename in het aantal leesoperaties kan wijzen op een data-exfiltratiepoging, zelfs als elke individuele operatie legitiem lijkt. Door trends te monitoren kunnen security teams dergelijke patronen vroegtijdig identificeren en actie ondernemen voordat er schade wordt aangericht.

Voor organisaties die gebruik maken van SIEM-systemen is het belangrijk om te zorgen dat Storage Logs correct worden doorgestuurd en geïndexeerd in het SIEM-systeem. Dit kan betekenen dat logs moeten worden getransformeerd of gefilterd voordat zij naar het SIEM worden gestuurd, om ervoor te zorgen dat alleen relevante informatie wordt opgeslagen. Daarnaast moet worden geverifieerd dat het SIEM-systeem de logs correct kan parseren en analyseren, zodat beveiligingsteams effectief gebruik kunnen maken van de logdata voor beveiligingsdoeleinden. De integratie met SIEM-systemen vereist vaak aanvullende configuratie, zoals het instellen van Event Hubs als tussenlaag tussen Azure Storage en het SIEM-systeem, of het gebruik van connectors die specifiek zijn ontworpen voor Azure Storage Logs. Het is belangrijk om deze integratie te testen voordat deze in productie wordt genomen, om ervoor te zorgen dat alle relevante logs correct worden doorgestuurd en dat er geen belangrijke informatie verloren gaat tijdens het transport.

Tot slot moet monitoring ook aandacht besteden aan de kwaliteit en volledigheid van de logs. Dit betekent dat moet worden gecontroleerd of alle verwachte informatie aanwezig is in de logs, zoals IP-adressen, timestamps, en gebruikersidentiteiten. Als belangrijke informatie ontbreekt, kan dit betekenen dat de loggingconfiguratie onvolledig is of dat er een probleem is met de loggeneratie. Daarnaast moet worden gecontroleerd of logs worden gegenereerd voor alle verwachte activiteiten, en of er geen gaps zijn in de logdata die kunnen wijzen op problemen met de loggingconfiguratie of op beveiligingsincidenten waarbij logging mogelijk is uitgeschakeld.

Remediatie

Gebruik PowerShell-script storage-logging-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring aangeeft dat Storage Logging niet is geconfigureerd of niet actief is, moet onmiddellijk remediatie worden uitgevoerd om de beveiligingsgap te sluiten. De remediatieprocedure is afhankelijk van de specifieke situatie: ontbrekende configuratie, gedeeltelijk geconfigureerde logging, of een configuratie die niet meer actief is. Het is belangrijk om te realiseren dat elke periode zonder logging een periode is waarin beveiligingsincidenten mogelijk niet worden gedetecteerd, wat betekent dat remediatie zo snel mogelijk moet worden uitgevoerd. Voor kritieke opslagaccounts met gevoelige gegevens moet remediatie binnen enkele uren worden uitgevoerd, terwijl voor minder kritieke accounts remediatie binnen enkele dagen acceptabel kan zijn.

Voor opslagaccounts waar helemaal geen logging is geconfigureerd, moet een volledige diagnostische instelling worden aangemaakt met alle drie de logcategorieën (StorageRead, StorageWrite, StorageDelete). Het is belangrijk om tijdens de remediatie te controleren of er een geschikte bestemming beschikbaar is, zoals een Log Analytics-workspace, en of deze voldoende capaciteit heeft. Als er geen bestemming beschikbaar is, moet deze eerst worden aangemaakt voordat de logging kan worden geconfigureerd. Tijdens het aanmaken van de bestemming moet worden overwogen welke regio moet worden gebruikt, vooral als er gegevenslocatievereisten zijn. Daarnaast moet worden gecontroleerd of de bestemming voldoet aan alle compliance-vereisten, zoals encryptie en toegangscontrole.

In gevallen waar logging gedeeltelijk is geconfigureerd, bijvoorbeeld alleen voor StorageRead maar niet voor StorageWrite en StorageDelete, moet de bestaande diagnostische instelling worden bijgewerkt om alle categorieën te omvatten. Dit kan via de Azure Portal door de bestaande instelling te bewerken, of programmatisch via PowerShell of Azure CLI. Het is aanbevolen om na de remediatie direct te verifiëren dat de logs daadwerkelijk worden gegenereerd en doorgestuurd. Deze verificatie moet worden uitgevoerd door een testoperatie uit te voeren en te controleren of deze wordt vastgelegd in de logs. Als de verificatie faalt, moet de configuratie opnieuw worden gecontroleerd en indien nodig worden gecorrigeerd.

Het geautomatiseerde remediatiescript dat bij dit artikel hoort, voert alle benodigde stappen uit om Storage Logging correct te configureren volgens de best practices. Het script controleert eerst de huidige status, identificeert wat ontbreekt, en voert vervolgens de benodigde configuratiewijzigingen door. Na de remediatie verifieert het script dat de configuratie correct is toegepast en dat logging actief is. Voor organisaties met veel opslagaccounts kan dit script worden uitgevoerd als onderdeel van een geautomatiseerde compliance-workflow. Het script kan ook worden geconfigureerd om automatisch te worden uitgevoerd wanneer monitoring aangeeft dat logging ontbreekt, wat zorgt voor snelle remediatie zonder menselijke tussenkomst.

Na remediatie is het belangrijk om te onderzoeken waarom de logging niet correct was geconfigureerd. Was dit een configuratiefout, een onbedoelde wijziging, of een bewuste actie? Dit helpt om toekomstige incidenten te voorkomen en om eventuele beveiligingsincidenten te identificeren waarbij logging mogelijk opzettelijk is uitgeschakeld om activiteiten te verbergen. Als de logging is uitgeschakeld door een onbevoegde persoon, kan dit wijzen op een beveiligingsincident waarbij een aanvaller probeert zijn activiteiten te verbergen. In dergelijke gevallen moet een volledig forensisch onderzoek worden uitgevoerd om te bepalen wat er is gebeurd en welke gegevens mogelijk zijn gecompromitteerd.

Voor organisaties die gebruik maken van Azure Policy kan automatische remediatie worden geconfigureerd, wat ervoor zorgt dat logging automatisch wordt ingeschakeld wanneer monitoring aangeeft dat logging ontbreekt. Deze automatische remediatie kan waardevol zijn voor het snel oplossen van problemen, maar het is belangrijk om te realiseren dat automatische remediatie niet altijd geschikt is. In sommige gevallen kan het beter zijn om eerst te onderzoeken waarom logging ontbreekt voordat remediatie wordt uitgevoerd, vooral als er aanwijzingen zijn dat logging mogelijk opzettelijk is uitgeschakeld. Daarom moet automatische remediatie worden geconfigureerd met de juiste waarschuwingen en escalatieprocedures.

Na succesvolle remediatie moet worden gedocumenteerd wat er is gedaan, wanneer de remediatie is uitgevoerd, en wie verantwoordelijk was voor de remediatie. Deze documentatie kan waardevol zijn voor compliance-doeleinden en kan helpen om te demonstreren dat de organisatie proactief omgaat met beveiligingsproblemen. Daarnaast moet worden overwogen of er wijzigingen nodig zijn in processen of procedures om te voorkomen dat hetzelfde probleem opnieuw optreedt. Dit kan betekenen dat er aanvullende training nodig is voor personeel, of dat er wijzigingen nodig zijn in de configuratieprocedures om te zorgen dat logging altijd wordt ingeschakeld bij het aanmaken van nieuwe opslagaccounts.

In gevallen waar remediatie niet onmiddellijk kan worden uitgevoerd, bijvoorbeeld omdat er technische problemen zijn of omdat er goedkeuring nodig is van management, moet een tijdelijke compenserende controle worden geïmplementeerd. Dit kan betekenen dat er extra monitoring wordt ingesteld, of dat er tijdelijke beperkingen worden opgelegd aan toegang tot het opslagaccount totdat logging is hersteld. Deze compenserende controles moeten worden gedocumenteerd en moeten worden verwijderd zodra de logging is hersteld. Het is belangrijk om te realiseren dat compenserende controles geen vervanging zijn voor logging, maar alleen een tijdelijke maatregel totdat logging kan worden hersteld.

Compliance & Frameworks

• CIS M365: Control Azure opslag - Logging (L2) -
• BIO: 12.04.01 -
• ISO 27001:2022: A.12.4.1 -

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

Azure Storage Logging is een verplichte beveiligingsmaatregel voor het monitoren van alle toegang tot opslagaccounts. Zie storage-account-logging-enabled.json voor volledige implementatie-instructies. Deze maatregel is verplicht volgens CIS Azure Benchmark 3.6 en essentieel voor AVG-compliance en detectie van gegevensexfiltratie. Zonder adequate logging kunnen organisaties niet voldoen aan hun wettelijke verplichtingen en lopen zij het risico op aanzienlijke boetes en reputatieschade.

• Implementatietijd: 4 uur
• FTE required: 0.02 FTE