CC BY
54
МЕТОДЫ И СРЕДСТВА ЗАЩИТЫ ИНФОРМАЦИИ
АУДИТ ИЗМЕНЕНИЙ В СУБД «РЕД БАЗА ДАННЫХ»
© GHMÄKOß Роман Александрович
© GTÄPOÄVEOß Дмитрий Николаевич
пгп н'тгнт кафедры «Ин-кандидат технических формационные систе-наук, директор по произ- мы» Муромского ин-водству ООО «Ред Софт ститута Владимирского Муром» государственного уни-
верситета
+7(920)900-65-02 ] [email protected]
+7(920)624-13-92 1 [email protected]
Статья рассматривает вопросы аудита событий, происходящих в СУБД «Ред База Данных». Приводятся практические примеры использования разработанных инструментов. Статья показывает место СУБД в построении информационной системы, удовлетворяющей заданному классу безопасности. Ключевые слова: база данных, защита информации, аудит, СУБД,.
ВС
в
(опрос защиты информации в современных компьютерных системах стоит достаточно остро. В особенности это касается баз данных, в которых, собственно, и хранится в большинстве случаев основной объем данных информационной системы. Различные системы управления базами данных (СУБД) предлагают схожий набор механизмов по обеспечению защиты хранимых данных - авторизованный доступ пользователей по имени / паролю, передача паролей по сети в зашифрованном виде, назначение пользователям ролей для доступа к данным.
Еще одной составляющей механизма безопасности как в СУБД, так и в компьютерных системах вообще, является ведение журнала доступа к контролируемым данным и объектам, т.е. аудит событий. Аудит обычно является частью системы обнаружения вторжений (IDS, Intrusion detection system) Современные СУБД, такие как Oracle, Microsoft SQL Server, PostgreSQL предлагают средства регистрации пользовательской активности: присоединение к базе данных и отключение от нее, выполнение запросов по выборке и изменению данных и метаданных и т.д.
В свободно распространяемой СУБД Firebird (основанной на коде Borland Interbase) регистрация событий, к сожалению, практически не развита. В лог-файл Firebird - fire-
bird.log - записываются только сообщения об ошибках, произошедших на сервере, в результате чего анализ инцидентов безопасности существенно затруднен.
В качестве решения подобной проблемы предлагается сохранять информацию о запросах в самой БД с использованием триггеров, срабатывающих на изменение данных. Для этого в отслеживаемую базу данных добавляются одна или несколько таблиц, в которых будет храниться информация о событиях. Затем создается несколько триггеров, которые будут срабатывать на изменение данных и записывать информацию об этих изменениях в таблицы лога. Такой подход обладает следующими преимуществами и недостатками (табл. 1).
Как видно из приведенной таблицы, недостатки хранения сведений аудита внутри БД перевешивают преимущества такого подхода. Поэтому сотрудниками компании «Ред Софт» в рамках развития отечественной промышленной СУБД «Ред База Данных», исходный код которой основан на ярде Firebird, было разработано дополнение, добавляющее функционал регистрации событий безопасности - FBTrace1.
1 Изначальный исходный код дополнения написан Николаем Самофатовым.
Таблица 1
Преимущества
+ Использование стандартных инструментов работы с БД, входящих в стандарт SQL и предоставляемых любым сервером баз данных (нет необходимости в модификации кода Firebird) + Хранение сведений о событиях в базе данных позволяет при их анализе использовать возможности языка SQL -фильтрацию, поиск, и сортировку
Недостатки
- Триггеры позволяют регистрировать очень ограниченный спектр событий - вставка, изменение, удаление записей (в Firebird 2.1 добавились триггеры на подключение к БД / отключение от нее и запуск / завершение транзакции)
- Если кто-то получит доступ к базе данных, то он может получить доступ и к таблицам журналов
- Повреждение или удаление БД ведет к потере информации из журнала
- При подробной регистрации событий размер БД существенно увеличивается
Возможность разработки дополнений, расширяющих функциональность СУБД Firebird, реализуется с использованием механизма плагинов. Общая схема работы с пользовательским плагином показана на рис. 1.
При подключении к любой базе данных Firebird запускает менеджер плагинов, который ищет доступные дополнения и подключает их. После этого плагин инициализируется - ядро СУБД подключает библиотеку функций, в которой находится реализация плагина.
После этого обмен между ядром и функциями дополнения идет через интерфейс дополнения - в данном случае - менеджер РВТгасе. Ему передаются уведомления о происходящих в сервере событиях, которые он перенаправляет в сам плагин, где и происходит непосредственная регистрация события.
Разработанное расширение - РВТгасе - позволяет вести запись в журнал событий (лог) для каждой базы данных на сервере, начиная с момента ее создания или присоединения к ней, и до момента отсоединения от нее
Рис. 1. Работа СУБД Firebird с подключаемым расширением
или ее удаления. По умолчанию лог-файлы размещаются в том же каталоге, что и отслеживаемая база данных.
Ведется регистрация событий следующих типов:
- начало и окончание ведения аудита для БД;
- присоединение к БД и отсоединение от
нее;
- присоединение к сервису и отсоединение от него;
- старт сервиса и запрос к нему;
- проверка предъявленного фактора аутентификации (пароль, сертификат);
- подготовка, выполнение и освобождение SQL-запроса к БД, а также выборка записей;
- компиляция и выполнение BLR- и DYN-запросов (откомпилированные SQL-запросы во внутреннем представлении сервера);
- выполнение хранимой процедуры;
- установка значения контекстной переменной;
- начало и завершение транзакции.
Для каждого события, кроме предъявления фактора аутентификации, в журнал аудита сохраняется следующая информация:
- дата, время и тип события;
- идентификатор процесса, вызвавшего событие;
- результат (успешно, неуспешно, несанкционированно);
- сведения о соединении: путь к БД, идентификатор соединения, пользователь, от имени которого совершается действие, протокол соединения, имя компьютера, с которого установлено соединение.
Кроме того, для каждого события в журнале сохраняется специфичная для данного типа события информация (табл. 2).
Подобный набор регистрируемой информации позволяет подробно отслеживать активность пользователей на сервере баз данных.
Кроме параметров каждого события в журнал также сохраняется результат, с которым это событие было завершено. Существует три возможных способа завершения: успешно, неуспешно и несанкционировано.
Несанкционированным считается любое действие, при котором не была пройдена аутентификация или на которое у пользователя не было соответствующих прав (например, попытка изменения структуры таблицы без прав на это).
Неуспешным считается любое другое действие, которое не было выполнено в результате какой-либо ошибки (например, не-
соответствие типов при добавлении данных в таблицу или попытка чтения данных из несуществующей таблицы).
Используя информацию о способе завершения регистрируемых событий, можно быстро обнаружить попытки выполнения нехарактерных для пользователей действий. При этом необязателен просмотр всей информации в журнале, размер которого может быть очень значителен в зависимости от набора регистрируемых событий и активности работы с базой данных.
Плагин FBTrace реализуется в виде разделяемой библиотеки функций, которая доступна как в Windows- (fbtrace.dll), так и в Unix-системах (fbtrace.so). Для настройки работы системы аудита используется конфигурационный файл (fbtrace.conf). Настраивать можно следующие параметры:
enable = 0/1 - включение аудита: 0 -аудит не ведется (по умолчанию), 1 - ведется.
format = 0/1 - формат лог-файла: 0 -текстовый (по умолчанию), 1 - бинарный.
time_threshold = <число> - минимальный предел времени, при котором регистрируются события выполнения запросов. Если запрос выполняется меньше указанного здесь значения, то запись об операции не помещается в лог. Значение по умолчанию - 100 мс.
max_sql_length = <число> - максимальная длина текста SQL-запроса в лог-файле, в байтах. Значение по умолчанию - 300 байт.
max_blr_length = <число> - максимальная длина BLR-запроса, сохраняемого в лог, в байтах. Значение по умолчанию - 500 байт.
max_dyn_length = <число> - максимальная длина DYN-запроса, сохраняемого в лог, в байтах. Значение по умолчанию - 500 байт.
max_arg_length = <число> - максимальная длина одного параметра запроса / процедуры в лог-файле. Значение по умолчанию - 80 байт.
Для четырех вышеописанных параметров максимальная длина записи в лог-файле составляет 64Кб. Если длина записи будет больше указанного в параметре значения, то запись будет обрезана.
max_arg_count = <число> - максимальное количество параметров запроса / процедуры, которое заносится в лог-файл. Значение по умолчанию - 30. Параметры, номера которых больше указанного здесь значения, отображаться не будут.
Таблица 2
Сведения, регистрируемые для разных типов событий
„ Информация, сохраняемая в журнал
Тип события
присоединение к БД это подключение к существующей БД или создается новая база данных?
фактор аутентификации тип фактора; сам предъявленный фактор
присоединение к сервису отсоединение от сервиса имя сервиса
старт сервиса имя сервиса; параметры, переданные при старте
запрос к сервису имя сервиса; содержимое запроса
установка значения контекстной переменной сведения о транзакции; пространство имен (namespace), для которого устанавливается переменная; имя переменной; устанавливаемое значение
выполнение хранимой процедуры сведения о транзакции; имя процедуры; входные параметры; время выполнения; статистика производительности
старт и завершение транзакции идентификатор транзакции; параметры транзакции (уровень изоляции, режим блокировки); способ завершения транзакции - подтверждение (commit) или откат (rollback)
подготовка SQL-запроса сведения о транзакции; идентификатор запроса; текст запроса; время подготовки запроса (в мс); план выполнения
выполнение SQL- или BLR-запроса сведения о транзакции; идентификатор запроса; время выполнения запроса (в мс); статистика производительности; параметры запроса; текст запроса
выполнение DYN-запроса сведения о транзакции; содержимое запроса (в текстовом виде для текстового лога, в бинарном - для бинарного); время выполнения запроса (в мс)
компиляция BLR-запроса сведения о транзакции; идентификатор запроса; текст запроса (в текстовом виде для текстового лога, в бинарном - для бинарного); время подготовки запроса (в мс)
max_log_size = <число> - задает максимальный размер ^-файлов в мегабайтах. Если значение параметра не задано или равно о, то размер файла журнала не ограничен. Значение по умолчанию - о. Если задано значение, отличное от нуля, то при достижении лог-файла данного размера он будет переименован.
include_filter = <регулярное выражение> - этот параметр определяет те виды БОЬ-запросов, которые будут включаться в лог-файл. По умолчанию - не чувствителен к регистру. Под фильтр подпадают только те значения, которые удовлетворяют синтаксису регулярных выражений (в соответствии с РОБК 1003.2). Значение по умолчанию - пусто, то есть в лог будут включены все запросы.
exclude_filter = <регулярное выражение> - определяет виды SQL-запросов, которые не включаются в лог-файл. Аналогично include_filter. Значение по умолчанию - пусто.
log_auth_factors = 0/1 - определяет, записывать ли события проверки предъявленных факторов аутентификации.
log_connections = 0/1 - определяет, записывать ли события присоединения к БД / отсоединения от нее.
log_transactions = 0/1 - определяет, записывать ли события начала и завершения транзакций.
log_statements = 0/1 - определяет, записывать ли события подготовки и освобождения SQL-запросов к БД.
log_context = 0/1 - определяет, записывать ли события изменений значений контекстных переменных.
log_execute = 0/1 - определяет, записывать ли события выполнения запросов / выборки записей.
log_procedures = 0/1 - определяет, записывать ли события выполнения хранимых процедур.
log_blr_requests = 0/1 - определяет, записывать ли события непосредственного выполнения BLR-запросов.
log_dyn_requests = 0/1 - определяет, записывать ли события прямого выполнения DYN-запросов.
log_services = 0/1 - определяет, записывать ли события вызовов сервисов.
Для всех перечисленных параметров 1 означает включение, а 0 - отключение данной возможности. По умолчанию регистрация всех событий аудита отключена.
log_filename = <строка> - имя лог-файла. Если этот параметр не задан, лог-файл создаётся в той же папке, где находится БД и будет иметь имя вида <имя_базы.:РЬ1:гасе_:ех^ или <имя_базы.:РЬ1:гасе_Ьт> в зависимости от формата лога.
Для каждой базы данных может быть задан свой набор настроек с помощью определения в файле конфигурации секций вида: logged_database.fdb: r.*[\/](test|tst)\.fdb$]: В первом случае прямо указывается имя базы данных, для которой будут действовать параметры конфигурации. Во втором случае для указания базы данных используется регулярное выражение, под которое подпадут базы test.fdb и tst.fdb, находящиеся в любом каталоге.
В следующем примере конфигурации задаются две секции аудита. test.fdb:
enabled = 1 format = 0 log_connections = 1 log_statements = 1
[A.*\\(empbuild|employee|emp)\.fdb$]: enabled = 1 format = 1
log_filename = d:\log\employee.log Первая секция отвечает за регистрацию событий для баз test.fdb: формат журнала - текстовый, регистрируются соединения и подготовка/освобождение запросов, лог-файл - test.fdb.fbtrace_text в каталоге базы. Вторая секция задает аудит баз данных вида empbuild. fdb, employee.fdb, emp.fdb: формат журнала -бинарный, события от всех баз данных будут сохраняться в файл d:\log\employee.log. Другие базы данных отслеживаться не будут.
Таким образом, можно настроить типы регистрируемых событий, объем информации, попадающей в лог-файл и отслеживаемые базы данных. Применение регулярных выражений для фильтрации SQL-запросов позволяет записывать в лог-файл только интересующие запросы, облегчая анализ получаемого журнала.
Разработанное дополнение позволяет создавать файлы журналов в текстовом либо бинарном виде (контролируется параметром конфигурации format). В первом случае создается текстовый файл, содержащий форматированный текст записей вида: 2008-09-24T23:25:00.4530 (3116:00DBCFAC) TRACE_INIT
D:\TEMP\TEST.FDB
2008-09-24T23:25:00.6560 (3116:00DBCFAC) CREATE_DATABASE
D:\TEMP\TEST.FDB (ATT_1, sysdba, XNET:HOME)
2008-09-24T23:25:49.0460 (3116:00DBCFAC) PREPARE_STATEMENT
D:\TEMP\TEST.FDB (ATT_1, sysdba, XNET:HOME)
(TRA_5, READ_COMMITTED | NO_REC_VERSION | WAIT) Statement 013FDEF8:
create table tabi(ti int, t2 float)
ЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛ
0 ms
2008-09-24T23:26:03.5i50 (3116:00DBCFAC) FREE_STATEMENT
D:\TEMP\TEST.FDB (ATT_1, sysdba, XNET:HOME)
Statement 013FDEF8:
create table tabi(ti int, t2 float)
ЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛЛ
2008-09-24723:26:03.5150 (3116:00DBCFAC) DETACH_DATABASE
D:\TEMP\TEST.FDB (ATT_1, sysdba, XNET:HOME)
2008-09-24T23:26:03.5150 (3116:00DBCFAC) TRACE_FINI
D:\TEMP\TEST.FDB
Для анализа такого файла не нужно дополнительных программных средств - можно воспользоваться любым текстовым редактором. Но большое количество записей, избыточность информации и плохие возможности для поиска и фильтрации делают данный формат не совсем удобным в случае большого количества регистрируемых событий при активной работе с БД.
Поэтому был разработан бинарный формат хранения журнала аудита, при котором в лог-файл записываются все события, происходящие в базе данных в виде пакетов двоичных данных. При этом избыточность отсутствует, так как в лог-файл не заносится дублирующая информация. Например, в вышеприведенном отрывке текстового журнала для события освобождения запроса (FREE_ STATEMENT) для удобства чтения сохраняется информация о базе данных, параметрах соединения и о содержимом запроса, хотя
достаточно было бы хранения идентификатора запроса. В бинарном журнале подобные дублирующие данные не хранятся, поскольку он не предназначен для непосредственного просмотра.
Для анализа двоичных журналов аудита используется возможность подключения к БД Firebird внешнего файла, имеющего определенную структуру, в виде особой таблицы. Данный инструмент имеет ряд достаточно серьезных ограничений, например, не поддерживаются записи, в которых может быть различное количество полей или поля в которых имеют переменную длину. Кроме того, в такой таблице поддерживаются далеко не все типы данных Firebird.
Поэтому были внесены изменения в код Firebird, который отвечает за работу с внешними таблицами. Вводится понятие адаптера - программного механизма, который отвечает за анализ и разбор внешних файлов, передавая ядру СУБД данные в приемлемом для дальнейшей работы виде. С использованием этой концепции был создан адаптер для бинарных журналов FBTrace, который позволяет подключать их к базе данных Firebird в виде внешней таблицы.
В результате становится возможным использование стандартных инструментов SQL по фильтрации и поиску данных для анализа журнала аудита. Поскольку лог-файл подклю-
Таблица : [LOG] : log (C:\Program Files\Red Soft Corporation\Red Database\bin\EMP.FDB) ^■ЗЕШШ
Таблица т - X т Щ. Q О* ab Количество записей LOG ■.
External File
С: ^PROGRAM FILESIRED SOFT CORPORATIONIRED DATABASEIBINIEMPBUILD.FDB.FBTRACE BIN
Поля Зависимости
T- ъ
^ Запись №: |l6
Данные I Master/Detail View Описание Скрипт
Э
Права Comparison To-do «H + - ^ К С*
Б15 records fetched
EVENT TYPE
EVENT_TIME STMTJD 5TMT_SQL
TRANSJD TRANS_OPT
START TRANSACTION START TRANSACTION COMMIT TRANSACTION PREPARE STATEMENT PREPARE STATEMENT FREE STATEMENT COMMIT TRANSACTION
25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30
ДSTART TRANSACTION |25.09.2008 00:30
PREPARE STATEMENT FREE STATEMENT PREPARE STATEMENT FREE STATEMENT COMMIT TRANSACTION START TRANSACTION PREPARE STATEMENT FREE STATEMENT
25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30 25,09.2008 00:30
<null> <null>
<null> <null>
<null> <null>
0140DEF8 CREATE DOMAIN firstname
013FDEF8 CREATE DOMAIN firstname
013FDEF8 <null> <null>
<null> <null>
ВИН
013FDEF8 CREATE DOMAIN lastname
0140DEF8 <null> <null>
0140DEF8 CREATE DOMAIN lastname
0140DEF8 <null> <null>
<null> <null>
<null> <null>
0140DEF8 CREATE DOMAIN
013FDEF8 <null> <null>
3 READJIOMMITTED | NO_REC_VER5ION | 1
4 <null> 4 <null> 3 <null> 3 <null>
<null> 3 <null>
5 READJIOMMITTED | NO_REC_VERSION | WAIT
5 <null> <null> 5 <null> <null>
5 <null>
6 READ_COMMITTED | NO_REC_VERSION | WAIT 6 <null>
<null>
<
ЛИ
A
2, Форма
3, Печать
Рис. 2. Подключенный к базе данных журнал аудита
чен в виде внешней таблицы, он не увеличивает размер файла базы данных. Изменить записи в журнале также нельзя, так как внешняя таблица создается только для чтения. Таким образом, возможность повреждения бинарного журнала с помощью SQL-запросов исключена.
На рис. 2 приведен пример двоичного журнала, подключенного к базе данных в виде внешней таблицы (таблица открыта в приложении IB Expert).
Описанная система аудита полностью реализована в СУБД «Ред База Данных», которая в настоящее время проходит испытания для получения сертификата системы, соответствующей пятому классу защищенности от несанкционированного доступа, согласно утвержденной классификации ФСТЭК (http:// www.fstec.ru/_razd/_ispo.htm). Кроме того, рассматривается вопрос внедрения изменений, связанных с подсистемой регистрации событий, в открытый исходный код СУБД Firebird.
^//////////////////ш^
Г
КНИЖНАЯ ПОЛКА
1
^ Информационное обеспечение правоохранительной деятельности: проблемы, тен-
| денции, перспективы. Сборник научных статей. - Калининград: Калининградский ЮИ МВД | России, 2007. - 244 с.
ISBN 5-93919-031-6
В сборнике научных статей, посвященном памяти выдающегося криминалиста современности, Заслуженного деятеля науки Российской Федерации, доктора юридических наук, профессора Р.С. Белкина, исследуются современные проблемы, тенденции и перспективы развития информационного обеспечения правоохранительной деятельности в России и зарубежных странах.
В работах нашли отражение взгляды представителей науки и практических работников на проблему информационного обеспечения деятельности сотрудников органов предварительного следствия, оперативных подразделений и других служб государственных органов, занимающихся проблемами противодействия преступности.
Сборник научных статей будет весьма интересен и полезен научным работникам, преподавателям, аспирантам и адъюнктам образовательных учреждений системы Министерства внутрен-
^ них дел Российской Федерации, других правоохранительных структур, юридических вузов и факультетов, практическим работникам правоохранительных органов.
/////////////////////^^^^
