поиск по сайту
СРАВНИТЕЛЬНЫЙ АНАЛИЗ AMQP БРОКЕРОВ СООБЩЕНИЙ ДЛЯ ИСПОЛЬЗОВАНИЯ В КАЧЕСТВЕ ЭЛЕМЕНТА ДЕЦЕНТРАЛИЗОВАННОЙ СИСТЕМЫ РАЗГРАНИЧЕНИЯ ДОСТУПА

СРАВНИТЕЛЬНЫЙ АНАЛИЗ AMQP БРОКЕРОВ СООБЩЕНИЙ ДЛЯ ИСПОЛЬЗОВАНИЯ В КАЧЕСТВЕ ЭЛЕМЕНТА ДЕЦЕНТРАЛИЗОВАННОЙ СИСТЕМЫ РАЗГРАНИЧЕНИЯ ДОСТУПА

А.Ю. ЧАДОВ, К.Э. МИХАЛЬЧЕНКО

МФТИ (НИУ), Москва, 117303, Россия

ЗАО «ОКБ САПР», Москва, 115114, Россия

Введение

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

 

Рис. 1 Децентрализованная система разграничения доступа

К нему будет предъявляться рад требований, вытекающих из требований к самой системе. Удовлетворяющий этим требованиям менеджер можно либо написать с нуля, либо использовать уже существующий сторонний брокер сообщений. Но в первом случае следует учесть, что написание менеджера очередей сообщений достаточно трудоёмкая задача: это достаточно большой проект, в котором необходимо реализовать множество механизмов, таких как кэширование данных, мультипоточная обработка запросов, отказоустойчивость, работа при высоких нагрузках и т.д. В связи с этим прежде, чем браться писать свой брокер, логично сначала исследовать имеющиеся на рынке решения: возможно, какие-то из них будут удовлетворять всем требованиям. А даже если ни один из существующих брокеров не подойдёт, в процессе анализа можно будет выявить общие полезные подходы, которые помогут в дальнейшей разработке.

Для рассмотрения были выбраны распространенные брокеры сообщений, поддерживающие стандартизованный в ISO/IEC 19464:2014 протокол AMQP [2], а именно:

  • RabbitMQ
  • Apache ActiveMQ
  • Qpid C++
  • SwiftMQ Universal Router
  • Apache Artemis
  • Apache Apollo

Определение требований

В статье [1] к системе разграничения доступа был выдвинут следующий список требований:

  1. Система должна состоять отдельных модулей, общающихся друг с другом через определённое API. Среди этих модулей обязательно должны быть:
    • модуль принятия решений о доступе,
    • модуль хранения политик доступа,
    • модуль-перехватчик запросов доступа субъектов к объектам,
    • модуль управления политиками,
    • модуль транспортной системы для передачи сообщений.
  2. Решения о доступе субъектов к объектам должен принимать центральный модуль, политики также должны храниться централизовано.
  3. Задержка, вносимая работой системы, не должна ощущаться пользователем: она должна быть того же порядка, что и время обращения к диску или меньше.
  4. Модули должны иметь возможность проводить взаимную аутентификацию.
  5. Данные, передаваемые в запросах модулей друг к другу, должны быть защищены от изменения.

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

1) функциональность:

a. используемый механизм передачи сообщений не должен тратить много ресурсов;

Это связано с тем, что система разграничения доступа не должна вносить значительного замедления в работу основной системы. Например, механизм получения сообщений, использующий постоянную проверку наличия сообщений для узла, связан с большим потреблением ресурсов СВТ. Передача сообщений в формате подписки не нагружает СВТ так сильно.

b. поддержка однонаправленной, широковещательной и групповой передач данных;

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

c. упорядоченная доставка сообщений;

Это требование обусловлено необходимостью упорядоченного выполнения команд компонентами системы разграничения доступа. В контексте разграничения доступа пришедшие в неправильном порядке сообщения, например, о разрешении/запрете доступа, очевидно, недопустимы.

d. гарантированная доставка

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

2) масштабируемость

a. горизонтальная масштабируемость:

Система разграничения доступа является распределенной; горизонтальная масштабируемость является необходимым требованием для таких систем [3]. Поскольку брокер сообщений является ключевым элементом, то к нему так же предъявляется это требование.

3) отказоустойчивость: 

a. отказоустойчивость брокера/кластеризация;

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

b. автоматическое восстановление каналов после потери связи;

Так же, как и предыдущее, это требование предъявляется к брокеру сообщений в следствие наличия требования отказоустойчивости к системе разграничения доступа. В случае потери связи с серверной частью клиентский модуль должен по возможности полностью восстановить связь с сервером.

4) поддержка механизмов обеспечения безопасности каналов связи:

a. контроль доступа;

Никто не должен вмешиваться в работу системы разграничения доступа, если не имеет на это прав. Т.к. НСД к брокеру может привести к вмешательству в работу системы, то к нему предъявляется требование о наличии контроля доступа.

b. поддержка TLS/SSL

Данное требование к брокеру следует из необходимости защитить от изменений управляющие команды системы разграничения доступа.

5) универсальность:

a. открытый исходный код брокера

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

b. наличие библиотек для разных языков программирования;

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

c. кроссплатформенность;

Требование кроссплатформенности предъявляется к децентрализованной системе разграничения доступа, а, следовательно, и к брокеру, как к её элементу.

Сравнительный анализ

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

Таблица 1. Результаты сравнения брокеров сообщений.

 

RabbitMQ

ActiveMQ

Qpid C++

SwiftMQ

Artemis

Apollo

Результат сопоставления

Подписка на сообщения

+

+

+

+

+

+

Равнозначные возможности

Однонаправленная, широковещательная, групповая передача данных

Реализованы все типы

Реализованы однонаправленный и широковещательный типы

Реализованы однонаправленный и широковещательный типы

Реализован только однонаправленный тип

Реализованы однонаправленный и широковещательный типы

Реализованы однонаправленный и широковещательный типы

Преимущество RabbitMQ, так как только он поддерживает групповую передачу сообщений

Упорядоченная доставка сообщений

+

+

+

-

+

-

Преимущество RabbitMQ, ActiveMQ, Qpid C++ и Artemis

Гарантированная доставка сообщений

+

+

+

+

+

+

Преимущество Artemis и Qpid C++, так как только они помимо гарантии доставки, гарантируют что сообщение будет доставлено только 1 раз

Кластеризация

+

+

+

+

+

-

Равнозначные возможности у всех, кроме Apollo

Восстановление каналов после потери связи

+

+

+

+

+

-

Равнозначные возможности у всех, кроме Apollo

Масштабируемость

+

+

+

+

+

+

Равнозначные возможности

Контроль доступа

+

+

+

+

+

+

Равнозначные возможности

SSL/TLS

+

+

+

+

+

+

Равнозначные возможности

Открытый код

+

+

+

-

+

+

Равнозначно у всех, кроме SwiftMQ

API

[5]

[6]

C++, Java, Python

-

Core client, JMS 2.0 client

[7]

Преимущество RabbitMQ, ActiveMQ и Apollo, так как поддерживают большее количество языков программирования

Поддерживаемые платформы

[4]

Любая, поддерживающая Java 7+

Linux, Windows

Linux, Windows

Любая, поддерживающая Java 8+

Linux, OC X, Windows

Преимущество RabbitMQ, ActiveMQ и Artemis, так как поддерживают большее количество платформ (платформ поддерживающих Java немного меньше, чем платформ, которые поддерживает RabbitMQ)

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

Также из-за отсутствия гарантии упорядоченной доставки сообщений для системы централизованного управления СЗИ не подходит SwiftMQ.

По результатам сопоставления API и поддерживаемых платформ, выделяются 2 брокера: RabbitMQ и ActiveMQ. При этом в RabbitMQ реализована групповая передача сообщений, что открывает больше возможностей при проектировании системы централизованного управления СЗИ.

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

Сравнение брокеров

Одной из наиболее важных количественных характеристик брокера является скорость обработки сообщений. Эта характеристика будет играть важную роль при увеличении системы. При увеличении количества модулей системы будет расти поток сообщений, и в какой-то момент скорости обработки станет не хватать, для дальнейшего расширения придётся использовать кластеризацию, выделять дополнительные мощности и перенастраивать систему. И чем выше скорость обработки сообщений, тем больше модулей смогут одновременно общаться с сервером децентрализованной системы разграничения доступа, построенной с использованием только одного запущенного брокера сообщений без использования кластеризации. Поэтому далее сравним выбранные на предыдущем шаге брокеры по скорости обработки сообщений в различных ситуациях. Полных данных для сравнения найти не удалось, поэтому для замера производительности проведен эксперимент.

Основываясь на тех данных о скорости работы брокеров, что всё же удалось  найти в интернете, а также на том, что RabbitMQ написан на языке программирования Erlang, предназначенном для написания программ для распределенных систем [8], можно сделать предположение, что RabbitMQ покажет лучшие результаты в данном эксперименте.

Стенд для тестов:

  • Машина с брокером и администратором, принимающим сообщения
  • 4 машины, соединенные с первой в виртуальной сети

Характеристики машин:

  • Процессор Intel(R) Xeon(R) CPU E5-2670, 2.60GHz, 4-ядерный
  • Оперативная память 4 GB
  • Размер диска 60 GB
  • Операционная система Ubuntu 18.04.1 LTS

В эксперименте использовалось 200 клиентов, передающих сообщения через брокер администратору, по 50 клиентов на каждой машине. При таких условиях CPU на машинах не загружается и не влияет на оценки производительности.

Количество клиентов было выбрано исходя из среднего количества клиентов, которое находится под контролем системы разграничения доступа Аккорд в одной организации.

Все клиенты одновременно передавали сообщения в брокер. Время замерялось с момента начала приема сообщений администратором до получения последнего сообщения. Были проведены разные тесты:

  • Каждый клиент передавал 10000 сообщений размером 1Кб.
  • Каждый клиент передавал 100 сообщений размером 1Кб
  • Каждый клиент передавай 100 сообщений размером 10Кб
  • Каждый клиент передавал 10000 сообщений размером 10Кб

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

В ходе эксперимента обнаружилось, что ActiveMQ значительно медленнее остальных (около 8 часов для передачи 2000000 сообщений размером 1Кб, когда самый медленный из оставшихся передавал за 35 минут). Непонятно, почему результат так разительно отличался от других, но брокер был установлен со стандартными настройками, никаких дополнительных изменений в конфигурацию внесено не было. Поиск путей оптимизации не входит в данную работу, поэтому дальнейшие тесты ActiveMQ не проводились.

Итоговая таблица с результатами эксперимента:

Условие

брокер

2000000

1Кб

200000

1КБ

200000

10КБ

2000000

10Кб

RabbitMQ

4606 сообщ/с

5720 сообщ/с

5115 сообщ/с

3145 сообщ/с

Qpid C++

968 сообщ/с

880 сообщ/с

848 сообщ/с

916 сообщ/с

Artemis

3600 сообщ/с

1745 сообщ/с

1338 сообщ/с

1796 сообщ/с

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

Заключение

Был проведён сравнительный анализ брокеров сообщений. В результате анализа были выявлены брокеры, подходящие для использования в качестве элемента децентрализованной системы разграничения доступа. Поставленный эксперимент показал, что брокером с самой высокой скоростью обработки сообщений среди удовлетворяющих выдвинутым критерием брокеров является RabbitMQ. Его и планируется использовать при дальнейшей разработке системы.

Список литературы

  1. Чадов А.Ю. Выработка требований к децентрализованной системе разграничения доступа // Вопросы защиты информации, 2018. №3. С.13-16.
  2. ISO/IEC 19464:2014 [Электронный ресурс] URL: https://www.iso.org/standard/64955.html (дата обращения: 24.10.2018)
  3. Проблемы распределенных систем [электронный ресурс] URL: https://cyberleninka.ru/article/v/problemy-raspredelennyh-sistem (дата обращения 30.10.2018)
  4. Supported Platforms [Электронный ресурс]. URL: https://www.rabbitmq.com/platforms.html (дата обращения: 25.08.2018).
  5. Clients & Developer Tools [Электронный ресурс]. URL: https://www.rabbitmq.com/devtools.html (дата обращения: 25.08.2018).
  6. Apache ActiveMQ [Электронный ресурс]. URL: http://activemq.apache.org/cross-language-clients.html (дата обращения: 25.08.2018)
  7. Architecture [Электронный ресурс] URL: https://activemq.apache.org/apollo/documentation/architecture.html (дата обращения: 26.08.2018)
  8. Erlang (язык программирования) [Электронный ресурс] URL: https://ru.bmstu.wiki/Erlang_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F) (дата обращения: 26.08.2018)