Wat moet je bijhouden in een 'auditlog' zoals vaak gevraagd in aanbestedingen?
Hallo, ik ben Otsuka en ik ben CTO bij Liberogic.
Wanneer je meedoet aan een aanbesteding voor een website of webdienst, staat in de eisen vaak dat er 'auditlogs moeten kunnen worden bijgehouden' en dat 'logs gedurende een bepaalde periode moeten worden bewaard'.
Om aan die eisen te voldoen, kies je een dienst, pas je een abonnement aan of voeg je een optie voor logopslag toe. Maar wat wordt er eigenlijk bedoeld met een 'auditlog'?
In dit artikel brengen we dat graag wat meer in kaart.
Er zijn meerdere soorten logs
Hoewel we het allemaal 'logs' noemen, zijn er in de praktijk verschillende soorten.
Soorten logs | Wat er hoofdzakelijk wordt vastgelegd | Belangrijkste doel |
|---|---|---|
Toegangslogboek | URL, datum en tijd, status, herkomst van de verbinding | Onderzoek naar gebruik en storingen |
Applicatielogboek | Start en einde van processen, zakelijke gebeurtenissen | Controle van de werking en onderzoek naar fouten |
Foutlogboek | Uitzonderingen, abnormale beëindigingen, foutinhoud | Vaststellen van de oorzaak van storingen |
Auditlogboek | Wie heeft wanneer wat gedaan | Interne controle en het veiligstellen van bewijsmateriaal |
Beveiligingslogs | Authenticatie, geweigerde toegang en detectie van aanvallen | Onderzoek naar incidenten |
Het zijn allemaal logs, maar wat ze vastleggen en waarvoor ze worden gebruikt, verschilt.
Een log die bijvoorbeeld vastlegt dat een beheerder de rechten van een gebruiker heeft gewijzigd of dat een medewerker content heeft gepubliceerd, komt het dichtst in de buurt van wat doorgaans een auditlog wordt genoemd.
Onderscheid onderzoek naar storingen van het veiligstellen van bewijsmateriaal
Het doel van logs valt grofweg in twee categorieën uiteen.
Het eerste type helpt bij het achterhalen van de oorzaak wanneer er storingen of fouten optreden.
Dit gebruik je bijvoorbeeld om vragen te onderzoeken zoals: "Ik heb gisteren het formulier verzonden, maar het is niet aangekomen" of "Er traden alleen op bepaalde tijden fouten op."
Het tweede is een logboek om achteraf na te gaan welke handelingen er zijn uitgevoerd.
Het gaat om registraties zoals "wie heeft de instellingen gewijzigd", "wanneer is de content gepubliceerd" en "welke handelingen zijn uitgevoerd in het beheerscherm".
Vergelijkingspunt | Voor onderzoek naar storingen en verbeteringen | Voor audit en bewaring van bewijsmateriaal |
|---|---|---|
Belangrijkste gebruikers | Ontwikkelaars en beheerders | Auditors en securityverantwoordelijken |
Gebruikelijke periode | Recente dagen tot enkele weken | enkele maanden tot enkele jaren |
Waar we op letten | Doorzoekbaarheid en hoeveelheid informatie | Volledigheid en langdurige bewaring |
Raadpleegfrequentie | Regelmatig controleren | Op te halen wanneer dat nodig is |
Deze twee verschillen zowel in bewaartermijn als in gebruik.
Als alle logs langdurig doorzoekbaar worden bewaard, stijgen de kosten aanzienlijk. Omgekeerd geldt: wie alleen recente logs bewaart, verliest mogelijk het bewijsmateriaal dat nodig is voor audits of incidentonderzoek.
Het is vanaf het begin verstandiger om beide te scheiden, dan wordt het ontwerp eenvoudiger.
"Auditlogging is nodig" omzetten in concrete vereisten
Alleen het begrip auditlogging maakt nog niet duidelijk hoe het er concreet uit moet zien.
We beginnen daarom met het doel en werken vervolgens uit welke registraties nodig zijn en hoe die worden bewaard.
"Er worden logs geregistreerd" is nog niet genoeg
Als logs zichtbaar zijn in het beheerscherm van een cloudservice, denkt men al snel: "We registreren de logs."
Welke gegevens er worden opgeslagen en hoe lang, verschilt echter per dienst.
- Fouten worden vastgelegd, maar handelingen van beheerders niet
- Zichtbaar in het beheerscherm, maar na een bepaalde periode verdwenen
- Doorsturen naar een externe partij vereist een hoger abonnement
- Handelingen binnen de applicatie zelf moeten we zelf registreren
Bedrijfsgegevens zoals "wie heeft de productinformatie gewijzigd" of "welke aanvraaggegevens zijn verwerkt" zijn met alleen cloudservices niet altijd te achterhalen.
Als in de aanbestedingseisen "auditlogging" staat, is het raadzaam om op z'n minst de volgende punten na te gaan.
Checklist voor het verduidelijken van de eisen
✅️ Welke handelingen moeten worden vastgelegd?
✅️ Gaat het om handelingen van gebruikers of van beheerders?
✅️ Is het doel foutopsporing of auditing?
✅️ Hoe lang moeten de logs worden bewaard?
✅️ Moet er regelmatig in de logs worden gezocht?
✅️ Wie mag de logs inzien?
✅️ Kunnen de logs persoonsgegevens bevatten?
Als deze punten niet duidelijk zijn voordat diensten of abonnementen worden gekozen, wordt de opzet vaak onnodig groot, of ontbreken juist logs die later wel nodig blijken.
Bij moderne webservices is logging ook verspreid
Bij traditionele webservers was het relatief eenvoudig: de logbestanden werden op de server zelf bewaard.
Tegenwoordig worden webservices vaker opgebouwd uit meerdere cloudservices, zoals een CDN, hosting, een database, een headless CMS en e-mailverzending.
Ook Liberogic maakt, afhankelijk van het project, naast AWS gebruik van Cloudflare, Vercel, Supabase, microCMS, Kuroco en andere diensten.
Omdat elke dienst zijn eigen logs opslaat, moet je overzien welke gegevens er in het hele systeem worden bewaard.
Begin met het vaststellen van het doel.
Wanneer er wordt gezegd "er is een auditlog nodig", lijkt het alsof er een speciale dienst moet worden ingevoerd.
Afhankelijk van de eisen kan natuurlijk een externe logbeheerdienst of een mechanisme voor langdurige opslag nodig zijn. Het is echter niet zo dat je meteen een grote opzet moet maken.
Bepaal eerst wat er wordt vastgelegd, waarvoor, en hoe lang het moet worden bewaard.
Daarna is het realistisch om te scheiden welke onderdelen met standaardfunctionaliteit kunnen worden opgelost en welke onderdelen een aanvullend mechanisme vragen.
In het volgende artikel vergelijken we in grote lijnen welke logs er worden bijgehouden bij diensten die we vaak gebruiken, zoals AWS, Cloudflare, Vercel, Supabase en headless CMS's.
Tot de volgende keer!
Het ruggengraat van de technische afdeling van Liberogic. Wanneer er iemand zegt: "Zoiets zou handig zijn, zoiets zou ik graag hebben...", bedenkt hij met zijn eigen vernuftigheid extra waarde en implementeert het in een mum van tijd. Een kostbaar bezit van ons bedrijf: hij communiceert goed, heeft veel fans onder onze klanten, en is een echte kattenliefhebber.
Sho Otsuka
Directeur CTO / Chief Engineer / Vertegenwoordiger van Nekoana B.V. / Ziet er onnodig jong uit