| Oracle® Real User Experience Insightユーザーズ・ガイド 13.3.1.0 for Linux x86-64 E98302-02 |
|
 前 |
 次 |
コレクタの管理を容易にするため、各コレクタは1つのコレクタ・プロファイルに割り当てられます。 コレクタ・プロファイルの構成が変更された場合、それらは割当て済のすべてのコレクタに自動的に適用されます。
インストール時に、次の2つの事前定義済のコレクタ・プロファイルが作成されます。
システム・ネットワーク・データ・コレクタ(ネットワーク・ベースのデータ収集の場合)
システム・タグ・サーバー(タグ・ベースのデータ収集の場合)
レポート要件に応じて追加のプロファイルを作成するには、既存のプロファイルをコピーして、それを新規プロファイルのベースとして使用します。 ユーザー定義のコレクタ・プロファイルとは異なり、システム・コレクタ・プロファイルは削除できません。
現在使用可能なコレクタ・プロファイルを表示するには、構成→セキュリティ→コレクタ・プロファイルの順に選択します。 例を図13-1に示します。
図13-1 コレクタ・プロファイル・パネル
各コレクタ・プロファイルでは、表13-1に示すオプションをコンテキスト・メニューで使用できます。
表13-1 コレクタ・プロファイルのコンテキスト・メニュー
| オプション | 説明 |
|---|---|
構成 |
選択したプロファイルに割り当てられているすべてのコレクタの構成を指定できます。 それには、ネットワーク・フィルタ、コレクタでリスニングするTCPポート、およびセキュリティで保護されたトラフィックの復号化に使用する秘密キーの使用が含まれます。 これについては、「コレクタ・プロファイル構成の変更」で説明しています。 プロファイルの構成を変更した後に、プロファイルに割り当てられているコレクタを自動的に再起動するか、または手動による再起動を要求するメッセージを表示するかを指定できます。 これについては、「コレクタの再起動」で説明しています。 |
コピー |
選択したコレクタ・プロファイルを新規プロファイルのベースとして使用します。 これについては、「コレクタ・プロファイルの作成」で説明しています。 |
プロパティの編集 |
コレクタ・プロファイルの名前および簡単な説明を変更できます。 デフォルトのコレクタ・プロファイルのプロパティは変更できません。 |
削除 |
選択したコレクタ・プロファイルを削除します。 選択したプロファイルにコレクタが割り当てられている場合、これらはデフォルト(システム)コレクタ・プロファイルに自動的に再割当てされます。 デフォルトのコレクタ・プロファイルを削除することはできません。 |
新規コレクタ・プロファイルを作成する手順は、次のとおりです。
プロファイルに割り当てられているコレクタは、レポート要件に応じて別のコレクタに簡単に再割り当てできます。 たとえば、ネットワーク・トラフィックのパターンまたはセキュリティ要件が変更された場合などです。 コレクタを再割り当てする手順は、次のとおりです。
図13-4 コレクタ・プロファイルの割当てダイアログ
図13-5 移動したコレクタのステータス・メッセージ
このステータス・メッセージは最大で60秒間表示されます。 その後、コレクタが自動的に再起動されるか、手動による再起動を要求するメッセージが表示されます。 詳細は、「コレクタの再起動」を参照してください。
注意:
新規プロファイルのセグメンテーション・スキームが以前のプロファイルと異なる場合、新規プロファイルと一貫性が保たれるようにコレクタのセグメンテーション・スキームが調整されることに注意してください。 したがって、トラフィック・フィルタの設定を新規プロファイルに割り当てた後で確認することを強くお薦めします。 詳細は、「全トラフィックの制限」を参照してください。
例13-1 複数のコレクタの割当て
異なるプロファイルに複数のコレクタを割り当てる場合は、構成メニューの複数選択オプションを使用できます。 目的のコレクタをクリックしてから、ツールバーのプロファイルの割当てコマンド・ボタンをクリックします。
コレクタは、ネットワーク・ベースにもタグ・ベースにもでき、別のインタフェースに関連付けることができます。 コレクタをインタフェースに割り当てる手順は、次のとおりです。
図13-6 コレクタ・ネットワーク・インタフェース
新規コレクタをシステムに登録する手順は、次のとおりです。
図13-7 コレクタの登録ダイアログ
コレクタ・プロファイルでなんらかの構成を変更した場合、変更を有効にするには、そのプロファイルに割り当てられているすべてのコレクタを再起動する必要があります。 この再起動は自動(デフォルト)または手動のいずれかで実行できます。 コレクタの再起動の方法を構成する手順は、次のとおりです。
例13-2 手動によるコレクタの再起動
ネットワーク・データ・コレクタの構成ウィンドウに再起動を要求するメッセージが表示されるまで、コレクタは再起動できません。 例を図13-9に示します。
個々のコレクタを再起動するには、コンテキスト・メニューで再起動を選択します。 コレクタ・プロファイルに多数のコレクタが含まれる場合は、「構成」メニューの「すべてのコレクタの再起動」オプションを使用すると便利な場合があります。
リモート・コレクタ・システムでメンテナンスまたはトラブルシューティングを実行するときは、コレクタ・インスタンスを停止する必要が生じる可能性があります。 この場合は、コレクタのコンテキスト・メニューで無効化を選択します。 次に、再起動オプションを選択すると、コレクタに監視を再開するように指示できます。
リモート・コレクタ・システムが廃止された場合は、インストール済RUEIからそれを削除する必要があります。 それには、コレクタのコンテキスト・メニューで登録解除オプションを選択します。 確認後に、レポータのコレクタ・システムへの接続が中止されます。 ローカル・コレクタ・インスタンスは登録解除できないことに注意してください。
ローカル・コレクタ
レポータ・システムのローカル・コレクタ・インスタンスは、System(localhost)項目で表します。 インストール後はまだ有効化されておらず、現在定義されているすべてのコレクタ・プロファイルに表示されることに注意してください。 特定のプロファイルで有効になると、選択したコレクタ・プロファイルのみで表示されます。 ローカル・コネクタ・インスタンスは登録解除できません。
単一システムの能力を超えて処理を拡大するために、通常はレポータによって実行されるデータ処理を負担するように1つ以上の処理エンジンを構成することができます。
RUEIのデプロイメントに処理エンジンを追加するには、次の手順を実行します。
例13-3 処理エンジンの無効化
システムのメンテナンス(パッチのインストールなど)を実行するため、処理エンジンを一時的に無効にできます。 処理エンジンを無効にする場合、次の点に注意してください。
処理エンジンを長期間無効にすると、短期間のデータが失われる場合があります。
無効になった処理エンジンで通常実行される処理は、残りの有効な処理エンジンに自動的に再分散されます。 すべての処理エンジンを無効にすると、処理がレポータ・システムに戻ります。
例13-4 処理エンジンの削除
処理エンジンを削除すると、関連するすべての情報(データベース・リンクなど)がRUEIデプロイメントからパージされます。 ただし、処理エンジン・データベース内の情報は保存されます。 このため、以前に削除した処理エンジン・システムを再登録する場合、データベース内のデータをレポータで引き続き使用できます。
RUEI内で、ネットワーク・データ・ベースの収集に対して監視対象のTCPポートを指定して、トラフィック監視の有効範囲を制御します。 監視対象外のポートについての情報は表示されません。 監視対象および監視対象外のTCPポート(HTTPおよびHTTPSの両方)の選択について、注意深く確認することをお薦めします。
現在監視対象であるポートを表示するには、構成→セキュリティ→プロトコルの順に選択します。 例を図13-13に示します。
図13-13 監視対象のポート
この設定を変更する手順は、次のとおりです。
表13-3 プロトコル設定
| プロトコル | 説明 |
|---|---|
HTTP/Formsサーブレット・モード |
プロファイルのコレクタがFormsサーブレット・トラフィックをリスニングするポートを指定します。 このオプションは、Ebsベースのトラフィックにのみ適用できます(「Oracle FormsおよびOracle E-Business Suiteのサポート」を参照)。 |
Formsソケット・モード |
プロファイルのコレクタがソケット・モードのFormsトラフィックをリスニングするポートを指定します。 このオプションは、Ebsベースのトラフィックにのみ適用できます(「Oracle FormsおよびOracle E-Business Suiteのサポート」を参照)。 |
HTTP |
プロファイルのコレクタがHTTPトラフィックをリスニングするポートを指定します。 この設定は純粋なHTTPトラフィックに対してのみ使用してください。 |
HTTPSプロキシ |
SSLトラフィックの送信先のプロキシ・サーバーのポート番号を指定します。
|
HTTPS |
プロファイルのコレクタがHTTPSトラフィックをリスニングするポートを指定します。 インストール時には、デフォルトの監視対象ポートとしてHTTPSポート443が定義されます。 |
図13-14に示すようなダイアログが表示されます。
図13-14 コレクタ・ポートの編集ダイアログ
ポート番号の他に、ネットワーク・フィルタを使用しても、監視するトラフィックの有効範囲を管理できます。 また、監視対象を特定のサーバーやサブネットに制限したり、パケットの取得レベルを制限できます。
ネットワーク・フィルタを定義または変更する手順は、次のとおりです。
図13-15 ネットワーク・フィルタパネル
例13-5 ネットワーク・フィルタの適用の理解
ネットワーク・トラフィックは、定義されているフィルタの総合的な処理に基づいて監視されています。 たとえば、定義されているすべてのポート番号でトラフィックが監視されます。 同様に、定義されているネットワーク・フィルタ(サーバーIPアドレス範囲など)もすべて監視されています。 このルールには1つだけ例外があり、それがVLANフィルタの使用です。 有効にすると、指定したVLAN IDを持つVLANトラフィックのみが監視されます。 これを有効にしてVLAN IDを指定しない場合は、すべてのVLANトラフィックが監視されます。
フィルタを定義すると、監視対象の有効範囲を特定のサーバーやサブネットに制限できます。 この機能は、少なくとも1つのコレクタがコレクタ・プロファイルに割り当てられている場合にのみ使用できます。 次を実行します。
図13-16 ネットワーク・フィルタの追加ダイアログ
VLANフィルタを使用すると、監視対象トラフィックを特定のサーバーおよびサブネットに限定できます。 VLANフィルタを定義する手順は、次のとおりです。
図13-17 VLANフィルタの構成ダイアログ
ネットワークおよびVLANフィルタを使用できる以外にも、他のフィルタが適用された後に残るトラフィック全体のどの程度を実際に監視するかも指定できます。 デフォルトでは、残るすべてのトラフィックが監視されます。
トラフィック全体の監視レベルを指定する手順は、次のとおりです。
図13-18 トラフィック全体の制限ダイアログ
例13-6 トラフィック・モニタリング
前述の設定では、合計ネットワーク・トラフィックの何分の1を測定するかを指定しています。 したがって、トラフィックの1/2を監視対象とするよう指定した場合は、監視対象の1/2のみがレポートされます。 100%未満の設定を使用する場合、レポートされる情報は実際のトラフィック全体ではなく選択したサンプルを反映していることを忘れないようにしてください。
トラフィックの監視はIPアドレスに基づいて行われます。 このことは、使用する設定に関係なく、すべてのユーザー・セッションが記録されることを意味します。 ただし、これらのセッションの数は選択した設定によって決まります。
ロード・バランシングおよびトラフィック・サンプリング定義によってネットワーク・トラフィックの正しくない監視が生じる可能性があることを理解してください。 たとえば、選択したプロファイルに16個のコレクタが割り当てられていない場合に、ロード・バランシング部16で分割されたすべてのトラフィックを選択できます。 同様に、トラフィック・サンプリング部トラフィックの1/8 - パート1を選択して、選択したプロファイルに8個のコレクタを割り当て、それぞれでネットワーク・トラフィックの同じ部分を監視できます。 このため、次の点を確認する必要があります。
RUEIデプロイメントがネットワーク・インフラストラクチャ内の異なる監視ポイントに接続されるコレクタを取り込む場合は、トラフィック・サンプリングのみ指定されます。
ロード・バランシングを使用する場合、選択したオプションがプロファイルに割り当てられるコレクタの数と一致する必要があります。
注意:
ネットワーク・インフラストラクチャの完全な知識を持つユーザーがネットワーク・フィルタ定義を確認することを強くお薦めします。
プロファイルのコレクタの追加および削除
プロファイルのコレクタを追加または削除する場合にネットワーク・フィルタ定義は自動的に更新されず、そのような変更によってネットワーク・トラフィックが欠落または何度も処理される場合に警告は生成されないので注意してください。 このため、コレクタ・プロファイル設定を変更した後、ネットワーク・フィルタ定義を注意して確認する必要があります。
暗号化データ(HTTPSやSSLなど)を監視するようRUEIを構成できます。 この構成を行うには、WebサーバーのSSL秘密キーのコピーをRUEIにインポートする必要があります。 暗号化されたコンテンツを監視するための証明書をインポートする手順は、次のとおりです。
図13-19 SSLキーのステータス
SHA1フィンガープリントは、SHA1アップロードされたRSAキーの証明書部分のダイジェストです。 SHA1フィンガープリント列は、アップグレード・スクリプトの実行後に既存のキーに対してのみ表示されます。
例13-7 サポートされている暗号化プロトコルとメカニズム
Message Authentication Code(MAC)では、MD5、SHA-1およびSHA-2機能がサポートされます。 暗号化プロトコルSSL v3、TLS v1.0、TLS v1.1およびTLS v1.2がサポートされています。 現在サポートされている暗号化アルゴリズムの完全なリストは、コレクタ統計ウィンドウのSSL接続セクションに表示されます(「コレクタのステータスの表示」を参照)。
例13-8 SSLトラフィックのモニタリング
SSLトラフィックおよびOracle Formsトラフィックは両方とも、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。 これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。 また、「強く」では、コレクタの統計ウィンドウ(「コレクタのステータスの表示」を参照)に表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認することをお薦めします。 TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。
例13-9 秘密鍵抽出の失敗の例
秘密キーのロードに失敗した場合、パスワードが間違っている、証明書が格納されているファイルや秘密キーの破損などの理由が考えられます。
ファイルに複数の証明書(認証局(CA)証明書など)が含まれている場合もアップロードは失敗する場合があります。 これを修正するには、手動で証明書を編集してから別の証明書を削除します。 ファイルがPKCS12;コンテナの場合は、次のコマンドを使用して、クライアントとサーバーの証明書のみが含まれるpemファイルに変換
openssl pkcs12 -in PKCS12-FILE -out <PEM-File> -nodes -clcerts
ここで、PKCS12-FILEはPKCS12;コンテナ・ファイルの名前です。
オプションで、保留中のSSLキーの有効期限に関する通知を構成できます。 これにより、新規のキーのインポートを計画でき、新規のキーを取得してアクティブ化する間に監視対象データにずれが生じることがなくなります。 次を実行します。
図13-21 SSLキーの有効期限の監視ダイアログ
注意:
期限切れのSSLキーがないかどうかのチェックが、1日に1回6:00AM(レポータ・システム時間)に実行されるようスケジュールされます。
RUEIインストールは機密情報をログに記録しないように構成できます。 これをマスキングと呼びます。これによって、パスワード、クレジット・カード情報などの機密情報をディスクに記録しないようにできます。
RUEIのセキュリティ機能によって、POST URL引数、HTTPヘッダー、Cookieとその値、Oracle Forms要素およびURLの内容のログを制御できます。
マスキングを実装する手順は、次のとおりです。
構成→セキュリティ→マスキングの順に選択し、構成するHTTPプロトコル・アイテムについて適切なオプションを選択します。 たとえば、URL POST引数マスキングなどです。 図13-22に示すようなウィンドウが表示されます。
選択したHTTPプロトコル・アイテムについて現時点で定義されているマスキングが表示されます。
既存の項目の使用中リストをクリックして、使用状況の情報を表示します。 例を図13-23に示します。
この場合、選択したURL POST引数をアプリケーションのユーザーIDスキームの一部として使用し、RUEIの内部トラフィック検出の一部としても使用することを示します。 これらの自動的に検出された項目は、後の項で説明します。
新規マスキングの追加をクリックして新規マスキングを定義します。 図13-24に示すようなダイアログが表示されます。
ログを制御するアイテムの名前を指定します。 選択したプロトコル・アイテムに応じて、POST URL引数の名前、Cookie名または値、Oracle Forms要素、HTTPヘッダー内のアイテム、またはURL接頭辞を指定します。
定義するアイテムに割り当てるマスキング・アクションを選択します。 表13-5に、URL接頭辞以外のプロトコル・アイテムで使用可能なオプションを説明します。
表13-5 マスキング・アクション
| オプション | 説明 |
|---|---|
デフォルト |
選択したHTTPプロトコル・アイテムの定義済デフォルト・アクションをこのアイテムに対して実行するように指定します。 この機能の使用方法は次の項に記載されています。 |
ハッシュ済 |
計算されたハッシュ値でアイテムの内容を置き換えてログに記録するように指定します。 ハッシュは比較に使用可能な一意の値であるものの、判読可能な形式ではありません。 たとえば、5つの異なるユーザーIDでログインすると、5つの異なるハッシュを受け取りますが、同じビジターによる複数セッションでは、同じハッシュを受け取ります。 この作成された(ハッシュされた)値には一意性がありますが、それ自体は実質的な値ではありません。 |
ブラインド済 |
アイテムの元の内容をXで置き換えてログに記録するように指定します。 |
プレーン |
アイテムを元の状態のままログに記録するように指定します。 つまり、保護されません。 |
切捨て |
HTTPプロトコル・アイテムの最初の1KB分の文字のみがログに記録されるように指定します。 1KBより長い値の場合は、その値が切り捨てられてハッシュされたアラームが、(ハッシュされていない)プレーン・データの最初の1KBに追加されます。 このような方法で、一意性が保持されます。 |
次に、保存をクリックします。 指定した変更は5分以内に有効になります。
URL要素のマスキング
URL POST引数、Forms要素、CookieおよびHTTPヘッダーの他に、接頭辞を指定してURLの特定の内容を保護することもできます。 この機能が役立つのは、機密情報を含む可能性があるURL構文を保存できないようにする場合です。
URLコンポーネントを(データ・ブラウザ・グループ内の情報およびセッション診断機能が導出される)コレクタ・ログ・ファイルに保存するかどうかを指定します。 表13-6に使用可能なマスキング・アクションを示します。
表13-6 URL接頭辞マスキング・アクション
| マスキング・アクション | 説明 |
|---|---|
ロギング |
(他のすべての定義済マスキングを適用後)URLコンポーネントをコレクタ・ログ・ファイルに保存するよう指定します。 これはデフォルトです。 |
ロギングは行われません |
コレクタ・ログ・ファイルに何も保存しないように指定します。 |
URLプレフィクス・マスキング・アクションがロギングなしに設定されている場合、これもリプレイ・アクションになります。 「リプレイ・ポリシーの制御」で説明されているように、これは最初にマスキング・アクションを変更しないかぎり変更できません。
注意:
URL接頭辞のデフォルトのマスキング・アクションがロギングなしに設定されている場合、データはコレクタ・ログ・ファイルに書き込まれず、レポートに何も使用できません。 このため、記録されるURLコンポーネントのホワイトリストを最初に定義した場合のみ、このオプションを選択する必要があります。
デフォルトのマスキング・アクションの指定
前述のように、デフォルト設定では、セキュリティ定義においてアクションが明示的に指定されないHTTPプロトコル・アイテムに対して実行する必要があるアクションが指定されます。 デフォルトアクションのアイテムを定義すると、1回の操作で多数のデータ・アイテム(表示されているアイテムと非表示のアイテムの両方)のセキュリティ設定を変更できます。
デフォルト・アクションを指定する手順は、次のとおりです。
例13-10 自動表示アイテム
明示的に定義するHTTPプロトコル・アイテムのマスキングに加えて、構成時にRUEIで自動的に検出されるアイテムもあります。 たとえば、URL POST引数pagelabelを使用してWebLogic Portalアプリケーションを追跡し、HTTPヘッダーAccept-Languageを使用してエンド・ユーザーの言語プリファレンスを決定します。 これらのアイテムは、システムとして使用中列に示されます。 一般的に、マスキング・アクションプレーンを受信します。これは、関連付けられているアイテムが元の状態で記録されることを意味します。 アクションは、ネットワーク・トラフィックの正確な監視のために必要であり変更できません。
セッションのトラッキングが一部の標準テクノロジ(ApacheやColdFusionなど)に基づいている場合、Cookieは使用場所の項で報告されません。 このようなCookieは手動で定義されて、デフォルト値以外に構成されていないかぎり、デフォルト・マスキング・アクションが割り当てられています。 デフォルト・マスキング・アクションがブラインド済に設定されていない場合、問題はありません。 設定されていると、すべてのビジター・セッションが1セッションに記録されます。
例13-11 認可フィールドのマスキング
「ユーザー識別の定義」で説明しているように、ユーザーの識別は、まず「HTTP認可」フィールドに基づいて行われます。 この情報がネットワーク上でプレーン形式で送信されると、ユーザー名とパスワードをデコードされる可能性があり、セキュリティ問題が生じることに注意してください。 これは、基本的な認証プロトコルの制限です。
認証フィールドがネットワーク上でプレーン形式で送信される場合は、前のセクションで説明したマスキング・オプションを使用して、Replay Viewerに保存する内容を制御できます。 または、認証がネットワーク・トラフィックに含まれるときにハッシュされるようにすることができます。 この場合、セッション診断でユーザーIDを使用できません。
例13-12 Cookie値マスキング
cookie値 -1は自動的にマスキング・アクション"Plain" (つまり、元の状態で保持されます)に割り当てられます。 これが必要な理由は、Oracle E-Business Suite内ではセッションの終了を示すためにこの値が頻繁に使用されるからです。
例13-13 重要
マスキング機能を使用する場合には、次の点に特に注意する必要があります。
定義するマスキング・アクションはすべての監視対象ドメインに適用されます。
すべてのマスキングされたHTTPプロトコル・アイテム(URL接頭辞を除く)では、大/小文字が区別されません。
複数の(重なり合う)アイテム定義が可能ですが、一致部分が長い方の指定が、割当てのマスキング・アクションとして使用されます。
定義済のマスキング・アイテム(たとえば、「カスタム・ディメンションの操作」で説明されているカスタム・ディメンション・アイテム)を削除した後、そのマスキング・アクションを変更していない場合、そのアイテムは表示されるアイテム・リストから自動的に削除されます。 ただし、定義済アクションを事前に変更していた場合は、アイテム・リストから明示的にアイテムを削除する必要があります。
多言語キャラクタ・セットを使用する場合のデータ・マスキング操作の詳細は、「各国語サポートの使用」を参照してください。
「エンリッチ・データのエクスポート機能」で説明しているように、RUEIによって収集されたデータをエクスポートして、他のデータ・ウェアハウス・データと組み合せることができます。 RUEIでマスキングしたデータ・アイテムはマスキングされたままエクスポートされるため、外部アプリケーションで使用されるデータ・アイテムの要件をよく確認することをお薦めします。 マスキング機能の設定ウィンドウで、セキュリティ要件を確認するために最適な監査ツールが提供されます。
データ・アイテムのセキュリティを変更するときは、ログ・ファイルにすでに保存されているデータは変更の影響を受けないことに注意してください。 必要に応じて、システムのパージを検討する必要があります(これについては、「システムのリセット」で完全に説明されています)。
すべての機密データが間違いなくマスキングされていることを定期的に検証することを強くお薦めします。 通常、アプリケーションは時間とともに変化し、それに伴ってPOST変数、Cookie、ヘッダー、URL構文の使用方法も変化します。 コレクタおよびレポータのRAWログ・ファイルは、ディレクトリ/var/opt/ruei/processor/dataを参照してください。 セッション診断のエクスポート機能を使用して、これらのファイルの内容を監査することもできます。 これについては、「フル・セッション情報のエクスポート」で説明しています。
「ユーザー情報のマスキング」で説明するマスキング機能を使用すると、ヘッダー、URL、cookie、およびOracle Forms要素内の引数のマスキング・ポリシーを定義できます。 また、フル・セッション・リプレイ(FSR)機能内で表示されるアプリケーション・ページの実際のコンテンツについて、マスキング・ポリシーを定義することもできます。 これは、実際のWebサーバー・コンテンツ内の機密情報(パスワードおよびクレジット・カード情報など)へのアクセスを制限する場合に特に有用です。
ページ・コンテンツのマスキング・ポリシーを定義するには、次の手順を実行します。
注意:
ユーザー・インタフェースに表示されているデータはマスキングされていますが、ディスク上にはマスキングされていない状態で格納されます。
例13-14 XPath検索式の設計
目的のページ・コンテンツを検索するための正確なXPath検索式は、アプリケーション・ページの構造に応じて異なります。 次のリクエストおよびレスポンス・フラグメントを確認します。
POST /cgi-bin/post HTTP/1.1
Accept: */*
Connection: keep-alive
Content-Length: 97
Content-Type: text/xml
Host: myshop.com
Pragma: no-cache<user><CardName>AMEX</CardName><CardExp>150606</CardExp><CardNo>12345-12345-12345</CardNo></user>
HTTP/1.1 200 OK
Date: Fri, 03 Aug 2012 08:29:01 GMT
Server: Apache/2.2.3 (Oracle)
Connection: close
RUEI-Transfer-Encoding: chunked
Content-Type: text/xml
<?xml version="1.0"?>
<info>
<request>
<action>do_refund</action>
<meta>
<merchantid>8500</merchantid>
<ipaddress>10.69.10.214</ipaddress>
<version>1</version>
</meta>
<params>
<payment>
<orderid>2012050901</orderid>
<countrycode>nl</countrycode>
<paymentproductid>1</paymentproductid>
<amount>100</amount>
<currencycode>eur</currencycode>
<creditcardnumber>12345-12345-12345</creditcardnumber>
<expirydate>150606</expirydate>
</payment>
</params>
</request>
</info>
ユーザーのクレジット・カード番号がリクエストおよびレスポンスの両方に表示されます。 このため、セッション診断内で完全にマスキングするには、次の2つのマスキング・アクションを定義する必要があります。
検索タイプ: リクエスト・コンテンツ内のXPathの検索 検索値: //CardNo
検索タイプ: レスポンス・コンテンツ内のXPathの検索 検索値: //creditcardnumber
クレジット・カードの関連情報(有効期限など)をマスキングするには、追加のアクションを定義する必要もあります。
例13-15 重要
この機能内で定義されるマスキング・ポリシーは、アプリケーション・ページのFSR機能内の表示方法にのみ適用され、RUEIインストール内の記憶域には適用されません。
デフォルトでは、すべてのSSLクライアント証明書プロパティ(ある場合)は、各コレクタ・システムで生成されるログ・ファイルの一部として記録されます。 これが組織のセキュリティ・ポリシーにそぐわない場合は、次の手順を実行します。
図13-27 コレクタのSSLクライアント証明書のマスキング・ポリシー
図13-28 コレクタのSSL証明書マスキングの編集ダイアログ
表13-7に示すオプションがあります。
表13-7 SSL証明書マスキング・アクション
| オプション | 説明 |
|---|---|
すべての証明書のプロパティを記録 |
SSL証明書全体をログに記録するように指定します。 これはデフォルトです。 |
セッションIDのみを記録 |
セッションID情報のみを記録するように指定します。 |
証明書のプロパティが記録されていません |
SSL証明書をまったくログに記録しないように指定します。 |
目的のマスキング・アクションを選択します。 次に、保存をクリックします。
次の手順では、データ保存を構成し、アプリケーション・ベースまたはコレクタ・ベースで現在のディスク使用状況を監視できます。 コレクタのデータ保存は、次の基準を使用して構成できます。
サイズ・ベース - サイズ割当て(X GB)が満たされるとデータが破棄されます。
時間ベース - 定義された期間(N日間)が経過するとデータが破棄されます。
記憶域にはN日を超える分のデータは含まれず、記憶域がX GBを超えるディスク領域を占有することはありません。 この手順では、サイズ・ベースのデータ保存ポリシーを構成する方法について説明します。 時間ベースのデータ保存はレポータ保存ポリシーに関連しており、「レポータの保存ポリシーの定義」で説明されています。
サイズ・ベースのコレクタ保存ポリシーはアプリケーション/スイート単位で指定できますが、時間ベースのコレクタ/レポータのデータ保存ポリシーはこの単位で指定できません。
レポータに登録済のコレクタで使用されるサイズ・ベースのデータ保存ポリシーを指定する手順は、次のとおりです。
図13-29 コレクタ・データ保持ポリシー
図13-30 エラー・ページ・リプレイ格納サイズダイアログ
アプリケーション、スイートまたはサービスの選択したプロファイル内のすべてのコレクタについて、FSRまたはEPRデータのために予約しておくディスク領域の最大容量を指定します。
図13-31 リプレイのデフォルトの設定ダイアログ
リプレイ記憶域をデフォルトで有効化するかどうか、および各コレクタ・システムのFSRとEPRデータ用に予約するディスク領域の最大量を指定します。
例13-16 重要
以下の点に注意します。
リプレイ機能は、ネットワーク・データ・コレクタを使用している場合に使用できます。 タグ・データ・コレクタのみを使用している場合、この機能は使用できません。
関連付けられているコレクタ・プロファイルのリプレイ記憶域の有効化以外に、アプリケーション、スイートまたはサービスについてリプレイ・データを使用可能にする場合、リプレイ・ロギング・ポリシーが適切に設定されていることも確認する必要があります。 これについては、「リプレイ・ポリシーの制御」で説明しています。
アプリケーションで使用可能な再生用のディスク領域を、現在使用中の容量よりも減らすと、再生データ・ストアのサイズを調整するために、ストアの最も古いデータが削除されます。 たとえば、アプリケーションのFSRデータ・ストアを20GBから10GBに減らすように指定し、現在14GBが使用されているとします。 この場合、ストアのサイズを調整するために、現在のFSRデータ・ストアの最も古い4GB分が削除されます。
この項の冒頭で説明したように、データ保存は時間および領域の割当てによって制限されます。
FSR期間が15分未満の場合、エラー・リプレイ機能が正常に実行されない場合があります。 また、0に設定されると、EPRサイズ設定を変更できなくなります。
コレクタ・ビュータブをクリックして、レポータ・システムに接続された各コレクタの使用できるおよび使用されたリプレイ・データ記憶域、期間および最新の更新を表示できます。 これを定期的に確認してレポート要件を満たしていることを確認することをお薦めします。
例13-17 リプレイ・データのパージ
アプリケーションまたはスイートが削除されるとき、関連するFSRおよびEPRデータはコレクタ・システムから自動的に削除されません。 引き続き表示することができます。 このデータを削除する場合、リプレイ・アクティブ列に表示されている削除アイコンをクリックする必要があります。 データの削除を確認するように求められます。
RUEIで使用されるリプレイ・ビューアに書き込まれる情報を制御することができます。 リプレイ・アクションを監視中のすべてのトラフィックに適用するか、特定のIPアドレス範囲に適用するかを指定できます。 また、接頭辞を指定することによって、特定のURLコンテンツをログに記録する方法も制御できます。 RUEIのデプロイメントでリプレイ・ポリシーを指定するには、次の手順を実行します。
例13-18 リプレイ・アクションの適用方法の理解
次の点を理解してください。
マスキング・アクション・ロギングなしが明示的に定義されているURLプレフィクスのリプレイ・アクション(「ユーザー情報のマスキング」を参照)は、自動的にリストされたアイテムとして表示され、変更できません。 例(/bin)を図13-36に示します。 これらの項目を変更する場合、最初にマスキング・アクションをロギングに変更する必要があります。
表13-8に記載されているリプレイ・アクションは、リプレイ・ビューア機能に記録されている項目を制御します。 表13-9に、各リプレイ・アクション内で記録される部分を示します。
表13-9 リプレイ・アクション内に記録される項目
| マスキング・アクション | リクエスト・ヘッダー | リクエスト本文 | レスポンス・ヘッダー | レスポンス本文 | コレクタ・ログ・ファイルへの記録 |
|---|---|---|---|---|---|
完全ロギング |
X |
X |
X |
X |
X |
リクエスト本体なし |
X |
X |
X |
X |
|
ヘッダーのみ |
X |
X |
X |
||
リプレイなし |
X |
リプレイ・ビューアで確認用にログ・アイテムを使用できる期間は、各監視対象アプリケーションに指定されるエラー・ページ・リプレイ(EPR)およびフル・セッション・リプレイ(FSR)によって決定されます。 このため、レポート要件を満たす十分な記憶域が割り当てられていることを確認する必要があります。 これらの設定については、「コレクタのデータ保存ポリシーの定義」で説明します。
例13-19 URLプレフィクスの適用方法の理解
次の点を理解してください。
アクティブなIPアドレス範囲にURL接頭辞のリプレイ・アクションが定義されていると、デフォルトのリプレイ・アクションより優先されます。
一致するURL接頭辞が重複する場合(たとえば、/ruと/rueiなど)には、別々のリプレイ・アクションが割り当てられ、最長一致が採用されます。 また、プレフィクスはtrueのプレフィクスにする必要があります。 たとえば、対象のURLが/app/rueiの場合は、/ruも/rueiも一致しません。
URL接頭辞に疑問符(?は)指定できません。 指定すると、疑問符とその後の内容がすべて無視されます。 たとえば、URL /catalog/jn.php?itemと指定すると、切り捨てられて/catalog/jn.phpになります。 URLは判読可能な形式で(エンコーディングではなく)指定する必要があります。
URL接頭辞は大/小文字が区別されます。
デフォルトでは、レポータに接続されているコレクタは、ペイロード・サイズが64KBまでの受信フレームのみを監視します。 これにより、ネットワーク・ドライバでTCPセグメンテーション・オフロードを使用している場合に、RUEIはトラフィックを監視できます。 場合によっては、メモリー使用量を削減して、メモリーに保持できるフレーム数を増やすために、最大フレーム・サイズを大きくする必要があります。 最大フレーム・サイズを削減する手順は、次のとおりです。
表13-10に、メモリーに保持できるフレーム数を示します。
表13-10 最大フレーム・サイズ、フレーム数およびバッファ・サイズ
| 最大フレーム・サイズ | フレーム数 | バッファ・サイズ |
|---|---|---|
64K 「脚注1」 |
8K |
512MB 「脚注2」 |
32K |
16K |
512MB |
16K |
32K |
512MB |
8K |
64K |
512MB |
4K |
64K |
256MB |
2K |
64K |
128MB |
脚注1
デフォルト。
脚注 2
フレームの数は自動的に適応されます。
このため、監視対象トラフィック内の予想される最大フレーム・サイズを超える最大フレーム設定を行わないことをお薦めします。 コレクタ統計機能の「インタフェース」タブで、各コレクタが検出した最大フレーム・サイズを確認できます(「コレクタのステータスの表示」を参照)。
トラブルシューティングの手順の詳細は、「RUEIインストレーション・ガイド」の「トラブルシューティング」付録を参照してください。
