Met een audit van wijzigingen in PHP-databases kun je relevante wijzigingen reconstrueren: welk object is gewijzigd, wie de bewerking heeft gestart, wanneer die plaatsvond en in welke context. Een goed ontwerp betekent niet dat je voor altijd een kopie van elke rij bewaart. Het doel is om operationele en controlevragen te beantwoorden met betrouwbare, afgebakende en beschermde registraties.
Voordat je tabellen of bibliotheken kiest, is het verstandig vast te stellen welke beslissingen de geschiedenis moet ondersteunen. Een foutieve wijziging onderzoeken, een actie aan een klant uitleggen of een geautomatiseerde bewerking opsporen zijn verschillende behoeften. Ze bepalen welke gegevens je registreert, wie ze mag raadplegen en hoe lang je ze bewaart.
Audit, technische logbestanden en zichtbare geschiedenis zijn niet hetzelfde
Technische logbestanden beschrijven de uitvoering van de applicatie: fouten, verzoeken, vertragingen of storingen in afhankelijkheden. Ze zijn nuttig voor het diagnosticeren van systemen, maar kunnen snel worden geroteerd en koppelen een bewerking niet altijd op een gestructureerde manier aan het getroffen bedrijfsobject.
De voor gebruikers zichtbare geschiedenis toont doorgaans een begrijpelijke selectie van acties, zoals ‘het adres is bijgewerkt’. Details over de interne werking kunnen ontbreken en deze geschiedenis vormt niet noodzakelijk een toereikend overzicht voor het onderzoeken van incidenten. Bij een audit van wijzigingen ligt de prioriteit bij het toeschrijven en betrouwbaar reconstrueren van bewerkingen die als gevoelig zijn aangemerkt.
Deze mechanismen kunnen elkaar aanvullen, maar mogen niet met elkaar worden verward. Een auditgebeurtenis mag er niet van afhangen dat een logregel nog beschikbaar is. Ook moet je niet automatisch alle metadata die voor bewerkingen of ondersteuning wordt opgeslagen, aan de eindgebruiker tonen.
Bepalen voor welke acties traceerbaarheid nodig is
Begin met het identificeren van kritieke entiteiten en concrete risico’s. Een applicatie moet bijvoorbeeld mogelijk wijzigingen in rechten, factureringsgegevens, de status van bestellingen of accountgegevens registreren. De selectie moet antwoord geven op een praktische vraag: wat zou belangrijk zijn om uit te leggen of te onderzoeken als dit gegeven verandert?
Definieer de relevante bewerkingen: aanmaken, wijzigen, verwijderen, goedkeuren, intrekken of de status wijzigen. In veel gevallen is het nuttiger om betekenisvolle overgangen te registreren dan elke technische schrijfactie. Een update van weergavevelden kan een ander detailniveau vereisen dan een wijziging van de accounteigenaar.
Documenteer per geval het doel, de betrokken velden, mogelijke actoren, bevoegde lezers en de geplande bewaartermijn. Leg niet zonder onderscheid de volledige rij vast: dat kan persoonsgegevens of geheimen dupliceren en het naleven van toegangs- en verwijderingsbeleid bemoeilijken. Als het vergelijken van waarden nodig is, beperk de registratie dan tot de gerechtvaardigde velden.
De registratie modelleren met actor, bewerking en context
Een bruikbare registratie bevat doorgaans een eigen identificatiecode, het type en de identificatiecode van het betrokken object, de bewerking, datum en tijd, en de actor. Leg vast of die tijd het moment aangeeft waarop de bewerking wordt gestart of waarop de wijziging wordt bevestigd, zodat de waarde eenduidig te interpreteren is. Registreer datum en tijd volgens een gemeenschappelijke conventie, doorgaans UTC; gebruik een consistente tijdsbron, zoals de klok van de database of die van de applicatie, en houd servers gesynchroniseerd met de beschikbare operationele mechanismen. Meng geen tijdsbronnen of tijdzones zonder dit aan te geven.
De actor kan een persoon, een serviceaccount of een geautomatiseerd proces zijn. Gebruik geen dubbelzinnige waarde zoals ‘systeem’ als je het verantwoordelijke proces gecontroleerd kunt identificeren. De context kan de aanvraag- of correlatie-ID, het bronkanaal en, indien nodig, de door de gebruiker opgegeven reden bevatten. Registreer alleen wat nodig is: IP-adressen, gebruikersagenten en andere metadata kunnen gevoelige gegevens zijn of gevolgen hebben voor de privacy.
Overweeg voor gewijzigde waarden een afgebakende weergave van de oude en nieuwe veldwaarden op te slaan, of alleen een lijst met gewijzigde veldnamen als de waarden niet nodig zijn. Sluit inloggegevens, tokens en geheimen uit. Een verwijzing naar het object maakt navigeren vanuit de geschiedenis mogelijk, maar garandeert niet dat het object nog bestaat; de registratie moet voldoende context bewaren voor het beoogde onderzoek.
De relatie tussen actor en gebeurtenis moet weergeven wie de actie heeft gestart, niet alleen welke gebruiker bij een aanvraag was geauthenticeerd. Als een beheerder namens iemand anders handelt, maak dan onderscheid tussen de initiator en de betrokken entiteit en registreer die delegatie alleen als dat relevant en toegestaan is.
Kiezen tussen gebeurtenissen, een audittabel en een specifieke geschiedenis
Een relationele audittabel is doorgaans geschikt wanneer je rechtstreeks wilt kunnen zoeken op object, actor, bewerking of tijdsperiode. De tabel biedt een eenvoudig te inspecteren model en kan worden afgestemd op de behoeften van een bestaande applicatie. Definieer indexen voor de verwachte zoekopdrachten, zonder elk veld zonder onderscheid te indexeren.
Domeingebeurtenissen vertegenwoordigen bedrijfsrelevante feiten, zoals een goedkeuring of annulering. Ze kunnen zowel worden gebruikt voor vervolgprocessen als voor auditing, maar alleen als ze ondubbelzinnige feiten beschrijven en hun betekenis behouden blijft. Niet elke schrijfactie naar een database is een domeingebeurtenis. Ga er evenmin van uit dat het gebruik van gebeurtenissen betekent dat je event sourcing toepast: dat zijn verschillende architecturale keuzes.
Een specifieke geschiedenis per entiteit kan eenvoudiger zijn als de zoekopdrachten en regels specifiek zijn. Daar staat tegenover dat meerdere implementaties uiteen kunnen gaan lopen en hiaten kunnen achterlaten. Beoordeel het volume, de zoekopdrachten, de evolutie van het schema en het aantal schrijfpunten voordat je een keuze maakt. Een geavanceerder formaat compenseert geen onvolledige toeschrijving.
Consistentie met de bedrijfsbewerking garanderen
Als de wijziging en de registratie als één bewerking moeten gelden, sla ze dan samen op binnen dezelfde transactie. Zo voorkom je dat een wijziging wordt bevestigd zonder auditregistratie, of dat er een gebeurtenis wordt opgeslagen voor een wijziging die is teruggedraaid. Controleer welke garanties de database daadwerkelijk biedt en hoe de applicatie fouten bij elke schrijfactie afhandelt.
Wanneer een bewerking ook naar een wachtrij of externe dienst moet worden gepubliceerd, omvat een databasetransactie dat systeem niet vanzelf. Een patroon zoals de transactional outbox kan helpen: de wijziging en het nog te versturen bericht worden samen opgeslagen, waarna een proces het bericht aflevert. Beheer nieuwe pogingen en idempotentie om duplicaten of verlies te voorkomen.
Ook wijzigingen die niet vanuit de interface worden gestart — geplande taken, importbewerkingen, opdrachten of integraties — vereisen dezelfde aandacht. Definieer een gemeenschappelijk registratiemechanisme en een expliciete service-identiteit. Als er rechtstreeks buiten de applicatie om wordt geschreven, bepaal dan of dat wordt verboden, gecontroleerd of op een andere laag wordt geaudit; ga er niet van uit dat PHP-code zulke schrijfacties automatisch aan een actor kan toeschrijven.
Toegang beheren en veilige zoekopdrachten ontwerpen
Behandel de geschiedenis als gevoelige informatie. Scheid de rechten voor schrijven en raadplegen, pas het principe van minimale toegangsrechten toe en registreer toegang door ondersteuningsmedewerkers wanneer het risico dat rechtvaardigt. De gewone applicatie mag historische registraties niet ongecontroleerd kunnen wijzigen of verwijderen; houd rekening met wie de database beheert en welke mechanismen wijzigingen door bevoegde gebruikers kunnen detecteren.
Stel de bewaartermijn vast op basis van het doel, de toepasselijke verplichtingen en de operationele behoeften. Definieer een controleerbaar proces om registraties indien nodig te archiveren of te verwijderen. Gebruik auditing niet als excuus om gegevens die je niet meer nodig hebt, voor onbepaalde tijd te bewaren.
Gebruik paginering in zoekopdrachten en filter op object, actor, bewerking en datums. De interface moet eerst de informatie tonen die nodig is om de volgorde te begrijpen, met passende rechten en begrijpelijke indelingen. Vermijd volledige gevoelige waarden in schermen, exports of API-antwoorden. Beveilig ook zoekparameters tegen toegang tot objecten van anderen.
Integriteit testen en hiaten in de dekking opsporen
Tests moeten meer controleren dan alleen of er een rij bestaat. Controleer of elke verwachte bewerking de juiste actor, het object, de relevante velden en een geldige datum en tijd vermeldt. Simuleer fouten tussen het wegschrijven van bedrijfsgegevens en de auditregistratie, evenals het terugdraaien van transacties en nieuwe pogingen.
Neem tests op voor acties van gebruikers, serviceaccounts, importbewerkingen en geplande processen. Controleer dat uitgesloten gegevens niet in de registratie verschijnen en dat gebruikers zonder rechten geen geschiedenissen van anderen kunnen raadplegen. Integratietests zijn belangrijk omdat transactioneel gedrag afhangt van de database en van de manier waarop de applicatie die gebruikt.
Periodieke operationele controles helpen hiaten op te sporen die tests niet afdekken. Vergelijk de inventaris van acties die geaudit zouden moeten worden met de acties die daadwerkelijk voorkomen in een steekproef of een bepaald tijdsinterval. Zoek naar gevoelige bewerkingen zonder gebeurtenissen, registraties zonder actor of object, ontbrekende of verkeerd geordende datums en tijden, en verschillen tussen bevestigde wijzigingen en geregistreerde gebeurtenissen. Als er voldoende gegevens zijn om een patroon vast te stellen, controleer dan ook op onverwachte dalingen in het aantal gebeurtenissen of abnormale stijgingen.
Stel waarschuwingen in voor signalen waarop actie nodig is: fouten bij het schrijven naar de audit, lege verplichte velden, vertragingen in de aflevering van asynchrone processen of afwijkingen die controles aan het licht brengen. Wijs verantwoordelijken en een onderzoeksprocedure aan; een waarschuwing zonder opvolging verhelpt de gebrekkige dekking niet. Interpreteer een verandering in volume niet automatisch als een incident: vergelijk die met de verwachte werking en het taakrooster.
Begin voor het invoeren van traceerbaarheid in een bestaande applicatie met een inventaris van entiteiten en bewerkingen met het hoogste risico. Implementeer een gemeenschappelijk formaat, dek de geïdentificeerde schrijfpunten af en voeg zoekopdrachten, rechten en periodieke controles toe voordat je de reikwijdte uitbreidt. Beoordeel steekproeven in een gecontroleerde omgeving. Auditing is nuttig wanneer het op consistente wijze concrete vragen kan beantwoorden, niet wanneer het gegevens verzamelt die niemand kan interpreteren.
