Решение специфических задач аудита базы данных Текст научной статьи по специальности «Компьютерные и информационные науки»

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

Г.Ю. Громов, Д.А. Дорохин, В.С. Черемухин

Рассматриваются новые средства СУБД Oracle и предлагается их использование для расширения стандартных возможностей, связанных с механизмом сбора данных по функционированию информационной системы, обработкой исключительных ситуаций и повышению производительности системы.

Вопросы, связанные с аудитом базы данных, в СУБД Oracle решены давно и вполне успешно. В СУБД Oracle существует стандартный, довольно громоздкий, но при этом обладающий большими возможностями механизм сбора информации аудита базы данных. На любом уровне детализации можно отследить события, происходящие в базе данных, вплоть до конкретных запросов, выполняемых определенным пользователем. Однако использование средств аудита, помимо естественно возникающих накладных расходов, связанных с дополнительной загрузкой базы данных, вызывает и ряд административных сложностей. Обязательно должна быть тщательным образом разработана и отлажена стратегия аудита базы данных, которая должна предусматривать своевременную очистку системной таблицы SYS.AUDS, размещенную в табличном пространстве SYSTEM. Если не уделить этому вопросу должного внимания, постоянное изменение размера системной таблицы SYS.AUDS может привести к фрагментации табличного пространства SYSTEM, что просто недопустимо, так как избавиться от него можно только пересозданием базы данных. Наилучшим решением этой проблемы было бы перемещение системной таблицы SYS.AUDS в другое табличное пространство, однако 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

( 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-l|TO_CHAR(ora_server_errorQX'00000'));

END;

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

Литература

1. Васильев В.Н. Принципы создания интегрированной информационно-аналитической системы управления вузом // Тезисы докладов Международной конференции "Интернет, Общество, Личность - ИОЛ-2000" Институт "Открытое общество", Санкт-Петербург, 2000.

2. Кириллов В.В., Громов Г.Ю. Применение CASE-технологии при создании интегрированной информационной системы университета // Тез. докл. Юбилейной научно-технической конференции профессорско-преподавательского состава, посвященной 100-летию университета, 29-31 марта 2000 года, Санкт-Петербург, 2000.

3. Кириллов В.В., Громов Г.Ю., Штивельман Я.Е. Первый опыт проектирования несколькими вузами подсистемы "Учебный процесс" // Тезисы докладов Международной конференции "Интернет, Общество, Личность - ИОЛ-2000" Институт "Открытое общество", Санкт-Петербург, 2000.

4. Кириллов В.В., Громов Г.Ю., Черемухин В.С., Вотинцев А.А., Романенко В.А, Работа с одним репозиторием Oracle Designer территориально распределенных разработчиков // Тезисы докладов Международной научно-методической конференции "Телематика'2000", Санкт-Петербург, 2000.