Проводим анализ
И так, мы настроили аудит. Информация о действиях пользователей в базе данных начала собираться. Мы знаем, где ёё можно посмотреть. Но всё это будет напрасно, если мы не сможем разобраться в этом большом количестве разнообразных данных. Поэтому попытаемся выработать основные этапы анализа аудита. Начнём с подключений пользователей к базе данных. Так как в больших системах количество соединений может составлять тысячи за день, нас в первую очередь будут интересовать подключения пользователей обладающих расширенными привилегиями. К таким пользователям относятся системные учётные записи, отдельная учётная запись администратора базы данных, если таковая имеется. Так же к ним можно отнести и пользователей, которые могут изменить критически важные данные, например известные нам пользователи AH и BE. Такие подключения следует, прежде всего, отслеживать по месту откуда делается попытка соединения. Если соединение осуществлялось с компьютера имя, которого отличается от привычного имени, то, скорее всего, произошёл взлом или утечка регистрационных данных учётной записи. Во всяком случае, на эти записи следует обратить внимание. Выполним, к примеру, следующий запрос:
SQL> SELECT username, terminal, timestamp
2 FROM dba_audit_session
3 WHERE ((username IN ('SYS', 'SYSTEM') AND terminal 'W001')
4 OR (username = 'AH' AND terminal 'W002')
5 OR (username = 'BE' AND terminal NOT IN ('W003', 'W004'))
6 )
7 AND returncode = 0;
USERNAME TERMINAL TIMESTAMP
-------- --------- -------------------
BE W005 17.01.2009 21:48:56
В результате мы видим, что было произведено успешное подключение под учётной системной записью BE с компьютера W005, хотя пользователь раньше всегда соединялся только с терминалов W003 или W004. Возможно, это говорит о том, что учётная запись BE была взломана. Если же проверка успешных подключений привилегированных пользователей не показала ничего подозрительного, то нам стоит проанализировать соединения, которые по тем или иным причинам завершились с ошибкой. Делается это с помощью следующего запроса:
SQL> SELECT username, timestamp, returncode FROM dba_audit_session WHERE returncode 0; USERNAME TIMESTAMP RETURNCODE -------- ------------------- ---------- AH 17.01.2009 21:48:54 1017 BE 17.01.2009 21:48:55 1017 BE 17.01.2009 21:48:55 1017 BE 17.01.2009 21:48:55 1017 BE 17.01.2009 21:48:55 1017
В данном случае видно, что попытка подключения под пользователями AH и BE окончилась неудачей. Но если одиночное неудачное соединение пользователя AH можно списать на ошибку ввода пароля. То аудит подключений пользователя BE может говорить о попытке взлома учётной записи. Кроме вопросов касающихся безопасности аудит подключений можно использовать и в целях определения сеансов сильно загружающих экземпляра базы данных. Всё дело в том, что при удачном завершении подключения в аудит происходит запись некоторой статистики сеанса. Поэтому обращаясь к столбцам SESSION_CPU, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_DLOCK можно находить сеансы которые используют, слишком большое количество процессорного времени, осуществляют много физических и логических чтений или имеют взаимоблокировки. Выполним, к примеру, следующий запрос:
SQL> SELECT username, sessionid, timestamp, logoff_time, session_cpu FROM dba_audit_session WHERE session_cpu > 2880000; USERNAME SESSIONID TIMESTAMP LOGOFF_TIME SESSION_CPU -------- ---------- ------------------- ------------------- ----------- VP 162 28.12.2008 08:00:00 28.12.2008 17:00:00 3000000
Здесь мы видим, что сеанс пользователя VP длился девять часов, причём время, в течение которого использовался процессор, составило более восьми часов. Это, скорее всего, говорит о ненормальной работе приложения, в котором работал пользователь. Определить, какое это приложение можно только по числовому идентификатору сеанса SESSIONID. Ему соответствует поле AUDSID представления V$SESSION. К сожалению когда мы будем просматривать аудит мы уже не найдем в этом представлении информацию о сеансе. Поэтому нам придётся дополнительно вести историю сеансов с помощью системных триггеров. Разобравшись с подключениями и не выявив попыток взлома или несанкционированного использования учётных записей, можно попытаться разобраться в остальных действиях пользователей. И начать это лучше с проверки выполнения системных команд. К ним в первую очередь стоит отнести команду ALTER SYSTEM динамически меняющую экземпляр базы данных, команды выдачи, отбора привилегий GRANT и REVOKE, операторы изменения настройки аудита AUDIT и NOAUDIT. Выбрать все записи, образующиеся при выполнении этих команд можно с помощью следующего запроса:
SQL> SELECT username, TIMESTAMP, owner, obj_name, action_name, obj_privilege, 2 sys_privilege, admin_option, grantee, audit_option, returncode 3 FROM dba_audit_statement; USERNAME TIMESTAMP OWNER OBJ_NAME ACTION_NAME OBJ_PRIVILEGE SYS_PRIVILEGE ADMI GRANTEE AUDIT_OPTION RETURNCODE -------- ------------------- ----- ----------- ------------ ---------------- ------------- ---- ------- ------------ ---------- SYSTEM 17.01.2009 22:46:13 SYSTEM AUDIT PROCEDURE 0 SYSTEM 17.01.2009 22:46:13 HR COUNTRIES GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:13 HR DEPARTMENTS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:13 HR EMPLOYEES GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:13 HR JOB_HISTORY GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 HR JOBS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 HR LOCATIONS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 HR REGIONS GRANT OBJECT Y--Y-YY--YYY---- HR_PROG 0 SYSTEM 17.01.2009 22:46:14 SYSTEM GRANT ALTER SESSION - HR_PROG 0 SYSTEM 17.01.2009 22:46:14 CONNECT GRANT ROLE - AH 0 SYSTEM 17.01.2009 22:46:14 CONNECT GRANT ROLE - BE 0 SYSTEM 17.01.2009 22:46:14 CONNECT GRANT ROLE - VP 0 SYSTEM 17.01.2009 22:46:14 HR_PROG GRANT ROLE A AH 0 SYSTEM 17.01.2009 22:46:14 ALTER SYSTEM 0 AH 17.01.2009 22:46:15 HR_PROG GRANT ROLE - BE 0 BE 17.01.2009 22:46:15 HR_PROG GRANT ROLE - VP 1932 16 rows selected.
Попробуем провести анализ полученного результата. Первая запись говорит нам о том, что администратором была включена опция аудита PROCEDURE. На это указывает действие SYSTEM AUDIT в столбце ACTION_NAME и название опции в столбце AUDIT_OPTION. Далее следует семь записей, отображающие выдачу администратором объектных привилегий роли HR_PROG, о чём свидетельствует тип действия SYSTEM AUDIT. Столбцы OWNER и OBJ_NAME при этом идентифицируют объект, на который выдаются права, а столбец GRANTEE получателя этих привилегий. Расшифровку выдаваемых прав, можно осуществить с помощью значения столбца OBJ_PRIVILEGE. Здесь каждое положение символа соответствует определённой объектной привилегии. Если символ имеет значение Y, то значит, привилегия на объект была предоставлена. В нашем случае роли были предоставлены все объектные привилегии, которые имеются для данного типа объекта. В следующей записи аудита присутствует действие SYSTEM GRANT, означающее, что администратором была произведена выдача системной привилегии роли HR_PROG. Посмотреть какая привилегия при этом выдавалась можно в столбце SYS_PRIVILEGE. В нашем случае там находится значение ALTER SESSION. Далее мы видим группу записей с общим действием GRANT ROLE. Это действие относится к предоставлению роли пользователям или другим ролям, выдаваемая роль при этом отображается в столбце OBJ_NAME. В нашем случае была произведена выдача администратором роли CONNECT пользователям AH, BE, VP и роли HR_PROG пользователю AH. Причём в последнем случае роль была предоставлена пользователю с правом передачи, о чём свидетельствует присутствие символа A в столбце ADMIN_OPTION. Четырнадцатая запись аудита, пожалуй, не нуждается в пояснении. Действие ALTER SYSTEM явно указывает на то, что администратором была выполнена в системе одноименная команда и дополнительной информации мы здесь не увидим. Последние две записи аудита относятся, как было ранее рассмотрено, к предоставлению ролей пользователям. Но выдачу этих ролей осуществляют не привилегированные пользователи. Так мы видим, что пользователь AH предоставил роль HR_PROG пользователю BE, без права передачи, который в свою очередь попытался выдать эту роль пользователю VP, но потерпел неудачу. Ошибка при этом отобразилась в столбце RETURNCODE. Анализ аудита, осуществляемый с использованием представления DBA_AUDIT_STATEMENT, имеет большое значение, так как именно на этом этапе есть возможность определить попытки повышения привилегий учётной записи и вероятность замести следы несанкционированных действий путём изменения настроек аудита. Поэтому надо внимательно анализировать все без исключения записи на предмет, кто выполняет, какие действия, в какое время и главное откуда. Если же нам на этом этапе не удалось обнаружить никаких подозрительных действий, то мы можем спокойно переходить к следующему виду анализа аудита – анализу действий над объектами. Под объектами здесь подразумевается не только объекты схемы, но и системные объекты: пользователи, профили, роли, табличные пространства и т.д. Посмотреть аудит этих объектов можно с помощью следующего запроса:
SQL> SELECT username, timestamp, owner, obj_name, action_name, new_owner, 2 new_name, ses_actions, returncode 3 FROM dba_audit_object; USERNAME TIMESTAMP OWNER OBJ_NAME ACTION_NAME NEW_O NEW_NAME SES_ACTIONS RETURNCODE -------- ------------------- ----- ---------------- -------------- ----- --------- ---------------- ---------- SYSTEM 17.01.2009 22:46:13 HR_PROG CREATE ROLE 0 SYSTEM 17.01.2009 22:46:14 AH CREATE USER 0 SYSTEM 17.01.2009 22:46:14 BE CREATE USER 0 SYSTEM 17.01.2009 22:46:14 VP CREATE USER 0 SYSTEM 17.01.2009 22:46:14 HR SECURE_EMPLOYEES ENABLE TRIGGER 0 AH 17.01.2009 22:46:15 HR EMPLOYEES SESSION REC ----------F----- 0 AH 17.01.2009 22:46:15 HR SECURE_EMPLOYEES DISABLE TRIGGER 1031 AH 17.01.2009 22:46:15 HR JOBS SESSION REC ---------SS----- 0 SYSTEM 17.01.2009 22:46:15 HR SECURE_EMPLOYEES CREATE TRIGGER HR EMPLOYEES 0 AH 17.01.2009 22:46:15 HR EMPLOYEES SESSION REC ----------S----- 0 BE 18.01.2009 20:31:56 HR JOBS SESSION REC ---------B------ 0 11 rows selected.
Проанализируем полученный результат. В первых четырёх записях мы видим, что администратор создал роль HR_PROG и учетные записи пользователей AH, BE, VP. Их имена отображены в столбце OBJ_NAME, а действия совпадают с названиями применяемых SQL команд. После этого администратор включил триггер безопасности HR.SECURE_EMPLOYEES. На это указывает действие ENABLE TRIGGER и имя объекта в полях OWNER и OBJ_NAME. Далее пользователь AH попытался обратиться к таблице HR.EMPLOYEES. Но вместо какого либо понятного нам действия, в столбце ACTION_NAME мы видим лишь значение SESSION REC. На самом деле это значение означает, что запись факта всех действий для этого объекта в течение сеанса будет отображаться в этой записи, так как настройке опций был применён режим по умолчанию BY SESSION. Определить какие команды применялись к данному объекту можно по положению специального символа в столбце SES_ACTIONS. В нашем случае это положение соответствует команде UPDATE, а сам символ имеет значение F, что означает неудачное выполнение команды. После этого пользователь AH попытался выключить триггер безопасности HR.EMPLOYEES. Но потерпел неудачу. Это видно по значению поля RETURNCODE. Далее этим же пользователем были выполнены две команды SELECT и UPDATE применительно к объекту HR.JOBS. Это было определено из положения символов S в значении столбца SES_ACTIONS. Кстати данный символ свидетельствует об успешном выполнении команды. Продолжая анализ, мы видим, что в следующей записи присутствует действие CREATE TRIGGER, которое говорит нам о том, что администратор изменил триггер HR.SECURE_EMPLOYEES. Поле NEW_NAME здесь указывает на основной объект. В нашем случае это таблица HR.EMPLOYEES, к которой относится данный триггер. После того как триггер пересоздан, пользователь AH получил возможность удачно выполнить команду UPDATE для таблицы HR.EMPLOYEES, на это указывает положение символа S в значении столбца SES_ACTIONS. И наконец, в последней записи аудита видно как пользователь BE осуществил доступ к таблице HR.JOBS. Но в значении столбца SES_ACTIONS мы видим только символ B. Позиция его соответствует выполненной команде SELECT, но результат выполнения команды неизвестен. На самом деле присутствие этого символа означает, что произошло удачное и одновременно неудачное выполнение команды в течение сеанса.
Сопровождаем журнал
По мере роста количества записей в журнале аудита, возникает необходимость в проведении определённых действий связанных с сопровождением этого журнала. Если этого не делать, то мы можем столкнуться с рядом проблем, от сложности в анализе аудита, до полной остановки системы в случае переполнения табличного пространства SYSTEM. Что же это за действия? Перечислим их - это удаление лишних и архивирование нужных записей, сброс маркера максимального уровня заполнения таблицы SYS.AUD$, а также проведение усечения данной таблицы. Теперь рассмотрим их более подробно. В первую очередь необходимо время от времени удалять лишние записи из журнала аудита. Стратегия удаления может быть разнообразной. Допустим можно выборочно удалять отдельные записи аудита непосредственно в процессе анализа. Например, выполним следующий запрос и проанализируем полученный результат:
SQL> SELECT username, terminal, timestamp, owner, obj_name, action_name, 2 sessionid, entryid, statementid 3 FROM dba_audit_object 4 WHERE username = 'SYSTEM'; USERNAME TERMINAL TIMESTAMP OWNER OBJ_NAME ACTION_NAME SESSIONID ENTRYID STATEMENTID -------- --------- ------------------- ----- ---------------- -------------- --------- ------- ----------- SYSTEM W001 18.01.2009 20:31:53 HR_PROG CREATE ROLE 831 3 13 SYSTEM W001 18.01.2009 20:31:53 AH CREATE USER 831 12 58 SYSTEM W001 18.01.2009 20:31:53 BE CREATE USER 831 13 63 SYSTEM W001 18.01.2009 20:31:53 VP CREATE USER 831 14 68 SYSTEM W001 18.01.2009 20:31:53 HR SECURE_EMPLOYEES ENABLE TRIGGER 831 19 83 SYSTEM W001 18.01.2009 20:31:55 HR SECURE_EMPLOYEES CREATE TRIGGER 852 2 8
Подозрительных действий не обнаружено, и мы можем удалить, к примеру, первую запись. Удаление надо производить непосредственно из таблицы SYS.AUD$, используя при этом в качестве ключа значения столбцов SESSIONID и ENTRYID:
SQL> DELETE sys.aud$ WHERE sessionid = 831 AND entryid = 3; 1 row deleted.
Но такой способ годится только при небольшом количестве записей. Гораздо более удобно групповое удаление. Для этого можно использовать запросы, к представлениям журнала аудита применяемые при анализе. В качестве примера удалим с помощью следующей команды все санкционированные подключения привилегированных пользователей:
SQL> DELETE
2 FROM sys.aud$
3 WHERE sessionid IN
4 (
5 SELECT sessionid
6 FROM dba_audit_session
7 WHERE (
8 (username IN ('SYS', 'SYSTEM') AND terminal = 'W001')
OR
9 (username = 'AH' AND terminal = 'W002') OR
10 (username = 'BE' AND terminal IN ('W003','W004'))
11 ) AND returncode = 0
12 ) AND action# IN (100,101,102);
6 rows deleted.
Приведённые выше способы удаления подразумевают хранение оставшейся информации, которая нас интересует непосредственно в самом журнале аудита. Это может привести к тому, что, по мере роста журнала аудита, эту информацию также придётся удалять. Чтобы этого не делать, можно организовать архивирование нужных нам записей аудита. Для этого можно создать архивные таблицы по структуре соответствующие представлениям журнала аудита в схеме отличной от SYS. Попробуем продемонстрировать это на примере. Создадим архивную таблицу ARCH_AUDIT_SESSION в схеме SYSTEM. По структуре она будет соответствовать представлению DBA_AUDIT_SESSION, но располагаться в другом табличном пространстве.
SQL> CREATE TABLE system.arch_audit_session TABLESPACE users AS SELECT * FROM dba_audit_session WHERE ROWNUM < 1; Table created.
Теперь перенесём нужные нам записи из представления DBA_AUDIT_SESSION:
SQL> INSERT INTO SYSTEM.arch_audit_session
2 SELECT *
3 FROM dba_audit_session
4 WHERE ( (username IN ('SYS', 'SYSTEM') AND terminal 'W001')
5 OR (username = 'AH' AND terminal 'W002')
6 OR (username = 'BE' AND terminal NOT IN ('W003', 'W004'))
7 )
8 AND returncode = 0;
6 rows created.
После того как все архивные таблицы созданы и необходимые нам записи аудита будут в них перенесены, можно спокойно очистить журнал аудита одной командой DELETE. Правда само удаление записей не решит проблему роста журнала. Для её устранения необходим сброс маркера максимального уровня заполнения таблицы SYS.AUD$. И сделать это можно с помощью нескольких способов. Первый состоит в том, чтобы очистить таблицу SYS.AUD$ с помощью команды TRUNCATE TABLE. Это приведёт к сбросу маркера. Если в таблице должны оставаться какие-либо записи, то необходимо вначале создать копию таблицы с помощью оператора CREATE TABLE AS SELECT. Затем выполнить команду TRUNCATE TABLE и вставить записи из копии таблицы обратно. Если при создании копии таблицы возникают проблемы, например не хватает места в табличном пространстве, то можно выгрузить данные в файл экспорта. Затем провести импорт данных обратно в таблицу. В качестве недостатка этого способа следует отметить, что неиспользуемые блоки, возникшие в результате удаления записей из журнала аудита, не освобождаются. И хотя таблица SYS.AUD$ не будет больше расти по объёму до определённого уровня, она будет иметь такой же размер, как и до её очистки. Чтобы избежать этого, можно использовать ещё один способ сброса маркера. Он представляет собой перемещение таблицы SYS.AUD$ в другое табличное пространство с помощью команды ALTER TABLE MOVE TABLESPACE и последующий возврат таблицы в табличное пространство SYSTEM:
SQL> ALTER TABLE sys.aud$ MOVE TABLESPACE users; Table altered. SQL> ALTER TABLE sys.aud$ MOVE TABLESPACE system; Table altered. SQL> ALTER INDEX sys.i_aud1 REBUILD; Index altered.
При этом происходит не только сброс маркера максимального уровня, но и освобождение неиспользуемых блоков сегмента, то есть усечение таблицы. Единственно, что надо не забыть в этом случае, это перекомпилировать объекты, зависимые от таблицы SYS.AUD$, так как данная команда переводит их в статус инвалидных.
Используем расширенный режим
Проводя анализ аудита мы видели, что в журнале сохраняется довольно много информации, достаточной для того чтобы идентифицировать то действие которое выполнил пользователь. Но если мы захотим более подробно разобраться в том какая, же команда была выполнена, то здесь нас ждёт неудача. Поясним это на примере:
SQL> SELECT username, timestamp, action_name FROM dba_audit_statement WHERE action_name = 'ALTER SYSTEM'; USERNAME TIMESTAMP ACTION_NAME -------- ------------------- -------------- SYSTEM 18.01.2009 20:31:54 ALTER SYSTEM
Рассматривая результат запроса, мы видим, что администратор выполнил какое-то изменение экземпляра базы данных с помощью команды ALTER SYSTEM. Но нам не видно, какие конкретно изменения он сделал. Это могло быть и изменение инициализационного параметра, и уничтожение сеанса пользователя. Если бы мы знали, какую команду выполнил пользователь в данный момент времени, мы могли бы точнее определить само действие и опасность его для системы. К счастью в Oracle начиная с девятой версии, предусмотрен расширенный режим аудита. В данном режиме в качестве дополнения в журнал аудита записываются исполняемые SQL команды, или значения переменных привязки, если таковые имеются. Включается данный режим изменением параметра инициализации AUDIT_TRAIL. Для этого надо присвоить ему значение DB,EXTENDED. Попробуем включить данный режим:
SQL> ALTER SYSTEM SET audit_trail= db,extended SCOPE=SPFILE; System altered.
Перезагрузим экземпляр и проверим правильность установки значения параметра:
SQL> SHOW PARAMETERS audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB, EXTENDED
Расширенный режим установился. Заполним журнала аудита новой информацией. И если теперь мы повторим запрос к представлению журнала, то увидим, что в столбце SQL_TEXT появился текст выполненной команды:
SQL> SELECT username, timestamp, action_name, sql_text FROM dba_audit_statement WHERE action_name = 'ALTER SYSTEM'; USERNAME TIMESTAMP ACTION_NAME SQL_TEXT -------- ------------------- -------------- --------------------------------- SYSTEM 09.01.2009 22:23:29 ALTER SYSTEM ALTER SYSTEM FLUSH SHARED_POOL
В результате становиться понятно, какие действия совершил пользователь SYSTEM с экземпляром базы данных. Правда иногда, когда в SQL операторе используются связанные переменные, текст команды не даёт полной информации о совершаемом действии. В этом случае нам надо знать значения этих переменных. К примеру, в результате выполнения следующего запроса мы видим две записи с совершенно одинаковыми DML командами. Единственное что их отличает это значения связанных переменных, отображённых в столбце SQL_BIND.
SQL> SELECT username, timestamp, action_name, ses_actions, sql_bind, sql_text
2 FROM dba_audit_object
3 WHERE owner = 'HR' AND obj_name = 'EMPLOYEES';
USERNAME TIMESTAMP ACTION_NAME SES_ACTIONS SQL_BIND SQL_TEXT
-------- ------------------- -------------- ---------------- ---------- ---------------------------------
AH 09.01.2009 23:10:47 SESSION REC ----------F----- #1(3):102 UPDATE hr.employees SET email = '
ALHUNOLD' WHERE employee_id = :id
AH 09.01.2009 23:10:47 SESSION REC ----------S----- #1(3):103 UPDATE hr.employees SET email = '
ALHUNOLD' WHERE employee_id = :id
В заключение хочется сказать, что расширенный режим аудита является очень затратным в плане ресурсов. Поэтому включать его без острой необходимости не рекомендуется.
Применяем другие виды журналов
Журнал аудита, который мы рассматривали выше, представляет собой таблицу AUD$ в схеме пользователя SYS. Но это не единственно место для хранения записей аудита. Кроме таблицы, аудит можно помещаться в системный журнал операционной системы или в XML файлы. Для включения данных режимов требуется изменить значение параметра инициализации AUDIT_TRAIL. Попробуем включить один из таких режимов. Для этого выполним следующую команду:
SQL> ALTER SYSTEM SET audit_trail= os SCOPE=SPFILE; System altered.
Перезагрузим экземпляр и вновь сгенерируем аудит. Если после этого мы сделаем запрос таблице SYS.AUD$, то увидим, что она пуста:
SQL> SELECT * FROM sys.aud$; no rows selected
Но зато в системном журнале операционной системы появились записи. В нашем случае это будет выглядеть примерно так:
Тип события: Уведомление Источник события: Oracle.xe Категория события: Отсутствует Код события: 34 Дата: 10.01.2009 Время: 9:32:12 Пользователь: Н/Д Компьютер: W001 Описание: Не найдено описание для события с кодом ( 34 ) в источнике ( Oracle.xe ). Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= для получения этого описания, - дополнительные сведения об этом содержатся в справке. В записи события содержится следующая информация: SESSIONID: "585" ENTRYID: "11" STATEMENT: "53" USERID: "SYSTEM" USERHOST: "DBA\W001" TERMINAL: "W001" ACTION: "51" RETURNCODE: "0" OBJ$NAME: "AH" OS$USERID: "W001\Сергей" PRIV$USED: 20.
Информацию протоколирования можно записывать не только в системный журнал, но и в отдельные XML файлы. Их расположение определяется значением параметра AUDIT_FILE_DEST и по умолчанию может указывать на директории ORACLE_BASE/admin/DB_UNIQUE_NAME /adump или ORACLE_HOME/rdbms/audit. Попробуем включить данный режим, выполнив следующую команду:
SQL> ALTER SYSTEM SET audit_trail= xml SCOPE=SPFILE; System altered.
Перезагрузим экземпляр и проверим значения параметров инициализации:
SQL> SHOW PARAMETERS audit;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string C:\ORACLEXE\APP\ORACLE\ADMIN\X
E\ADUMP
audit_sys_operations boolean TRUE
audit_trail string XML
Далее проведём генерацию аудита. После чего мы обнаружим в директории C:\ORACLEXE\APP\ORACLE\ADMIN\XE\ADUMP несколько файлов. Это и будут файлы журнала аудита. В каждом отдельном файле с помощью XML формата будут отражены действия, выполняемые пользователем в течение одного сеанса. Имя файла при этом формируется из префикса ora_ и идентификатора серверного процесса. Приведем для примера содержимое одного такого файла:
<?xml version="1.0" encoding="UTF-8"?> <Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail- 10_2.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrai l-10_2.xsd"> <Version>10.2</Version> <AuditRecord><Audit_Type>1</Audit_Type><Session_Id>635</Session_Id><StatementI d>1</StatementId><EntryId>1</EntryId><Extended_Timestamp>2009-01- 10T10:20:07.765000</Extended_Timestamp><DB_User>AH</DB_User><OS_User>W002\Серг ей</OS_User><Userhost>DBA\W002</Userhost><OS_Process>308:1400</OS_Process><Ter minal>W002</Terminal><Instance_Number>0</Instance_Number><Action>100</Action>< Returncode>1017</Returncode> <Comment_Text>Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1067))</Comment_Text> </AuditRecord> </Audit>
Здесь мы могли бы столкнуться с большими трудностями при анализе аудита, так как довольно сложно обрабатывать такие файлы. Но Oracle облегчает задачу, предоставив нам системное представление V$XML_AUDIT_TRAIL. Сделав запрос к нему, мы получим данные аудита в уже привычной для нас табличной форме, где большинство столбцов соответствуют столбцам уже рассмотренного нами представления DBA_AUDIT_TRAIL.
Хочется отметить одну важную особенность, характерную для обоих режимов аудита. Так как Oracle не может прочитать такие журналы для поиска информации об уже выполнявшейся аналогичной команде в течение сеанса, то запись аудита будет генерироваться при каждом исполнении SQL оператора. Поэтому настройка опций с фокусировкой на сеанс, для данных режимов работы аудита не будет иметь смысла.