In verschillende van de projecten waaraan we hebben gewerkt, hebben klanten ons gevraagd om meer gebruikersacties in de database te loggen. Ze willen alle acties weten die de gebruikers in de applicatie uitvoeren, maar het vastleggen en vastleggen van alle menselijke interacties kan een uitdaging zijn. We moesten alle wijzigingen van gegevens die via het systeem werden uitgevoerd, loggen. Dit artikel beschrijft enkele van de valkuilen die we tegenkwamen en de benaderingen die we gebruikten om ze te overwinnen.
Inleiding
Ik werk als oplossingsarchitect bij financiële dienstverlening. Het is belangrijk om de laatste gebruiker bij te houden die een rij heeft gewijzigd. In de eenvoudigste gevallen volstaat het om het tijdstempel van de wijziging vast te leggen om traceerbaarheid te hebben van veranderingen. Hier is een eenvoudig voorbeeld van een tabel waarin klantovereenkomsten zijn opgeslagen die last_changed . bevatten kolommen voor gebruiker en tijdstempel.
Toch is dit in sommige gevallen niet voldoende. We moeten vaak volledige traceerbaarheid hebben (inclusief voor en na "afbeeldingen" van de gegevens). In sommige gevallen hebben we ook controleerbaarheid . nodig (wie, wat, wanneer).
Helaas zijn veel van onze systemen niet ontworpen om traceerbaarheid en controleerbaarheid te bieden. We moesten reverse engineeren deze vereisten voor bedrijfsvoering in de systemen.
Traceerbaarheid
In sommige gevallen hebben we ontdekt dat traceerbaarheid eenvoudig te realiseren is. Terwijl we het bij andere moeilijk of zelfs onmogelijk vonden. Afhankelijk van uw systeem kan de oplossing eenvoudig zijn. Uw gegevenstoegang kan een eenvoudige injectie van logging van voor- en nabeelden van de gegevens mogelijk maken. Deze logging kan zo worden geïmplementeerd dat de resultaten worden opgeslagen in een databasetabel in plaats van in een logbestand. In sommige producten hebben we dit op een eenvoudige manier bereikt door de persistentie laag. Dit was bijvoorbeeld mogelijk met Sluimerstand .
Hier ziet u een vermelding voor elk audittrail-item, plus er zijn voor- en na-waarden voor elke kolom die is gewijzigd. Ook in het geval dat een rij wordt verwijderd, slaan we die informatie op met de functioncode wissen aangeeft. We hebben ervoor gekozen om varchar(1) te gebruiken om de code van de functie (C, R, D) op te slaan die het type wijziging specificeert, in plaats van de naam of beschrijving van de "bewerking" (Create, Update, Delete) die werd uitgevoerd . De instance_key bevat de primaire sleutel van het item dat is toegevoegd, gewijzigd of verwijderd, voor traceerbaarheid.
Toch kan het zijn dat uw datatoegangslaag niet de benodigde functionaliteit voor u biedt. Voor andere producten deed onze gegevenstoegangslaag dat niet. In die gevallen vergde de traceerbaarheid complexe veranderingen. U heeft bijvoorbeeld de ophaal- en logboekregistratie . nodig van alle gegevens vóór wijziging. Zoals ik al schreef, is dit mogelijk, maar het kan complex zijn om in te voeren. Ontwikkelaars zouden een opvraging van elke rij moeten maken voordat ze een rij kunnen wijzigen. Het zou niet mogelijk zijn om een update uit te voeren zonder een select.
Hoe kun je traceerbaarheid omzeilen? Een mogelijke oplossing is ervoor te zorgen dat u de beginsituatie van alle gegevens kent, dat wil zeggen de beginsituatie die wordt gecreëerd door statische gegevens die in het systeem zijn geladen. Dan zou je alle wijzigingen moeten loggen. Met andere woorden, wat zijn alle 'na'-afbeeldingen van de gegevens? Op deze manier zou het mogelijk zijn om "vooruit te rollen ” van de geladen statische gegevens. Alle tot dan toe gemaakte updates worden toegepast. Dit is een minder dan ideale situatie, maar kan acceptabel zijn.
Een eenvoudige tabel kan worden gebruikt als de enige beschikbare informatie de nieuwe waarde is en niet de vorige waarde.
Controleerbaarheid
In sommige situaties moeten we ervoor zorgen dat alle acties die in het systeem worden ondernomen volledig controleerbaar zijn . Wie logde op welk moment in? Welke acties heeft elke gebruiker in het systeem ondernomen, waaronder alleen het bekijken van gegevens? Dit is belangrijk omdat het aanzienlijk kan zijn als een gebruiker naar een betaling kijkt.
Om fijnkorrelige tracering te bereiken kan moeilijk zijn om alleen naar databasetoegang te kijken. We moeten vaak op een hoger niveau kijken en de uitgevoerde acties of diensten onderzoeken. In sommige gevallen waren we in staat om elke serviceoproep te traceren om te weten wat een gebruiker op welk moment deed. Met een webservice input/output-controller was het loggen van serviceverzoeken vrij eenvoudig.
Hier is een voorbeeld van een eenvoudig gebruikersauditlogboek waarin we de actie vastleggen die elke gebruiker uitvoert. In de volgende sectie “Bewijs” bespreek ik enkele kwesties over deze aanpak.
Hieronder volgt een korte tabelbeschrijving:
De user_audit tabel bevat gegevenscontrole-items met een tijdstempel. De primaire sleutel bestaat uit de audit_entry_time stempel plus de user_id en bank_id plus de naam van de action uitgevoerd. De velden hebben een betekenis die overeenkomt met hun naam. De controletabel slaat het result op van de actie, plus de daadwerkelijke class die de actie uitvoerde, de invoer parameters en eventuele errors .
Hier is nog een voorbeeld van een audittrail waarin we de voor- en na-afbeeldingen vastleggen van gegevens die in een bepaalde tabel zijn gewijzigd (samen met de uitgevoerde actie, gebruikersreferenties en tijdstempel).
De audit_trail tabel bevat controle-items van voor en na afbeeldingen van de gegevens. De primaire sleutel bestaat uit de audit_gen_key dat is een sleutel die door de toepassing wordt gegenereerd. De velden hebben een betekenis die overeenkomt met hun naam. De naam van de databasetabel waarvoor deze audittrail-invoer is vastgelegd, wordt opgeslagen in modified_table , plus de "before" afbeelding wordt opgeslagen in prev_value en de "na" afbeelding in new_value . De module die de wijziging uitvoert en de funct_type van wijziging (Creëren, Updaten, Verwijderen) worden ook opgeslagen. Ten slotte de controle-informatie van de user_id (en bijbehorende bank_id ) plus het tijdstempel van de wijziging (date_last_changed ).
Dan gaan we een uitdaging aan. Bij het loggen van zowel traceerbaarheidsinformatie als auditability-informatie vindt het loggen twee keer plaats. Vanuit auditstandpunt is dit vervelend. Auditors moeten ervoor zorgen dat de informatie tussen deze twee logboeken hetzelfde is.
Bewijs
Een andere uitdaging was het loggen van alle gebruikersacties . Dit wordt vaak vereist door auditors in de financiële dienstverlening.
Nu hebben we een echte uitdaging. Onze oplossing was om te zorgen voor centrale traceerbaarheid en auditability logging. Centrale "interfaces" zorgen ervoor dat alle implementaties van die interface logging bevatten. Het was eenvoudig om ervoor te zorgen dat alle geschikte klassen de interface implementeerden.
Dit zorgt natuurlijk niet voor 100% bewijs van logging. Het is een sterke veiligheidscontrole dat alle relevante klassen werden geregistreerd zoals vereist.
Conclusie
Reverse engineering van nieuwe bedrijfsfunctionaliteit in een bestaand systeem is altijd een uitdaging. Dit kan zelfs nog meer het geval zijn wanneer de geïmplementeerde functionaliteit naar de kern gaat.