Детальный аудит для практических целей

Научитесь использовать средства детального аудита в сервере Oracle Database для того, чтобы отслеживать доступ к конкретным строкам таблиц в режиме "только для чтения" и в других целях.

Традиционные опции аудита в сервере Oracle Database позволяют вам отслеживать на макроуровне действия, выполняемые пользователями над объектами – например, если вы выполняете аудит операторов SELECT, выбирающих данные из таблицы, вы можете следить, кто выбирает данные из таблицы. Однако вы не сможете узнать, что они выбирают. Для операторов манипулирования данными, таких, как INSERT, UPDATE или DELETE, вы можете собирать данные о любых изменениях, используя триггеры или утилиту Oracle LogMiner – анализатор архивных журнальных файлов. Поскольку операторы SELECT не манипулируют данными, они не инициируют запуск триггеров и данные об их выполнении не поступают в архивные журнальные файлы, которые вы могли бы анализировать, так что эти два способа не оправдывают ожиданий, когда дело касается операторов SELECT.

В сервере Oracle9i Database введена новая возможность, названная детальным аудитом (FGA, fine-grained auditing), которая изменила все изложенное выше. Эта возможность позволяет вам выполнять аудит отдельных операторов SELECT. В дополнение к простому отслеживанию выполнения операторов FGA обеспечивает способ моделирования триггеров для операторов SELECT, выполняя некоторый код всякий раз, когда пользователь выбирает определенный набор данных. В первой части мы сосредоточимся на том, как построить основную систему FGA.

Настройка примера

Наш пример основан на банковской системе, в которой записи аудита (audit trails) пользовательского доступа к определенным данным традиционно обеспечиваются аудитом на уровне приложения. Однако система терпит неудачу всякий раз, когда пользователи обращаются к данным за пределами приложения, используя инструментальные средства типа SQL*Plus. Администратор базы данных, с помощью FGA может выполнить задачу сбора данных о SELECT-доступе пользователей к определенным строкам, независимо от используемого инструмента или механизма доступа.

В нашем примере в базе данных есть таблица, названная ACCOUNTS (счета) и принадлежащая схеме BANK. Таблица имеет следующую структуру:

Name Null? Type

---------------- -------- ------------

ACCT_NO NOT NULL NUMBER

CUST_ID NOT NULL NUMBER

BALANCE NUMBER(15,2)

Для построения системы, которая может выполнять аудит любой выборки из этой таблицы, вам требуется определить для этой таблицы правило аудита, правило FGA (FGA policy), следующим образом:

begin

dbms_fga.add_policy (

object_schema=>'BANK',

object_name=>'ACCOUNTS',

policy_name=>'ACCOUNTS_ACCESS'

);

end;

Этот код должен быть выполнен пользователем, который имеет привилегию выполнения пакета dbms_fga. Однако по соображениям безопасности желательно не предоставлять эту привилегию пользователю BANK, владельцу таблицы, которая подвергается аудиту; предпочтительнее предоставить ее доверенному пользователю с именем, скажем, SECMAN, который должен выполнить эту процедуру, чтобы добавить правило аудита (add_policy).

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

select * from bank.accounts;

В журнале аудита (audit trail) это действие зарегистрируется. Вы можете проверить журнал аудита, введя:

select timestamp,

db_user,

os_user,

object_schema,

object_name,

sql_text

from dba_fga_audit_trail;

TIMESTAMP DB_USER OS_USER OBJECT_ OBJECT_N SQL_TEXT

--------- ------- ------- ------- -------- ----------------------

22-SEP-03 BANK ananda BANK ACCOUNTS select * from accounts

Обратите внимание на новое представление с именем DBA_FGA_AUDIT_TRAIL, в которое записывается информация детального аудита. Между прочим, в представлении содержатся: отметка времени возникновения события аудита (TIMESTAMP), имя пользователя базы данных, который выполнил запрос (DB_USER), его же имя как пользователя операционной системы (OS_USER), имя владельца и название таблицы, используемой в запросе (OBJECT_SCHEMA и OBJECT_NAME) и, наконец, сам запрос. Информацию такого вида было невозможно получить до выхода сервера Oracle9i Database, но с появлением FGA эта процедура стала обычной.

FGA в сервере Oracle9i Database позволяет собирать данные только об операторах SELECT. FGA в сервере Oracle Database 10g может также обрабатывать DML-запросы – INSERT, UPDATE и DELETE, обеспечивая возможность полного аудита.

Столбцы аудита и условия аудита

Рассмотрим предыдущий пример более подробно. Мы потребовали, чтобы аудит выполнялся для любого оператора SELECT, используемого для запроса к таблице. В действительности в этом, вероятно, нет необходимости, и это может "завалить" данными таблицу аудита, в которой хранится информация аудита. Банк, возможно, должен выполнять аудит тогда, когда пользователь выбирает данные из столбца BALANCE (остаток на счете), которая содержит конфиденциальную информацию, но не должен выполнять аудит тогда, когда пользователь выбирает номер счета для конкретного клиента. Столбец BALANCE, выборка из которого инициирует событие аудита, называют столбцом аудита (audit column), и в этом случае параметр процедуры dbms_fga.add_policy задает это следующим образом:

audit_column => 'BALANCE'

Если в журнале аудита регистрируется каждая пользовательская выборка из таблицы, размер журнала будет расти, приводя к проблемам с пространством и администрированием, так что вы можете выполнять аудит только в случае удовлетворения определенным условиям, а не каждый раз. Возможно, банк нуждается в аудите только тогда, когда пользователи обращаются к счетам чрезвычайно богатых клиентов, например тогда, когда пользователь выбирает данные из счета с балансом, равным $11,000 и больше. Такой тип условия называют условием аудита (audit condition), и оно передается как параметр процедуры dbms_fga.add_policy следующим образом:

audit_condition => 'BALANCE >= 11000'

Посмотрим, как работают эти два параметра. Определение правила аудита теперь выглядит так:

begin

dbms_fga.add_policy (

object_schema=>'BANK',

object_name=>'ACCOUNTS',

policy_name=>'ACCOUNTS_ACCESS',

audit_column => 'BALANCE',

audit_condition => 'BALANCE >= 11000'

);

end;

В этом случае аудит будет выполняться только тогда, когда пользователь выбирает данные из столбца BALANCE и извлеченные строки содержат баланс больший или равный $11,000. Если любое из этих условий не выполняется, действие не регистрируется в журнале аудита. Примеры в таблице 1 иллюстрируют различные сценарии: когда действия будут регистрироваться в журнале аудита и когда не будут.

Таблица 1. Различные сценарии, иллюстрирующие, выполняется или не выполняется аудит действий.

SQL-оператор	Состояние аудита
select balance from accounts;	Аудит выполняется. Пользователь выбирает данные из столбца аудита BALANCE, заданного при добавлении правила аудита.
select * from accounts;	Аудит выполняется. Даже если пользователь явно не указывает столбец BALANCE, метасимвол "*" в списке выборки неявно задает его выборку.
select cust_id from accounts where balance < 10000;	Аудит выполняется. Даже если пользователь явно не указывает столбец BALANCE, его выборка неявно задается в предложении WHERE.
select cust_id from accounts;	Аудит не выполняется. Пользователь не выбирает данные из столбца BALANCE.
select count(*) from accounts;	Аудит не выполняется. Пользователь явно или неявно не выбирает данные из столбца BALANCE.

Режим оптимизатора

Для правильной работы FGA требуется оптимизация по стоимости (CBO, cost-based optimization). При оптимизации по синтаксису (rule-based optimization) записи в журнал аудита генерируются всякий раз, когда пользователь обращается к таблице, независимо от того, выбраны ли значимые столбцы или нет; увеличивается и возможность появления ложноположительных входов. Условиями нормальной работы FGA являются следующие: в дополнение к CBO, включенному на уровне экземпляра, в SQL-операторах не должно быть никаких подсказок RULE, и все таблицы в запросе должны быть проанализированы по крайней мере в оценочном режиме.

Управление правилами FGA

Ранее вы видели, как добавить правило FGA. Чтобы удалить правило, можно использовать следующее:

begin

dbms_fga.drop_policy (

object_schema => 'BANK',

object_name => 'ACCOUNTS',

policy_name => 'ACCOUNTS_ACCESS'

);

end;

Нет никакого "коробочного" решения, меняющего правило. Чтобы изменить любые параметры правила, вы должны удалить правило и добавить его снова с измененными параметрами.

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

begin

dbms_fga.enable_policy (

object_schema => 'BANK',

object_name => 'ACCOUNTS',

policy_name => 'ACCOUNTS_ACCESS',

enable => FALSE

);

end;

Для повторного включения правила используйте эту же функцию, но в параметре enable (включение) нужно установить значение TRUE.

Модуль обработчика

Мощность FGA не ограничивается простой регистрацией событий в журнале аудита; FGA может также выполнять процедуры. Процедура могла бы выполнять действия типа отправки предупреждения аудитору по электронной почте, когда пользователь выбирает определенную строку из таблицы, или писать другие записи аудита. Этот хранимый сегмент кода, который может быть автономной процедурой или процедурой пакета, называют модулем обработчика (handler module). Он не обязательно должен находиться в той же самой схеме, что и сама базовая таблица; по соображениям безопасности вы можете преднамеренно разместить его в отдельной схеме. Поскольку процедура выполняется всякий раз, когда происходит выборка, она очень похожа на триггеры, срабатывающие при выполнении DML-операторов; вы можете также думать о нем как о триггере операторов SELECT. Следующие параметры определяют, как модуль обработчика задается в правилах:

handler_schema – схема, которой принадлежит процедура, handler_module – имя процедуры.

Модуль обработчика может также быть пакетной процедурой. В таком случае параметр handler_module задается в формате пакет.процедура.

Представления словаря данных для FGA

Определения правил FGA находятся в представлении словаря данных DBA_AUDIT_POLICIES. В таблице 2 дано краткое описание некоторых важных столбцов этого представления.

Таблица 2. Важные столбцы представления словаря данных DBA_AUDIT_POLICIES.

OBJECT_SCHEMA	Владелец таблицы или представления, для которого определено правило FGA.
OBJECT_NAME	Имя таблицы или представления.
POLICY_NAME	Имя правила аудита, например, ACCOUNTS_ACCESS.
POLICY_TEXT	Условие аудита, заданное при добавлении правила аудита, например, BALANCE >= 11000.
POLICY_COLUMN	Столбец аудита, например, BALANCE.
ENABLED	YES, если проверка правила аудита включена; NO − в противном случае.
PF_SCHEMA	Схема, которой принадлежит модуль обработчика для правила аудита, если он существует.
PF_PACKAGE	Имя пакета, содержащего модуль обработчика, если он существует.
PF_FUNCTION	Имя процедуры модуля обработчика, если она существует.

Записи аудита хранятся в таблице FGA_LOG$, принадлежащей схеме SYS. Так же, как и для других необработанных (raw) таблиц схемы SYS, предусмотрен ряд представлений данной таблицы, дающих информацию в удобном для пользователей виде. DBA_FGA_AUDIT_TRAIL – одно из представлений этой таблицы. В таблице 3 кратко описаны важные столбцы этого представления.

Таблица 3. Важные столбцы представления DBA_FGA_AUDIT_TRAIL.

SESSION_ID	Идентификатор сеанса, в котором был выполнен запрос (Audit Session Identifier); не совпадает с идентификатором сеанса (SID, Session Identifier) в представлении V$SESSION.
TIMESTAMP	Отметка времени генерации записи аудита.
DB_USER	Имя пользователя базы данных, который выполнил запрос.
OS_USER	Имя пользователя операционной системы.
USERHOST	Имя машины, с которой соединен пользователь.
CLIENT_ID	Идентификатор клиента, если установлен с помощью пакетной процедуры dbms_session.set_identifier.
EXT_NAME	Имя клиента, аутентифицированного внешне, например, LDAP-пользователь.
OBJECT_SCHEMA	Владелец таблицы, доступ к которой инициирует событие аудита.
OBJECT_NAME	Имя таблицы, доступ к которой инициирует событие аудита.
POLICY_NAME	Имя правила аудита, инициирующего событие аудита. (Если для таблицы определено несколько правил аудита, для каждого из них будет генерироваться запись аудита. В таком случае этот столбец показывает, для какого правила была вставлена запись аудита.)
SCN	Системный номер изменения Oracle (System Change Number), на момент которого была записана запись аудита.
SQL_TEXT	SQL-оператор, выполненный пользователем.
SQL_BIND	Переменные связывания, использованные в SQL-операторе, если использовались.

Один из важных столбцов – SQL_BIND, в котором содержатся значения переменных связывания, использованные в запросах, – сведения, которые существенно повышают мощность средств активного аудита.

Другой важный столбец – SCN, в котором содержатся системные номера изменений (SCN, System Change Number), на момент которых был выполнен конкретный запрос. Эта информация полезна, чтобы определить, что пользователь видел в конкретное время, а не какое значение установлено сейчас; это делается с помощью ретроспективных запросов (Flashback Queries), которые могут показать данные на момент указанного значения SCN.

Представления и FGA

До сих пор мы рассматривали применение FGA для аудита запросов к таблицам; теперь давайте посмотрим, как вы можете использовать FGA для аудита запросов к представлениям. Предположим, представление VW_ACCOUNTS определено на таблице ACCOUNTS следующим образом:

create view vw_accounts as select * from accounts;

Теперь, если пользователь выбирает данные из этого представления, а не из таблицы:

select * from vw_accounts;

вы увидите в журнале аудита следующую запись:

select object_name, sql_text from dba_fga_audit_trail;

OBJECT_NAME SQL_TEXT

----------- -------------------------------------------------

ACCOUNTS select * from vw_accounts

Обратите внимание, что в столбце OBJECT_NAME появляется имя базовой таблицы, а не представления, потому что в представлении данные выбираются из базовой таблицы. Однако в столбце SQL_TEXT записан фактический оператор, выданный пользователем, и это – точно то, что вы хотите знать.

Если вы хотите выполнять аудит запросов только к представлениям, а не к таблицам, вы можете установить правила аудита непосредственно для представления. Вы делаете это, указывая в параметре object_name пакетной процедуры dbms_fga.add_policy вместо имени таблицы имя представления. В этом случае столбец OBJECT_NAME в представлении DBA_FGA_AUDIT_TRAIL будет показывать имя представления, и не будет никаких дополнительных записей о доступе к таблице.

Другие примеры использования FGA

В дополнение к регистрации доступа к таблицам в режиме "только для чтения" средства FGA полезны также в некоторых других ситуациях:

• вы можете использовать FGA в системах хранилищ данных для регистрации всех операторов, обращающихся к конкретной таблице, представлению или материализованному представлению, что полезно для планирования индексов. Вам не нужно обращаться к представлению V$SQL для получения этой информации. И даже если SQL-оператор из-за старения будет вытеснен из представления V$SQL, он всегда будет доступен в журнале аудита FGA;

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

• как было упомянуто ранее, модуль обработчика может отправлять предупреждения аудиторам или администраторам базы данных, что удобно для слежения за нестандартными приложениями;

• поскольку FGA может действовать как триггер для операторов SELECT, вы можете использовать его всякий раз, когда требуются такие функциональные возможности.

Заключение

FGA позволяет вам поддерживать правила конфиденциальности (privacy) и наблюдаемости (accountability) в системах баз данных Oracle.

Примечание

1. Возможность для ответственных за защиту информации лиц восстанавливать ход или попытки нарушения безопасности информационной системы.

2. Свойство компьютерной системы, позволяющее фиксировать деятельность пользователей и процессов, использования пассивных объектов, и однозначно устанавливать идентификаторы причастных к определенным событиям пользователей и процессов с целью предотвращения нарушения политики безопасности и/или обеспечения ответственности за определенные действия.

Поскольку аудит происходит в сервере базы данных, а не в приложении, действия регистрируются независимо от методов доступа, используемых пользователями (через инструментальные средства типа SQL*Plus или приложения), обеспечивая защиту от неосторожного или неумелого обращения.

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

Проблема пользователей приложения

В предшествующей статье объяснялось, как настроить FGA, чтобы записать в таблицу FGA_LOG$ данные о пользователях базы данных, которые выполняли запросы. Этот подход работает хорошо в тех случаях, когда пользователь базы данных соответствует одному-единственному физическому пользователю. Однако в некоторых случаях, например, с веб-приложениями, сервер приложений соединяется с базой данных, используя неизменный пользовательский идентификатор, скажем, APPUSER. Пользователи приложения аутентифицируются приложением. Например, пользователь SCOTT соединяется с приложением, которое аутентифицирует его, а затем оно соединяется с базой данных, используя идентификатор пользователя APPUSER. Если средства FGA будут использоваться в такой среде, то они будут показывать пользователя APPUSER, а не SCOTT. Точно так же и другой пользователь приложения JANE, выбирающий данные, будет также регистрироваться как пользователь APPUSER, а не JANE. Поскольку зарегистрированное в журнале аудита имя пользователя не является именем фактического пользователя, цели аудита не будут достигнуты.

Первое решение, которое приходит на ум, состоит в том, чтобы создать пользователей приложений в базе данных, позволяя приложению соединяться с базой данных, используя те же идентификаторы пользователей и пароли. Скажем, в вышеприведенном примере пользователи SCOTT и JANE будут пользователями базы данных и не будет никакой потребности иметь пользователя по имени APPUSER. Этот подход прост и безопасен, поскольку пользователь аутентифицируется сервером базы данных, и имя пользователя остается тем же самым независимо от способа подключения.

При таком подходе, однако, все пользователи должны быть созданы в базе данных, что приведет к кошмару администрирования, особенно когда число пользователей достигнет нескольких тысяч, что является обычным в веб-приложениях. Кроме того, пользователи должны запоминать свои имена пользователей и пароли в различных местах; неудобство, которое полностью оправдает существование опции однократной регистрации (SSO, Single Sign-On). Хотя эта проблема может быть решена при использовании опции расширенной безопасности (ASO, Oracle Advanced Security Option), также известной как расширенная сетевая опция (ANO, Advanced Networking Option) наряду с использованием интернет-каталога Oracle (OID, Oracle Internet Directory), для большинства сайтов это решение не подходит.

В веб-приложениях в концепции пула соединений (connection pooling) также требуется использование одного универсального идентификатора пользователя. Как показано на следующем рисунке, сервер приложений создает несколько соединений с базой данных, используя пользователя APPUSER. Когда пользователю приложения, такому, как SCOTT, требуется обслуживание, относящееся к базе данных, приложение для выполнения запроса использует одно из этих соединений с базой данных. Эта модель может поддерживать много пользователей, используя только несколько соединений и, следовательно, находит поддержку у архитекторов веб-приложений. Но снова этот подход не позволяет FGA записать правильное имя пользователя.

Надписи на рисунке:

• Web Sessions – веб-сеансы;

• Connection Pool – пул соединений;

• Database Sessions – сеансы базы данных.

Аргументы в пользу универсальных идентификаторов пользователей приложений очень сильны. Таким образом, предпочтительнее не пытаться "избавиться" от этого требования, идеальное решение состоит в том, чтобы использовать в среде FGA идентификаторы пользователей приложений.

Идентификатор клиента

В СУБД Oracle9i введено понятие идентификатора клиента (client identifier), который является значением, устанавливаемым в качестве атрибута сеанса. Все, что находится в этом атрибуте, в нашей ситуации мы можем использовать для представления имени фактического пользователя, такого, как JANE. И даже если имя пользователя базы данных зарегистрировано как APPUSER или что-то подобное, идентификатор клиента может иметь значение JANE.

Вы можете установить значение идентификатора клиента для сеанса с помощью поставляемой корпорацией Oracle пакетной процедуры dbms_session.set_identifier. Следующий оператор устанавливает в сеансе идентификатор SCOTT:

EXECUTE DBMS_SESSION.SET_IDENTIFIER ('SCOTT')

После установки этот идентификатор виден для данного сеанса в представлении V$SESSION:

SELECT CLIENT_IDENTIFIER

FROM V$SESSION

WHERE AUDSID = USERENV('SESSIONID');

Здесь будет показано значение SCOTT, которое и было установлено ранее. Итак, какова важность этого значения? В дополнение к тому, что эта информация находится в представлении V$SESSION, она также обнаруживается в среде FGA в таблице FGA_LOG$ и, впоследствии, в представлении DBA_FGA_AUDIT_TRAIL в столбце CLIENT_ID, как показано ниже:

SELECT DB_USER, CLIENT_ID FROM DBA_FGA_AUDIT_TRAIL;

И даже если столбец DB_USER показывает пользователя базы данных, в журнале аудита FGA может быть найден реальный пользователь приложения, если его имя установлено в идентификаторе клиента. Это очень важно для понимания и применения во время аудита пользователей приложения.

Идентификатор клиента также находится в журнале обычного аудита, а не только в журнале детального аудита. Итак, во всех типах аудита, от обычного до расширенного детального, это значение обеспечивает недостающую связь для представления фактического пользователя. В случае обычного аудита идентификатор клиента, если он установлен в сеансе, записывается в таблицу AUD$ в столбец CLIENTID. Это значение находится в зависимых представлениях, таких, как DBA_AUDIT_TRAIL, в столбце CLIENT_ID.

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

Другой подход состоит в том, чтобы создать "куку" (cookie) и использовать это значение для установки идентификатора клиента. Этот способ более безопасен, поскольку "кука" может содержать другую аутентификационную информацию, которая не доступна в обычном сеансе. Значение в идентификаторе в этом случае может быть должным образом декодировано для получения реального имени пользователя, но аутентификационная информация добавляет к значению идентификатора клиента компонент целостности данных.

Контексты приложений

Использование идентификатора клиента имеет свои преимущества, но также и представляет серьезную угрозу безопасности: эта установка предполагает, что пользователь установит в идентификаторе значение реального идентификатора пользователя, но этого нельзя гарантировать. Злонамеренный пользователь может соединиться с базой данных и установить значение другого идентификатора пользователя, что серьезно подрывает достоверность журнала аудита. В веб-приложениях использование "куков" для хранения идентификаторов клиентов делает эту задачу трудной, если не невозможной; но в обычных приложениях использование только клиентских идентификаторов не обеспечивает удовлетворительной защиты. Нам требуется более безопасное средство фиксации пользователей приложения в журнале аудита.

Предложим решение: контексты приложений (application contexts). Контексты приложений похожи на атрибуты сеанса: после установки к ним можно обращаться в сеансе в любое время. В другом сеансе может быть установлено другое значение, но эти значения не будут видны в других сеансах. Контекст имеет атрибуты, подобные столбцам таблицы; но, в отличие от таблиц, контексты – не объекты сегментов, и атрибуты могут быть определены во время выполнения, а не во время проектирования.

Контекст приложения может быть создан следующим SQL-оператором:

create context my_app_ctx using set_my_app_ctx;

Обратите внимание на предложение using set_my_app_ctx, указывающее, что атрибутами внутри контекста можно манипулировать только с помощью процедуры с именем set_my_app_ctx, определяемой следующим образом:

create or replace procedure set_my_app_ctx

(

p_app_user in varchar2 := USER

)

is

begin

dbms_session.set_context('MY_APP_CTX','APP_USERID', p_app_user);

end;

Эта процедура просто устанавливает в атрибуте APP_USERID значение, передаваемое в ее входном параметре, вызывая для этой установки процедуру dbms_session.set_context. Что случится, если пользователь непосредственно вызовет процедуру dbms_session.set_context?

SQL> exec dbms_session.set_context('MY_APP_CTX','APP_USERID', 'JUNE')

BEGIN dbms_session.set_context('MY_APP_CTX','APP_USERID', 'JUNE'); END;

*

ERROR at line 1:

ORA-01031: insufficient privileges

ORA-06512: at "SYS.DBMS_SESSION", line 78

ORA-06512: at line 1

Обратите внимание на ошибку ORA-01031:insufficient privileges (недостаточные привилегии), которая в данное время немного вводит в заблуждение. Пользователь не имеет привилегии выполнения процедуры SYS.DBMS_SESSION, установка атрибута контекста вызовом этой процедуры запрещена, поэтому возникает ошибка. Однако когда пользователь для установки атрибута вызовет доверенную процедуру:

SQL> execute set_my_app_ctx ('AAAA')

PL/SQL procedure successfully completed.

…она выполнится успешно. Атрибуты контекста могут устанавливаться только с помощью этой процедуры, поэтому она и называется соответствующим образом – доверенная процедура (trusted procedure). Это важное свойство контекста приложения, и оно может использоваться в FGA.

Атрибут контекста, если установлен (в приведенном выше коде), может быть извлечен вызовом функции SYS_CONTEXT:

select sys_context('MY_APP_CTX','APP_USERID') from dual;

Этот оператор возвращает значение атрибута. Если контекст может быть установлен безопасным способом, его можно использовать для установки идентификатора клиента.

Исходя из наших знаний, возможное решение может выглядеть следующим образом:

• приложение выполняет процедуру, которая автоматически устанавливает правильное значение в контексте приложения. В вышеупомянутом примере атрибут контекста использовался для установки идентификатора пользователя, но можно также использовать и другой атрибут, такой, как роль пользователя. В контексте вы можете определять более одного атрибута. Атрибут может использоваться как включаемая роль. В доверенную процедуру можно включить все типы проверок безопасности, обеспечивая защиту и аутентичность. Если эти проверки безопасности будут неудачными, требуемая роль не будет включена. Так, даже если пользователь может успешно соединиться с базой данных, используя учетную запись APPUSER, он будет не в состоянии манипулировать данными, так как соответствующая роль не будет включена. Обратите внимание: роли должны быть ролями, аутентифицируемыми процедурой, а не обычными. Такие роли создаются оператором CREATE ROLE <имя_роли> USING <имя_процедуры>; и пользователь включает роль, вызывая <имя_процедуры>, а не оператором SET ROLE;

• эта процедура также устанавливает идентификатор клиента, так что нет никакой потребности предоставлять привилегии выполнения пакета dbms_session всем пользователям (public), они не нужны даже данному пользователю. Поскольку пользователи не имеют привилегий вызова процедур пакета dbms_session, они не могут непосредственно устанавливать идентификаторы клиентов – те будут устанавливаться и переноситься в журнал детального аудита автоматически.

Этот метод может быть в дальнейшем усовершенствован за счет использования определяемых пользователем записей аудита, в которых в идентификаторах клиентов могут устанавливаться значения, извлекаемые из контекста приложения. Мы обсудим данный метод в третьей (и последней) части этой серии статей.

Что видел пользователь?

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

select balance from accounts

where acct_no = 10034;

Скажем, эта транзакция была выполнена утром в 10:00, а сейчас – 11:00, в это время остаток на счете, возможно, уже был изменен. Если аудитор (или администратор базы данных) решает увидеть точно то, что пользователь действительно видел в то время, существующее значение столбца, возможно, уже не показывает точную информацию. В случаях промышленного шпионажа или для установления повода или профиля необходимы точные данные, просмотренные пользователем. Даже если средства FGA не зафиксировали точные данные на тот момент времени, мы можем увидеть их, используя другую информацию, зафиксированную в журнале аудита. В начале вы видели структуру представления DBA_FGA_AUDIT_TRAIL, в которой имеется несколько ключевых столбцов, связанных с сеансом и пользователем. Подходящий столбец здесь – SCN, в котором содержится системный номер изменения (SCN, System Change Number) на момент времени генерации записи аудита. Используя ретроспективный запрос (flashback query), мы можем реконструировать данные на тот момент времени. Предполагая, что значение SCN в журнале аудита было равно 123456, мы можем выполнить следующий запрос: select balance from accounts as of SCN 123456 where acct_no = 10034;

Предложение as of SCN 123456 позволяет получить из таблицы остаток на счете, который был в нужный нам момент времени.

Поскольку ретроспективный запрос ограничен периодом сохранения информации в пространстве отката (undo retention period), транзакции, которые были выполнены за пределами этого периода, будут потеряны для анализа. Однако аудиторы могут анализировать записи аудита, сгенерированные после данного события аудита, используя ретроспективные запросы только для выборки из важных столбцов.

Теперь, когда вы овладели использованием детального аудита во всех типах сред, научитесь использовать его дополнительные возможности в сервере Oracle Database 10g

.

Ранее были рассмотрены концепции детального аудита (FGA, Fine-Grained Auditing), используемого для отслеживания выполнения операторов SELECT в сервере Oracle9iDatabase и последующих версиях, как использовать эти средства в сложных средах, таких, как веб-приложения, применяя в них контексты приложений и идентификаторы клиентов. Эти две статьи содержат достаточную информацию для того, чтобы сформировать систему FGA в почти всех типах систем базы данных, какими бы сложными они ни были. Далее рассмотрим усовершенствования FGA в сервере Oracle Database 10g.

Fga в сервере Oracle9iDatabase

Кратко резюмируем преимущества, обеспечиваемые использованием FGA. Более подробное обсуждение см. в части 1ичасти 2этой серии статей.

Обычный аудит (с помощью оператора AUDIT) записывает используемый оператор, такой, как оператор SELECT или INSERT, а также информацию о том, кто выдал его, с какого терминала, когда и некоторые другие сведения. Однако самый важный момент – какая конкретнаязапись была изменена и какое изменение было сделано непосредственно в данных – не фиксируется. Вместо этого многие пользователи пишут триггеры для перехвата значений данных до и после изменения и записи их в определяемые пользователями таблицы. Но триггеры срабатывают только при выполнении DML-операторов, таких, как INSERT, UPDATE и DELETE, аудит же основного средства доступа – оператора SELECT – не может быть выполнен таким способом.

Следовательно, достоинство средств FGA в том, что они перехватывают только операторы SELECT. Вместе с триггерами и утилитой LogMiner средства FGA обеспечивают механизм аудита всех типов доступа к данным, связанного и несвязанного с изменением значений данных.

FGA не только восполняет пробел в аудите операторов SELECT, но также обеспечивает и некоторые другие интересные дополнительные выгоды, облегчающие работу администратора базы данных. Например, FGA позволяет определяемой пользователем процедуре выполняться каждый раз, когда выполняется указанное условие аудита, так что вы можете считать его триггером операторов SELECT – средство, которое иным способом реализовать нельзя. Этот прием может быть очень полезен, например, чтобы отправлять электронные письма аудитору безопасности всякий раз, когда кто-то выбирает записи из платежной ведомости для служащих, зарабатывающих более 1 миллиона долларов; также удобно генерировать записи аудита в определяемых пользователями таблицах, которыми можно манипулировать без ограничений, существующими для таблицы FGA_LOG$ в схеме SYS; удобно использовать записи аудита для определения типа доступа к данным с целью поиска возможно лучшего механизма индексации и т.п.

По этой, а также и другим причинам место FGA – среди самых важных средств в инструментарии администратора базы данных. Однако в сервере Oracle9iDatabase отсутствует одна важная возможность – возможность выполнения аудита операторов, отличных от оператора SELECT.

Все типы dml-операторов

В сервере Oracle Database 10gсредства FGA стали функционально полными – они позволяют выполнять аудит всех типов DML-операторов, а не только операторов SELECT.

Рассмотрим пример. В начале было показано как использовать таблицу по имени ACCOUNTS (счета). Правило FGA (FGA policy), определенное для этой таблицы, было следующим:

begin

dbms_fga.add_policy (

object_schema => 'BANK',

object_name => 'ACCOUNTS',

policy_name => 'ACCOUNTS_ACCESS',

audit_column => 'BALANCE',

audit_condition => 'BALANCE >= 11000'

);

end;

В сервере Oracle 9iDatabase это правило позволяло выполнять аудит только операторов SELECT. Однако в сервере Oracle Database 10gвы можете расширить список операторов, включив в него также операторы INSERT, UPDATE и DELETE. Это делается с помощью нового параметра:

statement_types => 'INSERT, UPDATE, DELETE, SELECT'

Этот параметр включает аудит всех типов операторов, перечисленных в нем. Вы можете также создавать отдельные правила для каждого типа операторов, что позволит вам по желанию включать или отключать правила; это удобно, в частности, для управления генерацией записей аудита с целью управления пространством, занятым ими. Однако по умолчанию параметр statement_type включает аудит только операторов SELECT.

После добавления правила с этим новым параметром при выполнении следующего оператора в таблице FGA_LOG$ появляется запись аудита, например:

update accounts set balance = 1200 where balance >= 3000;

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

select lsqltext from fga_log$;

LSQLTEXT

--------------------------------------------------------

update accounts set balance = 3100 where balance >= 3000

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