Аудит – это наблюдение за выбранными действиями пользователей базы данных. Его обычное применение это контроль подозрительных операций и сбор информации об отдельных действиях в базе данных. В этой главе мы научимся включать, настраивать, просматривать и анализировать аудит, а также рассмотрим его расширения.

Включаем аудит

Для включения аудита нам достаточно изменить значение инициализационного параметра AUDIT_TRAIL. Для начала подключимся к экземпляру базы данных и выведем его значение:

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Nov 24 21:39:30 2008
Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Enter user-name: sys as sysdba
Enter password:

Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> SHOW PARAMETERS audit_trail;

NAME TYPE VALUE ------------------------------------ ----------- ---------------------------- audit_trail string NONE

Как видим параметр, имеет значение NONE, то есть аудит находиться по умолчанию в выключенном состоянии. Включим его, присвоив параметру значение DB:

SQL> ALTER SYSTEM SET audit_trail=db SCOPE=SPFILE;
System altered.

Для того чтобы изменения вступили в силу, нам необходимо перезагрузить экземпляр базы данных. Но прежде чем это сделать, изменим ещё один дополнительный инициализационный параметр AUDIT_SYS_OPERATIONS, отвечающий за включение аудита для пользователя SYS и пользователей имеющих привилегии SYSDBA и SYSOPER. Выведем его значение:

SQL> show parameters audit_sys_operations 

NAME                        TYPE        VALUE
--------------------------- ----------- -------------------------------------
audit_sys_operations        boolean     FALSE

Видно, что по умолчанию аудит действий для этой группы пользователей выключен. Включим его:

SQL> ALTER SYSTEM SET audit_sys_operations=true SCOPE=SPFILE;
System altered.

Теперь, после того как все параметры были установлены в нужные значения, можно перезагрузить экземпляр:

SQL> SHUTDOWN
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  440401920 bytes
Fixed Size                  1287904 bytes
Variable Size             130025760 bytes
Database Buffers          306184192 bytes
Redo Buffers                2904064 bytes
Database mounted.
Database opened.

Проверим, правильность установки значения инициализационных параметров:

SQL> SHOW PARAMETERS audit%r;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_sys_operations                 boolean     TRUE
audit_trail                          string      DB

Значения правильные. Аудит включён, и можно переходить к его настройке.

Приступаем к настройке

Настройка аудита представляет собой включение или выключение опций протоколирования выполняемых операций. Установка опций требует наличие привилегий AUDIT SYSTEM и AUDIT ANY, и может происходить на трёх уровнях аудита: команд, привилегий и объектов схемы. Рассмотрим настройку каждого уровня по отдельности. Первое, что мы сделаем, это применим аудит для команды ALTER SYSTEM, которая может динамически изменить текущий экземпляр базы данных. Включение опции производится следующим оператором:

SQL> AUDIT alter system;
Audit succeeded.

В результате, мы имеем первую установленную опцию и можем уже отслеживать действия по изменению текущего экземпляра базы данных. Правда следует сразу отметить, что включение опции не означает немедленное протоколирование команды для пользователей, которые в текущий момент времени уже подключены к базе данных. Аудит для них будет действовать, только начиная со следующего сеанса.

После того как мы произвели включение данной опции, мы должны проверить правильность её установки. Для этого нам надо сделать запрос к следующему представлению:

SQL> SELECT audit_option FROM dba_stmt_audit_opts;

AUDIT_OPTION
----------------------------------------
ALTER SYSTEM

Из результатов запроса видно, что сейчас у нас в системе одна установленная опция ALTER SYSTEM, настроенная на протоколирование действий одноимённой команды. На самом деле большинство опций аудита команд включают в себя группы связанных операторов. Включим, к примеру, следующую опцию:

SQL> AUDIT user;
Audit succeeded.

SQL> SELECT audit_option FROM dba_stmt_audit_opts;

AUDIT_OPTION
----------------------------------------
ALTER SYSTEM
USER

В результате мы добавили аудит сразу на три команды: CREATE USER, ALTER USER и DROP USER, и с помощью одной включенной опции USER можем полностью отслеживать все действия, совершаемые с учетными записями пользователей. Всего опций аудита команд не один десяток. Можно конечно могли включить их все с помощью сокращения ALL, но политика аудита подразумевает ограничивать количество отслеживаемых событий, насколько это возможно. Поэтому мы включим только те опции, которые необходимы для минимального функционирования аудита. В дополнение к уже двум ранее установленным опциям, нам необходимо настроить протоколирование команд связанных с изменением ролей и профилей пользователей: CREATE PROFILE, ALTER PROFILE, DROP PROFILE, CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE. Делается это с помощью включения двух опции PROFILE и ROLE. Также имеет смысл установить опцию SYSTEM GRANT, для того чтобы мы могли отслеживать выдачу, отбор системных привилегий и ролей с помощью команд GRANT, REVOKE. Защите настройки аудита тоже надо уделить особое внимание. Поэтому мы включим опцию SYSTEM AUDIT. Это позволит протоколировать действия совершаемые командами AUDIT и NOAUDIT. В заключение произведём установку опции SESSION, которая в определённом смысле является уникальной, так как не ассоциируется ни с одной командой. Смысл этой опции в формировании записи аудита при подключении сеанса и обновлении записи при его отключении. Включение всех вышеперечисленные опций можно оформить в виде одного оператора, что мы сейчас и сделаем:

SQL> AUDIT profile, role, system grant, system audit, session;
Audit succeeded.

После того как нами была произведена установка аудита операторов относящихся в основном к системе, мы можем перейти к включению опций команд, связанных непосредственно с объектами, как типом. В первую очередь мы должны настроить протоколирование DDL команд, осуществляющих действия над таким важным объектом как таблица. Надо отследить не только создание, изменение и удаление таблицы, но и полную очистку хранящихся в ней данных. Поэтому следующей опцией, которую мы включим, будет опция TABLE. Она активирует аудит сразу трёх команд CREATE TABLE, DROP TABLE и TRUNCATE TABLE. В перечисленном списке нет команды ALTER TABLE, поэтому нам придётся настроить дополнительную опцию с одноимённым названием.

В качестве следующего типа объекта, который подвергнется аудиту, мы выберем триггер, так как он является важной частью в поддержании целостности данных. Здесь нам надо учитывать, что триггеры могут находиться в двух состояниях. Поэтому надо протоколировать не только команды создания и удаления триггера, но также и операторы его включения и выключения. И сделать это нам поможет включение опции TRIGGER, которая активирует аудит команд CREATE TRIGGER, ALTER TRIGGER EHABLE (DISABLE), DROP TRIGGER, ALTER TABLE ENABLE (DISABLE) ALL TRIGGERS.

Следующая опция аудита, которую мы рассмотрим, объединяет целый список типов объектов. Она имеет название PROCEDURE и включает аудит на команды CREATE и DROP применяемые к хранимым объектам. Активация данной опции зависит от нескольких условий и специфична для конкретной системы. Если, к примеру, происходит частая модификация хранимых объектов, которую осуществляет только администратор по просьбе разработчиков приложения, то данную опцию можно выключить, чтобы ограничить число записей в аудите. Если же лиц, которые могут модифицировать данный тип объектов несколько, то данную опцию лучше активировать. Мы же этого делать не будем, и поэтому произведем включение только первых трёх опций:

SQL> AUDIT table, alter table, trigger;
Audit succeeded.

Последние опции, которые мы включим, относятся к протоколированию команд GRANT REVOKE, предоставляющих или отбирающих объектные привилегии. В качестве объектов здесь выступают хранимые объекты и таблицы. Для обнаружения несанкционированной выдачи на них привилегий, мы и включим две опции GRANT PROCEDURE и GRANT TABLE:

SQL> AUDIT grant procedure, grant table;
Audit succeeded.  

Теперь проверим результат нашей работы:

SQL> SELECT audit_option FROM dba_stmt_audit_opts;

AUDIT_OPTION
----------------------------------------
ALTER SYSTEM
SYSTEM AUDIT
SYSTEM GRANT
CREATE SESSION
TABLE
USER
ROLE
TRIGGER
PROFILE
ALTER TABLE
GRANT TABLE
GRANT PROCEDURE

11 rows selected.

Минимальный набор опций включен, и мы можем уже иметь хоть какое-то представление о действиях пользователей в базе данных. Но если количество этих действий достаточно велико это может привести к неоправданному росту журнала аудита и впоследствии к трудностям его анализа. Для того чтобы избежать этой ситуации, в аудите можно использовать фокусировку. Предназначение фокусировки вытекает из самого названия. Она необходима для сужения области действия аудита, с целью уменьшить количество генерируемых контрольных записей. По умолчанию, фокусировка для опций не осуществляется. Поэтому мы рассмотрим, её применение на конкретном примере установленной нами опции ROLE. Эта опция включает протоколирование четырёх команд: CREATE ROLE, ALTER ROLE, DROP ROLE, SET ROLE. Если приложения базы данных построены по принципу включения ролей, то при большом количестве работающих пользователей будет генерироваться значительное количество записей аудита из-за выполнения команды SET ROLE. Попробуем избежать это ситуации, установив эту опцию только для неудачного выполнения команд. Для начала посмотрим режим фокусировки для всех настроенных нами опций аудита команд, выполнив следующий запрос:

SQL> SELECT audit_option, success, failure FROM dba_stmt_audit_opts;

AUDIT_OPTION                             SUCCESS    FAILURE
---------------------------------------- ---------- ----------
ALTER SYSTEM                             BY ACCESS  BY ACCESS
SYSTEM AUDIT                             BY ACCESS  BY ACCESS
SYSTEM GRANT                             BY ACCESS  BY ACCESS
CREATE SESSION                           BY ACCESS  BY ACCESS
TABLE                                    BY ACCESS  BY ACCESS
USER                                     BY ACCESS  BY ACCESS
ROLE                                     BY ACCESS  BY ACCESS
TRIGGER                                  BY ACCESS  BY ACCESS
PROFILE                                  BY ACCESS  BY ACCESS
ALTER TABLE                              BY ACCESS  BY ACCESS
GRANT TABLE                              BY ACCESS  BY ACCESS
GRANT PROCEDURE                          BY ACCESS  BY ACCESS

11 rows selected.

Значение BY ACCESS в столбце SUCCESS(FAILURE) говорит о том, что записи аудита для данной опции будут образовываться при каждом удачном (неудачном) выполнении команды. Этот режим для DDL команд устанавливается по умолчанию и фокусировка здесь отсутствует. Отменим регистрацию удачного выполнения команды для опции ROLE:

SQL> NOAUDIT role WHENEVER SUCCESSFUL;
Noaudit succeeded.

SQL> SELECT audit_option, success, failure FROM dba_stmt_audit_opts;

AUDIT_OPTION                             SUCCESS    FAILURE
---------------------------------------- ---------- ----------
ALTER SYSTEM                             BY ACCESS  BY ACCESS
SYSTEM AUDIT                             BY ACCESS  BY ACCESS
SYSTEM GRANT                             BY ACCESS  BY ACCESS
CREATE SESSION                           BY ACCESS  BY ACCESS
TABLE                                    BY ACCESS  BY ACCESS
USER                                     BY ACCESS  BY ACCESS
ROLE                                     NOT SET    BY ACCESS
TRIGGER                                  BY ACCESS  BY ACCESS
PROFILE                                  BY ACCESS  BY ACCESS
ALTER TABLE                              BY ACCESS  BY ACCESS
GRANT TABLE                              BY ACCESS  BY ACCESS
GRANT PROCEDURE                          BY ACCESS  BY ACCESS

11 rows selected.

В столбце SUCCESS напротив опции ROLE появилось значение NOT SET. Теперь при удачном выполнении команд связанных с действиями над ролями аудит генерироваться не будет. Количество записей, конечно, уменьшится, но мы не сможем больше отслеживать создание, изменение и удаление ролей. Впрочем, как обойти этот недостаток, мы рассмотрим в настройке следующего типа аудита - аудита привилегий.

В настройке аудита привилегий в качестве опций используются непосредственно системные привилегии, и генерация аудита осуществляется в том случае, если эти привилегии применяются при выполнении SQL оператора. Настройка этого типа аудита осуществляется тогда, когда требуется настроить протоколирование не связанного списка команд, а конкретных операторов. Рассмотрим это на примере всё той же опции ROLE. С целью уменьшения количества генерируемых записей для неё была применена фокусировка, и теперь удачные выполнения DDL команд над ролями не попадают в аудит. Чтобы исправить эту ситуацию мы будем отслеживать удачное применение привилегий CREATE ROLE, ALTER ANY ROLE, DROP ANY ROLE. Для этого выполним следующий оператор:

SQL> AUDIT create role, alter any role, drop any role WHENEVER SUCCESSFUL;
Audit succeeded.

Теперь выберем список опций привилегий, к которым применён аудит:

SQL> SELECT privilege, success, failure FROM dba_priv_audit_opts;

PRIVILEGE                                SUCCESS    FAILURE
---------------------------------------- ---------- ----------
ALTER ANY ROLE                           BY ACCESS  NOT SET
DROP ANY ROLE                            BY ACCESS  NOT SET
CREATE ROLE                              BY ACCESS  NOT SET
CREATE SESSION                           BY ACCESS  BY ACCESS
ALTER SYSTEM                             BY ACCESS  BY ACCESS

5 rows selected.

В результате, все удачно выполненные команды, которые требуют привилегий, CREATE ROLE, ALTER ANY ROLE и DROP ANY ROLE теперь будут попадать в аудит. Так, используя совместную фокусировку аудита команд и привилегий, нам удалось сократить количество генерируемых записей за счет исключения протоколирования успешного выполнения команды SET ROLE. Но фокусировка этих двух типов аудита не ограничивается только результатом выполнения команд, её также можно применять и для конкретных пользователей. Рассмотрим это на основе демонстрационной схемы HR. Для этого создадим предварительно нужные нам роли и учётные записи пользователей. Сделав запрос к справочнику EMPLOYEES, мы увидим, что в фирме имеются пять служащих IT отдела:

SQL> SELECT first_name, last_name FROM hr.employees WHERE job_id = 'IT_PROG';

FIRST_NAME           LAST_NAME
-------------------- -------------------------
Alexander            Hunold
Bruce                Ernst
David                Austin
Valli                Pataballa
Diana                Lorentz

Допустим, что двое из них Alexander Hunold и Bruce Ernst осуществляют сопровождение объектов схемы HR. Так как у этих пользователей довольно широкие привилегии в этой схеме, нам потребуется отслеживать все DML команды, которые они могут выполнить. Поэтому включим для них следующие опции:

SQL> AUDIT select table, insert table, update table, delete table BY ah, be;
Audit succeeded.

Проверим список опций команд для пользователей:

SQL> SELECT user_name, audit_option, success, failure FROM dba_stmt_audit_opts WHERE user_name IS NOT NULL;

USER_NAME AUDIT_OPTION                             SUCCESS    FAILURE
--------- ---------------------------------------- ---------- ----------
AH        SELECT TABLE                             BY SESSION BY SESSION
AH        INSERT TABLE                             BY SESSION BY SESSION
AH        UPDATE TABLE                             BY SESSION BY SESSION
AH        DELETE TABLE                             BY SESSION BY SESSION
BE        SELECT TABLE                             BY SESSION BY SESSION
BE        INSERT TABLE                             BY SESSION BY SESSION
BE        UPDATE TABLE                             BY SESSION BY SESSION
BE        DELETE TABLE                             BY SESSION BY SESSION

Теперь мы будем знать, осуществлялся ли доступ к таблицам и представлениям схемы HR со стороны пользователей AH и BE. Это позволит сократить количество записей по сравнению со случаем, когда нам пришлось бы включать протоколирование этих действий для всех пользователей, а затем выискивать в журнале аудита записи нужного нам пользователя. Здесь я хочу обратить внимание на содержание столбцов SUCCESS и FAILURE в списке опций, как ещё одного из видов фокусировки. До этого мы встречали в них только значение BY ACCESS, что означало, что запись аудита будет создаваться при каждом выполнении SQL оператора включенной опции. Данный режим является единственным для опций, содержащих набор DDL команд. Но для аудита DML операторов существует и ещё один режим - BY SESSION. При данном виде фокусировки запись аудита будет образовываться только один раз за весь сеанс и только при первом выполнении команды. Данный режим используется для фиксации самого факта доступа к данным и для опций DML команд устанавливается по умолчанию.

Рассматривая последний пример, мы увидели, как можно настроить аудит доступа пользователя к данным таблиц и представлений. Но используемый нами вариант не лишен недостатков. В аудит попутно попадут все обращения пользователя к доступным ему представлениям и таблицам. Такой аудит удобно включать только кратковременно, для поиска подозрительной активности в базе данных. Если же нам потребуется постоянно отслеживать доступ к одному или нескольким объектам, то такой метод становиться очень затратным. Для того чтобы исключить такую ситуацию можно применить ещё один тип аудита – аудит объектов схемы. Его отличие от аудита команд и привилегий состоит в том, что протоколирование применяется только к конкретному объекту, а опции ассоциируются с одиночными командами. Рассмотрим это на основе последнего примера. Для того чтобы сократить количество записей аудита генерируемых текущей настройкой, попробуем отследить доступ к данным только критически важных таблиц HR.EMPLOYEES и HR.JOBS. Вначале отключим лишние опции аудита DML команд для пользователей AH и BE:

SQL> NOAUDIT insert table, update table, delete table, select table BY ah, be;
Noaudit succeeded.

Теперь активируем опции аудита объектов схемы для таблиц hr.employees и hr.jobs:

SQL> AUDIT select, insert, update, delete ON hr.employees;
Audit succeeded.

SQL> AUDIT select, insert, update, delete ON hr.jobs;
Audit succeeded.

В заключение посмотрим результат нашей работы:

SQL> SELECT owner, object_name, object_type, del, ins, upd, sel FROM dba_obj_audit_opts;

OWNER OBJECT_NAME OBJECT_TYPE       DEL       INS       UPD       SEL
----- ----------- ----------------- --------- --------- --------- ---------
HR    JOBS        TABLE             S/S       S/S       S/S       S/S
HR    EMPLOYEES   TABLE             S/S       S/S       S/S       S/S

Столбцы DEL, INS, UPD, SEL обозначают сокращенные названия опций аудита объектов схемы, а значение S/S является фокусировкой и расшифровывается следующим образом. Буква S перед знаком / и после означает, что протоколирование настроено на удачное или неудачное выполнение команды. Запись при этом будет образовываться только один раз за сеанс при первом выполнении команды (режим SESSION). В результате, мы можем отслеживать доступ только к этим двум таблицам, что позволит сократить количество протоколируемой информации. Правда, данный вид аудита имеет один недостаток. К нему не может применяться фокусировка по конкретному пользователю. Вследствие чего, в данном примере нам придётся отфильтровывать аудитные записи сделанные командами пользователей AH и BE непосредственно при просмотре аудита.

Как посмотреть аудит?

Включая аудит, мы указали значение инициализационного параметра AUDIT_TRAIL равное DB. Это означает, что в качестве хранилища записей (журнала аудита) у нас выступает таблица AUD$ в схеме SYS. Поэтому, для просмотра аудита мы можем обратиться непосредственно к этой таблице напрямую. Но гораздо удобнее это делать через системные представления журнала аудита. Ознакомимся с ними более подробно. Первое представление, которое мы рассмотрим, называется DBA_AUDIT_TRAIL. Оно единственное напрямую обращается к таблице AUD$ и содержит список всех её записей. Выведем описание этого представления:

SQL> DESC dba_audit_trail;
 Name                                      Null?    Type
 ----------------------------------------- -------- -------------------------
 OS_USERNAME                                        VARCHAR2(255)
 USERNAME                                           VARCHAR2(30)
 USERHOST                                           VARCHAR2(128)
 TERMINAL                                           VARCHAR2(255)
 TIMESTAMP                                          DATE
 OWNER                                              VARCHAR2(30)
 OBJ_NAME                                           VARCHAR2(128)
 ACTION   			                   NOT NULL NUMBER
 ACTION_NAME                                        VARCHAR2(28)
 NEW_OWNER                                          VARCHAR2(30)
 NEW_NAME                                           VARCHAR2(128)
 OBJ_PRIVILEGE                                      VARCHAR2(16)
 SYS_PRIVILEGE                                      VARCHAR2(40)
 ADMIN_OPTION                                       VARCHAR2(4)
 GRANTEE                                            VARCHAR2(30)
 AUDIT_OPTION                                       VARCHAR2(40)
 SES_ACTIONS                                        VARCHAR2(19)
 LOGOFF_TIME                                        DATE
 LOGOFF_LREAD                                       NUMBER
 LOGOFF_PREAD                                       NUMBER
 LOGOFF_LWRITE                                      NUMBER
 LOGOFF_DLOCK                                       VARCHAR2(40)
 COMMENT_TEXT                                       VARCHAR2(4000)
 SESSIONID                                 NOT NULL NUMBER
 ENTRYID                                   NOT NULL NUMBER
 STATEMENTID                               NOT NULL NUMBER
 RETURNCODE                                NOT NULL NUMBER
 PRIV_USED                                          VARCHAR2(40)
 CLIENT_ID                                          VARCHAR2(64)
 ECONTEXT_ID                                        VARCHAR2(64)
 SESSION_CPU                                        NUMBER
 EXTENDED_TIMESTAMP                                 TIMESTAMP(6) WITH TIME
                                                    ZONE
 PROXY_SESSIONID                                    NUMBER
 GLOBAL_UID                                         VARCHAR2(32)
 INSTANCE_NUMBER                                    NUMBER
 OS_PROCESS                                         VARCHAR2(16)
 TRANSACTIONID                                      RAW(8)
 SCN                                                NUMBER
 SQL_BIND                                           NVARCHAR2(2000)
 SQL_TEXT                                           NVARCHAR2(2000)

Предназначение столбцов OS_USERNAME, USERNAME, USERHOST, TERMINAL особо объяснять не надо. Они идентифицируют пользователя, аудит действий которого был выполнен, и компьютер на котором эти действия исполнялись. Столбцы TIMESTAMP и EXTENDED_TIMESTAMP определяют временную метку создания записи в локальном и гринвичском часовом поясе. Поля OWNER, OBJ_NAME указывают объект, на который направлено действие. Код и название этого действия можно узнать из столбцов ACTION и ACTION_NAME. Если была применена команда RENAME, то столбцы NEW_OWNER и NEW_NAME покажут новое название объекта, также здесь содержится имя основного объекта для некоторых типов команд. Группа столбцов OBJ_PRIVILEGE, SYS_PRIVILEGE, ADMIN_OPTION, GRANTEE относиться к выдаче, отбору прав и указывает на сами привилегии, опцию ADMIN и имя пользователя, всё то, что задаётся в командах GRANT или REVOKE. Следующий столбец AUDIT_OPTION показывает параметры аудита, установленные командой AUDIT. В поле SES_ACTIONS отображается суммарная информация по сеансу, в случае установления режима фокусировки SESSION. Группа столбцов LOGOFF_TIME, LOGOFF_LREAD, LOGOFF_PREAD, LOGOFF_LWRITE, LOGOFF_DLOCK относится к информации завершения работы сеанса и обозначает время завершения сеанса, количество логических, физических чтений за сеанс, логических записей и взаимоблокировок, обнаруженных во время работы. В поле COMMENT_TEXT содержится текстовый комментарий к записи аудита. Иногда кстати довольно полезная вещь. Группа столбцов SESSIONID, ENTRYID, STATEMENTID, является, пожалуй, самой главной в представлении. Она содержит информацию о числовых идентификаторах сеанса, записи и выполняемой команды аудита. Именно по информации из двух первых полей можно гарантированно удалить отдельную запись аудита. Следующее поле RETURNCODE – это код ошибки, генерируемый действием. Столбец PRIV_USED при этом показывает системную привилегию, которая использовались для выполнения этого действия. И наконец, последние поля SQL_BIND и SQL_TEXT относятся к расширенному режиму работы аудита и содержат информацию обо всех связанных переменных и тексте SQL оператора, выполняемого действия.

Следующие представления журнала аудита, которые мы рассмотрим, базируются на представлении DBA_AUDIT_TRAIL, и служат для удобства просмотра записей аудита, так как различаются только информацией выводимой для определённых групп действий. Например, представление DBA_AUDIT_EXISTS служит для вывода записей аудита операций, которые завершились неудачей из-за того, что объект не был найден. Представление DBA_AUDIT_OBJECT показывает аудит всех объектов в базе данных. В DBA_AUDIT_SESSION содержатся записи касающиеся команд CONNECT и DISCONNECT. И наконец, последнее представление DBA_AUDIT_STATEMENT отображает записи аудита команд GRANT, REVOKE, AUDIT, NOAUDIT, ALTER SYSTEM. Делая запрос к этим представлениям, мы можем получить доступ ко всей протоколируемой информации собираемой с помощью аудита. Что даёт нам шанс провести её полный анализ.

Добавить комментарий


Защитный код
Обновить