Поведение средств fga во время изменения данных

Можно выполнять детальный аудит изменения данных. При этом возникают некоторые интересные вопросы о поведении FGA в различных сценариях. Рассмотрим наш пример, в котором правила FGA определены для аудита операторов UPDATE с условием аудита BALANCE > = 3000 и столбцом аудита BALANCE.

Сценарий 1

Перед изменением: BALANCE = 1000 Пользователь выполняет оператор: update accounts set balance = 1200 where ACCOUNT_NO = .... Старый и новый остатки на счете (balance) меньше 3,000, и условие аудита не выполняется; следовательно, аудит этого оператора невыполняется.

Сценарий 2

Перед изменением: BALANCE = 1000 Пользователь выполняет оператор: update accounts set balance = 3200 where ACCOUNT_NO = .... Новый остаток на счете больше 3,000, и условие аудита выполняется; следовательно, аудит этого оператора будетвыполнен.

Сценарий 3

Перед изменением: BALANCE = 3200 Пользователь выполняет оператор: update accounts set balance = 1200 where ACCOUNT_NO = .... Новый остаток на счете меньше 3,000, но старый остаток больше. Следовательно, условие аудита выполняется, и аудит этого оператора будет выполнен.

Сценарий 4

Пользователь вставляет строку со старым значением столбца BALANCE < 3000. insert into accounts values (9999,1200,'X'); Остаток на счете стал равен 1,200, условие аудита не выполняется, и аудит этого оператора не будет выполнен. Если бы значение столбца остатков было больше или равно 3,000, аудит был бы выполнен.

Сценарий 5

Пользователь вставляет строку с неопределенным (null) значением столбца остатков: insert into accounts (account_no, status) values (9997, 'X'); Остаток на счете имеет неопределенное значение, и никакого значения по умолчанию для этого столбца не имеется; условие аудита не выполняется (в результате сравнения NULL >= 3000 всегда получается FALSE), и аудит этого оператора не будет выполнен. Важное замечание: если бы столбец аудитаимелзначение по умолчанию, превышающее 3,000, аудит оператора все равно не был бы выполнен даже несмотря на то, что значение столбца остатков вставленной строки превышает 3,000.

Все важные столбцы?

Рассмотрим правило аудита, определенное для таблицы ACCOUNTS следующим образом:

begin

dbms_fga.add_policy (

object_schema => 'ANANDA',

object_name => 'ACCOUNTS',

policy_name => 'ACCOUNTS_SEL',

audit_column => 'ACCOUNT_NO, BALANCE',

audit_condition => 'BALANCE >= 3000',

statement_types => 'SELECT'

);

end;

Как видите, правило аудита определено для столбцов аудита ACCOUNT_NO (номер счета) и BALANCE (остаток на счете). Предположим, если остаток на счете 9995 равен 3,200 и пользователь выполнит следующий оператор:

select balance from accounts where account_no = 9995;

то будет выполнен аудит оператора, поскольку данные выбирались из столбца остатков и остаток равен 3,200, больше чем 3,000, что удовлетворяет условию аудита. Оператор будет инициировать событие аудита независимо от того, какие столбцы выбирались (любые из трех).

В некоторых случаях может быть важна комбинация столбцов, а не определенный столбец. Например, если пользователь хочет узнать суммарный остаток на счетах, он выполняет оператор:

select sum(balance) from accounts;

Этот запрос довольно невинен: он определенно не идентифицирует владельца банковского счета и остаток на счете. Политика безопасности (security policy) банка Acme Bank может не требовать аудита таких запросов. Однако аудит следующего запроса должен быть выполнен, так как он идентифицирует конкретный банковский счет:

select balance from accounts where account_no = 9995

По умолчанию выполняется аудит всех операторов независимо от комбинации используемых столбцов. Это приводит к появлению в журнале аудита большого количества ненужных записей и, возможно, к некоторым проблемам с ограничениями пространства. Чтобы уменьшить количество записей аудита, вы можете разрешить генерацию записей аудита только тогда, когда в запросе используются желательные комбинации столбцов. Определяя правило, вы можете использовать новый параметр:

audit_column_opts => DBMS_FGA.ALL_COLUMNS

Этот параметр заставит FGA создавать записи аудита только тогда, когда запрос обращается к обоим столбцам: ACCOUNT_NO и BALANCE. Например, следующий запрос инициирует создание записи аудита:

select account_no, balance from accounts;

Но этот запрос не будет инициировать создание записи аудита:

select account_no from accounts;

Использование этого параметра позволит ограничить объем информации аудита до более приемлемого размера. Если желателен режим аудита по умолчанию, то есть при обращении к любому из столбцов аудита, то вы можете использовать другое значение этого же параметра:

audit_column_opts => DBMS_FGA.ANY_COLUMNS