Cisco ACE XML ゲートウェイ スタートアップ ガイド Software Version 5.1
サービスへのアクセス コントロール
サービスへのアクセス コントロール
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 637KB) | フィードバック

サービスへのアクセス コントロール

  • ACE XML Gateway はサービスを保護するために、そのサービス要求に対してアクセス コントロールによる制限を適用します。ACE XML Gateway は、次のように、受信要求に組み込まれた幅広い種類の証明情報を評価できます。
  • 電子証明書
  • Basic 認証 HTTP ヘッダ
  • WSS UsernameToken
  • WSS Password Digest
  • XPath 表記法によりメッセージ内の場所を記されたユーザ名/パスワードの組み合わせ
  • Netegrity トークン
  • SAML トークン
  • IP アドレス
  • 時刻
  • パスワード ベースの証明情報は ACE XML Gateway のポリシーが持つデータと照合するか、Netegrity SiteMinder、LDAP、Active Directory、あるいは何らかの SOAP サービスなどの外部の仕組みにより確認できます。
  • サービスへのアクセス条件は、オーセンティケータと呼ぶポリシー オブジェクトを使って定義します。要求がオーセンティケータにより許可されるには、オーセンティケータに格納されているすべての条件を満たさなければなりません。
  • 1 つのオーセンティケータは、1 つの認証グループを介して 1 つのサービス プロキシに関連付けられます。認証グループは 1 つまたは複数のオーセンティケータを 1 つまたは複数のサービス定義に結び付けます(図 13-1 を参照)。
アクセス コントロール ポリシーの構成要素
 
  • 1 つのサービスに関連付けられた複数のオーセンティケータが存在する場合は、要求がそのうちの 1 つに合致すればサービスにアクセスすることができます。ACE XML Gateway は証明情報の評価にいくつかの最適化手法を用います。1 つのサービスに関連付けられた複数のオーセンティケータが存在する場合、要求の評価は複雑な条件(暗号化など)のオーセンティケータよりも先に、すぐに確認できる条件(IP アドレスの規制など)のオーセンティケータを評価します。
  • もうひとつの最適化手法として、いったん要求がオーセンティケータに受け入れられると、ACE XML Gateway は他のオーセンティケータの条件を無視します。その結果として、イベント ログには実際にその要求を受け入れたオーセンティケータのみが表示されることに注意してください。受け入れる可能性のあったすべてのオーセンティケータが表示されるわけではありません。

IP アドレスによるアクセス コントロール

  • サービスの仮想化でサービス プロキシを作成したあと、このマニュアルの手順どおりに実行している場合は、retrieveQuote サービス プロキシを public に設定しているはずです。このレベルでは、ACE XML Gateway が、受信要求をいずれかのサービス プロキシと一度一致すると、以降の証明確認は行いません。実際の導入では、ほとんどのサービスにおいて何らかの方法でアクセスを規制することになるでしょう。
  • 次の手順では、ユーザの IP アドレスに基づいてオーセンティケータをセットアップし、それをサービス プロキシに関連付ける方法を説明します。
  • 操作メニューで [Access Control Browser] をクリックします。
  • retrieveQuote サービスが Public の一覧表に表示されていることに注意してください。
  • [Add an Authenticator] ボタンをクリックします。
  • オーセンティケータの Edit General Information ページでオーセンティケータの名前を入力してください(BeaglePartners など)。
  • [Authorization Group] には、Partners など、新しい認証グループの名前を入力します(ドロップダウン メニューで [Create in new authorization group named] が選択されている必要があります)。
  • [Create] をクリックします。
  • そのオーセンティケータの証明ページが表示されます。
  • [Add Credential] メニューに [IP Address] が選択された状態で [Add] をクリックします。
  • [IP Address] ページで、許容する IP アドレスの範囲を先頭と末尾の入力欄に入力します。
  • ACE XML Gateway が認証されないクライアントを適切に遮断するかどうかを確認するため、まず最初にテスト要求を発行しようとしているコンピュータのアドレスを含まない範囲を入力します。
  • [Save Changes] をクリックします。
  • 再び表示されたオーセンティケータのページには、REQUIRED CREDENTIALS(必要な証明情報)の下に IP アドレス要件が記載されています。
IP アドレスの要件
 
  • ここで、ハンドラを認証グループに関連付けるため、次の手順を行います。
  • オーセンティケータ ページ最下部にある [Exit to Access Browser] ボタンをクリックして、アクセス コントロールのブラウザに戻ります。
  • オーセンティケータのほかに、さきほど作成した認証グループが表示されることに注意してください。
  • retrieveQuote サービス プロキシの名前をクリックします。この名前は Public 一覧表に記載されているはずです。
  • サービス プロキシのアクセス コントロール ページで、 [Access is restricted to the following authorization groups] と記されたオプション ボタンをクリックします。
  • さきほど作成した認証グループ、Partners の横のチェックボックスをクリックします。
  • [Save Changes] をクリックします。
  • アクセス コントロール ブラウザが再び表示されます。今回は retrieveQuote サービス プロキシに結びつけて作成した認証グループが記載されています。
認証グループを与えられたサービス プロキシ
 
  1. この変更を有効にするためにポリシーの導入を行います。
  2. ポリシーの導入が終了したら、「 XML Gateway へのトラフィック送信」で説明したようにテスト要求を発行します。
  3. オーセンティケータに入力した IP アドレスの範囲外の IP アドレスを持つクライアントからテストを実行すると、図 13-4 に示すように、XML Gateway は「Forbidden」応答を返します。
不適格なアクセスへの応答
 
  • イベント ログがアクセス遮断のイベントをどのように記録しているかを確認するには、操作メニューの [Event Log] リンクをクリックします。
  • 遮断されたアクセス試行がイベント ログの警告レベルで記録されていることに注意してください(次の図を参照)。
遮断アクセスのイベントを記録したログ
 

ユーザ名/パスワードの認証によるアクセス コントロール

  • ACE XML Gateway は、パスワード ベースの柔軟な認証を行います。認証は、XML Gateway または LDAP ディレクトリなどの外部システムに保存したデータと照合することで有効になります。
  • 次に、受信要求内のベーシック認証 HTTP ヘッダに対するパスワード チェックをセットアップ手順について説明します。
  • まだ開いていない場合は、操作メニューの [Access Control Browser] リンクをクリックします。
  • 前回作成した認証グループにもう 1 つの認証手順を加えることにします。
  • [Add an Authenticator] ボタンをクリックします。
  • [Authenticator Name] 欄に、このオーセンティケータの名前を入力します(Beagle Basic Auth など)。
  • [Authorization Group] メニューで、初めに作成した認証グループの名前、Partners を選択します。
  • [Create] をクリックします。
  • オーセンティケータの証明情報ページが表示されます。
  • [Add Credential] メニューから [HTTP(S) Basic Authentication] を選択し、 [Add] をクリックします。
  • [HTTP(S) Basic Authentication] ページで [Verify Using] メニューのデフォルトの選択肢 [Fixed Values] をそのまま維持します。
  • このメニューのその他のオプションに、パスワードファイル認証(ユーザ名/パスワードの組み合わせを持つ .htaccess 形式のファイル)と様々な LDAP 認証方式が含まれていることに注意してください。
  • このオーセンティケータが受け入れるユーザ名を [Username] 欄に入力します。
  • [Password] 欄には、受け入れるパスワードを入力します。
  • [Save Changes] をクリックします。
  • Reqiured Credentials の下に [HTTP(S) Basic Authentication] という要件を記載するオーセンティケータ ページが表示されます。
  • Identity Reporting 機能を利用すると、ユーザごとのサービス アクティビティを表示できます。新規オーセンティケータに対して Identity Reporting 機能を有効にします。
  • オーセンティケータ ページにある Identity Reporting ヘッダの横の [Edit ] をクリックします。
  • [Enable Identity Reporting] チェックボックスをクリックします。
  • [HTTP Basic Auth Username] の横のチェックボックスを有効にします。これは、さきほど作成した認証要件の種別名です。
  • [Save Changes] をクリックします。
  • オーセンティケータ ページが再表示されます。 [Exit to Access Browser] をクリックし、アクセス ブラウザで新しい設定の効果を確認します。
認証グループを与えられたサービス プロキシ
 
  • ユーザは 2 つのオーセンティケータで定義されている条件の いずれか に合致すれば retrieveQuote サービスにアクセスできることに注意してください(さきほど設定したパスワード要件、または IP アドレス要件)。IP アドレス要件を持つ BeaglePartners オーセンティケータにパスワード要件を加えると、ユーザがサービスにアクセスするには両方の条件を満たさなければなりません。
  • パスワード要件を適切にテストするには、テスト対象のホストを遮断するように IP アドレス要件を設定(またはそのポリシーからオーセンティケータを削除)する必要があります。
  • 設定を最後まで完了させるためにポリシーを導入したあと、新しい認証要件をテストします。
  • 前回と同様に、XML Gateway の retrieveQuote サービスに送信する要求を WFetch で用意します。ただし、認証用の証明情報には Auth 方式として [Basic] を選択し、 [User] 欄および [Passwd] 欄には、オーセンティケータに入力したユーザ名とパスワードを入力します。
WFetch でベーシック認証の要求を設定
 
  • [Go!] をクリックします。これからサービスに対するパフォーマンス データの確認を行います。そのため、正常終了の応答を 1 回受け取ったあと、この要求を何回か繰り返して実行し、パフォーマンス データを蓄積してください。
  • これで、さきほど設定したユーザ証明に対するサービス アクティビティを参照できます。
  • XML Manager の Web コンソールで、操作メニューにある [Performance Monitor] をクリックします。
  • retrieveQuote サービスに対応するハンドラ グループの名前 order の横のエキスパンド コントロールをクリックします。
  • このサービス オペレーション全体についての合計値とともに、さきほど作成したユーザ ID に関する統計情報が表示されていることに注意してください。
パフォーマンス モニタに表示されたユーザのアクティビティ
 
  • この例では、オーセンティケータで認証するよう設定されている ID は 1 つだけです。オーセンティケータがパスワード ファイルや LDAP ディレクトリと突き合せてパスワードを確認するように設定されている場合、証明元に属する有効なアカウントからの要求は ID の数だけモニタに表示されます。
  • パフォーマンス モニタにおける統計情報の各項目についての詳細は、このページから呼び出すオンライン ヘルプで参照してください。