Cisco ACE XML Gateway ユーザ ガイド
基礎 知識
基礎知識
発行日;2012/02/01 | 英語版ドキュメント(2009/11/20 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

基礎知識

実装の計画

作成手順

仮想サービスについて

基本仮想サービスと拡張仮想サービスの比較

セキュリティと について

必要なリソースの概要

セキュリティ リソースの適用

参考資料

処理オペレーションの順序

Flex Path 要求処理

Flex Path 応答処理

ポリシーの正規表現

メッセージ トラフィックのサービス優先による分類

基礎知識

この章では、Cisco ACE XML ゲートウェイ システムの背景知識について概要を説明します。内容は次のとおりです。

「実装の計画」

「作成手順」

「仮想サービスについて」

「セキュリティと ACE XML Gateway について」

「処理オペレーションの順序」

「ポリシーの正規表現」

「メッセージ トラフィックのサービス優先による分類」

実装の計画

ACE XML Gateway は、ポリシーの指示どおりにトラフィックを処理します。ポリシーでは、ACE XML Gateway で使用可能なバックエンド サービス、サービスにアクセスするための認証要件、トラフィックの検証または変更方法、その他ほとんどの ACE XML Gateway アクティビティが決定されます。

ACE XML Gateway をネットワークにインストールしたら、次にACE XML Manager Web コンソール(ACE XML Gateway ポリシーのブラウザベース開発環境)でポリシーを作成します。

ポリシーを作成する前に、ネットワークや ACE XML システムの使用方法に関する可能な限り多くの情報を収集することが重要です。計画が慎重であれば、有効性と保守性に優れたポリシーを作成できます。次のリストは、必ずしも設定に影響を与える要因を網羅したものではありませんが、ポリシーの実装に必要と考えられる各種の情報を示しています。

ユーザ側およびサービス側のインターフェイスに使用するプロトコル(HyperText Transfer Protocol(HTTP; ハイパーテキスト転送プロトコル)、Simple Object Access Protocol(SOAP)、または TIBCO Rendezvous(TIB/RV)など)

ACE XML Gateway で仮想化するサービスの接続情報

バックエンド サービスのアクセス要件とセキュリティ要件

サービスがユーザに公開される URL パス

ACE XML Gateway がユーザ要求をリッスンするポート番号

認証要件および要件の評価方法

(ポートで)メッセージまたはチャネルを暗号化するかどうか、暗号化する場合は使用する証明書/鍵ペア

信頼する Certificate Authority(CA; 認証局)

使用するメッセージ検証およびアクセラレーション方法

サービス アベイラビリティの公開方法

これらの問題およびその他可能性のある問題に対処していると、ポリシー設定は、計画に従って設定値を適用するだけで済みます。

作成手順

ACE XML Gateway ポリシーの作成は一般に、ポリシーの作成、テスト、導入に必要な手順を繰り返すプロセスです。ACE XML Gateway ポリシーを作成する一般的なワークフローは次のとおりです。

1. ACE XML Gateway でプロキシ処理の対象となるサービスを定義します。サービス定義は、プロキシ処理の対象となるサービスを記述した Web Services Description Language(WSDL)ファイルのインポートで、一度に行うことができます。

2. 受信要求の検証方法を指定します。XML スキーマ検証、適格性のチェック、コンテンツ スクリーニング、XML 署名照合などを使用します。

3. サービスの暗号化設定や復号化設定を指定します。

4. サービス要求を許可するオーセンティケータを作成します。オーセンティケータは、パスワード、X509 証明書、Security Assertion Markup Language(SAML)トークンなど、さまざまなクレデンシャル タイプに基づいたアクセス条件を指定できます。

5. セキュリティの欠陥や設定の問題に対応するポリシーを確認します。ポリシー確認を補助するために ACE XML Manager では、導入前に各ポリシーの自動確認が実行されます。

6. ポリシーを適用する準備ができたら、ACE XML Gateway に導入します。ポリシーは ACE XML Gateway を通過するトラフィックに適用されます。

7. システム パフォーマンスを監視します。ネットワークが安全で期待どおりに動作することを確認するためには、ACE XML Manager から提供される監視ツールと診断ツールを使用します。

仮想サービスについて

ACE XML Gateway は、各種バックエンド サービスを仮想化できます。サービスには、SOAP サービス、REST ベースのアプリケーション リソース、メッセージ バス キュー、その他多種類のリソースがあります。いずれのバックエンド サービス タイプでも、ACE XML Gateway ポリシーはサービスの設定を仮想サービスと呼ばれるポリシー オブジェクトで表します。

仮想サービスには、バックエンド サーバの接続設定、サービスに着信するトラフィックの処理および検証ルール、およびその他サービス固有の設定が含まれています。

通常、仮想サービスは ACE XML Gateway からの単純なメッセージ パスを定義します。トランザクションの要求および応答ブランチを設定し、ユーザ インターフェイスとバックエンド サービス インターフェイスを 1 対 1 で対応させます。こうした仮想サービスは 基本仮想サービス と呼ばれ、図 2-1 に示すように仮想サービス ブラウザで表示されます。

図 2-1 拡張仮想サービス定義

 

仮想サービスはユーザ インターフェイスとバックエンド サービス インターフェイスを個別に規定するポリシー オブジェクトで定義することもできます。 サービス記述子 にはバックエンド サービスの設定、 ハンドラ にはユーザ インターフェイスの設定が表示されます。 ルート は、ハンドラをサービス記述子につなぎます。こうした仮想サービスは 拡張仮想サービス と呼ばれ、図 2-2 に示す仮想サービス ブラウザで表示されます。

図 2-2 拡張仮想サービス定義

 

拡張仮想サービスにより、ブランチ ルーティングとプロトコル メディエーションを別の拡張設定方法に実装できます。ブランチ ルーティングでは、メッセージを 1 つのハンドラから複数のサービス記述子の 1 つに(図 2-2 を参照)、または複数のハンドラから 1 つのサービス記述子にルーティングします。ルートでは、所定のメッセージを取得するバックエンド サービスを決定する条件が定義されます。

図 2-3 ブランチ ルーティング

 

WSDL インポートで SOAP サービス定義を作成する場合、ACE XML Manager で基本仮想サービスまたは拡張仮想サービスの生成を選択できます。

SOAP Document サービスでは、オペレーション単位の仮想サービス オブジェクトを作成したり、WSDL 内のサービス エレメントごとに基本仮想サービスを作成したりする(この場合、仮想サービスには複数のオペレーションが含まれる)追加オプションがあります。サービス内のすべてのオペレーションに同じ設定が必要な場合、一般に複数オペレーションの仮想サービスを使用する方が便利です。必要であれば、固有の設定を行うためにサービス内のオペレーションを上書きできます。

基本仮想サービスと拡張仮想サービスの比較

基本仮想サービス(単一ポリシー オブジェクトで構成されるサービス)は一般に操作が簡単です。ただし、複数オブジェクトで構成される仮想サービスの作成が必要であるか、より実用的な場合があります。所定のサービスにいずれの方法を使用するかを決めるうえで、決定に役立つ要因を次の表に示します。

表 2-1 基本サービスと拡張サービスの比較

 

基本仮想サービス オブジェクトを使用
拡張仮想サービスを使用

複数の SOAP オペレーション設定を 1 つのサービス定義に設定する利便性を望む場合

各オペレーションの設定を個別に設定する必要があるか、何らかの理由でオペレーションを個別に使用することが便利な場合

プロトコル間のメディエーションが不要な場合(たとえば、HTTP 要求がバックエンド HTTP サービスにルーティングされるなど)

プロトコル間のメディエーションが必要な場合(たとえば、HTTP 要求をメッセージ サーバに送るなど)

バックエンド サービスが HTTP ベースまたは SOAP ベースの場合

サービス インターフェイスまたはユーザ インターフェイスのプロトコルが、TIB/RV、MQSeries、Java Message Service(JMS)、ebXML over Simple Mail Transfer Protocol(SMTP; シンプル メール転送プロトコル)、ebXML over HTTP のいずれかの場合

メッセージのヘッダーまたは本文のパススルー マッピングが十分な場合

メッセージのヘッダーまたは本文のカスタム値マッピングおよび置換がユーザ インターフェイスとサービス インターフェイス間に必要な場合

コンテンツ キャッシングが重要でない場合

ユーザに渡される応答をキャッシュする場合

新しい仮想サービスは、単一または複数オブジェクトとして作成できます。仮想サービスを単一オブジェクトとして作成しても、後からコンポーネント部品に分割できます(ただし、追加設定可能な設定が含まれているため、コンポーネント部品で作成された仮想サービスを単一オブジェクトに戻すことはできません)。このオペレーションに対応する Web コンソール内のボタンには、[Convert to Advanced] ラベルが付いています。

セキュリティと ACE XML Gateway について

多くの ACE XML Gateway 機能を支える、Public Key Infrastructure(PKI; 公開鍵インフラストラクチャ)や暗号法などのセキュリティ技術は、確立された周知のテクノロジーです。ACE XML Gateway にセキュリティを実装する場合には、少なくともこれらの技術に精通していることが望ましく、実経験があれば最適です。

経験を積んだ専門家でも、ACE XML Gateway 環境でのセキュリティ実装は、初めての作業になる可能性もあります。Service-Oriented Architecture(SOA; サービス指向アーキテクチャ)によりネットワーク オペレーションとアプリケーション開発との境界はなくなりますが、いずれか 1 つの領域だけでセキュリティを実体験することがほとんどです。

ここでは、ネットワーク トラフィックのセキュリティに必要な作業の概要について説明します。  データ通信のセキュリティ保護は、特にパフォーマンスが犠牲になることが避けられません。暗号化と復号化、メッセージ検証、およびメッセージ スクリーニング ルールはすべて、セキュリティを高めるものですが、システム全体のパフォーマンスにも影響します。システム実装では、多くの場合セキュリティとパフォーマンスの関係を調整する必要があります。

必要なリソースの概要

ACE XML Gateway 実装に使用されるセキュリティ リソースは 2 種類あります。

システムの内部オペレーションのセキュリティ保護に必要なリソース(ACE XML Manager と Gateway 間の通信、ACE XML Manager への管理アクセスなど)

Gateway のサービス トラフィックのセキュリティ保護に必要なリソース(Secure Sockets Layer(SSL)チャネルの確立、トラフィックの暗号化と復号化など)

一般に内部リソースは、アプライアンスの初回インストールでセットアップします。一方、外部リソースは通常、新しいサービス プロバイダー、クライアント、またはサービスがオンラインになるときに応じて、追加および管理する必要があります。

こうしたリソースには次の種類があります。

ACE XML Gateway の 公開鍵/秘密鍵ペア 。通常、ACE XML Gateway には固有の公開鍵/秘密鍵ペアが必要です(クラスタ内に複数の Gateway が存在しても、外部で解決可能な単一のホスト名でアドレスを処理するのであれば、使用するペアは 1 つだけです)。公開鍵/秘密鍵ペアは、SSL、XML 暗号化、および XML 署名に使用されます。

パートナーの公開鍵証明書 。証明書には、対象者の公開鍵、有効性を証明する署名、その他の情報が含まれています。署名を確認してコンテンツを暗号化するパートナーの公開証明書を入手する必要があります。

認証局証明書 。デフォルトでは、ACE XML Gateway に信頼する認証局は設定されていません。CA 証明書をアップロードすると、ACE XML Gateway はその CA から発行されたユーザ証明書を信頼できるようになります。

ACE XML Gateway システムをインストール後、一般にはシステムの公開鍵/秘密鍵ペア リソースを取得する必要があります。鍵ペアを入手するために、まず ACE XML Manager で一時的に鍵ペアを生成します。次に、生成した公開鍵を認証局(CA)に送信して認証を受けます。または、組織内部だけで使用するシステムの場合は、自己署名証明書であれば十分です(ACE XML Manager コンソールから証明書と Certificate Signing Request(CSR; 証明書署名要求)を生成する方法については、「CSR の生成」を参照してください)。

公開鍵と署名は、CA で認証されると、X.509 証明書と呼ばれるリソースで機密が保持されます。公開鍵は証明書に入れてパートナーに運ばれるので、パートナーが CA 署名で公開鍵を確認できます。コンテンツの暗号化またはACE XML Gateway で生成された署名の確認には、送信者の公開鍵がパートナーに必要になります。

ここでは、リソースを適用して、ACE XML Gateway 機能を使用する方法について詳しく説明します。

セキュリティ リソースの適用

必要なセキュリティ リソースとその適用方法は、目的のシステム オペレーションに応じて異なります。一般的な SOAP アプリケーションの場合、メッセージの有効性とセキュリティの確保のために XML 署名や XML 暗号化を組み合わせて使用し、SSL でチャネルのセキュリティを保護します。

次の表に、機能に必要なリソースを示します。

表 2-2 機能に必要なリソース

 

目的
必要な作業

クライアント接続用 SSL

ACE XML Gateway の公開鍵/秘密鍵ペアを使用してセキュア ポートを設定します。鍵ペアは非対称暗号方式の鍵交換に使用され、SSL ネゴシエーションでセッション鍵が交換されます。鍵交換が完了すると、トラフィックの暗号化にセッション鍵が使用されます(対称暗号方式)。

XML 暗号化で保護されたコンテンツの復号化

ACE XML Gateway の秘密鍵を使用します(つまり、ACE XML Gateway 用に生成された公開鍵/秘密鍵ペア リソースに含まれる秘密鍵)。情報を暗号化するユーザまたはサーバは、ACE XML Gateway の公開鍵が必要です。公開鍵はコンテンツの暗号化に使用します。

XML 暗号化によるコンテンツの暗号化

目的のコンテンツ受信者の公開鍵でコンテンツを暗号化します。公開鍵は、手動でポリシーにロードするか、要求の認証時に Gateway で取り込むことができます。

XML 署名の確認

XML 署名は、署名の作成に使用された秘密鍵に対応する公開鍵で確認されます。受信メッセージの署名をその鍵で確認できれば、受信者は、メッセージの発信元が秘密鍵の所有者であり、メッセージは署名の生成後に変更されていないことを確認できます。

ACE XML Gateway では、この用途に使用される鍵を次のように設定できます。

ポリシーへのロードおよびサービス記述での指定。この場合、最初に発信元の組織から鍵を取得し、ACE XML Gateway ポリシーにアップロードする必要があります。

署名自身からの抽出。ACE XML Gateway の設定で信頼されたいずれかの認証局から鍵を発行する必要があります。

XML 署名の生成

署名の確認には、発信元の証明書(詳しくは、証明書内の公開鍵)が受信者に必要です。この署名は、ACE XML Gateway の秘密鍵を使用して ACE XML Gateway で生成されます。

x.509 証明書によるクライアントの認証

ユーザ証明書(証明書の照合による確認のため)または信頼する CA の証明書をアップロードします。つまり、CA 証明書のアップロードで信頼関係を指定した CA によって有効なユーザ証明書が署名されると、そのユーザ証明書が受け入れられます。

参考資料

PKI および XML セキュリティに関連する一般的な概念については、次のリソースを推奨します。

SSL 概要:Eric Rescorla 著『SSL and TLS』

WS-Security:Rosenberg、Remy 共著、『Securing Web Services with WS-Security』

公開鍵暗号方式(ウィキペディア): http://en.wikipedia.org/wiki/Public_key_cryptography

処理オペレーションの順序

仮想サービス インターフェイスで要求を処理する場合、ACE XML Gateway は多様な処理および検証オペレーションをメッセージに適用できます。ポリシーの作成またはトラブルシューティングでは、多くの場合、ACE XML Gateway のオペレーション実行順序の知識が役立ちます。

オペレーション順序情報は、Extensible Stylesheet Language(XSL)変換や Software Development Kit(SDK; ソフトウェア開発キット)変換拡張機能など、ポリシーの拡張機能に最も関連します。これらの機能はメッセージを直接変更するため、処理チェーンのいずれの場所で変換機能がメッセージを参照するか、どのような検証または変換オペレーションがメッセージに適用済みかを理解しておくと便利です。

Gateway 処理を理解するうえで重要な点は、特定のパラメータ内でオペレーション順序が保証されないことです。こうしたばらつきが生じるのは主に、最適なパフォーマンスを確保するために、サービス定義で有効にされる機能に応じて ACE XML Gateway がオペレーション順序を変更してメッセージ処理を最適化するからです。

特定のオペレーションの順序は必ずしも同じではありませんが、ACE XML Gateway の処理アクティビティでは確立された一定のフェーズ内だけで順序が変化するように制限されています。フェーズについては、次で説明します。

Flex Path 要求処理

図 2-4 に、ACE XML Gateway によるメッセージの一般的な処理手順を示します。ここで説明する内容は HTTP 要求に該当しますが、他のタイプのメッセージの処理順序も同様です。

図 2-4 Flex Path 要求処理

 

各処理フェーズの詳細を次の手順で説明します。

1. メッセージの読み込みまたは解析を行います。

2. 最初に要求 URL のパスおよびヘッダーに基づいて、要求を分類します。SOAP 要求の場合、ACE XML Gateway は SOAPAction ヘッダー(存在する場合)も使用し、要求をハンドラに関連付けます。

3. エンベロープレベルのクレデンシャルを評価します。エンベロープレベルのクレデンシャルは、SOAP 固有のものではないクレデンシャル タイプで構成されています。

Basic Auth ヘッダーをチェックします。

Security Token クレデンシャル チェックを呼び出します(このタイプのクレデンシャルでは、要求から取得した値は外部 Web サービスで評価されます)。

送信元 IP アドレスをチェックします。

XPath パスワードをチェックします。

SSL 証明書をチェックします。

SDK 独立型拡張オーソライザを呼び出します。

4. 要求 URL およびエンベロープレベルのクレデンシャル チェックに基づいてメッセージをハンドラに割り当てます。複数のハンドラに対応する要求がある場合、エンベロープレベルのクレデンシャル タイプを使用すると、目的のハンドラを絞り込むことができます。

5. 本文レベルのクレデンシャルを評価します。本文レベルのクレデンシャルは SOAP 固有のものです。SOAP サービス定義に要求が割り当てられた後でなければ評価されません。

Web Services Security(WSS)ユーザ名/パスワードを処理します。

SAML を処理します。

6. ルーティング(メッセージを受信するサービス定義)を決定します。仮想サービスでユーザ インターフェイスを 1 つのサービスにマッピングする場合、ルーティングを決定する必要はありません。ただし、複数のサービス定義にルーティングされるハンドラの場合、ACE XML Gateway はルーティング基準に基づいた決定を行います(要求処理の一部で実行されるメッセージ コンテンツの Extensible Stylesheet Language Transformation(XSLT; XSL 変換)処理の結果は、ルーティング決定に影響しません)。

7. 受信要求処理は次の一般的な順序で実行します。

前処理 XSLT を適用します。

SDK 変換拡張機能を呼び出します。

SOAP ヘッダーを処理します。ACE XML Gateway は、受信メッセージ内のヘッダー順に、SOAP ヘッダーで要求されるタスクを実行します。XML 暗号化コンテンツの復号化、XML 署名の検証、その他タイムスタンプのような SOAP ヘッダーの処理などのタスクがあります。

SOAP 添付ファイルの有無をチェックします。

適格性や XML スキーマの適合性をチェックします。

8. ルート処理を実行します。

XSLT を適用します。

引数をマッピングします。

ヘッダーをマッピングします。

9. 発信要求処理を実行します。

適格性や XML スキーマの適合性をチェックします。ここで、メッセージの有効性を再チェックし、XSLT または拡張処理でメッセージの構造が壊れていないかどうかを確認します。

SDK 変換拡張機能を呼び出します。

タイムスタンプを生成します。

署名を生成します。

コンテンツ暗号化を実行します。

ACE XML Gateway は常に、署名を生成した後に、署名されたコンテンツを暗号化するという順序で、XML 署名と暗号化を実行します。

後処理 XSLT をメッセージに適用します。

10. メッセージを宛先に送信します。

Flex Path 応答処理

対応する応答処理が図 2-5 に示すように実行されます。

図 2-5 Flex Path 応答処理

 

処理手順は次のとおりです。

1. 宛先からの応答の読み込みまたは解析を行います。

2. 例外のコンテンツが応答に存在するかどうかをチェックし、検出した場合は、例外マッピングを適用します。

3. 受信応答処理を実行します。

前処理 XSLT を適用します。

SDK 変換拡張機能を呼び出します。

SOAP ヘッダーをメッセージ内の記載順に処理します。ヘッダー処理には、コンテンツの復号化、デジタル署名の検証、その他タイムスタンプのような SOAP ヘッダーの検証などがあります。

SOAP 添付ファイルの有無をチェックします。

4. ルート処理を実行します。

ルート XSLT を適用します。

引数をマッピングします。

ヘッダーをマッピングします。

5. 送信応答処理を実行します。

SDK 変換拡張機能を呼び出します。

タイムスタンプを追加します。

署名を生成します。

コンテンツを暗号化します。

後処理 XSLT を適用します。

6. メッセージをクライアントに送信します。

ポリシーの正規表現

いくつかのポリシー機能では、機能設定内で正規表現を使用できます。たとえば、コンテンツ スクリーニング、要求 URL の照合、クレデンシャルの認証などで正規表現を使用できます。

仮想サービス機能の場合、ACE XML Gateway は Portable Operating System Interface(POSIX)1003.2 正規表現を実装します。ACE XML Gateway では、この標準が厳密に適用されて使用されます。正規表現は、改行依存性が有効にされています。つまり、キャレット記号(^)は、行の開始に相当します(Lightweight Directory Access Protocol(LDAP)ルックアップで返される LDAP Data Interchange Format(LDIF)形式の各プロパティが独立した行に記載されるので、特にこうしたプロパティの照合に役立ちます)。また、改行依存性により、any-character 演算子(.)は改行とは一致せず、match-end-of-line 演算子($)は改行直前の空白文字列に一致することになります。

仮想 Web アプリケーションに関連する機能の場合、ACE XML Gateway は PERL 形式の正規表現を使用します。

メッセージ トラフィックのサービス優先による分類

Cisco ACE XML ゲートウェイ バージョン 6.0 以降に送信される各メッセージは、仮想 Web アプリケーション インターフェイスまたは仮想サービス インターフェイスのいずれかで処理されますが、両方が同時に使用されることはありません。

Gateway は、HTTP 要求および応答アトリビュートであるホスト、ポート、HTTP メソッド、URL パス、GET 要求パラメータ値、POST 要求パラメータ値、要求ヘッダー値などに従って受信メッセージを分類します。Gateway サービス プロキシと仮想 Web アプリケーションによるこれらのメッセージ分類設定がまったく同じ場合、ACE XML ゲートウェイ Web サービス インターフェイスがメッセージを取得し、WAF はメッセージを処理しません。つまり、受信メッセージのプロトコル/ポート/パスが、Web アプリケーションと仮想サービス ユーザ インターフェイスの両方でまったく同じで、その他の照合パラメータが存在しなければ、WAF プロキシではなく、ACE XML ゲートウェイ プロキシがメッセージを処理します。

受信メッセージ トラフィックを分類する場合、Gateway では正規表現による一致よりも文字の一致が詳細であると見なされる結果、文字メッセージ分類子は同等の正規表現による分類子よりも優先されます。

たとえば、 表 2-3 に示す仮想 Web アプリケーションおよび仮想サービス ハンドラを指定するポリシーがあるとします。

表 2-3 メッセージ分類の例

仮想サービス
仮想 Web アプリケーション
プロトコル

HTTP

HTTP

ホスト名

reactivity.com

reactivity.com

ポート

80

80

要求 URL

hello*

helloworld

http://reactivity.com:80/helloworld/ への受信要求は両方のインターフェイスに一致します。ただし、仮想 Web アプリケーションが実行する文字の一致は、仮想サービスが実行する正規表現による一致よりも詳細であると見なされるため、仮想 Web アプリケーションがメッセージを処理します。

プロビジョニングされていないハンドラは、受信メッセージ トラフィックの分類に含まれず、分類に影響しません。つまり、プロビジョニングされていない仮想サービスは、仮想 Web アプリケーションが受け入れる特定パスへの要求を遮断しません。


) Manager Dashboard は、ハンドラに一致しなかった要求のリストを表示しません。一致しない要求は、Web App Incident レポートおよび [Event Log] に表示されます。