Producenten en de Audittrail-vraag die niemand stelt totdat ernaar gevraagd wordt

Een producent kan meestal een toegangslogboek produceren wanneer een klant of auditor hierom vraagt. Veel minder producenten kunnen een moeilijkere vraag beantwoorden: had iemand met beheerdersrechten stilletjes dat logboek kunnen bewerken voordat het werd overhandigd? 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 alles te zeggen wat ze wilden over wie een ontwerpbestand heeft geraadpleegd.

Dit artikel onderzoekt wat een audittrail daadwerkelijk betrouwbaar maakt als bewijs voor een producent, en waar het loggen bij de meeste producenten op de achtergrond niet aan die toets voldoet.

Samenvatting voor het management

De bruikbaarheid van een audittrail voor een klant-auditor of interne onderzoeker hangt volledig af van het vertrouwen in de integriteit ervan, en dat vertrouwen kan niet alleen op beleid rusten. Als beheerdersrechten op de onderliggende logopslag technisch bewerken mogelijk maken, is het feit dat beleid dit verbiedt niet hetzelfde als dat het daadwerkelijk onmogelijk is. Voor engineering- en IT-leiders is de praktische norm architectonisch: kan een individu, inclusief een systeembeheerder, het logboek daadwerkelijk aanpassen?

Belangrijkste punten

1. Een logboek dat een beheerder kan bewerken of verwijderen is geen bewijs, ongeacht hoe gedetailleerd het is.
2. Toegang tot de onderliggende logopslag moet architectonisch beperkt zijn, niet alleen via beleid.
3. Scheiding van taken is net zo belangrijk als toegangsbeperking. Degene die een ontwerpbestand raadpleegt en degene die het logboek daarvan controleert, mogen niet dezelfde rol zijn.
4. Volledigheid en directheid zijn onderdeel van betrouwbaarheid, niet losstaand ervan.
5. Klanten en auditors vragen steeds vaker hoe een logboek wordt beschermd, niet alleen wat het bevat.

Waarom “We hebben gedetailleerde logs” het verkeerde uitgangspunt is voor producenten

De meeste gesprekken over auditlogging richten zich op dekking. Dekking is belangrijk, maar beantwoordt niet de juiste eerste vraag.

Detail zonder integriteit is slechts een goed geschreven verhaal

Een logboek met veel details over wie een ontwerpbestand 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 te wijzigen nadat het is geschreven.

Wat maakt logintegriteit architectonisch in plaats van procedureel

Een beleid dat zegt dat beheerders geen logs mogen bewerken, vertrouwt erop dat beheerders zich eraan houden. Een architectonische controle haalt de technische mogelijkheid om anders te handelen weg.

Geen blijvende toegang tot de onderliggende logopslag

De sterkste variant van deze controle is dat noch de eigen IT-beheerders van de producent, 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 ontwerpbestand kan openen ook de rol is die het logboek daarvan controleert, ontstaat er een inherent belangenconflict.

Degene die handelt, mag niet degene zijn die auditeert

Echte scheiding van taken wijst compliance-, audit- en beleidsfuncties toe aan andere rollen dan operationeel beheer.

De standaard bouwen voordat een auditor erom vraagt

De praktische toets is eerlijk te vragen wie technisch het auditlogboek van de producent kan aanpassen, en of de rollen die handelen en de rollen die auditen 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 producent gewone toegang hebben tot het onderliggende besturingssysteem of de database, inclusief de opslag van het auditlogboek; elke supporttoegang is tijdelijk, vereist dubbele autorisatie en wordt zelf volledig gelogd. Specifieke Compliance- en Auditor-rollen scheiden het operationeel beheer van auditfuncties, en elke actie via elk kanaal wordt volledig en direct vastgelegd in een manipulatiebestendig, onbeperkt auditlogboek dat direct in SIEM-tools wordt gevoed.

Producenten die willen testen of hun huidige audittrail bestand is tegen de vraag “had een beheerder dit kunnen bewerken”, kunnen een aangepaste demo plannen.