Peter Crocker, Senior IT Specialist, IBM
2007年10月10日, 原文はこちら（US）
WebSphere DataPower XML セキュリティー・ゲートウェイ XS40は、WebSphere Message Broker環境に対して多数の利点を追加することが可能です。この記事では、DataPower XS40を用いて、HTTPSが提供するMessage Brokerへの接続のセキュリティーに加え、Message BrokerフローをWS-Securityを使用してセキュリティー機能強化する方法を説明します。DataPower XS40は、SOAPボディーをWS-Securityで暗号化することにより、Message Brokerに送信されるSOAPメッセージ、およびMessage Brokerで生成されるSOAPメッセージを保護します。また、XS40に追加のインテグレーション機能を備えたWebSphere DataPowerインテグレーション・アプライアンス XI50を使用することも可能です。
以下の図は、この記事で説明するシナリオを示しています。
図1 全体のシナリオ
リクエスター側のアプリケーションは、IBM® WebSphere® DataPower® XML セキュリティー・ゲートウェイ XS40（以降、「DataPower アプライアンス」と表記）と通信する際にSOAP/HTTPを使用しますが、このとき、WS-Securityに従ってメッセージ・ボディーを暗号します。さらにDataPower アプライアンスは、受信したメッセージ・ボディーを復号します。次に、このメッセージの内容は、HTTPSで保護された接続を通じて、WebSphere Message Broker（以降、「Message Broker」と表記）に渡されます。Message Brokerは、SOAPメッセージを受信すると、最後にある WebSphere MQアプリケーションのために、そのメッセージをCOBOL構造体へと変換します。このメッセージに対するレスポンスは、同様の方法で返されます。最初の構成では、DataPower アプライアンスと Message Broker間で単純なHTTPが使用されています。HTTPSを使用するための変更は、構成の第2ステージとして実行されます。
ここで説明するコンポーネントは、SOAデザイン・パターン内に配置できます。このSOAデザイン・パターンにおいて、DataPower アプライアンスは、企業を保護するDMZ内でWS-Securityを実装します。
図2 DMZ内で調整されたシナリオ
以下のセクションでは、DataPowerの構成、およびMessage BrokerがDataPowerに提供する、関連する外部の要素に焦点を当てます。
DataPower アプライアンスの構成
図3 DataPowerの構成に焦点を当てた図
WS-Security
WS-Security（US）は、SOAPメッセージングに対する機能強化を記述したものであり、メッセージの保全性、メッセージの機密性、および単一メッセージ認証を通じて、高度な保護を提供します。これらのメカニズムを使用すると、多様なセキュリティー・モデルおよび暗号化テクノロジーに対応することができます。 |
DataPower アプライアンスは、Message BrokerのHTTPリスナーに接続する静的なバックエンドを備えた、単純なXMLファイアー・ウォールで構成します。XMLファイアー・ウォールのメイン・ページを構成したら、処理ポリシーをXMLファイアー・ウォールに関連付ける前に、「ヘッダー」ページに対して追加を行う必要があります。この処理ポリシーには、WS-Securityを使用したSOAPボディーの暗号と復号を設定します。図4は、XMLファイアー・ウォールの主な構成を示しており、以下の項目が構成されています。
- 名前と要約（NameとSummary）
- サーバーのアドレスとポート（Server AddressとServer Port）
- デバイスのポート（Device Port）
- リクエストタイプとレスポンスタイプ（SOAPに設定）
図4 XMLファイアー・ウォールの構成
次のセクションの説明に従ってヘッダーを構成したら、処理ポリシーを追加します。
ヘッダー
DataPower アプライアンスは、2つのconnectionヘッダー・タグを生成します。XMLファイアー・ウォール構成ページのHeadersタブより、"Header Suppression Parameters"を追加すると、1つのconnectionヘッダーだけがDataPowerアプライアンスから送信されます。図5に示す「Headers」タブでは、connectionヘッダー・タグが"back"方向に対し抑制されています。
図5 ヘッダーの構成
処理ポリシー
処理ポリシーには、リクエスト・ルールとレスポンス・ルールがあります。リクエスト・ルールでは、リクエスト・メッセージのボディーが復号され、レスポンス・ルールでは、レスポンス・メッセージのボディーが暗号化されます。
この記事では、AliceKeyおよびBobKeyという名前の鍵を使用します。鍵はDataPowerアプライアンス上で作成することも、外部で作成したものを使用することも可能です。処理ポリシーで指定する前に、鍵および鍵のパスワードを鍵オブジェクトとして生成しておきます。リクエスト側のアプリケーションは、AliceKeyで暗号されたメッセージを送信し、DataPower アプライアンスは、BobKeyを使用してレスポンスを暗号します。
リクエスト（復号）ルール
リクエスト・ルールには、マッチング・ルールとDecryptアクションが含まれています（下図参照）。マッチング・ルールは、すべてのURLに対して受け付けるように設定しています。
図6 復号ルール
Decryptアクションは、SOAPメッセージに含まれる情報およびWS-Securityヘッダーに従ってレスポンスメッセージを復号するように構成されています。リクエスト側のアプリケーションがメッセージを暗号するときにAliceKeyを使用した場合は、DataPowerアプライアンス内で復号するときにAliceKeyが使用されます。
図7 Decryptアクション
レスポンス（暗号）ルール
レスポンス・ルールでは、その逆を実行して、下図の方向に向かうメッセージを暗号します。
図8 暗号ルール
Encryptアクションは、WS-Securityを使用してSOAPメッセージ・ボディーを暗号するように構成されており、事前定義の鍵BobKeyを使用します。
図9 Encryptアクション
秘密鍵であるBobKeyは、リクエスト側のアプリケーションが所有します。したがって、リクエスト側のアプリケーションは、DataPower アプライアンスが送信したメッセージを復号できます。
復号されたSOAP/HTTPメッセージをDataPowerアプライアンスから受信すると、Message Brokerインスタンス内で実行中のメッセージ・フローは、リクエストメッセージを固定長のCOBOL形式のメッセージに変換します。そのあと、このメッセージは、別のWebSphere MQアプリケーションによって処理されます。このメッセージは更新され、2番目のメッセージ・フローに渡されます。2番目のメッセージ・フローでは、このメッセージは、レスポンスを含むSOAP/HTTPメッセージに変換されます。
図10 Message Brokerの機能に焦点を当てた図
実行中の処理は、WebサービスのサンプルWSHOSTのものです（これは、WebSphere Message Broker V6で提供されます）。このサンプルについて詳しくは、Message Broker ToolkitのToolkitメニューで、「ヘルプ」=>「サンプル・ギャラリー」を選択してください。
図11 WebSphere Message Brokerの2つのメッセージ・フロー
最初のメッセージ・フローでは、DataPowerアプライアンスで復号された後のSOAP/HTTPリクエスト・メッセージが処理されます。メッセージ形式およびプロトコルが変換されると、出力メッセージはWebSphere MQキューに書き込まれます。WebSphere MQアプリケーションは、このメッセージを読み取って処理します。
2番目のメッセージ・フローでは、WebSphere MQアプリケーションからのWebSphere MQレスポンス・メッセージが受信され、入力メッセージの形式およびプロトコルがSOAP/HTTP応答メッセージに変換されます。2番目のメッセージ・フローで生成されたレスポンス・メッセージは、DataPower アプライアンスに渡されます。そのため、レスポンス・メッセージは、リクエスト側のアプリケーションに戻す前に暗号できます。
HTTP入力ノードのプロパティー
入力ノードのプロパティーには、このフローがリクエストを受信するように構成されたURLが示されます。「HTTPSの使用」ボックスは、チェックが外されたままになっています。このボックスは、後のセクションでセキュリティーを有効にするためにチェックされます。
WSHOSTサンプルで提供されるWebSphere MQアプリケーションは、ブローカーからのメッセージを待機しているその入力キューに対してMQGETを実行します。メッセージを受信すると、WebSphere MQアプリケーションは、そのメッセージを変更して、メッセージ・フローで読み取られるキューにレスポンスを書き込みます。
メッセージ
以下のセクションでは、システム内でDataPower アプライアンスとの間でやり取りされるメッセージを示します。下の図12は、フロー全体におけるこれらのメッセージの配置を示しています。Message BrokerとバックエンドのWebSphere MQアプリケーション間のメッセージは、示されていません。
図12 このセクションで説明するメッセージを強調した図
リクエスター側のアプリケーションからDataPower アプライアンスに送信されるメッセージ
以下に示すのは、リクエスター側のアプリケーションがDataPowerアプライアンスに送信するHTTPメッセージ・ボディーです。暗号メッセージの実際の内容は、（太字で）強調表示されており、読みやすくするために省略されています。このメッセージと後続メッセージの全内容については、この後の『ダウンロード』を参照してください。
DataPower アプライアンスからWMBに送信されるメッセージ
DataPower アプライアンスがMessage Brokerに送信するHTTPメッセージ・ボディーを以下に示します。ボディー（太字）は、SOAPリクエストを示すために復号されています。
メッセージ2. DataPower アプライアンスからMessage Brokerに送信されるメッセージ
|
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:c="http://www.brokersamplewshost.ibm.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd">
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<c:IA81CONFIN>
<MessageId>IA81CONF</MessageId>
<OrderNumber>ON4002</OrderNumber>
<ItemReference>IY4003</ItemReference>
<ItemQuantity>4</ItemQuantity>
<CustomerNumber>CY4004</CustomerNumber>
</c:IA81CONFIN>
</soapenv:Body>
</soapenv:Envelope>
|
|
Message BrokerからDataPower アプライアンスに送信されるメッセージ
Message BrokerがDataPower アプライアンスに返すHTTPメッセージ・ボディーを以下に示します。この戻りの経路では、メッセージの最後に2つの追加フィールド、DeliveryRefおよびConfirm（太字）が組み込まれます。
メッセージ3. Message BrokerからDataPowerアプライアンスに送信されるメッセージ
|
<?xml version="1.0"?>
<tns:Envelope xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:NS1="http://www.brokersamplewshost.ibm.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns:Body>
<NS1:IA81CONFOUT>
<MessageId>IA81CONF</MessageId>
<OrderNumber>ON4002</OrderNumber>
<ItemReference>IY4003</ItemReference>
<ItemQuantity>4</ItemQuantity>
<CustomerNumber>CY4004</CustomerNumber>
<DeliveryRef>JOHNCORP</DeliveryRef>
<Confirm>Y</Confirm>
</NS1:IA81CONFOUT>
</tns:Body>
</tns:Envelope>
|
|
DataPower アプライアンスがリクエスター側のアプリケーションに送信するメッセージ
DataPower アプライアンスがリクエスター側のアプリケーションに戻すHTTPメッセージ・ボディーは、DataPower アプライアンスに送信された最初のメッセージと同様のパターンに従います。異なる点は、このメッセージの内容は、戻り鍵を使用して暗号されるということです。このメッセージを復号すると、Message Brokerが送信したメッセージが現れます。
DataPower アプライアンスとMessage Broker間にSSLサポートを追加すると、それらの間の接続が保護されます。
図13 DataPower アプライアンスとMessage Broker間のリンクの保護
Message BrokerでHTTPをSSL対応にする
Message Brokerに対してSSLを有効にするには、最初にMessage Brokerを構成して、証明書を割り当てる必要があります。この記事では、鍵ストア内の自己署名証明書がMessage Broker HTTPリスナー・プロセスによって使用されます。認証局が署名した証明書を使用することも可能です。次に、この鍵ストアを使用するようにブローカーを構成します。
鍵ストアは、Java ikeymanアプリケーションを使用して作成します。この鍵ストアに保管する自己署名証明書を作成するには、「新規自己署名証明書」を選択します。この記事では、以下の構成を使用します。
図14 ikeymanの自己署名証明書
この証明書の公開鍵をDataPower アプライアンスに提供するには、「（証明書の）抽出」を選択します。以下のコマンドでは、SSLの有効化、鍵ストアの構成、この鍵ストアのパスワードの指定、およびHTTPSポートの設定が行われます。
リスト4. Message BrokerでHTTPSを有効にするコマンド
|
>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPListener
-n enableSSLConnector -v true
>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector
-n keystoreFile -v "c:\Program Files\IBM\WMBv6.0\MyKeystore.jks"
>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector
-n keystorePass -v ********
>mqsichangeproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector
-n port -v 7083
|
|
HTTPリスナー・プロセス内でこれらの変更を有効にするには、ブローカーを再始動する必要があります。以下の2つのコマンドを使用すると、以前の設定を確認できます。
リスト5. コマンドによるMessage BrokerのHTTPS設定の報告
|
>mqsireportproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPListener -a
HTTPListener=''
uuid='HTTPListener'
enableSSLConnector='true'
traceLevel='none'
traceSize='4194304'
BIP8071I: Successful command completion.
>mqsireportproperties WBRK6_DEFAULT_BROKER -b httplistener -o HTTPSConnector -a
HTTPSConnector=''
uuid='HTTPSConnector'
keystoreFile='c:\Program Files\IBM\WMBv6.0\MyKeystore.jks'
keystorePass='********'
port='7083'
BIP8071I: Successful command completion.
|
|
メッセージ・フローをSSL対応にする
ブローカーを再始動すると、HTTP入力ノードをHTTPS用に構成して、メッセージ・フローをブローカーに再デプロイできます。図15は、メッセージ・フロー内のHTTP入力ノードのプロパティーを示しています（「HTTPSの使用」がチェックされています）。
図15 HTTPノードのプロパティー（「HTTPSを使用」項目がチェック済み）
Message Brokerを再始動してHTTPSフローをデプロイした後、netstat -aコマンド（または同等のコマンド）を使用すると、構成されたポートをHTTPリスナーがlistenしているかどうかを確認できます。
DataPower アプライアンスでのクライアント側SSLの構成
Message Broker用に生成された鍵の証明書をDataPowerアプライアンスにアップロードする必要があります。これはトラステッド・サーバーとしてSSLプロファイル内で追加され、SSLクライアント暗号プロファイル用に使用されます。SSLクライアント暗号プロファイルの作成および関連付けを行うには、「XMLファイアー・ウォールの構成（Configure XML Firewall Policy）」のGeneralタブ「SSL Client Crypto Profile」の＋ボタンをクリックし、新規作成します。プロファイルのアップロードを構成するには、ikeymanからエクスポートされた証明書を「Trusted Servers」セクションに追加します。証明書を認証および検証するオプションを選択します。このオプションをチェックすると、DataPower アプライアンスは信頼されて、トラステッド・サーバーにのみ接続できるようになります。
図16 トラステッド・サーバーの構成
HTTPリスナーのSSLポート（この場合、デフォルト値は7083）を指すようにXMLファイアー・ウォールのリッスンポートを再構成する必要もあります。
SSL暗号化
この変更を監視するには、DataPower アプライアンスとMessage Broker間にHTTPトンネルを配置します。HTTPトンネルは、2つのコンポーネント間で両方向に渡されるメッセージを監視するために使用されます。SSLプロトコルを構成する最初のやりとりのいくつかは、平文（暗号化されていないテキスト）で渡されます。ただし、セッションで秘密鍵が設定された後は、すべてのデータが暗号化されます。
Message Broker Explorer（IS02サポート・パック）には、DataPower アプライアンス内でXMLファイアー・ウォールを構成できるウィザードが含まれます。これにより、Message BrokerがプロビジョニングするHTTPフローに接続することが可能です。詳しくは、『参考文献』の下にある最初の記事を参照してください。
この記事では、WebSphere DataPower SOA アプライアンスを使用してWebSphere Message Brokerが提供する機能を拡張し、SOAPメッセージのWS-SecurityをHTTPメッセージ・フローに提供する方法を説明しました。また、HTTPSを使用してWebSphere Message BrokerとDataPower アプライアンス間のセキュリティーを実現する方法も説明しました。
| 内容 |
ファイル名 |
サイズ |
ダウンロード形式 |
| 記事で説明した4つのメッセージ・ファイル |
messages.zip |
4 KB |
HTTP（US） |
|
Peter Crockerは、英国のIBM Hursley Software Lab内のソフトウェア・サービス・チームで作業しています。WebSphere Message Brokerを専門としており、アーキテクチャー、設計、および実装に関する優れた顧客のコンサルタントとして働いています。Peterは、この職務からMessage Broker開発チームに移動し、Message Brokerの深い技術知識を社内に提供しています。V6の発表前に、ベータ・プログラムの提供および開発を支援し、サービス・チームに対する新しいV6の機能の教育を担当しました。
|
