Учетные данные пользователя для защиты WebSphere MQ v7.1 - PullRequest
2 голосов
/ 23 февраля 2012

Linux Server Box с WebSphere MQ Server v7.1:

Я создал пользователя 'mq-user', который принадлежит группе 'mq-users' в 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 MQExplorer:

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

Если вам нужна дополнительная информация, пожалуйста, сообщите мне.Спасибо.

1 Ответ

6 голосов
/ 24 февраля 2012

Эта строка:

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

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

  • Для соединений, запрашивающих TEST_CHANNEL ...
  • Исходящий из любой IP-адрес ...
  • Установите 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 не проверяет ID пользователя и пароль, если вы их предоставляете. Он принимает идентификатор, который вы утверждаете. Поле пароля доступно для выходов, которые можно использовать для проверки идентификатора и пароля, например, по LDAP или локальной ОС. Такой выход можно приобрести у стороннего производителя или в письменном виде, но базовый WMQ ничего не делает с паролем. Если бы вы указали USERSRC(CHANNEL) в сопоставлении, тогда ваш идентификатор был бы использован и, скорее всего, отклонен. Но отклонение могло быть либо из-за того, что он входит в группу mqm (которая блокируется правилом CHLAUTH по умолчанию), либо из-за отсутствия AUTHREC записей для группы, в которой он находится.

Для получения дополнительной информации об усилении WMQ, есть ряд собранных ресурсов здесь . Презентация Hardening WebSphere MQ относится к версии 7.0. Хотя v7.1 имеет новые элементы управления, принципалы остаются прежними:

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