Тема Websphere MQ и SSL

Pub/Sub
До версии 7 WMQ функция Pub/Sub была доступна либо как отдельный компонент WMQ, либо как часть функциональных возможностей WebSphere Message Broker. Теперь в v7 pub/sub является неотъемлемой частью WMQ и обеспечивает безопасность на уровне тем. Существует определенное количество публикаций и подписок, которые происходят только потому, что теперь они встроены в WMQ как нативные функции.

Еще одним фактором, влияющим на популярность WMQ pub/sub, является то, что все больше людей знакомятся с ним через WMQ File Transfer Edition. WMQ FTE делает состояние передачи файлов доступным в виде публикаций, и многие люди, использующие этот продукт, пишут приложения, которые отслеживают эти темы, чтобы обеспечить различные пользовательские функции. Как только они начинают использовать pub/sub, многие из этих магазинов начинают видеть для него другие применения.

Pub/Sub также решает некоторые распространенные проблемы с обменом сообщениями, такие как приложение, которое в настоящее время записывает в очередь, и появляется новое требование, чтобы получить копию этого сообщения другому потребителю. До версии 7 переключение приложения с записи в очередь на запись в тему было несколько инвазивным и требовало изменений конфигурации для приложений JMS или изменений кода для других типов кода. Самым простым способом решения проблемы был перехват сообщения приложением или выходом, записывающим копии в две или более очередей. Начиная с версии 7, приложение, написанное для очередей, может иметь псевдоним для темы. Производитель по-прежнему думает, что пишет в очередь, но вместо этого WMQ публикует сообщения в тему. Затем потребители могут либо подписаться напрямую, либо, в случае устаревшего кода, для которого требуется очередь, административная подписка может вызвать доставку сообщений по теме в очередь. Я вижу, что pub/sub активно используют такие требования.

Есть также случаи, когда pub/sub является подходящим решением и используется только по этой причине. В прошлом требования к отдельным компонентам, административным навыкам или лицензии WMB были барьерами для внедрения, из-за которых определенная часть приложений публикации/подписки была переработана как точка-точка. С публикацией/подпиской, встроенной в WMQ, эти барьеры устраняются или, по крайней мере, значительно уменьшаются, что приводит к большему освоению просто потому, что это правильная архитектура для решения проблемы.

В целом, я бы сказал, что WMQ pub/sub стал мейнстримом с v7. Поскольку в сентябре 2011 года было объявлено об окончании срока службы версии 6, в этом году произойдет массовый переход на версию 7, что в результате приведет к еще большему внедрению pub/sub.

SSL/TLS
Что касается SSL, безопасность WMQ приближается к основному уровню. Я бы не сказал, что SSL является нормой — пока — но за последние два-три года он пользуется таким спросом, что мой Занятия WMQ Hands-On Security Lab на IMPACT и европейских технических конференциях WebSphere вызвали переизбыток посетителей. Я недавно написал...

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

Хотя каналы SSL (фактически TLS) шифруют, они также аутентифицируют. Поскольку все больше людей понимают, что им необходимо аутентифицировать соединения WMQ в «доверенной» внутренней сети, SSL стал распространенным методом достижения этого. Конечно, также растет потребность в службах конфиденциальности (шифрования) и целостности на каналах WMQ как для внутренних, так и для внешних подключений, и это также способствует внедрению каналов WMQ SSL.

Теперь, когда SSL стал более распространенным, есть ряд второстепенных проблем, которые возникают, когда люди не полностью понимают безопасность WMQ. Тот факт, что теперь это общие темы на списке WMQ и на < href="http://mqseries.net" rel="noreferrer">MQSeries.net свидетельствует об уровне внедрения SSL. Некоторые из этих второстепенных проблем включают в себя включение неиспользуемых корневых сертификатов центра сертификации в хранилище ключей QMgr или отсутствие настроек канала QMgr, таких как SSLPEER (который фильтрует соединения по различающемуся имени) или MCAUSER (который сопоставляет авторизацию с определенной учетной записью пользователя). Часто люди включают SSL, но упускают из виду одну или несколько других настроек и не достигают уровня безопасности, на который рассчитывали. Поскольку вы должны были включить SSL, чтобы эти вещи представляли проблему, это, как говорит мой друг, «проблема роскоши». Гораздо лучше иметь проблемы с настройками SSLPEER, чем вообще не применять SSL.

Подводя итог...
Итак, я полагаю, что краткий ответ на оба этих вопроса заключается в том, что использование pub/sub и SSL в WMQ довольно распространено. Оба сейчас находятся на резком подъеме, и если бы я писал новые приложения, я бы определенно использовал SSL и без колебаний использовал бы WMQ pub/sub там, где это требуется.