Cisco Security MARS Local Controller および Global Controller ユーザ ガイド リリース 6.x
システム メンテナンス
システム メンテナンス
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 12MB) | フィードバック

目次

システム メンテナンス

実行時ロギング レベルの設定

MARS バックエンド ログ ファイルの表示

監査証跡の表示

未処理メッセージの取得

未処理データのサイズ制限と保存場所について

未処理メッセージの取得

管理者アカウントのデフォルト パスワードの変更

証明書および フィンガープリントの検証と管理について

グローバルな証明書およびフィンガープリントの応答設定

期限切れになった証明書またはフィンガープリントからのアップグレード

対話形式での証明書またはフィンガープリントのアップグレード

手動での証明書のアップグレード

手動でのフィンガープリントのアップグレード

証明書のステータスと変更のモニタリング

データベースの調整とクエリーの最適化

データベースのインデックス化について

[Data Indexing/Query Optimization] ページについて

[Data Indexing/Query Optimization] での手順

濃度の計算

データベース インデックスの作成

データベース最適化のスケジューリング

インデックスの廃棄

システム メンテナンス

MARS アプライアンスのシステム メンテナンス情報の多くは、『 Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System. 』にのみ記載されています。

MARS アプライアンスはメンテナンスがほとんど不要です。メンテナンス タスクの実行には、必要に応じて CLI(コマンドライン インターフェイス)または Web インターフェイスを使用できます。ハードウェア メンテナンス タスクには、実際に物理的に MARS アプライアンスに触って作業する必要があるタスクもあります。


) MARS アプライアンスのデータのアップグレード、バックアップ、および復元の方法については、『Cisco Security MARS Initial Configuration and Upgrade Guide, 6.X』および『Migrating Data from Cisco Security MARS 4.x to 6.0.1』を参照してください。


この章は、次の内容で構成されています。

「実行時ロギング レベルの設定」

「MARS バックエンド ログ ファイルの表示」

「監査証跡の表示」

「未処理メッセージの取得」

「管理者アカウントのデフォルト パスワードの変更」

「証明書および フィンガープリントの検証と管理について」

「データベースの調整とクエリーの最適化」

実行時ロギング レベルの設定

アプライアンスの実行時ロギング レベルを設定するには、[Admin] > [System Maintenance] > [Set Runtime Logging Levels] の順にナビゲートします。通常は、このページの設定はデフォルトのままにしておくことを推奨します。

ロギング レベルを選択したら、[Change Logging Levels] ボタンをクリックします。

選択できるロギング レベルは、次のとおりです。

[Fatal]:重大ロギング メッセージをイネーブルにします。重大メッセージには、アプリケーションの中断をもたらす可能性のある非常に重大なエラー イベントが記録されます。

[Error]:エラーおよび重大ロギング メッセージをイネーブルにします。エラー メッセージには、アプリケーションが動作を継続することはできるエラー イベントが記録されます。

[Warn]:警告、エラー、および重大ロギング メッセージをイネーブルにします。警告メッセージには、潜在的に危険な状況が記録されます。

[Info]:情報、警告、エラー、および重大ロギング メッセージをイネーブルにします。情報メッセージは主に、アプリケーションの大まかな進行状況を示します。

[Debug]:デバッグ、情報、警告、エラー、および重大ロギング メッセージをイネーブルにします。デバッグ メッセージには、アプリケーションのデバッグに最も役立つ詳細な情報イベントが記録されます。

[Trace]:トレース、デバッグ、情報、警告、エラー、および重大ロギング メッセージをイネーブルにします。トレース メッセージには、デバッグ メッセージよりも詳細な情報イベントが記録されます。

MARS バックエンド ログ ファイルの表示

アプライアンスのログ ファイルを表示したり、そのレベルやソースを変更したりするには、[Admin] > [System Maintenance] > [View Log Files] の順にナビゲートします。

図 13-1 バックエンド ログの表示オプション

 

アプライアンスのバックエンド ログを表示するには、日数、時間、分を選択するか、開始日と開始時刻および終了日と終了時刻を選択します。

必要なロギング レベルを選択できます。選択できるレベルは、[All]、[Fatal]、[Error]、[Warn]、[Info]、および [Debug] です。

表示するファイルのソースも選択できます。選択できるのは、[Backend] または [GUI] です。

バックエンド ログ ファイルを表示する手順は、次のとおりです。


ステップ 1 次から、該当するオプション ボタンをクリックします。

[Last]:現在時刻からさかのぼる日数、時間、および分を入力します。

[Start/End]:日付から分までの単位で、絶対的な時間範囲そのものを指定します。

ステップ 2 ユーザ、グループなどを選択します。

ステップ 3 ソースを選択します。

ステップ 4 [Submit] をクリックします。


 

監査証跡の表示

アプライアンスのユーザ アクティビティを追跡するには、アプライアンスのログ ファイルを分析します。アプライアンスの監査証跡ログを設定するには、[Admin] > [System Maintenance] > [View Audit Trail] の順にナビゲートします。通常は、このページの設定はデフォルトのままにしておくことを推奨します。

ユーザ監査証跡を表示するには、日数、時間、分を選択します。特定のインターバルを表示するには、開始日と開始時刻および終了日と終了時刻を選択します。

監査証跡を表示する手順は、次のとおりです。


ステップ 1 次から、該当するオプション ボタンをクリックします。

[Last]: DD-HH-MM

[Start/End]: YY-MM-DD-HH-MM

ステップ 2 リストからユーザまたはユーザ グループを選択します。

ステップ 3 [Submit] をクリックします。


 

未処理メッセージの取得

未処理メッセージは、アーカイブ サーバ(「 Configuring and Performing Appliance Data Backups 」を参照してください)または Local Controller 上で稼動しているローカル ファイルから取得できます。これらの 2 つの方法には、それぞれの利点があります。

アーカイブ サーバの場合: アーカイブ サーバから未処理メッセージまたはイベント データを取得する方法は、データベースから取得する方法よりもはるかに高速です。したがって、この方法を使用でき、かつこの方法で調査期間がカバーされている場合は、この方法を推奨します。ただし、このオプションを使用できるのは、データ アーカイブをイネーブルにしていて、初期アーカイブ動作が発生するまでに必要な時間を待機した場合のみです。これは、午前 2:00 ごろに実行するようにスケジュールされている操作です。初期アーカイブが実行された後は、MARS アプライアンスがメッセージを受信してから 5 ~ 8 分内に、イベント データがアーカイブ サーバに頻繁に書き込まれます。このデータはリアルタイムでアーカイブされないため、このオプションには、調査できるのが過去の期間であるという別の制限事項があります。1 時間前のデータよりも新しいデータを表示する必要がある場合は、[Database] オプションを選択して、正しいデータが取得されるようにする必要があります。その他のすべての期間には、アーカイブ サーバ オプションを推奨します。アーカイブをイネーブルにする方法については、「 Configuring and Performing Appliance Data Backups 」を参照してください。

ローカル ファイルの場合 : ローカル ファイルからイベント データを取得する方法は、アーカイブ サーバ方式よりも低速ですが、受信した最新データにアクセスできます。アーカイブされた未処理データには 5 つのタプルはないのに対し、ローカル ファイルには 5 つのタプルがあります。

ここでは、次の内容について説明します。

「未処理データのサイズ制限と保存場所について」

「未処理メッセージの取得」

未処理データのサイズ制限と保存場所について

5.2.4 リリースよりも前は、ローカル データベース内の未処理メッセージ データの保存は、メッセージごとに 500KB までと制限されていました。5.2.4 から、ローカル ファイルに未処理メッセージを最大 1.5MB まで、切り詰めることなく保存できるようになりました。MARS アプライアンスの各モデルが、任意のサイズの未処理メッセージ ファイル用に予約された専用ディスク空間を持っています。このストレージ サイズの上限に達したら、pnarchiver プロセスは、リモート NFS サーバが設定されている場合には、未処理メッセージと関連のインデックス ファイルをリモート NFS サーバに移動させます。NFS サーバが設定されていない場合は、未処理メッセージ ファイルが、最も古いデータから順に削除されていきます(FIFO)。データベースが削除されると、対応する未処理メッセージ ファイルも削除されます。

未処理メッセージ ファイルは、 /pnarchive/DATA_POOL の下にアーカイブされています。DATA_POOL ディレクトリには、日付の付いたディレクトリが入っており、その下にその日付の日に作成された未処理メッセージ ファイルが保存されています。 /pnarchive/DATA_POOL/<date > ディレクトリのリストの例を次に示します。

2007-02-10
2007-02-11
 

ファイル名には、次のフォーマットが使用されます。

[dbversion]-[productversion]-[serialno]_[StartTime]_[EndTime].gz
 

たとえば、./pnarchive/DATA_POOL/2007-02-12/ES のリストは、次のようになります。

ix-5248-524-1171238692_2007-02-12-00-04-46_2007-02-12-01-04-51.gz
rm-5248-524-1171238692_2007-02-12-00-04-46_2007-02-12-01-04-51.gz
 

) 「ix」で始まるファイルはインデックス ファイル、「rm」で始まるファイルは未処理メッセージ ファイルです。


未処理メッセージの取得

未処理メッセージは、ファイルのソースおよび送信先の [Retrieve Raw Messages] ページで指定した設定に応じて、4 つのいずれかのモードで取得できます。次を実行できます。

ローカル MARS キャッシュにアーカイブされたファイルからデータを取得する。

リモート ネットワーク ファイル サーバ(NFS)にアーカイブされたファイルからデータを取得する。

ローカル MARS キャッシュのデータベースからデータを取得する。

リモート ネットワーク ファイル サーバ(NFS)のデータベースからデータを取得する。

時間範囲、報告元デバイス、およびファイル サイズで出力にフィルタをかけることもできます。

未処理メッセージ イベント データを取得する手順は、次のとおりです。


ステップ 1 [Admin] > [System Maintenance] > [Retrieve Raw Messages] の順にクリックします。

[Raw Message Files] ページが表示されます。

図 13-2 [Retrieve Raw Messages] ページ

 

ステップ 2 [Data Source] 領域で、ソースとして [Archived Files] または [From Database] を選択します。


) データ ソースとして [Archived Files] を選択するには、アーカイブがイネーブルになっている必要があります。


ステップ 3 [Filter] 領域で、[Start] と [End] の各フィールドで値を指定することにより、時間範囲を指定します。


) デフォルトは、最近の 10 分間 です。


ステップ 4 [File Size] 領域で、[Specify Uncompressed File Size (Compression Ratio 10:1)] を選択してから、サイズの上限をボックスに入力することにより、ファイル サイズの制限を指定します (指定できる範囲は、1 ~ 1024 MB です)。デフォルト サイズは、100 MB です。

[Archived Files] を選択していて、ファイル サイズの制限を指定していなかった場合は、指定した時間範囲内のすべてのファイルへのリンクが表示されます。

ステップ 5 [Output Settings] 領域で、次の いずれか を選択します。

[Local MARS Cache]:次のオプションが選択できるようになります。

[Force Generation of Files] オプションを選択解除すると、ファイルの強制的な生成を無効にできます。

[View Local Cache] をクリックすると、キャッシュが表示されます。

[Maximum Number of Files] フィールドに値を入力して、ファイルの数を増やしたり、制限したりできます。

[Remote NFS Server]:出力の宛先にこのオプションを選択する場合は、[Remote Host IP] および [Remote Path] を指定する 必要があります

ステップ 6 [Output Raw Message Time Format] に、次の いずれか を選択します。

[Local Time](出力未処理メッセージは、現地時間で表示されます)

[UTC Time](出力未処理メッセージは、UTC 時間で表示されます)

ステップ 7 [Submit] をクリックします。


) MARS がファイルを生成している間、システムで他のタスクを実行することができます。


[Retrieving Progress 0%] 画面が表示されます。この処理が完了したら、[Raw Message Files] 画面が表示され、新しい Gzip アーカイブ ファイルが指定した時間範囲に基づくファイル名で示されます。ファイルがソース(アーカイブまたはデータベース)から MARS 内のローカル キャッシュまたは指定した NFS にコピーされ、ファイルをダウンロードするためのリンクが GUI に表示されます。

 

ステップ 8 生成された未処理メッセージ ファイルをダウンロードして表示するには、ファイル名の横にある [Click Here to Download] をクリックします。

ファイル名は、 YYYY-MM-DD-HH-MM-SS_YYYY-MM-DD-HH-MM-SS.gz というフォーマットで作成されます。

ステップ 9 WinZip またはその他のアーカイブ展開プログラムを使用して、Gzip アーカイブ ファイルの内容を抽出します。

ステップ 10 GNU Zip アーカイブ フォーマットから抽出されたテキストファイルの内容は、次のようになります。

33750»Wed Jul 27 16:16:06 PDT 2005»BR-FW-1»10.1.2.4»9000»10.1.5.20»80»6»<134>Jan 06 2003 11:03:53: %PIX-6-302001: Built inbound TCP connection 21000 for faddr 10.1.2.4/9000 gaddr 10.1.5.20/80 laddr 10.1.5.20/80
 

この内容は、 イベント ID >> 日付 >> デバイス名 >> ソース IP >> ソース ポート >> 宛先 IP >> 宛先ポート >> プロトコル番号 >> 未処理メッセージ です。


) 生成されたテキスト ファイルに漢字またはその他の見慣れない文字列が表示された場合は、Microsoft Internet Explorer を使用してファイルを表示し、Western European ISO または Western European Windows のエンコードが選択されていることを確認してください( [表示] > [エンコード] の順に選択)。互換性のあるエンコードが選択されている場合は、「?」記号がセパレータとして正しく表示されます。



 

管理者アカウントのデフォルト パスワードの変更

セキュリティを高めるには、デフォルト パスワードを変更する必要があります。MARS アプライアンスには強力なパスワードを使用することを推奨します。

ログイン名およびパスワードには、次の事項が当てはまります。

英数字を使用できます。

大文字と小文字が区別されます。

特殊文字を使用できます(!,、@、# など)。

一重引用符(')および二重引用符(")は使用 できません

ログイン名は最大 20 文字、パスワードは最大 64 文字です。

デフォルト パスワードを変更したり、管理者通知を設定する手順は、次のとおりです。


ステップ 1 [Management] > [User Management] タブをクリックします。

ステップ 2 [Administrator] の横にあるチェックボックスをオンにし、[Edit] をクリックします。

ステップ 3 新しい管理者パスワードおよび管理者の電子メール アドレスを入力します。

ステップ 4 [Submit] をクリックします。


 

証明書および フィンガープリントの検証と管理について

多くの報告元デバイスが、SSL または SSH を介した安全な通信を可能にするために、証明書またはフィンガープリントを使用しています。MARS は、接続相手となるデバイスやサーバの証明書またはフィンガープリントの厳密なチェックを実行します。


) 証明書の検証は、証明局のリストでクライアントを提示し、選択されたものを使用して個々の証明書を検証する規約には従いません。そうではなく、MARS アプライアンスは、報告元のデバイスによって提示された証明書を以前に保存していた証明書と比較します。2 つが一致すれば、提示された証明書は有効であるものと見なされます。このアプローチは、MARS が失効リストを知らなくても証明書を検証できるため、インターネット接続のないネットワーク上でも機能します。


セキュアな接続の確立を試みる際に MARS がどのように応答するかを指定するためのオプションは、3 つあります。その 3 つのオプションは次のとおりです。

[Automatically always accept]: このオプションは、以前のバージョンと互換性のあるオプションで、MARS はすべてのデバイスについて証明書またはフィンガープリントの差し替えを自動的に受け付けて、新しい証明書またはフィンガープリントを保存するため、証明書またはフィンガープリントの変更頻度と関係なく MARS アプライアンスが報告元デバイスと接続することが可能です。ただし、このオプションでは、証明書またはフィンガープリントに加えられた変更を検査して許可する機会が得られません。競合が検出された場合や、新しい証明書またはフィンガープリントが受け付けられた場合には、内部ログにイベントが記録されます。内部ログのエントリには、競合を検出したプロセスの名前および報告元デバイスの IP アドレスが含められます。ログは、クエリーおよびレポートで取得できます。これらのイベントの詳細については、「証明書のステータスと変更のモニタリング」を参照してください。

[Accept first time and prompt on change](デフォルト):. このオプションでは、MARS アプライアンスは、初めて接続したデバイスの新しい証明書またはフィンガープリントを受け付け、保存します。以降の接続試行では、アプライアンスは提示された証明書またはフィンガープリントを保存されている値と照らし合わせてチェックします。競合が検出された場合は、セッションは拒否されます。新しい証明書またはフィンガープリントは、管理者が手動で受け付ける必要があります。このオプションは、初期のトポロジ検出を管理者の介在なしに処理することを可能にします。初期の受け付け、競合検出、および新しい変更の受付の内部システム ログが生成されます。内部ログには、競合を検出したプロセスの名前、報告元デバイスの IP アドレス、および変更の受け付けに使用されたアカウントのユーザ名が含められます。

Web インターフェイス プロセスによって変更が検出され、管理者が介在する前にセッションがタイムアウトした場合は、通信は失敗しますが、変更された証明書またはフィンガープリントを受け付けるための失敗を記録する内部システム ログは生成されません。また、バックエンド プロセスが自動検出などの要求を開始する場合は、セッション試行は常に失敗し、管理者による受け付けを得るための試行は開始されません。この場合には、通常であれば MARS アプライアンスがこのようなセッション中にデバイスから取得するデータが一切収集されません。このデータ取得の遅延は、報告元デバイスによる MARS アプライアンスへの syslog 転送に適用されず、新しい証明書が受け付けられて初めて再開されます。変更検出の手動での開始に推奨される方法は、報告元デバイスの [Test Connectivity] ボタンまたは [Discover] ボタンを使用することです。

[Always prompt on new and changed]: このオプションでは、MARS が必要な通信を確立できるようにするには、証明書またはフィンガープリントが変更されるたびに、管理者が手動で証明書またはフィンガープリントを受け付ける必要があります。変更中、変更の受け付けに使用されたアカウントのユーザ名が内部ログに含められます。管理者が介在する前に通信がタイムアウトした場合は、通信は失敗し、変更された証明書またはフィンガープリントを受け付けるために、内部システム ログに失敗が記録されます。

各オプションの持つ意味は、オプションの実施においてではなく、サービスがただちに管理者の介在を促すことができるかどうかという意味で、どの MARS サービスが接続を試みるかによって変わってきます。つまり、サービスが GUI ベースのサービスである場合、変更された証明書またはフィンガープリントを受け付けるように求められますが、サービスがバックエンド サービスの場合は、ターゲット デバイスとの通信が失敗し、イベントがログに記録されます。

次のサービスと操作が、グローバルな証明書/フィンガープリント応答設定によって影響されます。

アップグレード(SSL)。MARS は、[Admin] > [System Maintenance] > [Upgrade] ページで指定されたリモート サーバからアップグレード パッケージをダウンロードするのに HTTPS オプションを使用します。

検出操作 (SSH)

テスト接続操作 (SSL)

Cisco IDS、IPS、および IOS IPS ルータのイベント処理(RDEP または SDEE over SSH)

CSM ポリシー クエリー統合(SSL)

クエリー レポート検出 (SSL)

軽減操作のための Graphgen プロセス(SSH および SSL)

リソース モニタリング機能のためのデバイス モニタ プロセス(SSH)

グローバルな証明書およびフィンガープリントの応答設定

デフォルトの応答では、MARS が初めてデバイスに接続しようとしたときに証明書またはフィンガープリントが受け付けられ、その後は、競合が検出されると、新しい証明書またはフィンガープリントに更新するために管理者の介在が必要になります。

このオプションが使用したいオプションではない場合は、3 つのオプションからいずれかを選択できます。競合検出応答のグローバル設定は、[Admin] > [System Parameters] > [SSL/SSH Settings] ページにあります。

証明書およびフィンガープリントのデフォルトの応答を変更する手順は、次のとおりです。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Parameters] > [SSL/SSH Settings] タブをクリックします。

ステップ 3 次のいずれかのオプションを選択して、グローバルな動作を定義します。

[Automatically always accept]

[Accept first time and prompt when changed]

[Always prompt on new and changed]

これらのオプションの詳細については、「証明書および フィンガープリントの検証と管理について」を参照してください。

ステップ 4 [Submit] をクリックします。


 

期限切れになった証明書またはフィンガープリントからのアップグレード

[Automatically always accept] (「グローバルな証明書およびフィンガープリントの応答設定」を参照してください)以外のグローバル応答オプションを選択した場合は、いつかの時点で、期限が切れた証明書またはフィンガープリントを更新する必要が生じます。

期限が切れた証明書またはフィンガープリントからアップグレードするには、2 つのオプションがあります。GUI プロセスが証明書またはフィンガープリントの競合を検出したときに Web インターフェイスにログインしていた場合は、新しい値を受け付けるか拒否するかを尋ねられます。一方、ログインしていなかった場合、またはバックエンド プロセスが競合を検出した場合は、デバイスとの通信を手動で開始する必要があります。証明書またはフィンガープリントを手動で更新しなければならないデバイスの一覧を調べるには、Activity: CS-MARS Detected Conflicting Certificates/Fingerprints レポートを確認してください(「証明書のステータスと変更のモニタリング」を参照してください)。

次の手順は、特定の環境下でアップグレードを行う方法について説明したものです。

「対話形式での証明書またはフィンガープリントのアップグレード」

「手動での証明書のアップグレード」

「手動でのフィンガープリントのアップグレード」

対話形式での証明書またはフィンガープリントのアップグレード

対話形式でのアップグレードとは、Web インターフェイスでの指示に応答することによって証明書を更新することをいいます。このタイプのアップグレードは、管理者が GUI にログインしていて、graphgen などのプロセスが、以前受け付けた値と競合する証明書またはフィンガープリントのアップグレードを促す場合に使用できます。[Yes] をクリックして、新しいフィンガープリントまたは証明書を受け付けます。

手動での証明書のアップグレード

手動のアップグレードでは、その理由が対話形式での指示中のセッション タイムアウト、ユーザ エラー、バックエンド プロセスによる競合の検出などの何であったかに関係なく、いつでも、どの証明書でもアップグレードできます。

新しい証明書に手動でアップグレードする手順は、次のとおりです。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Setup] > [Security and Monitor Devices] ページで、MARS が証明書の競合を検出した報告元デバイスを選択します。[Edit] をクリックします。

ステップ 3 [Test Connectivity] をクリックします。

「Do you want to accept following certificate for the device named: <device_name>?」というメッセージの入ったダイアログボックスが表示されます。

ステップ 4 証明書の値を確認します。

ステップ 5 値が正しければ、[Yes] をクリックします。


 

手動でのフィンガープリントのアップグレード

手動のアップグレードでは、その理由が対話形式での指示中のセッション タイムアウト、ユーザ エラー、バックエンド プロセスによる競合の検出などの何であったかに関係なく、いつでも、どのフィンガープリントでもアップグレードできます。

フィンガープリントを手動でアップグレードする手順は、次のとおりです。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Setup] > [Security and Monitor Devices] ページで、MARS がフィンガープリントの競合を検出した報告元デバイスを選択してから、[Edit] をクリックします。

ステップ 3 [Discover] をクリックします。

「Do you want to accept following fingerprint for the device named: <device_name>?」というメッセージの入ったダイアログボックスが表示されます。

ステップ 4 フィンガープリントの値を確認します。

ステップ 5 値が正しければ、[Yes] をクリックします。


 

証明書のステータスと変更のモニタリング

MARS での証明書管理機能をサポートするために、次のシステム検査規則が存在します。

System Rule: CS-MARS Failure Saving Certificates/Fingerprints: この検査規則は、[SSL/SSH Settings] ページで指定されたとおりの明示的なユーザ操作または自動受け付けのいずれかに基づく新しいまたは変更されたデバイス SSL 証明書または SSH 鍵フィンガープリントの保存に失敗したことを示します。

さらに、System: CS-MARS Issue カテゴリの下に次のレポートが表示されます。

Activity: CS-MARS Accepted New Certificates/Fingerprints

Activity: CS-MARS Accepted Conflicting Certificates/Fingerprints

Activity: CS-MARS Detected Conflicting Certificates/Fingerprints

Activity: CS-MARS Accepted New Certificates/Fingerprints'

Activity: CS-MARS Failure Saving Certificates/Fingerprints

Activity: CS-MARS Device Connectivity Errors

データベースの調整とクエリーの最適化

MARS GUI からクエリーを実行して、大きい時間範囲を指定した場合、返される結果には少数のエントリしか含まれない場合であっても、クエリーが完了するまでに長時間を要することがあります。このような長期間のクエリーは、クエリー フィルタを使用するように指定したにも関わらず、データベースに完全なテーブル スキャンの実行を要求しています。

クエリーの実行速度を大きく向上させるために、フィルタリング カラムのデータベース インデックスを作成し、それを使用することをお勧めします。ただし、その場合でも、データベース クエリーのパフォーマンスは、返されるデータの量に依存します。何千行というデータを返すクエリーには、数十行しか返さないクエリーよりはるかに長い時間がかかります。

達成されるパフォーマンスの向上は、作成されたインデックスの数には影響されません。パフォーマンス向上の度合いは、次の 3 つの条件によって変わります。

クエリーが少なくとも 1 つのフィルタを持っている

すべてのフィルタがインデックス化されている(フィルタの数は問題ではなく、フィルタ 1 つで多数のフィルタと同程度に良好な場合もあります)

クエリーが、フィルタリングの後に少数のデータを返す

データベースのインデックス化について

一連のデータベース インデックスで応答時間を大幅に向上させることができますが、さらにインデックスを作成すると、状況によっては、逆の影響が出る場合もあります。クエリー操作を効果的に最適化するために、MARS は、ユーザがデータベースに行うべきインデックス化の性質と範囲を決定する作業を支援します。

MARS は、10 個のデータベース テーブル、 pn_event_session_0 , ... , pn_event_session_9 にセキュリティ イベントを保存します。各テーブルがほぼ同じサイズで、そのサイズは CS-MARS モデルに基づいてあらかじめ定義されています。たとえば、MARS-25 では、各テーブルの行数が MARS-55 よりも約 70% 少なくなります。最新テーブルがデータでいっぱいになると、最も古いデータが格納されているテーブルが切り捨てられ、そこに新しいデータが格納されます。

インデックスとは、データベース テーブル内での特定のデータの場所が格納された特別なデータベース テーブルです。データ テーブルから直接行うエントリの検索はシーケンシャルで、通常は非常に低速になりますが、インデックス テーブルは整理されているため、インデックス テーブルでのエントリの検索は、通常は高速になります。

MARS では、ビットマップ インデックスと B ツリー インデックスの両方が採用されています。ビットマップ インデックスは、データベース テーブルのカラム濃度が低い場合に適しています。濃度とは、1 つのカラム内のはっきりした値の数です。たとえば、 true|false の値しか持たないカラムは、濃度が 2 で、ビットマップ インデックスの最有力候補となります。このため、データベースの適正なインデックス化は、すべてのデータベース カラムの濃度を調べることから始まります。


) B ツリー インデックスは、はるかに多くのシステム リソースを消費し、システム パフォーマンスに重大な影響を与える可能性もあります。B ツリーでのインデックス化は、そのインデックスが推奨されていない場合には慎重に行うようにし、システム パフォーマンスに影響が出ていることを発見したらそのインデックスは廃棄してください。


データベースの最適化については、次の考慮事項を念頭に置いておいてください。

濃度の計算は、テーブル全体に対して行うと、最善の結果が得られます。

濃度の計算は、年に 1 度か 2 度行えば十分です。

濃度の計算は、インデックスを作成する前に行ってください。

返されるデータの範囲を最も少なくするカラムでインデックスを作成してください。

システム パフォーマンスを監視し、インデックス化されたカラムをフィルタとして使用してクエリーをテストしてください。

システム パフォーマンスの低下を発見したときには、インデックスを廃棄してください (廃棄したインデックスは、いつでも復活させられます)。

たとえ「Not Recommended」と評価されたインデックスでも、うまく機能していると判断した場合には残してください。

[Data Indexing/Query Optimization] ページについて

[Data Indexing/Query Optimization] ページでは、 インデックスの設定情報が表示され、インデックス関連の機能を実行できます 。このページを表示するには、[Admin] > [System Maintenance] > [Database Tuning / Query Optimization] を選択します。

図 13-3 に、[Data Indexing/Query Optimization] ページの [System Maintenance] タブを示します。


) [Data Indexing/Query Optimization] ページの表は、別の行にインデックス化することができる各データベース テーブル カラムを示します。


 

図 13-3 [Data Indexing/Query Optimization] ページ

 

1

[Index Column]:どのデータベース カラムがインデックスを作成できるかを示します。

2

[Status]:各インデックス カラムのインデックス ステータスを示します。アクティブなインデックスにはグリーンの四角いチェック アイコンが、アクティブになっていないインデックスには X の入ったブラックの丸いアイコンが 表示されます。

3

[Schedule Task]:各インデックス カラムに 2 つのオプション ボタンがあり、このボタンで、インデックスの操作をスケジューリングするか、ただちに実行するかを選択できます。 スケジューリングする場合は、日付と時刻のための 4 つのフィールドで時刻を指定できます。

4

[Index Cardinality]:各インデックス カラムの最後に濃度がサンプリングされたときのサイズが 1000 単位で表示され、括弧内にサンプル ベース サイズが表示されます。

5

[Last Sampling Date]:各インデックス カラムの最後に濃度計算サンプリングが行われた日付が表示されます。

6

[Recommendation]:各インデックス カラムについて、インデックス化が推奨されるかどうかが次のように示されます。

インデックス化を 推奨 (「Recommended」の文字の横に親指を上に向けたグリーンのアイコンが表示されます)

インデックス化 してもよい (「Not Ideal」の文字の横に親指を上に向けたグリーンのアイコンが表示されます)

インデックス化は推奨 できない (親指を下に向けたレッドのアイコンが表示されます)

7

[Calculate Cardinality Button]:このボタンをクリックすると、選択されているデータベース カラムに対して、ただちに、または指定したスケジュールで濃度計算を実行するように要求できます。

8

[Create Index Button]:このボタンをクリックすると、選択されているデータベース カラムが、ただちに、または指定したスケジュールでインデックス化される(または再インデックス化される)ように要求できます。

9

[Drop Index]:選択されているインデックスを廃棄します。

10

[Cancel Task]:選択されているデータベース カラムに対して要求したアクションを取り消します。

インデックス化されたデータベースのクエリーに対するパフォーマンスは、次の 3 つの要素に依存します。

少なくとも 1 つのフィルタが採用されている

使用されるフィルタがインデックス化されている

クエリーがフィルタリングの後に返すデータが少数である

[Data Indexing/Query Optimization] での手順

[Data Indexing/Query Optimization] ページから行える手順には、次のものがあります。

「濃度の計算」

「データベース インデックスの作成」

「データベース最適化のスケジューリング」

「インデックスの廃棄」

濃度の計算

任意のデータベース テーブル カラムについて、そのカラムがビットマップ インデックスに適しているかどうかをよりよく理解するために、濃度を計算できます。この計算は、システムが作成すべき最適なインデックスのタイプを判断するのにも役立ちます(通常は、濃度値が数千より低い場合はビットマップ インデックスを使用し、濃度値がそれより大きい場合は B ツリー インデックスを使用します)。この操作は、システムへの影響を最小限に留めるために、ピーク時間帯を外して実行されるようにスケジューリングできます。

次の考慮事項を念頭に置いておいてください。

濃度の計算は、テーブル全体に対して行うと、最善の結果が得られます。

濃度の計算は、年に 1 度か 2 度行えば十分です。


警告 システム リソースの消費過多を防ぐために、データベース カラムのインデックスを作成する場合は、必ずその前にその濃度を計算するようにしてください。


データベース カラムの濃度を計算する手順は、次のとおりです。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Maintenance] > [Database Tuning / Query Optimization] の順にクリックします。

[Index Configuration Information] ページが表示されます。

ステップ 3 テーブルの左にある各カラムに対応するチェックボックスを選択することにより、濃度を計算するデータベース カラムを選択します。


ヒント 通常は、すべてのインデックスの濃度をほぼ同じタイミングで計算するのが便利ですが、システムへの影響を低減するためには、日を分けて各夜間に数個ずつ計算を実行した方がよい場合もあります。


ステップ 4 次のいずれかの方法で、いつ計算を実行するかを選択します。

計算をただちに実行するには、デフォルトの [Run Now] を選択します。

計算を後から実行されるようにスケジューリングするには、日付、時間、分、および AM/PM を指定する各フィールドで値を選択します。


ヒント 日付フィールドの横にあるブルーのカレンダー アイコンをクリックすれば、日付を簡単に選択できます。または、mm/dd/yyy のフォーマットで入力することも可能です。


ステップ 5 [Calculate Cardinality] をクリックします。

データベース インデックスの作成

クエリーの実行に使用するデータベース カラムはすべて、インデックス化してください。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Maintenance] > [Database Tuning / Query Optimization] の順にクリックします。

[Index Configuration Information] ページが表示されます。

ステップ 3 テーブルの左にある各カラムに対応するチェックボックスを選択することにより、インデックスを作成するデータベース カラムを選択します。


ヒント 通常は、すべてのインデックスをほぼ同じタイミングで作成するのが便利ですが、システムへの影響を低減するためには、週末に、1 度に 1 つずつインデックスを作成した方がよい場合もあります。


ステップ 4 次のいずれかの方法で、いつインデックスを作成するかを選択します。

インデックスをただちに作成するには、デフォルトの [Run Now] を選択します。

インデックスの作成を後から実行されるようにスケジューリングするには、日付、時間、分、および AM/PM を指定する各フィールドで値を選択します。


ヒント 日付フィールドの横にあるブルーのカレンダー アイコンをクリックすれば、日付を簡単に選択できます。または、mm/dd/yyy のフォーマットで入力することも可能です。


ステップ 5 [Create Index] をクリックします。

データベース最適化のスケジューリング

この手順では、1 つ以上のデータベース テーブルの更新をスケジューリングできます。システムへの影響を低減するためには、週末に、1 度に 1 つずつインデックスを最適化した方がよい場合もあります。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Maintenance] > [Database Tuning / Query Optimization] の順にクリックします。

[Index Configuration Information] ページが表示されます。

ステップ 3 更新をスケジューリングするデータベース カラムを選択します。


ヒント 以前にすでに特定のインデックスの最適化をスケジューリングしていた場合は、インデックスを選択してから [Cancel Task] を選択することにより、タスク要求を削除できます。


ステップ 4 日付、時間、分、および AM/PM を指定する各フィールドで値を選択して、時刻を指定します。

ステップ 5 [Create Index] をクリックします。

ステップ 6 更新する各データベース カラムに対して、ステップ 3ステップ 5 を繰り返します。


 

インデックスの廃棄

アクティブなインデックスが多すぎると、システム パフォーマンスの問題が発生し、イベント速度に影響が及びます。データベース インデックスを 3 つ以上コンパイルしていると、この警告が発生します。インデックスがシステム パフォーマンスに影響を与えていることがわかった場合は、インデックスを廃棄してください。


ステップ 1 管理権限を持つアカウントを使用して、Web インターフェイスにログインします。

ステップ 2 [Admin] > [System Maintenance] > [Database Tuning / Query Optimization] の順にクリックします。

[Index Configuration Information] ページが表示されます。

ステップ 3 インデックス ステータスが [Index Active] と表示されている任意のデータベース カラムのチェックボックスを選択します。

ステップ 4 次のいずれかの方法で、いつインデックスを廃棄するかを選択します。

インデックスをただちに廃棄するには、デフォルトの [Run Now] を選択します。

インデックスを後から廃棄されるようにスケジューリングするには、日付、時間、分、および AM/PM を指定する各フィールドで値を選択します。

ステップ 5 [Drop Index] をクリックします。