Аудит по журналу транзакций

Большинство информационных систем строятся по схеме «клиент – сервер приложений – база данных», причем задача протоколирования выполняемых пользователями операций решается на уровне сервера приложений. Для этого, например, в прикладной системе может быть реализован служебный компонент для ведения журнала событий (операций), в котором регистрируются все значимые действия по просмотру и модификации информации. Преимущество такого подхода в том, что он позволяет регистрировать события в терминах предметной области, а не на уровне SQL-операций над таблицами базы данных. Казалось бы, подобный компонент, фиксирующий действия пользователей, решает все проблемы мониторинга операций и нет необходимости включения дополнительных средств на уровне СУБД, однако это не так. В крупных компаниях и организациях, имеющих большое количество взаимосвязанных систем, возникает острая необходимость контролировать критические изменения в данных не только по журналу событий, отражающих действия пользователя, но и на уровне операций, производимых в базе данных посредством SQL-команд или путем загрузки данных из разных источников.

Мониторинг на уровне СУБД

У любой прикладной системы обычно имеется администратор, сопровождающий ее с помощью SQL-интерфейса, и его действия, как правило, в журнале событий прикладной системы не отражаются. В результате на уровне приложения не остается никаких следов, позволяющих обнаружить возможные несанкционированные действия. Кроме этого, в самой прикладной системе могут быть уязвимости, позволяющие ее взломать, например, при помощи популярного среди хакеров метода SQL-инъекций, что может привести к непредсказуемым изменениям в базе, которые не будут зафиксированы в журнале событий. Наконец, часто возникает необходимость проведения прямых изменений в базе посредством SQL-команд, минуя интерфейс прикладной системы. Например, в задачу некоторых прикладных систем входит ежедневное выполнение расчетов определенных показателей (финансовых обязательств, биржевых котировок, и т. п.) на основе нормативных или оперативных данных, загружаемых из внешних источников. Бывают ситуации, когда перед расчетом выясняется, что поступившие в систему данные некорректны, а времени на их повторную загрузку уже нет, и в этом случае ошибки обычно исправляются вручную путем прямых изменений в базе. Очевидно, что такие действия необходимо контролировать, поскольку велика вероятность того, что исправление будет неверным. При этом важно отслеживать, что все изменения произведены до запуска расчета, а не в процессе его выполнения или окончания.

Все эти примеры свидетельствуют о том, что журнала событий прикладной системы недостаточно — необходим аудит изменений данных на уровне базы. Несмотря на инструментальную роль, отводимую базам данных в архитектуре современных информационных систем, в условиях, когда подавляющее большинство пользователей не употребляют SQL и вообще ничего не знают о схеме базы и структуре таблиц, с которыми они работают, применение средств мониторинга изменений на уровне базы оказывается полезным дополнительным инструментом для обеспечения безопасности и исключения ошибок при эксплуатации системы. Основным критерием для выбора механизма, обеспечивающего мониторинг, является минимальное влияние внедряемого решения на производительность системы.

Мониторинг с помощью триггеров

Наиболее известным способом мониторинга изменений является использование механизма триггеров, с помощью которых можно осуществлять перехват и протоколирование операций, производимых в базе, — модификацию данных (операции DML (Data Manipulation Language): insert, update, delete) и модификацию схемы (операции DDL (Data Definition Language): create table, alter table add column и т. п.). Этот метод также действует во встроенных механизмах аудита современных СУБД (например, при использовании команды AUDIT в Oracle), где система в автоматическом режиме создает и актуализирует набор триггеров, соответствующий текущим правилам контроля объектов базы, типов операций и т. п.

Основным недостатком применения триггеров и встроенного аудита для мониторинга изменений является падение производительности системы, поскольку в этом случае каждая операция в транзакции дополнительно сопровождается добавлением записи в таблицу аудита. Реально использовать встроенный аудит СУБД возможно только в том случае, когда удается заранее установить селективные условия аудита (например, настроить фильтр на протоколирование данных из небольшого подмножества таблиц базы, чтобы обеспечить обозримый объем выборки записей для анализа). Если же подключить к аудиту все операции над базой или их большую часть, то это сильно повлияет на производительность прикладной системы, и выполнять подобные операции на «боевой» системе, находящейся под постоянной или временами пиковой нагрузкой, обычно неприемлемо.

Мониторинг по журналу транзакций

С учетом названных ограничений получил развитие альтернативный подход к реализации мониторинга изменений, основанный на возможности извлечения и последующей обработки информации об операциях DML и DDL, имеющейся в журнале транзакций базы. Для основных СУБД (Oracle, Microsoft SQL Server и IBM DB2) созданы промышленные системы аудита, предлагаемые в виде отдельных продуктов: Oracle Audit Vault, Apex SQL Log и IBM Audit Management Expert. Эти системы обладают возможностями захвата изменений из журналов транзакций и позволяют аудитору удаленно подключаться к журналам транзакций целевых баз (включая архивы журналов), задавать разнообразные фильтры на выборку интересующих его записей, получать удобные для анализа отчеты в различных форматах и пр. Общим недостатком этих систем, несмотря на различия в их архитектуре, является то, что захват изменений осуществляется непосредственно на целевой базе — этот процесс достаточно «тяжелый», поскольку связан с парсингом и трансформацией данных. По сравнению с подключением встроенного аудита СУБД способ захвата нагружает систему не так значительно, однако это не всегда можно делать на исходной базе, особенно когда прикладная система активно выполняет свою целевую функцию.

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

Архитектура сервера контроля изменений

Перспективным можно считать вариант, когда серверы с базами данных информационной системы полностью избавляются от «непрофильной» работы, а выполнение задач по захвату, обработке и сохранению информации об изменениях осуществляется на специально выделенном сервере. На рис. 1 приведена предлагаемая архитектура системы такого класса.

Рис. 1. Архитектура сервера контроля изменений

Центральным звеном архитектуры является сервер контроля изменений (СКИ), на котором выполняется процесс захвата и обработки записей из архивных журналов, поступающих с серверов, содержащих исходные базы. Предполагается, что любая СУБД поддерживает механизм архивирования журналов транзакций, применяемый для решения задач резервного копирования и восстановления данных. Именно эти архивные журналы передаются на СКИ и обрабатываются, формируя структурированное представление о прочитанном из журнала изменении, которое в виде отдельной записи (или группы записей) может быть сохранено в базе СКИ.

СКИ может обслуживать несколько исходных баз, для каждой из которых порождается свой процесс захвата и обработки изменений. Основная особенность предложенной архитектуры заключается в том, что сами исходные базы на сервер СКИ не перемещаются, а метаданные о структуре базы, составляющие содержимое словаря данных (место размещения названий таблиц, полей и т. п.), могут быть получены из архивного журнала или каким-то иным способом переданы на СКИ. Не имея этих метаданных (а они являются неотъемлемой частью любой базы данных и используются при чтении файлов журнала), анализировать записи журналов невозможно — они закодированы, и, например, вместо имен полей используются их номера.

К числу дополнительных преимуществ, вытекающих из данной архитектуры, относятся: экономическая целесообразность (для реализации подобной системы достаточно одного сервера); возможность получения интегральной информации (например, в виде отчетов) об изменениях, произведенных в нескольких источниках; организация централизованного долговременного хранения файлов архивных журналов и т. п.

СКИ для СУБД Oracle

На сегодняшний день Oracle, пожалуй, одна из немногих компаний, обеспечивающих разработчиков набором штатных инструментальных средств для решения задач мониторинга. Алгоритмы консолидации изменений, происходящих и транслируемых из исходных баз данных, основываются на механизме Oracle Streams версии 11g R2, предназначенном для распространения данных на базе очередей сообщений Oracle Advanced Queuing (AQ). Этот механизм достаточно универсален, с его помощью можно выполнять репликацию данных; резервное копирование; загрузку хранилищ данных из прикладных систем; управление событиями и т. п.

В СУБД Oracle используется журнал транзакций фиксированного размера, называемый также оперативным журналом повтора (online redo log). Рабочий объем журнала определяется при конфигурировании базы путем указания количества файлов журнала (не менее двух) и их размера. Выделение свободного места для записи генерируемого системой потока транзакций осуществляется по циклической схеме. Записи последовательно помещаются в один из файлов журнала (активный файл), по достижении конца которого производится переключение (logfile switching) на следующий по порядку файл либо на начало первого файла, если был заполнен последний из файлов журнала.

Для реализации возможности сохранения информации о транзакциях за продолжительный период времени, а также для передачи этой информации в другие системы необходимо включить режим ARCHIVELOG, активирующий механизм генерации архивных журналов (archived logs). При работе в таком режиме система осуществляет копирование заполненных файлов оперативного журнала в архивные журналы. Гарантируется, что до перезаписи файла система сделает копию его предыдущего содержимого.

В Oracle для любой базы может быть порождено несколько архивных журналов (не более 10) для решения различных прикладных задач. Каждый архивный журнал представляет собой папку в файловой системе, где сохраняются копии заполненных файлов оперативного журнала транзакций. Папки архивных журналов могут размещаться не только в локальной файловой системе, но и на удаленных устройствах. Обычно архивные журналы создаются для резервного копирования или для зеркального отображения данных на резервный сервер. Для передачи файлов журнала между основным и резервным серверами предназначен встроенный сервис Log Transport Service (процесс, осуществляющий транспортировку файлов журнала), который выполняет синхронизацию между серверами путем копирования журнальных файлов в определенную папку на резервном компьютере. Для подключения базы к Oracle Streams следует создать отдельный архивный журнал, который будет передаваться на целевой сервер  СКИ. Это рекомендуется сделать, чтобы избежать конфликтов со штатными процедурами архивирования, если таковые имеются.

При организации подключения базы к Oracle Streams возникает вопрос, связанный с выбором способа транспортировки файлов журнала на целевой сервер СКИ. Для этого можно использовать либо штатный сервис Log Transport Service, либо реализовать свое решение для передачи файлов.

Транспортировка архивных журналов

Опыт работы с Log Transport Service показал, что этот сервис имеет ряд принципиальных недостатков, ставящих под сомнение целесообразность его применения в качестве транспортного средства для передачи файлов журнала транзакций. Во-первых, метод аутентификации, используемый сервисом, требует совпадения паролей для учетной записи SYS на исходной и целевой базе данных. Данное требование необходимо при использовании сервиса транспортировки для организации зеркалирования, поскольку очевидно, что в этом случае вся учетная информация должна быть идентична. С другой стороны, при подключении к целевому серверу СКИ это ограничение нелогично и не отвечает требованиям безопасности.

Кроме того, Log Transport Service не обеспечивает гарантированной доставки файлов, в результате чего в журнале на целевом сервере могут возникать разрывы в последовательности отгруженных файлов. Это объясняется push-режимом, лежащим в основе архитектуры данного процесса. Если по каким-то причинам не удается передать файл (например, целевой компьютер выключен или с ним разорвано соединение), то процесс после нескольких неудачных попыток просто «забывает» про передаваемый файл и переключается на следующий. Такие разрывы приходится устранять вручную с помощью копий журнала, в которых следует отыскать все потерянные файлы и скопировать их на целевой сервер СКИ. 

Можно рекомендовать альтернативный подход для организации транспортировки файлов журнала на целевой сервер СКИ, который основан на использовании pool-технологии. При подключении исходной базы к системе мониторинга в ней необходимо создать отдельный архивный журнал в папке файловой системы этого сервера. Эту папку следует сделать разделяемой и открыть к ней доступ по сети. На целевом сервере СКИ должен быть реализован и запущен процесс Log_File_Reader, который опрашивает удаленную папку и «забирает» из нее новые файлы. При подключении других внешних источников с архивными журналами каждый из этих журналов будет копироваться в свою папку на целевой сервер СКИ. Таким образом, любой архивный журнал исходной базы будет представлен своей копией, размещаемой в отдельном каталоге целевого сервера СКИ. После того как файл успешно передан, он удаляется из папки первоисточника. Разумеется, что для работоспособности описанной схемы у разделяемой папки-первоисточника должны быть установлены права на чтение/запись/удаление файлов для процесса Log_File_Reader. Изложенная схема по транспортировке файлов журнала обладает одним важным преимуществом — она устраняет возможность появления разрывов в последовательности загружаемых файлов.

Захват изменений

После того как решен вопрос с транспортировкой данных, требуется описать основные понятия и процессы Oracle Streams, которые позволяют выполнять обработку файлов журнала транзакций. Oracle Streams состоит из трех основных процессов:

• Capture Process — захват изменений в рабочих и архивных журналах транзакций, выбор из них записей об изменениях в исходной базе (Change Record, CR) и формирование логических записей изменений (Logical Change Record, LCR), помещаемых в очередь сообщений AQ;
• Propagate Process — передача сообщений из очереди исходной базы в очередь на целевой базе;
• Apply Process — применение изменений из очереди LCR к таблицам целевой базы либо их передача специальной обрабатывающей программе для выполнения необходимых преобразований.

В Oracle 11g R2 реализован комбинированный способ обработки журналов транзакций Combined Capture Apply, позволяющий через служебную очередь организовать взаимодействие между процессами Capture и Apply (рис. 2).

Рис. 2. Схема обработки журналов транзакций с помощью механизма Combined Capture Apply

Процесс захвата изменений осуществляет обработку поступающих log-файлов журнала при помощи вызова штатной утилиты Oracle LogMiner, которая считывает записи об изменениях (CR) и преобразует их в логические записи об изменениях — LCR. Для выполнения этой трансформации LogMiner использует словарь данных исходной базы, выгружаемый в журнал транзакций специальной процедурой (BUILD). На уровне процесса захвата изменений задаются правила, с помощью которых определяются схема и набор таблиц баз данных, подлежащих мониторингу. Соответственно, в очередь процесса Apply будут передаваться только изменения объектов, перечисленные в правилах. Набор правил может изменяться путем добавления в них новых объектов, подлежащих аудиту, или исключения тех, мониторинг которых утратил актуальность. Далее процесс Apply извлекает из очереди входящих сообщений LCR-записи и передает их обрабатывающей прикладной программе. Предварительно выбираемые записи могут быть отфильтрованы по аналогичным правилам, которые задаются для процесса захвата изменений. Обрабатывающая программа разбирает LCR, распознавая указанный там тип операции, и сохраняет ее в базе данных СКИ.

На наш взгляд, главным ограничением существующей версии Streams является отсутствие штатного доступа к словарю данных, который был получен из журнала транзакций. Из-за этого при построении пользовательских сервисов над базой СКИ приходится обращаться к недокументированным системным таблицам для выбора объектов схемы (названий таблиц, полей и т. п.) из списка.

Управление мониторингом

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

При задании конкретного правила в своем профиле пользователь может дополнительно указать дату, начиная с которой он хочет получить соответствующие изменения, произведенные в базе прикладной системы. Указание такой даты «инструктирует» систему о необходимости перезагрузки файлов журнала задним числом, но не ранее момента подключения базы к мониторингу. Это возможно, если считать, что все архивные журналы-первоисточники сохранены в файловой системе СКИ.

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

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

***

Описанный подход к организации мониторинга изменений баз данных позволяет создать корпоративный сервис централизованного аудита всех критических изменений в прикладных системах компании или организации как на уровне данных, так и их структур. Такой аудит особенно важен в случае взаимодействия большого количества прикладных систем, в которые вносятся изменения, способные оказать влияние на логическую целостность и информационную безопасность. Успешное тестирование и апробация изложенных механизмов были проведены в рамках пилотного проекта в компании ОАО «АТС» — коммерческого оператора оптового рынка электроэнергии в России. Одной из побудительных причин для данного проекта стала возникшая в компании потребность в создании единого универсального механизма аудита на уровне СУБД действий пользователей, программ-загрузчиков, SQL-скриптов и т. п., которые затрагивают изменения в схеме  базы и самих данных. Программный комплекс состоит из нескольких сотен взаимодействующих модулей, в которые постоянно вносятся изменения в соответствии с изменениями правил рынка. Подобный механизм аудита дает мощное средство обеспечения логической целостности и информационной безопасности всего программного обеспечения.  Представленное в статье решение по организации аудита на основе журнала транзакций универсально и может быть реализовано на любой платформе  СУБД во многих крупных компаниях и организациях. 

Александр Лашманов (http://www.atsenergo.ru/ats/topmanagement/administration/index.htm) — зам. председателя правления по ИТ ОАО «Администратор торговой системы оптового рынка электроэнергии», Михаил Слепенков (www.keldysh.ru/persons/slepenkov.html) — старший научный сотрудник  Института прикладной математики им. М. В. Келдыша РАН (Москва).