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

2005 г.

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

Оригинал - Fine-Grained Auditing for Real-World Problems (oracle.com)
Part 1, Part 2, Part 3

Часть 1

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

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

В сервере Oracle9i Database введена новая возможность, названная детальным аудитом (FGA, fine-grained auditing), которая изменила все изложенное выше. Эта возможность позволяет вам выполнять аудит отдельных операторов SELECT. В дополнение к простому отслеживанию выполнения операторов FGA обеспечивает способ моделирования триггеров для операторов SELECT, выполняя некоторый код всякий раз, когда пользователь выбирает определенный набор данных. В этой серии статей (в трех частях) я объясню, как вы можете использовать FGA для того, чтобы решать реальные проблемы. В первой части мы сосредоточимся на том, как построить основную систему 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, обеспечивая возможность полного аудита. В части 3 этой серии статей я подробно объясню эти функции.

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

Рассмотрим предыдущий пример более подробно. Мы потребовали, чтобы аудит выполнялся для любого оператора 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. Я расскажу об этом мощном средстве более подробно в части 2 этой серии статей.

Представления и 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.

Примечание научного редактора А.П.Соколова: Наблюдаемость:

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

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

В следующих частях я расскажу о расширенных возможностях FGA, а также о новых возможностях в сервере Oracle Database 10g, которые делают FGA чрезвычайно мощным средством, подходящим для всех типов аудита.

Часть 2

Арап Нанда (Arup Nanda) (arup@proligence.com) - основатель компании Proligence (Нью-Йорк), предоставляющей высокоспециализированную расширенную поддержку решений Oracle и обучение методам обеспечения информационной безопасности. В 2003 г. он был удостоен награды "Oracle's DBA of the Year"( администратор года баз данных Oracle). Арап - соавтор книги Oracle Privacy Security Auditing (издательство Rampant TechPress, 2003) - "Средства аудита в СУБД Oracle, обеспечивающие информационную безопасность".