Компания IBM
Опубликован: 10.06.2008 | Доступ: свободный | Студентов: 732 / 55 | Оценка: 4.18 / 4.00 | Длительность: 26:27:00
Специальности: Системный архитектор
Лекция 11:

Защита инфраструктуры WebSphere MQ

< Лекция 10 || Лекция 11: 12 || Лекция 12 >

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

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

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

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

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

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

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

Примечание. При подключении к удаленному менеджеру очередей клиентский MCA может передавать по каналу идентификатор, отличный от идентификатора на удаленной машине. Например, при подключении к UNIX-машинам передаются первые 12 символов в нижнем регистре идентификатора пользователя, под которым работает приложение. Так, вместо идентификатора Administrator менеджеру очередей в UNIX передается строка admin. Поэтому на машине, где работает менеджер очередей, должен существовать авторизованный идентификатор admin, иначе попытка подключения закончится неудачно.

Учтите, что существуют также стандартные учетные записи пользователя, такие как mqm, и стандартные каналы, например SYSTEM.DEF.SVRCONN. Удаленные приложения могут использовать их для подключения к менеджеру очередей, у которого есть слушатель, привязанный к доступной сети.

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

11.3.2. Идентификатор пользователя MCA

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

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

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

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

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

Само по себе применение идентификатора пользователя MCA не всегда гарантирует безопасность каналов связи с менеджером очередей. В этих обстоятельствах защита контекста идентификационных данных и конфиденциальности подключений осуществляется с использованием протоколов Secure Sockets Layer (SSL) и Transport Layer Security (TLS).

11.4. Secure Sockets Layer (SSL)

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

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

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

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

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

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

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

11.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 MQ IPT.

11.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.

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

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

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

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

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

11.4.5. Хранилище сертификатов менеджера очередей

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

Атрибут "SSL Key Repository" ( SSLKEYR ) объекта менеджера очередей идентифицирует хранилище ключей данного менеджера. Подробнее об этом см. в разделе "ALTER QMGR" руководства WebSphere MQ Script (MQSC) Command Reference, SC34-6597.

Менеджер очередей определяет, какой из находящихся в данном хранилище сертификатов ему следует использовать в качестве персонального сертификата, с помощью метки, или понятного имени сертификата. При этом метка должна быть определена в корректном формате. Подробнее см. в разделе "Setting up SSL communications" руководства WebSphere MQ Security, SC34-6588.

Примечание. Метка, или понятное имя сертификата, идентифицирует сертификат в хранилище. Однако не путайте его с составным именем сертификата. Формат метки персональных сертификатов и закрытых ключей, полученных от ЦС в виде PKCS12-файлов, может не поддерживаться. Утилита IBM KeyMan (см. http://www.alphaworks.ibm.com/tech/keyman) позволяет скорректировать метку сертификата в PKCS12-файле перед импортом его в хранилище ключей WebSphere MQ.

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

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

  • создание хранилища ключей для менеджера очередей;
  • выпуск самоподписанных сертификатов;
  • создание запросов для ЦС;
  • получение от ЦС подписанных сертификатов;
  • добавление сертификата доверенного ЦС в хранилище;
  • импорт персонального сертификата и закрытого ключа из PKCS12-файла;
  • экспорт персонального сертификата и закрытого ключа в PKCS12-файл;
  • извлечение открытого ключа из хранилища.

Дополнительные сведения о полном наборе функций утилит командной строки IBM GSKit iKeycmd, поставляемых с WebSphere MQ для Windows и UNIX, см. в разделе "Managing keys and certificates" руководства WebSphere MQ System Administration Guide, SC34-6584.

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

11.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).

11.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.

Примечание. В JSSE для хранения ключей используется файл формата Java KeyStore (JKS), отличный от формата хранилища ключей менеджеров очередей WebSphere MQ. Однако с WebSphere MQ для Windows и UNIX поставляются утилиты KeyMan, которые служат для администрирования хранилища ключей в формате JKS. В набор KeyMan входит утилита командной строки gsk7cmd и gsk7ikm - инструмент с графическим интерфейсом пользователя (graphical user interface, GUI). Альтернатива KeyMan - утилита keytool из стандартной поставки исполняющей среды Java Runtime Environment (JRE).

Ниже вы найдете сводку операций по настройке Java-приложений для подключения с использованием SSL и стандартной реализации JSSE.

  • Укажите CipherSuite, соответствующий CipherSpec в определении канала серверного подключения, объявленного на сервере:
    • для приложений, использующих базовый Java API, CipherSuite можно указать в атрибуте sslCipherSuite объекта MQEnvironment либо в свойстве MQC.SSL_CIPHER_SUITE_PROPERTY таблицы хеш-значений, передаваемой конструктору объекта MQQueueManager. Альтернативный вариант (в WebSphere MQ V6.0) - передать конструктору объекта MQQueueManager таблицу CCDT с каналом, для которого задан соответствующий атрибут SSL Cipher Specification ( SSLCIPH );
    • для JMS-приложений CipherSuite можно указать при помощи атрибута SSLCIPHERSUITE объекта ConnectionFactory. Альтернативный вариант (в WebSphere MQ V6.0) - передать через атрибут CCDTURL объекта ConnectionFactory таблицу CCDT с каналом, для которого задан соответствующий атрибут SSL Cipher Specification ( SSLCIPH ).
  • Укажите расположение и пароль для JSSE KeyStore; в хранилище должен быть минимум один персональный сертификат с закрытым ключом. Метка этого сертификатав KeyStore не имеет значения для клиентских Java-приложений. Хранимые в KeyStore сертификаты защищены паролем, поэтому для доступа к KeyStore необходим пароль. По умолчанию параметры для доступа к JSSE KeyStore указывают с помощью следующих Java-свойств:
    javax.net.ssl.keyStore
    javax.net.ssl.keyStorePassword
  • Укажите размещение JSSE TrustStore. В TrustStore должны быть открытые сертификаты всех ЦС, которым доверяет Java-приложение. Обычно эти сертификаты хранятся в JKS-файле, не защищенном паролем, поэтому указывать пароль не требуется. TrustStore и KeyStore могут храниться в одном файле. По умолчанию параметры для доступа к JSSE TrustStore указывают с помощью следующих Java-свойств:
    javax.net.ssl.trustStore
    javax.net.ssl.trustStorePassword

11.4.9. SSL и WebSphere MQ Explorer

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

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

< Лекция 10 || Лекция 11: 12 || Лекция 12 >