W kilku projektach, nad którymi pracowaliśmy, klienci poprosili nas o rejestrowanie większej liczby działań użytkowników w bazie danych. Chcą znać wszystkie czynności wykonywane przez użytkowników w aplikacji, ale przechwytywanie i rejestrowanie wszystkich interakcji międzyludzkich może być trudne. Musieliśmy rejestrować wszystkie modyfikacje danych dokonywane za pośrednictwem systemu. W tym artykule opisano niektóre napotkane przez nas pułapki i metody, które zastosowaliśmy, aby je przezwyciężyć.
Wprowadzenie
Pracuję jako architekt rozwiązań w usługach finansowych. Ważne jest, aby prowadzić rejestr ostatniego użytkownika, który zmodyfikował wiersz. W najprostszych przypadkach wystarczy zarejestrować znacznik czasu modyfikacji, aby mieć identyfikowalność zmian. Oto prosty przykład tabeli, w której przechowywane są umowy z klientami zawierające last_changed kolumny dla użytkownika i znacznika czasu.
Jednak w niektórych przypadkach to nie wystarczy. Często musimy mieć pełną identyfikowalność (w tym przed i po „obrazach” danych). W niektórych przypadkach potrzebujemy również kontroli (kto, co, kiedy).
Niestety wiele naszych systemów nie zostało zaprojektowanych z myślą o zapewnieniu identyfikowalności i możliwości kontroli. Musieliśmy zaprojektować inżynierię wsteczną te wymagania dotyczące operacji biznesowych w systemach.
Identyfikowalność
W niektórych przypadkach uznaliśmy, że identyfikowalność jest łatwa do osiągnięcia. Podczas gdy w innych okazało się to trudne lub wręcz niemożliwe. W zależności od systemu rozwiązanie może być proste. Dostęp do danych może umożliwiać proste wstrzyknięcie rejestrowania obrazów przed i po danych. To rejestrowanie może być zaimplementowane w taki sposób, że wyniki są przechowywane w tabeli bazy danych, a nie w pliku dziennika. W przypadku niektórych produktów osiągnęliśmy to w prosty sposób dzięki wytrwałości warstwa. Na przykład było to możliwe dzięki Hibernacji .
Tutaj możesz zobaczyć wpis dla każdego elementu ścieżki audytu, a także wartości przed i po dla każdej zmienionej kolumny. Ponadto, w przypadku usunięcia wiersza, zapisujemy te informacje za pomocą functioncode oznaczający usunięcie. Zdecydowaliśmy się użyć varchar(1) do przechowywania kodu funkcji (C, R, D) określającego typ modyfikacji, a nie nazwę lub opis „operacji” (Create, Update, Delete), która została wykonana . instance_key zawiera klucz podstawowy elementu, który został dodany, zmodyfikowany lub usunięty, w celu śledzenia.
Może się jednak zdarzyć, że warstwa dostępu do danych nie zapewnia niezbędnej funkcjonalności. W przypadku innych produktów nasza warstwa dostępu do danych nie. W takich przypadkach identyfikowalność wymagała złożonych zmian. Na przykład możesz potrzebować odzyskiwania i rejestrowania wszelkich danych przed modyfikacją. Jak pisałem, jest to możliwe, ale wdrożenie może być skomplikowane. Deweloperzy musieliby utworzyć pobieranie każdego wiersza przed modyfikacją wiersza. Aktualizacja nie byłaby możliwa bez wyboru.
Jak można obejść identyfikowalność? Jednym z możliwych rozwiązań jest upewnienie się, że znasz sytuację początkową wszystkich danych, to znaczy sytuację początkową stworzoną przez dowolne statyczne dane załadowane do systemu. Następnie musiałbyś rejestrować wszystkie modyfikacje. Innymi słowy, jakie są wszystkie obrazy „po” danych? W ten sposób możliwe byłoby „przesunięcie do przodu ” z załadowanych danych statycznych. Wszystkie aktualizacje dokonane do tego czasu są stosowane. Nie jest to idealna sytuacja, ale może być do przyjęcia.
Można użyć prostej tabeli, jeśli jedyną dostępną informacją jest nowa wartość, a nie poprzednia wartość.
Sprawność
W niektórych sytuacjach musimy upewnić się, że wszystkie działania podejmowane w systemie są w pełni kontrolowalne . Kto się zalogował o której godzinie? Jakie działania wykonał każdy użytkownik w systemie, w tym tylko przeglądanie danych? Jest to ważne, ponieważ może mieć znaczenie, jeśli użytkownik obejrzy płatność.
Aby osiągnąć drobnoziarniste śledzenie może być trudne, patrząc tylko na dostęp do bazy danych. Często musimy spojrzeć na wyższy poziom i przyjrzeć się wykonywanym czynnościom lub usługom. W niektórych przypadkach byliśmy w stanie prześledzić każde zgłoszenie serwisowe, aby dowiedzieć się, co użytkownik zrobił i o której godzinie. Dzięki kontrolerowi wejścia/wyjścia usługi sieciowej rejestrowanie żądań usług było dość łatwe.
Oto przykład prostego dziennika audytu użytkownika, w którym rejestrujemy akcję wykonywaną przez każdego użytkownika. Niektóre kwestie dotyczące tego podejścia omawiam w kolejnym rozdziale „Dowód”.
Poniżej znajduje się krótki opis tabeli:
user_audit tabela zawiera wpisy audytu danych, które są oznaczone znacznikiem czasu. Klucz podstawowy składa się z audit_entry_time pieczęć plus user_id i bank_id plus nazwa action wykonywane. Pola mają znaczenia odpowiadające ich nazwom. Tabela kontroli przechowuje result akcji, plus rzeczywista class który wykonał akcję, jego dane wejściowe parameters i wszelkie errors .
Oto kolejny przykład ścieżki audytu, w której rejestrujemy obrazy danych przed i po danych, które zostały zmodyfikowane w określonej tabeli (wraz z wykonaną czynnością, danymi uwierzytelniającymi użytkownika i znacznikiem czasu).
audit_trail tabela zawiera wpisy audytu obrazów przed i po danych. Klucz podstawowy składa się z audit_gen_key to jest klucz generowany przez aplikację. Pola mają znaczenia odpowiadające ich nazwom. Nazwa tabeli bazy danych, dla której zapisany jest ten wpis ścieżki audytu, jest przechowywana w modified_table , plus obraz „przed” jest przechowywany w prev_value i obraz „po” w new_value . module który wykonuje modyfikację i funct_type modyfikacji (Utwórz, Aktualizuj, Usuń). Na koniec informacje kontrolne user_id (i odpowiadający bank_id ) plus sygnatura czasowa zmiany (date_last_changed ).
Następnie podejmujemy wyzwanie. Podczas rejestrowania zarówno informacji o możliwości śledzenia, jak i kontroli, rejestrowanie odbywa się dwukrotnie. Z punktu widzenia audytu jest to denerwujące. Audytorzy muszą upewnić się, że informacje w tych dwóch dziennikach są takie same.
Dowód
Kolejnym wyzwaniem było zapewnienie rejestrowania wszystkich działań użytkownika . Jest to często wymagane przez audytorów w branży usług finansowych.
Teraz mamy prawdziwe wyzwanie. Nasze rozwiązanie polegało na zapewnieniu centralnego śledzenia i rejestrowania możliwości audytu. Centralne „interfejsy” zapewniają, że wszystkie implementacje tego interfejsu zawierają rejestrowanie. Upewnienie się, że wszystkie odpowiednie klasy implementują interfejs, było proste.
Oczywiście nie gwarantuje to 100% dowodu logowania. Jest to silne sprawdzenie, czy wszystkie odpowiednie klasy były rejestrowane zgodnie z wymaganiami.
Wniosek
Inżynieria wsteczna nowych funkcji biznesowych w istniejącym systemie jest zawsze wyzwaniem. Może się tak stać jeszcze bardziej, gdy zaimplementowana funkcjonalność trafia do rdzenia.
