Основы обеспечения безопасности WebSphere MQ

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

1. Отправка и прием сообщений WebSphere MQ должны осуществляться с проверкой подлинности пользователей (аутентификации) на основе паролей, ключей и т.п. Помещение сообщений в очередь на удаленном WebSphere MQ-менеджере не должно быть доступно "псевдоадминистратору" с собственного компьютера, подключившемуся к корпоративной транспортной системе WebSphere MQ. Нарушение этого требования ведет к риску подмены злоумышленником сообщений в транспортных потоках на ложные или фальсифицированные сообщения и финансовым потерям в крупных размерах.
2. Система обеспечения безопасности WebSphere MQ должна иметь достаточно стойкие механизмы реализации процесса аутентификации, обеспечивать работу с сертификатами, ключами длиной до 256 бит и стойкими алгоритмами шифрования. Чтение сообщений в транспортных потоках WebSphere MQ, возможность перенаправить поток и организовать сбор информации на промежуточном компьютере не должны быть доступны "псевдоадминистратору" с собственного компьютера, подключившемуся с любым паролем к удаленному менеджеру очередей транспортной системы WebSphere MQ. Нарушение этого требования ведет к риску расшифровывания сообщений, утечки финансовой и конфиденциальной информации, финансовым потерям.
3. Система обеспечения безопасности WebSphere MQ не должна понижать производительность работы транспортной системы более чем на 10%. Нарушение требования ведет к риску замедления работы КИС в целом.
4. Система обеспечения безопасности WebSphere MQ должна работать стабильно (без собственных сбоев) 24 часа в сутки при достаточно больших потоках в сети (до 100000 сообщений в сутки). Нарушение требования ведет к риску нестабильности работы КИС.

Для обеспечения безопасности WebSphere MQ, начиная с версии 5.3, IBM поставляется встроенный механизм SSL (Secure Sockets Layer). Кроме этого у IBM существует специализированный продукт для этих целей - MQSecure, разработанный еще в компании Candle до ее присоединения к IBM и работающий на всех платформах. В России появился свой продукт для этих целей: MQКрипто компании " ФакторТС", работающий под Windows с алгоритмом ГОСТ 28147-89 и ключом 256 бит.

Работа всех этих средств защиты основана на следующей концепции безопасности. Для обеспечения безопасности WebSphere MQ должны решаться задачи: идентификации и аутентификации. Идентификация означает распознавание уникального пользователя в операционной системе или в приложении, которое работает в системе. Аутентификация означает проверку того, что пользователь является именно той персоной, которой он заявляет себя в системе или приложении. Например, при входе в систему пользователь вводит идентификатор (user ID) и пароль (password). Система использует user ID для идентификации и пароль для аутентификации. Для WebSphere MQ можно привести подобные примеры идентификации и аутентификации.

1. Приложение, отправляющее сообщение, помещает в заголовок сообщения имя приложения и имя пользователя (user ID), связанного с этим приложением. Приложение, получающее сообщение, на основе этих данных производит идентификацию и аутентификацию (для надежной защиты WebSphere MQ этого недостаточно и можно легко подставить нужные данные, если знать о такой проверке).
2. Во время старта канала, канальный агент (message channel agent - MCA) может проверять аутентификацию партнера. Это взаимная аутентификация предполагает, что посылающий и принимающий канальные агенты обмениваются сообщениями и проверяют друг друга на подлинность.

Для обеспечения безопасности WebSphere MQ предлагается 2 уровня: безопасность на уровне связей и на уровне приложений. Безопасность на уровне связей обеспечивается непосредственно MCA, как показано на рис.13.1.

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

Безопасность на уровне приложений реализуется при помощи MQI обращений в приложениях, и при этом могут использоваться и другие продукты, которые поддерживают WebSphere MQ, например, MQSecure. Этот уровень безопасности называют иногда безопасность на уровне сообщений или сквозная безопасность (end-to-end security). Сквозная безопасность позволяет защитить сообщения, когда они поступают в очереди на другой менеджер и этот уровень безопасности несомненно выше, чем безопасность на уровне связей, хотя и требует дополнительных затрат на этапе разработки приложений.

Основная криптографическая терминология [23], [24], [25]. Криптографические методы защиты делятся на два класса алгоритмов: симметричный алгоритм (или алгоритм с симметричным ключом) и асимметричный алгоритм (или алгоритм с открытым ключом), проиллюстрированные на рис.13.2. Открытым ключом (public key) называют ключ для шифрования информации. Закрытым или секретным ключом (secret key) называют ключ для расшифровывания данных.

Рис. 13.1.  Обеспечение безопасности WebSphere MQ на уровне связей

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

• Производительность. Производительность алгоритмов с симметричными ключами достаточно велика.
• Стойкость. Алгоритмы с симметричными ключами очень стойкие, что делает практически невозможным процесс расшифровывания. При прочих равных условиях стойкость определяется длиной ключа. Длина ключа 40 или 56 бит (алгоритмы DES, MD5 компании RSA) обеспечивает защиту информационных потоков без финансовых рисков. При длине ключа 256 бит необходимо произвести 10 в 77 степени переборов для определения ключа.

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

• Распределение ключей. Для шифрования и расшифровывания применяется один и тот же ключ, и поэтому требуются надежные механизмы для распределения ключей.
• Масштабируемость. Единый ключ используется между отправителем и каждым получателем, и поэтому количество необходимых ключей возрастает в геометрической прогрессии. Для 10 пользователей нужно 45 ключей, а для 100 уже 499500.
• Ограниченное использование. Алгоритмы с симметричными ключами применяются только для шифрования данных и не могут быть использованы для аутентификации.

В алгоритмах с открытыми ключами применяется пара ключей: открытый ключ и секретный или личный ключ (private key), известный только его владельцу. В отличие от секретного ключа, который должен сохраняться в тайне, открытый ключ может распространяться по сети. Секретный ключ в криптографии с открытыми ключами используется для формирования электронной подписи и расшифровывания данных. Криптография с открытыми ключами обеспечивает все требования, предъявляемые к криптографическим системам. Но реализация этих алгоритмов требует больших затрат процессорного времени.

Рис. 13.2.  Симметричный и асимметричный алгоритмы

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

512 бит алгоритм шифрования слабый;

788 бит алгоритм шифрования средний;

1024 бит алгоритм шифрования сильный.

Криптография с открытыми ключами требует наличия инфраструктуры открытых ключей (PKI - Public Key Infrastructure) - неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.

Инфраструктура управления открытыми ключами - это современная система управления криптографической защитой, в том числе и в агрессивной среде, например Интернет. Задачей PKI является определение политики выпуска цифровых сертификатов, выдача их и аннулирование, хранение информации, необходимой для последующей проверки правильности сертификатов. В число приложений, поддерживающих PKI, входят: защищенная электронная почта, протоколы платежей, электронные чеки, электронный обмен информацией, защита данных в сетях с протоколом IP, электронные формы и документы с электронной цифровой подписью (ЭЦП).

Public Key Cryptography Standarts (PKCS) это стандарты криптографии с открытым ключом, разработанные компанией RSA Security. Наиболее известными стандартами PKCS являются:

• PKCS#7 - стандарт, определяющий формат и синтаксис криптографических сообщений. Электронный документ, оформленный с соблюдением требований PKCS#7 Signed, является электронным документом, содержащим электронную цифровую подпись;
• PKCS#10 - стандарт, определяющий формат и синтаксис запроса на сертификат открытого ключа подписи. Электронный документ, оформленный с соблюдением требований PKCS#10, содержит информацию о сертифицируемом открытом ключе, используемом криптографическом средстве и данные, необходимые для идентификации владельца сертифицируемого открытого ключа электронной цифровой подписи.

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

Для заверения цифрового сертификата используется ЭЦП удостоверяющего центра сертификации (CA - Certificate Authority). Исходя из функций, которые выполняет удостоверяющий центр (УЦ), его можно отнести к основным компонентам инфраструктуры открытых ключей. Применяя открытый ключ УЦ, каждый пользователь может проверить достоверность электронного сертификата, выпущенного УЦ, и обратиться к его содержимому.

Доверие к любому сертификату пользователя определяется на основе цепочки сертификатов. Начальным элементом цепочки является корневой сертификат УЦ (Root CA), хранящийся в защищенном персональном справочнике пользователя. Процедура верификации цепочки сертификатов проверяет связанность между именем владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все "правильные" цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации. Под доверенным центром понимается главный УЦ, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не дают гарантии на безопасность. Для обеспечения доверия к открытому ключу такого сертификата должны быть применены специальные способы его распространения и хранения, так как на данном открытом ключе проверяются все остальные сертификаты.

Следует отметить, что инфраструктура открытых ключей (PKI) предусматривает взаимодействие с УЦ, регистрирующим центром (RA - Registration Authority), хранилищем сертификатов, сервером восстановления ключей и конечным пользователем. УЦ применяют хранилища и каталоги сертификатов, при этом наиболее популярен облегченный протокол службы каталогов LDAP (Lightweight Directory Access Protocol).

SSL (Secure Sockets Layer) протокол обеспечивает аутентификацию, шифрование и целостность передачи информации и широко применяется для Интернет и интранет - приложений. Именно поэтому он используется для защиты сообщений в WebSphere MQ версии 5.3.

Методика работы WebSphere MQ с SSL

SSL (Secure Sockets Layer - "слой защищенных сокетов") был первоначально создан компанией Netscape, чтобы обеспечить поверх обычного протокола HTTP дополнительный защищенный "слой". Этот дополнительный слой позволяет идентифицировать стороны на основе сертификатов, осуществлять шифрование передаваемых данных и подтверждать то, что информация в процессе передачи не искажалась. В настоящее время SSL стал стандартом защиты данных, передаваемых по сетям общего пользования. SSL протокол применяет две различные схемы шифрования: асимметричную и симметричную.

Принцип работы SSL. При инициализации сеанса связи (процесс "SSL - рукопожатие" - "SSL handshake") стороны используют асимметричную схему шифрования. В этот период стороны идентифицируют друг друга по сертификату и договариваются об алгоритме и ключе шифрования, которые будут использоваться при симметричной схеме. По завершению процесса "SSL - рукопожатия" на каждой стороне имеется разовый секретный ключ (secret key), которым шифруется весь последующий трафик. Кроме этого, используя механизм электронной подписи, SSL гарантирует неизменность данных в процессе их передачи.

Более подробно описание работы с SSL можно разобрать на примере настройки WebSphere MQ SSL для двух менеджеров: QM1 (порт 1515) и QM2 (порт 1616) и двух каналов: QM2.QM1 и QM1.QM2, которые используют опцию настройки TRIPLE_DES_SHA_US.

Когда стартует канал-отправитель QM2.QM1, начинается "SSL рукопожатие":

1. QM2 запускает соединение и требует сертификат.
2. QM1 посылает сертификат, зашифрованный с помощью ключа CA.
3. QM2 проверяет цифровую подпись QM1 на сертификате. QM2 теперь знает, что QM1 это тот, кем он себя объявляет.
4. ...рукопожатие продолжается с использование секретного ключа обеими сторонами, которые используют для этого зашифрованные сообщения.

Из приведенного диалога следует, что WebSphere MQ сервер QM1 должен иметь сертификат и сервер QM2 должен уметь расшифровывать подписанный сертификат.

Вариантов получения сертификата для сервера QM1 может быть несколько:

1. можно создать самоподписанный сертификат (self-signed certificates).
2. можно иметь собственный центр сертификации.
3. можно потребовать сертификат из центра сертификации.

В тестовых целях можно получить бесплатно демонстрационный персональный сертификат из GlobalSign.com, действительный 30 дней. Есть и другие сайты для этих целей, но GlobalSign не требует регистрации. Сертификат для других, не демонстрационных целей, конечно, не будет бесплатным.

Далее методику настройки WebSphere MQ с SSL можно изложить в виде следующих шагов-рекомендаций для работы в операционной системе Windows.

Шаг 1 - Создание менеджеров очередей QM1 и QM2

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

DEFINE QLOCAL ('FROM.QM2') 
DEFINE QLOCAL ('QM1') USAGE(XMITQ)
DEFINE QLOCAL ('QM1.DLQ')
DEFINE QREMOTE ('TO.QM1')  XMITQ('QM1')  RNAME('FROM.QM2')  RQMNAME('QM1')
DEFINE CHANNEL ('QM2.QM1') CHLTYPE(RCVR)
DEFINE CHANNEL ('QM2.QM1') CHLTYPE(SDR)  XMITQ('QM1')  CONNAME('MQSERVER(1515)')
        

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

DEFINE QLOCAL ('FROM.QM1') 
DEFINE QLOCAL ('QM2')  USAGE(XMITQ)
DEFINE QLOCAL ('QM2.DLQ') 
DEFINE QREMOTE ('TO.QM1')  XMITQ('QM2')  RNAME('FROM.QM2')  RQMNAME('QM1')
DEFINE CHANNEL ('QM1.QM2') CHLTYPE(RCVR)
DEFINE CHANNEL ('QM2.QM1') CHLTYPE(SDR)  XMITQ('QM2')  CONNAME('MQSERVER(1515)')
        

Шаг 2 - Получение SSL сертификата для QM1

На сайте http://www.GlobalSign.com/ выбрать из выпадающего меню Certificates пункт Personal Certificates и затем выбрать PersonalSign Demo. Это даст экран восьми шаговой процедуре для получения сертификата (рис.13.3). Нажать на пункт "Переход на Шаг 1" и выполнить действия из таблицы ниже:

Рис. 13.3.  Процедура получения сертификата

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

После того как был инсталлирован сертификат, можно удостовериться, что это сертификат от GlobalSign. В Microsoft Internet Explorer необходимо перейти в пункт меню "Tools", выбрать "Internet options", нажать на закладку "Content" и еще раз нажать на "Certificates". После этого, откроется менеджер сертификатов и можно будет увидеть GlobalSign сертификат, предназначенный для e-mail адреса, заданного на шаге 2 (рис.13.4).

Шаг 4 - Добавление сертификата в хранилище сертификатов менеджера очередей QM1

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

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

1. C:\> amqmcert -k MY -l
2. C:\> amqmcert -a "certificate number" -m QM1

Первая команда дает список сертификатов из хранилища сертификатов операционной системы для текущего пользователя (MY). Вторая команда добавляет сертификат в хранилище сертификатов менеджера очередей. Копия экрана выполнения этих команд представлена на рис.13.5.

Рис. 13.4.  Проверка инсталляции сертификата

Рис. 13.5.  Добавление сертификата в хранилище сертификатов

Шаг 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.

Рис. 13.6.  Назначение сертификата менеджеру очередей

Рис. 13.7.  Проверка помеченной иконки сертификата

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

Шаг 6 - Добавление SSL- сертификата в хранилище сертификатов менеджера QM2

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

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

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

   GlobalSign Root CA

   • GlobalSign Primary Class 1 CA

   • GlobalSign PersonalSign Class 1 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). Это добавит сертификат и вернет нас назад к Менеджеру Сертификатов.

   
   
   Рис. 13.8.  Добавление ROOT сертификата в хранилище сертификатов QM2

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.

Рис. 13.9.  Добавление двух сертификата в хранилище сертификатов QM2

Шаг 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.

   
   
   Рис. 13.10.  Выбор сертификата для 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.

   
   
   Рис. 13.11.  Выбор алгоритма шифрования в канале

4. Стартовать канал-отправитель и нажать кнопку Обновить (Refresh). Статус канала должен быть running.

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

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

amqsput TO.QM2 QM1

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

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

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

1. Данная методика рекомендуется для практической работы под Windows. Освоив ее, читатель без труда сможет настроить SSL на UNIX, OS/390, OS400, OS/2 и др. платформах с помощью документации [24], [26] и специалистов с http://www.mqseries.net.
2. Существует альтернативный метод создания и использования самоподписанных сертификатов. Если имеется инсталлированные WebSphere Application Server и/или IBM HTTP Server, то можно сгенерировать собственный самоподписанный сертификат для такого демонстрационного примера без необходимости затребования сертификата из CA такого как GlobalSign.

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

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

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

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

• S_MQPUT (версия стандартного MQPUT для целей безопасности)
• S_MQGET (версия стандартного MQGET для целей безопасности)
• MQS_EXIT (MQ Channel - Exit программа)
• MQS_ADM (административный модуль)
• MQS_READ (фоновый модуль, который получает новый открытый ключ и помещает его в базу данных).

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

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

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

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

Работа с WebSphere MQ через Интернет/Интранет

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

• При инсталляции WebSphere MQ сервер необходимо отметить опцию для инсталляции компонентов: Web Administration Server;
• Через любой Web браузер можно подключиться к менеджеру очередей с помощью команды http://<hostname>:<port_number>, например, http://9.20.20.92:8081/ (по умолчанию порт Web Administration Server - 8081)

В корпоративных системах работа через Интернет, в отличие от интранет, требует обязательной защиты от внешних посягательств, например, такими средствами как шифрование данных через SSL, демилитаризованная зона (Demiliatarized Zone - DMZ), FireWall. Поэтому для работы с WebSphere MQ клиентом и такими средствами защиты понадобится установить с сайта ИБМ свободно распространяемый SupportPacs MS81 - WebSphere MQ internet pass-thru (MQIPT):

http://www-306.ibm.com/software/integration/support/supportpacs/category.html

MQIPT создан для подключения клиента WebSphere MQ версии 5.3 к WebSphere MQ менеджеру очередей с использованием SSL. MQIPT устанавливается на WebSphere MQ клиенте или в DMZ на WebSphere MQ сервере и работает как proxy-сервер для WebSphere MQ трафика. Типичный пример подключения MQIPT приведен на рис.13.12.

Рис. 13.12.  Схема подключения MQIPT

Эта схема показывает, как MQIPT моделирует клиента и SSL-защищенный канал. В этой схеме может использоваться любой сертификат, заверенный центром сертификации (CA). MQIPT имеет свой простой сертификат, который может быть установлен на WebSphere MQ менеджере и MQIPT в целях тестирования.

Настройка такой конфигурации состоит из следующих шагов.

1. Конфигурирование WebSphere MQ.

   На машине с WebSphere MQ сервером создается менеджер с именем, например, QM. MQIPT инсталлируется на другой машине в директорию C:\mqipt вместе с WebSphere MQ клиентом. Стандартные команды для клиента и сервера (amqsputc, amqsgetc) работают. На WebSphere MQ сервере создаются: менеджер очередей MQIPT.QM1, канал server connection с именем MQIPT.CONN.CHANNEL, локальная очередь MQIPT.LOCAL.QUEUE, TCP/IP listener для MQIPT.QM1 на порту 1414.

2. Назначение самоподписанного сертификата MQIPT для MQIPT.QM1.

   Для этого необходимо импортировать сертификат в Windows Internet Explorer: выбрать в меню "Tools" => "Content" => "Certificates" и нажать кнопку "Import". Найти сертификат на пути c:\mqipt\ssl\sslSample.pfx и ввести пароль "mqiptV1.3" (без кавычек). Выбрать "Automatically select the certicate store based on the type of certificate" и нажать "Finish". Далее следует импортировать сертификат в WebSphere MQ Explorer. На свойствах MQIPT.QM1 выбрать закладку SSL, нажать the "manage SSL certificates" и "add" - добавить. Среди сертификатов выбрать только что добавленный сертификат, подписанный "Phil Blake", и нажать "add" - добавить. После этого для нашего сертификата нажать кнопку "assign" - назначить.

3. Определение кода шифрования.

   В свойствах канала MQIPT.CONN.CHANNEL выбрать закладку SSL, из выпадающего меню выбрать RC4_MD5_EXPORT и нажать кнопку "OK".

4. Конфигурирование MQIPT.

   MQIPT должен быть сконфигурирован как SSL клиент. Для этого выбрать конфигурационный файл c:\mqipt\mqipt.conf и отредактировать его следующим образом для определения маршрута для SSL клиента:

   [route]
   ListenerPort=1415
   Destination=10.20.9.2
   DestinationPort=1414
   SSLClient=true
   SSLClientKeyRing=c:\\mqipt\\ssl\\sslSample.pfx
   SSLClientKeyRingPW=c:\\mqipt\\ssl\\sslSample.pwd
   SSLClientCipherSuite=SSL_RSA_EXPORT_WITH_RC4_40_MD5
        

   Примечание. Соответствие CipherSpec и SSLClientCipherSuite определяется таблицей:

   Вид шифрования (CipherSpec)	Набор шифров SSL (SSLClientCipherSuite)
   DES_SHA_EXPORT	SSL_RSA_WITH_DES_CBC_SHA
   DES_SHA_EXPORT1024	SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA *
   NULL_MD5	SSL_RSA_WITH_NULL_MD5
   NULL_SHA	SSL_RSA_WITH_NULL_SHA
   RC2_MD5_EXPORT	SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
   RC4_56_SHA_EXPORT1024	SSL_RSA_EXPORT1024_WITH_RC4_56_SHA *
   RC4_MD5_US	SSL_RSA_WITH_RC4_128_MD5
   RC4_MD5_EXPORT	SSL_RSA_EXPORT_WITH_RC4_40_MD5
   RC4_SHA_US	SSL_RSA_WITH_RC4_128_SHA
   TRIPLE_DES_SHA_US	SSL_RSA_WITH_3DES_EDE_CBC_SHA

   После этого активизировать MQIPT через командное окно:

   cd \mqipt\bin
   mqipt ..
        

   В командном окне появятся консольные сообщения, сообщающие об успешном старте MQIPT.

5. Конфигурирование и работа с WebSphere MQ клиент.

   Менеджер QM1 и MQIPT готовы для совместной работы. На клиенте переменная MQSERVER должна отражать IP - адрес вашего сервера и для этого установить в командном окне:

   SET MQSERVER=TEST.CONN.CHANNEL/TCP/10.20.3.1

   Теперь помещение сообщения в очередь можно сделать командой:

   amqsputc MQIPT.LOCAL.QUEUE MQIPT.QM1

   а извлечение сообщения из очереди делается командой:

   amqsgetc MQIPT.LOCAL.QUEUE MQIPT.QM1

   Конфигурирование выполнено успешно и WebSphere MQ клиент версии 5.3 может работать через SSL защиту с использованием MQIPT и Интернет.

Таким образом, MQIPT позволяет сформировать канал для создания SSL- соединения и работы через Интернет. Работа между менеджерами осуществляется также просто. MQIPT дает возможность осуществлять трассировку передачи сообщений по каналу связи.

В завершение раздела хочется отметить еще две полезные особенности WebSphere MQ: работа по выделенным каналам связи и работа через модем. По выделенным каналам, как только установится надежная TCP/IP связь, работа ничем не отличается от работы в локальной сети. Каналы стартуют как обычно, может быть на 1-2 секунды дольше, если речь идет о тысячах километров и оптоволоконных каналах связи. Сообщения движутся так же быстро, надежность доставки гарантируется. Главное, чтобы канал связи обеспечивал качественную связь, а WebSphere MQ доставит, например, котировки курсов акций со всего мира за считанные секунды.

При работе WebSphere MQ через модем необходимы, как правило, специальные программы, которые обеспечивают дозвон и устанавливают TCP/IP адресацию. После этого запускается приложение, работающее через WebSphere MQ клиента с удаленным WebSphere MQ сервером. Это наиболее типичный вариант работы, ведь, как известно, WebSphere MQ клиент IBM распространяет бесплатно через Интернет (в версии 5.3 WebSphere MQ клиент имеет объем 86Мбт и это не всегда удобно - прим. авторов). Таким образом, число клиентских приложений не ограничено по финансовым соображениям и один WebSphere MQ сервер под Windows выдерживает подключение 3 - 5 тысяч клиентов со временем обслуживания менее 1 сек. Чем этот способ лучше обычной передачи файлов через модем? WebSphere MQ гарантирует доставку, скорость, целостность передачи, средства защиты через SSL и, наконец, отлаженную технологию интеграции данных и приложений.