В няколко от проектите, по които сме работили, клиентите са ни помолили да регистрираме повече потребителски действия в базата данни. Те искат да знаят всички действия, които потребителите извършват в приложението, но заснемането и записването на всички човешки взаимодействия може да бъде предизвикателство. Трябваше да регистрираме всички модификации на данните, извършени чрез системата. Тази статия описва някои от подводните камъни, които срещнахме, и подходите, които използвахме, за да ги преодолеем.
Въведение
Работя като архитект на решенията във финансовите услуги. Важно е да запазите запис на последния потребител, който е променил ред. В най-простите случаи е достатъчно да запишете времевата марка на модификацията, за да има проследяемост на промените. Ето прост пример за таблица, която съхранява споразумения с клиенти, която включва last_changed колони за потребител и времева марка.
Но в някои случаи това не е достатъчно. Често трябва да имаме пълна проследимост (включително изображения преди и след от данните). В някои случаи се нуждаем и отконтрол (кой, какво, кога).
За съжаление, много от нашите системи не са проектирани да предоставят проследимост и одит. Трябваше да направим обратно инженерство тези изисквания за бизнес операции в системите.
Проследяемост
В някои случаи установихме, че проследимостта е лесна за постигане. Докато в други ни е трудно или дори невъзможно. В зависимост от вашата система, решението може да е просто. Вашият достъп до данни може да позволи просто инжектиране на регистриране на изображения преди и след на данните. Това регистриране може да бъде реализирано така, че резултатите да се съхраняват в таблица на база данни, а не в регистрационен файл. При някои продукти постигнахме това по директен начин чрез постоянството слой. Например това беше възможно сХибернация .
Тук можете да видите запис за всеки елемент от одитната пътека, плюс ще има стойности преди и след за всяка колона, която се е променила. Също така, в случай, че ред е изтрит, ние запазваме тази информация с functioncode което показва изтриване. Избрахме да използваме varchar(1) за съхраняване на кода на функцията (C, R, D), указващ вида на модификацията, а не името или описанието на „операцията“ (Създаване, Актуализиране, Изтриване), която беше извършена . instance_key съдържа първичния ключ на елемента, който е бил добавен, променен или изтрит за проследимост.
И все пак може да се окаже, че вашият слой за достъп до данни не предоставя необходимата функционалност за вас. За други продукти нашият слой за достъп до данни не го направи. В тези случаи проследимостта изисква сложни промени. Например, може да се нуждаете от извличане и регистриране на всякакви данни преди промяна. Както писах, това е възможно, но може да бъде сложно за въвеждане. Разработчиците ще трябва да създадат извличане на всеки ред, преди да променят ред. Не би било възможно актуализацията да се изпълнява без избор.
Как можете да заобиколите проследимостта? Едно възможно решение е да се гарантира, че знаете началната ситуация на всички данни, тоест началната ситуация, създадена от всички статични данни, заредени в системата. След това ще трябва да регистрирате всички модификации. С други думи, какви са всички „след“ изображения на данните? По този начин би било възможно „превъртане напред ” от заредените статични данни. Всички актуализации, направени до този момент, се прилагат. Това не е идеална ситуация, но може да е приемлива.
Може да се използва проста таблица, ако единствената налична информация е новата стойност, а не предишната стойност.
Проверка
В някои ситуации трябва да гарантираме, че всички действия, предприети в системата, са напълно контролируеми . Кой е влязъл в кое време? Какви действия е предприел всеки потребител в системата, включително само преглед на данни? Това е важно, защото може да е важно, ако потребителят погледне плащане.
За постигане нафинно трасиране може да е трудно да гледате само достъпа до базата данни. Често трябва да гледаме на по-високо ниво и да изследваме извършените действия или услуги. В някои случаи успяхме да проследим всяко обаждане на услуга, за да разберем какво е направил потребителят в кое време. С контролер за вход/изход на уеб услуги регистрирането на заявки за услуги беше доста лесно.
Ето пример за прост журнал за одит на потребители, където записваме действието, което всеки потребител извършва. Обсъждам някои въпроси относно този подход в следващия раздел „Доказателство“.
Кратко описание на таблицата е дадено по-долу:
user_audit таблицата съдържа записи за одит на данни, които са с времеви печат. Първичният ключ се състои от audit_entry_time печат плюс user_id и bank_id плюс името на action изпълнено. Полетата имат значения, които съответстват на техните имена. Таблицата за одит съхранява result на действието, плюс действителния class който е изпълнил действието, неговите входни parameters и всякакви errors .
Ето още един пример за одитна пътека, където записваме изображения преди и след на данни, които са били променени в определена таблица (заедно с извършеното действие, потребителски идентификационни данни и времеви печат).
audit_trail таблицата съдържа записи за одит на изображения преди и след на данните. Първичният ключ се състои от audit_gen_key това е ключ, генериран от приложението. Полетата имат значения, които съответстват на техните имена. Името на таблицата на базата данни, за която е записан този запис в одитната пътека, се съхранява в modified_table , плюс изображението „преди“ се съхранява в prev_value и изображението „след“ в new_value . module който извършва модификацията и funct_type на промяна (Създаване, Актуализиране, Изтриване) също се съхраняват. И накрая, информацията за одита на user_id (и съответният bank_id ) плюс времевата марка на промяната (date_last_changed ).
Тогава се натъкнахме на предизвикателство. Когато регистрирате както информация за проследимост, така и информация за одит, регистрирането се извършва два пъти. От гледна точка на одита това е досадно. Одиторите трябва да гарантират, че информацията е една и съща между тези два журнала.
Доказателство
Друго предизвикателство беше да се осигури регистриране на всички потребителски действия . Това често се изисква от одиторите в индустрията на финансовите услуги.
Сега имаме истинско предизвикателство. Нашето решение беше да осигурим централно регистриране на проследяване и одитиране. Централните „интерфейси“ гарантират, че всички реализации на този интерфейс включват регистриране. Беше лесно да се гарантира, че всички подходящи класове изпълняват интерфейса.
Разбира се, това не гарантира 100% доказателство за регистриране. Силна проверка за безопасност е, че всички подходящи класове са регистрирали според изискванията.
Заключение
Обратното проектиране на нова бизнес функционалност в съществуваща система винаги е предизвикателство. Това може да се случи още повече, когато внедрената функционалност е до ядрото.
