Denkt u aan een database-ontwerp voor het loggen van audits? Denk aan wat er met Hans en Grietje is gebeurd:ze dachten dat het achterlaten van een eenvoudig spoor van broodkruimels een goede manier was om hun stappen te volgen.
Wanneer we een datamodel ontwerpen, zijn we getraind om de filosofie toe te passen dat nu het enige is dat bestaat . Als we bijvoorbeeld een schema ontwerpen om prijzen voor een productcatalogus op te slaan, denken we misschien dat de database ons op dit moment alleen de prijs van elk product hoeft te vertellen. Maar als we zouden willen weten of de prijzen zijn gewijzigd en zo ja, wanneer en hoe die wijzigingen hebben plaatsgevonden, zouden we in de problemen komen. Natuurlijk zouden we de database specifiek kunnen ontwerpen om een chronologisch overzicht van wijzigingen bij te houden - algemeen bekend als een audittrail of auditlog.
Met auditlogging kan een database een 'geheugen' hebben van gebeurtenissen uit het verleden. Als we verder gaan met het voorbeeld van de prijslijst, kan de database met een goed auditlogboek ons precies vertellen wanneer een prijs is bijgewerkt, wat de prijs was voordat deze werd bijgewerkt, wie deze heeft bijgewerkt en van waar.
Oplossingen voor database-auditregistratie
Het zou geweldig zijn als de database een momentopname van zijn status zou kunnen bijhouden voor elke wijziging die in zijn gegevens optreedt. Op deze manier kon je teruggaan naar elk moment in de tijd en zien hoe de gegevens waren op dat precieze moment, net alsof je een film terugspoelde. Maar die manier om auditlogging te genereren is natuurlijk onmogelijk; de resulterende hoeveelheid informatie en de tijd die nodig is om de logs te genereren zou te hoog zijn.
Strategieën voor het loggen van audits zijn gebaseerd op het genereren van alleen audittrails voor gegevens die kunnen worden verwijderd of gewijzigd. Elke wijziging daarin moet worden gecontroleerd om wijzigingen ongedaan te maken, de gegevens in geschiedenistabellen op te vragen of verdachte activiteiten te volgen.
Er zijn verschillende populaire technieken voor het loggen van audits, maar geen ervan dient elk doel. De meest effectieve zijn vaak duur, arbeidsintensief of prestatieverlagend. Andere zijn goedkoper in termen van hulpbronnen, maar zijn ofwel onvolledig, omslachtig in onderhoud of vereisen een opoffering in ontwerpkwaliteit. Welke strategie u kiest, hangt af van de toepassingsvereisten en de prestatielimieten, middelen en ontwerpprincipes die u moet respecteren.
Out-of-the-box oplossingen voor loggen
Deze oplossingen voor auditlogging werken door alle opdrachten die naar de database worden verzonden te onderscheppen en een wijzigingslogboek in een aparte repository te genereren. Dergelijke programma's bieden meerdere configuratie- en rapportage-opties om gebruikersacties te volgen. Ze kunnen alle acties en query's die naar een database worden verzonden, loggen, zelfs als ze afkomstig zijn van gebruikers met de hoogste privileges. Deze tools zijn geoptimaliseerd om de impact op de prestaties te minimaliseren, maar dit gaat vaak gepaard met geldelijke kosten.
De prijs van speciale audittrailoplossingen kan gerechtvaardigd zijn als u zeer gevoelige informatie (zoals medische dossiers) verwerkt, waarbij elke wijziging van de gegevens perfect moet worden gecontroleerd en controleerbaar en de audittrail onveranderlijk moet zijn. Maar als de audittrail-vereisten niet zo streng zijn, kunnen de kosten van een speciale logging-oplossing buitensporig zijn.
De native monitoringtools die worden aangeboden door relationele databasesystemen (RDBMS'en) kunnen ook worden gebruikt om audittrails te genereren. Aanpassingsopties maken het mogelijk om te filteren welke gebeurtenissen worden geregistreerd, om geen onnodige informatie te genereren of de database-engine te overbelasten met logboekbewerkingen die later niet zullen worden gebruikt. De logboeken die op deze manier worden gegenereerd, maken een gedetailleerde tracking mogelijk van de bewerkingen die op de tabellen worden uitgevoerd. Ze zijn echter niet handig voor het doorzoeken van geschiedenistabellen, omdat ze alleen gebeurtenissen registreren.
De meest economische optie voor het onderhouden van een audittrail is om uw database specifiek te ontwerpen voor auditlogging. Deze techniek is gebaseerd op logtabellen die worden gevuld door triggers of mechanismen die specifiek zijn voor de toepassing die de database bijwerkt. Er is geen algemeen aanvaarde benadering voor het ontwerp van databases voor auditlogging, maar er zijn verschillende veelgebruikte strategieën, die elk hun voor- en nadelen hebben.
Ontwerptechnieken voor databasecontrolelogboekregistratie
Rijversies voor controle loggen op zijn plaats
Een manier om een controlespoor voor een tabel bij te houden, is door een veld toe te voegen dat het versienummer van elk record aangeeft. Invoegingen in de tabel worden opgeslagen met een eerste versienummer. Alle wijzigingen of verwijderingen worden in feite invoegbewerkingen, waarbij nieuwe records worden gegenereerd met de bijgewerkte gegevens en het versienummer met één wordt verhoogd. Hieronder ziet u een voorbeeld van dit ontwerp voor het inloggen op de plaats:
Opmerking:Tabelontwerpen met ingesloten rijversiebeheer kunnen niet worden gekoppeld door externe-sleutelrelaties.
Naast het versienummer moeten enkele extra velden aan de tabel worden toegevoegd om de oorsprong en oorzaak van elke wijziging in een record te bepalen:
- De datum/tijd waarop de wijziging is vastgelegd.
- De gebruiker en applicatie.
- De uitgevoerde actie (invoegen, bijwerken, verwijderen), enz. Om de audit trail effectief te laten zijn, mag de tabel alleen invoegingen ondersteunen (updates en verwijderingen mogen niet zijn toegestaan). De tabel vereist ook noodzakelijkerwijs een surrogaat-primaire sleutel, aangezien elke andere combinatie van velden onderhevig is aan herhaling.
Om toegang te krijgen tot de bijgewerkte tabelgegevens via query's, moet u een weergave maken die alleen de nieuwste versie van elke record retourneert. Vervolgens moet u de naam van de tabel vervangen door de naam van de weergave in alle query's, behalve die specifiek bedoeld zijn om de chronologie van records te bekijken.
Het voordeel van deze versiebeheeroptie is dat er geen extra tabellen nodig zijn om de audittrail te genereren. Bovendien worden er slechts een paar velden toegevoegd aan de gecontroleerde tabellen. Maar het heeft een enorm nadeel:het zal je dwingen om enkele van de meest voorkomende fouten in het databaseontwerp te maken. Deze omvatten het niet gebruiken van referentiële integriteit of natuurlijke primaire sleutels wanneer dit nodig is, waardoor het onmogelijk is om de basisprincipes van het ontwerpen van entiteit-relatiediagrammen toe te passen. U kunt deze nuttige bronnen over databaseontwerpfouten bezoeken, zodat u wordt gewaarschuwd over welke andere praktijken moeten worden vermeden.
Schaduwtabellen
Een andere optie voor een audittrail is het genereren van een schaduwtabel voor elke tabel die moet worden gecontroleerd. De schaduwtabellen bevatten dezelfde velden als de tabellen die ze controleren, plus de specifieke controlevelden (dezelfde die worden vermeld voor de rijversietechniek).
Schaduwtabellen repliceren dezelfde velden als de tabellen die ze controleren, plus de velden die specifiek zijn voor controledoeleinden.
Om audittrails in schaduwtabellen te genereren, is de veiligste optie om triggers voor invoegen, bijwerken en verwijderen te maken, die voor elk betrokken record in de oorspronkelijke tabel een record in de audittabel genereren. De triggers moeten toegang hebben tot alle auditinformatie die u in de schaduwtabel moet vastleggen. U moet de specifieke functionaliteit van de database-engine gebruiken om gegevens te verkrijgen, zoals de huidige datum en tijd, de aangemelde gebruiker, de toepassingsnaam en de locatie (netwerkadres of computernaam) waar de bewerking vandaan kwam.
Als het gebruik van triggers geen optie is, moet de logica om de audittrails te genereren deel uitmaken van de applicatie-stack, in een laag die zich idealiter net voor de datapersistentielaag bevindt, zodat deze alle bewerkingen die naar de database zijn gericht, kan onderscheppen.
Dit soort logtabel zou alleen het invoegen van records moeten toestaan; als ze wijzigingen of verwijdering toelaten, zou de audit trail zijn functie niet meer vervullen. De tabellen moeten ook surrogaat-primaire sleutels gebruiken, omdat de afhankelijkheden en relaties van de originele tabellen er niet op kunnen worden toegepast.
Als de tabel waarvoor u een audittrail hebt gemaakt tabellen heeft waarvan deze afhankelijk is, moeten deze ook overeenkomstige schaduwtabellen hebben. Dit is zodat de audit trail niet verweesd wordt als er wijzigingen worden aangebracht in de andere tabellen.
Schaduwtabellen zijn handig vanwege hun eenvoud en omdat ze de integriteit van het datamodel niet aantasten; de audit trails blijven in aparte tabellen staan en zijn eenvoudig op te vragen. Het nadeel is dat het schema niet flexibel is:elke verandering in de structuur van de hoofdtabel moet worden weerspiegeld in de bijbehorende schaduwtabel, wat het moeilijk maakt om het model te onderhouden. Als controlelogboekregistratie moet worden toegepast op een groot aantal tabellen, zal het aantal schaduwtabellen ook hoog zijn, waardoor het onderhoud van het schema nog moeilijker wordt.
Algemene tabellen voor auditregistratie
Een derde optie is het maken van generieke tabellen voor controlelogboeken. Dergelijke tabellen maken het loggen van elke andere tabel in het schema mogelijk. Voor deze techniek zijn slechts twee tabellen nodig:
Een koptabel waarin wordt vastgelegd:
- De datum en tijd van de wijziging.
- De naam van de tafel.
- De sleutel van de betreffende rij.
- De gebruikersgegevens.
- Het type bewerking dat is uitgevoerd.
Een detailtabel waarin wordt vastgelegd:
- De namen van elk betrokken veld.
- De veldwaarde(n) vóór de wijziging.
- De veldwaarde(n) na de wijziging. (U kunt dit indien nodig weglaten, aangezien het kan worden verkregen door het volgende record in het auditspoor of het overeenkomstige record in de gecontroleerde tabel te raadplegen.)
Het gebruik van generieke controlelogboektabellen legt beperkingen op aan de soorten gegevens die kunnen worden gecontroleerd.
Het voordeel van deze strategie voor het loggen van audits is dat er geen andere tabellen voor nodig zijn dan de twee hierboven genoemde. Ook worden er alleen records in opgeslagen voor de velden die door een bewerking worden beïnvloed. Dit betekent dat het niet nodig is om een hele rij van een tabel te repliceren wanneer slechts één veld wordt gewijzigd. Bovendien kunt u met deze techniek een logboek bijhouden van zoveel tabellen als u wilt - zonder het schema vol te proppen met een groot aantal extra tabellen.
Het nadeel is dat de velden waarin de waarden worden opgeslagen, van één type moeten zijn - en breed genoeg om zelfs de grootste velden van de tabellen waarvoor u een controlelogboek wilt genereren, op te slaan. Het is gebruikelijk om velden van het type VARCHAR te gebruiken die een groot aantal tekens accepteren.
Als u bijvoorbeeld een controlelogboek moet genereren voor een tabel met één VARCHAR-veld van 8.000 tekens, moet het veld waarin de waarden in de controletabel worden opgeslagen ook 8.000 tekens bevatten. Dit geldt zelfs als u slechts één geheel getal in dat veld opslaat. Aan de andere kant, als uw tabel velden met complexe gegevenstypen heeft, zoals afbeeldingen, binaire gegevens, BLOB's, enz., moet u hun inhoud serialiseren zodat ze kunnen worden opgeslagen in de VARCHAR-velden van de logtabellen.
Kies verstandig het ontwerp van uw database-auditlogboek
We hebben verschillende alternatieven gezien voor het genereren van audit logging, maar geen enkele is echt optimaal. U moet een logboekstrategie volgen die de prestaties van uw database niet substantieel beïnvloedt, deze niet buitensporig laat groeien en die aan uw traceerbaarheidsvereisten kan voldoen. Als u alleen logboeken voor een paar tabellen wilt opslaan, zijn schaduwtabellen wellicht de handigste optie. Als u de flexibiliteit wilt om elke tabel te loggen, zijn generieke logtabellen wellicht het beste.
Heeft u een andere manier ontdekt om een controlelogboek bij te houden voor uw databases? Deel het in de opmerkingen hieronder - uw mede-databaseontwerpers zullen u zeer dankbaar zijn!