機械翻訳について

13 セキュリティ関連情報の管理

この章では、トラフィックの監視のためにRUEIで使用されるコレクタ・プロファイルの使用方法およびセキュリティ関連設定の構成方法について説明します。 また、ネットワーク・フィルタを設定して、特定のネットワーク、ホスト、仮想Local Area Network(VLAN)が取得されないようにしたり、監視対象トラフィック全体を減らす方法についても説明します。 機密データのセキュリティを維持するために、HTTPプロトコル・アイテム(HTTPヘッダー、Cookieなど)のマスキング・アクションを指定することもできます。 また、暗号化で保護されたトラフィックを処理するWebサーバーの秘密キーの管理についても説明します。

すべてのセキュリティ関連情報の管理は、セキュリティ担当者が担当します。

コレクタ・プロファイルの管理

コレクタの管理を容易にするため、各コレクタは1つのコレクタ・プロファイルに割り当てられます。 コレクタ・プロファイルの構成が変更された場合、それらは割当て済のすべてのコレクタに自動的に適用されます。

インストール時に、次の2つの事前定義済のコレクタ・プロファイルが作成されます。

• システム・ネットワーク・データ・コレクタ(ネットワーク・ベースのデータ収集の場合)

• システム・タグ・サーバー(タグ・ベースのデータ収集の場合)

レポート要件に応じて追加のプロファイルを作成するには、既存のプロファイルをコピーして、それを新規プロファイルのベースとして使用します。 ユーザー定義のコレクタ・プロファイルとは異なり、システム・コレクタ・プロファイルは削除できません。

現在使用可能なコレクタ・プロファイルを表示するには、「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。 例を図13-1に示します。

図13-1 コレクタ・プロファイル・パネル

「図13-1 コレクタ・プロファイル・パネル」の説明

各コレクタ・プロファイルでは、表13-1に示すオプションをコンテキスト・メニューで使用できます。

表13-1 コレクタ・プロファイルのコンテキスト・メニュー

オプション	説明
構成	選択したプロファイルに割り当てられているすべてのコレクタの構成を指定できます。 それには、ネットワーク・フィルタ、コレクタでリスニングするTCPポート、およびセキュリティで保護されたトラフィックの復号化に使用する秘密キーの使用が含まれます。 これについては、「コレクタ・プロファイル構成の変更」で説明しています。 プロファイルの構成を変更した後に、プロファイルに割り当てられているコレクタを自動的に再起動するか、または手動による再起動を要求するメッセージを表示するかを指定できます。 これについては、「コレクタの再起動」で説明しています。
コピー	選択したコレクタ・プロファイルを新規プロファイルのベースとして使用します。 これについては、「コレクタ・プロファイルの作成」で説明しています。
プロパティの編集	コレクタ・プロファイルの名前および簡単な説明を変更できます。 デフォルトのコレクタ・プロファイルのプロパティは変更できません。
削除	選択したコレクタ・プロファイルを削除します。 選択したプロファイルにコレクタが割り当てられている場合、これらはデフォルト(システム)コレクタ・プロファイルに自動的に再割当てされます。 デフォルトのコレクタ・プロファイルを削除することはできません。

コレクタ・プロファイルの作成

新規コレクタ・プロファイルを作成する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。 現時点で定義されているコレクタ・プロファイルが表示されます。 例を「図13-1」に示します。
2. 新規プロファイルのベースとして使用するコレクタ・プロファイルのコンテキスト・メニューで「コピー」を選択します。 図13-2に示すダイアログが表示されます。

   図13-2 「コレクタ・プロファイルのコピー」ダイアログ

   
   

   
   「図13-2 「コレクタ・プロファイルのコピー」ダイアログ」の説明

   
   
3. 新規コレクタ・プロファイルに一意の名前および必要に応じて簡単な説明を指定します。 この説明にはプロファイルの目的と有効範囲を示すことをお薦めします。 次に、「保存」をクリックします。 新規プロファイルが作成されると、使用可能なコレクタ・プロファイルのリストに表示されます(図13-1)。
4. 新規コレクタ・プロファイルを監視要件に応じて構成します。 これについては、「コレクタ・プロファイル構成の変更」で説明しています。

コレクタ・プロファイルの構成の変更

作成された新規プロファイルの構成は、ベースとなるプロファイルと同じです。 その構成を要件に応じて変更する手順は、次のとおりです。

1. 使用可能なコレクタ・プロファイルのリスト(図13-1)から目的のプロファイルをクリックするか、コンテキスト・メニューで「構成」を選択します。 ウィンドウが開き、選択したプロファイルに現在割り当てられているコレクタが表示されます。 例を「図13-3」に示します。

   図13-3 「ネットワーク・データ・コレクタ・ステータス」ウィンドウ

   
   

   
   「図13-3 「ネットワーク・データ・コレクタ・ステータス」ウィンドウ」の説明

   
   
2. 「構成」メニュー→「構成」の順に選択して、コレクタ・プロファイルの構成を変更します。 表13-2に示すオプションがあります。

   表13-2 コレクタ・プロファイルの「構成」のオプション

   オプション	説明
   プロトコル	プロファイルに割り当てられているコレクタでリスニングするTCPポートを指定するには、このオプションを選択します。 これについては、「ネットワーク・ベースのモニタリングの有効範囲の管理」で説明しています。
   ネットワーク・フィルタ	プロファイルに割り当てられているコレクタの監視対象をネットワーク・トラフィックの特定のセグメントに制限するか、または特定のサーバーやサブネットに制限するかを指定するには、このオプションを選択します。 これについては、「ネットワーク・フィルタの定義」で説明しています。
   SSLキー	暗号化されたコンテンツを監視するため、プロファイルに割り当てられている各コレクタにインポートする証明書を指定するには、このオプションを選択します。 これについては、「SSL鍵の管理」で説明しています。
   コレクタ再起動メソッド	構成を変更した後で、プロファイルに割り当てられているコレクタを自動的に再起動するかどうか指定するには、このオプションを選択します。 これについては、「コレクタの再起動」で説明しています。

別のプロファイルへのコレクタの割当て

プロファイルに割り当てられているコレクタは、レポート要件に応じて別のコレクタに簡単に再割り当てできます。 たとえば、ネットワーク・トラフィックのパターンまたはセキュリティ要件が変更された場合などです。 コレクタを再割り当てする手順は、次のとおりです。

1. コレクタの現在の割当て先であるプロファイルを選択します。 図13-3に示すようなウィンドウが表示されます。
2. コレクタのコンテキスト・メニューで「プロファイルの割当て」オプションを選択します。 図13-4に示すダイアログが表示されます。

   図13-4 「コレクタ・プロファイルの割当て」ダイアログ

   
   「図13-4 「コレクタ・プロファイルの割当て」ダイアログ」の説明
3. コレクタの新しい割当て先となるプロファイルを選択します。 次に、「保存」をクリックします。
4. 選択したプロファイルにコレクタが割り当てられると、図13-5に示すステータス・メッセージが表示されます。

   図13-5 移動したコレクタのステータス・メッセージ

   
   「図13-5 移動したコレクタのステータス・メッセージ」の説明

   このステータス・メッセージは最大で60秒間表示されます。 その後、コレクタが自動的に再起動されるか、手動による再起動を要求するメッセージが表示されます。 詳細は、「コレクタの再起動」を参照してください。

ノート:

新規プロファイルのセグメンテーション・スキームが以前のプロファイルと異なる場合、新規プロファイルと一貫性が保たれるようにコレクタのセグメンテーション・スキームが調整されることに注意してください。 したがって、トラフィック・フィルタの設定を新規プロファイルに割り当てた後で確認することを強くお薦めします。 詳細は、「全トラフィックの制限」を参照してください。

例13-1 複数のコレクタの割当て

異なるプロファイルに複数のコレクタを割り当てる場合は、「構成」メニューの複数選択オプションを使用できます。 目的のコレクタをクリックしてから、ツールバーの「プロファイルの割当て」コマンド・ボタンをクリックします。

インタフェースへのコレクタの割当て

コレクタは、ネットワーク・ベースにもタグ・ベースにもでき、別のインタフェースに関連付けることができます。 コレクタをインタフェースに割り当てるには:

1. 「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。 現時点で定義されているコレクタ・プロファイルが表示されます。 例を「図13-1」に示します。
2. 変更するコレクタに移動します。 図13-3に示すようなウィンドウが表示されます。 変更するコレクタを右クリックします。
3. コレクタのコンテキスト・メニューから「ネットワーク・インタフェースの割当て」オプションを選択します。 図13-4に示すダイアログが表示されます。

   図13-6 コレクタ・ネットワーク・インタフェース

   
   「図13-6 コレクタ・ネットワーク・インタフェース」の説明
4. タグ・ベースの収集の場合、「IPありのインタフェース」を割り当てる必要があります。 ネットワーク・ベースの収集の場合、「IPなしのインタフェース」を割り当てる必要があります。 あるいは、「指定されたインタフェース」を選択して、すべてのインタフェースを表示し、個々に選択します。 次に、「保存」をクリックします。

新規コレクタの接続

新規コレクタをシステムに登録する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。 現時点で定義されているコレクタ・プロファイルがリストされます。 例を「図13-1」に示します。
2. 新規リモート・コレクタを登録するプロファイルを選択します。 または、コンテキスト・メニューで「構成」を選択します。 選択したプロファイルに現在割り当てられているコレクタがリストされます。 例を「図13-3」に示します。
3. 「構成」メニューで「リモート・コレクタの登録」オプションを選択します。 図13-7に示すダイアログが表示されます。

   図13-7 「コレクタの登録」ダイアログ

   
   「図13-7 「コレクタの登録」ダイアログ」の説明
4. 新規コレクタ・システムのIPアドレスおよび必要に応じて簡単な説明を指定します。 これには、その有効範囲と目的を示すことをお薦めします。 次に、「登録」をクリックします。 コレクタ・システムの構成要件は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。

コレクタの再起動

コレクタ・プロファイルでなんらかの構成を変更した場合、変更を有効にするには、そのプロファイルに割り当てられているすべてのコレクタを再起動する必要があります。 この再起動は自動(デフォルト)または手動のいずれかで実行できます。 コレクタの再起動の方法を構成する手順は、次のとおりです。

1. 使用可能なコレクタ・プロファイルのリスト(図13-1)から目的のプロファイルをクリックするか、コンテキスト・メニューで「構成」を選択します。 ウィンドウが開き、選択したプロファイルに現在割り当てられているコレクタが表示されます。 例を「図13-3」に示します。
2. 「構成」メニュー→「構成」→「コレクタ再起動メソッド」の順に選択します。 図13-8に示すダイアログが表示されます。

   図13-8 「コレクタ再起動メソッドの編集」ダイアログ

   
   

   
   「図13-8「コレクタ再起動メソッドの編集」ダイアログ」の説明

   
   
3. 「再起動メソッド」メニューを使用して、選択したプロファイルに割り当てられているコレクタを、プロファイルの構成を変更した後で自動的に再起動(デフォルト)するか、または手動による再起動を要求するかを指定します。 次に、「保存」をクリックします。

例13-2 手動によるコレクタの再起動

「ネットワーク・データ・コレクタの構成」ウィンドウに再起動を要求するメッセージが表示されるまで、コレクタは再起動できません。 例を図13-9に示します。

図13-9 再起動を待機中のコレクタ

「図13-9 再起動を待機中のコレクタ」の説明

個々のコレクタを再起動するには、コンテキスト・メニューで「再起動」を選択します。 コレクタ・プロファイルに多数のコレクタが含まれる場合は、「構成」メニューの「すべてのコレクタの再起動」オプションを使用すると便利な場合があります。

コレクタの無効化および登録解除

リモート・コレクタ・システムでメンテナンスまたはトラブルシューティングを実行するときは、コレクタ・インスタンスを停止する必要が生じる可能性があります。 この場合は、コレクタのコンテキスト・メニューで「無効化」を選択します。 次に、「再起動」オプションを選択すると、コレクタに監視を再開するように指示できます。

リモート・コレクタ・システムが廃止された場合は、インストール済RUEIからそれを削除する必要があります。 それには、コレクタのコンテキスト・メニューで「登録解除」オプションを選択します。 確認後に、レポータのコレクタ・システムへの接続が中止されます。 ローカル・コレクタ・インスタンスは登録解除できないことに注意してください。

ローカル・コレクタ

レポータ・システムのローカル・コレクタ・インスタンスは、System(localhost)項目で表します。 インストール後はまだ有効化されておらず、現在定義されているすべてのコレクタ・プロファイルに表示されることに注意してください。 特定のプロファイルで有効になると、選択したコレクタ・プロファイルのみで表示されます。 ローカル・コネクタ・インスタンスは登録解除できません。

処理エンジンの管理

単一システムの能力を超えて処理を拡大するために、通常はレポータによって実行されるデータ処理を負担するように1つ以上の処理エンジンを構成することができます。

RUEIのデプロイメントに処理エンジンを追加するには、次の手順を実行します。

1. 処理エンジンのインストールおよび構成手順がターゲット・システムで完了していることを確認してください。 詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
2. 「構成」、「セキュリティ」、「処理エンジン」の順に選択します。 現時点で登録されている処理エンジンがリストされます。 例を図13-10に示します。

   図13-10 「処理エンジン」ウィンドウ

   
   

   
   「図13-10 「処理エンジン」ウィンドウ」の説明

   
   
3. 「登録」をクリックします。 図13-11に示すダイアログが表示されます。

   図13-11 「処理エンジンの登録」ダイアログ

   
   

   
   「図13-11 「処理エンジンの登録」ダイアログ」の説明

   
   
4. 処理エンジン・システムのホスト名またはIPアドレスと、データベース・リンク名を指定します。 次に、「保存」をクリックします。 データベース・リンク名は、ホスト名を指定し、Oracle命名規則に従う必要があります。 たとえば、空白を含むことはできず、数字またはアンダースコアで開始することはできません。 詳細は、「Oracle Database管理者ガイド」を参照してください。
5. 新しく登録した処理エンジンは、「なし」モードで図13-10に示すリストに表示されます。 これは、まだ初期化されていないためにレポータで使用できないことを示しています。 「処理エンジン」の「モード」設定をクリックします。 図13-12に示すダイアログが表示されます。

   図13-12 処理エンジン・モード

   
   

   
   「図13-12 処理エンジン・モード」の説明

   
   
6. 「モード」メニューから「有効」を選択します。 次に、「保存」をクリックします。 短い期間の後、図13-10に示すウィンドウに戻ります。

例13-3 処理エンジンの無効化

システムのメンテナンス(パッチのインストールなど)を実行するため、処理エンジンを一時的に無効にできます。 処理エンジンを無効にする場合、次の点に注意してください。

• 処理エンジンを長期間無効にすると、短期間のデータが失われる場合があります。

• 無効になった処理エンジンで通常実行される処理は、残りの有効な処理エンジンに自動的に再分散されます。 すべての処理エンジンを無効にすると、処理がレポータ・システムに戻ります。

例13-4 処理エンジンの削除

処理エンジンを削除すると、関連するすべての情報(データベース・リンクなど)がRUEIデプロイメントからパージされます。 ただし、処理エンジン・データベース内の情報は保存されます。 このため、以前に削除した処理エンジン・システムを再登録する場合、データベース内のデータをレポータで引き続き使用できます。

ネットワーク・ベース監視の有効範囲の管理

RUEI内で、ネットワーク・データ・ベースの収集に対して監視対象のTCPポートを指定して、トラフィック監視の有効範囲を制御します。 監視対象外のポートについての情報は表示されません。 監視対象および監視対象外のTCPポート(HTTPおよびHTTPSの両方)の選択について、注意深く確認することをお薦めします。

現在監視対象であるポートを表示するには、「構成」→「セキュリティ」→「プロトコル」の順に選択します。 例を図13-13に示します。

図13-13 監視対象のポート

「図13-13 監視対象のポート」の説明

この設定を変更する手順は、次のとおりです。

1. 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。
2. ポート設定を変更するプロトコルをクリックします。 表13-3に使用可能な設定を示します。

   表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トラフィックの送信先のプロキシ・サーバーのポート番号を指定します。 SSL以外のトラフィックのみがプロキシ・ポートに送信される場合、この設定でそのポート番号を指定しないでください。 指定すると、コレクタのパフォーマンスに大きな影響を与えることがあります。 SSLトラフィックを受信するサーバー(プロキシの後ろ)のポート番号は、HTTPS設定で指定する必要があります。
   HTTPS	プロファイルのコレクタがHTTPSトラフィックをリスニングするポートを指定します。 インストール時には、デフォルトの監視対象ポートとしてHTTPSポート443が定義されます。

   図13-14に示すようなダイアログが表示されます。

   図13-14 「コレクタ・ポートの編集」ダイアログ

   
   「図13-14 「コレクタ・ポートの編集」ダイアログ」の説明
3. 新規ポート番号またはポートの範囲(80-85など)を追加するには、「ポート番号」フィールドに必要な番号を入力し、「追加」をクリックします。 リストからアイテムを削除するには、ポートの右側にある「削除」アイコンをクリックします。 次に、「保存」をクリックします。

   ノート:

   各プロトコルに指定するポート番号はコレクタ・プロファイル内で重複しないようにしてください。 つまり、1つのポート番号は、1つのプロトコルの割当てポート番号リストのみに指定する必要があります。

4. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。 これについては、「コレクタの再起動」で説明しています。

ネットワーク・フィルタの定義

ポート番号の他に、ネットワーク・フィルタを使用しても、監視するトラフィックの有効範囲を管理できます。 また、監視対象を特定のサーバーやサブネットに制限したり、パケットの取得レベルを制限できます。

ネットワーク・フィルタを定義または変更する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「ネットワーク・フィルタ」の順に選択します。
2. 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。 現時点で定義されているネットワーク・フィルタが表示されます。 例を「図13-15」に示します。

   図13-15 「ネットワーク・フィルタ」パネル

   
   「図13-15 「ネットワーク・フィルタ」パネル」の説明
3. 次の項で説明しているフィルタを使用して、監視対象トラフィックの有効範囲を管理します。
4. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。 これについては、「コレクタの再起動」で説明しています。

例13-5 ネットワーク・フィルタの適用の理解

ネットワーク・トラフィックは、定義されているフィルタの総合的な処理に基づいて監視されています。 たとえば、定義されているすべてのポート番号でトラフィックが監視されます。 同様に、定義されているネットワーク・フィルタ(サーバーIPアドレス範囲など)もすべて監視されています。 このルールには1つだけ例外があり、それがVLANフィルタの使用です。 有効にすると、指定したVLAN IDを持つVLANトラフィックのみが監視されます。 これを有効にしてVLAN IDを指定しない場合は、すべてのVLANトラフィックが監視されます。

サーバーIPアドレス・フィルタの定義

フィルタを定義すると、監視対象の有効範囲を特定のサーバーやサブネットに制限できます。 この機能は、少なくとも1つのコレクタがコレクタ・プロファイルに割り当てられている場合にのみ使用できます。 次を実行します。

1. 「新規フィルタの追加」をクリックして新しいフィルタを定義するか、または既存のフィルタをクリックして変更します。 図13-16に示すダイアログが表示されます。

   図13-16 「ネットワーク・フィルタの追加」ダイアログ

   
   「図13-16 「ネットワーク・フィルタの追加」ダイアログ」の説明
2. 「サーバーIPアドレス」フィールドを使用して、コレクタがリスニングするアドレスを指定します。 これは、ネットワーク・スペシャリストに相談した上で行うことをお薦めします。 次に、「保存」をクリックします。

VLANフィルタの定義

VLANフィルタを使用すると、監視対象トラフィックを特定のサーバーおよびサブネットに限定できます。 VLANフィルタを定義する手順は、次のとおりです。

1. 図13-15に表示されている「VLANフィルタ」の現在の設定をクリックします。 図13-17に示すダイアログが表示されます。

   図13-17 「VLANフィルタの構成」ダイアログ

   
   「図13-17 「VLANフィルタの構成」ダイアログ」の説明
2. フィルタ・モードメニューを使用して、VLANフィルタを有効化する必要があるかどうかを指定します。 デフォルトでは、VLANトラフィックが監視されません。 このフィルタを有効にすると、VLANトラフィックのみモニターされます。
3. 必要に応じて、VLAN IDフィールドを使用して、フィルタの基準とする特定のVLANを指定します。 次に、「保存」をクリックします。

全体のトラフィックの制限

ネットワークおよびVLANフィルタを使用できる以外にも、他のフィルタが適用された後に残るトラフィック全体のどの程度を実際に監視するかも指定できます。 デフォルトでは、残るすべてのトラフィックが監視されます。

トラフィック全体の監視レベルを指定する手順は、次のとおりです。

1. 図13-15に表示されている「トラフィック・フィルタ」の現在の設定をクリックします。 図13-18に示すダイアログが表示されます。

   図13-18 「トラフィック全体の制限」ダイアログ

   
   「図13-18 「トラフィック全体の制限」ダイアログ」の説明
2. 「スキームをフィルタリング中」メニューを使用して、物理IPアドレスと機能IPアドレスのどちらに基づいてネットワーク・トラフィックのフィルタリングを行うかを指定します。 次のフィルタリング・スキームを使用できます:

   • IPパケット

   • 機能IPアドレス

   • クライアント・ポート

   デフォルトでは、ネットワーク・トラフィックのフィルタリングは物理IPアドレスに基づいて行われます。 つまり、IPアドレスがIPパケットから取得されます。 ただし、コレクタがCDNまたはプロキシ・サーバーの内側にインストールされている場合は、機能IPアドレスまたはクライアント・ポートに基づいたフィルタリングをお薦めします。 SSLトラフィックは、クライアント・ポート・スキームの最初のコレクタに常に送信されます。 これは、SSLトラフィックがクライアント・ポート・モードごとにセグメント化されていないことを意味します。

   機能IPアドレスを使用する場合は、次の点に注意してください:

   • 機能IPアドレスが使用できない場合は、IPパケットから取得されたIPアドレスがかわりに使用されます。

   • ネットワーク・フィルタリングで構成済のクライアントIPヘッダーを使用すると、かなりの処理オーバーヘッドがコレクタで発生します。監視対象のトラフィックでSSL暗号化が使用されている場合は特に増加します。 物理アドレスのフィルタリングはTCPレベルで実行できるのに対して、機能IPアドレスのフィルタリングは通常はHTTPレベルで実行する必要があるためです。

3. 「パケット取得」メニューを使用して、プロファイルのコレクタで監視する必要のあるトラフィックの一部を指定します。 表13-4に使用可能なオプションを示します。

   表13-4 パケット取得スキーム

   オプション	説明
   すべてのトラフィック	他のフィルタが適用された後に残るすべてのトラフィックを監視するように指定します。 これはデフォルトです。
   指定されたドメイン	アプリケーション、スイートおよびサービスの定義で明示的に指定されたドメインのみに監視対象を制限するように指定します。
   トラフィック・サンプリング	トラフィックの一部のみを監視対象とすること、およびその割合を指定します。 たとえば、オプション「トラフィックの1/4 - パート4」では、選択したプロファイル内の各コレクタがネットワーク・トラフィックの最後の1/4のみを監視するよう指定します。
   ロード・バランシング	パケット・ストリームの監視をコレクタ・プロファイル内の複数のコレクタ全体に分散させ、各コレクタがストリームの一部を受け取るように指定します。 2-16コレクタでこの設定がサポートされています。 自動: 各コレクタには、プロファイル定義における順位に基づいて、トラフィックの一部が監視対象として割り当てられます。 たとえば、8番目の割当て済コレクタは、直近の8番目のトラフィックを監視することになります。 手動: 監視対象とするトラフィックの一部および割合をコレクタごとに指定できます。 このオプションは、コレクタ・プロファイルにコレクタが1つ以上割り当てられている場合にのみ使用できます。

   次に、「保存」をクリックします。

4. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。 これについては、「コレクタの再起動」で説明しています。

例13-6 トラフィック・モニタリング

前述の設定では、合計ネットワーク・トラフィックの何分の1を測定するかを指定しています。 したがって、トラフィックの1/2を監視対象とするよう指定した場合は、監視対象の1/2のみがレポートされます。 100%未満の設定を使用する場合、レポートされる情報は実際のトラフィック全体ではなく選択したサンプルを反映していることを忘れないようにしてください。

トラフィックの監視はIPアドレスに基づいて行われます。 このことは、使用する設定に関係なく、すべてのユーザー・セッションが記録されることを意味します。 ただし、これらのセッションの数は選択した設定によって決まります。

ロード・バランシングおよびトラフィック・サンプリング定義の確認

ロード・バランシングおよびトラフィック・サンプリング定義によってネットワーク・トラフィックの正しくない監視が生じる可能性があることを理解してください。 たとえば、選択したプロファイルに16個のコレクタが割り当てられていない場合に、ロード・バランシング部「16で分割されたすべてのトラフィック」を選択できます。 同様に、トラフィック・サンプリング部「トラフィックの1/8 - パート1」を選択して、選択したプロファイルに8個のコレクタを割り当て、それぞれでネットワーク・トラフィックの同じ部分を監視できます。 このため、次の点を確認する必要があります。

• RUEIデプロイメントがネットワーク・インフラストラクチャ内の異なる監視ポイントに接続されるコレクタを取り込む場合は、トラフィック・サンプリングのみ指定されます。

• ロード・バランシングを使用する場合、選択したオプションがプロファイルに割り当てられるコレクタの数と一致する必要があります。

ノート:

ネットワーク・インフラストラクチャの完全な知識を持つユーザーがネットワーク・フィルタ定義を確認することを強くお薦めします。

プロファイルのコレクタの追加および削除

プロファイルのコレクタを追加または削除する場合にネットワーク・フィルタ定義は自動的に更新されず、そのような変更によってネットワーク・トラフィックが欠落または何度も処理される場合に警告は生成されないので注意してください。 このため、コレクタ・プロファイル設定を変更した後、ネットワーク・フィルタ定義を注意して確認する必要があります。

SSLキーの管理

暗号化データ(HTTPSやSSLなど)を監視するようRUEIを構成できます。 この構成を行うには、WebサーバーのSSL秘密キーのコピーをRUEIにインポートする必要があります。 暗号化されたコンテンツを監視するための証明書をインポートする手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「SSLキー」→「SSLキー管理」の順に選択します。 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。 現時点でインストール済のキーのリストが表示されます。 例を図13-19に示します。

   図13-19 SSLキーのステータス

   
   

   SHA1フィンガープリントは、SHA1アップロードされたRSAキーの証明書部分のダイジェストです。 SHA1フィンガープリント列は、アップグレード・スクリプトの実行後に既存のキーに対してのみ表示されます。

2. 「新規キーの追加」をクリックして新規のキーを定義します。 既存のSSL鍵定義は変更できません。 図13-20に示すダイアログが表示されます。

   図13-20 「SSLキーの追加」ダイアログ

   
   

   
   「図13-20 「SSLキーの追加」ダイアログ」の説明

   
   
3. 「キー」フィールドを使用して、キーを含むファイルを指定します。 キーが暗号化されている場合は、パスフレーズを指定する必要があります。 次に、「キーのインストール」をクリックします。

   ノート:

   PEM、DERまたはPKCS12形式のファイルを指定でき、ファイルにはキーおよび一致する証明書が含まれている必要があります。 キーはRSAキーである必要があります。 40-bitキー(DES_40、RS2_4-0、RC4_40)およびAEAD暗号を使用する暗号化プロトコルはサポートされません。 Camelliaは、Oracle Linux 6.5以上でのみサポートされています。

例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キーの削除

インストール済のSSLキーを削除するには、必要なキーを右クリックして「削除」を選択します。 キーの削除を確認するように求められます。

キーの有効期限の監視

オプションで、保留中のSSLキーの有効期限に関する通知を構成できます。 これにより、新規のキーのインポートを計画でき、新規のキーを取得してアクティブ化する間に監視対象データにずれが生じることがなくなります。 次を実行します。

1. タスクバーにある「キー有効期限の監視」アイコンをクリックします。 アイコンが未表示の場合は、「構成」→「セキュリティ」→「SSLキー」→「SSLキー管理」の順に選択します。 図13-21に示すダイアログが表示されます。

   図13-21 「SSLキーの有効期限の監視」ダイアログ

   
   「図13-21 「SSLキーの有効期限の監視」ダイアログ」の説明
2. 有効期限より何日前に通知を生成する必要があるか、その日数を指定します。 その他のタブにあるコントロールを使用して、電子メール、SNMPおよびテキスト・メッセージの通知詳細を指定します。 これらは、「アラート・プロファイルの定義」で説明されているダイアログと似ています。 次に、「保存」をクリックします。
3. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。 これについては、「コレクタの再起動」で説明しています。

ノート:

期限切れのSSLキーがないかどうかのチェックが、1日に1回6:00AM(レポータ・システム時間)に実行されるようスケジュールされます。

ユーザー情報のマスキング

RUEIインストールは機密情報をログに記録しないように構成できます。 これをマスキングと呼びます。これによって、パスワード、クレジット・カード情報などの機密情報をディスクに記録しないようにできます。

RUEIのセキュリティ機能によって、POST URL引数、HTTPヘッダー、Cookieとその値、Oracle Forms要素およびURLの内容のログを制御できます。

マスキングを実装する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「マスキング」の順に選択し、構成するHTTPプロトコル・アイテムについて適切なオプションを選択します。 たとえば、URL POST引数マスキングなどです。 図13-22に示すようなウィンドウが表示されます。

   図13-22 「URL POST引数マスキング」ウィンドウ

   
   

   
   「図13-22 「URL POST引数マスキング」ウィンドウ」の説明

   
   

   選択したHTTPプロトコル・アイテムについて現時点で定義されているマスキングが表示されます。

2. 既存の項目の「使用中」リストをクリックして、使用状況の情報を表示します。 例を図13-23に示します。

   図13-23 HTTP項目の使用状況の例のダイアログ

   
   

   
   「図13-23 HTTP項目の使用状況の例のダイアログ」の説明

   
   

   この場合、選択したURL POST引数をアプリケーションのユーザーIDスキームの一部として使用し、RUEIの内部トラフィック検出の一部としても使用することを示します。 これらの自動的に検出された項目は、後の項で説明します。

3. 「新規マスキングの追加」をクリックして新規マスキングを定義します。 図13-24に示すようなダイアログが表示されます。

   図13-24 「POST引数のマスキング・アクションの追加」ダイアログ

   
   

   
   「図13-24 「POST引数のマスキング・アクションの追加」ダイアログ」の説明

   
   

4. ログを制御するアイテムの名前を指定します。 選択したプロトコル・アイテムに応じて、POST URL引数の名前、Cookie名または値、Oracle Forms要素、HTTPヘッダー内のアイテム、またはURL接頭辞を指定します。

5. 定義するアイテムに割り当てるマスキング・アクションを選択します。 表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回の操作で多数のデータ・アイテム(表示されているアイテムと非表示のアイテムの両方)のセキュリティ設定を変更できます。

デフォルト・アクションを指定する手順は、次のとおりです。

1. デフォルト・アクションを指定するHTTPプロトコル・アイテムを選択します。 たとえば、「HTTPヘッダー・マスキング」を選択します。
2. 「デフォルトのマスキング・アクション」メニューの現在の設定をクリックします。 これは、マスキングのウィンドウの一番上にあります。 図13-20に示すようなダイアログが表示されます。

   図13-25 デフォルトのマスキング設定の編集ダイアログ

   
   

   
   「図13-25 デフォルトのマスキング設定の編集ダイアログ」の説明

   
   
3. アクションが「デフォルト」のすべてのデータ・アイテムに適用する、目的のセキュリティ設定を選択します。 次に、「保存」をクリックします。 この設定は、変更すると、5分以内に有効になります。

例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を参照してください。 セッション診断のエクスポート機能を使用して、これらのファイルの内容を監査することもできます。 これについては、「フル・セッション情報のエクスポート」で説明しています。

FSRページ・コンテンツのマスキング

「ユーザー情報のマスキング」で説明するマスキング機能を使用すると、ヘッダー、URL、cookie、およびOracle Forms要素内の引数のマスキング・ポリシーを定義できます。 また、フル・セッション・リプレイ(FSR)機能内で表示されるアプリケーション・ページの実際のコンテンツについて、マスキング・ポリシーを定義することもできます。 これは、実際のWebサーバー・コンテンツ内の機密情報(パスワードおよびクレジット・カード情報など)へのアクセスを制限する場合に特に有用です。

ページ・コンテンツのマスキング・ポリシーを定義するには、次の手順を実行します。

1. 「構成」、「アプリケーション」、「アプリケーション」または「スイート」の順に選択し、必要なアプリケーションを選択します。 「アプリケーション概要」が表示されます。
2. 「詳細」タブ、「リプレイ」タブ、「リプレイ・マスキング」タブの順にクリックします。 現在定義されているマスキング・ポリシーが表示されます。 「編集」をクリックします。 図13-26に示すダイアログが表示されます。

   図13-26 リプレイ・マスキング・アクションの編集ダイアログ

   
   

   
   「図13-26 リプレイ・マスキング・アクションの編集ダイアログ」の説明

   
   
3. 「検索タイプ」メニューを使用して検索範囲を指定します。 これには、リクエストまたはレスポンスのコンテンツのいずれかを指定できます。 「検索値」フィールドを使用して、目的のページ・コンテンツの検索に使用するXPath式を指定します。 XPathの問合せの使用方法の詳細は、「XPath問合せの操作」を参照してください。 必要な検索ごとに「追加」を追加します。 次に、「保存」をクリックします。

   変更は5分以内に有効になります。

ノート:

ユーザー・インタフェースに表示されているデータはマスキングされていますが、ディスク上にはマスキングされていない状態で格納されます。

例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クライアント証明書のマスキング

デフォルトでは、すべてのSSLクライアント証明書プロパティ(ある場合)は、各コレクタ・システムで生成されるログ・ファイルの一部として記録されます。 これが組織のセキュリティ・ポリシーにそぐわない場合は、次の手順を実行します。

1. 「構成」、「セキュリティ」、「SSL証明書マスキング」の順に選択します。 図13-27に示すパネルが表示されます。

   図13-27 コレクタのSSLクライアント証明書のマスキング・ポリシー

   
   「図13-27 コレクタのSSLクライアント証明書のマスキング・ポリシー」の説明
2. 目的のコレクタ・プロファイルの証明書マスキング・アクションをクリックします。 図13-28に示すダイアログが表示されます。

   図13-28 「コレクタのSSL証明書マスキングの編集」ダイアログ

   
   「図13-28 「コレクタのSSL証明書マスキングの編集」ダイアログ」の説明

   表13-7に示すオプションがあります。

   表13-7 SSL証明書マスキング・アクション

   オプション	説明
   すべての証明書のプロパティを記録	SSL証明書全体をログに記録するように指定します。 これはデフォルトです。
   セッションIDのみを記録	セッションID情報のみを記録するように指定します。
   証明書のプロパティが記録されていません	SSL証明書をまったくログに記録しないように指定します。

   目的のマスキング・アクションを選択します。 次に、「保存」をクリックします。

3. 再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。 これについては、「コレクタの再起動」で説明しています。

コレクタのデータ保存ポリシーの定義

次の手順では、データ保存を構成し、アプリケーション・ベースまたはコレクタ・ベースで現在のディスク使用状況を監視できます。 コレクタのデータ保存は、次の基準を使用して構成できます。

• サイズ・ベース - サイズ割当て(X GB)が満たされるとデータが破棄されます。

• 時間ベース - 定義された期間(N日間)が経過するとデータが破棄されます。

記憶域にはN日を超える分のデータは含まれず、記憶域がX GBを超えるディスク領域を占有することはありません。 この手順では、サイズ・ベースのデータ保存ポリシーを構成する方法について説明します。 時間ベースのデータ保存はレポータ保存ポリシーに関連しており、「レポータの保存ポリシーの定義」で説明されています。

サイズ・ベースのコレクタ保存ポリシーはアプリケーション/スイート単位で指定できますが、時間ベースのコレクタ/レポータのデータ保存ポリシーはこの単位で指定できません。

レポータに登録済のコレクタで使用されるサイズ・ベースのデータ保存ポリシーを指定する手順は、次のとおりです。

1. 「構成」→「セキュリティ」→「コレクタ・データ保持ポリシー」の順に選択します。 図13-29に示すパネルが表示されます。

   図13-29 コレクタ・データ保持ポリシー

   
   「図13-29 コレクタ・データ保持ポリシー」の説明
2. 「アプリケーション・ビュー」タブ内で、定義された各アプリケーション、スイート、サービス、および各コレクタ・プロファイル全体に対して、次の情報が表示されます。

   • 制限(GB): エラー・ページ・リプレイ(EPR)およびフル・セッション・リプレイ(FSR)のデータ用に現在予約されているディスク領域の最大量を示します。

   • 使用量(GB): リプレイ・データ用のプロファイル内の各コレクタによって現在使用されているディスク領域の量を示します。

3. アプリケーション、スイートおよびサービスごとに、プロファイル列の「詳細」をクリックして詳細を表示します。
4. 詳細画面で、「リプレイがアクティブです」ラベルの横にある「はい」またはいいえをクリックして、リプレイ・データの作成を有効にするかどうかを指定します。 デフォルトでは、再生データは有効になっています。
5. リプレイが有効になっている場合は、変更するコレクタ・プロファイルをモニタリングするために、詳細画面で「エラー・ページ・リプレイ・ストア」 (ERS)または「フル・セッション・リプレイ記憶域」 (FRS)の値をクリックします。 図13-30に示すようなダイアログが表示されます。

   図13-30 「エラー・ページ・リプレイ格納サイズ」ダイアログ

   
   「図13-30 「エラー・ページ・リプレイ格納サイズ」ダイアログ」の説明

   アプリケーション、スイートまたはサービスの選択したプロファイル内のすべてのコレクタについて、FSRまたはEPRデータのために予約しておくディスク領域の最大容量を指定します。

6. または、特定のコレクタ・プロファイル全体にわたる個々のアプリケーションおよびスイートのFSRおよびEPRデータ・ストアのサイズを指定するかわりに、「図13-29」に表示される「リプレイのデフォルトの設定」コマンド・ボタンをクリックすることもできます。 図13-31に示すようなダイアログが表示されます。

   図13-31 「リプレイのデフォルトの設定」ダイアログ

   
   「図13-31 「リプレイのデフォルトの設定」ダイアログ」の説明

   リプレイ記憶域をデフォルトで有効化するかどうか、および各コレクタ・システムのFSRとEPRデータ用に予約するディスク領域の最大量を指定します。

7. これらの設定を変更したら、ネットワーク・データ・コレクタ・ステータス(「コレクタのステータスの表示」)で適切な各コレクタ・プロファイルに対する最後の更新を確認し、適用されていることを確認することをお薦めします。 必要に応じて、「コレクタの再起動」の説明に従って、必要なすべてのコレクタを再起動します。

例13-16 重要

次のことに注意してください。

• リプレイ機能は、ネットワーク・データ・コレクタを使用している場合に使用できます。 タグ・データ・コレクタのみを使用している場合、この機能は使用できません。

• 関連付けられているコレクタ・プロファイルのリプレイ記憶域の有効化以外に、アプリケーション、スイートまたはサービスについてリプレイ・データを使用可能にする場合、リプレイ・ロギング・ポリシーが適切に設定されていることも確認する必要があります。 これについては、「リプレイ・ポリシーの制御」で説明しています。

• アプリケーションで使用可能な再生用のディスク領域を、現在使用中の容量よりも減らすと、再生データ・ストアのサイズを調整するために、ストアの最も古いデータが削除されます。 たとえば、アプリケーションのFSRデータ・ストアを20GBから10GBに減らすように指定し、現在14GBが使用されているとします。 この場合、ストアのサイズを調整するために、現在のFSRデータ・ストアの最も古い4GB分が削除されます。

• この項の冒頭で説明したように、データ保存は時間および領域の割当てによって制限されます。

• FSR期間が15分未満の場合、エラー・リプレイ機能が正常に実行されない場合があります。 また、0に設定されると、EPRサイズ設定を変更できなくなります。

• 「コレクタ・ビュー」タブをクリックして、レポータ・システムに接続された各コレクタの使用できるおよび使用されたリプレイ・データ記憶域、期間および最新の更新を表示できます。 これを定期的に確認してレポート要件を満たしていることを確認することをお薦めします。

例13-17 リプレイ・データのパージ

アプリケーションまたはスイートが削除されるとき、関連するFSRおよびEPRデータはコレクタ・システムから自動的に削除されません。 引き続き表示することができます。 このデータを削除する場合、「リプレイ・アクティブ」列に表示されている「削除」アイコンをクリックする必要があります。 データの削除を確認するように求められます。

リプレイ・ポリシーの制御

RUEIで使用されるリプレイ・ビューアに書き込まれる情報を制御することができます。 リプレイ・アクションを監視中のすべてのトラフィックに適用するか、特定のIPアドレス範囲に適用するかを指定できます。 また、接頭辞を指定することによって、特定のURLコンテンツをログに記録する方法も制御できます。 RUEIのデプロイメントでリプレイ・ポリシーを指定するには、次の手順を実行します。

1. 「構成」、「セキュリティ」、「リプレイ・ロギング・ポリシー」の順に選択します。 図13-32に示すウィンドウが表示されます。

   図13-32 「リプレイ・ロギング・ポリシー」ウィンドウ

   
   

   
   「図13-32 「リプレイ・ロギング・ポリシー」ウィンドウ」の説明

   
   
2. 「デフォルトのリプレイ・アクション」設定をクリックします。 図13-33に示すダイアログが表示されます。

   図13-33 「デフォルトのリプレイ・アクションの編集」ダイアログ

   
   

   
   「図13-33 「デフォルトのリプレイ・アクションの編集」ダイアログ」の説明

   
   
3. 「アクション」メニューを使用して、リクエストとレスポンスのヘッダーおよび本体において、監視中のトラフィックのどの要素をリプレイ・ビューア機能とコレクタ・ログ・ファイルに記録するかを指定します。 表13-8に、使用可能なオプションを示します。

   表13-8 デフォルトのロギング・アクション

   マスキング・アクション	説明
   リプレイなし	すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアには何も保存しないように指定します。 これはデフォルトです。
   完全ロギング	すべての部分をリプレイ・ビューアとコレクタ・ログ・ファイルの両方に保存するように指定します(他にマスキングが定義されていればその適用後)。
   リクエスト本体なし	すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアにリクエスト本体は保存しないように指定します。
   返信本体なし	すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアに返信本体は保存しないように指定します。
   ヘッダーのみ	すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアにはリクエスト・ヘッダーとレスポンス・ヘッダーのみを保存するように指定します。

   マスキング・アクションの使用方法は、「ユーザー情報のマスキング」で説明しています。

4. 「リプレイIP範囲」設定をクリックします。 図13-34に示すダイアログが表示されます。

   図13-34 「コレクタのリプレイIP範囲の編集」ダイアログ

   
   

   
   「図13-34 「コレクタのリプレイIP範囲の編集」ダイアログ」の説明

   
   
5. 「範囲」メニューでは、選択したデフォルト・アクション(デフォルト)を使用してすべてのIPアドレス範囲のネットワーク・トラフィックをログに記録するか、それとも特定のアドレス範囲のトラフィックのみを記録するか指定します。 次に、「保存」をクリックします。 図13-32に示すウィンドウに戻ります。
6. 特定のIPアドレス範囲からのみネットワーク・トラフィックをログに記録する場合は、IP範囲のロギング・タブをクリックします。 すべてのIPアドレス・オプションを選択した場合は、既存のIPアドレス範囲の定義が無効になり、無視されます。
7. 「新規IP範囲の追加」をクリックして新しいIPアドレス範囲を定義するか、既存の定義をクリックして変更します。 図13-35に示すダイアログが表示されます。

   図13-35 「リプレイIPアドレス範囲の追加」ダイアログ

   
   

   
   「図13-35 「リプレイIPアドレス範囲の追加」ダイアログ」の説明

   
   
8. トラフィック・ロギングを制限するCIDR表記のIP範囲を指定します。 次に、「保存」をクリックします。
9. オプションで、「アップロード・リスト」をクリックすると、現在定義されているIPアドレス範囲に、IPアドレス範囲のリストをマージすることができます。 ファイルには、1行に1エントリのみ、および各アドレス範囲の情報(CIDR表記のIP範囲)を含める必要があります。 次に、「マージ」をクリックします。
10. URLコンポーネントのロギング・ポリシーを指定するには、「URL接頭辞」タブをクリックします。 現時点で定義されているURL接頭辞がリストされます。 例を図13-36に示します。

    図13-36 「URL接頭辞」セクション

    
    

    
    「図13-36 「URL接頭辞」セクション」の説明

    
    
11. 「新規URL接頭辞の追加」をクリックして新しいURL接頭辞を定義するか、既存のURL接頭辞をクリックして変更します。 図13-37に示すダイアログが表示されます。

    図13-37 「URL接頭辞のリプレイ・アクションの追加」ダイアログ

    
    

    
    「図13-37 「URL接頭辞のリプレイ・アクションの追加」ダイアログ」の説明

    
    
12. URLコンポーネントを指定し、対応するロギング・アクションを選択します。 表13-8に、使用可能なオプションを示します。 次に、「保存」をクリックします。

例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はトラフィックを監視できます。 場合によっては、メモリー使用量を削減して、メモリーに保持できるフレーム数を増やすために、最大フレーム・サイズを大きくする必要があります。 最大フレーム・サイズを削減するには:

1. 「構成」、「セキュリティ」、「超特大フレーム」の順に選択します。
2. 「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。
3. 最大フレーム・サイズの設定をクリックします。
4. プロファイルのコレクタによって受け入れられる受信フレームの最大サイズを選択します。 デフォルトは64 KBです。 指定した最大値を超えるフレームが破棄され、イベント・ログにメッセージが投稿されます。 次に、「保存」をクリックします。

表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インストレーション・ガイド」の「トラブルシューティング」付録を参照してください。

RUEIユーザー・セッション・アイドル時間の制御

デフォルトでは、ユーザー・アクティビティがない状態で60分経過すると、ユーザーはRUEIから自動的にログアウトされます。 ユーザーが自動的にログアウトされるまでのアイドル時間を変更するには、「構成」→「一般」→「詳細設定」→「ユーザー・インタフェース」を選択します。 表示されるリストから「RUEIセッション・アイドル時間(分)」を選択します。 ビジターが非アクティブになってからRUEIセッションを終了するまでに必要な経過時間を指定するか、空のままにします(制限を設定しない場合)。