Информационные системы активно входят в нашу повседневную жизнь: большое количество информации и документов переносится в электронный вид, всё больше услуг можно получить через интернет, а бизнес процессы современного предприятия становится сложно представить без использования новейших информационных технологий. Но наряду с несомненными выгодами, которые даёт использование информационных систем, существует и ряд проблем. Одной из таких проблем является проблема информационной безопасности и защиты информации. Ущерб от раскрытия конфиденциальной или секретной информации может быть значительным и даже может привести к разорению предприятий, коммерческий успех которых основан на использовании «ноу-хау». Поэтому грамотно проведённые мероприятия по организации информационной безопасности становятся залогом успеха в деятельности многих организаций. Одной из возможных составляющих комплексной защиты может выступать использование специализированных систем обнаружения вторжений (СОВ) в базы данных, целью работы которых является выявление действий способных нарушить конфиденциальность, целостность и доступность хранящихся данных.
Среди перспективных направлений развития СОВ можно выделить СОВ, которые базируются на методах обнаружения аномалий в SQL-запросах к базе данных, в частности в последние годы получили развитие идеи выявления аномалий в SQL-запросе на основе оценки результатов его выполнения [1, 2, 3]. Отметим, что предлагаемые подходы являются логичным расширением методов, основная идея которых заключается в детектировании аномального поведения пользователей путём осуществления синтаксического анализа текста запроса до его непосредственной передачи на обработку в систему управления базами данных (СУБД). Согласно [3], методы, основанные на оценке результатов выполнения запросов, позволяют более эффективно обнаруживать некоторые виды атак, нежели методы, базирующиеся на синтаксическом анализе, что говорит об актуальности задачи использования данных методов в СОВ и, как следствие, организации интеграции подобных СОВ с различными информационными системами.
На сегодняшний день одной из самых распространённых архитектур информационных систем является архитектура «клиент-сервер». Данная архитектура подразумевает разделение информационной системы на поставщика услуг (сервер) и потребителя (клиент). Информационная система, построенная на базе клиент-серверного подхода, может быть реализована в виде двухзвенной или многозвенного приложения. Так, например, при двухзвенной архитектуре в качестве сервера может выступать СУБД, а в качестве клиента – программа, взаимодействующая с СУБД посредством специализированных компонент (драйверов) и отвечающая за представление данных пользователю. Развитие двухзвенной архитектуры привело к выделению дополнительных звеньев. Среди многозвенных архитектур «клиент-сервер» остановимся на трёхзвенной архитектуре, в которой функция обработки данных вынесена в отдельное звено. При таком подходе происходит разделение функций хранения, обработки и представления данных. Примером использования трёхзвенной архитектуры являются приложения, разработанные в соответствии с рекомендациями технологической платформы Java EE [4]. Так распределённое многоуровневое Java EE приложение состоит из:
клиентский уровень (клиентское приложение);
сервер приложений Java EE (web-уровень и уровень бизнес логики);
сервер хранения данных (СУБД).
При подобной архитектуре клиентское приложение напрямую не взаимодействует с СУБД и, вообще говоря, в общем случае не обладает информацией о типе хранилища данных (это может быть как СУБД, так и другие источники данных, например, файловый репозиторий или удалённый веб-сервис). В данной ситуации посредником между клиентским приложением и СУБД выступает сервер приложения, который получает запросы от клиентского приложения, в случае необходимости обращается к СУБД и возвращает сформированный ответ.
Многоуровневая архитектура помимо декомпозиции, приводящей к уменьшению зависимости между отдельными элементами, позволяет и более гибко организовать защиту отдельных компонентов, например, «спрятать» сервер СУБД за серверами приложений. Зачастую интеграция модуля обнаружения аномалий в уже существующую программу, которая проектировалась и разрабатывалась без учёта возможности подобных расширений, представляет собой сложную и подчас неразрешимую задачу. Наибольшие трудности возникают при работе с монолитными системами, программные компоненты которых сильно связаны и зацеплены между собой, что приводит к отсутствию возможности замены одной части системы на другую, выполняющую ту же функцию. Одним из способов избежать подобной проблемы является проектирование системы, как набора слабо связанных модулей, выполняющих строго определённые задачи. Причём задачи, выполняемые в рамках одного модуля, должны быть однотипными и логически связанными. Удачным решением может быть определение для каждого модуля программы строго определённого интерфейса, через который другие модули смогут к нему обращаться. Применение такого подхода позволит при необходимости заменить одну реализацию интерфейса модуля на другую, при этом изменения других модулей не потребуется, так как все взаимодействия между модулями производятся через неизменный интерфейс.
Продолжая рассматривать трёхзвенную архитектуру Java EE, можно сказать, что наиболее удачным местом для встраивания СОВ является место между сервером приложений Java EE и СУБД. Действительно, в такой ситуации СОВ может контролировать все запросы, которые сервер приложений адресует СУБД, и все результаты выполнения запросов, которые СУБД направляет в ответ.
В общем виде СУБД можно представить как модуль программы, который отвечает за предоставление данных в соответствии с протоколом взаимодействия, определённым строгим интерфейсом. Обращение других модулей программы к данному модулю представляют наибольший интерес, ведь именно во время этого взаимодействия происходит передача данных из СУБД к компонентам программы, которые занимаются подготовкой ответа пользователю системы. На рисунке 1 представлена модель обращения модулей программы к СУБД через определённый интерфейс.
Рис. 1 - Организация доступа к данным через определённый интерфейс
Одним из вариантов добавления функции проверки данных, возвращаемых из хранилища данных, может быть экранирование хранилища данных специальным объектом, реализующим интерфейс источника данных. Данный объект становиться посредником между модулями системы и хранилищем данных. Так все запросы, адресованные хранилищу данных, и все возвращаемые данные будут проходить через этот объект-посредник. Причём для модулей, обращающихся к источнику данных, видимых изменений не будет – объект-посредник станет для них лишь новой реализацией интерфейса доступа к данным. Описанная модель представлена на рисунке 2.
Рис. 2 - Использование объекта-посредника для добавления проверки возвращаемых данных
На диаграмме представлен класс IDSDataSource, который реализует интерфейс источника данных DataSource. Все запросы, поступающие к IDSDataSource через интерфейс DataSource, делегируются классу RealDataSource, который непосредственно осуществляет предоставление данных. Последовательность действий, выполняющихся при обращении к источнику данных, показана рисунке 3.
Рис. 3 - Процесс обработки запроса к базе данных
Как видно из рисунка, сначала запрос за данными поступает к объекту-посреднику, который затем передаёт этот запрос далее «спрятанному» источнику данных, который в свою очередь обрабатывает запрос и возвращает запрашиваемые данные. Эти данные передаются объекту-посреднику, который выполняет их анализ и по итогам анализа, в случае если результат признаётся допустимым, передаёт данные тому, кто их запрашивал.
При таком подходе возможно организовать различное поведение системы обнаружение аномалий. Так объект-посредник может работать в следующих режимах:
Синхронный режим. При таком подходе объект-посредник выполняет оценку переданного ему результата и только после завершения анализа передаёт данные далее по цепочке.
Асинхронный режим. При асинхронном режиме объект-посредник, получив результат выполнения запроса, не задерживает его, а сразу передаёт его тому компоненту, от которого поступил запрос. При этом анализ результата запроса производится в отдельном потоке.
У каждого подхода есть как преимущества, так и недостатки. При работе в синхронном режиме у объекта-посредника есть возможность прервать дальнейшую передачу данных в случае, если при анализе будет выявлена аномалия. Однако при синхронной обработке может существенно увеличиться время отклика системы на запросы. С другой стороны работа в асинхронном режиме позволяет производить оценку результата параллельно основному процессу выполнения запросов, что должно снизить временные задержки. Но в то же время может оказаться так, что процесс обнаружение аномалий в результате запроса завершиться уже позже того, как данные будут переданы пользователю. В таком случае системе обнаружения вторжений остаётся лишь зафиксировать факт аномалий и, возможно, предпринять меры для предотвращения выполнения впредь подобных запросов.
В заключении следует сказать, что в настоящее время спектр архитектурных решений и подходов, применяемых при создании программного обеспечения, весьма широк. Инструментальных арсенал разработчиков ежедневно пополняется новыми утилитами, библиотеками, фреймворками, охватывающими и упрощающими различные этапы разработки и эксплуатации информационных систем. Но, несмотря на это, интеграция информационных систем и систем обнаружения вторжений зачастую затруднена в виду ряда возможных причин:
Используемое архитектурное решение не позволяет расширять функционал приложения, подключая или заменяя в нём существующие модули и компоненты.
Разнородность программно-аппаратного окружения, в котором функционирует СОВ и приложение.
Отсутствие возможности предоставления приложением информации, необходимой для полноценного функционирования СОВ.
Таким образом, разработка архитектурных подходов и методов разрешение подобных проблем является необходимым условием успешной интеграции информационных систем и систем обнаружения вторжений в базы данных. Литература:
Mathew S., Petropoulos M., Hung Q. Ngo, Shambhu Upadhyaya. A Data-Centric Approach to Insider Attack Detection in Database Systems // Recent Advances in Intrusion Detection: 13th International Symposium, RAID, 2010 – P. 382-401.
Григоров А.С. Обнаружение аномалий запросов к базе данных методом определения уровня связанности результата выполнения запроса // Вузовская наука – региону. Материалы 8-й всеросс. научно-техн. конф. – Вологда: ВоГТУ, 2010.
Григоров А.С. Метод обнаружения аномалий запросов к базе данных на основе кластеризации результата выполнения запросов // Материалы всероссийской научно-практической конференции «Череповецкие научные чтения - 2010» - Череповец: ГОУ ВПО ЧГУ, 2010.
Java EE Technical Documentation [http://download.oracle.com/javaee/]
