Каким образом очереди могут быть приватными/безопасными в RabbitMQ в многоуровневой системе?
Я прочитал руководство Get Started от RabbitMQ и даже внес шестой пример в stormed-amqp, поэтому у меня есть представление о AMQP.
Однако руководство не является исчерпывающим и позволяет избежать таких вещей, как аутентификация и авторизация.
Мы разрабатываем систему многоуровневости, которая будет использовать RabbitMQ в ситуации типа RPC. Что, возможно, отличается от этой реализации RPC, заключается в том, что удаленные процедуры будут фактически другими программами арендаторов в системе.
В принципе, я хочу изолировать шины данных, которые включают в себя следующие утверждения:
- Наш сервер не будет передавать данные неверной программе арендатора (это обрабатывается легко и актуально, но не допрошено).
- Программы-арендаторы не смогут читать данные из очередей, которые не принадлежат им.
- Программы-арендаторы не смогут писать в очереди, которые не принадлежат им.
Этот вопрос строго связан с безопасностью RabbitMQ. Я знаю, что RabbitMQ поддерживает SSL, который обеспечивает сквозное шифрование, и я знаю, что RabbitMQ поддерживает аутентификацию имени пользователя и пароля. Я не знаю, применимы ли эти вещи к приватизации использования очереди (иначе ACL), т.е. Соединение может быть зашифровано, и пользователь может быть проверен, но пользователь может читать/записывать из всех очередей.
Может кто-нибудь просветить меня на этой более продвинутой теме? Я уверен, что RabbitMQ может поддерживать такую систему, но не совсем позитивно. Я знаю, что в RabbitMQ есть вещи, о которых я просто не знаю, например. что такое vhosts, и помогут ли они в этой ситуации? Я просто не вижу, что решение в моих текущих знаниях ограничено ключами маршрутизации, именами очередей и обменами.
Ответы
Ответ 1
В многоуровневой системе вы делаете очереди безопасными, определяя разрешения, которые есть у пользователей. Прочтите раздел управления доступом руководства администратора RabbitMQ здесь http://www.rabbitmq.com/admin-guide.html
Начните с того, что все происходит внутри vhosts и полностью блокирует общий vhost, то есть не позволяйте никому объявлять очереди и обмены на vhost "/".
Ответ 2
Я верю этот учебник демонстрирует то, что вы пытаетесь сделать.
Тот факт, что callback queue является исключительным, автоматически удаляет и имеет автогенерируемое имя, должен обеспечивать достаточную безопасность.