Binnen moderne security operations geldt een eenvoudige stelregel: wat je niet logt, kun je niet onderzoeken en ook niet verantwoorden. Zonder betrouwbare loggegevens blijft bij een beveiligingsincident vaak onduidelijk wat er precies is gebeurd, welke systemen betrokken waren en of er persoonsgegevens zijn geraakt. Voor Nederlandse overheidsorganisaties gaat het daarbij niet alleen om technische nieuwsgierigheid, maar om harde verplichtingen vanuit de Baseline Informatiebeveiliging Overheid (BIO), NIS2, de AVG en de Archiefwet. Deze kaders verwachten dat organisaties kunnen aantonen dat maatregelen daadwerkelijk worden toegepast, dat afwijkingen tijdig worden ontdekt en dat er achteraf een compleet spoor van gebeurtenissen beschikbaar is.
Tegelijkertijd is onbeperkt alles loggen geen realistische optie. Ongefilterde logstromen leiden al snel tot enorme datavolumes, stijgende kosten en een overvloed aan ruis waardoor relevante signalen verdrinken in routine‑meldingen. Aan de andere kant levert te weinig logging gaten op in het forensische beeld en ontstaan discussies met auditors omdat cruciale gebeurtenissen niet zijn vastgelegd. De kern van een volwassen loggingstrategie is het vinden van het juiste midden: precies voldoende detail om incidenten te reconstrueren en naleving te bewijzen, zonder dat de organisatie wordt overspoeld door onbruikbare data.
Voor een publieke organisatie betekent dit dat juridische, organisatorische en technische disciplines samen moeten optrekken. Juristen en privacy‑experts bepalen welke gegevens minimaal en maximaal mogen worden vastgelegd en hoe lang zij bewaard mogen blijven. CISO‑office en informatiebeveiligingsadviseurs vertalen normen als de BIO en NIS2 naar concrete logbronnen en detectiescenario’s. Technische teams ontwerpen de architectuur rond Azure Monitor, Log Analytics en Microsoft Sentinel, inclusief koppelingen met on‑premises systemen en andere cloudomgevingen. Bestuurders en proceseigenaren zorgen tenslotte voor prioritering en budget, zodat logging geen vrijblijvend bijproduct is maar een expliciet onderdeel van de beveiligingsstrategie.
Deze tutorial biedt een praktische routekaart voor het opzetten of aanscherpen van zo’n strategie. We starten met het in kaart brengen van de wettelijke eisen en leggen uit hoe je die vertaalt naar concrete logbronnen en bewaartermijnen. Vervolgens bekijken we hoe een centrale logarchitectuur met Log Analytics, Sentinel en aanvullende Azure‑diensten kan worden ingericht, inclusief keuzes rond filtering, verrijking en opslagniveaus. Tot slot laten we zien hoe je dezelfde loggegevens inzet voor geautomatiseerde compliance‑rapportage, zodat audits minder beslag leggen op de organisatie en bestuurders continu inzicht houden in de effectiviteit van de getroffen maatregelen. De voorbeelden sluiten aan bij de Nederlandse Baseline voor Veilige Cloud, maar de onderliggende principes zijn ook toepasbaar in andere omgevingen.
Deze tutorial laat stap voor stap zien hoe je van losse logbestanden toewerkt naar een samenhangende observability‑architectuur. Je ontdekt hoe je de juiste logbronnen selecteert voor normenkaders als BIO, NIS2 en AVG, hoe je bewaartermijnen juridisch onderbouwd vastlegt, hoe je logstromen centraal verzamelt in een SIEM‑oplossing zoals Microsoft Sentinel en hoe je dashboards en rapportages opbouwt die voor auditors direct als bewijs bruikbaar zijn. Daarbij is er nadrukkelijk aandacht voor integriteit en bescherming van loggegevens zelf, zodat logboeken niet alleen informatief zijn maar ook juridisch standhouden.
Ontwerp bewaartermijnen nooit als een puur technische instelling, maar als een expliciet juridisch besluit. Een waterschap dat alle logbestanden standaard negentig dagen bewaart omdat dit “praktisch” leek, kwam tijdens een AVG‑onderzoek tot de conclusie dat men voor bepaalde processen minimaal een jaar aan loggegevens nodig had om verwerkingen te kunnen verantwoorden, terwijl andere categorieën juist na dertig dagen hadden moeten worden verwijderd. De organisatie moest in allerijl retentie‑instellingen aanpassen, oude datasets selectief wissen en aanvullende maatregelen treffen om vertrouwen van de toezichthouder te herstellen. Door vooraf samen met privacy‑juristen, informatiebeveiligingsadviseurs en archivarissen per logcategorie vast te leggen wat minimaal vereist en maximaal toegestaan is, voorkom je dit soort hersteloperaties. Retentie‑ontwerp is daarmee een integraal onderdeel van governance en niet slechts een schuifje in de techniek.
Regelgevende eisen vertalen naar concrete logging
Voor Nederlandse overheidsorganisaties is logging geen technisch bijproduct, maar een direct gevolg van wettelijke verplichtingen. Elke norm kijkt met een eigen bril naar hetzelfde vraagstuk: kan de organisatie laten zien dat zij haar informatievoorziening beheerst en dat beveiligingsmaatregelen daadwerkelijk werken? De Baseline Informatiebeveiliging Overheid benadrukt vooral de volledigheid en betrouwbaarheid van beveiligingsrelevante gebeurtenissen. NIS2 legt de nadruk op vroegtijdige detectie van incidenten en adequate opvolging. De AVG richt zich op transparantie rond de verwerking van persoonsgegevens en op de mogelijkheid om misbruik of ongeoorloofde toegang achteraf aan te tonen. De Archiefwet vraagt tenslotte om duurzame vastlegging van bepaalde gebeurtenissen als onderdeel van het openbaar bestuur. Wie deze kaders naast elkaar legt, ziet dat een doordachte loggingstrategie in feite een juridische vertaalslag is: van abstracte normen naar concrete logbronnen, bewaartermijnen en verantwoordelijkheden.
Een goede aanpak begint daarom niet in de techniek, maar bij een gezamenlijke sessie van juristen, privacy‑experts, informatiebeveiligers en archivarissen. Zij inventariseren per norm welke vragen toezichthouders en auditors in de praktijk stellen. Denk aan vragen als: wie heeft toegang gehad tot deze gegevens? Welke beheerder heeft dit beveiligingsprofiel aangepast? Hoe lang werden ongebruikelijke aanmeldpogingen genegeerd? Welke stappen zijn gezet na een incidentmelding? Voor elk van deze vragen wordt vervolgens bepaald welke gebeurtenissen minimaal moeten worden vastgelegd om een overtuigend antwoord te kunnen geven. Pas daarna komt de vraag in beeld welke platformen die gegevens kunnen leveren, zoals Azure AD, Microsoft 365 auditlogs, netwerkapparatuur, applicatielogs of SIEM‑gebaseerde correlatiegegevens.
In een Microsoft‑gebaseerde omgeving ontstaat zo een set van kernlogbronnen die vrijwel altijd nodig is: aanmeldings‑ en auditlogboeken in Microsoft Entra ID, toegangslogs voor SharePoint en OneDrive, activiteitenlogboeken voor Exchange en Teams, en beveiligingssignalen uit Defender‑producten. Deze bronnen leveren samen het verhaal van wie wat heeft gedaan, met welke rechten, vanaf welke locatie en in welke context. Voor sectoren die onder NIS2 vallen, komen daar vaak nog netwerk‑ en firewall‑logs bij, evenals gegevens uit operationele systemen of OT‑omgevingen. De kunst is om per bron heel expliciet vast te leggen welk normenkader ermee wordt ondersteund, zodat zichtbaar is waarom een logstroom bestaat en welke consequentie het heeft als die stroom wegvalt.
Minstens zo belangrijk is de vraag hoe lang loggegevens beschikbaar moeten blijven. De reflex om “alles zeven jaar te bewaren” is zelden verstandig en meestal juridisch niet houdbaar. Voor sommige processen is een retentie van enkele weken voldoende, bijvoorbeeld bij technische diagnostische logs die geen rol spelen bij verantwoording of opsporing. Voor andere categorieën – zoals toegangslogs rond kritieke persoonsgegevens of logboeken van beheerdersactiviteiten – kan een retentie van één tot meerdere jaren noodzakelijk zijn om incidenten te kunnen onderzoeken en om invulling te geven aan de verantwoordingsplicht. Archiefwaardige loggegevens, bijvoorbeeld rond crisisbesluitvorming of grootschalige incidenten, vallen weer onder aparte archiefselectielijsten en moeten duurzaam worden bewaard. Door per categorie expliciet te documenteren welke wet of norm de gekozen bewaartermijn draagt, ontstaat een verdedigbaar kader dat overeind blijft tijdens audits.
Daarnaast speelt dataminimalisatie een belangrijke rol. Het loggen van meer gegevens dan nodig kan in strijd komen met de AVG, zeker wanneer logs gedetailleerde persoonsgegevens bevatten zoals volledige IP‑adressen, inhoud van zoekopdrachten of details over geraadpleegde dossiers. Organisaties doen er daarom goed aan om bewust te kiezen welke velden worden opgenomen, welke worden geanonimiseerd of gepseudonimiseerd en welke alleen onder strikte voorwaarden beschikbaar zijn. Dit vraagt om nauwe samenwerking tussen beveiliging en privacy: beide willen inzicht, maar binnen grenzen die proportioneel en uitlegbaar zijn.
Ten slotte moeten internationale gegevensstromen en clouddiensten nadrukkelijk worden meegenomen in de loggingstrategie. Wanneer loggegevens worden opgeslagen in een publieke cloud of worden verwerkt door een externe dienstverlener, willen toezichthouders zien dat de organisatie de controle behoudt. Dat betekent dat helder moet zijn in welke regio logdata wordt bewaard, onder welk contractueel regime dit valt en welke partijen toegang kunnen krijgen. Door deze keuzes vast te leggen in zowel verwerkingsregisters als in documentatie rond de logarchitectuur, ontstaat een sluitend beeld: niet alleen wat er wordt gelogd, maar ook waar, hoe lang, onder welke voorwaarden en met welk doel. Zo wordt logging het sluitstuk van aantoonbare governance binnen de Nederlandse Baseline voor Veilige Cloud.
Logaggregatie en centrale intelligentie
Wanneer eenmaal duidelijk is welke gebeurtenissen moeten worden vastgelegd, ontstaat de volgende uitdaging: hoe verzamel je al die gegevens op een manier die beheersbaar, betaalbaar en betrouwbaar blijft? In een gemiddelde overheidsorganisatie komen logstromen uit vele richtingen. Azure‑diensten registreren hun eigen diagnostische informatie, Microsoft 365 genereert aanmeldings‑ en auditlogboeken, on‑premises domeincontrollers, firewalls en routers schrijven weer andere logs en maatwerkapplicaties voegen daar hun eigen formaat aan toe. Wie al deze bronnen los van elkaar laat loggen zonder centrale regie, creëert een landschap waarin niemand het totaaloverzicht heeft en waarin belangrijke verbanden onzichtbaar blijven. Een centrale logarchitectuur is daarom geen luxe, maar een voorwaarde om van ruwe data bruikbare informatie te maken.
In een Microsoft‑georiënteerde omgeving vormt een Log Analytics‑workspace in Azure vaak het hart van die architectuur. Deze omgeving fungeert als schakelpunt waar logstromen uit de cloud, uit Microsoft 365 en uit lokale infrastructuur samenkomen. Azure‑resources zoals Key Vault, App Service en SQL‑databases sturen hun diagnostische logs naar de workspace, terwijl Microsoft 365 via ingebouwde connectors audit‑ en activiteitlogboeken kan aanleveren. Lokale servers en netwerkapparatuur sturen hun gebeurtenissen via agents of via Syslog‑koppelingen. Door al deze stromen te bundelen, ontstaat één platform waarop security‑teams en auditors kunnen zoeken, filteren en analyseren zonder steeds tussen verschillende tools te hoeven wisselen.
De manier waarop loggegevens worden aangeleverd, heeft grote invloed op prestaties en kosten. Het is zelden nodig om elk detail van elk systeem in realtime door te sturen naar de cloud. Vaak is het efficiënter om dicht bij de bron al een selectie te maken van relevante gebeurtenissen en om gegevens in kleine batches te verzenden. Dat vermindert netwerkbelasting en voorkomt dat triviale debug‑meldingen evenveel ruimte innemen als kritieke beveiligingsgebeurtenissen. Door samen met ontwikkelteams, beheerders en security‑analisten te bepalen welke gebeurtenissen echt nodig zijn, ontstaat een stroom die rijk genoeg is voor analyse, maar slank genoeg om beheersbaar te blijven.
Zodra logs de centrale omgeving bereiken, is structurering de belangrijkste stap. Ruwe logregels zijn vaak moeilijk te lezen en bevatten velden die tussen systemen net anders heten. Door gebruik te maken van parsingregels, gestandaardiseerde veldnamen en verrijking met context uit bijvoorbeeld een configuration management database of een autorisatiematrix, veranderen losse regels in een samenhangend verhaal. In Azure gebeurt dit onder andere met Data Collection Rules, Kusto‑query’s en serverless functies die inkomende gegevens transformeren. Op dat niveau wordt vastgelegd wat een “beheeractie”, een “kritieke fout” of een “mislukte aanmelding” precies betekent, zodat analyse en rapportage over afdelingen en systemen heen mogelijk wordt.
Een volwassen logarchitectuur maakt daarnaast gebruik van verschillende opslagniveaus. Recente, beveiligingsrelevante gegevens moeten snel doorzoekbaar zijn, bijvoorbeeld voor het Security Operations Center dat verdachte patronen wil onderzoeken. Oudere gegevens kunnen worden verplaatst naar goedkopere opslag, waar zij nog steeds beschikbaar zijn voor forensisch onderzoek of audits, maar niet langer dagelijks worden geraadpleegd. Bepaalde categorieën, zoals puur technische diagnostische logs, kunnen na een korte periode zelfs volledig worden verwijderd als zij geen juridische of operationele waarde meer hebben. Door deze gelaagde aanpak sluiten opslagkosten en prestaties beter aan bij het daadwerkelijke gebruik van de data.
Centrale aggregatie brengt ook nieuwe beveiligingsrisico’s met zich mee: wie toegang heeft tot het logplatform, ziet vaak meer dan in welk afzonderlijk bronsysteem dan ook. Rollen en rechten moeten daarom zorgvuldig worden ingericht. Beheerders die de omgeving configureren, mogen niet automatisch ook alle inhoudelijke loggegevens kunnen inzien, terwijl auditors alleen toegang moeten krijgen tot de datasets die binnen hun opdracht vallen. Wijzigingen in de logconfiguratie zelf – zoals het aanpassen van retentie‑instellingen of het uitschakelen van een logbron – worden opnieuw gelogd en gemonitord. Door bovendien gebruik te maken van versleuteling, append‑only opslag en eventueel extra integriteitscontroles zoals hash‑waarden, kan een organisatie aantonen dat loggegevens niet stilzwijgend zijn aangepast of verwijderd. Daarmee groeit de centrale logarchitectuur uit tot een betrouwbaar fundament onder zowel security‑operaties als compliance‑verantwoording.
Geautomatiseerde compliance‑rapportage uit loggegevens
Als loggegevens eenmaal centraal beschikbaar zijn en op een consistente manier zijn gestructureerd, ontstaat de kans om ze te verheffen van technische detailinformatie tot volwaardig compliance‑instrument. Veel overheidsorganisaties herkennen het beeld van audits waarbij medewerkers wekenlang gegevens bij elkaar zoeken, screenshots maken en losse exports uit verschillende systemen bundelen in spreadsheets. Die aanpak is niet alleen arbeidsintensief, maar ook slecht reproduceerbaar: kleine verschillen in query’s, filters of tijdsperioden zorgen ervoor dat twee audits nooit precies hetzelfde beeld opleveren. Door loggegevens vanaf het begin te ontwerpen met herbruikbare rapportage in gedachten, verandert dit proces fundamenteel.
De eerste stap is om samen met auditors, interne toezichthouders en de functionaris voor gegevensbescherming in kaart te brengen welke vragen regelmatig terugkomen. Vaak gaan die over toegang tot gevoelige gegevens, het gebruik van beheerrechten, de naleving van beleid (zoals verplichte meervoudige authenticatie) en de behandeling van incidenten. Voor elk van deze vraagstukken wordt een set vaste query’s opgesteld in de logomgeving, voorzien van duidelijke documentatie: welk doel dient de query, welke tabellen worden gebruikt, welke filters gelden en hoe moet de uitkomst worden geïnterpreteerd? Deze querybibliotheek vormt de basis voor alle toekomstige audits en maakt de resultaten veel beter vergelijkbaar over de tijd.
Vervolgens worden rapportages geautomatiseerd. In plaats van handmatig query’s te draaien wanneer een onderzoek start, worden periodieke rapporten ingericht die maandelijks of per kwartaal worden gegenereerd. Een CISO ontvangt bijvoorbeeld een terugkerend overzicht van aanmeldingen met verhoogd risico, uitstaande incidenten en het gebruik van noodaccounts. De functionaris voor gegevensbescherming krijgt een rapport met statistieken over toegang tot persoonsgegevens, ongeautoriseerde pogingen en de doorlooptijd van meldingen. Deze rapporten worden opgeslagen in een centrale governance‑omgeving, zodat auditors kunnen zien dat monitoring geen momentopname is maar een doorlopend proces.
Visualisatie speelt daarbij een grote rol. Dashboards in Microsoft Sentinel of Power BI vertalen ruwe loggegevens naar grafieken, trendlijnen en signaalwaarden die ook voor niet‑technische bestuurders begrijpelijk zijn. In één scherm is zichtbaar welk percentage accounts MFA gebruikt, hoe lang incidenten gemiddeld openstaan, hoeveel mislukte aanmeldpogingen vanaf buitenlandse locaties zijn geregistreerd en hoe retentietermijnen zich verhouden tot afgesproken drempelwaarden. Door drempelwaarden en signaalkleuren te koppelen aan risicogrenzen, zien bestuurders direct waar aandacht nodig is.
Daarnaast moet een organisatie voorbereid zijn op gerichte onderzoeken waarbij detailinformatie nodig is. In die situaties is het cruciaal dat logexports gecontroleerd plaatsvinden. Dat betekent dat vooraf wordt bepaald welke periode, welke systemen en welke gegevenscategorieën binnen scope vallen en dat alleen de relevante logregels worden geëxporteerd. De export zelf vindt plaats in gestandaardiseerde formaten, bijvoorbeeld CSV of JSON, en wordt versleuteld aangeboden aan de auditor. Een begeleidend document legt uit hoe de data is verzameld, welke filters zijn gebruikt en hoe de integriteit is geborgd. Zo blijft het onderzoek transparant, terwijl privacy en vertrouwelijkheid worden beschermd.
Een volwassen organisatie monitort niet alleen de onderliggende logs, maar ook de rapportages die eruit voortkomen. Wanneer periodieke rapporten ineens niet meer worden gegenereerd, als indicatoren langdurig leeg blijven of als het aantal uitzonderingen op beleid opvallend stijgt, zijn dat signalen dat er iets misgaat in de controleketen. Door ook deze signalen te voorzien van alerts en follow‑up‑taken, wordt compliance een continu verbeterproces in plaats van een jaarlijkse controle. Loggegevens leveren dan niet alleen het bewijs achteraf, maar fungeren ook als vroegtijdig waarschuwingssysteem dat bestuurders en toezichthouders in staat stelt om tijdig bij te sturen en de Nederlandse Baseline voor Veilige Cloud daadwerkelijk in de dagelijkse praktijk te brengen.
Een doordachte logging‑ en monitoringstrategie is voor Nederlandse overheidsorganisaties onmisbaar om incidenten te onderzoeken, risico’s te beheersen en naleving van wet‑ en regelgeving aan te tonen. Wie begint bij de juridische kaders en deze vertaalt naar concrete logbronnen, bewaartermijnen en verantwoordelijkheden, voorkomt dat logging verwordt tot een verzameling losse instellingen zonder duidelijke samenhang. Door logstromen centraal te verzamelen in een goed ontworpen architectuur, met aandacht voor filtering, structurering, gelaagde opslag en strikte toegangscontrole, ontstaat een betrouwbaar fundament waarop zowel security‑operaties als audits kunnen steunen.
De echte meerwaarde ontstaat wanneer dezelfde loggegevens systematisch worden ingezet voor geautomatiseerde compliance‑rapportage en bestuurlijke sturing. Met vaste query’s, periodieke rapporten en heldere dashboards wordt zichtbaar hoe maatregelen presteren, waar afwijkingen optreden en welke verbeteracties prioriteit hebben. Logging ontwikkelt zich dan van technisch detail naar strategisch instrument: een middel waarmee bestuurders kunnen laten zien dat zij controle hebben over hun digitale omgeving en dat de Nederlandse Baseline voor Veilige Cloud niet alleen op papier bestaat, maar daadwerkelijk wordt toegepast.
Het opbouwen van zo’n volwassen logginglandschap kost tijd en vraagt om samenwerking tussen juristen, beveiligingsspecialisten, beheerders en archivarissen. Door de ontwikkeling stap voor stap aan te pakken, regelmatig te evalueren en leerpunten uit incidenten en audits consequent terug te voeren in beleid en inrichting, groeit de organisatie naar een niveau waarop observability, compliance en risicobeheersing naadloos in elkaar grijpen. Iedere iteratie – hoe klein ook – versterkt het fundament en verkleint de kans dat een incident onopgemerkt blijft of een audit leidt tot onaangename verrassingen.