Изменения безопасности websphere-mq в 7.0+ - Возможно ли защитить объекты MQ без использования выходов безопасности - PullRequest
1 голос
/ 12 мая 2010

Мы используем защитные выходы в WebsphereMQ 6.0 для обеспечения безопасности в клиентах java, подключающихся к MQ и MQ - MQ. Мы используем защитные выходы, чтобы обеспечить безопасный способ подключения к менеджерам очередей, очереди, каналу.

Есть ли какие-либо изменения в механизме безопасности в последней версии, чтобы мы могли полностью избежать использования защитных выходов?

Это то, что наше требование / цель в безопасности MQ

  • Менеджеры очередей должны быть доступны только с указанием правильного имени пользователя и пароля (я знаю, что это невозможно в 6.0 без выходов безопасности)

  • Легальный пользователь после проверки подлинности соединения queuemanager должен иметь доступ только к своей очереди / каналу.

Спасибо

1 Ответ

1 голос
/ 12 мая 2010

Краткий ответ - нет.

WMQ v7.0 внес некоторые существенные изменения в безопасность, такие как добавление тем в качестве первоклассных объектов WMQ, к которым вы можете применить безопасность. Однако для аутентификации удаленных соединений в WMQ v7.0 используются те же механизмы, что и в v6.0, то есть SSL, выходы или некоторая их комбинация. Хотя в WMQ Explorer теперь есть место для ввода идентификатора пользователя и пароля, идентификатор пользователя просто принимается QMgr по номиналу (как в v6.0 и более ранних версиях), и пароль игнорируется, если только выход не используется для его проверки .

Я должен также упомянуть, что всякий раз, когда идентификатор и пароль отправляются от клиента WMQ к выходу на стороне сервера для проверки, ничто не защищает учетные данные при передаче по умолчанию. Если используется выходная пара, возможно, что выходы на стороне клиента и на стороне сервера могли бы установить шифрование для каждого сеанса, в котором отправлять учетные данные. Однако чаще выход на стороне сервера используется в сочетании с каналами SSL с набором шифров, отличным от NULL_SHA или NULL_MD5. Это обеспечивает защиту учетных данных за сеанс, не требуя пары выхода.

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

Настоящая хитрость в том, чтобы подтвердить пароль. Если SSL-сертификата достаточно, можно использовать SSLPEER на канале для фильтрации по отличительному имени или использовать выход для сопоставления SSL-сертификата с локальным идентификатором пользователя. Этот последний метод возможен при использовании бесплатного выхода BlockIP2 из http://mrmq.dk (сайт управляется IBMer, но код выхода поддерживается сообществом).

...