CC BY
43
ПЕРСПЕКТИВНЫЕ ИНФОРМАЦИОННЫЕ
ТЕХНОЛОГИИ
РАЗРАБОТКА ПОЛЬЗОВАТЕЛЬСКОЙ КОНСОЛИ ДЛЯ ПРОГРАММНОГО КОМПЛЕКСА МОНИТОРИНГА И АУДИТА БАЗ ДАННЫХ QDAS
С.В. Антонов
Научный руководитель - кандидат технических наук, доцент Д.И. Муромцев
В рамках работы произведена разработка клиентской части для программного комплекса мониторинга и аудита баз данных QDAS, предоставляющей возможности по настройки политик безопасности и конфигурации сервера QDAS. Помимо этого, разработанная консоль предоставляет удобный пользовательский интерфейс для просмотра и анализа накопленных в системе данных.
Введение
В настоящее время практически на всех крупных предприятиях внедрены системы автоматизации производственных и бизнес-процессов. Это системы автоматизированного проектирования, поддержки жизненного цикла продуктов, автоматизированного документооборота и т.д. Подобные комплексы в процессе своей работы накапливают и манипулируют огромными объемами данных, причем с данными одновременно может работать множество пользователей. По этой причине в таких комплексах для хранения информации применяются специальные хранилища, называемые базами данных, а для доступа к ним - системы управления базами данных (СУБД).
Современные СУБД, помимо структурированного хранения данных, предоставляют множество дополнительных сервисов, таких как параллельная обработка запросов, поддержка целостности данных, исполнение программного кода и т.д. Одним из наиболее важных сервисов является контроль наличия прав на доступ к данным и выполнение операций. В настоящее время большинство СУБД позволяют настроить права доступа определенного пользователя или группы пользователей для всех объектов базы данных. Однако, учитывая темпы роста и усложнения современных систем, а также то, что все больше стратегически важной информации переводится в электронный вид, становится актуальным вопрос о контроле над санкционированным доступом к информации, а также сборе статистических сведений об обращении к объектам баз данных.
В связи с этим в последние несколько лет активно разрабатываются комплексы для мониторинга и аудита различных типов баз данных. Одним из таких комплексов, поддерживающим такие СУБД, как Oracle, MS SQL и Sybase, является Quest Database Auditing and Security (QDAS). Центральным узлом данного комплекса является QDAS-сервер. Сервер представляет собой набор автономных модулей, поддерживающих функционирование на платформах Sun Solaris, Linux Red Hat, MS Windows NT-XP. Он предназначен исключительно для перехвата, обработки и сохранения сетевого трафика с максимальным быстродействием и не содержит пользовательского интерфейса, или иных средств администрирования и постобработки. В связи с этим в рамках работы была спроектирована и разработана пользовательская консоль, предоставляющая следующие функциональности:
• настройку параметров работы сервера анализа и политик сбора информации о транзакциях, осуществляемых в организации;
• вывод накопленных в системе данных в удобном для пользователей виде;
• одновременную работу нескольких пользователей;
• предотвращение несанкционированного доступа к хранимым в системе данным;
4
• одновременную работу пользователя с несколькими серверами анализа;
• «дружелюбный» пользовательский интерфейс.
Анализ средств сопряжения консоли с комплексом
К основной функциональности, которую должна обеспечивать консоль, можно отнести вывод накопленных в системе данных, настройку сервера анализа и своевременное реагирование на изменения в системе. Последнее требование обусловлено тем, что разработанная консоль является многопользовательской системой, и при изменении данных одним пользователем эти изменения должны быть отображены остальным пользователям системы.
В соответствие с указанными требованиями консоль должна обеспечивать удобные в использовании и надежные механизмы для настройки системы и вывода и анализа накопленной в системе информации. На рис. 1 показана общая схема комплекса ОБЛБ в рабочей среде.
Рис. 1. Структурная схема комплекса ОРЛБ
В корпоративной сети имеется несколько серверов баз данных (Сервер БД1 - Сервер БД4), к каждому из которых подключено множество клиентов. Сервер анализа подключен к каналу передачи данных между ними и перехватывает весь идущий трафик. Попадая на сервер анализа, данные подвергаются разбору в соответствии с политиками, установленными на сервера анализа. После разбора и анализа нужные данные передаются в репозитории. Следующей задачей является извлечение данных из репозито-рия, их отображение и анализ. Эти задачи возлагаются на пользовательскую консоль. Как видно из схемы, к одному серверу анализа может быть одновременно подключено несколько консолей, и в то же время одна консоль позволяет настраивать и анализировать данные с нескольких серверов анализа.
В схеме возможно построение стандартной трехзвенной архитектуры, в которой клиент (консоль в данном случае) взаимодействует с базой данный (репозиторий в данном случае) только через сервер приложений, роль которого в системе может выполнять сервер анализа. Однако такой подход неприемлем, поскольку сервер анализа не должен быть нагружен задачами, не относящимися к обработке трафика, так как эта задача является крайне ресурсоемкой и критической с точки зрения скорости обработки. В отдельные моменты времени объемы обрабатываемого трафика могут быть крайне велики, и сервер анализа будет не в состоянии обработать их «на лету». В такой ситуации данные будут сохранены в памяти и обработаны при первой возможности. Если же ресурсов недостаточно, то сервер перезаписывает старые пакеты данных новыми. В случае же, когда сервер анализа отвечает за передачу данных клиентам, вероятность потери данных, вследствие их перезаписи, существенно выше.
Также возможен вариант выделения отдельного сервера для обработки запросов клиентов и реализация консоли в виде тонкого клиента, т.е. без необходимости установки дополнительного программного обеспечения на клиентские машины. Однако такой вариант нецелесообразен, так как в системе не подразумевается работа большого количества пользователей. В соответствии с этим в консоли реализован модуль доступа к серверу анализа и модуль доступа к репозиторию, абстрагирующие остальные модули от реализации механизмов связи с сервером анализа и репозиторием, соответственно.
Для взаимодействия с сервером анализа были рассмотрены следующие технологии: ремоутинг, веб-сервисы, сокеты, COM+, IPC, CORBA. При выборе технологии взаимодействия консоли и сервера анализа, ограничивающими факторами являются:
• совместимость с технологиями, использованными при разработке комплекса:
■ консоль разработана на платформе .NET;
■ сервер анализа разработан на основе стандартных библиотек языка C и функций операционной системы;
• кросплатформенность сервера анализа;
• время, затраченное на реализацию взаимодействия на основе выбранной технологии.
В результате по общей совокупности характеристик была выбрана технология со-кетов, так как она реализована на всех платформах [1], а в среде .NET для нее есть удобная оболочка, полностью реализующая функциональность сокетов и предоставляющая дополнительные методы для асинхронной работы. Помимо этого, важным фактором является то, что в сервере анализа на данный момент уже реализована функциональность, обеспечивающая передачу сообщение по сокетам.
Что касается репозитория, то он представляет собой РСУБД (реляционную систему управления базами данных) Oracle версии 10/. Система Oracle была выбрана в первую очередь по соображениям безопасности и производительности. Более подробную информацию по этому вопросу можно найти в [2]. Помимо этого, Oracle является наиболее гибкой системой в настоящее время и предоставляет множество механизмов для реализации программной логики прямо внутри базы данных [3, 4].
Для взаимодействия с Oracle, как и с другими РСУБД, требуется клиентское программное обеспечение, реализующее интерфейс с данным сервером баз данных. Сегодня под платформу .NET предлагается множество Oracle-клиентов, из которых наиболее сильные позиции занимают Oracle Data Provider for .Net (ODP.NET), Microsoft .Net Data Provider for Oracle и OraDirect .Net Data Provider. В наиболее полной мере возможности Oracle покрывает ODP.NET, однако он требует дополнительной установки и занимает около 200 Мб на диске. Что касается OraDirect .Net Data Provider, то он компактен (11 Мб) и в режиме ограниченной функциональности поддерживает все версии Oracle, начиная с версии 8.
В итоге для взаимодействия с сервером репозитория по общей совокупности характеристик был выбран Microsoft .Net Data Provider for Oracle - провайдер, в достаточной мере покрывающий функциональность сервера БД, а также обеспечивающий высокую производительность и имеющий поддержку со стороны производителя платформы разработки.
Разработка программной модели
Разработанная консоль представляет собой Windows-приложение, реализованное на платформе .NET. Программная структура консоли представлена на рис. 2.
Рис. 2. Программная структура консоли
Логически консоль можно подразделить на четыре уровня: уровень пользовательского интерфейса, уровень программной логики, уровень доступа к данным (или уровень абстрагирования данных) и уровень доступа к серверу анализа. Такое деление обусловлено необходимостью такого выделения модулей системы, чтобы при глобальных изменениях системы как можно больше ее частей оставалось в исходном состоянии.
Уровень пользовательского интерфейса отвечает за прорисовку элементов управления консоли, отображение окон, вывод диалогов. На этом уровне также происходит создание объектов программной логики. Это обусловлено тем, что программный код данного уровня является стартовым, и, соответственно, при запуске программы управление передается именно ему. Уровень пользовательского интерфейса также отвечает за реакцию на действия пользователя, тем самым обеспечивая интерактивность работы. Помимо этого, он содержит функциональность, необходимую для оповещения пользователя о событиях, происходящих в системе. На этом уровне также выполняются основные операции, связанные с синхронизацией потоков [5] консоли.
Уровень программой логики отвечает за выполнение операций, связанных с бизнес-логикой системы, а также логикой работы самой консоли. Он является центральным
звеном консоли, так как связывает все остальные в единое целое и определяет четкие интерфейсы взаимодействия компонентов консоли. Также важной функцией уровня является инкапсуляция программой логики, не зависящей от взаимодействия консоли с окружающей средой. Такая инкапсуляция требуется, в первую очередь, для того, чтобы не переписывать программную логику при изменении в одном из модулей системы. Уровень является своего рода скелетом, на который крепятся остальные модули системы.
Уровень доступа к данным осуществляет передачу данных между консолью и ре-позиторием. В его обязанности входит преобразование типов данных, заполнение коллекций из курсоров, открытие/закрытие соединений, управление транзакциями и блокировками. Реализация уровня зависит от используемой системы управления базами данных в качестве репозитория. Основной же его задачей является абстрагирование остальных уровней от деталей реализации репозитория.
Уровень доступа к серверу анализа абстрагирует консоль от методов взаимодействия с сервером анализа. Он содержит коды всех команд, механизмы асинхронного запуска операций, методы для декодирования и распознания сообщений, приходящих с сервера анализа. На уровне доступа к серверу анализа также содержится функциональность для протоколирования операций обмены сообщениями.
Проектирование структуры консоли
С точки зрения предметной области консоль можно разделить на две основные части - пользовательскую и административную.
Пользовательская часть предоставляет возможности настройки встроенных политик мониторинга, а также конфигурирования произвольных пользовательских политик. Помимо этого, пользовательская консоль содержит множество отчетов, отображающих все данные, накопленные в системе, в структурированном виде.
Административная консоль предоставляет функциональность по конфигурированию сервера анализа, администрированию учетных записей пользователей комплекса, указанию параметров целевых серверов и др.
По реализуемой функциональности в консоли модно выделить следующие основные части: мониторинг соединений с базами данных, мониторинг по встроенным политикам, мониторинг по пользовательским политикам, аутентификация пользователей.
Мониторинг соединений с базами данных
Раздел мониторинга соединений с базами данных позволяет настраивать политику, в соответствии с которой определяется, какие соединения с базой данных считать допустимыми, а какие - нет. При настойке политики пользователь может указать сохранение всех команд перехваченных сессий в репозиторий. В дальнейшем сохраненные команды могут быть просмотрены и проанализированы администратором безопасности. Помимо этого, пользователь может указать получать извещение о сессии, не входящей в список допустимых сессий. Также важной особенностью является возможность указать автоматически прекращать все недопустимые сессии.
Помимо подраздела настроек, в данном разделе содержится два отчета по всем сессиям в системе. Один отчет содержит линейный список сессий, что позволяет производить фильтрацию и сортировку по всем параметрам сессий. Другой отчет (рис. 3) содержит все сессии в сгруппированном виде.
Группировка осуществляется по параметрам, однозначно определяющим сущность, породившую данную сессию. При выборе одной из строк в нижней таблице отображается список всех сессий с соответствующими параметрами. При желании пользователь может либо завершить выбранную сессию, либо сделать параметры, идентифи-
цирующие ее, допустимыми. Также у пользователя есть возможность просмотреть все команды, выполненные этой сессией, а также данные, переданные в соответствующую команду, и ошибки, вызванные ее выполнением.
Рис. 3. Отчет по соединениям с базами данных Мониторинг по встроенным политикам
Встроенные политики представлены следующими разделами: мониторинг привилегированных сессий, мониторинг ошибок авторизации, мониторинг отсутствия привилегий доступа. Каждый из разделов содержит средства для настройки соответствующей политики, а также подробные отчеты по данным, собранным соответствующей политикой. На рис. 4 представлен отчет по политике отсутствия привилегий доступа.
Данный отчет содержит записи обо всех отказах доступа за выбранный период. В каждой записи, помимо параметров, идентифицирующих сущность, которой было отказано в доступе, отображается запрос, породивший ошибку доступа, код и расшифровка ошибки, запрашиваемые объекты.
Политика мониторинга отсутствия привилегий доступа ведет отчетность по все случаям отказа какой-либо сессии в доступе к объекту базы данных. При настройке политики пользователь может указать, посылать ли извещение при отказе доступа, настроить порог, при котором посылается извещение, а также указать, сохранять ли записи обо всех отказах доступа или же сохранять запись только при превышении порога.
Политика мониторинга ошибок авторизации записывает информацию обо всех неудачных попытках регистрации на сервере баз данных. Параметры настройки и отчеты по большей части схожи с разделом политики мониторинга отсутствия привилегий доступа.
Политика мониторинга привилегированных сессий предоставляет информацию о том, какая сущность была подключена к базе данных в привилегированном режиме, когда и какие операции были выполнены в рамках соответствующей сессии. Параметры настройки и отчеты по большей части схожи с разделом политики мониторинга от-
сутствия привилегии доступа, однако пользователю предоставляется возможность выбирать, какие именно сессии считать привилегированными.
Рис. 4. Отчет по политике мониторинга отсутствия привилегий доступа Мониторинг по пользовательским политикам
Рис. 5. Раздел пользовательской политики
Раздел мониторинга по пользовательским политикам показан на рис. 5.
Раздел позволяет настраивать политики, отслеживающие работу пользователей с определенными объектами баз данных. Для каждой политики можно указать действия, осуществляемые при ее нарушении. Действия могут быть следующим: сохранить информацию в отчет для дальнейшего просмотра, послать извещение во все запущенные в этот момент консоли или же завершить соединение, нарушившее политику.
Управление учетными записями пользователей
Раздел предоставляет возможность добавления, изменения и удаления учетных записей пользователей системы. Каждый пользователь идентифицируется с помощью SID (Security Identifier - идентификатор безопасности, применяемый в системах Windows). В системе поддерживается 2 типа учетных записей: пользовательская и административная. Пользовательская учетная запись позволяет получить доступ к пользовательской части консоли, административная, соответственно, - к административной. Если в системе все пользователи являются администраторами, то она работает в режиме супервайзора, в котором у пользователей есть доступ к обеим частям консоли. Этот режим реализован для систем, где разделение прав нецелесообразно (при одном или нескольких пользователях). Внешний вид раздела по управлению учетными записями пользователей показан на рис. 6.
Рис. 6. Раздел управления учетными записями
Механизм аутентификации консоли базируется на системе аутентификации ОС Windows, что позволяет пользователям не вводить дополнительный пароль. Для заве-
дения новых учетных записей применяется встроенная подсистема поиска пользователей, позволяющая находить как локальных, так и доменных пользователей.
Заключение
Разработанная консоль предоставляет пользователям удобный доступ ко всей функциональности комплекса QDAS, включая возможности конфигурирования режимов работы сервера, настройки политик сбора информации и вывода всех накопленных в системе данных в удобной для восприятия форме. Помимо этого, консоль предоставляет возможности по фильтрации и анализу выводимых данных, тем самым позволяя производить планирование политики безопасности в организации.
Литература
1. Гантер Д., Барнет С., Гантер Л. Интерация Windows NT и UNIX в подлиннике. СПб: БХВ, 1998. 464 с., ил.
2. Кайт Т. Oracle для профессионалов. Книга 1. Архитектура и основные особенности. / Второе издание. СПб: ДиаСофтЮП, 2004. 672 с.
3. Кайт Т. Oracle для профессионалов. Книга 2. Расширение возможностей и защита. / Второе издание. СПб: ДиаСофтЮП, 2004. 848 с.
4. Ферштейн С., Прибыл Б. Oracle PL/SQL для профессионалов. 3-е изд. СПб: Питер, 2004. 941 с.; ил.
5. Рихтер Д. Windows для профессионалов: создание эффективных Win32 приложений с учетом спецификации 64-разрядной версии Windows. М.: Русская Редакция, 2001. 752 с.; ил.
