Het auditlogboek: het antwoord op "wie deed het", niet op "wat gebeurde er"

Bewaking en een auditlogboek zijn twee verschillende dingen, en ze worden door elkaar gehaald. Bewaking beantwoordt "wat gebeurde er": de schijf liep vol, een dienst viel om, de belasting steeg. Een auditlogboek beantwoordt wie het deed. De waarde van het tweede blijkt op dagen die je nooit hoopt.

Drie momenten

Er is iets veranderd en niemand herinnert zich het veranderd te hebben. Het antwoord is meestal "jij, drie weken geleden", en dat is eerder een opluchting dan een beschuldiging: een onbekende wijziging verontrust veel meer dan een bekende.

Twee mensen werken aan dezelfde machine en elk neemt aan dat de ander het deed. In die situatie is het enige dat de discussie beëindigt het logboek.

Er is werkelijk iets misgegaan en je hebt de volgorde van gebeurtenissen nodig. De eindtoestand vertelt wat er gebeurde; de volgorde vertelt hoe. Zonder het tweede herhaalt hetzelfde zich.

"Root deed het" is geen antwoord

Logt iedereen in met hetzelfde account, dan is de naam in het logboek voor iedereen dezelfde. Het logboek blijft "wat gebeurde er" beantwoorden maar stopt met "wie deed het". Daarom is een auditlogboek onbelangrijk op een opstelling met één persoon en wordt het kritisch op de dag dat er een tweede bij komt.

Wat er niet in het logboek hoort

De inhoud van het verzoek. Wachtwoorden, sleutels en tokens gaan daardoorheen. Een logboek dat alles vastlegt betekent een nieuwe plek waar je geheimen wonen, en die plek is meestal minder beschermd omdat hij telt als "maar een logboek".

Een auditlogboek heeft vijf dingen nodig: wie, wat, wanneer, waaraan, en het resultaat. Wil je een zesde toevoegen, vraag dan eerst of het een geheim draagt.

Waar het staat bepaalt of het bewijs is

Een logboek dat alleen de toepassing kan schrijven en herschrijven is een dagboek, geen bewijs. Wordt de toepassing zelf overgenomen, dan repareert hij het logboek er meteen bij.

Daarom moet het logboek ook landen waar de toepassing niet bij kan. Het eigen logboek van het systeem bestaat daarvoor: de toepassing schrijft ernaartoe maar kan er niets uit verwijderen.

Bewaartermijn

Een auditlogboek dat drie dagen bewaard blijft, beantwoordt "wie deed het gisteren" en verder niets. Maar de meeste van die vragen komen weken later, want het gevolg van een wijziging is meestal niet meteen zichtbaar. Bewaar het auditlogboek volgens een andere redenering dan je back-ups: het neemt weinig ruimte in en blijft lang waardevol.

Wat Atlas doet

Atlas schrijft slechts vijf dingen in het auditlogboek: wie, wat, wanneer, waaraan, resultaat. De inhoud van het verzoek wordt nooit geschreven, want een aanmeldverzoek draagt een wachtwoord en het heeft geen enkel nut dat dat wachtwoord een tweede keer in een logbestand bestaat.

Het logboek landt op twee plekken tegelijk. De ene is het eigen logboek van het systeem: Atlas schrijft ernaartoe maar kan er niets uit halen of wijzigen. De andere is een bestand in de gegevensmap van het product dat door updates niet wordt verwijderd. Je hoeft dus niet in het systeemlogboek af te dalen om het te lezen, maar het staat er wanneer je het nodig hebt.

Een klein maar betekenisvol detail: het tijdstempel wordt helemaal aan het eind van de regel geschreven. Zo kan de kant die de regel maakt hem niet overschrijven, zelfs als hij een eigen tijdstempel meegeeft. Vandaag probeert niets dat, maar in een auditlogboek hoort de juiste volgorde bij de aard van de zaak.

En geweigerde verzoeken worden ook vastgelegd, niet alleen de uitgevoerde. De informatie "iemand probeerde het en het lukte niet" staat dus ook in het logboek; meestal is dat precies de zin die je zocht.