О кластеризации серверных модулей в распределенных системах защиты информации

Текст доклада на конференции "Микроэлектроника и информатика - 2010"

© Сергей Панасенко, 2010.

Вводная часть доклада

Распределенные системы защиты могут решать множество различных задач. В настоящее время подавляющее большинство проблем защиты информации могут быть решены с помощью подобных систем, серверная («центральная») часть которых выполняет управление клиентскими устройствами или программными средствами и мониторинг их деятельности, а клиентские модули могут быть следующими [1]:

• антивирусные программы;
• средства защиты от несанкционированного доступа (НСД);
• межсетевые экраны;
• модули создания виртуальных частных сетей (VPN);
• средства обнаружения/предотвращения вторжений (IDS/IPS);
• различные средства обеспечения целостности и конфиденциальности информации;
• модули идентификации и аутентификации;
• средства комплексного обеспечения безопасности;
• прочие модули.

По мере расширения спектра угроз информационной безопасности расширяется и список подобных решений.

Во всех этих случаях можно утверждать, что центральные модули распределенных систем защиты выполняют некий типовой набор функций. Поэтому можно предположить, что структура различных серверов управления распределенными системами защиты в большинстве случаев представляется в виде совокупности следующих модулей [2]:

• сетевая подсистема, отвечающая за прием и передачу команд и/или данных по сети;
• подсистема разбора запросов от управляемых устройств или программных модулей;
• подсистема работы с данными;
• подсистема защиты целостности и конфиденциальности сообщений;
• подсистема защиты хранимых и обрабатываемых сервером данных от несанкционированного доступа;
• подсистема протоколирования операций.

К данным модулям добавляется еще и некий основной, платформо-зависимый, модуль, обеспечивающий функционирование и взаимодействие остальных модулей системы. Например, если программное обеспечение сервера управления представляет собой службу, работающую под управлением операционных систем семейства Windows NT, то в основном модуле должны быть реализованы стандартные функции службы Windows NT [3].

Данная структура представлена на рис. 1.

О подсистеме работы с данными

Одной из подсистем сервера управления является подсистема работы с данными, задача которой – обеспечение взаимодействия с хранилищем данных – основной базой данных (подразумевается, что существует также база данных протоколирования).

На рис. 2 представлена структура подсистемы работы с данными, а также взаимосвязь между ее модулями и другими подсистемами сервера управления. По своей структуре данная подсистема является наиболее простой, однако она является одной из основных (и можно предположить, что наиболее трудоемкой в разработке) в любой системе управления, поскольку отвечает за обработку всех представленных в распределенной системе данных.
Подсистему работы с данными можно представить в виде совокупности двух модулей, назначение которых приведено далее.

• Модуль формирования и выполнения запросов к основной базе данных (БД). Назначение модуля видно из его названия – это формирование запросов к основной БД, их отправка на выполнение и разбор результата выполнения запроса, если запрос подразумевает получение какого-либо набора данных. Данный модуль выполняет наиболее низкоуровневую обработку данных; его работа сводится, фактически, к трансляции команд и данных в запросы к БД и к обратной трансляции данных.
• Модуль взаимодействия с подсистемой разбора команд. Назначение данного модуля – осуществление бизнес-логики на уровне подсистемы работы с данными, что необходимо в тех случаях, когда алгоритм выполнения какой-либо команды зависит от конкретных данных системы, следовательно, такую команду относительно затруднительно реализовать на более высоком уровне – в модуле обработки данных подсистемы разбора команд [4], реализующем основную бизнес-логику работы сервера управления. При этом можно предположить, что при обработке абсолютного большинства простых команд необходимость в данном модуле отсутствует и его задача состоит, фактически, в трансляции данных нижележащему модулю и обратно.

При большом количестве клиентских модулей может потребоваться кластеризация следующих серверных модулей распределенной системы:

• собственно сервера управления;
• основной БД;
• БД протоколирования.

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

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

Итак, предположим, что распределенная система защиты состоит из следующих модулей (см. рис. 3):

• одного или нескольких серверов управления (в последнем случае – объединенных каким-либо образом в кластер);
• нескольких БД, выполняющих как функции основной БД, так и функции БД протоколирования;
• управляемых клиентских модулей.

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

Также предполагаем, что данная функция периодически (частота вызова функции зависит от специфики распределенной системы) вызывается для проверки доступности главной БД и переключения на резервную БД по мере необходимости.
Алгоритм работы такой функции (см. рис. 4) выглядит следующим образом:

1. Если резервные БД не используются или их использование по каким-либо причинам в текущий момент отключено, функция завершает работу.
2. Выполняется проверка доступности главной БД.
3. Если текущая БД (т. е. БД, с которой сервер управления работает в данный момент) – это главная БД, выполняется переход к шагу 4, иначе – переход к шагу 8.
4. Если главная БД доступна, то функция завершает работу (поскольку переключение не требуется).
5. Выполняется поиск доступной БД среди резервных.
6. Если доступная БД не найдена, выполняется разбор и протоколирование ошибки (имеется в виду причина недоступности текущей БД, если ее возможно определить), после чего функция завершает работу.
7. Выполняется протоколирование факта переключения на резервную БД, после чего функция завершает работу.
8. Данный шаг алгоритма достигается в случае, когда текущая БД является резервной, т. е. переключение с главной БД на одну из резервных было выполнено ранее. Если главная БД доступна, то выполняется переход к шагу 9, иначе – переход к шагу 11.
9. Выполняется переключение на главную БД (поскольку она снова стала доступна).
10. Выполняется протоколирование факта переключения на главную БД, после чего функция завершает работу.
11. Данный шаг алгоритма достигается в случае, если текущая БД является резервной, а главная БД по-прежнему недоступна. Здесь выполняется проверка доступности текущей БД.
12. Если текущая БД доступна, программа завершает работу (поскольку нет необходимости в переключении – главная БД все еще недоступна, но доступна резервная БД, с которой в данный момент работает сервер управления). Иначе выполняется переход к шагу 5 (поиск доступной БД среди резервных, поскольку недоступна ни главная БД, ни текущая резервная).

Данный алгоритм представляет собой простейший способ кластеризации БД сервера управления с целью обеспечения отказоустойчивости БД. Алгоритм обеспечивает:

• автоматическое переключение с главной БД на резервную в случае потери связи с главной БД;
• автоматическое обратное переключение на главную БД в случае восстановления связи;
• автоматическое переключение с одной резервной БД на другую в случае потери связи с текущей резервной БД;
• протоколирование ошибок связи с БД и фактов переключения между БД.

Стоит отметить и тот факт, что данный алгоритм не требует доступности всех БД кластера в режиме 24 X 7 – достаточно доступности одной из БД кластера в конкретный момент времени. Помимо отказоустойчивости, это существенно упрощает «горячее» техническое обслуживание системы в части БД без приостановки ее функционирования.

Литература

1. Панасенко С. П. Принципы разработки серверных модулей распределенных систем защиты информации, часть 1. // Вопросы защиты информации. – 2009 – № 2 – с. 30-34.
2. Панасенко С. П. Централизованное управление электронными замками. // Мир и безопасность. – 2005 – № 3 – с. 18-20.
3. Рихтер Д., Кларк Д. Программирование серверных приложений для Microsoft Windows 2000. Мастер-класс. / Пер. с англ. – СПб.: Питер; М.: Издательско-торговый дом «Русская редакция», 2001 – 592 с.
4. Панасенко С. П. Принципы разработки серверных модулей распределенных систем защиты информации, часть 2. // Вопросы защиты информации. – 2009 – № 2 – с. 34-44.

Рисунки

1. Структура сервера управления распределенной системы защиты.
2. Структура подсистемы работы с данными.
3. Структура распределенной системы защиты.
4. Схема алгоритма работы функции переключения между БД.