Wat moet je precies vastleggen in het 'auditlogboek' dat vaak in aanbestedingen voorkomt?
Hallo, ik ben Otsuka, CTO bij Liberogic.
Als je deelneemt aan aanbestedingen voor websites of webservices, zie je in de vereisten vaak staan dat je 'auditlogboeken moet kunnen opvragen' en 'logboeken gedurende een bepaalde periode moet bewaren'.
Op basis van die vereisten selecteer je een service, wijzig je van plan of voeg je opslag-opties voor logboeken toe, maar wat bedoelen we eigenlijk met 'auditlogboek'?
In dit artikel ga ik dit onderwerp wat nader uitwerken.
Logboeken zijn niet allemaal hetzelfde
Hoewel we logboeken vaak aanduiden als één categorie, bestaan er in werkelijkheid verschillende soorten.
Soorten logboeken | Wat wordt er voornamelijk vastgelegd | Belangrijkste toepassingen |
|---|---|---|
Toegangslogboeken | URL, datum en tijd, status, verbindingsbron, enzovoort | Onderzoek van gebruik en storingen |
Toepassingslogboeken | Begin en einde van verwerking, bedrijfsevenementen | Functionaaliteitscontrole en onderzoek van defecten |
Foutenlogboeken | Uitzonderingen, abnormale beëindiging, foutgegevens | Identificatie van de oorzaak van de storing |
Auditlogboeken | Wie, wanneer en wat is gewijzigd | Interne controle en behoud van audit trails |
Beveiligingslogboeken | Authenticatie, toegangsweigering, aanvalsdetectie | Incidentonderzoek |
Ze zijn allemaal logboeken, maar de inhoud die wordt vastgelegd en het doel waarvoor ze worden gebruikt, verschillen.
Bijvoorbeeld, een logboek dat registreert wanneer een beheerder de machtigingen van een gebruiker wijzigt of wanneer een medewerker inhoud publiceert, staat bekend als wat we doorgaans een auditlogboek noemen.
Onderzoek naar storingen en behoud van audit trails scheiden
Het doel van logboeken kan in twee grote categorieën worden onderverdeeld.
De ene is een logboek voor het onderzoeken van de oorzaak wanneer er een storing of defect optreedt.
Het wordt gebruikt bij het onderzoeken van vragen zoals 'ik heb gisteren een formulier verzonden maar het is niet aangekomen' of 'er trad alleen op bepaalde momenten een fout op'.
Het andere type is een logboek om later de feiten van bewerkingen te verifiëren.
Records zoals "wie heeft de instellingen gewijzigd", "wanneer was de inhoud gepubliceerd" en "welke bewerkingen zijn in het beheerdashboard uitgevoerd".
Vergelijkingspunten | Voor onderzoek en verbetering van storingen | Voor audits en bewaarpflicht |
|---|---|---|
Voornaamste gebruikers | Ontwikkelaars, bedrijfsmedewerkers | Audit- en beveiligingsmedewerkers |
Meest bekeken periode | Afgelopen dagen tot weken | Enkele maanden tot enkele jaren |
Belangrijke overwegingen | Zoekmogelijkheden, hoeveelheid informatie | Volledigheid, duurzame beschikbaarheid |
Raadplegingsfrequentie | Dagelijks controleren | Ophalen wanneer nodig |
Deze twee hebben verschillende bewaartermijnen en gebruikspatronen.
Als u alle logs gedurende lange tijd in een doorzoekbare staat wilt bewaren, zullen de kosten aanzienlijk stijgen. Omgekeerd, als u alleen recente logs bewaart, kunnen benodigde audittrails en bewijsmateriaal bij incidentonderzoeken verloren gaan.
Het is beter om van het begin af aan onderscheid te maken voor een ontwerp zonder onnodig beperkingen.
"Auditlogboek nodig" als vereiste vastleggen
Met alleen het woord "auditlogboek" kun je de concrete structuur niet bepalen.
Eerst controleer je het doel en leg je vast welke gegevens je moet registreren en hoe je deze opslaat.
"We kunnen logboeken vastleggen" is niet helemaal genoeg
Als logboeken in het bedieningspaneel van een cloudservice worden weergegeven, denk je snel "we kunnen logboeken vastleggen".
De inhoud en retentieperiode van opgeslagen gegevens verschillen echter per service.
- Fouten worden opgeslagen, maar de handelingen van beheerders niet
- Zichtbaar in het bedieningspaneel, maar wordt na een bepaalde periode verwijderd
- Voor externe overdracht is een hoger abonnement nodig
- Je moet de handelingen van de applicatie zelf registreren
Met cloudservices alleen kunt u soms niet achterhalen wie productinformatie heeft gewijzigd of welke aanvraaggegevens zijn verwerkt. Deze soort bedrijfslogboeken kunnen dus onvolledig zijn.
Wanneer "auditlogboeken" in de vereisten van een tender wordt vermeld, is het raadzaam om op zijn minst de volgende punten te controleren.
Checklist voor vereistenverzameling
✅️ Welke bewerkingen moeten worden geregistreerd
✅️ Bewerkingen van gebruikers of administrators
✅️ Is het voor probleemdiagnose of audit
✅️ Hoe lang moeten logbestanden worden bewaard
✅️ Is regelmatig zoeken in logbestanden nodig
✅️ Wie mag logbestanden bekijken
✅️ Kunnen persoonlijke gegevens in de logbestanden voorkomen
Als u dit niet begrijpt en toch een service of abonnement kiest, kan dit leiden tot een overmatig groot systeem of omgekeerd tot onvoldoende benodigde logbestanden.
In moderne webservices zijn logbestanden ook gedistribueerd
Bij traditionele webservers kon je logbestanden eenvoudig op de server zelf opslaan - een vrij duidelijk concept.
Tegenwoordig worden webservices vaker gecreëerd door meerdere cloudservices te combineren, zoals CDN, hosting, databases, headless CMS en e-mailverzending.
Liberogic gebruikt ook, afhankelijk van het project, niet alleen AWS, maar ook Cloudflare, Vercel, Supabase, microCMS en Kuroco.
Omdat logboeken afzonderlijk in elk service worden opgeslagen, is het noodzakelijk om vanuit een breder perspectief na te denken over "wat er in het geheel van het systeem overblijft".
Begin door het doel vast te stellen
Wanneer wordt gezegd dat "auditlogboeken nodig zijn", voelt het vaak alsof u een speciaal service moet implementeren.
Afhankelijk van de vereisten kunnen externe logbeheerservices of mechanismen voor langdurige opslag nodig zijn. Echter, het is niet altijd nodig om vanaf het begin een groot opzet in te richten.
Begin met: wat moet u registreren, waarom, en hoe lang moet u dit bewaren?
Na deze inventarisatie is het praktischer om onderscheid te maken tussen wat u met standaardfuncties kunt bereiken en wat extra constructie vereist.
In het volgende artikel vergelijken we globaal welke logboeken worden gegenereerd in services die we regelmatig gebruiken, zoals AWS, Cloudflare, Vercel, Supabase en headless CMS.
Tot ziens.
De ruggengraat van Liberogics technische afdeling. Als we horen 'ik wou dat we dit hadden, het zou erg handig zijn', voegt deze persoon met aangeboren slimheid direct meerwaarde toe en implementeert het in een mum van tijd. Met uitstekende communicatievaardigheden en veel fans onder onze klanten: de schat van ons bedrijf, en iemand die gek is op katten.
Shō Ōtsuka
Directeur CTO / Chief Engineer / Directeur van Nekoana LLC / Onredelijk jong uitziend