В некоторых случаях нет необходимости в записи в журнал аудита SQL-текста и значений переменных связывания. Тогда можно отключить регистрацию таких значений для экономии пространства. Для этого (т. е., чтобы не записывать значения переменных связывания) следует установить параметр audit_trail процедуры ADD_POLICY пакета DBMS_FGA в значение DB (прекращение сбора текстов SQL и значений переменных связывания) вместо DB_EXTENDED (сбор текстов SQL и значений переменных связывания). Значение по умолчанию - DB_EXTENDED. Напишем PL/SQL-блок для отключения сбора текстов SQL и значений переменных связывания (параметру audit_trail присваиваем значение константы DBMS_FGA.DB):
Вы уже видели, как FGA может регистрировать факт выборки (SELECT) данных (в Oracle9i) из таблицы или факт выполнения оператора DML (в Oracle 10*) в таблице журнала аудита FGA, FGA_LOG$. FGA поддерживает еще одну важную функцию - возможность выполнения хранимой PL/SQL-программы (хранимой процедуры на PL/SQL или Java-метода). Если хранимая процедура, в свою очередь, инкапсулирует программу оболочки (shell) или операционной системы, то и она может быть выполнена. Такая единица хранимой программы называется модулем обработки (handler module). В предыдущем примере при создании механизма аудита для обращений к таблице EMP можно дополнительно указать хранимую процедуру для выполнения (отдельную или в составе пакета).
Если условия политики аудита выполнены, и встречается ссылка на указанные столбцы, то происходят два события: действие регистрируется в журнале аудита, и выполняется процедура myproc в схеме FGA_ADMIN. Процедура автоматически выполняется в рамках автономной транзакции при каждой вставке записи в журнал аудита. Это означает, что любые изменения, внесенные модулем обработки, будут зафиксированы или отменены без оказания какого-либо воздействия на транзакцию сеанса, вызвавшего модуль обработки. Они также не будут мешать выполнению аудита.
Если по какой-то причине модуль обработки не смог отработать корректно, FGA не сообщает об ошибке при выборке данных из таблицы. Вместо этого FGA просто молча прекращает извлечение строк, для которых не удалось выполнить модуль обработки. Это достаточно коварная ситуация, так как вы никак не узнаете о том, что модуль обработки не отработал. Будут возвращены не все строки, то есть результат будет неверным. Поэтому чрезвычайно важно тщательно тестировать такие модули!
Модуль обработки особенно полезен, если вы хотите записывать данные в собственные таблицы, а не только в обычные таблицы журнала аудита. На первый взгляд может показаться, что речь идет о простом повторении уже имеющейся функциональности. Однако в следующих разделах будет показано, что тем самым вы можете значительно расширить свои возможности.
Если вы помните, при детальном аудите журналы аудита пишутся в таблицу FGA_LOG$ схемы SYS табличного пространства SYSTEM. Такой механизм имеет три потенциально слабых места.
цедуры myproc, принадлежащей пользователю FGA_ADMIN, просто вызываем процедуру ADD POLICY с двумя новыми параметрами:
1. Так как эта таблица содержит сведения обо всех обращениях ко всем таблицам, для которых определен детальный аудит, ее содержимое является конфиденциальным и должно быть защищено. Однако пользователь SYS или любой другой пользователь с ролью администратора базы данных может без труда удалять строки из этой
таблицы, удаляя тем самым записи журнала FGA. Для чрезвычайно требовательных к безопасности организаций (в особенности тех, чья деятельность регулируется специальными нормативами, такими как HIPAA, Sarbanes-Oxley, Visa Cardholder Information Security Policy) возможность подделки данных аудита недопустима. Обеспечение безопасности для журнала аудита является первостепенной задачей, а механизм аудита «по умолчанию» этого не гарантирует.
Журналы аудита ведутся не только для операторов DML, но и для SELECT, поэтому за короткое время может быть сгенерировано большое количество записей. Частота обращений к базе данных и количество заданных параметров аудита определяют, насколько серьезными могут быть вызванные этим проблемы. В базе данных OLTP журналы аудита (расположенные в схеме SYS и табличном пространстве SYSTEM) могут существенно «раздуть» табличное пространство SYSTEM. Даже если таблица будет усекаться после периодического архивирования, может оказаться, что увеличившиеся файлы данных не могут сократиться до прежнего размера, и в конце концов в табличном пространстве SYSTEM будет масса неиспользуемого места.
Альтернативный подход заключается в создании пользовательского журнала аудита и помещении его в пользовательское табличное пространство, где им так же удобно управлять, как и любым другим табличным пространством. Можно также специально спроектировать таблицу таким образом, чтобы оптимизировать производительность и архивацию. Например, можно секционировать таблицу, сделав управление более гибким.
При настройке по умолчанию записи просто вносятся в журнал, никакого уведомления о возникшей проблеме никому не отсылается. Oracle не поддерживает возможность создания триггеров для таблицы журнала аудита, которые можно было бы использовать для отправки электронных сообщений или предупреждений. Однако возможность автоматического вызова хранимой программы может быть весьма полезной, если необходимо выполнить какое-то предопределенное действие при выполнении условий аудита. Например, когда кто-то рассматривает данные о зарплате наиболее высокооплачиваемых топ-менеджеров вашей компании, можно отправлять уведомление сотруднику службы безопасности посредством Oracle Advanced Queuing или Oracle Streams. Можно также отправить электронное сообщение при наступлении определенного события или зарегистрировать факты доступа к данным сотрудников высокого ранга в специальной таблице.
Решить возможные проблемы может пользовательская настройка аудита. Создадим таблицу для хранения записей. Она могла бы входить
в любую схему, но из соображений безопасности поместим ее в схему,
1 О
|
CREATE TABLE flagged_access (
|
|
2
3
|
(
fgasid NUMBER(20),
|
|
4
|
entryid NUMBER(20),
|
|
5
|
audit_date DATE,
|
|
6
|
fga_policy VARCHAR2(30),
|
|
7
|
db_user VARCHAR(30),
|
|
8
|
os_user VARCHAR2(30),
|
|
9
|
authent_type VARCHAR2(30),
|
|
10
|
client_id VARCHAR2(100),
|
|
11
|
client_info VARCHAR2(64),
|
|
12
|
host_name VARCHAR2(54),
|
|
13
|
instance_id NUMBER(2),
|
|
14
|
ip VARCHAR2(30),
|
|
15
|
term VARCHAR2(30),
|
|
16
|
schema_owner VARCHAR2(20),
|
|
17
|
table_name VARCHAR2(30),
|
|
18
|
sql_text VARCHAR2(64),
|
|
19
|
SCN NUMBER(10)
|
|
20
|
)
|
|
21
|
TABLESPACE audit_ts
|
|
22
|
PARTITION BY RANGE (audit_date)
|
|
23
|
(
|
|
24
|
PARTITION y04m01 VALUES
|
LESS THAN
|
25
|
(TO_DATE('02/01/2004
|
,'mm/dd/yyyy')),
|
26
|
PARTITION y04m02 VALUES
|
LESS THAN
|
27
|
(TO_DATE('03/01/2004
|
,'mm/dd/yyyy')),
|
28
|
PARTITION y04m03 VALUES
|
LESS THAN
|
29
|
(TO_DATE('04/01/2004
|
,'mm/dd/yyyy')),
|
30
|
PARTITION y04m04 VALUES
|
LESS THAN
|
31
|
(TO_DATE('05/01/2004
|
,'mm/dd/yyyy')),
|
32
|
PARTITION y04m05 VALUES
|
LESS THAN
|
33
|
(TO_DATE('06/01/2004
|
,'mm/dd/yyyy')),
|
34
|
PARTITION y04m06 VALUES
|
LESS THAN
|
35
|
(TO_DATE('07/01/2004
|
,'mm/dd/yyyy')),
|
36
|
PARTITION y04m07 VALUES
|
LESS THAN
|
37
|
(TO_DATE('08/01/2004
|
,'mm/dd/yyyy')),
|
38
|
PARTITION y04m08 VALUES
|
LESS THAN
|
39
|
(TO_DATE('09/01/2004
|
,'mm/dd/yyyy')),
|
40
|
PARTITION def VALUES LESS THAN
|
|
41 42*
|
(MAXVALUE)
|
|
которая для других целей использоваться не будет. Будем использовать ту же схему, что и раньше: FGA ADMIN. Вот пример такой таблицы:
Стратегия очистки данной таблицы чрезвычайно проста: каждый месяц все данные аудита, срок хранения которых превышает один месяц, перемещаются в отдельное автономное хранилище и удаляются из таблицы. Таким образом, происходит помесячное диапазонное секционирование таблицы по столбцу AUDIT_DATE. Когда приходит время очист-
ки, я преобразую секцию в таблицу, используя команду ALTER TABLE...EXCHANGE PARTITION, а затем пересылаю содержимое на магнитную ленту при помощи такой функциональности Oracle, как Transportable Tab- lespace (переносимые табличные пространства). Затем удаляю раздел. Каждый месяц создаются новые секции для наступающих месяцев.
Теперь необходимо создать процедуру для заполнения таблицы. Будем работать в той же безопасной схеме, где хранится таблица (например, FGA_ADMIN). Процедура будет вызывать встроенную функцию DBMS_FLASH- BACK.GET_SYSTEM_CHANGE_NUMBER, поэтому необходимо явно выдать привилегию EXECUTE на соответствующий пакет. От имени пользователя SYS выполняем:
Ключевые моменты кода поясняются в таблице.
Строки
|
Описание
|
3-5
|
Обратите внимание на входные параметры. В модуле обработки необходимо использовать именно приведенные здесь параметры, а не какие-то другие, и именно в указанном порядке: владелец таблицы, имя таблицы и имя политики FGA. Конечно, имена параметров могут быть любыми, но их позиция определяет их назначение.
|
Строки
|
Описание
|
22-34
|
Эти строки содержат разнообразную информацию о действиях и сеансах пользователя. Их может быть больше, - они могут использовать всю информацию, предоставляемую контекстом USERENV.
|
34
|
Возвращенный функцией текущий системный номер изменения SCN записывается в журнал аудита.
|
35
|
Собранные значения вставляются в созданную ранее таблицу
FLAGGED_ACCESS.
|
Из-за ошибки Oracle вызов функции SYS_CONTEXT( 'USERENV', 'SES- SIONID ) всегда возвращает 0 внутри обработчика FGA. Эта ошибка была исправлена в версии Oracle 10* Release 2. На момент создания книги не существовало патча, исправляющего эту ошибку для предшествующих версий, поэтому строка 2 всегда будет иметь значение 0 (пока не выйдет и не будет установлен соответствующий патч).
Наконец, добавляем процедуру в политику FGA, чтобы она вызывалась автоматически при выполнении условий аудита:
Теперь при выполнении условий аудита запись вносится в таблицу FGA_LOG$, а также в таблицу FLAGGED_ACCESS. Другими словами, пользовательский обработчик аудита не отменяет ведение обычного журнала аудита. Причина проста: модуль обработки служит не только для создания пользовательского журнала аудита, он также используется для автоматического вызова хранимой процедуры, которая может выполнять разнообразные действия: отправлять электронные сообщения, выдавать предупреждения, обновлять какой-то флаг и т. д. Поэтому системные журналы аудита необходимо поддерживать в любом случае.
Если необходимо обеспечить еще более надежную защиту хранимой информации, можно создать идентичную таблицу в удаленной базе данных и использовать одностороннее создание моментальных копий в режиме «только для чтения». Для любой записи, вставленной в таблицу FLAGGED_ACCESS локальной базы данных, создается идентичная строка в удаленной таблице. Но и здесь возможны злоупотребления со стороны администратора базы данных, который может удалить журнал моментальной копии. Однако в базах данных с относительно невысокой активностью можно задать короткий период обновления, чтобы значения передавались сразу после их появления в исходной базе данных и у администратора было очень мало времени для удаления записей. К сожалению, такое решение является единственно доступным, так как внутри модуля обработки распределенные транзакции не поддерживаются, поэтому невозможно выполнить вставку напрямую в удаленную таблицу.
Даже если записи удалены, можно получить значения из архивных файлов журнала при помощи Oracle Log Miner. Так защищают журналы FGA в высоконадежных системах.
Можно использовать модуль обработки не только для создания пользовательского журнала аудита, но и для выполнения других операций (например, для отправки электронного сообщения ревизору при обращении к особо секретным данным вне рабочего времени).
| < Предыдущая | Следующая > |
|---|
