Как защитить IBM WebSphere MQ 8.0 с помощью Creds? - PullRequest
Новая
       15

Как защитить IBM WebSphere MQ 8.0 с помощью Creds?

0 голосов
/ 04 сентября 2018

Я использую IBM WebSphere MQ 8.x и хочу его защитить.

Как я могу защитить свой WebSphere Queue Messaging с помощью имя пользователя / пароль , чтобы только действительный пользователь мог выполнять операции.

вот так я сейчас получаю доступ к очереди 

Context jndiContext = getInitialContext();
String qcf= getJMSDetailsBean().getQueueConnectionFactory();
QueueConnectionFactory qconFactory = (QueueConnectionFactory) jndiContext.lookup(qcf);
qcon = qconFactory.createQueueConnection();

Не могли бы вы вести меня ниже:

  1. Как мне сначала обезопасить свой MQ?
  2. После # 1, как я могу получить доступ к MQ, используя QueueConnectionFactory?

Спасибо

1 Ответ

0 голосов
/ 05 сентября 2018

Как и во многих других технологиях, существует множество способов выполнить задание, о котором вы спрашиваете, ниже описывается один метод с использованием предоставленной функциональности IBM MQ.

Чтобы сначала ответить на более простой вопрос, если вы хотите передать имя пользователя и пароль в MQ, вы можете позвонить createQueueConnection с аргументами имени пользователя и пароля 

createQueueConnection("username", "password")

На стороне MQ, если вы можете обновить, я бы посоветовал вам перейти на 9.0.0.5 LTS, если вы не можете обновить до v9.0, тогда я предлагаю вам обновить до 8.0.0.10 + IFIX IT25591 , вы Вы можете скачать IFIX для этого прямо со страницы APAR вверху.

Вы не упоминаете, в какой операционной системе работает администратор очередей. Для большинства версий операционной системы вы можете настроить администратор очередей для проверки учетных данных в операционной системе (IDPWOS) или LDAP (IDPWLDAP). Вы будете указывать свойство QMGR CONNAUTH на объект AUTHINFO с AUTHTYPE любым из указанных выше параметров.

В операционных системах Unix, таких как Linux, вы можете настроить IDPWOS метод аутентификации (AUTHENMD) как OS (использует шифрование и сравнение с записями теневого пароля) или PAM (использует подключаемый модуль аутентификации). Если вы используете IDPWOS, я рекомендую PAM, потому что он может обеспечить поддержку шифрования и сравнения (аналогично методу OS), но также поддерживает все, что вы можете делать с PAM, например, аутентификацию в Windows Active Directory.

В целях безопасности вы хотите указать MQ принять аутентифицированного пользователя, это настройка ADOPTCTX(YES) для объекта AUTHINFO. Вы должны настроить администратор очередей для ChlauthEarlyAdopt=Y в файле qm.ini (обратите внимание, что теперь они оба являются поведением по умолчанию на компакт-диске MQ v9.0.4 и выше и на 9.1.0.0 LTS (также на компакт-диске 9.1.1) и выше.

Если вы уверены, что хотите, чтобы каждый SVRCONN канал в администраторе очередей требовал отправки действительного имени пользователя / пароля, вы можете установить CHCKCLNT(REQUIRED) для объекта AUTHINFO. Если вам нужно быть более детальным, вы можете установить его на CHCKCLNT(OPTIONAL), что означает, что при наличии имени пользователя и пароля пароль должен быть действительным для имени пользователя, но это также означает, что если пароль не указан, MQ не будет пытаться выполнить аутентификацию. , Вы можете захотеть этого, если, например, у вас есть некоторые существующие каналы, где вы используете другой метод аутентификации, такой как сертификаты TLS, или выход безопасности. Если для уровня QMGR установлено значение OPTIONAL, вы можете настроить правила CHLAUTH, чтобы повысить значение параметра CHCKCLNT(REQUIRED) для определенных каналов.

Помните, что если вы вносите какие-либо изменения в настройки CONNAUTH администратора очередей, вам нужно запустить REFRESH SECURITY TYPE(CONNAUTH), чтобы они вступили в силу.

Если клиент MQ имеет версию MQ v8 или выше, пароль, если он отправлен по каналу, отличному от TLS, будет защищен по умолчанию с помощью шифрования 3DES, исключение здесь составляет для клиентов Java и JMS, вы должны включить режим MQCSP (совместимость по умолчанию).

Параметр PasswordProtection=always можно установить в qm.ini, чтобы гарантировать, что MQ обеспечивает защиту паролем функции защиты паролем или использование канала TLS с ненулевым зашифрованным кодом. Это также означает, что на не-TLS-каналах будет отклонен любой клиент ниже v8.

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

Я отсканировал список исправлений для IBM MQ версии 8.0 и обнаружил следующие интересные сведения, относящиеся либо к CONNAUTH, либо к безопасности в целом, которые исправлены в версиях, более поздних, чем 8.0.0.3, это не полный список Есть еще много:

8.0.0.5:

  • IT12825 : IBM MQV8: ПРОГРАММА КЛИЕНТА НЕ МОЖЕТ ПОДКЛЮЧИТЬСЯ К МЕНЕДЖЕРУ ОЧЕРЕДИ С ОШИБКОЙ AMQ9777: КАНАЛ БЛОКИРОВАН.
  • IT11645 : СОЕДИНЕНИЕ КЛИЕНТА IBM MQ V8 НЕПРАВИЛЬНО РАЗРЕШЕНО, КОГДА PASSWORDPROTECTION = ВСЕГДА И USER_AUTHENTICATION_MQCSP = FALSE
  • CVE-2015-7473 : IBM WebSphere MQ Неправильное управление доступом для некоторых локальных команд MQSC
  • CVE-2016-0259 : IBM WebSphere MQ Неправильное управление доступом для некоторых команд отображения в локальном runmqsc

8.0.0.6:

  • CVE-2016-3052 : Java-клиенты IBM MQ могут отправлять пароль в виде открытого текста

8.0.0.7:

  • IT18052 : модификации ChlauthEarlyAdopt

8.0.0.8:

  • IT22419 : все запросы аутентификации имени пользователя / пароля зависают. Администратор очередей настроен на запрос через PAM
  • IT21306 : обеспечение согласованности между механизмами включения режима аутентификации MQCSP в Java
  • IT21384 : Настройка COM.IBM.MQ.CFG.JMQI.USEMQCSPAUTHENTICATION = Y не включает режим аутентификации MQCSP после IT15833

8.0.0.10:

  • IT20275 : правила USERMAP CHLAUTH и ChlauthEarlyAdopt не отображаются на правильного пользователя

8.0.0.11 (еще не выпущено):

  • IT25591 : не удается подключиться к администратору очередей после обновления до MQ 8.0.0.10, журнал ошибок сообщает, что пользователю не хватает прав CTRL для qmgr (AMQ8077)
...