Co to jest DAM? Database Activity Monitoring, czyli monitorowanie baz danych

DAM (Database Activity Monitoring) to system bezpieczeństwa, który na bieżąco rejestruje i analizuje wszystko, co dzieje się w bazie danych: logowania, zapytania SQL, zmiany uprawnień i struktury tabel. Jego zadaniem jest odpowiedzieć na pytanie „kto, kiedy i w jaki sposób dotknął danych” — i zaalarmować, gdy coś odbiega od normy.

Najważniejsza cecha DAM to niezależność od administratora bazy. Logi, które baza prowadzi sama, kontroluje DBA. Monitorowanie baz danych w modelu DAM działa obok bazy, więc nawet konto z pełnymi uprawnieniami nie może po cichu wyłączyć nadzoru ani zatrzeć śladów.

Co to jest DAM i skąd się wziął termin

Pojęcie Database Activity Monitoring spopularyzowała firma analityczna Gartner w drugiej połowie lat 2000. Firmy coraz częściej musiały wykazać audytorom, kto miał dostęp do danych kart płatniczych czy danych finansowych, a natywne narzędzia baz nie dawały wiarygodnej, scentralizowanej ścieżki audytu.

Z czasem kategoria rozrosła się i bywa nazywana Database Audit and Protection (DAP), a obecnie często wchodzi w skład szerszych platform ochrony danych (Data Security Platform). Sama idea pozostaje ta sama: niezależny nadzór nad tym, co dzieje się z danymi w systemach bazodanowych — Oracle, Microsoft SQL Server, PostgreSQL, MySQL, Db2, a coraz częściej także w bazach chmurowych i NoSQL.

DAM to nie Digital Asset Management

Ten sam skrót ma drugie, zupełnie inne znaczenie. Digital Asset Management to system do przechowywania, opisywania i wersjonowania plików cyfrowych — zdjęć, grafik, filmów, szablonów marketingowych. Korzystają z niego działy marketingu i agencje. Jeśli trafiłeś tu, szukając narzędzia do katalogowania materiałów graficznych, chodzi Ci o Digital Asset Management. Dalsza część artykułu dotyczy wyłącznie DAM w sensie bezpieczeństwa baz danych.

Do czego służy Database Activity Monitoring

Systemy DAM rozwiązują kilka konkretnych problemów, z którymi zwykły firewall czy antywirus sobie nie poradzą, bo nie rozumieją, co oznacza dane zapytanie SQL.

Kontrola kont uprzywilejowanych

Administratorzy baz, administratorzy systemów i programiści z dostępem produkcyjnym mogą zrobić z danymi praktycznie wszystko. DAM rejestruje ich działania i alarmuje, gdy np. ktoś o 2:00 w nocy eksportuje całą tabelę klientów, nadaje sobie nowe uprawnienia albo wyłącza audyt. To uzupełnienie systemów PAM do zarządzania dostępem uprzywilejowanym: PAM kontroluje, kto i kiedy dostaje dostęp, a DAM — co z tym dostępem zrobiono.

Monitorowanie aktywności aplikacji

Aplikacje łączą się z bazą zwykle jednym kontem technicznym, więc w logach bazy wszystkie operacje wyglądają tak samo. DAM uczy się typowego profilu zapytań aplikacji i wychwytuje odstępstwa: nietypowe zapytania, nagły wzrost liczby odczytanych wierszy, dostęp do tabel, z których aplikacja nigdy nie korzystała. Tak wykrywa się zarówno nadużycia pracowników działających przez aplikację, jak i przejęte konta.

Wykrywanie ataków, w tym SQL injection

Atak SQL injection z perspektywy bazy wygląda jak zapytanie, którego aplikacja normalnie nie wysyła — np. UNION SELECT na tabeli z hasłami albo zapytanie do słowników systemowych (information_schema). DAM potrafi takie zapytanie oznaczyć, a w trybie blokującym — zatrzymać. Pamiętaj jednak, że to ostatnia linia obrony. Podstawą są zapytania parametryzowane w kodzie, a przed aplikacją webową przydaje się WAF, czyli firewall aplikacji webowych.

Dowody dla audytu i zgodność z przepisami

RODO wymaga m.in. umiejętności wykazania, kto przetwarzał dane osobowe i czy doszło do naruszenia. PCI DSS wprost wymaga rejestrowania dostępu do danych posiadaczy kart. Do tego dochodzą wymagania NIS2 (w Polsce wdrażanej nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa) oraz regulacje sektorowe w bankowości. DAM daje jedną, trudną do zmanipulowania ścieżkę audytu i gotowe raporty, zamiast ręcznego zbierania logów z dziesiątek serwerów.

Jak działa DAM — trzy architektury zbierania danych

Najważniejsza decyzja przy wdrożeniu to sposób, w jaki system zbiera informacje o aktywności. Każda metoda ma inne mocne i słabe strony.

W praktyce dojrzałe wdrożenia łączą metody: agent na najważniejszych serwerach, monitorowanie sieci tam, gdzie nie można zainstalować agenta, i logi natywne dla usług chmurowych typu DBaaS, w których nie masz dostępu do systemu operacyjnego.

Tryb pasywny i tryb blokujący

Większość wdrożeń zaczyna od trybu pasywnego: system tylko obserwuje, uczy się normalnego ruchu i generuje alerty. Dopiero gdy reguły są dopracowane, można włączyć blokowanie wybranych operacji — np. zakaz DROP TABLE na produkcji poza oknem serwisowym albo odcięcie sesji, która masowo odczytuje dane osobowe. Zbyt agresywne reguły blokujące potrafią zatrzymać działanie aplikacji, więc wprowadza się je ostrożnie.

Najważniejsze funkcje systemów DAM

Konkretne produkty różnią się szczegółami, ale typowy zestaw funkcji wygląda tak:

• odkrywanie i klasyfikacja danych — skanowanie baz w poszukiwaniu kolumn z danymi wrażliwymi (PESEL, numery kart, adresy e-mail), żeby wiedzieć, co w ogóle trzeba chronić,
• rejestrowanie sesji i zapytań z pełnym kontekstem: użytkownik bazy, użytkownik systemu, adres IP, nazwa programu klienckiego, liczba zwróconych wierszy,
• polityki i alerty — reguły typu „alarm, gdy konto spoza grupy płacowej czyta tabelę wynagrodzeń”,
• analiza behawioralna — wykrywanie odchyleń od typowego zachowania użytkownika lub aplikacji,
• blokowanie i maskowanie — przerwanie sesji lub dynamiczne maskowanie danych w wynikach,
• ocena podatności — wykrywanie domyślnych haseł, brakujących poprawek, zbyt szerokich uprawnień,
• integracja z SIEM, systemami zgłoszeń i SOAR, aby alerty z bazy trafiały do zespołu SOC razem z innymi zdarzeniami.

DAM uzupełnia inne warstwy ochrony, a nie je zastępuje. System IDS i systemy NDR patrzą na ruch sieciowy ogólnie, DAM rozumie semantykę zapytań SQL i kontekst danych.

Monitorowanie bazy danych natywnymi narzędziami

Jeśli nie masz budżetu na komercyjny DAM, możesz zbudować jego uproszczoną wersję z natywnego audytu bazy i centralnego systemu logów. Poniżej przykłady dla popularnych silników.

PostgreSQL: rozszerzenie pgAudit

W pliku postgresql.conf dodaj bibliotekę i określ zakres audytu, a po restarcie serwera utwórz rozszerzenie:

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'ddl, role, write'
pgaudit.log_parameter = on

CREATE EXTENSION pgaudit;

Ustawienie ddl, role, write rejestruje zmiany struktury, operacje na rolach i uprawnieniach oraz modyfikacje danych. Odczyty (read) włączaj selektywnie — np. audytem obiektowym tylko dla wrażliwych tabel — bo na obciążonej bazie wygenerują ogromne ilości logów.

Microsoft SQL Server: SQL Server Audit

USE master;
CREATE SERVER AUDIT Audit_Dane TO FILE (FILEPATH = 'D:\Audit\');
ALTER SERVER AUDIT Audit_Dane WITH (STATE = ON);

USE Kadry;
CREATE DATABASE AUDIT SPECIFICATION Spec_Wynagrodzenia
  FOR SERVER AUDIT Audit_Dane
  ADD (SELECT, UPDATE ON OBJECT::dbo.Wynagrodzenia BY public)
  WITH (STATE = ON);

Taka konfiguracja zapisuje każdy odczyt i zmianę w tabeli wynagrodzeń, niezależnie od tego, kto je wykonał. Pliki audytu odczytasz funkcją sys.fn_get_audit_file.

Oracle i MySQL/MariaDB

W Oracle Database służy do tego Unified Auditing (CREATE AUDIT POLICY ... ACTIONS SELECT ON hr.employees;, a następnie AUDIT POLICY nazwa_polityki;). W MySQL audyt zapewnia MySQL Enterprise Audit (wersja komercyjna) lub wtyczki społecznościowe, a w MariaDB wtyczka server_audit.

Ważne: Natywny audyt nie daje rozdziału obowiązków. Administrator bazy może go wyłączyć, zmienić reguły lub usunąć pliki. Dlatego logi trzeba od razu wysyłać do zewnętrznego systemu (SIEM, centralny serwer logów), do którego DBA nie ma uprawnień zapisu.

DAM a inne metody ochrony baz danych

Monitorowanie to tylko część ochrony baz danych. Pełny obraz obejmuje kilka warstw, a DAM najlepiej sprawdza się, gdy pozostałe są już na miejscu:

1. Minimalne uprawnienia — osobne konta dla aplikacji, brak współdzielonych kont administracyjnych, przegląd ról co najmniej raz na kwartał. Pomaga w tym przemyślany model RBAC.
2. Szyfrowanie — TLS dla połączeń, szyfrowanie danych w spoczynku (TDE) i kopii zapasowych.
3. Hartowanie i aktualizacje — wyłączone zbędne funkcje, zmienione hasła domyślne, aktualne poprawki silnika bazy.
4. Bezpieczny kod — zapytania parametryzowane, walidacja danych wejściowych.
5. Monitorowanie (DAM lub natywny audyt + SIEM) — wykrywanie tego, czego nie zatrzymały poprzednie warstwy.

Dobrze zaprojektowana baza też ułatwia ochronę: gdy dane osobowe są wydzielone do kilku tabel zamiast rozsiane po całym schemacie, reguły audytu są prostsze i mniej kosztowne. Więcej o projektowaniu struktury tabel przeczytasz w artykule o normalizacji i denormalizacji baz danych, a przegląd silników — w zestawieniu najpopularniejszych systemów baz danych.

Kiedy firma potrzebuje DAM

Pełnoprawny system DAM ma sens przede wszystkim, gdy:

• przetwarzasz dane szczególnie wrażliwe na dużą skalę — dane medyczne, finansowe, numery kart,
• podlegasz audytom zewnętrznym (PCI DSS, nadzór finansowy, NIS2) i potrzebujesz wiarygodnych raportów,
• wiele osób ma uprzywilejowany dostęp do produkcyjnych baz, a ryzyko nadużycia wewnętrznego jest realne,
• utrzymujesz dziesiątki instancji różnych silników i ręczne zbieranie logów przestało być wykonalne.

Na rynku działają zarówno duże platformy (np. IBM Guardium, Imperva — obecnie część Thales, Oracle Audit Vault and Database Firewall), jak i mniejsze rozwiązania oraz usługi wbudowane w chmury publiczne. Wybierając narzędzie, sprawdź przede wszystkim obsługę Twoich silników baz, możliwość monitorowania sesji lokalnych i ruchu szyfrowanego oraz integrację z SIEM, którego już używasz.

W mniejszej firmie z jedną czy dwiema bazami rozsądnym pierwszym krokiem jest natywny audyt wrażliwych tabel, logi wysyłane poza serwer bazy i kilka prostych alertów: logowanie kontem administracyjnym spoza znanych adresów, zmiana uprawnień, masowy eksport danych. To nie jest pełny DAM, ale pokrywa najważniejsze scenariusze nadużyć.