Als er iets misgaat in je app, is de eerste vraag altijd dezelfde: wat is er precies gebeurd en wanneer. Zonder registratie kun je die vraag niet beantwoorden, en dan wordt een klein incident een groot probleem. Hieronder wat je minimaal vastlegt, wat je juist niet moet loggen, en hoe lang je het bewaart.
Een logboek is verzekering: je merkt de waarde alleen op het moment dat je hem nodig hebt.
Er gaat iets mis. Een gebruiker zegt dat zijn gegevens weg zijn, een betaling is dubbel afgeschreven, of je krijgt een melding dat er een lek zat in een pakket dat je gebruikt. De vraag is dan meteen: is er iets gebeurd, wanneer, en bij wie. Zonder registratie is het antwoord op alle drie hetzelfde: dat weten we niet.
Dat is niet alleen ongemakkelijk, het is duur. Je kunt niet vaststellen of een lek is misbruikt, dus moet je uitgaan van het slechtste geval. Je kunt niet aantonen dat een gebruiker iets zelf heeft gedaan, dus krijg je het verwijt. En je kunt niet zien dat iets al drie weken misging, dus repareer je alleen het symptoom van vandaag.
In prototypes die snel zijn gebouwd ontbreekt dit vrijwel altijd, en dat is logisch: het levert tijdens het bouwen niets op. Het is precies zoals back-ups, met hetzelfde patroon dat je het pas regelt nadat het een keer is misgegaan.
Te weinig loggen maakt je blind. Te veel loggen maakt je logboek zelf een risico.
Er is geen enkel juist getal, maar er zijn wel drie categorieën met een eigen logica.
Kort, meestal enkele weken. Je gebruikt ze om te repareren wat nu kapot is, en daarna hebben ze geen waarde meer. Ze bevatten vaak toevallig gevoelige informatie, dus lang bewaren levert alleen risico op.
Langer, meestal maanden tot een jaar. Dit is het materiaal waarmee je na een lek kunt vaststellen of er iets is gebeurd. Een lek dat je pas na drie maanden hoort, kun je alleen onderzoeken als je logboek zo ver terugloopt.
Het langst, en hier gelden ook boekhoudkundige eisen. Dit hoort niet in je gewone logboek maar in je administratie, waar het beschermd en herleidbaar staat en waar je het over jaren nog kunt terugvinden.
Een halve dag werk, en je bent van het grootste deel van dit probleem af.
Begin met één functie die een gebeurtenis wegschrijft met een vast formaat: wanneer, wie, wat, en het resultaat. Roep die aan op de plekken uit de lijst hierboven. Meer is het niet. De verleiding is groot om meteen een uitgebreide oplossing te kiezen, maar een consequent formaat op tien belangrijke plekken is meer waard dan een geavanceerd systeem dat halverwege is ingebouwd.
Zorg dat je het kunt teruglezen. Een logboek dat je alleen kunt raadplegen door een bestand van tweehonderd megabyte te openen, gebruik je in de praktijk niet. Kunnen zoeken op gebruiker en op tijdvak is het minimum, want dat zijn de twee vragen die je altijd stelt.
Bewaar het ergens waar het blijft staan als de rest omvalt. Een logboek op dezelfde machine die je opnieuw opbouwt bij een probleem, is precies op het verkeerde moment weg. En zorg dat het niet aan te passen is door de applicatie zelf, want een logboek dat gewijzigd kan worden bewijst niets.
Tot slot: dit is de registratie die je nodig hebt zodra een zakelijke klant vragen gaat stellen, en zodra je moet uitzoeken of een bekend lek jou heeft geraakt. Zie de beveiligingsvragenlijst van je eerste zakelijke klant en hoe snel moet jij een lek dichten.
Vijf dingen: inloggen en uitloggen inclusief mislukte pogingen, wijzigingen in rechten en rollen, alles wat geld raakt, het verwijderen van gegevens, en fouten met genoeg context om ze te kunnen naspelen. Die vijf dekken de vragen die je bij een incident altijd krijgt.
Wachtwoorden, tokens, sleutels en sessie-identificaties, ook niet gedeeltelijk. Verder volledige verzoekinhoud met persoonsgegevens erin, want dan wordt je logboek een tweede database die je ook moet beschermen. En betaalgegevens zoals volledige kaartnummers, in geen enkele vorm.
Dat verschilt per soort. Technische foutmeldingen zijn na enkele weken waardeloos en leveren daarna alleen risico op. Toegangs- en rechtengegevens wil je maanden tot een jaar houden, want een lek hoor je vaak pas later. Betalingen horen niet in je logboek maar in je administratie, waar langere bewaareisen gelden.
Omdat elk veld dat je bewaart iets is dat kan lekken en dat je moet beschermen. Een logboek van drie jaar met volledige verzoekinhoud is een aantrekkelijker doelwit dan je eigen database. De vuistregel is: lang genoeg om iets te kunnen uitzoeken, en geen dag langer.
Op een andere plek dan de machine die je bij een probleem opnieuw opbouwt, anders is je logboek precies op het verkeerde moment weg. En zorg dat de applicatie zelf het niet kan wijzigen of wissen, want een logboek dat aangepast kan worden bewijst niets als iemand ernaar vraagt.
Voor de meeste producten niet. Eén functie die een gebeurtenis wegschrijft met een vast formaat, aangeroepen op tien belangrijke plekken, is meer waard dan een geavanceerd systeem dat je halverwege hebt ingericht. Kunnen zoeken op gebruiker en op tijdvak is het enige dat je echt nodig hebt.
Ja, zodra er iets in staat dat tot een persoon herleidbaar is, en een gebruikersnaam of een IP-adres telt daar al bij. Dat betekent dat je een grondslag en een bewaartermijn nodig hebt, en dat je het moet meenemen in je verwerkingsregister. Het is geen reden om niet te loggen, wel om niet meer te loggen dan nodig.
Bouw dan eerst inloggen en rechtenwijzigingen in, want dat zijn de twee waarmee je na een lek kunt vaststellen of er iets is gebeurd. Dat is een uur werk. De rest kun je erbij zetten op het moment dat je er langskomt, zolang je maar hetzelfde formaat aanhoudt.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.