Научная статья на тему 'Решение специфических задач аудита базы данных'

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

CC BY
125
53
i Надоели баннеры? Вы всегда можете отключить рекламу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Громов Геннадий Юрьевич, Дорохин Денис Алексеевич, Черемухин Виктор Станисоавович

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

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

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

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

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

Рассматриваются новые средства СУБД 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.

i Надоели баннеры? Вы всегда можете отключить рекламу.