НОУ ИНТУИТ | Лекция | Обеспечение безопасности WebSphere MQ

Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру

Теперь нужно настроить клиент и сервер так, чтобы они доверяли бы только удостоверяющему центру. Сделать это можно, импортировав сертификат удостоверяющего центра в хранилища TrustStore клиента и сервера.

Сделаем это, выполнив на клиенте следующую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/truststore.jks -storepass secret -noprompt

На сервере выполним такую команду:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.

Выполним на клиенте такую команду:

keytool -v -delete -alias server -keystore client/src/test/resources/truststore.jks -storepass secret

Вот — команда для сервера:

keytool -v -delete -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret

Если снова запустить клиент — можно видеть успешное прохождение теста. А это значит, что клиент и сервер успешно обмениваются данными, используя сертификаты, подписанные удостоверяющим центром.

Запуск сервера

Для того чтобы организовать работу сервера — нам понадобится следующее:

1. Java 11
2. Maven 3.5.0
3. Eclipse, Intellij IDEA (или любой другой текстовой редактор вроде VIM)
4. Доступ к терминалу
5. Копия этого проекта

Если вы хотите приступить к экспериментам и при этом ничего не устанавливать — можете

вышеупомянутый проект в онлайновой среде разработки Gitpod.

В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.

Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.

git checkout tags/java-8-compatible

При работе с этой версией проекта рекомендовано следовать инструкциям, подготовленным специально для него. Найти их можно

Сервер можно привести в рабочее состояние, вызвав метод main класса App или выполнив следующую команду в корневой директории проекта:

cd server/ && mvn spring-boot:run

Вот команда, рассчитанная на Maven-обёртку:

cd server-with-spring-boot/ && ./../mvnw spring-boot:run

Создание удостоверяющего центра

Обычно работают с уже существующими удостоверяющими центрами, которым, для подписи, нужно передавать сертификаты. Здесь же мы создадим собственный удостоверяющий центр и подпишем с его помощью сертификаты клиента и сервера. Для создания удостоверяющего центра воспользуемся такой командой:

keytool -v -genkeypair -dname "CN=Root-CA,OU=Certificate Authority,O=Thunderberry,C=NL" -keystore root-ca/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias root-ca -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,keyCertSign -ext BasicConstraints=ca:true,PathLen:3

Ещё можно воспользоваться

удостоверяющим центром.

.1. Администрирование новой копии WebSphere MQ

Для настройки только что установленных копий WebSphere MQ, а также для создания, запуска и остановки менеджеров очередей пользователь должен войти в систему на машине, где установлен WebSphere MQ.

При этом пользователь получает возможность исполнения управляющих команд в Microsoft Windows и UNIX, команд CL на серверах IBM Eserver iSeries, а также исполнения команд для управления подсистемами менеджеров очередей в z/OS. В этой книге такие пользователи называются администраторами.

Администраторы также обслуживают установленные копии WebSphere MQ и менеджеры очередей. Например, они регулярно анализируют журналы ошибок менеджеров очередей, работающих на вверенной им машине, а также выполняют проверки на FFST.

Примечание. Команда runmqsc – управляющая команда WebSphere MQ. В Windows, UNIX и iSeries только пользователи, авторизованные как администраторы WebSphere MQ, могут исполнять команды MQSC, адресованные непосредственно менеджерам очередей.

Способы ограничения доступа к этим операциям в WebSphere MQ зависят от платформы.

.2. Предоставление доступа к ресурсам менеджеров очередей

Модель защиты WebSphere MQ основана на конфигурировании профилей доступа для отдельных объектов и групп объектов WebSphere MQ.

Объекты WebSphere MQ представляют все ресурсы, принадлежащие менеджеру очередей и управляемые им; о некоторых из этих ресурсов рассказывается ниже. Например, объекты WebSphere MQ служат для настройки очередей в составе менеджера очередей, а также каналов, управляющих сетевым взаимодействием с данным менеджером очередей.

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

.2.1. Object Authority Manager (OAM)

В Windows, UNIX и iSeries у каждого менеджера очередей имеется компонент под названием Object Authority Manager (OAM). Он проверяет у всех сущностей, подключенных к менеджеру очередей и пытающихся выполнить какое-либо действие над объектами WebSphere MQ, наличие соответствующих полномочий.

Сущности различаются по идентификаторам пользователя операционной системы. У приложений, выполняющихся на той же машине, это реальный идентификатор пользования, который есть у каждого приложения (а не действующий идентификатор пользователя, как в UNIX).

.2.2. Полномочия для объектов в WebSphere MQ для z/OS

Проверка полномочий для объектов WebSphere MQ для z/OS выполняется внешними по отношению к WebSphere MQ средствами – при помощи RACF.

Этот механизм описан выше, в
“Защита инфраструктуры WebSphere MQ”
. В этом случае проверка полномочий основана на профилях RACF для отдельных объектов, а не на полномочиях OAM.

Это может быть индивидуальный профиль менеджера очередей либо разделяемый профиль менеджеров группы с разделением очередей (queue sharing group). Различные операции над объектами WebSphere MQ, представляющими менеджеры очередей, требуют различных уровней доступа RACF.

Подробнее об этом см. в разделе “Setting up security” руководства WebSphere MQ для z/OS V6.0 System Setup Guide, SC34-6583.

.3. Установка контекста идентификационных данных клиентских приложений

Установку контекста идентификационных данных (identity context) проще выполнить для приложений, работающих на одной машине с менеджером очередей и подключающихся к нему с использованием связывания. В этом случае менеджер очередей может считать идентификатор пользователя ОС, под которым работает приложение, подлинным, а правильность аутентификации OAM будет обеспечиваться администрированием системных учетных записей пользователей.

Однако при запуске слушателя менеджер очередей получает идентификационные данные для работы в сети. Через него возможно подключение к менеджеру очередей клиентских приложений.

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

.3.1. Процедура установки идентификационных данных в WebSphere MQ по умолчанию

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

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

.4. Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) – это промышленный стандарт технологий защиты конфиденциальных данных при передаче по публичным сетям и проверки подлинности контекста идентификационных данных.

В основе SSL лежит ряд фундаментальных понятий: симметричная и асимметричная криптография, дайджест сообщений, цифровая подпись и цифровой сертификат, CipherSuite и центры сертификации. Эти понятия существуют во всех реализациях SSL.

Разъяснение этих понятий приводится во введении к руководству WebSphere MQ Security, SC34-6588.

.4.1. Поддержка SSL в WebSphere MQ

WebSphere MQ позволяет защищать при помощи SSL любые типы каналов: распределенные и кластерные каналы передачи сообщений, а также клиентские каналы.

SSL применяют для проверки подлинности удостоверений удаленных приложений и менеджеров очередей.

SSL также применяют для обеспечения конфиденциальности и целостности данных при передаче через каналы связи.

.4.2. CipherSpec

Чтобы защитить канал с помощью SSL, необходимо занести строку CipherSpec в атрибут “SSL Cipher Specification” ( SSLCIPH ) объекта канала.

Имя CipherSpec определяет алгоритмы шифрования и вычисления кода проверки подлинности сообщения (message authentication code, MAC), которые будут использоваться для установленного канала.

Каждому значению CipherSpec в WebSphere MQ соответствует CipherSuite других поддерживающих SSL приложений, у которых в CipherSuite используется обмен ключами по протоколу RSA.

Различные значения CipherSpecs предоставляют различные уровни безопасности и быстродействия. Подробнее об этом см. в разделе “Working with CipherSpecs” руководства WebSphere MQ Security, SC34-6588.

Примечание. Для канала может быть задано только одно значение CipherSpec, которое к тому же должно соответствовать значению канала-партнера. При подключении клиентских Java-приложений или WebSphere MQ Internet Pass-Thru значение CipherSpec должно быть совместимо с параметром CipherSuite, указанным Java-клиентом или экземпляром WebSphere MQIPT.

.4.3. Протокол TLS

Transport Layer Security (TLS) версии 1.0 – протокол, сходный с SSL 3.0, с рядом дополнений, повышающих надежность защиты каналов связи.

В WebSphere MQ V6.0 использование протокола TLS задается некоторыми значениями CipherSpec, подробнее об этом см. в разделе “Transport Layer Security (TLS) concepts” руководства WebSphere MQ Security, SC34-6588.

Примечание. Все сказанное в следующих разделах этой главы про SSL верно и для TLS.

.4.4. Обязательная и необязательная SSL-аутентификация клиентов

В SSL-взаимодействии вызывающая сторона традиционно называется SSL-клиентом, а отвечающая – SSL-сервером.

Во время первоначального SSL-взаимодействия (handshake) проверяется подлинность SSL-сервера, но не SSL-клиента. Так, при подключении браузера к сайту Интернет-магазина подлинность сайта проверяется с использованием цифрового сертификата, тогда как браузеру предъявлять свой сертификат, как правило, не обязательно.

В каждой допустимой паре каналов в WebSphere MQ один из MCA играет роль SSL-клиента, а другой MCA – SSL-сервера. При этом receiver-канал и канал серверного подключения являются SSL-серверами.

Объект канала на стороне SSL-сервера можно настроить так, чтобы он запрашивал у SSL-клиента действительный сертификат либо позволял ему предъявлять сертификат по желанию. Это делается при помощи атрибута “SSL Client Authentication” ( SSLCAUTH ).

.4.6. Администрирование хранилищ сертификатов WebSphere MQ

Подробно администрирование сертификатов освещается в разделе “Working with WebSphere MQ SSL support” руководства WebSphere MQ Security, SC34-6588. В число административных задач управления сертификатами входит:

.4.7. Клиентские приложения WebSphere MQ

Администрирование хранилища сертификатов клиентских приложений, написанных на C и C , во многом сходно с таковым для менеджера очередей.

Эти хранилища имеют одинаковый формат и административный интерфейс. Переменная окружения MQSSLKEYR определяет расположение хранилища и используется так же, как атрибут SSLKEYRменеджера очередей.

О требованиях к формату метки (понятного имени) персональных сертификатов, содержащихся в хранилищах, см. в разделах “Setting up SSL communications” и “Working with the Secure Sockets Layer (SSL) on UNIX and Windows systems” руководства WebSphere MQ Security, SC34-6588.

Чтобы настроить CipherSpec для канала при подключении к менеджеру очередей, используют таблицу определений клиентских каналов (CCDT).

Альтернативный вариант – явно указать расположение хранилища ключей и CipherSpec. Это делается путем добавления структур MQCD и MQSCO к структуре MQCNO, передаваемой при вызове MQCONNX (см. руководство WebSphere MQ Application Programming Reference, SC34-6596).

.4.8. Доступ клиентских Java-приложений к WebSphere MQ

Java-приложения могут получать доступ к инфраструктуре WebSphere MQ как клиенты через каналы, защищенные SSL. В число этих приложений входят WebSphere MQ Explorer и приложения, исполняемые сервером приложений WebSphere.

В этих случаях клиентские MCA используют одну из реализаций Java Secure Sockets Extension (JSSE) для SSL-аутентификации у менеджера очередей, подробнее см. в разделе “Secure Sockets Layer (SSL) support” руководства WebSphere MQ Using Java, SC34-6591.

.4.9. SSL и WebSphere MQ Explorer

WebSphere MQ Explorer подключается к менеджерам очередей как клиентское Java-приложение.

Настроить доступ к JSSE KeyStore и TrustStore можно в секции SSL Client Certificate Stores окна WebSphere MQ Preferences (
рис.
11.1).

Отправка приветствия серверу (без шифрования)

Сейчас сервер работает на порте, используемом по умолчанию (8080) без шифрования. С помощью следующей команды, задействующей

curl

, можно обратиться к конечной точке

hello

Создание файла запроса на подпись сертификата

Для того чтобы подписать сертификат — нужен .csr-файл (Certificate Signing Request, файл запроса на подпись сертификата). Создать его можно с помощью особой команды.

Вот её вариант для сервера:

keytool -v -certreq -file shared-server-resources/src/main/resources/server.csr -keystore shared-server-resources/src/main/resources/identity.jks -alias server -keypass secret -storepass secret -keyalg rsa

Вот — эта команда для клиента:

keytool -v -certreq -file client/src/test/resources/client.csr -keystore client/src/test/resources/identity.jks -alias client -keypass secret -storepass secret -keyalg rsa

Такой файл нужен удостоверяющему центру для подписи сертификата. Следующий шаг нашей работы заключается в подписании сертификата.

Подписание сертификата с помощью запроса на подпись сертификата

Вот соответствующая команда для клиента:

keytool -v -gencert -infile client/src/test/resources/client.csr -outfile client/src/test/resources/client-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Вот команда для сервера:

keytool -v -gencert -infile shared-server-resources/src/main/resources/server.csr -outfile shared-server-resources/src/main/resources/server-signed.cer -keystore root-ca/identity.jks -storepass secret -alias root-ca -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth -ext SubjectAlternativeName:c=DNS:localhost,IP:127.0.0.1

Аутентификация клиента (двусторонний TLS)

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

client-auth

, сообщив серверу о том, что ему нужно проверять клиентов.

Приведём файл сервера application.yml к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    client-auth: need

Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:

keytool -v -genkeypair -dname "CN=Suleyman,OU=Altindag,O=Altindag,C=NL" -keystore client/src/test/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias client -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

keytool -v -exportcert -file client/src/test/resources/client.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret -rfc

Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

keytool -v -importcert -file client/src/test/resources/client.cer -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

Мы создали для клиента дополнительное хранилище ключей, но клиент об этом не знает. Сообщим ему сведения об этом хранилище. Кроме того, клиенту нужно сообщить о том, что включена двусторонняя аутентификация.

Приведём файл application.yml клиента к такому виду:

client:
  ssl:
    one-way-authentication-enabled: false
    two-way-authentication-enabled: true
    key-store: identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: truststore.jks
    trust-store-password: secret

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл

application.yml

к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: classpath:truststore.jks
    trust-store-password: secret
    client-auth: need

Если снова запустить клиент — можно будет убедиться в том, что тест завершается успешно, и что клиент получает данные от сервера в защищённом виде.

Примите поздравления! Только что вы настроили двусторонний TLS!

Замена неподписанного сертификата подписанным

В хранилище идентификационных данных сервера и клиента всё ещё хранится неподписанный сертификат. Сейчас можно заменить его на подписанный. У инструмента

keytool

есть одна не вполне понятная особенность. А именно — он не позволяет напрямую импортировать в хранилище подписанный сертификат. Если попытаться это сделать — будет выведено сообщение об ошибке. Сертификат, подписанный удостоверяющим центром, должен быть представлен в файле

identity.jks

Экспортируем подписанный сертификат:

keytool -v -exportcert -file root-ca/root-ca.pem -alias root-ca -keystore root-ca/identity.jks -storepass secret -rfc

Выполним на клиенте следующие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file client/src/test/resources/client-signed.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore client/src/test/resources/identity.jks -storepass secret

На сервере выполним такие команды:

keytool -v -importcert -file root-ca/root-ca.pem -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret -noprompt
keytool -v -importcert -file shared-server-resources/src/main/resources/server-signed.cer -alias server -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret
keytool -v -delete -alias root-ca -keystore shared-server-resources/src/main/resources/identity.jks -storepass secret

Установление двустороннего TLS-соединения с использованием доверенного удостоверяющего центра

Есть и другой способ организации двусторонней аутентификации. Он основан на использовании доверенного удостоверяющего центра. У такого подхода есть сильные и слабые стороны.

Сильные стороны:

Слабые стороны:

Рассмотрим пошаговый план действий по установлению двустороннего TLS-соединения с использованием доверенного удостоверяющего центра.

Автоматизация различных подходов к аутентификации

Всё, о чём мы говорили выше, можно автоматизировать с помощью скриптов, которые находятся в папке

рассматриваемого нами проекта. Для запуска скриптов можете воспользоваться следующими командами:

Криптографическая методология mqsecure

Появление продукта MQSecureTM обусловлено отсутствием механизмов SSL в более ранних чем 5.3 версиях WebSphere MQ и необходимостью более глубокого уровня шифрования (уровня приложений) и, кроме этого, усилением защиты на уровне связей.

Ведь после SSL “рукопожатия” возможна подмена идентификатора пользователя без указания пароля и проблема безопасности опять становится актуальной. Кроме этого, удаленное администрирование дает злоумышленнику возможность остановки каналов и просмотра сообщений в очереди, снятие SSL защиты и т.п.

Основу MQSecure составляет криптографическая методология RSA, включающая крупноразмерные открытый/секретный ключи, цифровую подпись сообщений для обеспечения неизменности, аутентификации и подлинности сообщений.

Распространение открытых ключей использует концепцию цифровых сертификатов, в которой ключи посылаются только истинным аутентифицированным источникам. Для шифрования используются различные алгоритмы, начиная от AES (наиболее сильный), далее RC6, RC5, RC4, TDES и заканчивая RC2 (наиболее слабый).

Для защиты на уровне связей используются Channel – Exit программы, как и в SSL. При этом аутентификация пользователя осуществляется для каждого сообщения.

MQSecure поддерживает различные полезные опции для разработчиков: прямые и непрямые WebSphere MQ обращения, машинный уровень аутентификации, аутентификацию пользователей, доступ к групповой/ролевой аутентификации. Таким образом, MQSecure обеспечивает сквозную безопасность.

Безопасность на уровне связей предполагает цифровую подпись и шифрование каждого сообщения. Если сообщение на принимающей стороне воспринимается как недействительное, то оно попадает в очередь недоставленных сообщений (Dead letter queue) или в специальную очередь недействительных сообщений MQSecure, где оно хранится в первозданном зашифрованном виде для анализа, а не в модифицированном виде для Dead letter queue.

Если сообщение воспринимается как законное и действительное, то оно помещается в очередь назначения в первозданном виде для дальнейшей обработки приложением. Во время нахождения сообщения в очереди существует возможность при наличии внутренних администраторов-злоумышленников корпоративной сети “перехватить” сообщение.

База данных – источник => WebSphere MQ => База данных – приемник

обеспечено криптографической защитой. Кроме того, сообщение нельзя посмотреть в очереди отправления или в очереди приема – там оно уже зашифровано! Защиту на уровне приложений целесообразно закладывать на этапе проектирования приложений. Модифицировать работающие программы, как известно, занятие малоприятное.

Полномочия oam

Любому действию, которое может быть выполнено над объектом, соответствуют полномочия, которые можно предоставить либо отозвать с помощью OAM. Сущности, подключенные к менеджеру очередей, могут выполнять следующие действия над объектами WebSphere MQ.

• Подключение к менеджерам очередей.

  Существует объект WebSphere MQ, представляющий менеджер очередей. Чтобы подключиться к менеджеру очередей, сущность прежде должна получить полномочия на подключение к данному объекту менеджера очередей.

• Операции с интерфейсом очередей сообщений ( message queue interface, MQI ).

  Любое действие, программно выполняемое над менеджером очередей, независимо от используемого API, соответствует одной или нескольким операциям MQI, например MQPUT, MQGET, MQINQ и MQSET.

  Интерфейс MQI перед обращением к ресурсам требует выполнения операции MQOPEN. Чаще всего MQOPEN применяют для того, чтобы открыть очередь перед размещением и извлечением из нее сообщений.

  Именно во время вызова MQOPEN компонент OAM проверяет наличие полномочий на выполнение операций, запрошенных при вызове MQOPEN. Каждой из возможных операций соответствуют полномочия, обслуживаемые OAM, а именно разрешения на извлечение ( get ), добавление ( put ), просмотр ( browse ), запрос ( inquire ) и установку ( set ). После вызова MQOPEN приложению разрешено выполнять лишь операции MQI, авторизованные во время вызова MQOPEN.

  Примечание. Авторизация занимает некоторое время, поэтому после вызова MQOPEN рекомендуется выполнять несколько операций put/get, а не вызывать MQOPEN и MQCLOSE после каждой операции. То же верно для вызова MQPUT1, который соответствует операциям MQOPEN, MQPUT и MQCLOSE.

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

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

  В табл. 6.1 дана сводка объектов, для которых выполняется проверка полномочий при открытии очереди для размещения сообщений.

  Примечание. Чтобы получить полномочия для размещения сообщений в любой из общих очередей кластера менеджеров очередей, приложение может получить полномочие на добавление в отношении очереди SYSTEM.CLUSTER.TRANSMIT.QUEUE, обслуживаемой менеджером, к которому это приложение подключается. Больше возможностей по управлению доступом можно получить следующим образом. Определите объекты модельных очередей, в атрибуте “target queue” ( TARGQ ) которых указаны имена общих очередей кластера. Далее можно предоставлять полномочия только для добавления сообщений в отношении этих объектов модельных очередей.

• Выполнение действий в контексте другого пользователя.

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

  Примером может быть служба, которая переносит идентификационные данные из сообщения-запроса в сообщение-ответ.

  Если приложению требуется возможность выполнять эти операции, оно должно заявить об этом при вызове MQOPEN для очереди. В WebSphere MQ имеется набор полномочий, соответствующих параметрам вызова MQOPEN: altusr, passid, passall, setid, setall.

  Подробнее об этом см. в разделе “MQOPEN – Open object” руководства WebSphere MQ Application Programming Reference, SC34-6596.

• Администрирование объектов WebSphere MQ.

  Только пользователи, назначенные администраторами WebSphere MQ, могут непосредственно администрировать менеджеры очередей с использованием управляющих команд WebSphere MQ и команд CL, в том числе исполнять команды MQSC с помощью runmqsc, подробнее об этом см. в
  “Защита инфраструктуры WebSphere MQ”
  .

  Однако WebSphere MQ допускает администрирование менеджеров очередей другими пользователями, которые могут использовать WebSphere MQ Explorer либо передавать команды PCF непосредственно командному серверу менеджера очередей.

  Примечание. Командный сервер по умолчанию запускается для менеджеров очередей, созданных в WebSphere MQ V6.0 на любой платформе, кроме z/OS.

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

  OAM поддерживает ряд административных полномочий для тонкой настройки администрирования объектов пользователями.

  • Create ( crt ) и delete ( dlt ): назначаются в отношении некоторого типа объектов, позволяют, соответственно, создавать и удалять любые объекты этого типа.
  • Display ( dis ) и change ( chg ): назначаются в отношении отдельных объектов, позволяют отображать и модифицировать атрибуты объекта, для которого они назначены;
  • Clear ( clr ), ping ( ping ), control ( ctrl ) и control-extended ( ctrlx ): назначаются в отношении отдельных объектов соответствующего типа; позволяют выполнять над объектом некоторые операции по управлению. Например, полномочие clear ( clr ) позволяет очищать очередь, control ( ctrl ) – запускать и останавливать каналы, а control-extended ( ctrlx ) — выполнять сброс (reset) или разрешение (resolve) для каналов.

Работа с websphere mq через интернет/интранет

Работа с WebSphere MQ в Интранет возможна при помощи Internet Explorer почти так же, как и с WebSphere MQ Explorer. Читатель может легко настроить работу с WebSphere MQ в интранет через Internet Explorer на основе следующих простых правил:

В корпоративных системах работа через Интернет, в отличие от интранет, требует обязательной защиты от внешних посягательств, например, такими средствами как шифрование данных через SSL, демилитаризованная зона ( Demiliatarized Zone – DMZ), FireWall.

Поэтому для работы с WebSphere MQ клиентом и такими средствами защиты понадобится установить с сайта ИБМ свободно распространяемый SupportPacs MS81 – WebSphere MQ internet pass-thru ( MQIPT ):

Шаг 1 – создание менеджеров очередей qm1 и qm2

Создается менеджер QM1 с портом для listener 1515 и объектами:

Создается менеджер QM2 с портом для listener 1516 и объектами:

Шаг 3 – проверка инсталляции сертификата

После того как был инсталлирован сертификат, можно удостовериться, что это сертификат от GlobalSign. В Microsoft Internet Explorer необходимо перейти в пункт меню “Tools”, выбрать “Internet options”, нажать на закладку “Content” и еще раз нажать на “Certificates”.

Шаг 5 – назначение сертификата менеджеру очередей qm1

Можно увидеть множество сертификатов в хранилище менеджера очередей. Необходимо назначить менеджеру только что введенный сертификат, чтобы использовать его во время “SSL рукопожатия”. Последовательность действий следующая.

1. Нажать Start, Programs, IBM Websphere MQ, WebSphere MQ Services.
2. Нажать правой кнопкой на менеджере очередей (в данном случае, QM1 ).
3. Выбрать All tasks и затем Manage SSL Certificates.
4. Выбрать наш сертификат и нажать кнопку Assign (назначить). Это откроет диалог “Назначение сертификата менеджеру очередей” (рис.13.6).
5. Выбрать наш сертификат и нажать Assign.
6. Можно увидеть в окне сертификатов помеченную иконку нашего сертификата (рис.13.7). Менеджер очередей будет посылать этот сертификат во время “SSL рукопожатия”. Нажать OK.

Когда QM1 посылает зашифрованный сертификатQM2, QM2 необходима авторизация сертификата для аутентификации QM1. Это делается на следующем шаге.

Шаг 6 – добавление ssl- сертификата в хранилище сертификатов менеджера qm2

Перед тем как добавить сертификат в QM2, необходимо знать какой сертификат добавляется.

Для этого следует:

1. Открыть Internet Explorer
2. Перейти к Tools, Internet Options, выбрать Content tab, нажать на Certificates.
3. Сделать двойной клик на нашем сертификате, затем выбрать закладку Certification Path. Можно увидеть путь сертификации нашего сертификата. В данном случае это:

   GlobalSign Root CA

4. Запомнить это и нажать последовательно OK, Close, OK.

Теперь необходимо добавить эти три сертификата в QM2. Для этого нужно сделать:

1. Нажать кнопки Start, Programs, IBM Websphere MQ, WebSphere MQ Services.
2. Нажать правую кнопку на QM2.
3. Выбрать All tasks, Manage SSL Certificates …
4. Нажать на Add. Это покажет список всех сертификатов в Windows.
5. Изменить значение Certificate Store с All на ROOT.
6. Выбрать GlobalSign Root CA и нажать на Add (рис.13.8). Это добавит сертификат и вернет нас назад к Менеджеру Сертификатов.
7. Нажать Add снова.
8. Изменить значение Certificate Store на Certification Authority (CA)
9. Выбрать оба класса (нажав CTRL) GlobalSign Primary Class 1 CA и GlobalSign PersonalSign Class 1 CA, как это было определено в начале шага 6 (рис.13.9).
10. Нажать ADD, OK.

Шаг 7 – получение, добавление и назначение ssl сертификата менеджеру очередей qm2

1. Повторить Шаг 2 и Шаг 3 для получения SSL сертификата для QM2.
2. Поскольку первый сертификат уже добавлен к WebSphere MQ серверу, можно добавить последовательно сертификаты, используя графический интерфейс вместо командной строки.
3. Нажать Start, Programs, IBM Websphere MQ, WebSphere MQ Services.
4. Нажать правой кнопкой на менеджер очередей (в данном случае, QM2 ).
5. Выбрать All tasks и далее Manage SSL Certificates.
6. Нажать на Add. Это покажет список всех сертификатов Windows.
7. Изменить наше хранилище сертификатов ( Certificate Store ) с All на MY (текущий пользователь).
8. Должен быть виден сертификат (рис.13.10), присланный на наш e-mail адрес GlobalSign Class 1 CA. Проверить по серийному номеру, что будет выбран новый сертификат, а не один из тех, что уже назначен для QM1. QM1 уже имеет инсталлированный сертификат, проверить его серийный номер для выбора правильного сертификата для использования в QM2.
9. Выбрать сертификат, присланный на наш e-mail адрес, и нажать Add. Это добавит сертификат в хранилище сертификатов менеджера очередей и его можно будет увидеть в списке.
10. Повторить шаг 5 для назначения сертификатаQM2.
11. Как и раньше, повторить шаг 6 для добавления SSL- сертификата в хранилище сертификатов менеджера, на этот раз в QM1.

Шаг 8 – настройка ssl – свойств для каналов websphere mq

1. Для каждого канала QM1.QM2 и QM2.QM1 в WebSphere MQ Explorer перейти на свойства и нажать закладку SSL для отправляющего и принимающего каналов.
2. На канале-отправителе в свойствах выбрать закладку SSL и в ней выбрать, например, TRIPLE_DES_SHA_US из выпадающего меню шифров (рис.13.11). Нажать OK.
3. На канале-получателе в свойствах выбрать закладку SSL и в ней выбрать TRIPLE_DES_SHA_US из выпадающего меню шифров. Отметить значок “Всегда идентифицировать сторону, инициирующую соединение”. Нажать OK.
4. Стартовать канал-отправитель и нажать кнопку Обновить (Refresh). Статус канала должен быть running.

Шаг 9 – тестирование

Для тестирования можно остановить каналы, убрать в одном из них настройку SSL (CipherSpec установить в none) и попробовать стартовать каналы. Успешного старта отправляющего канала не произойдет, и он будет оставаться в состоянии retry.

amqsput TO.QM2 QM1

Если сообщение передано успешно, то тест настройки SSL соединения следует считать выполненным успешно.

Для проверки шифрования в канале после отправки сообщения нужна специальная программа-перехватчик сообщений. Ведь в очередях на отправку и прием сообщения хранятся в незашифрованном виде. Такая программа может быть написана на C или Java как channel-exit программа для перехвата сообщений по порту 1515 для QM1 и по порту 1516 для QM2.

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

Заключительные замечания.

Предоставление, отзыв и отображение полномочий oam

WebSphere MQ поддерживает ряд управляющих команд, контролирующих атрибуты индивидуальных объектов и их групп.