Czy logi audytowe w aplikacji są w stanie nam w czymś pomóc? A może to tylko dziwne wymaganie biznesu?

Dziś się tego dowiesz.

Większość systemów, z których korzystamy i które tworzymy, operuje na danych. Jedną z akcji na tych danych jest oczywiście ich modyfikacja. Taka modyfikacja może mieć wpływ na całość działania systemu, a wtedy powinna być szczególnie chroniona.

Logi w użyciu

Wyobraźmy sobie następującą sytuację.

Mamy aplikację e-commerce. Możemy w niej dokonywać zakupów i opłacać je. Jedną z metod płatności za takie zamówienie jest bezpośredni przelew na konto bankowe. Wtedy numer takiego konta bankowego musi być zapisany w danych aplikacji.

Być może nawet istnieje funkcjonalność zmiany numeru konta bankowego na wypadek, gdyby zaistniała taka potrzeba biznesowa.

Jednak co by się stało, gdyby pewien administrator systemu (który ma dostęp do panelu zmiany numeru konta) postanowił je mienić na swoje własne. Wtedy cały przychód z zakupów w naszym sklepie online byłby wysyłany na konto tego administratora. Właściwie to nie cały, tylko kwota z tej części zamówień, które byłyby opłacane bezpośrednim przelewem bankowym. Co właściwie tylko utrudniałoby wykrycie takiej modyfikacji, a właściwie ataku.

Nasz “złośliwy administrator”, wiedząc, że ktoś może mieć do niego pretensje o tę zmianę (skądinąd słuszne), postanowił po tygodniu zmienić z powrotem numer konta na oryginalny. W ten sposób zmniejszył ilość skradzionych pieniędzy, ale równocześnie ograniczył szanse wykrycia.

Pod koniec miesiąca podczas bilansowania konta ze stanem zamówień w sklepie okazało się, że na koncie brakuje dość sporej sumy. Po głębszej analizie okazało się, że przez cały tydzień na konto nie wpłynęły żadne środki poza środkami z bramek płatniczych.

Podejrzewamy, że mogło dojść do oszustwa. Jednak okazało się, że na poziomie bazy danych nie mamy zapisanych żadnych informacji o tym kto i kiedy ostatnio zmieniał numer konta. Przeszukujemy logi transakcyjne bazy danych i rzeczywiście widzimy, że ktoś dokonał zmiany numeru konta na nieznane, a potem zmienił je na oryginalne. Jednak nadal nie wiemy, kto to zrobił. Szukamy w logach aplikacyjnych, jednak one są trzymane tylko przez dwa tygodnie, a od tego czasu minęły już cztery. Jesteśmy w kropce. Nie wiedząc, kto dokonał takiej malwersacji, nie jesteśmy w stanie pociągnąć nikogo do odpowiedzialności za kradzież naszych pieniędzy.

A wystarczyłoby odkładać informacje o modyfikacji tak istotnych danych w systemie. Wtedy jasno byśmy widzieli, kto, kiedy zmienił numer konta i na jaki. Moglibyśmy jeszcze do tego dołożyć mechanizm dwuetapowego zatwierdzania takiej kluczowej zmiany, jednak skupmy się tutaj głównie na audycie zmian.

Czy logi audytowe to tylko zmiany danych?

Niekoniecznie. Pełen audyt zmian dotyczy również zmian dokonywanych wyników zwracanych na podstawie silników decyzyjnych. Dlaczego to istotne? Ponieważ często chcemy wiedzieć jaką odpowiedź, czy decyzje zobaczył użytkownik, nawet jeżeli jest to po prostu wynik pewnego algorytmu na istniejących danych.

Ze względu na to, że algorytmy potrafią się zmieniać w czasie, nie zawsze jest łatwo odtworzyć informacje, które zobaczył użytkownik tylko na bazie danych źródłowych do takiego obliczenia.

Co więcej, logi audytowe to nie tylko śledzenie zmian. Niektóre regulacje wymagają nawet odnotowywania samego dostępu do danych szczególnie chronionych (np. do pełnych danych kart kredytowych według PCI-DSS).

Do czego są potrzebne logi audytowe w systemie?

• Śledzenie wszelkich operacji na kluczowych danych — pozwala to wyświetlić użytkownikom historię zmian danych biznesowych. Może to pomóc podejmować lepsze decyzje biznesowe. Na przykład widząc tendencję zmiany ceny skorelowaną z liczbą zamówionych egzemplarzy, możemy dobrać najbardziej optymalną cenę jednostkową.
• Analiza ścieżki ataku (po fakcie) – tak jak już pokazaliśmy w przykładzie. Dokładny log operacji pozwoli prześledzić ścieżkę, w jaki sposób doszło do ataku i co atakujący po kolei robił w naszym systemie. Pełny log historii zmian systemie, w tym log techniczny, pozwoli nam dokładnie ustalić wszelkie działania atakującego.
• Rozwiązywanie problemów — śledzenie zmian pozwala również na dokładniejsze badanie problemów w przypadku ich zaistnienia Produkcji. Szczególnie rzadko występujących i trudnych do zreplikowania problemów. Dzięki dokładnym logom jesteśmy w stanie prześledzić ścieżkę prowadzącą do błędnego zachowania.
• Audyty regulacyjne — w przypadku niektórych regulacji (jak na przykład PCI-DSS) jesteśmy zobowiązani do przechowywania pełnej historii zmiana jak również dostępu do informacji.
• Zwiększenie jakości danych — sam log audytowy pozwala również pośrednio poprawić jakość danych w systemie. Dzięki temu, że wiemy, jak dane się zmieniają jesteśmy w stanie poprawić procesy tych zmian, żeby zagwarantować lepszą jakość.

Jaki powinien być doby log audytowy?

• Transparentny — powinien udostępniać pełną widoczność wszelkich operacji na danych, zarówno modyfikacji jak i odczytu. Choć to też zależy od wymagań biznesowych i regulacyjnych.
• Powinien definiować odpowiedzialność za dane — każda akcja na danych w systemie powinna mieć przypisanego użytkownika, najlepiej użytkownika, którego jesteśmy w stanie jednoznacznie zidentyfikować. Tak więc lepiej nie w postaci — imię i nazwisko, ale raczej za pomocą ID tego użytkownika w naszym systemie zarządzania dostępem. Zawsze może się okazać, że jest wielu Janów Kowalskich, którzy korzystają z tego systemu.
• Zgodny z regulacjami — dla określonego typu danych (jak dane kart płatniczych w przypadku PCI-DSS lub dane medyczne w przypadku HIPPA) szczegółowy log audytowy jest wymagany regulacyjnie. A to oznacza, że możemy być z tego faktu rozliczeni przez zewnętrznego audytora.

Jak dobrze zaimplementować logi audytowe w systemie?

Często architektura systemu z definicji wspiera pełną historię wszelkich zmian (np. architektura Event Storming). Jednak w większości systemów trzeba o to zadbać.

Podstawowe dane, które powinny znaleźć się w takim logu audytowym to:

• Kto? – kto dokonał danej zmiany, w jednoznacznie identyfikowalny sposób;
• Kiedy? – kiedy ta zmiana została wykonana i być może kiedy weszła w życie w systemie;
• Gdzie? – jaka właściwość naszych danych została zmieniona;
• Jak? – jaką operację logujemy;
• Co? – jaka była poprzednia wartość zmienionej właściwości.

Ta podstawowa lista pokrywa większość potrzeb wynikających z regulacji lub potencjalnych scenariuszy użycia takiego logu audytowego.

Warto o to zadbać w systemie, szczególnie że często istnieją dojrzałe biblioteki czy narzędzia, które mocno automatyzują cały ten proces.