WebSphere MQ v7.1 безопасности учетных данных пользователя

Question

Linux Server Box работает WebSphere MQ V7.1 сервера:

Я создал пользователя 'MQ-пользователь', который принадлежит группе 'MQ-пользователей' в Linux. Затем я создал диспетчер очереди QM_TEST и используется MQSC выдавать следующие команды для создания очереди и настроить безопасность:

SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('mq-user') AUTHADD(ALL) 
SET AUTHREC PROFILE(SYSTEM.MQEXPLORER.REPLY.MODEL) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(INQ,DSP,GET) 
SET SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(INQ,DSP,PUT) 
DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP) MCAUSER('mq-user') 
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user') 
DEFINE QLOCAL (TEST_QUEUE) 
SET AUTHREC PROFILE(TEST_QUEUE) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(ALL) 
DEFINE LISTENER (TEST_LISTENER) TRPTYPE (TCP) CONTROL (QMGR) PORT (1414) 
START LISTENER (TEST_LISTENER) 

Linux Client Box работает WebSphere MQ Client v7.1 и WebSphere MQ Explorer:

Я зарегистрировался как мое имя пользователя (arrehman), которое не входит в группу пользователей mq-users. Однако я могу получить доступ к очереди, которую я создал выше, как через приложение Java, так и через клиент MQ Explorer без передачи каких-либо учетных данных пользователя. Почему так происходит, если безопасность действует?

Любые дальнейшие подробности, пожалуйста, дайте мне знать. Благодарю.

Answer 1

Эта линия:

SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')

говорит следующее:

• Для соединений, запрашивающих TEST_CHANNEL ...
• происходящих из любого IP-адреса ...
• Set MCAUSER - mq-user

Другими словами, включите канал таким образом, чтобы любые соединения наследовали привилегии mq-user независимо от того, где они происходят, и какой имидж присутствует. Таким образом, поведение, которое вы видите, является ожидаемым поведением, основанным на правиле CHLAUTH выше.

Есть несколько других проблем, с правилами, перечисленными:

• Использование PRINCIPAL, а не GROUP. На серверах, отличных от Windows, если вы укажете PRINCIPAL, произойдет то, что QMgr ищет этот идентификатор, запрашивает его основную группу и затем устанавливает на него авторизации. Поэтому, если mq-users имеет основную группу staff или users, то это то, что получает разрешение вместо mq-users и, вероятно, не то, что вы намеревались. Всегда используйте group, чтобы получить результат, который вы намереваетесь с setmqaut или AUTHREC.
• Предоставление ALL на QMgr делает администратором ID/группы. Одна из привилегий на уровне QMgr - SET, и любой пользователь в группе с правами SET может устанавливать, помимо прочего, списки управления авторизацией. Поэтому, даже если вы предоставили только AUTHADD(INQ,DSP,PUT), идентификатор mq-users может отправлять команды PCF, чтобы предоставить весь доступ ко всем объектам. Предоставьте только CONNECT и INQUIRE на QMgr, если это все, что вам нужно.
• Существует предположение (выделено жирным шрифтом), которое, как вы ожидали, должно было передавать учетные данные пользователя. Имейте в виду, что WMQ не проверяет идентификатор пользователя и пароль, если вы их предоставите. Он принимает идентификатор, который вы утверждаете. Поле пароля доступно для выходов, которые могут использоваться для проверки идентификатора и пароля для, например, LDAP или локальной ОС.Такой выход можно приобрести у третьего лица или записать, но базовый WMQ ничего не делает с паролем. Если бы вы указалина сопоставлении, то ваш идентификатор был бы использован и, скорее всего, отклонен. Но отказ был бы либо потому, что он находится в mqm группы (которая блокируется CHLAUTH правила по умолчанию) или потому, что нет AUTHREC записи для группы он находится.

Подробнее о закалке WMQ, имеется ряд собранных ресурсов here. Презентация Hardening WebSphere MQ - от версии 7.0. Несмотря на то, v7.1 имеет новые элементы управления, принципалы остаются прежними:

• Аутентифицировать соединение с помощью фильтрации IP (для приложений или QMgrs, где соединение происходит в запертом центре обработки данных), SSL/TLS и/или выход
• Карта аутентифицированного идентичности к MCAUSER значения путем жесткого кодирования его в канале или с помощью выхода или CHLAUTH правило динамически установить его
• Административные соединения и высокой стоимости приложения должны пройти проверку подлинности с помощью TLS