V několika projektech, na kterých jsme pracovali, nás zákazníci požádali o přihlášení více uživatelských akcí do databáze. Chtějí znát všechny akce, které uživatelé v aplikaci provádějí, ale zachytit a zaznamenat všechny lidské interakce může být náročné. Veškeré úpravy dat provedené přes systém jsme museli logovat. Tento článek popisuje některá úskalí, na která jsme narazili, a přístupy, které jsme použili k jejich překonání.
Úvod
Pracuji jako architekt řešení ve finančních službách. Je důležité uchovávat záznam o posledním uživateli, který upravil řádek. V nejjednodušších případech stačí zaznamenat časové razítko úpravy, aby byla sledovatelnost změn. Zde je jednoduchý příklad tabulky, která ukládá zákaznické smlouvy, které obsahují last_changed sloupce pro uživatele a časové razítko.
V některých případech to však nestačí. Často musíme mít plnou sledovatelnost (včetně před a po „obrázcích“ údajů). V některých případech potřebujeme také kontrolovatelnost (kdo, co, kdy).
Bohužel mnoho našich systémů nebylo navrženo tak, aby poskytovaly sledovatelnost a auditovatelnost. Potřebovali jsme reverzní inženýrství tyto požadavky na obchodní operace do systémů.
Vysledovatelnost
V některých případech jsme zjistili, že sledovatelnost je snadná. Zatímco v jiných jsme to považovali za obtížné nebo dokonce nemožné. V závislosti na vašem systému může být řešení jednoduché. Váš přístup k datům může umožnit jednoduchou injekci protokolování obrázků dat před a po. Toto protokolování může být implementováno tak, že výsledky jsou uloženy v databázové tabulce spíše než v souboru protokolu. U některých produktů jsme toho dosáhli přímočarým způsobem prostřednictvím perzistence vrstva. Například to bylo možné pomocí Hibernace .
Zde můžete vidět záznam pro každou položku auditního záznamu a navíc budou hodnoty před a po pro každý sloupec, který se změnil. Také v případě, že je řádek smazán, uložíme tyto informace pomocí functioncode označující smazání. Rozhodli jsme se použít varchar(1) k uložení kódu funkce (C, R, D) určující typ modifikace, spíše než názvu nebo popisu „operace“ (Create, Update, Delete), která byla provedena. . instance_key obsahuje primární klíč položky, která byla přidána, upravena nebo odstraněna z důvodu sledovatelnosti.
Přesto se může stát, že vaše vrstva pro přístup k datům vám neposkytuje potřebné funkce. U ostatních produktů naše vrstva pro přístup k datům ne. V těchto případech vyžadovala sledovatelnost komplexní změny. Můžete například potřebovat načítání a protokolování jakýchkoli údajů před úpravou. Jak jsem psal, je to možné, ale zavedení může být složité. Před úpravou řádku by vývojáři museli vytvořit načtení každého řádku. Bez výběru by nebylo možné spustit aktualizaci.
Jak můžete obejít sledovatelnost? Jedním z možných řešení je zajistit, že znáte výchozí situaci všech dat, tedy výchozí situaci vytvořenou jakýmikoli statickými daty načtenými do systému. Poté byste museli zaznamenat všechny změny. Jinými slovy, jaké jsou všechny obrázky dat „po“? Tímto způsobem by bylo možné „rolovat dopředu ” z načtených statických dat. Budou použity všechny aktualizace provedené do té doby. Toto není ideální situace, ale může být přijatelná.
Pokud jedinou dostupnou informací je nová hodnota, nikoli předchozí hodnota, lze použít jednoduchou tabulku.
Kontrola
V některých situacích musíme zajistit, aby všechny akce provedené v systému byly plně auditovatelné . Kdo se v kolik hodin přihlásil? Jaké akce provedl každý uživatel v systému, včetně pouze zobrazení dat? To je důležité, protože to může být významné, pokud se uživatel podíval na platbu.
K dosažení jemného trasování může být obtížné dívat se pouze na přístup k databázi. Často se musíme dívat na vyšší úroveň a zkoumat prováděné akce nebo služby. V některých případech jsme byli schopni vysledovat každé volání služby, abychom věděli, co uživatel v kterou dobu dělal. S řadičem vstupu/výstupu webové služby bylo protokolování požadavků na služby docela snadné.
Zde je příklad jednoduchého protokolu uživatelského auditu, kde zaznamenáváme akci, kterou každý uživatel provádí. Některé problémy týkající se tohoto přístupu diskutuji v další části „Důkaz“.
Krátký popis tabulky je uveden níže:
user_audit tabulka obsahuje záznamy auditu dat, které jsou opatřeny časovým razítkem. Primární klíč se skládá z audit_entry_time razítko plus user_id a bank_id plus název action provedeno. Pole mají význam, který odpovídá jejich názvům. Tabulka auditu ukládá result akce plus aktuální class který akci provedl, její vstupní parameters a všechny errors .
Zde je další příklad auditní stopy, kde zaznamenáváme obrázky před a po dat, která byla upravena v konkrétní tabulce (spolu s provedenou akcí, přihlašovacími údaji uživatele a časovým razítkem).
audit_trail tabulka obsahuje auditní záznamy snímků dat před a po. Primární klíč se skládá z audit_gen_key to je klíč generovaný aplikací. Pole mají význam, který odpovídá jejich názvům. Název databázové tabulky, pro kterou je tento záznam auditní stopy zaznamenán, je uložen v modified_table , plus obrázek „před“ je uložen v prev_value a obrázek „po“ v new_value . module který provádí úpravu a funct_type změny (Vytvořit, Aktualizovat, Smazat) jsou také uloženy. Nakonec informace o auditu user_id (a odpovídající bank_id ) plus časové razítko změny (date_last_changed ).
Pak jsme narazili na výzvu. Při protokolování informací o sledovatelnosti i informací o auditovatelnosti dochází k protokolování dvakrát. Z hlediska auditu je to nepříjemné. Auditoři musí zajistit, aby informace mezi těmito dvěma protokoly byly stejné.
Důkaz
Dalším úkolem bylo zajistit protokolování všech uživatelských akcí . To často vyžadují auditoři v odvětví finančních služeb.
Nyní nás čeká opravdová výzva. Naším řešením bylo zajistit centrální sledovatelnost a protokolování auditovatelnosti. Centrální „rozhraní“ zajišťují, že všechny implementace tohoto rozhraní zahrnují protokolování. Bylo přímočaré zajistit, aby všechny příslušné třídy implementovaly rozhraní.
To samozřejmě nezajistí 100% průkaz těžby. Je to přísná bezpečnostní kontrola, že všechny příslušné třídy byly protokolovány podle potřeby.
Závěr
Zpětné inženýrství nových obchodních funkcí do stávajícího systému je vždy výzvou. To může být ještě více v případě, kdy implementovaná funkčnost jde do jádra.