業界でのMQトピックの使用がどれほど一般的であるかを理解しようとしています。そして、SSLを使用したMQ?
みんなありがとう
業界でのMQトピックの使用がどれほど一般的であるかを理解しようとしています。そして、SSLを使用したMQ?
みんなありがとう
Pub / Sub
WMQのv7より前は、Pub / Subは、WMQの別個のコンポーネントとして、またはWebSphereMessageBrokerの機能の一部として使用可能でした。現在、v7ではpub / subがWMQに不可欠であり、トピックレベルのセキュリティを可能にします。ネイティブ機能としてWMQに組み込まれているという理由だけで、ある程度のpub/subの採用が行われています。
WMQ pub / subの取り込みに影響を与える別の要因は、WMQ FileTransferEditionを介してより多くの人々がそれにさらされていることです。WMQ FTEは、ファイル転送のステータスを出版物として利用できるようにします。この製品を使用する多くの人々は、これらのトピックを監視してさまざまなカスタム機能を提供するアプリケーションを作成しています。pub / subの使用を開始すると、これらのショップの多くは他の用途を見始めます。
Pub / Subは、現在キューに書き込んでいるアプリケーションや、そのメッセージのコピーを別のコンシューマーに取得するための新しい要件など、メッセージングに関するいくつかの一般的な問題も解決します。v7より前は、アプリをキューへの書き込みからトピックへの書き込みに切り替えることはやや侵襲的であり、JMSアプリの構成変更または他のタイプのコードのコード変更が必要でした。この問題に対処する最も簡単な方法は、2つ以上のキューにコピーを書き込んだアプリケーションまたは出口でメッセージをインターセプトすることでした。v7以降、キュー用に作成されたアプリケーションに、トピックのエイリアスを提供できます。プロデューサーはまだキューに書き込んでいると考えていますが、WMQは代わりにトピックにメッセージを公開しています。その後、コンシューマーは直接サブスクライブするか、キューを必要とするレガシーコードの場合は、管理サブスクリプションにより、トピックに関するメッセージがキューに配信される可能性があります。これらの種類の要件に対処するために、pub/subで多くの取り込みが見られます。
pub / subが適切なソリューションであり、その理由だけで使用される場合もあります。以前は、個別のコンポーネント、管理スキル、またはWMBライセンスの要件が採用の障壁となっていたため、pub/subアプリの特定の部分がポイントツーポイントで作り直されていました。WMQに組み込まれたpub/subを使用すると、これらの障壁が排除されるか、少なくとも大幅に削減されます。これは、目前の問題に適したアーキテクチャであるという理由だけで、より多くの取り込みにつながります。
一般的に、WMQ pub/subはv7で主流になっていると言えます。2011年9月にv6のサポート終了が発表されたため、今年はv7への大規模な移行が行われ、その結果、pub/subがさらに採用される予定です。
SSL / TLS
SSLに関しては、WMQセキュリティが主流に近づいています。SSLが標準であるとは言いませんが、まだですが、過去2、3年間、IMPACTおよびEuropeanWebSphereTechnicalカンファレンスでのWMQハンズオンセキュリティラボセッションに多くの人が参加することが十分に求められています。私は最近書いた...
「信頼できる内部ネットワーク」という用語は、ファイアウォールの外部の宛先から内部にあるネットワークの部分を区別するために造られました。しかし、この文脈で使用される「信頼できる」という用語は相対的なものです。内部ネットワークが暗黙的に信頼されていることを示すものではなく、ファイアウォールの外部のものよりも信頼されていることだけを示しています。残念ながら、この用語は文字通りに解釈されることがあります。私はクライアントに、定義上、「信頼できる内部ネットワーク」上のすべてのものを信頼していると真剣に言わせてきました。そのため、私たちはそれをそう呼んでいます。もちろん、これは事実を誇張しています。なぜなら、内部ネットワークを信頼している最も堅実な信者でさえ、サーバー、データベース、およびアプリケーションへのパスワードベースのログインを強制しているからです。したがって、内部ネットワークは信頼されています。
SSL(TLS、実際には)チャネルは暗号化されますが、認証も行います。「信頼できる」内部ネットワークでWMQ接続を認証する必要があることを認識する人が増えるにつれ、SSLはそれを実現するための一般的な方法になっています。もちろん、内部接続と外部接続の両方のWMQチャネルでのプライバシー(暗号化)および整合性サービスに対する要件も高まっており、これによりWMQSSLチャネルの採用も促進されています。
SSLがより一般的になっている現在、人々がWMQのセキュリティを完全に理解していない場合に発生する、いくつかの二次的な課題があります。これらがWMQlistserveおよびMQSeries.netで一般的なトピックになっているという事実SSL採用のレベルを証明します。これらの二次的な問題のいくつかは、QMgrのキーストアに未使用の認証局ルート証明書が含まれていること、またはSSLPEER(識別名で接続をフィルタリングする)やMCAUSER(認証を特定のユーザーアカウントにマップする)などのQMgrチャネル設定がないことです。多くの場合、SSLを有効にしますが、これらの他の設定の1つ以上を見落とし、意図したレベルのセキュリティを達成できません。これらの問題を提示するにはSSLを有効にしている必要があるため、私の友人が「贅沢な問題」と言っているようです。SSLをまったく適用しないよりも、SSLPEER設定に挑戦する方がはるかに優れています。
要約すると...
これらの質問の両方に対する簡単な答えは、WMQでのpub/subとSSLの使用が非常に一般的であるということだと思います。どちらも現在急上昇傾向にあり、新しいアプリケーションを作成する場合は、SSLを使用し、必要に応じてWMQ pub/subを使用することを躊躇しません。