РЕШЕНИЕ СПЕЦИФИЧЕСКИХ ЗАДАЧ АУДИТА БАЗЫ ДАННЫХ

РЕШЕНИЕ СПЕЦИФИЧЕСКИХ ЗАДАЧ АУДИТА БАЗЫ ДАННЫХ
Г.Ю. Громов, Д.А. Дорохин, В.С. Черемухин
Рассматриваются новые средства СУБД Oracle и предлагается их использование для расширения
стандартных возможностей, связанных с механизмом сбора данных по функционированию
информационной системы, обработкой исключительных ситуаций и повышению производительности
системы.
Вопросы, связанные с аудитом базы данных, в СУБД Oracle решены давно и
вполне успешно. В СУБД Oracle существует стандартный, довольно громоздкий, но
при этом обладающий большими возможностями механизм сбора информации аудита
базы данных. На любом уровне детализации можно отследить события, происходящие
в базе данных, вплоть до конкретных запросов, выполняемых определенным
пользователем. Однако использование средств аудита, помимо естественно
возникающих накладных расходов, связанных с дополнительной загрузкой базы
данных, вызывает и ряд административных сложностей. Обязательно должна быть
тщательным образом разработана и отлажена стратегия аудита базы данных, которая
должна предусматривать своевременную очистку системной таблицы SYS.AUD$,
размещенную в табличном пространстве SYSTEM. Если не уделить этому вопросу
должного внимания, постоянное изменение размера системной таблицы SYS.AUD$
может привести к фрагментации табличного пространства SYSTEM, что просто
недопустимо, так как избавиться от него можно только пересозданием базы данных.
Наилучшим решением этой проблемы было бы перемещение системной таблицы
SYS.AUD$ в другое табличное пространство, однако Oracle официально заявляет о
непредсказуемых последствиях данного шага.
К тому же, несмотря на все возможности по сбору информации аудита,
предоставляемые стандартными средствами Oracle, возникают специфические задачи,
решение которых с использованием стандартных средств невозможно.
Однако в Oracle, начиная с версии 8i, появилось средство, которое и должно
помочь администраторам и разработчикам решить большинство проблем,
возникающих при сборе специфической информации аудита. Это средство называется
"триггера событий".
В отличии от "классических" триггеров базы данных, срабатывающих в случае
выполнения операций INSERT, UPDATE, DELETE, триггера событий срабатывают при
возникновении как-либо системных событий, среди которых SERVERERROR, AFTER
LOGON, BEFORE LOGOFF, AFTER/ BEFORE ALTER/CREATE/DROP, AFTER/
BEFORE GRANT/REVOKE и так далее. По сути, данный тип триггеров позволяет,
помимо сбора информации аудита, выполнять набор необходимых действий, связанных
с тем или иным системным событием. Триггера событий могут создаваться на двух
уровнях – на уровне базы данных и на уровне конкретной схемы. Также только в
триггерах событий доступен набор атрибутов этих событий, например, стек ошибок
(ora_server_error) для события SERVERERROR или ip-адрес компьютера пользователя
(ora_client_ip_address) для события AFTER LOGON.
В качестве простейшего примера можно привести два триггера, выполняющих
сбор информации аудита в созданную администратором базы данных таблицу. Таблица
создается не в табличном пространстве SYSTEM, и помимо информации, которую
можно собрать стандартными средствами (время начала и окончания работы с базой
данных), в нее заносится информация о том, какая программа используется
пользователем для работы, и ip-адрес компьютера, с которого он работает.
DROP TABLE adm_connections;
CREATE TABLE adm_connections
102
( s_id NUMBER ,
user_name
VARCHAR2(30),
host_ip
VARCHAR2(200),
progr
VARCHAR2(200),
begin_date
DATE DEFAULT sysdate,
end_date
DATE)
TABLESPACE tools;
CREATE OR REPLACE TRIGGER OnLogon AFTER LOGON ON DATABASE
DECLARE
-- описываем служебную переменную
pr VARCHAR2(64);
BEGIN
BEGIN
-- выбираем из представления v$session информацию о программе пользователя
SELECT program INTO pr FROM sys.v_$session t where audsid =
sys_context('USERENV','SESSIONID');
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
END;
-- вставляем всю необходимую информацию в нашу таблицу
INSERT INTO adm_connections(s_id,user_name,host_ip,progr)
VALUES (sys_context('USERENV','SESSIONID'), ora_login_user,
ora_client_ip_address, pr);
END;
CREATE OR REPLACE TRIGGER OnLogoff BEFORE LOGOFF ON DATABASE
BEGIN
-- обновляем нашу таблицу сведениями об окончании работы с базой данных
данного пользователя
UPDATE adm_connections SET end_date = sysdate WHERE s_id =
sys_context('USERENV','SESSIONID');
END;
Триггера событий также очень полезны и разработчикам. При использовании
многоуровневых архитектур не так просто организовать детальный сбор информации о
возникающих при работе приложения ошибок. Здесь также неоценимую помощь
оказывают триггера событий. Вместо того, чтобы включать программный код каждой
процедуры/функции/пакета в обработчик исключений команды по сохранению
возникшей ошибки, достаточно написать триггер на событие SERVERERROR на
уровне схемы или базы данных. С его помощью возможно, например, сохранять все
ошибки возникающие при работе приложения на уровне базы данных.
CREATE OR REPLACE TRIGGER OnError AFTER SERVERERROR ON
DATABASE
BEGIN
INSERT INTO adm_errors(user_name,host_ip, error_nom)
VALUES (ora_login_user, SYS_CONTEXT('USERENV','IP_ADDRESS'),
SYS_CONTEXT('USERENV','CLIENT_INFO'), 'ORA'||TO_CHAR(ora_server_error(1),'00000'));
END;
103
Рассмотренные примеры использования триггеров событий лишь частично
иллюстрируют их возможности. Использование их в полном объеме позволяет
администраторам и разработчикам находить простые и гибкие решения практически
любых специфических задач, связанных с аудитом базы данных.
Литература
1. Васильев В.Н. Принципы создания интегрированной информационноаналитической системы управления вузом // Тезисы докладов Международной
конференции "Интернет, Общество, Личность - ИОЛ-2000" Институт "Открытое
общество", Санкт-Петербург, 2000.
2. Кириллов В.В., Громов Г.Ю. Применение CASE-технологии при создании
интегрированной информационной системы университета // Тез. докл. Юбилейной
научно-технической конференции профессорско-преподавательского состава,
посвященной 100-летию университета, 29-31 марта 2000 года, Санкт-Петербург,
2000.
3. Кириллов В.В., Громов Г.Ю., Штивельман Я.Е. Первый опыт проектирования
несколькими вузами подсистемы "Учебный процесс" // Тезисы докладов
Международной конференции "Интернет, Общество, Личность - ИОЛ-2000"
Институт "Открытое общество", Санкт-Петербург, 2000.
4. Кириллов В.В., Громов Г.Ю., Черемухин В.С., Вотинцев А.А., Романенко В.А,
Работа с одним репозиторием Oracle Designer территориально распределенных
разработчиков // Тезисы докладов Международной научно-методической
конференции "Телематика'2000", Санкт-Петербург, 2000.
104