| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
 前 |
 次 |
| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
前 |
次 |
この章では、トラフィックの監視のためにRUEIで使用されるコレクタ・プロファイルの使用方法およびセキュリティ関連設定の構成方法について説明します。また、ネットワーク・フィルタを設定して、特定のネットワーク、ホスト、仮想Local Area Network(VLAN)が取得されないようにしたり、監視対象トラフィック全体を減らす方法についても説明します。機密データのセキュリティを維持するために、HTTPプロトコル・アイテム(HTTPヘッダー、Cookieなど)のマスキング・アクションを指定することもできます。また、暗号化で保護されたトラフィックを処理するWebサーバーの秘密鍵の管理についても説明します。
すべてのセキュリティ関連情報の管理は、セキュリティ担当者が担当します。
コレクタの管理を容易にするため、各コレクタは1つのコレクタ・プロファイルに割り当てられます。コレクタ・プロファイルの構成が変更された場合、それらは割当て済のすべてのコレクタに自動的に適用されます。
インストール時に、次の2つの事前定義済のコレクタ・プロファイルが作成されます。
システム・ネットワーク・データ・コレクタ(ネットワーク・ベースのデータ収集の場合)
システム・タグ・サーバー(タグ・ベースのデータ収集の場合)
レポート要件に応じて追加のプロファイルを作成するには、既存のプロファイルをコピーして、それを新規プロファイルのベースとして使用します。ユーザー定義のコレクタ・プロファイルとは異なり、Systemコレクタ・プロファイルは削除できないことに注意してください。
現在使用可能なコレクタ・プロファイルを表示するには、「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。例を図13-1に示します。
各コレクタ・プロファイルでは、表13-1に示すオプションをコンテキスト・メニューで使用できます。
表13-1 コレクタ・プロファイルのコンテキスト・メニュー
| オプション | 説明 |
|---|---|
|
構成 |
選択したプロファイルに割り当てられているすべてのコレクタの構成を指定できます。それには、ネットワーク・フィルタ、コレクタでリスニングするTCPポート、およびセキュリティで保護されたトラフィックの復号化に使用する秘密鍵の使用が含まれます。この詳細は、13.1.2項「コレクタ・プロファイルの構成の変更」に記載されています。プロファイルの構成を変更した後に、プロファイルに割り当てられているコレクタを自動的に再起動するか、または手動による再起動を要求するメッセージを表示するかを指定できます。この詳細は、13.1.6項「コレクタの再起動」に記載されています。 |
|
コピー |
選択したコレクタ・プロファイルを新規プロファイルのベースとして使用します。この詳細は、13.1.1項「コレクタ・プロファイルの作成」に記載されています。 |
|
プロパティの編集 |
コレクタ・プロファイルの名前および簡単な説明を変更できます。デフォルトのコレクタ・プロファイルのプロパティは変更できないことに注意してください。 |
|
削除 |
選択したコレクタ・プロファイルを削除します。選択したプロファイルにコレクタが割り当てられている場合、それらは自動的にデフォルトの(System)コレクタ・プロファイルに再割り当てされることに注意してください。デフォルトのコレクタ・プロファイルは削除できません。 |
新規コレクタ・プロファイルを作成する手順は、次のとおりです。
「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。現時点で定義されているコレクタ・プロファイルが表示されます。例を図13-1に示します。
新規プロファイルのベースとして使用するコレクタ・プロファイルのコンテキスト・メニューで「コピー」を選択します。図13-2に示すダイアログが表示されます。
新規コレクタ・プロファイルに一意の名前および必要に応じて簡単な説明を指定します。この説明にはプロファイルの目的と有効範囲を示すことをお薦めします。次に、「保存」をクリックします。新規プロファイルが作成されると、使用可能なコレクタ・プロファイルのリストに表示されます(図13-1)。
新規コレクタ・プロファイルを監視要件に応じて構成します。この詳細は、13.1.2項「コレクタ・プロファイルの構成の変更」に記載されています。
作成された新規プロファイルの構成は、ベースとなるプロファイルと同じです。その構成を要件に応じて変更する手順は、次のとおりです。
使用可能なコレクタ・プロファイルのリスト(図13-1)から目的のプロファイルをクリックするか、コンテキスト・メニューで「構成」を選択します。ウィンドウが開き、選択したプロファイルに現在割り当てられているコレクタが表示されます。例を図13-3に示します。
「構成」メニュー→「構成」の順に選択して、コレクタ・プロファイルの構成を変更します。表13-2に示すオプションがあります。
表13-2 コレクタ・プロファイルの「構成」のオプション
| オプション | 説明 |
|---|---|
|
プロトコル |
プロファイルに割り当てられているコレクタでリスニングするTCPポートを指定するには、このオプションを選択します。これについては、13.3項「ネットワーク・ベース監視の有効範囲の管理」で説明します。 |
|
ネットワーク・フィルタ |
プロファイルに割り当てられているコレクタの監視対象をネットワーク・トラフィックの特定のセグメントに制限するか、または特定のサーバーやサブネットに制限するかを指定するには、このオプションを選択します。この詳細は、13.4項「ネットワーク・フィルタの定義」に記載されています。 |
|
SSL鍵 |
暗号化されたコンテンツを監視するため、プロファイルに割り当てられている各コレクタにインポートする証明書を指定するには、このオプションを選択します。この詳細は、13.5項「SSL鍵の管理」に記載されています。 |
|
コレクタ再起動メソッド |
構成を変更した後で、プロファイルに割り当てられているコレクタを自動的に再起動するかどうか指定するには、このオプションを選択します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。 |
プロファイルに割り当てられているコレクタは、レポート要件に応じて別のコレクタに簡単に再割り当てできます。たとえば、ネットワーク・トラフィックのパターンまたはセキュリティ要件が変更された場合などです。コレクタを再割り当てする手順は、次のとおりです。
コレクタの現在の割当て先であるプロファイルを選択します。図13-3に示すようなウィンドウが表示されます。
コレクタのコンテキスト・メニューで「プロファイルの割当て」オプションを選択します。図13-4に示すダイアログが表示されます。
コレクタの新しい割当て先となるプロファイルを選択します。次に、「保存」をクリックします。
選択したプロファイルにコレクタが割り当てられると、図13-5に示すステータス・メッセージが表示されます。
このステータス・メッセージは最大で60秒間表示されます。その後、コレクタが自動的に再起動されるか、手動による再起動を要求するメッセージが表示されます。詳細は、13.1.6項「コレクタの再起動」を参照してください。
|
重要: 新規プロファイルのセグメンテーション・スキームが以前のプロファイルと異なる場合、新規プロファイルと一貫性が保たれるようにコレクタのセグメンテーション・スキームが調整されることに注意してください。したがって、トラフィック・フィルタの設定を新規プロファイルに割り当てた後で確認することを強くお薦めします。詳細は、13.4.3項「全体のトラフィックの制限」を参照してください。 |
複数のコレクタの割当て
異なるプロファイルに複数のコレクタを割り当てる場合は、「構成」メニューの複数選択オプションを使用できます。目的のコレクタをクリックしてから、ツールバーの「プロファイルの割当て」コマンド・ボタンをクリックします。
コレクタは、ネットワーク・ベースにもタグ・ベースにもでき、別のインタフェースに関連付けることができます。コレクタをインタフェースに割り当てる手順は、次のとおりです。
「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。現時点で定義されているコレクタ・プロファイルが表示されます。例を図13-1に示します。
変更するコレクタに移動します。図13-3に示すようなウィンドウが表示されます。変更するコレクタを右クリックします。
コレクタのコンテキスト・メニューから「ネットワーク・インタフェースの割当て」オプションを選択します。図13-4に示すダイアログが表示されます。
タグ・ベースの収集の場合、「IPありのインタフェース」を割り当てる必要があります。ネットワーク・ベースの収集の場合、「IPなしのインタフェース」を割り当てる必要があります。あるいは、「指定されたインタフェース」を選択して、すべてのインタフェースを表示し、個々に選択します。次に、「保存」をクリックします。
新規コレクタをシステムに登録する手順は、次のとおりです。
「構成」→「セキュリティ」→「コレクタ・プロファイル」の順に選択します。現時点で定義されているコレクタ・プロファイルがリストされます。例を図13-1に示します。
新規リモート・コレクタを登録するプロファイルを選択します。または、コンテキスト・メニューで「構成」を選択します。選択したプロファイルに現在割り当てられているコレクタがリストされます。例を図13-3に示します。
「構成」メニューで「リモート・コレクタの登録」オプションを選択します。図13-7に示すダイアログが表示されます。
新規コレクタ・システムのIPアドレスおよび必要に応じて簡単な説明を指定します。これには、その有効範囲と目的を示すことをお薦めします。次に、「登録」をクリックします。コレクタ・システムの構成要件は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
コレクタ・プロファイルでなんらかの構成を変更した場合、変更を有効にするには、そのプロファイルに割り当てられているすべてのコレクタを再起動する必要があります。この再起動は自動(デフォルト)または手動のいずれかで実行できます。コレクタの再起動の方法を構成する手順は、次のとおりです。
使用可能なコレクタ・プロファイルのリスト(図13-1)から目的のプロファイルをクリックするか、コンテキスト・メニューで「構成」を選択します。ウィンドウが開き、選択したプロファイルに現在割り当てられているコレクタが表示されます。例を図13-3に示します。
「構成」メニュー→「構成」→「コレクタ再起動メソッド」の順に選択します。図13-8に示すダイアログが表示されます。
「再起動メソッド」メニューを使用して、選択したプロファイルに割り当てられているコレクタを、プロファイルの構成を変更した後で自動的に再起動(デフォルト)するか、または手動による再起動を要求するかを指定します。次に、「保存」をクリックします。
コレクタの手動による再起動
「ネットワーク・データ・コレクタの構成」ウィンドウに再起動を要求するメッセージが表示されるまで、コレクタは再起動できません。例を図13-9に示します。
個々のコレクタを再起動するには、コンテキスト・メニューで「再起動」を選択します。コレクタ・プロファイルに多数のコレクタが含まれている場合は、「構成」メニューの「すべてのコレクタの再起動」オプションを使用した方が便利です。
リモート・コレクタ・システムでメンテナンスまたはトラブルシューティングを実行するときは、コレクタ・インスタンスを停止する必要が生じる可能性があります。この場合は、コレクタのコンテキスト・メニューで「無効化」を選択します。次に、「再起動」オプションを選択すると、コレクタに監視を再開するように指示できます。
リモート・コレクタ・システムが廃止された場合は、インストール済RUEIからそれを削除する必要があります。それには、コレクタのコンテキスト・メニューで「登録解除」オプションを選択します。確認後に、レポータのコレクタ・システムへの接続が中止されます。ローカル・コレクタ・インスタンスは登録解除できないことに注意してください。
ローカル・コレクタ
レポータ・システムのローカル・コレクタ・インスタンスは、System(localhost)項目で表します。インストール後はまだ有効化されておらず、現在定義されているすべてのコレクタ・プロファイルに表示されることに注意してください。特定のプロファイルで有効になると、選択したコレクタ・プロファイルのみで表示されます。ローカル・コネクタ・インスタンスは登録解除できません。
単一システムの能力を超えて処理を拡大するために、通常はレポータによって実行されるデータ処理を負担するように1つ以上の処理エンジンを構成することができます。
処理エンジンの登録
RUEIのデプロイメントに処理エンジンを追加するには、次の手順を実行します。
処理エンジンのインストールおよび構成手順がターゲット・システムで完了していることを確認してください。詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
「構成」、「セキュリティ」、「処理エンジン」の順に選択します。現時点で登録されている処理エンジンがリストされます。例を図13-10に示します。
「登録」をクリックします。図13-11に示すダイアログが表示されます。
処理エンジン・システムのホスト名またはIPアドレスと、データベース・リンク名を指定します。次に、「保存」をクリックします。データベース・リンク名は、ホスト名を含んでいる必要があり、Oracleの命名規則に準拠している必要があります。たとえば、空白を含むことはできず、数字またはアンダースコアで開始することはできません。詳細は、次のサイトで入手可能な『Oracle Database管理者ガイド』を参照してください。
http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/ds_admin.htm#ADMIN029
新しく登録した処理エンジンは、「なし」モードで図13-10に示すリストに表示されます。これは、まだ初期化されていないためにレポータで使用できないことを示しています。「処理エンジン」の「モード」設定をクリックします。図13-12に示すダイアログが表示されます。
「モード」メニューから「有効」を選択します。次に、「保存」をクリックします。短い期間の後、図13-10に示すウィンドウに戻ります。
処理エンジンの無効化
システムのメンテナンス(パッチのインストールなど)を実行するため、処理エンジンを一時的に無効にできます。処理エンジンを無効にする場合、次の点に注意してください。
処理エンジンを長期間無効にすると、短期間のデータが失われる場合があります。
無効になった処理エンジンで通常実行される処理は、残りの有効な処理エンジンに自動的に再分散されます。すべての処理エンジンを無効にすると、処理がレポータ・システムに戻ります。
処理エンジンの削除
処理エンジンを削除すると、関連するすべての情報(データベース・リンクなど)がRUEIデプロイメントからパージされます。ただし、処理エンジン・データベース内の情報は保存されます。このため、以前に削除した処理エンジン・システムを再登録する場合、データベース内のデータをレポータで引き続き使用できます。
RUEI内で、ネットワーク・データ・ベースの収集に対して監視対象のTCPポートを指定して、トラフィック監視の有効範囲を制御します。監視対象外のポートについての情報は表示されません。監視対象および監視対象外のTCPポート(HTTPおよびHTTPSの両方)の選択について、注意深く確認することをお薦めします。
現在監視対象であるポートを表示するには、「構成」→「セキュリティ」→「プロトコル」の順に選択します。例を図13-13に示します。
この設定を変更する手順は、次のとおりです。
「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。
ポート設定を変更するプロトコルをクリックします。表13-3に使用可能な設定を示します。
表13-3 プロトコル設定
| プロトコル | 説明 |
|---|---|
|
HTTP/Formsサーブレット・モード |
プロファイルのコレクタがFormsサーブレット・トラフィックをリスニングするポートを指定します。このオプションはEBSベース・トラフィック専用です(付録N「Oracle FormsおよびOracle E-Business Suiteのサポート」を参照)。 |
|
Formsソケット・モード |
プロファイルのコレクタがソケット・モードのFormsトラフィックをリスニングするポートを指定します。このオプションはEBSベース・トラフィック専用です(付録N「Oracle FormsおよびOracle E-Business Suiteのサポート」を参照)。 |
|
HTTP |
プロファイルのコレクタがHTTPトラフィックをリスニングするポートを指定します。この設定は「純粋な」HTTPトラフィックに対してのみ使用してください。 |
|
HTTPSプロキシ |
SSLトラフィックの送信先のプロキシ・サーバーのポート番号を指定します。次の点に注意してください。
|
|
HTTPS |
プロファイルのコレクタがHTTPSトラフィックをリスニングするポートを指定します。インストール時には、デフォルトの監視対象ポートとしてHTTPSポート443が定義されます。 |
図13-14に示すようなダイアログが表示されます。
新規ポート番号またはポートの範囲(80-85など)を追加するには、「ポート番号」フィールドに必要な番号を入力し、「追加」をクリックします。リストからアイテムを削除するには、ポートの右側にある「削除」アイコンをクリックします。次に、「保存」をクリックします。
|
重要: 各プロトコルに指定するポート番号はコレクタ・プロファイル内で重複しないようにしてください。つまり、1つのポート番号は、1つのプロトコルの割当てポート番号リストのみに指定する必要があります。 |
再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。
ポート番号の他に、ネットワーク・フィルタを使用しても、監視するトラフィックの有効範囲を管理できます。また、監視対象を特定のサーバーやサブネットに制限したり、パケットの取得レベルを制限できます。
ネットワーク・フィルタを定義または変更する手順は、次のとおりです。
「構成」→「セキュリティ」→「ネットワーク・フィルタ」の順に選択します。
「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。現時点で定義されているネットワーク・フィルタが表示されます。例を図13-15に示します。
次の項で説明しているフィルタを使用して、監視対象トラフィックの有効範囲を管理します。
再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。
ネットワーク・フィルタの適用の理解
ネットワーク・トラフィックは、定義されているフィルタの総合的な処理に基づいて監視されています。たとえば、定義されているすべてのポート番号でトラフィックが監視されます。同様に、定義されているネットワーク・フィルタ(サーバーIPアドレス範囲など)もすべて監視されています。このルールには1つだけ例外があり、それがVLANフィルタの使用です。有効にすると、指定したVLAN IDを持つVLANトラフィックのみが監視されます。これを有効にしてVLAN IDを指定しない場合は、すべてのVLANトラフィックが監視されます。
フィルタを定義すると、監視対象の有効範囲を特定のサーバーやサブネットに制限できます。この機能は、コレクタ・プロファイルにコレクタが1つ以上割り当てられている場合にのみ使用できることに注意してください。次を実行します。
「新規フィルタの追加」をクリックして新しいフィルタを定義するか、または既存のフィルタをクリックして変更します。図13-16に示すダイアログが表示されます。
「サーバーIPアドレス」と「ネットマスク」フィールドを使用して、コレクタでリスニングするアドレスを指定します。これは、ネットワーク・スペシャリストに相談した上で行うことをお薦めします。次に、「保存」をクリックします。
ネットワークおよびVLANフィルタを使用できる以外にも、他のフィルタが適用された後に残るトラフィック全体のどの程度を実際に監視するかも指定できます。デフォルトでは、残るすべてのトラフィックが監視されます。
トラフィック全体の監視レベルを指定する手順は、次のとおりです。
図13-15に表示されている「トラフィック・フィルタ」の現在の設定をクリックします。図13-18に示すダイアログが表示されます。
「スキームをフィルタリング中」メニューを使用して、物理IPアドレスと機能IPアドレスのどちらに基づいてネットワーク・トラフィックのフィルタリングを行うかを指定します。
デフォルトでは、ネットワーク・トラフィックのフィルタリングは物理IPアドレスに基づいて行われます。つまり、IPアドレスがIPパケットから取得されます。ただし、コレクタがCDNデバイスまたはプロキシ・サーバーの後ろにインストールされている場合は、機能IPアドレスに基づいたフィルタリングをお薦めします。この場合は、次の点に注意する必要があります。
機能IPアドレスが使用できない場合は、IPパケットから取得されたIPアドレスがかわりに使用されます。
ネットワーク・フィルタリングで構成済のクライアントIPヘッダーを使用すると、かなりの処理オーバーヘッドがコレクタで発生します。監視対象のトラフィックでSSL暗号化が使用されている場合は特に増加します。物理アドレスのフィルタリングはTCPレベルで実行できるのに対して、機能IPアドレスのフィルタリングは通常はHTTPレベルで実行する必要があるためです。
「パケット取得」メニューを使用して、プロファイルのコレクタで監視する必要のあるトラフィックの一部を指定します。表13-4に使用可能なオプションを示します。
表13-4 パケット取得スキーム
| オプション | 説明 |
|---|---|
|
すべてのトラフィック |
他のフィルタが適用された後に残るすべてのトラフィックを監視するように指定します。これがデフォルトです。 |
|
指定されたドメイン |
アプリケーション、スイートおよびサービスの定義で明示的に指定されたドメインのみに監視対象を制限するように指定します。 |
|
トラフィック・サンプリング |
トラフィックの一部のみを監視対象とすること、およびその割合を指定します。たとえば、オプション「トラフィックの1/4 - パート4」では、選択したプロファイル内の各コレクタがネットワーク・トラフィックの最後の1/4のみを監視するよう指定します。 |
|
ロード・バランシング |
パケット・ストリームの監視をコレクタ・プロファイル内の複数のコレクタ全体に分散させ、各コレクタがストリームの一部を受け取るように指定します。2-16コレクタでこの設定がサポートされています。
このオプションは、コレクタ・プロファイルにコレクタが1つ以上割り当てられている場合にのみ使用できます。 |
次に、「保存」をクリックします。
再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。
前述の設定では、合計ネットワーク・トラフィックの何分の1を測定するかを指定しています。したがって、トラフィックの1/2を監視対象とするよう指定した場合は、監視対象の1/2のみがレポートされます。100%未満の設定を使用する場合、レポートされる情報は実際のトラフィック全体ではなく選択したサンプルを反映していることを忘れないようにしてください。
トラフィックの監視はIPアドレスに基づいて行われます。このことは、使用する設定に関係なく、すべてのユーザー・セッションが記録されることを意味します。ただし、これらのセッションの数は選択した設定によって決まります。
ロード・バランシングおよびトラフィック・サンプリング定義によってネットワーク・トラフィックの正しくない監視が生じる可能性があることを理解してください。たとえば、選択したプロファイルに16個のコレクタが割り当てられていない場合に、ロード・バランシング部「16で分割されたすべてのトラフィック」を選択できます。同様に、トラフィック・サンプリング部「トラフィックの1/8 - パート1」を選択して、選択したプロファイルに8個のコレクタを割り当て、それぞれでネットワーク・トラフィックの同じ部分を監視できます。このため、次の点を確認する必要があります。
RUEIデプロイメントがネットワーク・インフラストラクチャ内の異なる監視ポイントに接続されるコレクタを取り込む場合は、トラフィック・サンプリングのみ指定されます。
ロード・バランシングを使用する場合、選択したオプションがプロファイルに割り当てられるコレクタの数と一致する必要があります。
|
重要: ネットワーク・インフラストラクチャの完全な知識を持つユーザーがネットワーク・フィルタ定義を確認することを強くお薦めします。 |
プロファイルのコレクタの追加および削除
プロファイルのコレクタを追加または削除する場合にネットワーク・フィルタ定義は自動的に更新されず、そのような変更によってネットワーク・トラフィックが欠落または何度も処理される場合に警告は生成されないので注意してください。このため、コレクタ・プロファイル設定を変更した後、ネットワーク・フィルタ定義を注意して確認する必要があります。
暗号化データ(HTTPSやSSLなど)を監視するようRUEIを構成できます。この構成を行うには、WebサーバーのSSL秘密鍵のコピーをRUEIにインポートする必要があります。暗号化されたコンテンツを監視するための証明書をインポートする手順は、次のとおりです。
「構成」→「セキュリティ」→「SSLキー」→「SSLキー管理」の順に選択します。「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。現時点でインストール済の鍵のリストが表示されます。例を図13-19に示します。
「新規キーの追加」をクリックして新規の鍵を定義します。既存のSSL鍵の定義は変更できないことに注意してください。図13-20に示すダイアログが表示されます。
「キー」フィールドを使用して、鍵を含むファイルを指定します。鍵が暗号化されている場合は、パスフレーズを指定する必要があります。次に、「鍵のインストール」をクリックします。
|
注意: PEM、DERまたはPKCS12形式のファイルを指定でき、ファイルには鍵および一致する証明書が含まれている必要があります。鍵はRSA鍵である必要があります。40ビット鍵(DES_40、RS2_4-0、RC4_40など)およびAEAD暗号を使用する暗号化プロトコルはサポートされていないことに注意してください。Camelliaは、Oracle Linux 6.5以上でのみサポートされています。 |
サポートされる暗号化プロトコルとメカニズム
Message Authentication Code(MAC)では、MD5、SHA-1およびSHA-2機能がサポートされます。暗号化プロトコルSSL v3、TLS v1.0、TLS v1.1およびTLS v1.2がサポートされています。現在サポートされているすべての暗号化アルゴリズムは、「コレクタ統計」ウィンドウの「SSL接続」セクションに表示されます(15.2項「コレクタのステータスの表示」を参照)。
SSLトラフィックの監視
SSLトラフィックおよびOracle Formsトラフィックは両方とも、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタが信頼性の高いネットワーク・デバイス(TAPなど)に接続されることを確認する必要があります。また、「コレクタ統計」ウィンドウ(15.2項「コレクタのステータスの表示」を参照)に表示される情報を定期的に調べて、TCPパケット・ストリームが正常な状態であることを確認するように強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。
秘密鍵の抽出の失敗
秘密鍵のロードに失敗した場合、パスワードが間違っている、証明書が格納されているファイルや秘密鍵の破損などの理由が考えられます。
オプションで、保留中のSSL鍵の有効期限に関する通知を構成できます。これにより、新規の鍵のインポートを計画でき、新規の鍵を取得してアクティブ化する間に監視対象データにずれが生じることがなくなります。次を実行します。
タスクバーにある「キー有効期限の監視」アイコンをクリックします。アイコンが未表示の場合は、「構成」→「セキュリティ」→「SSLキー」→「SSLキー管理」の順に選択します。図13-21に示すダイアログが表示されます。
有効期限より何日前に通知を生成する必要があるか、その日数を指定します。その他のタブにあるコントロールを使用して、電子メール、SNMPおよびテキスト・メッセージの通知詳細を指定します。これらは7.5.1項「アラート・プロファイル」で説明したダイアログと似ています。次に、「保存」をクリックします。
再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。
|
注意: 期限切れの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 POST引数、Forms要素、CookieおよびHTTPヘッダーの他に、接頭辞を指定してURLの特定の内容を保護することもできます。この機能が役立つのは、機密情報を含む可能性があるURL構文を保存できないようにする場合です。
URLコンポーネントを(データ・ブラウザ・グループ内の情報およびセッション診断機能が導出される)コレクタ・ログ・ファイルに保存するかどうかを指定します。表13-6に使用可能なマスキング・アクションを示します。
表13-6 URL接頭辞マスキング・アクション
| マスキング・アクション | 説明 |
|---|---|
|
ロギング |
(他のすべての定義済マスキングを適用後)URLコンポーネントをコレクタ・ログ・ファイルに保存するよう指定します。これがデフォルトです。 |
|
ロギングなし |
コレクタ・ログ・ファイルに何も保存しないように指定します。 |
URL接頭辞のマスキング・アクションが「ロギングなし」に設定されている場合、これはリプレイ・アクションにもなります。13.10項「リプレイ・ポリシーの制御」で説明するように、これは最初にマスキング・アクションを変更しないと変更できません。
|
重要: URL接頭辞のデフォルトのマスキング・アクションが「ロギングなし」に設定されている場合、データはコレクタ・ログ・ファイルに書き込まれず、レポートに何も使用できません。このため、記録されるURLコンポーネントのホワイトリストを最初に定義した場合のみ、このオプションを選択する必要があります。 |
デフォルトのマスキング・アクションの指定
前述のように、デフォルト設定では、セキュリティ定義においてアクションが明示的に指定されないHTTPプロトコル・アイテムに対して実行する必要があるアクションが指定されます。「デフォルト」アクションのアイテムを定義すると、1回の操作で多数のデータ・アイテム(表示されているアイテムと非表示のアイテムの両方)のセキュリティ設定を変更できます。
デフォルト・アクションを指定する手順は、次のとおりです。
デフォルト・アクションを指定するHTTPプロトコル・アイテムを選択します。たとえば、「HTTPヘッダー・マスキング」を選択します。
「デフォルトのマスキング・アクション」メニューの現在の設定をクリックします。これは、マスキングのウィンドウの一番上にあります。図13-20に示すようなダイアログが表示されます。
アクションが「デフォルト」のすべてのデータ・アイテムに適用する、目的のセキュリティ設定を選択します。次に、「保存」をクリックします。この設定は、変更すると、5分以内に有効になります。
自動表示アイテム
明示的に定義するHTTPプロトコル・アイテムのマスキングに加えて、構成時にRUEIで自動的に検出されるアイテムもあります。たとえば、URL POST引数pagelabelを使用してWebLogic Portalアプリケーションを追跡し、HTTPヘッダーAccept-Languageを使用してエンド・ユーザーの言語プリファレンスを決定します。これらのアイテムは、「システム」として「使用中」列に示されます。一般的に、マスキング・アクション「プレーン」を受信します。これは、関連付けられているアイテムが元の状態で記録されることを意味します。アクションは、ネットワーク・トラフィックの正確な監視のために必要であり変更できません。
セッションの追跡が標準のテクノロジ(ApacheまたはColdFusionなど)に基づいている場合、Cookieは「使用中」セクションではレポートされません。このようなCookieは手動で定義されて、デフォルト値以外に構成されていないかぎり、デフォルト・マスキング・アクションが割り当てられています。デフォルト・マスキング・アクションが「ブラインド済」に設定されていない場合、問題はありません。設定されていると、すべてのビジター・セッションが1セッションに記録されます。
8.3.14項「ユーザー識別の定義」に記載しているように、ユーザーの識別は最初はHTTP認可フィールドに基づいて行われます。この情報がネットワーク上でプレーン形式で送信されると、ユーザー名とパスワードをデコードされる可能性があり、セキュリティ問題が生じることに注意してください。これは、基本的な認証プロトコルの制限です。
認証フィールドがネットワーク上でプレーン形式で送信される場合は、前のセクションで説明したマスキング・オプションを使用して、Replay Viewerに保存する内容を制御できます。または、認証がネットワーク・トラフィックに含まれるときにハッシュされるようにすることができます。この場合、セッション診断でユーザーIDを使用できません。
Cookie値のマスキング
Cookie値-1には自動的にマスキング・アクション「Plain」が割り当てられる(つまり、元の状態のまま保持される)ことに注意してください。これが必要な理由は、Oracle E-Business Suite内ではセッションの終了を示すためにこの値が頻繁に使用されるからです。
重要:
マスキング機能を使用する場合には、次の点に特に注意する必要があります。
定義するマスキング・アクションはすべての監視対象ドメインに適用されます。
すべてのマスキングされたHTTPプロトコル・アイテム(URL接頭辞を除く)では、大/小文字が区別されません。
複数の(重なり合う)アイテム定義が可能ですが、一致部分が長い方の指定が、割当てのマスキング・アクションとして使用されます。
定義済のマスキング・アイテム(たとえば、3.12項「カスタム・ディメンションの使用」に記載されているカスタム・ディメンション・アイテム)を削除すると、そのマスキング・アクションを変更しなくても、そのアイテムは表示されるアイテム・リストから自動的に削除されます。ただし、定義済アクションを事前に変更していた場合は、アイテム・リストから明示的にアイテムを削除する必要があります。
各国語のキャラクタ・セットを使用する際のデータ・マスキング設定の詳細は、付録G「各国語サポートの使用」を参照してください。
付録S「エンリッチ・データのエクスポート機能」に記載しているように、RUEIによって収集されるデータをエクスポートして、他のデータ・ウェアハウス・データと組み合せることができます。RUEIでマスキングしたデータ・アイテムはマスキングされたままエクスポートされるため、外部アプリケーションで使用されるデータ・アイテムの要件をよく確認することをお薦めします。マスキング機能の設定ウィンドウで、セキュリティ要件を確認するために最適な監査ツールが提供されます。
データ・アイテムのセキュリティを変更するときは、ログ・ファイルにすでに保存されているデータは変更の影響を受けないことに注意してください。必要であれば、システムのパージを検討する必要があります(この詳細は、15.12項「システムのリセット」に記載されています)。
すべての機密データが間違いなくマスキングされていることを定期的に検証することを強くお薦めします。通常、アプリケーションは時間とともに変化し、それに伴ってPOST変数、Cookie、ヘッダー、URL構文の使用方法も変化します。コレクタおよびレポータのRAWログ・ファイルは、ディレクトリ/var/opt/ruei/processor/dataを参照してください。セッション診断のエクスポート機能を使用して、これらのファイルの内容を監査することもできます。この詳細は、4.4項「すべてのセッション情報のエクスポート」に記載されています。
13.6項「ユーザー情報のマスキング」で説明されているマスキング機能では、ヘッダー、URL、CookieおよびOracle Forms要素内の引数のマスキング・ポリシーを定義できます。また、フル・セッション・リプレイ(FSR)機能内で表示されるアプリケーション・ページの実際のコンテンツについて、マスキング・ポリシーを定義することもできます。これは、実際のWebサーバー・コンテンツ内の機密情報(パスワードおよびクレジット・カード情報など)へのアクセスを制限する場合に特に有用です。
ページ・コンテンツのマスキング・ポリシーを定義するには、次の手順を実行します。
「構成」、「アプリケーション」、「アプリケーション」または「スイート」の順に選択し、必要なアプリケーションを選択します。「アプリケーション概要」が表示されます。
「拡張」タブ→リプレイ・マスキングタブの順にクリックします。現在定義されているマスキング・ポリシーが表示されます。「編集」をクリックします。図13-26に示すダイアログが表示されます。
「検索タイプ」メニューを使用して検索範囲を指定します。これには、リクエストまたはレスポンスのコンテンツのいずれかを指定できます。「検索値」フィールドを使用して、目的のページ・コンテンツの検索に使用するXPath式を指定します。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。必要な検索ごとに「追加」を追加します。次に、「保存」をクリックします。
変更は5分以内に有効になります。
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
クレジット・カードの関連情報(有効期限など)をマスキングするには、追加のアクションを定義する必要もあります。
重要:
この機能内で定義されるマスキング・ポリシーは、アプリケーション・ページのFSR機能内の表示方法にのみ適用され、RUEIインストール内の記憶域には適用されません。
デフォルトでは、すべてのSSLクライアント証明書プロパティ(ある場合)は、各コレクタ・システムで生成されるログ・ファイルの一部として記録されます。これが組織のセキュリティ・ポリシーにそぐわない場合は、次の手順を実行します。
「構成」、「セキュリティ」、「SSL証明書マスキング」の順に選択します。図13-27に示すパネルが表示されます。
目的のコレクタ・プロファイルの証明書マスキング・アクションをクリックします。図13-28に示すダイアログが表示されます。
表13-7に示すオプションがあります。
表13-7 SSL証明書マスキング・アクション
| オプション | 説明 |
|---|---|
|
すべての証明書のプロパティを記録 |
SSL証明書全体をログに記録するように指定します。これがデフォルトです。 |
|
セッションIDのみを記録 |
セッションID情報のみを記録するように指定します。 |
|
証明書のプロパティが記録されていません |
SSL証明書をまったくログに記録しないように指定します。 |
目的のマスキング・アクションを選択します。次に、「保存」をクリックします。
再起動を要求するメッセージが表示されたら、プロファイルに割り当てられているコレクタを再起動します。この詳細は、13.1.6項「コレクタの再起動」に記載されています。
次の手順では、データ保存を構成し、アプリケーション・ベースまたはコレクタ・ベースで現在のディスク使用状況を監視できます。コレクタのデータ保存は、次の基準を使用して構成できます。
サイズ・ベース - サイズ割当て(X GB)が満たされるとデータが破棄されます。
時間ベース - 定義された期間(N日間)が経過するとデータが破棄されます。
記憶域にはN日を超える分のデータは含まれず、記憶域がX GBを超えるディスク領域を占有することはありません。この手順では、サイズ・ベースのデータ保存ポリシーを構成する方法について説明します。時間ベースのデータ保存はレポータ保存ポリシーに関連しており、これについては12.10.1項「レポータの保存ポリシーの定義」で説明されています。
サイズ・ベースのコレクタ保存ポリシーはアプリケーション/スイート単位で指定できますが、時間ベースのコレクタ/レポータのデータ保存ポリシーはこの単位で指定できません。
レポータに登録済のコレクタで使用されるサイズ・ベースのデータ保存ポリシーを指定する手順は、次のとおりです。
「構成」→「セキュリティ」→「コレクタ・データ保持ポリシー」の順に選択します。図13-29に示すパネルが表示されます。
「アプリケーション・ビュー」タブ内で、定義された各アプリケーション、スイート、サービス、および各コレクタ・プロファイル全体に対して、次の情報が表示されます。
制限(GB): エラー・ページ・リプレイ(EPR)およびフル・セッション・リプレイ(FSR)のデータ用に現在予約されているディスク領域の最大量を示します。
平均使用量(GB): リプレイ・データ用のプロファイル内で、各コレクタによって現在使用されているディスク領域の平均容量を示します。
平均期間: リプレイ・データを使用可能な時間の長さ(秒、分、時間または日数)を示します。通常、10分とレポートされる場合は、10分を超えるデータを格納できないほどシステムがビジーであることを意味します。
アプリケーション、スイート、およびサービスについて、「リプレイ・アクティブ」列のラジオ・ボタンを使用して、再生データの作成を有効にするかどうかを指定します。デフォルトでは、再生データは有効になっています。
有効にした場合、変更するアプリケーションを監視する各コレクタ・プロファイルの「エラー・ページ・リプレイ・ストア」(ERS)設定またはフル・セッション・リプレイ記憶域(FRS)設定をクリックします。図13-30に示すようなダイアログが表示されます。
アプリケーション、スイートまたはサービスの選択したプロファイル内のすべてのコレクタについて、FSRまたはEPRデータのために予約しておくディスク領域の最大容量を指定します。
または、特定のコレクタ・プロファイルの個々のアプリケーションおよびスイートのFSRおよびEPRデータ・ストア・サイズを指定するかわりに、図13-29に表示されている「リプレイのデフォルトの設定」コマンド・ボタンをクリックできます。図13-31に示すようなダイアログが表示されます。
リプレイ記憶域をデフォルトで有効化するかどうか、および各コレクタ・システムのFSRとEPRデータ用に予約するディスク領域の最大量を指定します。
これらの設定を変更したら、「ネットワーク・データ・コレクタ・ステータス」(15.2項「コレクタのステータスの表示」を参照)を使用して、それぞれの適切なコレクタ・プロファイルに対する最後の更新を確認し、適用されていることを確認することをお薦めします。必要な場合は、13.1.6項「コレクタの再起動」の説明に従って、すべての必要なコレクタを再起動します。
重要:
次の点に注意してください。
リプレイ機能は、ネットワーク・データ・コレクタを使用している場合に使用できます。タグ・データ・コレクタのみを使用している場合、この機能は使用できません。
関連付けられているコレクタ・プロファイルのリプレイ記憶域の有効化以外に、アプリケーション、スイートまたはサービスについてリプレイ・データを使用可能にする場合、リプレイ・ロギング・ポリシーが適切に設定されていることも確認する必要があります。この詳細は、13.10項「リプレイ・ポリシーの制御」に記載されています。
アプリケーションで使用可能な再生用のディスク領域を、現在使用中の容量よりも減らすと、再生データ・ストアのサイズを調整するために、ストアの最も古いデータが削除されます。たとえば、アプリケーションのFSRデータ・ストアを20GBから10GBに減らすように指定し、現在14GBが使用されているとします。この場合、ストアのサイズを調整するために、現在のFSRデータ・ストアの最も古い4GB分が削除されます。
この項の冒頭で説明したように、データ保存は時間および領域の割当てによって制限されます。
FSR期間が15分未満の場合、エラー・リプレイ機能が正常に実行されない場合があります。また、0に設定されると、EPRサイズ設定を変更できなくなります。
「コレクタ・ビュー」タブをクリックして、レポータ・システムに接続された各コレクタの使用できるおよび使用されたリプレイ・データ記憶域、期間および最新の更新を表示できます。これを定期的に確認してレポート要件を満たしていることを確認することをお薦めします。
リプレイ・データのパージ
アプリケーションまたはスイートが削除されるとき、関連するFSRおよびEPRデータはコレクタ・システムから自動的に削除されません。引き続き表示することができます。このデータを削除する場合、「リプレイ・アクティブ」列に表示されている「削除」アイコンをクリックする必要があります。データの削除を確認するように求められます。
RUEIで使用されるリプレイ・ビューアに書き込まれる情報を制御することができます。リプレイ・アクションを監視中のすべてのトラフィックに適用するか、特定のIPアドレス範囲に適用するかを指定できます。また、接頭辞を指定することによって、特定のURLコンテンツをログに記録する方法も制御できます。RUEIのデプロイメントでリプレイ・ポリシーを指定するには、次の手順を実行します。
「構成」、「セキュリティ」、「リプレイ・ロギング・ポリシー」の順に選択します。図13-32に示すウィンドウが表示されます。
「デフォルトのリプレイ・アクション」設定をクリックします。図13-33に示すダイアログが表示されます。
「アクション」メニューを使用して、リクエストとレスポンスのヘッダーおよび本体において、監視中のトラフィックのどの要素をリプレイ・ビューア機能とコレクタ・ログ・ファイルに記録するかを指定します。表13-8に、使用可能なオプションを示します。
表13-8 デフォルトのロギング・アクション
| マスキング・アクション | 説明 |
|---|---|
|
リプレイなし |
すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアには何も保存しないように指定します。これがデフォルトです。 |
|
完全ロギング |
すべての部分をリプレイ・ビューアとコレクタ・ログ・ファイルの両方に保存するように指定します(他にマスキングが定義されていればその適用後)。 |
|
リクエスト本体なし |
すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアにリクエスト本体は保存しないように指定します。 |
|
返信本体なし |
すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアに返信本体は保存しないように指定します。 |
|
ヘッダーのみ |
すべての部分を(他にマスキングが定義されていればその適用後に)コレクタ・ログ・ファイルに保存するが、リプレイ・ビューアにはリクエスト・ヘッダーとレスポンス・ヘッダーのみを保存するように指定します。 |
マスキング・アクションの使用方法の詳細は、13.6項「ユーザー情報のマスキング」を参照してください。
「リプレイIP範囲」設定をクリックします。図13-34に示すダイアログが表示されます。
「範囲」メニューでは、選択したデフォルト・アクション(デフォルト)を使用してすべてのIPアドレス範囲のネットワーク・トラフィックをログに記録するか、それとも特定のアドレス範囲のトラフィックのみを記録するか指定します。次に、「保存」をクリックします。図13-32に示すウィンドウに戻ります。
特定のIPアドレス範囲からのみネットワーク・トラフィックをログに記録する場合は、IP範囲のロギング・タブをクリックします。「すべてのIPアドレス」オプションを選択した場合は、既存のIPアドレス範囲の定義が無効になり無視されます。
「新規IP範囲の追加」をクリックして新しいIPアドレス範囲を定義するか、既存の定義をクリックして変更します。図13-35に示すダイアログが表示されます。
トラフィックのロギングを限定するIPアドレスとネットマスクの組合せを指定します。次に、「保存」をクリックします。
オプションで、「アップロード・リスト」をクリックすると、現在定義されているIPアドレス範囲に、IPアドレス範囲のリストをマージすることができます。ファイルは、1行が1エントリである必要があり、各アドレス範囲に関する情報(IPアドレスとネットマスク)はタブで区切られている必要があります。次に、「マージ」をクリックします。
URLコンポーネントのロギング・ポリシーを指定するには、「URL接頭辞」タブをクリックします。現時点で定義されているURL接頭辞がリストされます。例を図13-36に示します。
「新規URL接頭辞の追加」をクリックして新しいURL接頭辞を定義するか、既存のURL接頭辞をクリックして変更します。図13-37に示すダイアログが表示されます。
URLコンポーネントを指定し、対応するロギング・アクションを選択します。表13-8に、使用可能なオプションを示します。次に、「保存」をクリックします。
リプレイ・アクションの適用方法の理解
次の点を理解してください。
マスキング・アクション「ロギングなし」が明示的に定義されているURL接頭辞のリプレイ・アクション(13.6項「ユーザー情報のマスキング」を参照)は、自動的にリストされた項目として表示されて変更できません。例(/bin)を図13-36に示します。これらの項目を変更する場合、最初にマスキング・アクションを「ロギング」に変更する必要があります。
表13-8に記載されているリプレイ・アクションは、リプレイ・ビューア機能に記録されている項目を制御します。表13-9に、各リプレイ・アクション内で記録される部分を示します。
リプレイ・ビューアで確認用にログ・アイテムを使用できる期間は、各監視対象アプリケーションに指定されるエラー・ページ・リプレイ(EPR)およびフル・セッション・リプレイ(FSR)によって決定されます。このため、レポート要件を満たす十分な記憶域が割り当てられていることを確認する必要があります。これらの設定は、13.9項「コレクタのデータ保存ポリシーの定義」で説明されています。
URL接頭辞の適用方法の理解
アクティブなIPアドレス範囲にURL接頭辞のリプレイ・アクションが定義されていると、デフォルトのリプレイ・アクションより優先されます。
一致するURL接頭辞が重複する場合(たとえば、/ruと/rueiなど)には、別々のリプレイ・アクションが割り当てられ、最長一致が採用されます。また、接頭辞は厳密に先頭部分に適用されることに注意してください。たとえば、対象のURLが/app/rueiの場合は、/ruも/rueiも一致しません。
URL接頭辞に疑問符(?は)指定できません。指定すると、疑問符とその後の内容がすべて無視されます。たとえば、URL /catalog/jn.php?itemと指定すると、切り捨てられて/catalog/jn.phpになります。URLは判読可能な形式で(エンコーディングではなく)指定する必要があります。
URL接頭辞は大/小文字が区別されます。
デフォルトでは、レポータに接続されているコレクタは、ペイロード・サイズが64KBまでの受信フレームのみを監視します。これにより、ネットワーク・ドライバでTCPセグメンテーション・オフロードを使用している場合に、RUEIはトラフィックを監視できます。場合によっては、メモリー使用量を削減して、メモリーに保持できるフレーム数を増やすために、最大フレーム・サイズを大きくする必要があります。最大フレーム・サイズを削減する手順は、次のとおりです。
「構成」、「セキュリティ」、「超特大フレーム」の順に選択します。
「プロファイル」メニューを使用して、目的のコレクタ・プロファイルを選択します。
最大フレーム・サイズの設定をクリックします。
プロファイルのコレクタによって受け入れられる受信フレームの最大サイズを選択します。デフォルトは64 KBです。指定した最大値を超えるフレームは破棄され、メッセージがイベント・ログに記録されます。次に、「保存」をクリックします。
表13-10に、メモリーに保持できるフレーム数を示します。
表13-10 最大フレーム・サイズ、フレーム数およびバッファ・サイズ
| 最大フレーム・サイズ | フレーム数 | バッファ・サイズ |
|---|---|---|
|
64K脚注1 |
8K |
512MB脚注2 |
|
32K |
16K |
512MB脚注2 |
|
16K |
32K |
512MB脚注2 |
|
8K |
64K |
512MB |
|
4K |
64K |
256MB |
|
2K |
64K |
128MB |
脚注1 デフォルトです。
脚注2 フレーム数は自動的に調整されます。
このため、監視対象トラフィック内の予想される最大フレーム・サイズを超える最大フレーム設定を行わないことをお薦めします。コレクタ統計機能の「インタフェース」タブ内で、各コレクタで出現する最大フレーム・サイズを確認できます(15.2項「コレクタのステータスの表示」を参照)。
トラブルシューティング手順の詳細は、RUEIインストレーション・ガイドの付録「トラブルシューティング」を参照してください。
