Waar audittrails in de publieke sector daadwerkelijk tegen bestand moeten zijn
Een overheidsinstantie kan meestal een toegang logboek overleggen wanneer een toezichthoudend orgaan daarom vraagt. Veel minder instanties kunnen echter antwoord geven op een lastigere vraag: had iemand met beheerdersrechten stilletjes dat logboek kunnen bewerken voordat het werd overlegd? Als het antwoord ja is, zelfs in theorie, is het logboek geen bewijs. Het is een document dat iemand met de juiste inloggegevens had kunnen schrijven om te vermelden wat hij of zij maar wilde over wie een burgerdossier heeft geraadpleegd.
Dit artikel onderzoekt wat een audittrail daadwerkelijk betrouwbaar maakt als bewijs voor een overheidsinstantie, en waar het loggen bij de meeste instanties op dit punt ongemerkt tekortschiet.
Samenvatting voor het management
De bruikbaarheid van een audittrail voor een toezichthouder of interne onderzoeker hangt volledig af van het vertrouwen in de integriteit ervan, en dat vertrouwen kan niet alleen op beleid rusten. Als administratieve toegang tot de onderliggende logopslag technisch bewerken mogelijk maakt, is het feit dat beleid dit verbiedt niet hetzelfde als dat het onmogelijk is. Voor IT- en complianceleiders is de praktische norm architectonisch: kan een individu, inclusief een systeembeheerder, daadwerkelijk het logboek aanpassen?
Belangrijkste inzichten
- Een logboek dat een beheerder kan bewerken of verwijderen, is geen bewijs, ongeacht hoe gedetailleerd het is.
- Toegang tot de onderliggende logopslag moet architectonisch worden beperkt, niet alleen via beleid.
- Scheiding van taken is net zo belangrijk als toegangsbeperking. Degene die een burgerdossier raadpleegt en degene die het logboek van die toegang controleert, mogen niet dezelfde rol zijn.
- Volledigheid en directheid zijn onderdeel van betrouwbaarheid, niet los ervan.
- Toezichthouders vragen steeds vaker hoe een logboek wordt beschermd, niet alleen wat erin staat.
Waarom “We hebben gedetailleerde logs” het verkeerde uitgangspunt is voor instanties
De meeste gesprekken over auditlogging gaan over dekking. Dekking is belangrijk, maar beantwoordt niet de belangrijkste eerste vraag.
Detail zonder integriteit is slechts een goed geschreven verhaal
Een logboek met veel details over wie een burgerdossier heeft geraadpleegd, is alleen zo betrouwbaar als de garantie dat niemand het achteraf heeft aangepast.
De vraag die echt telt: wie had dit kunnen wijzigen
De juiste eerste vraag is niet wat een logboek vastlegt, maar wie technisch in staat is het na het schrijven te wijzigen.
Wat maakt logintegriteit architectonisch in plaats van procedureel
Een beleid dat stelt dat beheerders geen logs mogen bewerken, vertrouwt op de keuze van beheerders om zich eraan te houden. Een architectonische controle neemt de technische mogelijkheid om anders te handelen weg.
Geen permanente toegang tot de onderliggende logopslag
De sterkste vorm van deze controle is dat noch de IT-beheerders van de instantie, noch de platformleverancier gewone toegang hebben tot het besturingssysteem of de database waar logs worden opgeslagen.
Uitzonderingen moeten echt uitzondering zijn, geen achterdeur
Wat een verdedigbare uitzondering onderscheidt van een achterdeur, is of die toegang tijdelijk is, dubbele autorisatie vereist en zelf volledig wordt gelogd.
Scheiding van taken als tweede, onafhankelijke waarborg
Als dezelfde rol die een burgerdossier kan raadplegen ook de rol is die het logboek van die toegang controleert, is er sprake van een belangenconflict.
Degene die handelt, mag niet degene zijn die controleert
Echte scheiding van taken betekent dat compliance-, audit- en beleidsfuncties worden toegewezen aan andere rollen dan de operationele administratie.
De norm opbouwen voordat een toezichthouder erom vraagt
De praktische test is eerlijk te vragen wie technisch het auditlogboek van de instantie zou kunnen aanpassen, en of de rollen die handelen en de rollen die controleren daadwerkelijk gescheiden zijn.
Hoe een Data Control Plane bewijsintegriteit in de architectuur verankert
Het Kiteworks Data Control Plane draait op een geharde architectuur waarbij noch Kiteworks, noch de eigen IT-beheerders van de instantie gewone toegang hebben tot het onderliggende besturingssysteem of de database, inclusief de opslag van het auditlogboek; elke ondersteunende toegang is tijdelijk, vereist dubbele autorisatie en wordt volledig gelogd. Specifieke Compliance- en Auditor-rollen scheiden de operationele administratie van auditfuncties, en elke actie via elk kanaal wordt volledig en direct vastgelegd in een manipulatiebestendig, onbeperkt auditlogboek dat direct doorgevoerd wordt naar SIEM-tools.
Instanties die willen testen of hun huidige audittrail bestand is tegen de vraag “had een beheerder dit kunnen bewerken”, kunnen een aangepaste demo plannen.
Veelgestelde vragen
Een audittrail is alleen betrouwbaar als de integriteit ervan architectonisch is gegarandeerd, wat betekent dat geen enkel individu—inclusief systeembeheerders—technisch in staat is om records te wijzigen of te verwijderen nadat ze zijn vastgelegd. Alleen beleid is onvoldoende als bewerken mogelijk blijft.
Rijke details over toegangsmomenten zijn alleen zo betrouwbaar als de garantie dat het logboek achteraf niet kan worden aangepast. Zonder architectonische beperkingen is een gedetailleerd logboek slechts een goed geschreven verhaal dat iemand met inloggegevens had kunnen verzinnen.
Scheiding van taken zorgt ervoor dat de rol die burgerdossiers raadpleegt, verschilt van de rol die deze toegang controleert of auditeert. Dit voorkomt belangenconflicten en wijst compliance- en auditfuncties toe aan andere rollen dan de operationele administratie.
Kenmerken zijn onder andere geen permanente toegang tot de onderliggende logopslag voor IT-beheerders of leveranciers, tijdelijke uitzonderingen met dubbele autorisatie die zelf worden gelogd, en volledige, directe vastlegging van elke actie in een manipulatiebestendig logboek dat direct wordt doorgezet naar SIEM-systemen.