Audyt – monitorowanie użytkowników i działań na obiektach

Włączanie opcji AUDIT

Opcja monitoringu tego typu jest domyślnie wyłączona w Oracle. Musimy więc ją ustawić, a następnie zrestartować bazę. Logujemy się jako SYS, a następnie wydajemy polecenie :

ALTER SYSTEM SET AUDIT_TRAIL=TRUE SCOPE=SPFILE;

*Aby widzieć dokładnie wprowadzane przez użytkownika komendy SQL (również nieudane próby tj. np. brak uprawnień do obiektu), musimy zmodyfikować powyższe poleceni tak, aby zamiast TRUE było DB,EXTENDED:

ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE;

Następnie jako SYS należy wykonać SHUTDOWN IMMEDIATE (trzeba pamiętać, że ta opcja zerwie wszystkie sesje i wycofa transakcje). Logujemy się jako SYS do wyłączonej (!) bazy. Aby móc to zrobić korzystamy z SQL*Plusa i logujemy się bez podawania „@adres_ip”. Co za tym idzie, należy to zrobić z komputera na którym zainstalowana jest baza Oracle. Jeśli wyłączyliśmy bazę z SQL*Plusa, to nie ma potrzeby ponownego logowania do bazy. Włączamy ją poleceniem STARTUP.

Teraz opcja audytu jest już włączoną. Możemy się upewnić wywołując komendę:SELECT * FROM V$PARAMETER WHERE NAME LIKE ‘%audit_trail’;

Śledzenie użytkownika

Po włączeniu opcji audytu możemy włączyć opcję śledzenia konkretnego użytkownika. Opcja AUDIT ALL dla użytkownika powoduje obserwację jego działań takich jak tworzenie linków bazodanowych, synonimów, tabel – słowem operacji DDL.

AUDIT ALL BY UZYTKOWNIK;

Możemy wybrać tylko niektóre działania użytkownika, które chcemy monitorować. Do tego celu używamy komendy:

AUDIT SELECT table, insert table, delete table, update table BY uzytkownik BY ACCESS;

Opcja BY ACCESS powoduje zachowanie informacji o działaniu użytkownika nawet jeśli już w ramach danej sesji wykonał instrukcję tego samego typu (np. więcej niż 1 raz wykonał SELECT na jakiejś tabeli). Przeciwieństwem dla tej opcji jest BY SESSION, ale wtedy dany tym działania jest rejestrowany tylko raz.

Aby rozpocząć śledzenie danego użytkownika wymagane jest aby wylogował się (możemy również wymusić jego rozłączenie) i ponownie zalogował do bazy.

Aby przejrzeć wyniki śledzenia należy zalogować się do użytkownika SYS. Następnie wybrać tabelę DBA_AUDIT_TRAIL. Zadając do niej odpowiednie zapytanie, jesteśmy w stanie prześledzić działalność konkretnego użytkownika.

SELECT username,

extended_timestamp,

owner,

obj_name,

action_name

FROM dba_audit_trail

WHERE USERNAME LIKE 'PRZYKLADOWY'

and owner not like 'SYS'

ORDER BY timestamp;

Warunek AND OWNER NOT LIKE 'SYS' wprowadzamy aby nie wyświetlać zmian w tabelach systemowych, które wykonują się w związku z działalnością użytkownika SYS. Warunek ORDER BY timestamp wyświetla wydarzenia według czasu ich wystąpienia.

Możemy też wyświetlić informacje na temat działań związanych z obiektami których właścicielem (twórcą) jest wybrany użytkownik:

SELECT username,

extended_timestamp,

owner,

obj_name,

action_name

FROM dba_audit_trail

WHERE owner LIKE 'PRZYKLADOWY'

ORDER BY timestamp;

Wyświetlone zostało tylko kilka kolumn, bo tylko te nas w danym momencie interesują. W kolumnie USERNAME jest informacja kto wykonał dane działanie, w kolumnie OWNER na czyim obiekcie (tutaj akurat nasz user zmieniał dane we własnym obiekcie). OBJ_NAME zawiera informacje o nazwie obiektu na którym zostały wykonane działania a ACTION_NAME trzyma info o tym jaki typ działań został przez usera wykonany.

Śledzenie działań na obiekcie

W tym punkcie będziemy śledzić kto zmienia zawartość konkretnego obiektu, niezależnie od tego który to użytkownik.

Z poziomu SYSa należy wykonać:

AUDIT DELETE, INSERT, UPDATE ON nazwa_uzytkownika.nazwa_tabeli BY ACCESS;

Polecenie to włączy obserwację tabeli produkty w schemacie użytkownika uzytkownik. Obserwowane będzie jedynie kasowanie, uzupełnianie oraz zmiana danych w tej tabeli. Możesz oczywiście wymienić takie aktywności, które nas interesują (np. select).

Należy zmodyfikować nasze wcześniejsze zapytanie. W tym przypadku zmieniamy warunek WHERE. Wyświetlamy informacje o działaniach tylko te, które mają w nazwie obiektu ‘PRODUKTY’ a więc nazwę tabeli, która nas interesuje. Dla wszelkiej pewności możemy dodać jeszcze warunek dla kolumny OWNER, by mieć pewność, że chodzi o tabelę konkretnego użytkownika. Tabela o takiej samej nazwie może występować przecież w kilku schematach.

SELECT username,

extended_timestamp,

owner,

obj_name,

action_name

FROM dba_audit_trail

WHERE obj_name LIKE 'PRODUKTY'

ORDER BY timestamp;