Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 74

Общая последовательность настройки и проведения мониторинга следующая. Вначале системному администратору необходимо определиться с целями мониторинга и, в частности, ответить на вопрос, какие события связаны с угрозами безопасности. Отслеживать все происходящие в системе события нецелесообразно, т. к. это приводит к генерации ненужной информации и снижает производительность сервера. Затем, запустив соответствующую утилиту, администратор подключается к серверу под своей учетной записью, вводит и сохраняет настройки мониторинга (в том числе указывает классы отслеживаемых событий) и параметры журнализации. Журнализация может производиться в специальный файл журнала, в обычный текстовый файл, в таблицу системной БД. В процессе мониторинга генерируемые события отображаются на экране, что позволяет администратору наблюдать за происходящим в реальном масштабе времени, своевременно обнаруживать подозрительные действия пользователей и принимать адекватные меры противодействия.

8.4. Организация местного аудита в базах данных с использованием триггеров

Помимо мониторинга и протоколирования событий на уровне СУБД, существует возможность организации местного аудита на уровне отдельной БД. Такой аудит может потребоваться, если, к примеру, в БД имеется особо важная информация, и нужно детально отслеживать любые действия пользователей, направленные на ее изменение, вплоть до вставки, удаления и обновления отдельных записей. Также можно отслеживать события, связанные с выполнением DDL-операторов в БД.

Наиболее разумный способ организации местного аудита следующий. Вначале создаются две дополнительные таблицы, в одну из которых записываются данные по отслеживанию выполнения DDL-операций, в другую – аналогичные данные по выполнению DML-операций. Таблицы должны включать такие столбцы, как имя пользователя, дата и время выполнения действия, вид действия; для DML-операций – имя таблицы, строки которой были обработаны.

Для отслеживания действий пользователя используются DDL- и DML-триггеры.

Не следует создавать DDL-триггеры для всех команд DDL: это может сказаться на производительности системы и существенно увеличить количество записей в таблице аудита. Следует проводить аудит наиболее критичных операций. К примеру, если администратор БД решает, что команда DROP TABLE является критичной, и требуется ее аудит, ему нужно создать триггер типа DROP_TABLE. Триггер будет добавлять новую строку в таблицу аудита – запись о том, что некий пользователь удалил таблицу в указанное время. Оператор создания данного триггера будет выглядеть так:

create trigger trDropTable

            on database

            for drop_table

as

insert into ddl_audit values(session_user, getdate(),

EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]', 'nvarchar(max)'))

Здесь ddl_audit – имя таблицы DDL-аудита. Глобальная переменная session_user содержит имя текущего пользователя БД (т. е. пользователя, выполнившего команду). Функция getdate() возвращает текущую дату и время. На третьем месте стоит специальная конструкция, позволяющая получить полный текст запроса с именем удаленной таблицы. Для этого использована функция EVENTDATA(), работающая только внутри DDL-триггеров (вне триггеров она возвращает NULL). Ее результатом является структура, содержащая, в принципе, всю информацию, необходимую для аудита. Мы в приведенном примере воспользовались базовыми возможностями Transact-SQL для получения имени пользователя и текущего времени. Только для получения текста команды потребовалась функция EVENTDATA(). Ее детальное описание находится в MSDN Library.

Для DML-аудита также следует выбирать лишь те таблицы, в которых содержатся особо критичные данные. Если все данные одинаково критичны, то не стоит проводить местный DML-аудит: таблиц в БД может оказаться очень много, и для каждой придется создавать по три DML-триггера.

Пусть в БД имеется таблица documents. Требуется отслеживать выполнение над ней операторов INSERT, UPDATE и DELETE. Для решения этой задачи создадим три DML-триггера, по одному для каждой активизирующей операции.