Wanneer een webapplicatie een witte pagina weergeeft of een server een verbinding weigert, is de eerste stap die een beheerder onderneemt het openen van een bestand. Dit bestand is een log. Het bevat de tijdstempel van elk evenement dat op het systeem heeft plaatsgevonden: een ontvangen verzoek, een opgetreden fout, een geauthenticeerde gebruiker. Het begrijpen van logs in de informatica is een leidraad om de oorsprong van een probleem te achterhalen, te controleren of een dienst functioneert of een abnormaal gedrag te detecteren.
Wat een log werkelijk bevat en waarom het formaat alles verandert
Een log is een registratie van evenementen. Elke regel koppelt minimaal een datum, een bron en een bericht. Op een webserver genereert bijvoorbeeld elke bezoeker een regel die het IP-adres van de bezoeker, de opgevraagde pagina, de HTTP-responscode en de verwerkingstijd specificeert.
Heb je ooit een tekstbestand geopend vol onbegrijpelijke regels? Dat is vaak een ongestructureerde log. Het bericht is in vrije tekst geschreven, zonder vast formaat. Elke applicatie schrijft op zijn eigen manier, wat het zoeken moeilijk maakt zodra meerdere diensten samen bestaan.
Daarentegen organiseert een gestructureerde log in JSON elk veld op een machineleesbare manier. De datum, het ernstniveau, de betrokken dienst en het bericht hebben elk een specifiek veld. De winst is direct: een analysetool kan duizenden evenementen in enkele seconden filteren, sorteren en kruisen in plaats van een patroon in platte tekst te zoeken.
Voor alles te weten over logs in de informatica, is het onderscheid tussen gestructureerd en ongestructureerd formaat het eerste concept dat je moet beheersen, omdat het de rest bepaalt: verzameling, opslag, analyse.
Ernstniveaus van logs: het juiste signaal op het juiste moment lezen
Niet alle geregistreerde evenementen hebben dezelfde ernst. Logging-frameworks gebruiken een ernstschaal die het mogelijk maakt om te filteren wat onmiddellijke aandacht vereist.
- DEBUG: fijne details die tijdens de ontwikkeling worden gebruikt, uitgeschakeld in productie om een overmatige hoeveelheid te voorkomen.
- INFO: normale evenementen die de goede werking bevestigen (start van een dienst, succesvolle verbinding).
- WARN: ongebruikelijke situatie die de werking niet belemmert maar een risico aangeeft (weinig schijfruimte, hoge latentie).
- ERROR: een verwerking is mislukt, een gebruikersactie is niet gelukt. Vaak is een interventie nodig.
- FATAL: de dienst stopt. De hele applicatie of server is offline.
De frequente verleiding is om alles op DEBUG te zetten om “niks te missen”. Het resultaat: bestanden die dagelijks met meerdere gigabytes groeien, een opslagkost die explodeert en een constante ruis die de echte waarschuwingen verdrinkt. Het kiezen van het juiste ernstniveau vermindert het volume zonder nuttige informatie te verliezen.
Gevoelige gegevens in logs: wat je nooit moet registreren
Een log kan bijna alles vastleggen wat door een applicatie gaat. Dat is precies het probleem. OWASP raadt aan om wachtwoorden, toegangstokens, sessie-ID’s, encryptiesleutels en gevoelige persoonlijke gegevens uit logs uit te sluiten.
Waarom deze voorzichtigheid? Omdat de logs zelf een bron van datalekken kunnen worden. Een logbestand dat zonder toegangsbeperkingen is opgeslagen, stelt informatie bloot die door een aanvaller kan worden benut. Wanneer monitoring nodig blijft, is de beste praktijk om gevoelige waarden te maskeren of te pseudonimiseren voordat ze in het logboek worden geschreven.
De CNIL geeft een richtlijn voor de toegangstraceringen en acties van gebruikers: een bewaring van zes maanden tot een jaar afhankelijk van het doel. Daarboven moet de verzamelde inhoud proportioneel blijven aan de werkelijke behoefte. Het bewaren van volledige verzoeken gedurende meerdere jaren zonder gedefinieerde rechtvaardiging brengt zowel juridische als technische risico’s met zich mee.
De integriteit van logs beschermen
Een gewijzigde of verwijderde log verliest zijn bewijswaarde. OWASP beveelt integriteitscontroles aan, een beperkte en gecontroleerde toegang, evenals een veilige opslag van loggegevens. Een logboek dat nuttig is voor een onderzoek moet ook betrouwbaar zijn. Een aanvaller die toegang heeft tot een server zal vaak proberen zijn sporen in de logs uit te wissen voordat hij andere acties onderneemt.
Europese regelgeving en logging: concrete verplichtingen
Logging is niet langer alleen een goede technische praktijk. De Europese Cyber Resilience Act schrijft de logging van beveiligingsevenementen voor als een van de vereisten die van toepassing zijn op digitale producten. De NIS 2-richtlijn verplicht op haar beurt de betrokken entiteiten om detectie- en responscapaciteiten voor incidenten op te zetten, wat een functioneel en bruikbaar logsysteem vereist.
Zonder betrouwbare logging wordt naleving van NIS 2 of CRA onmogelijk om aan te tonen. Deze teksten geven niet aan welke tool te gebruiken, maar vereisen de mogelijkheid om te traceren, detecteren en reageren. Logs zijn de technische basis van deze capaciteit.
Goede praktijken voor logbeheer in het dagelijks leven
Het opzetten van logs is niet genoeg. Hun nut hangt af van hoe ze worden verzameld, gecentraliseerd en benut.
- Centraliseer de logs van alle diensten op een uniek platform om handmatig zoeken op elke server te vermijden. Een verzamelaar haalt de evenementen op en stuurt ze naar een gemeenschappelijk analysepunt.
- Definieer een retentiebeleid dat is afgestemd op elk type log. De toegangstraceringen van gebruikers hebben niet dezelfde nuttige bewaartijd als de logs van applicatiediagnose.
- Stel waarschuwingen in voor de niveaus ERROR en FATAL om te reageren voordat gebruikers het probleem melden.
- Herzie regelmatig wat er wordt geregistreerd. Een veld dat tijdens een snelle ontwikkeling is toegevoegd, kan persoonlijke gegevens bevatten zonder dat iemand dat heeft voorzien.
De waarde van een logsysteem wordt gemeten aan de snelheid van incidentoplossing. Een goed gestructureerd, gecentraliseerd en volgens duidelijke regels gezuiverd logboek transformeert een storing van meerdere uren in een diagnose van enkele minuten. Dit is wat een team dat incidenten ondergaat scheidt van een team dat ze anticipeert.
