Само по себе создание сложной системы контроля доступа с применением прав, ролей, представлений и даже детальных политик безопасности не гарантирует стопроцентной безопасности базы данных. Аудит использования базы данных позволяет убедиться, действительно ли механизмы контроля доступа работают так, как было задумано. Аудит подразумевает мониторинг и запись действий (выбранных) пользователей базы данных.
Встроенные функции аудита Oracle позволяют отслеживать изменения, выполняемые в объектах базы данных. При этом можно подвергать аудиту предоставление полномочий внутри базы данных, а также изменения, не связанные с DML и DDL, такие как события запуска и остановки. Теоретически аудит активности пользователя может приводить к отслеживанию большого объема данных, но, к счастью, Oracle предлагает множество средств управления тем, какие типы активности нужно подвергать аудиту. Аудит можно осуществлять только на уровне сеанса или на уровне всей базы данных.
Oracle четко разграничивает стандартный аудит и детальный аудит. В основе стандартного аудита лежит аудит на уровне операторов, полномочий и объектов. Детальный аудит имеет дело с доступом к данным на детализованном уровне, с действиями, зависящими от содержимого, такими как при значении больше 100 000. Вначале мы рассмотрим стандартный аудит, а потом детальный аудит.
Стандартный аудит
Oracle Database 11g позволяет выполнять аудит базы данных на трех различных уровнях: оператора, полномочий и объекта. Аудит на уровне оператора определяет аудит всех действий с любым типом объектов. Например, с помощью оператора AUDIT TABLE можно указать, чтобы база данных подвергала аудиту все действия с таблицами.
Аудит на уровне полномочий отслеживает действия, обусловленные системными полномочиями. Аудиту можно подвергать все действия, которые подразумевают использование предоставленных полномочий, например, проводить аудит всех операторов CREATE ANY PROCEDURE. И, наконец, аудит на уровне объекта отслеживает такие действия, как выполнение операторов UPDATE, DELETE и INSERT применительно к конкретной таблице, что, например, позволило бы выполнять аудит всех операций DELETE в таблице hr_employees.
Для каждого из трех уровней аудита можно выполнять аудит по сеансу или по доступу. При выполнении аудита по сеансу Oracle будет записывать в журнал только по одной записи для всех аналогичных операторов, попадающих сферу действия аудита. При выполнении аудита по доступу Oracle сохраняет запись для каждого случая доступа. С помощью параметров аудита WHENEVER SUCCESSFUL и WHENEVER NOT SUCCESSFUL можно также указывать, чтобы запись в журнал производилась только в случае успешного или неудачного выполнения определенного действия. Обычно неудачное выполнение операции свидетельствует о том, что пользователь не обладает полномочиями для выполнения данной операции. Администратору желательно знать, кто предпринимает попытки таких несанкционированных операций.
Совет. Один из часто приводимых аргументов против использования аудита базы данных Oracle — сопряженные с ним большие затраты дискового пространства базы данных. Однако если не пожалеть время на анализ побудительной причины аудита, объем данных, записываемых в журнал аудита, можно ограничить. Используя целенаправленную политику аудита, ориентированную только на жизненно важные данные, а не на аудит всей системы, выходные данные аудита можно ограничить до приемлемого объема. Кроме того, к аудиту можно обращаться только при обнаружении сомнительной активности в базе данных.
Активизация аудита
Чтобы провести аудит активности любого пользователя внутри базы данных, и даже попыток входа в БД, необходимо активизировать аудит, указав параметр AUDIT_TRAIL в файле init.ora. Записи аудита содержат информацию аудита, такую как имя контролируемого пользователя, тип операции и дату и время ее выполнения, а параметр AUDIT_TRAIL определяет действия, выполняемые над этими записями. Параметр может принимать следующие значения.
- NONE. Отключает аудит базы данных. NONE — значение, используемое по умолчанию.
- OS. Указывает, что Oracle будет сохранять записи аудита в файл операционной системы (журнал аудита операционной системы).
- DB. Указывает, что Oracle будет сохранять записи аудита в журнале аудита базы данных, доступном для просмотра в виде представления DBA_AUDIT_TRAIL (хранящемся в таблице SYS.AUD$).
- DB, EXTENDED. Указывает, что Oracle будет отправлять все записи аудита в журнал аудита базы данных (SYS.AUD$) и при этом будет заполнять столбцы SQLBIND и SQLTEXT CLOB.
- XML. Указывает, что записи аудита в XML-формате должны пересылаться в файлы операционной системы.
- XML, EXTENDED. Аналогично значению XML, но вызывает также запись всех столбов журнала аудита, включая SQLTEXT и SQLBIND.
Существует заданное по умолчанию местоположение, в которое Oracle будет помещать файл аудита. Место хранения этого файла легко изменить с помощью параметра AUDIT_FILE_DEST в файле init.ora, как показано в следующем примере:
AUDIT_TRAIL=DB AUDIT_FILE_DEST=/a10/app/oracle/oradata/audit_data
Если указать AUDIT_TRAIL=OS, журнал аудита не будет сохранять информацию аудита в базе данных. Вместо этого информацию будет сохраняться в месте, указанном параметром AUDIT_FILE_DEST. Если указать AUDIT_TRAIL=OS и опустить параметр AUDIT_FILE_DEST, по умолчанию информация аудита будет записываться в каталог
$ORACLE_HOME/rdbms/audit/.
Совет. При указании параметра AUDIT_TRAIL=DB записи аудита будут вноситься в специальную принадлежащую пользователю SYS таблицу SYS.AUD$, расположенную в табличном пространстве System. При выполнении любого более-менее серьезного аудита базы данных табличное пространство быстро переполняется. Прежде чем включать аудит, обязательно измените параметры хранения таблицы SYS.AUD$ и увеличьте объем табличного пространства System. В противном случае существует риск переполнения табличного пространства System во время аудита базы данных.
Чтобы воспользоваться информацией из таблицы журнала аудита (SYS.AUD$), можно прибегнуть к услугам представления DBA_AUDIT_TRAIL. В зависимости от событий, подвергаемых аудиту, и выбранных для него параметров, журнал аудита может содержать следующие типы данных:
- учетное имя для входа в операционную систему;
- имя пользователя базы данных;
- идентификаторы терминала и сеанса;
- имя выполненной операции или операции, для которой была предпринята попытка выполнения;
- метка даты и времени;
- SQL-текст, запустивший аудит.
Не стоит особо беспокоиться о заполнении таблицы SYS.AUD$ при включении аудита. Таблицу всегда можно усечь после экспорта ее содержимого в другое местоположение или когда принято решение, что больше не стоит хранить содержимое таблицы аудита.
Аудит, выполняемый по умолчанию в Oracle
Если вообще опустить параметр AUDIT_TRAIL, определяющий параметры аудита базы данных, по умолчанию Oracle будет записывать следующие три типа действий над базой данных в каталог $ORACLE_HOME/rdbms/audit:
- подключения в качестве пользователя SYSOPER или SYSDBA;
- запуск базы данных;
- останов базы данных.
Как правило, файл аудита фиксирует события CONNECT, SHUTDOWN и STARTUP, инициированные пользователем SYS, который, естественно, обладает полномочиями SYSDBA.
Аудит всех действий пользователя SYS, как и всех пользователей, подключающихся с полномочиями SYSDBA или SYSOPER, можно выполнить, установив параметр AUDIT_SYS_OPERATIONS файла init.ora в true:
AUDIT_SYS_OPERATIONS=TRUE
Обратите внимание, что если этот параметр установлен, все действия пользователя SYS будут подвергаться аудиту, независимо от значения параметра AUDIT_TRAIL. Значение этого параметра, установленное по умолчанию — false.
Включение аудита
Установка параметра AUDIT_TRAIL ведет к активизации аудита в базе данных. Однако чтобы действительно начать аудит, необходимо также указать таблицы и действия, которые должны подвергаться аудиту со стороны базы данных.
Аудит действий на любом уровне можно запустить с помощью соответствующей команды. Примеры команд, включающих аудит на различных уровнях с различными параметрами, приведены в листинге ниже.
SQL> AUDIT SELECT ON employees; Audit succeeded. SQL> AUDIT DELETE ANY TABLE BY salapati WHENEVER NOT SUCCESSFUL; Audit succeeded. SQL> AUDIT UPDATE ANY TABLE; Audit succeeded. SQL> AUDIT SESSION BY SALAPATI; Audit succeeded. SQL> AUDIT SELECT,INSERT,UPDATE,DELETE 2 ON employees BY ACCESS WHENEVER SUCCESSFUL; Audit succeeded. SQL>
Следующий пример демонстрирует использование более мощного параметра, который обеспечивает аудит всех полномочий:
SQL> AUDIT ALL PRIVILEGES; Audit succeeded. SQL>
Естественно, журнал аудита для этого варианта выбора будет достаточно большим при наличии большого числа пользователей с предоставленными им объектными полномочиями.
На заметку! Оператор AUDIT SESSION не проводит аудит операторов, выполняемых в течение всего сеанса — он ведет к регистрации времени запуска сеанса, времени его окончания и логических и физических ресурсов ввода-вывода, использованных сеансом.
Отключение аудита
Для отключения аудита используют оператор, который почти идентичен применяемому для включения аудита. Основное различие между ними в том, что вместо ключевого слова AUDIT используется ключевое слово NOAUDIT.
Вот несколько примеров:
SQL> NOAUDIT SESSION; Noaudit succeeded. SQL> NOAUDIT DELETE ANY TABLE BY salapati WHENEVER NOT SUCCESSFUL; Noaudit succeeded. SQL> NOAUDIT DELETE ANY TABLE BY salapati; Noaudit succeeded.
На заметку! Для отключения аудита действия DELETE ANY TABLE BY salapati WHENEVER NOT SUCCESSFUL можно использовать любой из двух последних операторов. То есть ключевое слово NOAUDIT, примененное к более общему оператору, отключает аудит более низкого уровня, подразумеваемый общими полномочиями.
Если требуется отключить все уровни аудита — операторов, полномочий и объектов, — это можно сделать с помощью следующих трех SQL-операторов:
SQL> NOAUDIT ALL; /* отключает аудит всех операторов */ SQL> NOAUDIT ALL PRIVILEGES; /* отключает аудит всех полномочий */ SQL> NOAUDIT ALL ON DEFAULT; /* отключает аудит всех объектов */
Индивидуальная настройка аудита базы данных с помощью триггеров
Триггер (trigger) Oracle — это специальный блок кода, который запускается определенным событием в базе данных. Большинство приложений использует триггеры для обновления одной таблицы при выполнении действия в другой таблице. Триггеры могут запускаться операторами DML или DDL, и их можно использовать для облегчения реализации бизнес-правил внутри базы данных. Аудит определенных действий пользователя можно осуществлять, создавая триггеры или другие хранимые процедуры, которые будут фиксировать информацию о пользователе в таблице, когда пользователь выполняет определенную операцию в базе данных.
В Oracle можно создавать несколько типов триггеров, в том числе триггеры DML и DDL, которые построены на основе действий, выполняемых пользователем в таблицах и представлениях, и триггеры системного уровня, имеющие более общий характер. Эти типы триггеров рассмотрены в последующих разделах статьи.
Совет. Если интерес представляют только определенные действия пользователя, или требуется выполнить аудит ограниченного множества действий в базе данных, не обязательно включать аудит на уровне всей базы данных. В этом случае можно создать триггеры, которые будут вставлять информацию в таблицу журнала при наступлении указанных событий.
Использование DML-триггеров для аудита
DML-триггеры являются наиболее часто используемыми в базах данных Oracle. Обычно приложения применяют их для поддержания бизнес-правил внутри базы данных. Триггеры Oracle просты в реализации, и их можно использовать, если требуется обеспечить умеренную степень аудита. Небольшой пример применения триггера для аудита операций вставки, выполняемых пользователями в определенной таблице, приведен в листинге ниже.
SQL> CONNECT tester/tester1
Connected.
SQL> CREATE OR REPLACE TRIGGER audit_insert
2 AFTER INSERT ON tester.xyz
3 FOR EACH ROW
4 INSERT INTO xyz_audit 5* VALUES(user, sysdate);
Trigger created.
SQL>
SQL> CONNECT tester/tester1
Connected.
SQL> INSERT INTO xyz
2 VALUES
3 ('sam alapati');
1 row created.
SQL> COMMIT;
Commit complete.
SQL> CONNECT system/system_passwd
Connected.
SQL> SELECT * FROM xyz_audit;
USER_NAME ACTION_DATE
---------------------------
TESTER 24-MAR-08
SQL>
Чем больше действий требуется подвергать аудиту, тем больше дискового пространства понадобится иметь для хранения журнала аудита. Необходимо тщательно разобраться, чем вызвана необходимость аудита, и проводить аудит только тех действий, которые действительно важны в конкретной организации.
На заметку! Не существует никаких правил относительно того, какие операции следует подвергать аудиту. В некоторых организациях аудиту могут подвергаться все DML-изменения (INSERT, UPDATE и DELETE), чтобы можно было отслеживать любые несанкционированные изменения. В других организациях может оказаться достаточным обеспечить аудит неудачных попыток регистрации.
Использование триггеров системного уровня для аудита
Триггеры, запускающиеся после выполнения DML-операций, таких как INSERT или DELETE, применяются в базах данных Oracle наиболее часто, но они — не единственно доступный для использования тип триггеров. Oracle поддерживает мощные триггеры системного уровня, такие как запускаемые после запуска или перед остановкой базы данных. Триггеры входа и выхода из базы данных особенно полезны при аудите БД. Oracle Database 11g предоставляет следующие типы триггеров системного уровня.
- Триггеры запуска базы данных. Эти триггеры можно использовать главным образом для выполнения кода, который нужно запускать немедленно после запуска базы данных.
- Триггеры входа. Эти триггеры предоставляют информацию о случаях входа пользователя в базу данных и подробности о сеансе пользователя.
- Триггеры выхода. Эти триггеры аналогичны триггерам входа, но они выполняются непосредственно перед закрытием сеанса пользователя.
- Триггеры DDL. Эти триггеры позволяют фиксировать все изменения объектов базы данных.
- Триггеры ошибки сервера. Эти триггеры записывают все основные ошибки кода PL/SQL в специальную таблицу.
Рассмотрим простой пример, который демонстрирует возможности по аудиту пользователей, предоставляемые специальными триггерами Oracle. Вначале в этом примере создается простая таблица для хранения данных входа в БД. Когда пользователь регистрируется в базе данных, таблица захватывает определенную информацию о пользователе. Выполняя аудит элементов выхода из БД с помощью другого триггера, легко выяснить, насколько долго пользователь пребывал в базе данных в данный день.
Для создания системы аудита событий входа/выхода с помощью триггеров системного уровня нужно выполнить следующие действия:
1. Создайте тестовую таблицу logon_audit:
SQL> CREATE TABLE logon_audit( 2 user_id VARCHAR2(30), 3 sess_id NUMBER(10), 4 logon_time DATE, 5 logoff_time DATE, 6* host VARCHAR2(20)); Table created. SQL>
2. Создайте пару триггеров входа и выхода:
SQL> CREATE OR REPLACE TRIGGER logon_audit_trig
2 AFTER LOGON
3 ON DATABASE
4 BEGIN
5 INSERT INTO logon_audit
6 VALUES
7 (user,
8 sys_context('userenv', 'sessionid'),
9 sysdate,
10 null,
11 sys_context('userenv', 'host'));
12* END;
Trigger created.
SQL> CREATE OR REPLACE TRIGGER logoff_audit_trig
2 AFTER LOGOFF
3 ON DATABASE
4 BEGIN
5 INSERT INTO logon_audit
6 VALUES
7 (user,
8 sys_context('userenv', 'sessionid'),
9 null,
10 sysdate,
11 sys_context('userenv', 'host'));
12* END;
Trigger created.
SQL>
3. Просмотрите сведения о входе/выходе пользователей:
SQL> SELECT * FROM logon_audit; USER_NAME SESS_ID LOGON_TIME LOGOFF_TIME HOST_NAME --------- -------- ------------------- ----------- ---------- SYSTEM 347 24-MAR-08 07:00:30 NTL-ALAPATI HR 348 24-MAR-08 07:10:31 NTL-ALAPATI HR 348 24-MAR-08 07:32:17 NTL-ALAPATI SQL>
Триггер DDL можно было бы использовать также для перехвата изменений, произведенных пользователями в объектах, включая изменение, создание и удаление различных типов объектов. С помощью триггера DDL можно перехватывать множество атрибутов событий и пользователей.
Чтобы перехватывать некоторые важные атрибуты события пользователя, вначале потребуется создать таблицу для регистрации DDL-изменений. После этого можно создать DDL-триггер, подобный приведенному в листинге ниже. В этом примере таблица названа DDL_LOG, а триггер — DDL_LOG_TRIG.
SQL> CREATE OR REPLACE TRIGGER 2 ddl_log_trig 3 AFTER DDL ON DATABASE 4 BEGIN 5 INSERT INTO ddl_log 6 (username, 7 change_date, 8 object_type, 9 object_owner, 10 database 11 ) 12 VALUES 13 (ora_login_user, 14 sysdate, 15 ora_dict_obj_type, 16 ora_dict_obj_owner, 17 ora_database_name) 16* END; Trigger created. SQL>
Как только триггер задействован, можно запросить таблицу DDL_LOG, чтобы просмотреть изменения. Как легко убедиться, пользователи HR и SYSTEM выполнили несколько DDL-изменений в базе данных:
SQL> SELECT * FROM ddl_log; USERNAME CHANGE_DATE OBJECT_TYPE OBJECT_OWNER DATABASE_NAME -------- ----------- --------------- ------------ ------------- HR 24-MAR-08 SYNONYM HR NINA SYSTEM 24-MAR-08 OBJECTPRIVILEGE SYSTEM NINA HR 24-MAR-08 TRIGGER HR NINA SQL>
Использование средств Flashback для проведения аудита
Кроме стандартных функциональных возможностей аудита Oracle, описанных в предшествующих разделах моей статьи блога, для аудита изменений, выполненных в строках таблицы, можно использовать также функциональные возможности ретроспективных запросов Oracle. Например, средство Flashback Query (Ретроспективный запрос) можно применять для анализа данных таблицы на определенный момент времени в прошлом. С использованием Flashback Transaction Query (Ретроспективный запрос транзакции) можно выяснить все изменения, произведенные в некоторой строке на определенный момент времени или с определенным номером SCN (System Change Number — системный номер изменения).
Средство Flashback Versions Query (Ретроспективный запрос версий) возвратит все версии строки, существовавшие в указанный период. Это позволяет легко идентифицировать пользователя и конкретную операцию, которые привели к недопустимым или несанкционированным изменениям данных. Используя сведения о транзакции, полученные из этого запроса, можно пойти еще дальше и с помощью другой функции ретроспективных запросов, Flashback Transaction Query, идентифицировать всю транзакцию (или транзакции).
В основе работы средств Flashback Query, Flashback Versions Query и Flashback Transaction Query лежат данные отмены.
Детальный аудит
Предположим, что требуется использовать аудит для выяснения того, не просматривают ли пользователи данные в таблице, в которую для них не предусмотрен доступ. Например, предполагается, что менеджер может просматривать информацию о зарплате работающих под его началом сотрудников. Но не может ли он просматривать и информацию о зарплате его начальников? Нужно ли подвергать аудиту все операторы SELECT, выполняемые этим менеджером?
Аудит всех операторов SELECT привел бы к колоссальному объему данных аудита, но, к счастью, существует более простой выход. Oracle позволяет выполнять аудит действий в базе данных на основе содержимого. То есть можно указать, что записи аудита должны создаваться не для всех операторов SELECT, INSERT, UPDATE и DELETE, а только для тех из них, которые соответствуют определенному критерию. Вместо того чтобы пытаться выявить нарушения политики, исходя из действий, выполняемых над любыми данными, потребуется применить политики детального аудита (fine-grained auditing — FGA) в отношении отдельных таблиц или конкретных операций, которые требуется подвергать мониторингу.
Активизация детального аудита
Для активизации детального аудита используется пакет DBMS_FGA Oracle. FGA позволяет подвергать аудиту только определенные строки внутри таблицы. Запуская написанные пользователем процедуры при выполнении условий аудита, можно имитировать триггеры операторов. Это позволяет обнаруживать непредусмотренное использование данных тем или иным сотрудником. FGA можно применять также в качестве средства обнаружения вторжений в систему.
Для использования FGA включать аудит всей базы данных не нужно, а поскольку аудит осуществляется на основе обращений к таблице, политики FGA буквально невозможно обойти. Записи FGA доступны через представления DBA_FGA_AUDIT_TRAIL и DBA_COMMON_AUDIT_TRAIL, причем последнее представление содержит журнальные записи как стандартного, так детального аудита.
Для добавления политики детального аудита применяется процедура ADD_POLICY из пакета DBMS_FGA. Структура процедуры ADD_POLICY показана в листинге ниже.
SQL> EXECUTE DBMS_FGA.ADD_POLICY( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2, audit_condition VARCHAR2, audit_column VARCHAR2, handler_schema VARCHAR2, handler_module VARCHAR2, enable BOOLEAN, statement_types VARCHAR2, audit_trail BINARY_INTEGER IN DEFAULT, audit_column_opts BINARY_INTEGER IN DEFAULT);
Процедура ADD_POLICY имеет следующие параметры.
- object_schema. Схема объекта, который нужно подвергнуть аудиту. Значение этого параметра по умолчанию — NULL, что означает схему пользователя, вошедшего в базу данных.
- object_name. Имя объекта, который нужно подвергнуть аудиту.
- policy_name. Имя политики аудита, присвоенной пользователем.
- audit_condition. Условие в строке, указывающее условие мониторинга. Значение по умолчанию — NULL, которое действует как значение TRUE.
- audit_column. Столбцы, доступ к которым нужно подвергать аудиту. Значение этого параметра по умолчанию — NULL, что означает аудит доступа ко всем столбцам. Параметр audit_column_opts работает в сочетании с этим параметром.
- handler_schema. Схема, которая содержит обработчик события. Значение этого параметра по умолчанию — NULL, что означает использование текущей схемы.
- enable. Параметр, который включает или отключает политику. Значение этого параметра по умолчанию — TRUE, активизирующее политику.
- statement_types. Типы SQL-операторов, которым применяется данная политика: INSERT, UPDATE, DELETE или SELECT. Значение по умолчанию — SELECT.
- audit_trail. Параметр, который указывает, нужно ли заполнять столбцы LSQLTEXT и LSQLBIND в таблице fga_log$. Установка параметра DB не ведет к заполнению столбцов. Значение, используемое по умолчанию — DB_EXTENDED, которое вызывает заполнение столбцов.
- audit_column_opts. Определяет, должен ли аудит осуществляться при обращении запроса к любому столбцу или ко всем столбцам, указанным в параметре audit_column. При установке этого параметра в DBMS_FGA.ALL_COLUMNS оператор будет подвергаться аудиту, только если он обращается ко всем столбцам, заданным в параметре audit_column. Значение этого параметра, используемое по умолчанию — DBMS_FGA.ANY_COLUMNS, которое вызывает аудит оператора, если тот обращается к любому столбцу, указанному в параметре audit_column.
Использование детального аудита
Теперь пора рассмотреть применение пакета DBMS_FGA для реализации детального аудита. Следующий пример FGA подвергает аудиту любой оператор DML (INSERT, UPDATE, DELETE и SELECT) в таблице hr.emp, который обращается к столбцу salary любого сотрудника отдела продаж (SALES):
SQL> EXECUTE DBMS_FGA.ADD_POLICY( object_schema => 'hr', object_name => 'emp', policy_name => 'chk_hr_emp', audit_condition => 'dept = ''SALES'' ', audit_column => 'salary', statement_types => 'insert,update,delete,select', handler_schema => 'sec', handler_module => 'log_id', enable => TRUE);
Как только приведенная процедура ADD_POLICY будет выполнена, все последующие операторы SELECT, которые запрашивают в таблице emp информацию о зарплате сотрудника отдела SALES, будут регистрироваться в таблице SYS.FGA_LOG$ из табличного пространства System. Представление DBA_FGA_AUDIT_TRAIL строится на основе этой таблицы. Если указать audit_trail=DBMS_FGA.DB_EXTENDED, то посредством столбцов LSQLTEXT и LSQLBIND можно захватывать также SQL-текст, имя политики и другую информацию.
Параметры handler_module и handler_schema служат для выполнения предопределенного набора действий при каждом событии аудита. Кроме того, можно создать подобный триггеру механизм, называемый обработчиком аудита, который обрабатывает событие аудита, когда оно происходит.
Два параметра обработчика событий имеют следующий смысл:
- handler_schema — схема, которая содержит процедуру обработки данных;
- handler_module — имя процедуры или пакета.
В приведенном примере модуль обработчика обозначен идентификатором sec_id, который представляет следующую процедуру:
SQL> CREATE PROCEDURE sec.log_id (schema1 varchar2, table1 varchar2, policy1 varchar2) AS BEGIN UTIL_ALERT_PAGER(schema1, table1, policy1); /*отправляет предупреждение на пэйджер автора*/ END;
Совет. Для применения FGA нужно иметь только полномочия на выполнение пакета DBMS_FGA. При использовании этого пакета записи аудита не помещаются в стандартную таблицу аудита SYS.AUD$, даже при включении журнала аудита базы данных. Они помещаются в специальную таблицу sys.fga_aud$.
Просмотр журнала аудита
При использовании FGA в базе данных представление DBA_FGA_AUDIT_TRAIL отображает журнал аудита (хранящийся в таблице sys.fga_aud$). Оно предоставляет детальную информацию аудита, такую как метку времени, идентификатор пользователя базы данных, имя объекта и действительный SQL-текст, используемый операторе, выделенном политикой FGA. Например:
SQL> SELECT timestamp, db_user, os_user, object_schema, object_name, sql_text FROM dba_fga_audit_trail;
Стандартный журнал аудита в базах данных Oracle носит имя DBA_AUDIT_TRAIL, а журнал аудита FGA — DBA_FGA_AUDIT_TRAIL. При желании результаты обоих типов аудита можно просмотреть в новом представлении DBA_COMMON_AUDIT_TRAIL, которое сочетает в себе журналы как обычного, так и FGA-аудита.
На заметку! Всегда старайтесь сохранять параметры аудита на минимуме, необходимом для решения стоящих задач аудита. При включенном аудите администратор БД должен уделять пристальное внимание табличному пространству System и таблице SYS.AUD$. Переполнение таблицы SYS.AUD$ может привести к замораживанию последующих подключений и DML-активности в базе данных. Возможно, периодически придется архивировать и удалять записи из таблицы SYS.AUD$.
