Пока мы говорили только о том, как задать детальный аудит для отдельной таблицы. Администратор базы данных отвечает также за контроль и управление всей конфигурацией FGA.
Для просмотра политик FGA, которые уже были определены в базе данных, можно обратиться к представлению словаря базы данных DBA_AUDIT_POLICIES, которое содержит следующие столбцы:
Имя таблицы или представления, для которых определена политика.
Имя политики.
Если существует условие политики, например SALARY>=150000 OR EM- PID=100, оно приводится в данном столбце.
Если политика связана с определенными столбцами (например, журнал аудита формируется только при ссылке на определенные столбцы), их названия выводятся в данном столбце.
Если определен модуль обработки для политики, отображается имя его владельца.
Если модуль обработки определен и является независимой процедурой, выводится его имя. Если модуль обработки является пакетной процедурой, то в данном столбце выводится имя процедуры, а в столбце PF_PACKAGE - имя пакета.
См. описание столбца PF_FUNCTION.
Указывает, включена ли политика аудита (YES или NO).
DBMS_FGA - достаточно простой пакет, включающий в себя всего 4 процедуры, которые можно использовать для администрирования детального аудита базы данных: ADD_POLICY, DROP_POLICY, DISABLE_POLICY и ENAB- LE_POLICY.
Помните, что политика FGA не является объектом базы данных, поэтому к ней не применяются обычные операции SQL. Для администрирования политики необходимо использовать процедуру ADD_POLICY пакета DBMS_FGA, которая уже была описана выше.
Для удаления политики FGA следует использовать процедуру DROP_PO- LICY пакета DBMS_FGA. Например, для удаления определенной ранее политики для таблицы EMP необходим такой фрагмент кода:
Может возникнуть необходимость временного отключения записи журнала аудита, например для очистки журнала аудита или изменения таблицы для его хранения. Удалять политику не придется, можно просто отключить ее, используя процедуру DISABLE_POLICY пакета DBMS_FGA:
Отключенная политика сохраняется, только не ведется запись в журнал аудита. После того как необходимые манипуляции по обслуживанию выполнены, можно снова включить политику, используя процедуру ENABLE_POLICY пакета DBMS_FGA:
В этом разделе описаны специальные возможности и расширения функциональности FGA в версии Oracle 10*.
В Oracle9i FGA поддерживает аудит только для оператора SELECT; такие операторы DML, как INSERT, UPDATE и DELETE, детальному аудиту подвергнуть невозможно. В Oracle 10* детальный аудит доступен и для операторов DML. Новый параметр statement_types процедуры ADD_POLICY пакета DBMS_FGA позволяет указать, для каких операторов следует проводить аудит. Продолжая предыдущий пример, предположим, что теперь мы хотим собирать сведения обо всех типах операторов: SELECT, IN-.
Записи попадают все в ту же таблицу FGA_LOG$ и доступны через то же представление словаря данных - DBA_FGA_AUDIT_TRAIL. Чтобы учесть три дополнительных типа обращения к данным (INSERT, UPDATE и DELETE), в представление добавлен новый столбец STATEMENT_TYPE. Если новый параметр процедуры опущен, то регистрируются только операторы SELECT.
Для операторов DELETE аудит ведется всегда, вне зависимости от параметра audit_column. Дело в том, что DELETE удаляет всю строку и неявно ссылается (воздействует) на все столбцы таблицы.
Только простые предикаты (то есть содержащие всего одно условие) могут использоваться в параметре audit_condition для операторов DML. Нельзя, например, определить политику для детального аудита операторов DML, задав параметр audit_condition следующим образом: 'SALARY >= 150000 OR EMPID = 100'. Политику создать удастся, но обновления таблицы будут завершаться с ошибкой «ORA-28138: Error in Policy Predicate» (ошибка в предикате политики). Аналогично в audit_condition нельзя задать подзапрос. Разрешены только простые предикаты.
В Oracle 10* в журнал детального аудита записывается ряд дополнительных элементов, которые доступны через представление DBA_FGA_ AUDIT_TRAIL. Кроме того, появляется дополнительное представление
FLASHBACK_TRANSACTION_QUERY.
В Oracle 10* в представление DBA_FGA_AUDIT_TRAIL добавляются следующие новые столбцы:
STATEMENT_TYPE
Тип оператора, для которого выполнена регистрация (например,
SERT, UPDATE и DELETE, для таблицы EMP, но только в том случае, если выполнены условия аудита. Этого можно достичь следующим образом:
SELECT, INSERT, UPDATE или DELETE).
В дополнение к обычной временной метке хранится расширенная, включающая в себя микросекунды, часовой пояс и другую дополнительную информацию.
Для прокси-пользователя, получившего привилегию на доверенный вход в систему, как показано ниже, идентификатор прокси-сеанса сохраняется в данном столбце:
Если пользователь является корпоративным пользователем, например, определенным через LDAP, то идентификатор пользователя отличается от обычного идентификатора пользователя Oracle. В этот столбец записывается идентификатор корпоративного или глобального пользователя.
При использовании технологии Real Application Clusters (RAC) каждому экземпляру может соответствовать свой идентификатор сеанса, то есть пользовательский сеанс однозначно идентифицируется комбинацией номера экземпляра и идентификатора сеанса. В Oracle 10*, в отличие от предыдущих версий, номер экземпляра регистрируется. (Обратите внимание, что в приведенном выше пользовательском журнале аудита мы собирали эти сведения.)
Идентификатор процесса операционной системы для пользовательского сеанса. Этот идентификатор оказывается чрезвычайно важен, если необходим анализ соответствующего файла трассировки.
Идентификатор транзакции, используемый в ретроспективных запросах (для того чтобы понять, что за значение хранится в данном столбце, необходимо представлять себе ретроспективные запросы, о которых мы говорили ранее в главе).
В Oracle 10* появляется новое представление словаря данных, FLASH- BACK_TRANSACTION_QUERY, которое отображает выполненные в базе данных транзакции. Представление содержит следующие столбцы:
Каждая транзакция имеет уникальный номер, который записывается в данный столбец в виде значения типа RAW.
Системный номер изменения (SCN) на момент начала транзакции.
Временная метка на момент начала транзакции.
Временная метка на момент фиксации транзакции.
Пользователь Oracle, который открыл сеанс.
Номер SCN операции отката.
Тип операции (например, INSERT, UPDATE, DELETE). Если речь идет о PL/SQL-блоке, то в столбце выводится DECLARE или BEGIN.
Имя таблицы, упоминаемой в транзакции.
Владелец вышеупомянутой таблицы.
Идентификатор строки, которая была изменена или прочитана.
Оператор SQL, который может отменить изменения, выполненные исходным оператором. Если исходный оператор SQL - INSERT, то в столбце UNDO_SQL хранится DELETE, и т. д.
Информация данного представления полезна в основном в рамках использования функциональности ретроспективных запросов (новой возможности Oracle 10*), но может пригодиться и для детального аудита. Столбец XID данного представления содержит уникальный идентификатор транзакции, который также хранится в столбце TRANSACTIONID представления DBA_FGA_AUDIT_TRAIL. На основе этого столбца можно установить соответствие между двумя представлениями и получить всю информацию о транзакции, которая привела к регистрации записи в журнале аудита.
Это означает, что будет вестись аудит при обращении пользователя к столбцу SALARY или COMM. Однако в некоторых случаях возникает тре-
В предыдущем примере список столбцов задавался следующим образом:
бование вести аудит только при ссылке на все столбцы списка, а не на какой-то один из них. Например, в базе данных EMP можно вести журнал только в том случае, если кто-то одновременно запрашивает данные из столбцов SALARY и EMPNAME. Дело в том, что при доступе только к одному столбцу раскрытие конфиденциальной информации маловероятно (обычно пользователь ищет зарплату по имени сотрудника). Предположим, что пользователь выдает такой запрос:
SELECT salary FROM hr.emp;
Будут выведены зарплаты всех сотрудников, но без указания того, кому какая цифра соответствует. Такая информация, скорее всего, не представляет особого интереса. Предположим теперь, что выдан такой запрос:
SELECT empname FROM hr.emp;
Выдаются имена сотрудников, но без указания их зарплат, сведения о зарплате защищены. Но если пользователь выполняет следующий запрос:
SELECT empname, salary FROM hr.emp;
то будет выведена информация о зарплатах с указанием сотрудников. Это как раз те данные, которые хотелось бы защитить. И в этом последнем случае (но не в двух первых) журнал аудита содержит полезную информацию, поэтому его стоит вести.
Такая возможность позволяет сконцентрировать усилия на отслеживании только ключевых условий (и уменьшить объем журнала аудита).
В версии Oracle9i не существовало возможности указать в условии аудита комбинацию столбцов. В Oracle 10* это можно сделать при помощи параметра audit_column_opts процедуры ADD_POLICY. По умолчанию этот параметр установлен в значение DBMS_FGA.ANY_COLUMNS, что означает включение аудита при обращении к любому из столбцов списка. Если заменить значение по умолчанию на DBMS_FGA.ALL_COLUMNS, то журнал аудита будет формироваться только при обращении ко всем столбцам из списка. В нашем случае создаем политику FGA, которая будет создавать запись аудита только в том случае, когда пользователь выбирает данные из обоих столбцов: SALARY и EMPNAME, следующим образом:
Для поддержки новой функциональности в представление DBA_AUDIT_ POLICIES в Oracle 10* добавлен ряд дополнительных столбцов.
Указывает, запускает ли политика ведение журнала аудита FGA в случае выборки (SELECT) данных (YES или NO).
То же самое, но для INSERT.
То же самое, но для UPDATE.
То же самое, но для DELETE.
Столбцы SQL_TEXT и SQL_BIND заполняются только в том случае, если параметр AUDIT_TRAIL установлен в значение DB_EXTENDED (умолчание), а не в DB. Данный столбец отображает значение этого параметра.
Указывает, ведется ли журнал аудита при ссылке на все столбцы списка или на любой из них.
В этом разделе мы сравним FGA с другими технологиями аудита Oracle, в частности с триггерами и обычным аудитом, и рассмотрим причины, по которым использование какого-то из способов может оказаться предпочтительным.
Изменения в базе данных, вызванные выполнением операторов DML, традиционно отслеживались с помощью триггеров. Триггеры уровня строки для таких операторов DML, как INSERT, UPDATE и DELETE, могут регистрировать имя пользователя, временную метку, измененный объект и другие сведения. Приведем пример записи изменений в таблице EMP при помощи триггера:
Начиная с версии Oracle 10* FGA также может регистрировать такие сведения для операторов DML: временную метку изменения, IP-адрес и многое другое. Исчезает ли в связи с этим необходимость в триггерах? Не совсем. В следующих разделах будет показано, что оба подхода имеют свои плюсы и минусы.
Сначала поговорим о детальном аудите. FGA имеет несколько явных преимуществ по сравнению с триггерами.
Первое преимущество уже неоднократно отмечалось в этой главе. FGA позволяет вести записи для пользователей, которые просто выбирают данные, не изменяя их. Триггеры не запускаются при выборке данных, поэтому они бесполезны для аудита операторов SELECT.
Простота программирования
Триггеры требуют написания большого объема кода, соответствующего вашим конкретным требованиям, который затем еще нужно поддерживать. Со своей стороны, FGA не требует больших усилий от программиста.
Регистрируемые события
Триггеры запускаются только при изменении данных, в то время как FGA ведет журнал вне зависимости от того, менялись ли данные. Если данные были сначала изменены, затем изменение было откачено, то триггеры не зарегистрируют изменения (если только вы не используете автономные транзакции). FGA вносит записи в журнал аудита посредством автономных транзакций, поэтому обращения к данным будут записаны. В системах с высокой защищенностью такое требование может быть обязательным.
При выполнении изменения триггеры уровня строки вносят в журнал аудита по одной записи для каждой измененной строки. В случае с FGA для каждого оператора в журнал аудита записывается всего одна строка, вне зависимости от того, сколько строк затронуто, что уменьшает объем журнала.
Если вы хотите отслеживать доступ только к некоторым столбцам, то можно использовать предложение WHERE триггера. Например, для записи обращений только к столбцу SALARY, изменим триггер следующим образом:
Результат в обоих случаях будет одним и тем же: изменения будут регистрироваться только при обращении к столбцу SALARY. Но есть одно важное отличие. Если столбец SALARY не изменяется, а просто упоминается в предикате, то FGA будет учитывать этот факт, а триггеры - нет.
Теперь предположим, что существует представление VW_EMP для таблицы EMP. Это представление, в отличие от таблицы, доступно конечным пользователям, так что вы могли бы определить набор триггеров INSTEAD OF для манипулирования таблицей в случаях, когда пользователи будут манипулировать данными представления. Однако если триггер INSTEAD OF изменит элемент данных, то определенные для таблицы триггеры аудита не смогут увидеть это изменение и соответственно не зарегистрируют его. FGA регистрирует любые изменения вне зависимости от того, как они были совершены.
Всегда ли FGA отслеживает небольшие изменения лучше, чем триггеры? Это не совсем так. В большинстве случаев FGA с легкостью обеспечивает механизм детального аудита, необходимый для удовлетворения ваших требований. Однако в некоторых случаях триггеры работают лучше, чем FGA:
Отсутствие необходимости выделения большого сегмента отката Когда пользователь Scott изменяет элемент данных, как можно узнать, каким было значение до изменения? Ранее уже говорилось о том, что можно использовать ретроспективные запросы Oracle для получения старого значения из таблицы с помощью номера SCN, записанного в журнале аудита. Например, для определения того, каким было значение SALARY до того, как Scott его изменил, следует выполнить такой запрос:
SELECT salary FROM emp AS OF scn 14122310350 WHERE empid = 100;
Изменение произошло 6 июня, а сегодня 20 июня, т. е. прошло 14 дней после изменения. Ретроспективный запрос использует для восстановления данных сегменты отката, так что данные должны
там присутствовать. Для того чтобы можно было вернуться к данным по состоянию на 14 дней назад, параметр инициализации UNDO_RETENTION_PERIOD должен быть установлен в 14 дней. Для этого в свою очередь необходимо, чтобы табличное пространство отката было достаточно большим, чтобы вмещать в себя такой объем данных. В большинстве компаний выделение такого большого табличного пространства может быть весьма проблематичным. Дополнительную сложность создает тот факт, что при остановке базы данных данные отката пропадают.
Если же вместо FGA использовать для отслеживания подобных изменений триггеры, то старые значения можно легко сохранить в самом журнале аудита, и огромное табличное пространство отката не понадобится. Кроме того, старые значения «выживут» и при остановке базы данных. Так что в подобных ситуациях, вероятно, разумнее применять триггеры, а не FGA.
Хранение выборочных данных
Данные отката собираются не только для интересующих вас изменений базы данных, но и для всех вообще. В активно используемых базах данных может формироваться значительный объем данных отката, и может случиться так, что необходимая информация будет вычищена из сегментов отката до того, как ее удастся использовать в ретроспективном запросе.
Как уже говорилось в предыдущем пункте, при работе с триггерами данные будут сразу сохранены в таблицах, и никакая очистка им не страшна.
При определенных обстоятельствах FGA формирует гораздо более объемный и гораздо менее полезный журнал аудита, чем тот, что можно получить при использовании триггеров. Пусть пользователь Scott выполняет такой оператор DML:
UPDATE hr.emp SET salary = 14000 WHERE empid = 100;
Если для таблицы EMP определена политика FGA, для этого оператора будет сформирована запись в журнале аудита. Так как журнал FGA ведется в режиме автономных транзакций, запись в журнале аудита фиксируется вне зависимости от того, что произошло в транзакции пользователя Scott. Предположим, что Scott откатывает, а не фиксирует изменение. Фактически строка не была обновлена, однако запись в журнале зафиксирована и не откатывается. В результате в журнале аудита присутствуют ложные результаты.
Если использовать триггеры, то вставка записи в журнал аудита будет частью той же самой транзакции, так что она будет откачена при откате основной транзакции, и ошибочных записей не возникнет. Если система выполняет множество изменений и часто их откатывает, то журнал FGA станет невероятно большим, при этом
большая его часть будет представлять собой ложные данные. Разумнее использовать триггеры.
Очевидно, что FGA не может полностью заменить собой триггеры, каждый подход имеет свою нишу. Принимая решение об использовании FGA, внимательно проанализируйте приведенные отличия и посмотрите, какой из способов лучше подходит в каждой конкретной ситуации.
| < Предыдущая | Следующая > |
|---|
