5 操作管理

操作管理は、現在の物理インフラストラクチャとその監視方法に関する、Configuration Change Consoleの構成機能と関連しています。これは、コンプライアンス・ポリシーのフレームワーク、ポリシーおよびコントロールと関連するポリシー管理とは対照的です（第6章「ポリシー管理」を参照）。Configuration Change Consoleでは、重要なアプリケーション・コンポーネントを監視および監査し、割当て済のアプリケーション・ポリシーを通じてアプリケーション・インフラストラクチャの変更を検出およびレポートできます。操作管理構成には、次の要素が含まれます。

• コンポーネント: アプリケーションで監視する重要なファイル、プロセス、データベースおよび内部オブジェクトを指定します。これらの監視ポイントは、インフラストラクチャにおけるアプリケーションの多くの異なるインスタンス全体で共通である可能性があります。たとえば、注文処理アプリケーションのコンポーネントでは、変更を監視する必要のある特定のファイルおよびプロセスが識別されます。

• コンポーネント・インスタンス: 1つ以上の監視デバイスにコンポーネントを割り当てる場合、それらの各割当てはコンポーネント・インスタンスと呼ばれます。単一のコンポーネントは、そのコンポーネントの目的に応じて1つ以上のデバイスにマップできます。たとえば、環境内のすべてのサーバーで実行する必要のあるウイルス対策プログラムなどのコンポーネントを定義できます。これらの各割当ては、コンポーネント・インスタンスとみなされます。

• アプリケーション: 管理デバイスにコンポーネントを割り当てたら、それらのコンポーネント・インスタンスで構成されるアプリケーションを作成できます。アプリケーションは、ビジネス・アプリケーションを構成する多くのコンポーネントの変更データを監視、レポートおよび管理する際に役立ちます。たとえば、注文処理アプリケーションでは、状況に応じてデータベース、アプリケーション・サーバーおよびWebサーバーを実行する必要があります。これらのコンポーネントをすべて注文処理アプリケーションに指定して、レポート処理を簡略化できます。

• 監査アクション: 監査アクションでは、特定のコンポーネントまたはアプリケーションでイベントが発生したときにサーバーで実行する様々なアクションを定義します。構成可能なアクションには、電子メール通知、SNMPトラップ、レポート生成、および統合変更管理システムに送信されるアノテーションがあります。

注意: 変更管理システムを統合して認可済イベントと未認可イベントを検出する場合、追加の構成手順を実行する必要があります。第7章「変更管理サーバーとの統合」を参照してください。

コンポーネントを定義する前に、次の項目を決定する必要があります。

• 各コンポーネントで監視するファイル、プロセスおよび内部オブジェクト（ルール）

• これらのファイル、プロセスおよび内部オブジェクトを相互に関連付ける方法。重要な構成ファイルであるために重要なもの。常に実行されている必要があるプロセスあるいは一連のファイルへのアクセス権がないユーザーであるために重要なもの。（コンポーネント）

• 監査および通知する変更（監査アクション）

• コンポーネント・インスタンスをアプリケーションにグループ化してビジネス・アプリケーション構造に関連付ける方法（レポート、管理および変更分析目的）

コンポーネントを定義する場合、次のことに留意してください。

• 単一のコンポーネント内で複数のオペレーティング・システム・プラットフォームを組み合せて使用することはできません。アプリケーションに複数のオペレーティング・システムに基づくコンポーネントが存在する場合、オペレーティング・システムのコンポーネントごとに個別のコンポーネントを定義する必要があります。その後、異なるコンポーネント・インスタンスをグループ化して、実際のビジネス・アプリケーションを表す単一のアプリケーションにまとめることができます。

• 単一のコンポーネント・インスタンスは、複数のアプリケーションに割り当てることができます。たとえば、アプリケーションまたはビジネス機能別、オペレーティング・システム別およびリージョン別にコンポーネント・インスタンスをグループ化できます。

• 1つのコンポーネントに対して構成できるのは、1つの内部監視機能またはエージェント・モジュールのみです。この制限の主な目的は、コンポーネント・インスタンスに対するレポートが意味を失わない程度にコンポーネント定義の粒度を維持することにあります。内部監視モジュールには、次のものが含まれます。

  • Active Directory(スナップショット)

  • Active Directory(トレース)

  • Oracle 8i(スナップショット)

  • Oracle 8i/9i/10g(SQLトレース)

  • Oracle 9i/10g(スナップショット)

  • SQL Server(スナップショット)

  • SQL Server 2000(SQL監査)

  • SQL Server 2000(SQLトレース)

  • Windowsレジストリ(トレース)

• コンポーネントは、時間経過に伴って変更できます。たとえば、Configuration Change Consoleのライフサイクルの初期には、コンポーネント内の多くのルールを監視する一方で、時間の経過とともにコンプライアンス・イニシアチブまたは変更管理プロセスに関連する変更に監視対象を絞り込むことができます。この調整は、継続的なプロセスであり、時間が経過するにつれてその頻度は少なくなります。

• コンポーネントは、非常に個別的であるか、非常に一般的であるかのいずれかです。たとえば、企業全体のすべてのデバイスに含まれる一連のファイルを監視するために、Critical OS Filesというコンポーネントを構成できます。その後、このコンポーネントを割り当てて、デバイスごとにインスタンスを保持できます。また、アプリケーションの一部に対するパッチを定義するコンポーネントなど、非常に個別的なコンポーネントを作成することもできます。たとえば、Financeアプリケーション・サーバーが存在し、それにパッチを適用する場合、パッチ処理の一環として変更されるファイルを監視するコンポーネントを作成できます。

ビジネス・アプリケーションのモデル化手順

次の表に、現在のIT環境で稼働しているビジネス・アプリケーションを反映するようにこの製品でコンポーネントをモデル化し、アプリケーションを作成する場合の基本手順の概要を示します。手順の詳細は、この章の後続の項を参照してください。

表5-1 ビジネス・アプリケーションのモデル化手順

手順	タスク	説明
1	1つ以上のコンポーネントを作成します。	使用しているビジネス・アプリケーションの各部分に対して、独自コンポーネントを作成するか、製品に付属する事前定義済コンポーネントのいずれかをコピーします。コンポーネントの例として、データベース・インスタンス、アプリケーション・サーバー、ファイアウォール、メッセージング・バス、重要なOSファイル、機密データを含むデータベース表、アプリケーション・サーバーのセキュリティ・ファイルなどがあげられます。
2	ルール・セットを選択して各コンポーネントのルールを指定します。	ファイル、プロセス、ユーザー、またはデータベース表などの内部オブジェクト（あるいはこれらの任意の組合せ）のルール・セットを監視できます。一部のルール・セットには、追加の構成パラメータが必要です。ルール・セットごとに、コンポーネントの一部として監視する対象を制御する包含/除外ルールをいくつか指定します。
3	管理デバイスにコンポーネントをマップしてコンポーネント・インスタンスを作成します。	この手順では、基本的に関連コンポーネントの特定のインストールに監視ルールを適用し、インストール済エージェントにどの要素の変更を監視するかを指示します。
4	アプリケーションを作成して管理およびレポート作業を簡略化します。	機能ごとにコンポーネント・インスタンスを論理的にグループ化します。この意味でのアプリケーションは、Financeアプリケーションなどの実際のビジネス・アプリケーションに関連しています。
5	コンポーネント・インスタンスまたはアプリケーション全体の監査アクションを定義します。	変更管理システムと統合している場合、これらの監査アクションは、コンポーネントおよびアウトバウンド・チケット・テンプレートを構成すると自動的に作成されます。通知などの追加アクションを指定する場合、追加の監査アクションを作成するか、自動的に作成された監査アクションを変更することができます。

コンポーネントの理解

製品を構成してIT組織にマップする最初の手順では、アプリケーションを構成するコンポーネントを理解し、それらのコンポーネントをモデル化します。コンポーネントは、現在の環境内で使用されているアプリケーションに関連する重要な要素のブループリントとして機能します。管理デバイス上で実行中のインストールにこれらのコンポーネントを適用することで、エージェントにより実行される監視の内容を決定できます。

コンポーネントにより、次のような監視対象のオペレーティング・システムおよびアプリケーションのルール・セットが識別されます。

• ファイル

• プロセス

• OSユーザー

• アプリケーション固有の内部オブジェクト

  • データベース・オブジェクト

  • Active DirectoryおよびLDAPオブジェクト

  • その他のアプリケーション・オブジェクト

Configuration Change Consoleには、様々なオペレーティング・システムおよびアプリケーション用の監視ルールを含む事前定義済コンポーネントのセットが付属しています（付録A「事前定義済コンポーネント・テンプレート」のリストを参照）。これらの事前定義済コンポーネントを開始ポイントとして使用し、独自の監視、コンプライアンスまたは監査要件にあわせてカスタマイズできます。

単一のコンポーネントを作成して、それを環境内の複数のインスタンスに割り当てることができます。複数のコンポーネントにルールを指定する必要はありません。ルールの差異がわずかである場合は、特定のインスタンスに対するコンポーネントのグローバル設定を上書きできます。次のいずれかの方法を使用して、必要な数のコンポーネントを構成し、アプリケーションをモデル化できます。

• 事前定義済コンポーネントを使用してカスタム・コンポーネントを作成します。

• 「コンポーネント」画面を使用してカスタム・コンポーネントを追加します。

• 別のサーバーで作成されたコンポーネントをインポートするか、XMLファイルを手動で作成します。

手順1: コンポーネントの作成

「コンポーネント」画面を使用して、監視するアプリケーション用のカスタム・コンポーネントを作成します。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

「コンポーネント」画面では、次の複数のビューを使用できます。

1. 事前定義済コンポーネント: 製品に付属するコンポーネントが表示されます。すべての事前定義済コンポーネントには、業界トップレベルのアプリケーション・スペシャリストの入力に基づいた監視ルールが指定されています。特定の監査要件を満たすカスタム・コンポーネントの基盤としてこれらの事前定義済コンポーネントを使用できます。事前定義済コンポーネントは、デバイスに直接割り当てることはできません。事前定義済コンポーネントは、使用する前にカスタム・コンポーネントとして保存する必要があります。

2. デバイス・ビュー: 各デバイスに関連付けられたコンポーネント・インスタンスの数を含んだデバイスのリストが表示されます。インスタンス数のリンクをクリックすると、デバイスに割り当てられたコンポーネントを確認できます。

3. カスタム・コンポーネント: ユーザー定義のコンポーネントがリストされます。事前定義済コンポーネントのコピーにより作成されたコンポーネントも、カスタム・コンポーネントとしてここに表示されます。

注意: 管理デバイスには、カスタム・コンポーネントのみを割り当てることができます。

「コンポーネント」画面は、主要な構成にアクセスできる集中エントリ・ポイントです。「コンポーネント」画面では、次の操作を実行できます。

• 事前定義済コンポーネントを表示するには、ビュー・メニューの「事前定義済コンポーネント」を選択します。

• カスタム・コンポーネントを表示するには、ビュー・メニューの「カスタム・コンポーネント」を選択します。

• 「デバイス・ビュー」では、デバイスに割当て済のすべてのコンポーネントを表示できます。

• 事前定義済コンポーネントのコピーを作成するには、「事前定義済コンポーネント」ビューでコンポーネント名のリンクをクリックし、そのコンポーネントをカスタム・コンポーネントとして保存します。その後、現在の環境に固有の要件を反映するようにコンポーネントをカスタマイズできます。

• 既存のコンポーネントの情報を編集するには、「コンポーネント名」列のリンクをクリックして「コンポーネントの追加または更新」画面を表示します。

• カスタム・コンポーネントを追加するには、「カスタム・コンポーネントの追加」ボタンをクリックして「コンポーネントの追加または更新」画面を表示します。

• コンポーネントの一部として監視するデータのタイプを識別するルール・セットを定義できます。「ルール・セット」列のカウント・リンクをクリックし、「コンポーネント・ルール・セットの追加または更新」画面にアクセスします。

• コンポーネント・インスタンスを作成または変更するには、コンポーネントを1つ以上の特定のデバイスに割り当てます。「インスタンス」列のカウント・リンクをクリックし、「コンポーネント・インスタンス」画面にアクセスします。

• 監査アクションを定義または変更して、コンポーネントに関連するイベントの発生時に実行するアクションを関連付けることができます。「監査アクション」列のカウント・リンクをクリックし、この画面にアクセスします。

• コンポーネントにコントロールを割り当てることができます。コントロールは、製品のコンプライアンス・ポリシー領域に含まれます。

コンポーネントの追加または更新

「コンポーネントの追加または更新」画面は、テンプレートを追加または編集する場合に表示されます。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント: カスタム・コンポーネントの追加」の順に移動します。

1. 次の情報を入力します。

   • コンポーネント・タイプ: コンポーネントのタイプ。（新規カスタム・コンポーネント専用です。）現在構成済のすべてのコンポーネント・タイプから選択します。アプリケーション・タイプは、コンポーネントをリストした「コンポーネント」画面のアプリケーション・タイプの追加リンクを通じて作成できます。

   • コンポーネントOS: アプリケーションが実行されているプラットフォーム。（新規カスタム・テンプレート専用です。）ルールはコンポーネントの作成時に選択したOSに依存するため、コンポーネントの作成後にOSを変更することはできません。

   • 名前: コンポーネントを説明する一意の名前。

   • バージョン: コンポーネントのバージョン。

   • 説明: コンポーネントの機能に関するオプションの簡単な説明。

2. 事前定義済コンポーネントを変更して新規名で保存する場合、「別名保存」をクリックします。または、新規コンポーネントを作成するか、既存のカスタム・コンポーネントを変更する場合、「保存」をクリックします。「別名保存」機能を使用して、別のカスタム・コンポーネントに既存のカスタム・コンポーネントをコピーすることもできます。

コンポーネントのインポート

完全新規のコンポーネントを作成するかわりに、別のサーバーで使用されているコンポーネントをインポートできます。たとえば、開発環境でコンポーネントを作成およびテストしてから、そのコンポーネントを「コンポーネント」画面の「エクスポート」ボタンを使用してエクスポートします。次に、本番環境で「コンポーネント」画面の「インポート」ボタンをクリックして、そのコンポーネントをインポートできます。コンポーネント名の前にあるチェック・ボックスを選択して「選択項目のエクスポート」ボタンをクリックすると、サーバーで構成されている任意のコンポーネントをエクスポートできます。すべてのコンポーネントをエクスポートするか、この方法を使用して、選択したコンポーネントをエクスポートできます。

コンポーネントをインポートするには、次の手順を実行します。

1. 「コンポーネント」画面で、「インポート」ボタンをクリックします。インポートするファイルを選択するよう求めるポップアップ・ダイアログ・ボックスが表示されます。

2. コンポーネントXMLが保存されている場所を検索して特定し、「送信」をクリックします。

3. ファイルがインポートするのに適したコンポーネントであるかどうかを尋ねるダイアログ・ボックスが表示されます。「インポートの継続」をクリックしてコンポーネントのインポートを完了します。

カスタム・コンポーネント・タイプの作成

「コンポーネント」で使用するために、「コンポーネント・タイプ」画面を通じてカスタム・コンポーネント・タイプを作成できます。カスタム・コンポーネント・タイプを作成することで、組織では、組織で使用している分類に従って環境内で使用する各コンポーネントを論理的にグループ化できます。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」→「コンポーネント・タイプの追加」リンクの順に移動します。

「コンポーネント・タイプ」画面には、現在構成されているすべてのカスタム・コンポーネント・タイプが表示されます。また、この画面には、説明、作成日時、および各カスタム・タイプを現在使用しているコンポーネントの数も含まれます。

表5-2 「コンポーネント・タイプ」画面のタスク

タスク	操作
「コンポーネント」画面のフィルタされたバージョンを表示する（コンポーネント・タイプに現在関連付けられているコンポーネントのみを表示する）。	「コンポーネントの数」カウント・リンクをクリック。
構成済のコンポーネント・タイプを変更する。	「コンポーネント・タイプ」の「名前」リンクをクリック。
新規コンポーネント・タイプを追加する。	「コンポーネント・タイプの追加」ボタンをクリックして新規タイプ名を指定し、説明を入力。

終了したら、「保存」をクリックします。これで、カスタム・コンポーネントをフィルタまたは作成する際に、コンポーネント・タイプを選択できるようになります。

作成したカスタム・コンポーネント・タイプは削除できますが、そのコンポーネント・タイプを使用するコンポーネントが存在する間は削除できません。コンポーネント・タイプを削除するには、先に既存のコンポーネントを編集して、それらを異なるコンポーネント・タイプに割り当てておく必要があります。また、製品に付属する「デフォルト」コンポーネント・タイプは削除できません。削除できないコンポーネント・タイプに関しては、削除オプションが無効になります。

手順2: コンポーネント・ルールの定義

コンポーネントを作成したら、監視するルール・セットを選択してルールを定義する必要があります。各コンポーネントには、ビジネス・アプリケーションを構成するコンポーネントに関連付けられたルール・セット（プロセス、ファイル、ユーザーおよび内部オブジェクト）に関する一連のルールがあります。コンポーネント・ルール・セットごとに最大50のルール・パターンを包含または除外できます。ルール・セットごとのルールの数を増やすには、コンポーネントをより小さいコンポーネントに分割します。コンポーネントが大きすぎると、イベントのレポートが意味を持たなくなります。

監視ルールは、「コンポーネント」画面で追加します。この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

コンポーネントに関して、次の操作を実行できます。

• 「ルール・セット」列のリンクを選択し、ルール・セットを指定して各セットのルールを構成します。

• 「インスタンス」列のリンクを選択し、コンポーネントをデバイスに割り当ててアクティブなコンポーネント・インスタンスを作成します。

• 「監査アクション」リンクを選択し、コンポーネントに関連付けられたイベントが発生したときに実行するアクション（通知やSNMPトラップの送信など）を構成および有効化します。

ルール・セットの各タイプの詳細は、後続の項を参照してください。

監視の一般的なガイドライン: ルール・セット

次の各見出しは、様々なルール・セットを示しています。

• ファイル: 通常、組織では、不要なデータを収集することを避けるため、アプリケーションの日常的な動作で変更されるファイルやディレクトリ（トランザクション・ログなど）は監視しません。コンプライアンス目的で、アプリケーションの動作を定義する構成ファイルや表など、アプリケーションの機能またはパフォーマンスに重大な影響を与えるファイルのみを監視します。ファイル・ルール・セットの監視を通じて、ファイルの変更をリアルタイムで監視し、変更を行ったユーザーとイベントの他の属性を取得できます。また、権限の変更も監視されます。

• プロセス: Configuration Change Consoleエージェントは、監視対象プロセスが起動および停止した時期に関する情報を収集します。コンプライアンス・コントロール・ポイントを表すプロセスを選択します。または、その状態の変化（プロセスの起動または停止）が環境内で例外的なアクティビティを表すプロセスを選択します。たとえば、Financeアプリケーションに必要とされるメイン・プロセスが停止した場合、それは確認する必要のあるイベントです。

• ユーザー: Configuration Change Consoleエージェントは、OSユーザーがマシンに対してログオンおよびログオフした時期に関する情報を収集します。これは、ローカルの標準システムによるログオンと、TelnetやFTPアクセスなどの外部ログオンの両方を対象に行われます。この種のコンプライアンスでは、監視対象のアプリケーションにのみ関連しているユーザーまたは接続方法（あるいはその両方）を選択して、そのアプリケーションのユーザー・セッションの記録（開始と停止）を取得する必要があります。

• 包含/除外ルール: 最初に監視対象を指定しなければ、何も監視されません。*を使用してすべてを監視に含めることから開始し、次に監視しない要素を除外できます。または、より選択的な包含ルールを作成することもできます。

  最も限定的な包含/除外ルールは、常により一般的な包含/除外ルールに優先します。

  同じオブジェクトまたは特定の同じパターンに対して矛盾する2つのルールを定義した場合、包含ルールが優先され、その状態でデータが収集されます。

  包含/除外ルールを作成する場合、次の監視ルールが適用されます。

  • ワイルドカード（*）を含まないパターンは、同じエンティティ・タイプに対してワイルドカードを含むパターンより限定的です。たとえば、/program/files/a.txtは/program/files/a.*より限定的です。

  • 文字列の長さが長いパターンは、同じタイプの短いパターンより限定的です。たとえば、/program/files/userは/program/filesより限定的です。

  • データベース監視のパターン・タイプは、次のようなオブジェクト・タイプの階層に準拠します。

    • 表、ビュー、プロシージャ

    • 列、制約、索引

    • 属性

  • 「イベント」および「リソース」パターン・タイプは、パターンの長さが同じ場合、「両方」パターン・タイプより限定的です。

詳細は、付録C「コンポーネント内部ルール・セット機能の詳細」を参照してください。

コンポーネント・ルール・セットの選択

コンポーネント・ルールを構成する最初の手順では、コンポーネントで監視するデータのタイプを指定します。たとえば、あるアプリケーション・コンポーネントではファイルに対する変更を監視し、別のコンポーネントではプロセスの起動と停止に加え、データベース内で発生した変更を監視できます。

コンポーネントに個々のルール・セットを追加するには、次の手順を実行します。

1. 「コンポーネント・ルール・セットの追加または更新」画面のドロップダウン・メニューから「ルール・セット」を選択します。「コンポーネントの追加または更新」を参照してください。

2. ルール・セットの見出しにある「ルールの編集」リンクをクリックして、監視ルールをルール・セットに追加します。Configuration Change Consoleサーバーを1つ以上のLDAPまたはActive Directoryサーバーと統合している場合、この画面で手動入力するかわりに、LDAPユーザーまたはグループに基づいてユーザーの包含/除外ルールを指定できます。ルールにグループが含まれており、LDAPまたはActive Directoryサーバーでそのグループが変更された場合、その変更は自動的にコンポーネントに反映され、エージェントはその監視要件を変更するよう指示されます。

3. コンポーネント内部ルール・セットを監視します。

一部のルール・セットは、特定のタイプの監視に関連しています。これは、「Active Directory(スナップショット)」のように、ルール・セット名に続くカッコ内に示されます。これらのモジュールでは、通常、監視を実行する前に追加の構成が必要です。このようなルール・セットを追加すると、ルール・セット・ヘッダーに追加の「構成」リンクが表示されます。

コンポーネントに追加できるルール・セットには、2つの種類があります。外部ルール・セットは、アプリケーション外部のオブジェクトや、OSレベルのオブジェクト（ファイル、プロセス、OSユーザーなど）を処理するためのルール・セットです。内部ルール・セットは、アプリケーション内部のオブジェクト（データベースの表やActive Directoryサーバーのオブジェクトなど）を監視するためのルール・セットです。

1つのコンポーネントに追加できる内部ルール・セットは、1つのみです。これにより、コンポーネントの管理と確認が容易になります。コンポーネントを詳細にしすぎると、イベントをコンプライアンス・フレームワークに戻して適用することが難しくなります。

使用可能な内部ルール・セットのクラスは、次のとおりです。

• スナップショット: データベースとMicrosoft Active Directoryで使用します。このルール・セットでは、スナップショットとインベントリという2つの監視機能が提供されます。スナップショット機能では、選択したアプリケーションまたはデータベース・コンテンツのイメージが一定の間隔で格納されます。新規スナップショットが取得されるたびに、前に格納されたスナップショットと比較されます。2つのイメージの間に差異が検出されると、変更イベントが生成されます。スナップショット・ルール・セットは、アプリケーションまたはデータベースに関連するデータの更新、追加または削除を追跡するための軽量監視メカニズムです。ただし、スナップショット・ルール・セットで検出されるのは差異のみであり、変更イベントを起動したアイテムや、関連するユーザーは正確にはわかりません。「データベース・インベントリ」画面を使用すると、前のスナップショット以降にスナップショットで変更が取得された時期を確認し、2つのスナップショットの差分を比較して特定の変更を識別できます。

  同様に、スナップショットのSQLインベントリ機能では、ユーザー定義のSQL問合せを監視対象データベースに対して一定の間隔で実行し、個々の結果を格納して後で「視覚化の変更」および「データベース・インベントリ」画面を通じて確認できます。このルール・セットでは、検出された変更イベントに関連するユーザーの情報はレポートされません。

• SQL監査: サポート対象のデータベースで使用します。SQL監査ルール・セットでは、監視対象データベースの組込みの監査機能により生成された監査証跡をレポートします。SQL監査とSQLトレースの違いは、監査モジュールがオブジェクト・タイプ（表、ビュー、プロセスなど）、オブジェクト名（sales、employee）および操作（SELECT、CREATE、INSERT）におけるイベントをレポートするのに対し、SQLトレースは単にSQL文をレポートするところにあります。

• SQLトレース: サポート対象のデータベースで使用します。SQLトレース・ルール・セットでは、通常、監視対象データベースの組込みの監査機能を使用して、データベースのユーザーにより実行されたすべてのSQL文を記録します。このルール・セットを構成するには、特定のユーザーのアクティビティ（データベースと通信するアプリケーションのアクティビティ）を取得するコンポーネントか、またはデータベース内の重要なデータの変更に使用されるSQL文のセグメントを検索して取得するコンポーネント（あるいはその両方のコンポーネント）を使用します。このルール・セットにより、特定の変更イベントの原因となった問合せまたは文、その実行時間、および関連するユーザーを管理者が正確に追跡するのに使用できる詳細なフォレンジック・データ証跡が生成されます。ただし、収集されるデータの範囲が広いことと、状況によってはデータベースの内部監査機能を使用する必要があることから、このルール・セットの使用時にはデータベース・パフォーマンスが低下する可能性があります。

• トレース: Active DirectoryとWindowsレジストリで使用します。トレース・ルール・セットでは、オペレーティング・システム固有のメカニズムを使用して、関連するアプリケーションの内部イベントを監査します。たとえば、「Windowsレジストリ(トレース)」ルール・セットを使用すると、特定のアプリケーションに関連する指定されたレジストリ・キーおよび値に対するすべての変更をレポートできます。

コンポーネント・ルール・セットの追加

「コンポーネント・ルール・セットの追加または更新」画面を使用してモジュールを追加できます。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント: ルール・セット」カウント・リンクの順に移動します。

各コンポーネントに関して、次の操作を実行できます。

• 「追加」ドロップダウン・メニューからルール・セットを選択します。「実行」をクリックしてコンポーネントにルール・セットを追加します。

  1. ファイル・イベント

  2. プロセス・イベント

  3. ユーザー・イベント

  4. Active Directory(スナップショット)

  5. Active Directory(トレース)

  6. Oracle 8i(スナップショット)

  7. Oracle 8i/9i/10g(SQLトレース)

  8. Oracle 9i/10g(スナップショット)

  9. SQL Server(スナップショット)

  10. SQL Server 2000(SQL監査)

  11. SQL Server 2000(SQLトレース)

  12. Windowsレジストリ(トレース)

  最初の3つの項目は、外部ルール・セットであり、オペレーティング・システム・レベル（監視される別のシステムの外部）に存在します。残りのルール・セットは、内部ルール・セットであり、他のシステムを内部監視するために存在します。

• 選択したルール・セットに追加の設定が必要とされる場合、ルール・セット・ヘッダーに「構成」リンクが表示されます。「構成」リンクをクリックすると、ルール・セットの「内部構成の更新」画面に移動します。サポートされるルール・セットの接続パラメータの詳細は、付録C「コンポーネント内部ルール・セット機能の詳細」を参照してください。

• 「ルールの編集」リンクをクリックして、アプリケーション・コンポーネントの監視ルールを指定します。コンポーネント・タイプに応じた適切な画面に移動します。個々のルール・セットのルール画面については、次の項で説明します。

特定のコンポーネントに対してすべてのルール・セットを構成したら、「完了」をクリックしてコンポーネント・リスト画面に戻ります。

ファイルの監視

特定のファイルまたはディレクトリを監視するようにコンポーネントを構成します。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

ファイルを監視するには、次の手順を実行します。

1. 「コンポーネント」画面で、コンポーネントの「ルール・セット」カウント・リンクをクリックして「コンポーネント・ルール・セットの追加または更新」画面を表示します。

2. 「追加」ドロップダウン・リストから「ファイル・イベント」を選択し、「実行」をクリックします。

3. ファイル・イベント・ルール・セットの「ルールの編集」リンクをクリックします。

注意: 「コンポーネント・ファイルの追加または更新」画面でルール・パターンを入力するために表示されるフィールドは、最初は1つのみです。別のルールを追加するには、「インスタンスの追加」リンクをクリックします。

監視ポリシー用のファイルを構成する場合、ユーザー指定のベース・パスを基準とする相対パスを設定するか（同じベース・パスを何度も使用する場合、入力を省略できます）、絶対パスを指定します。相対パスを使用すると、1つのコンポーネントを複数のデバイスに割り当てる場合に、デバイスごとに異なるコンポーネントを割り当てることなく、デバイスで使用されている実際のディレクトリ・パスと関連するように相対パスに追加（または相対パスを変更）できます。

監視対象ファイルが変更されたときにConfiguration Change Consoleでアーカイブするには、ファイルの「アーカイブ」ボックスを選択します。たとえば、重要なデータベース構成ファイルをアーカイブできます。検出されたファイル変更により問題が発生した場合、以前のバージョンの構成ファイルをリストアできます。コンソールを使用して2つのバージョンのファイルを比較し、変更された部分を正確に確認することもできます。「エージェントの更新」を使用してエージェントに新規構成を送信する場合、エージェントでは、変更が発生する前にファイルの初期アーカイブ・コピーを取得し、変更が発生するたびに別のコピーを保存します。

Configuration Change Consoleでは、デフォルトで、デバイスごとに最大5つのバージョンのファイルを格納できます。この数を変更するには、「管理」→「サーバー構成」→「アーカイブ・ファイル構成」の順に移動します。

アーカイブするディレクトリは指定できません。エージェントでユーザー指定のパターンを持つ特定のファイルを検出できない場合、アーカイブ・アクションは単純に無視されます。

アーカイブ機能では、エージェントが格納されているディレクトリのディスク領域を消費するため、この機能は慎重に使用してください。

次の情報を入力します。

• 相対パス: 相対パスとして指定するパスで、所定のデフォルト・パスを使用するかどうかを選択します。デフォルト・パスは、このフォームの下のフィールドに入力します。

• 包含/除外: 適切なラジオ・ボタンを選択して、ファイルを監視するか、ファイルを監視対象から除外します。

• ファイル: ファイル名を入力します。最後のスラッシュに続く任意の場所で単一のワイルドカード（*）がサポートされます。ワイルドカード・サポートの詳細は、付録C「コンポーネント内部ルール・セット機能の詳細」を参照してください。

• 有効ファイル/ディレクトリ・パス: このフィールドは、システムにより自動的に生成され、相対パスを含む完全なディレクトリ・パスを表示するのに使用されます（「デフォルト・パス」フィールドでパスが指定されている場合）。

• 説明: オプションで、ルールの目的に関する簡単な説明を入力します。

• アーカイブ: オプションで、変更が発生したときに監視対象ファイルの異なるバージョンを格納するよう選択します。最新の5つのバージョンのファイルが、ファイルを監視するエージェントがインストールされているコンピュータ上に格納されます。アーカイブ・ファイルは、「アーカイブ・ファイル」画面で確認し、ファイル差分メソッドを使用して比較できます。管理画面で、格納するファイルのアーカイブ・コピーの数を変更できます。

• デフォルト・パス: いずれかのルールで「相対パス」ボックスを選択した場合、デフォルトの絶対パスを入力します。コンポーネントのインスタンスを作成する場合、インスタンス・レベルでこのデフォルト・パスを変更できます。

• ユーザー・フィルタ: 同じコンポーネントで構成されたユーザー・ルールにより、検出された変更をすべてフィルタする場合、このボックスを選択します。たとえば、管理者ユーザーのみを対象に指定したファイル・ルールでファイル変更を取得する場合、管理者ユーザーを含むルールを使用してコンポーネントにOSユーザー・ルール・セットを追加します。OSユーザー・ルール・セット画面には、ユーザー・ルールを使用して他のイベント・タイプをフィルタするよう指定するオプションがあります。「ファイル・ルール・セット」画面でこのユーザー・フィルタ・チェック・ボックスも選択し、フィルタ作業を完了します。管理者ユーザーに関連するファイル変更イベントのみが取得されます。

「保存」をクリックして変更を保存するか、「取消」をクリックして変更せずに画面を閉じます。

プロセスの監視

コンポーネントにとって重要なプロセスが、コンポーネントの一部として監視されるように構成します。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

プロセスを監視するには、次の手順を実行します。

1. 「コンポーネント」画面で、コンポーネントの「ルール・セット」カウント・リンクをクリックして「コンポーネント・ルール・セットの追加または更新」画面を表示します。

2. 「追加」ドロップダウン・リストから「プロセス・イベント」を選択し、「実行」をクリックします。

3. プロセス・イベント・ルール・セットの「ルールの編集」リンクをクリックします。

注意: 「コンポーネント・プロセスの追加または更新」画面でプロセス・パターンを入力するために表示されるフィールドは、最初は1つのみです。別のルールを追加するには、「インスタンスの追加」リンクをクリックします。

次の情報を入力します。

• 包含/除外: 適切なラジオ・ボタンを選択して、プロセスを監視するか、プロセスを監視対象から除外します。ルールを作成する場合、*を使用してすべてのプロセスを監視対象に含め、そこから特定のプロセスを除外することも、*を使用してすべてのプロセスを除外し、その後に特定のプロセスを含めることもできます。

• パターン: このルールを適用するプロセスの名前。

• パターン・タイプ: イベント（起動と停止）、または指定したプロセスに関連するリソース（CPU）使用率の情報（あるいはその両方）を収集するかどうかを選択します。プロセスのリソース使用率を収集する場合、エージェント・スケジュール・テンプレートがパフォーマンス・データを含むように構成されていることも確認する必要があります。デフォルトでは、デフォルト・スケジュール・グループにより変更イベント・データのみが監視されます。詳細は、エージェント・スケジュール・グループおよびエージェント・スケジュール・テンプレートに関する項を参照してください。

• 説明: オプションで、プロセスの目的に関する簡単な説明を入力します。

• ユーザー・フィルタ: 同じコンポーネントで構成されたユーザー・ルールにより、検出された変更をすべてフィルタする場合、このボックスを選択します。たとえば、管理者ユーザーのみを対象に指定したプロセス・ルールでプロセス変更（起動と停止）を取得する場合、管理者ユーザーを含むルールを使用してコンポーネントにOSユーザー・ルール・セットを追加します。OSユーザー・ルール・セット画面には、ユーザー・ルールを使用して他のイベント・タイプをフィルタするよう指定するオプションがあります。「プロセス・ルール・セット」画面でこのユーザー・フィルタ・チェック・ボックスも選択し、フィルタ作業を完了します。管理者ユーザーに関連するプロセス変更イベントのみが取得されます。

「保存」をクリックして変更を保存するか、「取消」をクリックして変更せずに画面を閉じます。

オペレーティング・システム・ユーザーの監視

特定のオペレーティング・システム・ユーザーのログインまたはログアウト・イベントを監視するようにコンポーネントを構成します。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

ユーザーを監視するには、次の手順を実行します。

1. 「コンポーネント」画面で、コンポーネントの「ルール・セット」カウント・リンクをクリックして「コンポーネント・ルール・セットの追加または更新」画面を表示します。

2. 「追加」ドロップダウン・リストから「OSユーザー・イベント」を選択し、「実行」をクリックします。

3. OSユーザー・イベント・ルール・セットの「ルールの編集」リンクをクリックします。

注意: 「コンポーネントOSユーザーの追加または更新」画面でユーザー・パターンを入力するために表示されるフィールドは、最初は1つのみです。別のルールを追加するには、「インスタンスの追加」リンクをクリックします。

次の情報を入力します。

• 包含/除外: 適切なラジオ・ボタンを選択して、ユーザーまたは接続タイプを監視するか、監視対象からそれらを除外します。ワイルドカードを使用してすべてのユーザーを含め、そこから特定のユーザーを除外することも、逆にすべてのユーザーを除外し、その後に特定のユーザーを含めることもできます。

• パターン: ユーザー名または接続方法（ftp、telnet、rdpなど）を入力します。このフィールドでは、単一のワイルドカード（*）がサポートされます。ワイルドカード・サポートの詳細は、付録C「コンポーネント内部ルール・セット機能の詳細」を参照してください。デフォルトでは、どのユーザーも監視に含まれないことに注意してください。

• パターン・タイプ: 「パターン」フィールドで指定した要素に適したタイプを選択します。使用可能なオプションには、「ユーザー」（ユーザー名）および「接続タイプ」（接続方法）があります。

• 説明: オプションで、ユーザーと、コンポーネントにとって重要な理由を記載した簡単な説明を入力します。

• ユーザー・フィルタ: このユーザー・リストを使用して、コンポーネントの他のルール・セットでイベントをフィルタする場合、このボックスを選択します。他のルール・セットでこのフィルタを使用する方法の詳細は、各ルール・セット・タイプに関する記述を参照してください。

「保存」をクリックして変更を保存するか、「取消」をクリックして変更せずに画面を閉じます。

Configuration Change Consoleサーバーを1つ以上のLDAPまたはActive Directoryサーバーと統合している場合、この画面で手動入力するかわりに、LDAPユーザーまたはグループに基づいてユーザーの包含/除外ルールを指定できます。ルールにグループが含まれており、LDAPまたはActive Directoryサーバーでそのグループが変更された場合、その変更は自動的にコンポーネントに反映され、エージェントはその監視要件を変更するよう指示されます。

コンポーネント内部ルール・セットの監視

内部ルール・セットは、監視対象のアプリケーションの内部機能を定義するコンポーネントに追加されるルール・セットです。内部ルール・セットの例として、データベース表の監視、Active Directoryオブジェクトの監視、Windowsレジストリの監視などがあげられます。

次のリストに、コンポーネントで使用できる内部ルール・セットの一部を示します。使用可能なコンポーネントは、定義するコンポーネントのリリースおよびOSバージョンに応じて異なります。

• Active Directory(スナップショット)

• Active Directory(トレース)

• Oracle 8i(スナップショット)

• Oracle 8i/9i/10g(SQLトレース)

• Oracle 9i/10g(スナップショット)

• SQL Server(スナップショット)

• SQL Server 2000(SQL監査)

• SQL Server 2000(SQLトレース)

• Windowsレジストリ(トレース)

各内部ルール・セットには、その監視を実行する1つ以上の方法（スナップショット、SQL監査、SQLトレース、トレース）があります。このドキュメントで前に説明したとおり、それぞれにメリットとデメリットがあります。

1つのコンポーネントは、3つの外部ルール・セット（ファイル、プロセスおよびOSユーザー）をすべて保持できますが、同時に保持できる内部ルール・セットは1つのみです。この主な理由は、製品のレポートおよび監査機能が有効となるようにコンポーネント定義を特定しておくことにあります。

コンポーネント・ルール・セットで内部監視をサポートする場合、「コンポーネント・ルール・セットの追加または更新」画面で適切なルール・セットの「構成」リンクを使用して、監視を有効化します。一部のルール・セットでは、監視対象のアプリケーションにアクセスするため、ログイン資格証明などの接続パラメータを指定する必要があります。これらのパラメータは、各アプリケーションに固有であり、監視を適切に有効化するよう構成する必要があります。たとえば、Oracleデータベースでは、特定のデータベース・ユーザー権限とログイン資格証明が必要です。

この画面を表示するには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

内部コンポーネント・ルール・セットを監視するには、次の手順を実行します。

1. 「コンポーネント」画面で、コンポーネントの「ルール・セット」カウント・リンクをクリックして「コンポーネント・ルール・セットの追加または更新」画面を表示します。

2. 「追加」ドロップダウン・リストから内部ルール・セットの1つを選択し、「実行」をクリックします。

3. 内部ルール・セットの「ルールの編集」リンクをクリックします。

   
   

   注意: 「コンポーネント・プロセスの追加または更新」画面でルール・パターンを入力するために表示されるフィールドは、最初は1つのみです。別のルールを追加するには、「インスタンスの追加」リンクをクリックします。

   
   

4. 「コンポーネント・ルール・セットの追加または更新」画面に戻り、コンポーネント・ルール・セット・ヘッダーの「構成」リンクをクリックします。コンポーネントの「内部構成の更新」画面に移動します。

   
   

   注意: 「構成」リンクが表示されるのは、内部監視機能をサポートするルール・セットのみです。

   
   

5. 有効チェック・ボックスを選択してルール・セットを有効化または無効化し、ルール・セットに必要な接続パラメータを入力します。

「内部構成の更新」画面の内容は、コンポーネントに対して選択したルール・セットと監視対象に応じて変化します。前述の画面内容は、1つの例にすぎません。各ルール・セットに必要なすべての接続パラメータ設定の完全なリストは、付録B「オペレーティング・システム・ルール・セット機能の詳細」を参照してください。

内部ルール・セットの構成

内部ルール・セットを構成するには、次の手順を実行します。

1. 「ポリシー」→「操作管理」→「コンポーネント」→「ルール・セット」カウント・リンク→「構成」リンクの順に移動して、「内部構成の更新」画面にアクセスします。

2. 選択したルール・セットの要件に応じて、次の情報を入力します。

   • 接続URL: （付録C「コンポーネント内部ルール・セット機能の詳細」を参照）

   • ユーザー名: エージェントが監視を実行するためにこのシステムに接続するのに必要なユーザー名。エージェントには、監視のための権限が必要です。たとえば、データベース・トレース・ルール・セットの場合、エージェントでデータベースの監査ログを読み取ることができる必要があります。

   • パスワード: このユーザーのパスワード。

   • ルール・セット固有の監視オプション: （付録C「コンポーネント内部ルール・セット機能の詳細」を参照）

3. 有効ボックスを選択してルール・セットを有効化します。

4. 「保存」をクリックして変更を保存するか、「変更を元に戻す」をクリックしてフィールドをリセットします。

注意: 有効化した構成は、「エージェントの更新」画面でエージェントを更新するまで反映されません。「エージェントの更新」画面にアクセスするには、ユーザー・インタフェースの右上隅にある「エージェントの更新」ボタンを使用します。

インスタンスのルールおよび構成の上書き

「コンポーネント・インスタンス」画面を通じてこの画面にアクセスした場合、どのフィールドも編集できません。「上書き」ボタンをクリックすると、特定のコンポーネント・インスタンスの情報のみを編集できます。このとき、他のインスタンスが使用しているベース・コンポーネントは変更されません。上書きする場合、ルールの他に、他の監視対象システムに接続するのに必要な構成を変更できます。

内部ルール・セット: データベース・スナップショット・タイプのルール・セット

この画面にアクセスするには、「ポリシー」→「操作管理」→「コンポーネント」の順に移動します。

「コンポーネント・ルール・セットの追加または更新」画面で、データベース（スナップショット）・タイプの監視に対応するルール・セットの「ルールの編集」リンクをクリックします。このリンクにより、「コンポーネント・ルール・セットの追加または更新」画面に移動します。エージェント・モジュールの選択に応じて、「SQL問合せ」画面または「内部監視」画面が個別に表示されるか、Oracleスナップショット・モジュールの場合のように、同じ画面に両方の機能を含んだ組合せ画面が表示されます。

ルール構成に関連するルール・セット固有の詳細は、付録B「オペレーティング・システム・ルール・セット機能の詳細」を参照してください。

SQL問合せのパラメータ

ルール画面の「SQL問合せ」セクションでは、スケジュールにあわせて実行される問合せを入力できます。この問合せの実行時に、その出力と前の実行の出力が比較されます。スナップショット間に変更がある場合、その変更は変更イベントとしてカウントされます。また、中間スナップショットを格納するだけでなく、定期的にベースラインを保存できるように、ベースライン問合せを記録するよう指定できます。「データベース・インベントリ」画面では、これらのベースライン（スナップショット）と、各スナップショット間の差異を確認できます。

• 名前: 問合せの名前。この名前は、問合せを識別するためにレポートで使用されます。

• SQL問合せ: データベースに対する完全修飾されたSQL問合せ。SQL問合せを指定する場合、完全なデータベース・オブジェクト名を含める必要があります。たとえば、HRデータベース・スキーマからすべての顧客データを選択する問合せを入力する場合、select * from HR.customerと入力します。入力する問合せの最後にセミコロンは付けないでください。

  
  

  注意: この画面では、問合せに入力したスキーマの妥当性はチェックされません。スキーマがデータベース構造内に存在しない場合、監視結果は不完全なものとなります。エージェントのログに、表または問合せを実行できなかったことを示すエラーが記録されます。

  
  

• レコード・ベースライン: サーバー側で定期的にベースラインを記録する場合、このボックスを選択します。ベースライン間隔は、デバイスのローカル・カレンダに基づきます。ベースライン間隔は、ルール・セットの「構成」リンクの下で設定します。

ベースラインの記録

ベースラインの記録により、スナップショットにサーバー側のベースライン・データの定期的な記録を含めることができます。ベースライン間隔は、監視デバイスのローカル時間に基づきます。

次のタイプの内部監視モジュール・ルールで、ベースラインの記録がサポートされます。

• Oracle 8i(スナップショット)

• Oracle 9i/10g(スナップショット)

• SQL Server(スナップショット)

ルール・セットの「構成」リンクで、上にリストされているルール・セットのオプションを使用して、ベースラインを選択できます。ベースラインのオプションは、次のとおりです。

表5-3 ベースライン・ルールのオプション

オプション	説明
なし	ルールで指定しても、ベースラインは記録されません。
時	毎正時にベースラインが記録されます。
日	毎日その日の午前0時にベースラインが記録されます。
週	毎週1日目の午前0時にベースラインが記録されます。
月	毎月1日目の午前0時にベースラインが記録されます。

包含/除外のパラメータ

このルール画面の「包含/除外」セクションでは、監視するスキーマ・オブジェクトを選択できます。これはスナップショット・タイプのルール・セットであるため、実行される監視ではスキーマの状態が記録され、それが次の実行結果と比較されて差異が変更イベントとして扱われます。

このタイプのルールに基づくスナップショット・モジュールは、スキーマ構造の変更のみを監視し、内容の変更は監視しません。

• 包含/除外: 適切なラジオ・ボタンを選択して、オブジェクトを監視するか、オブジェクトを監視対象から除外します。

• パターン: オブジェクト・パターンを入力します。エージェントは、包含/除外ポリシーで指定されたオブジェクトまたは属性の完全名を照合します。アスタリスクをワイルドカードとして使用し、同様の形式の文字列をオブジェクト名と照合することもできます。データベース・オブジェクトの完全修飾名は、監視を実行するには正確に一致している必要があるため、慎重に使用してください。

• パターン・タイプ: ドロップダウン・メニューから適切なパターン・タイプを選択します。使用可能なパターン・タイプは、監視するアプリケーションと使用するルール・セットに応じて変化します。モジュール固有のパターン・タイプの完全なリストは、次の項を参照してください。

• 説明: ポリシーの目的に関する簡単な説明を入力します。

サポート対象データベースでの完全修飾オブジェクト名の形式は、次のようになります。

• Oracle. <schema>.<tablespace-name>

• SQL Server. <database name>.<owner>.<tablespace-name>

前述したとおり、コンポーネントで特に構成していなければ、エージェントはデフォルトの5分間隔で構成済の問合せを実行します。監視タイプの選択に応じて、この問合せは、SQLトレースのようにデータベースから単にデータを収集するために使用されるか、スナップショット・モジュールのようにデータベースに格納されたデータに対する変更を監視するために使用されます。選択問合せによりデータが戻される場合、Configuration Change Consoleには、デフォルトで1000行の制限があることに注意してください。このため、関係のあるデータのみを戻すように問合せを限定する必要があります。

たとえば、過度に検索範囲の広い問合せをスナップショットベースのエージェント・モジュールで使用しており、戻される限度の1000番目の行を超える行で変更イベントが発生した場合、その変更は検出されず、レポート画面にも表示されません。このような問合せには例外条件を使用して、必要なデータのみが戻され、正確な変更検出ができるように調整する必要があります。1000行の制限は、コンポーネントの「ルール・セット」画面にあるルール・セットの「構成」リンクで構成できます。

内部ルール・セット: 特定のパターン・タイプ

「コンポーネント・ルール・セットの追加または更新」画面で使用可能なパターン・タイプは、操作しているルール・セットに応じて異なります。

詳細は、次を参照してください。

• 付録B「オペレーティング・システム・ルール・セット機能の詳細」

• 付録C「コンポーネント内部ルール・セット機能の詳細」

ルール・セットでサポートされるパターン・タイプは、次のとおりです。

• Active Directory(スナップショット): Active DirectoryまたはLDAPサーバーで構成されている個々のユーザー（ユーザー）、監視対象コンピュータ（コンピュータ）、ユーザー・グループまたはデバイス・グループ（グループ）、あるいはこれらすべて（すべて）に対する変更から選択します。

• Active Directory(トレース): Active Directory内で構成されているコンピュータ（コンピュータ）、グループ（グループ）およびユーザー（ユーザー）から選択します。

• Oracle 8i(スナップショット): 付録B「オペレーティング・システム・ルール・セット機能の詳細」を参照してください。

• Oracle 9i/10g(スナップショット): 付録B「オペレーティング・システム・ルール・セット機能の詳細」を参照してください。

• Oracle 8i/9i/10g(SQLトレース): ユーザー（ユーザー）、データベースへの接続に使用される特定のマシン（ホスト）、オペレーティング・システム・ユーザー（OSユーザー）、端末（ターミナル）、イベント（イベント）またはデータベース内のオブジェクト名（オブジェクト名）に対する変更から選択します。

• Windowsレジストリ(トレース): レジストリ・キー（キー）、レジストリ値（値）、またはレジストリ監視に含まれるすべてのレジストリ情報（すべて）から選択します。

• SQL Server(スナップショット): 付録B「オペレーティング・システム・ルール・セット機能の詳細」を参照してください。

• SQL Server 2000(SQL監査): ユーザー（ユーザー）、データベースへの接続に使用される特定のマシン（ホスト）、データベースに接続される特定のアプリケーション（アプリケーション名）、特定のデータベース（DB名）またはデータベース内のオブジェクト名（オブジェクト名）に対する変更から選択します。

• SQL Server 2000(SQLトレース): SQL問合せを実行する個々のユーザー（ユーザー）、データベースへの接続に使用される特定のマシン（ホスト）、データベースに接続される特定のアプリケーション（アプリケーション名）、または実行されるSQL問合せ内で検索される特定の文字列（SQL文）から選択します。「アプリケーション名」パターン・タイプは、大文字と小文字が区別されます。また、「SQL文」パターン・タイプでは、ワイルドカードはサポートされません。

トレースおよび監査ルール・セットのパターン・タイプ

次の表は、トレースおよび監査モジュールでサポートされるパターン・タイプのクイック・リファレンスです。

表5-4 トレースおよび監査ルール・セットのパターン・タイプ

トレース・モジュール	監査モジュール
SQL Server 2000 SQL文 ユーザー アプリケーション名 ホスト	SQL Server 2000 ユーザー ホスト アプリケーション名 オブジェクト名 DB名
Oracle8i/9i/10g ユーザー ホスト ターミナル OSユーザー オブジェクト名 イベント	N/A

Active Directoryの監視

Active Directoryルール・セットでは、ユーザーの追加、ユーザー権限の変更、アカウントの削除、およびデバイスとグループの変更を追跡してレポートします。Configuration Change Consoleエージェントは、変更を行ったユーザーを取得可能な監査レベルの監視のために、ドメイン・コントローラが稼働しているデバイスにインストールできます。または、Configuration Change Consoleエージェントでスナップショット・ルール・セットを使用して、ドメイン・コントローラをリモート監視できます。ただし、この場合、変更は検出できますが変更を行ったユーザーは検出できません。

Active Directoryの監視では、ユーザー、グループおよびコンピュータに関する次の変更イベントがレポートされます。

表5-5 ユーザー、グループおよびコンピュータの変更イベント

イベントID	イベントの説明	エンティティ・タイプ	エンティティ名	イベント・タイプ
624	ユーザー・アカウントの作成	user	entityname	追加
627	ユーザー・パスワードの変更	user attribute	entity.password	修正
628	ユーザー・パスワードの設定	user.attribute	entity.password	修正
630	ユーザー・アカウントの削除	user	entityname	削除
631	グローバル・グループの作成	group	entityname	追加
632	グローバル・グループへのメンバーの追加	group.member	entityname.member-name	追加
633	グローバル・グループからのメンバーの削除	group.member	entityname.member-name	削除
634	グローバル・グループの削除	group	entityname	削除
635	ローカル・グループの作成	group	entityname	追加
636	ローカル・グループへのメンバーの追加	group.member	entityname.member-name	追加
637	ローカル・グループからのメンバーの削除	group.member	entityname.member-name	削除
638	ローカル・グループの削除	group	entityname	削除
639	ローカル・グループ・アカウントの変更	group.attribute	entityname.-	修正
641	グローバル・グループ・アカウントの変更	group.attribute	entityname.-	修正
642	ユーザー・アカウントの変更	user.attribute	entityname.-	修正
645	コンピュータ・アカウントの作成	computer	entityname	追加
646	コンピュータ・アカウントの変更	computer	entityname	修正
647	コンピュータ・アカウントの削除	computer	entityname	削除
*エンティティ・タイプ = モジュール・ルール定義のパターン・タイプ *エンティティ名 = ドメイン名 + "\\" + アカウント名

Active Directoryの監視では、次の基本ガイドラインに従ってルールを包含または除外できます。

• ルールは、ユーザー、グループ、ログイン名およびデバイスに基づきます。

• すべてのパターンで大文字と小文字は区別されません。つまり、AbCはABCと一致します。

• 特定のエンティティを対象とするには、包含ルールと除外ルールを組み合せて使用します。

• include = *またはexclude = *を使用する場合以外は、同じパターンに包含ルールと除外ルールを適用しないでください。

特定のターゲットを除外する場合、include=*を使用してから特定の除外ルールを追加します。また、特定のターゲットのみを含める場合、明示的な除外パターンを含むいくつかのルールと組み合せてexclude=*ルールを使用します。

手順3: 管理デバイスへのコンポーネントのマッピング

アプリケーションのコンポーネントを構成したら、各コンポーネントが実行されるデバイスを指定する必要があります。単一のコンポーネントは、1つ以上のデバイスに割り当てることができます。

デバイスにコンポーネントをマップする前に、次の作業を行う必要があります。

• 監視するデバイスにConfiguration Change Consoleエージェントをインストールする必要があります。一部のデータベース・ルール・セットでは、リモート・データベース・アクセスが可能になるため、データベースのインストール先以外のデバイス上にインストールされたエージェントを使用できます。

• ルール・セットおよびルールを使用してコンポーネントを構成する必要があります。コンポーネントに監視ルールを定義していない場合、「ルール・セット」のカウント・リンクをクリックして「コンポーネント」画面で監視の詳細を構成または編集します。

「コンポーネント・インスタンス」画面には、コンポーネントが現在割り当てられているすべてのデバイスが表示されます。

この画面にアクセスするには、「ポリシー」→「操作管理」→「コンポーネント: インスタンス」カウント・リンクの順に移動します。

コンポーネント・インスタンスに割り当てられているデバイスの名前は、「デバイス名」列に表示されます。「上書き済」列には、関連するアプリケーション・インスタンスに対してグローバル・コンポーネント・ルール・セットのルールが変更されているかどうかが表示されます。上書きステータス・リンクをクリックすると、そのインスタンス専用のコンポーネント・ルール・セット画面に移動し、選択したインスタンスのみを対象にルールおよび接続設定を編集できます。ただし、一部のルール・セットでは、インスタンス・レベルの変更が許可されません。

コンポーネントのデバイス割当てを追加または更新するには、「デバイス割当ての変更」ボタンをクリックします。「新規デバイスの割当て」画面が表示されます。

「新規デバイスの割当て」画面には、現在構成されているすべてのデバイス・グループと、そのすべてのメンバー・デバイスが表示されます。デバイス・グループ名の横にあるボックスを選択してデバイス・グループ全体にコンポーネントを割り当てるか、デバイス・グループのツリーを開いて個々のデバイスを選択します。すべてのデバイスを選択したら、「保存」をクリックしてこの画面を閉じます。デバイス・グループの構造は、グループの選択時に維持されません。グループのデバイスを追加または削除しても、コンポーネント割当てには影響しません。

手順4: コンポーネントへのコントロールの割当て

製品のポリシー管理機能（次の章を参照）をすでに構成している場合、コンポーネントにポリシー・コントロールを割り当てることができます。

この画面にアクセスするには、「ポリシー」→操作管理コントロール→「コントロール」カウント・リンクの順に移動します。

この画面では、コンポーネントに割り当てられたコントロールを変更できます。コントロール割当ては、コントロール/ポリシー/フレームワーク・レポート構造を通じてコンポーネントの変更をレポートする方法です。たとえば、トップレベル・ダッシュボードで変更をレポートするには、コントロールにコンポーネントを割り当てると同時に、そのコントロールをポリシーに割り当てる必要があります。

画面のサブタイトルに、コンポーネントのコンテキストが表示されます。たとえば、次のようになります。

コンポーネント: Finance Application Server 1.0 WINNT

「+」をクリックすると、コントロール・フレームワークおよびポリシー階層を開いてコントロールのリストを表示できます。各ポリシー名に続く[ ]内に、選択済コントロールの数が示されます。

階層の最下位レベルのチェック・ボックスを選択すると、選択済コンポーネントに割り当てるコントロールを指定できます。

選択済コンポーネントに割り当てるコントロールを指定するには、次のいずれかの方法を使用します。

階層の最下位レベルにあるコントロールのチェック・ボックスを選択します。

ポリシー名（またはフレームワーク名）をクリックして、そのポリシー（またはコントロール）に含まれるすべてのコントロールをコンポーネントに割り当てます。

「選択ヘルパー」リンクをクリックして、パターン一致に基づいてテンプレートのグループを選択します。パターン一致では、大文字と小文字が区別されます。

新規割当てを作成するか、コントロールの割当てを解除すると、コンポーネントに割り当てられたコントロールの数が更新され、コンポーネント・リスト画面に表示されます。

手順5: アプリケーション

コンポーネント・インスタンスをアプリケーションにグループ化すると、現実のビジネス・アプリケーションをモデル化し、レポートを実際のビジネスと一致させることができます。ほとんどの大規模エンタープライズ・アプリケーションは、複数のサーバーに存在する複数のアプリケーション・コンポーネントの相互作用に依存しています。たとえば、Webベースの顧客サービス・アプリケーションには、通常、Webサーバー、アプリケーション・サーバーおよびデータベースが含まれており、これらはすべて異なるサーバー上で稼働しています。これらの各要素に対応するコンポーネントを作成し、アプリケーションが稼働するサーバーに基づいてインスタンスを定義します。次に、コンポーネントのみを監視対象とするのではなく、アプリケーション全体に影響を与える変更イベントを簡単に確認できるアプリケーションを作成します。

1つのコンポーネント・インスタンスは、複数のアプリケーションに含めることができます。これは、レポート目的や管理目的で役に立ちます。たとえば、ファイアウォール・コンポーネントを使用して、HRアプリケーション・サーバーを保護できますが、同時にFinanceアプリケーション・サーバーも保護できます。このファイアウォールの構成設定に対する変更は、同時に両方のアプリケーションに影響する可能性があります。

アプリケーションを使用するには、最初にコンポーネントを作成し、次にそれらを各デバイスに割り当ててコンポーネント・インスタンスを作成する必要があります。

アプリケーションの作成

「アプリケーション」画面には、既存のアプリケーションのリスト、各グループに関連付けられたコンポーネント・インスタンスの数、および各アプリケーションに現在構成されている監査アクションの数が表示されます。

注意: グループにコンポーネント・インスタンスが追加されるまで、「アプリケーション」画面の「コンポーネント・インスタンスの数」列のリンクには、0（ゼロ）が表示されます。

この画面にアクセスするには、「ポリシー」→「操作管理」→「アプリケーション」の順に移動します。

アプリケーションを追加するには、「アプリケーションの追加」ボタンをクリックします。既存のアプリケーション情報を変更するには、アプリケーション名のリンクをクリックします。どちらの操作を行っても、「アプリケーションの追加または更新」画面が表示されます。アプリケーションの名前とオプションの説明を入力します。「保存」をクリックして変更を保存します。グループが「アプリケーション」画面に表示されます。

アプリケーションへのコンポーネント・インスタンスの追加

アプリケーションを作成したら、そのアプリケーションに1つ以上のコンポーネント・インスタンスを追加できます。

この画面にアクセスするには、「ポリシー」→「操作管理」→「アプリケーション」の順に移動します。

適切なアプリケーションの「コンポーネント・インスタンスの数」列のリンクをクリックし、「新規コンポーネント・インスタンスの割当て」画面を表示します。使用可能なインスタンス・ツリーから1つ以上のコンポーネント・インスタンスを選択します。「保存」をクリックして変更を保存するか、「変更を元に戻す」をクリックしてフィールドをリセットします。

手順6: アプリケーション監査アクションの定義

監査アクションでは、イベントの発生時に実行するアクションを指定します。監査アクションに対して指定できるイベントのタイプは、ファイル、プロセス、OSユーザーおよびコンポーネント内部（データベース、レジストリ、Active Directoryなど）の変更です。これらのイベントで、電子メール通知、レポート生成、SNMPトラップおよび変更管理調整を起動できます。

SNMP通知を構成する方法の詳細は、第12章「サーバーおよびエージェントの管理」を参照してください。

変更管理の統合: 認可済イベントと未認可イベントの検出

Configuration Change Consoleは、変更管理サーバーとの統合により、認可済または未認可のイベントを監視および分類できます。監査アクションにより、変更イベントは変更管理サーバーのチケットおよび構成済CTIに対して比較されます。検出された変更が構成済CTIのオープン・チケットに一致する場合、その変更は認可済であると判断され、変更管理サーバーで、イベントの詳細によって対応するチケットが更新されます。検出された変更が構成済CTIのオープン・チケットに一致しない場合、その変更は未認可であると判断されます。変更が未認可であると判断されると、変更管理サーバーの構成に応じて次のいずれかの処理が行われます。

1. CT統合が有効化されていない場合、未認可の変更ごとに新規チケットが作成されます。

2. CT統合が有効化されている場合、既存の未認可チケットのCTIに一致するすべての未認可イベントは、その未認可チケットに追加されます。一致するCTIが見つからない場合、デフォルト・アウトバウンド・チケット情報を使用して新しい未認可チケットが作成されます。

監査アクションでは、変更管理アプリケーションとの最後の統合ポイントが提供されます。

統合が機能するためには、変更管理アプリケーションで使用する接続パラメータを指定し、デフォルト・アウトバウンド・チケット構成を選択して、ユーザー・インタフェースを通じて個々のコンポーネント・インスタンスにカテゴリを割り当てておく必要があります。この統合の構成方法の詳細は、第7章「変更管理サーバーとの統合」を参照してください。

監査ポリシーの定義

変更管理システムが統合された状態（変更管理の統合が変更管理の構成画面を通じて完全に構成された状態）でコンポーネントを作成すると、監査アクションが自動的に生成されます。自動生成されたアクションは、名前にAUTO ACTIONという文字列が追加されて「監査アクション」画面に表示されます。これらの監査アクションは、コンポーネント・インスタンスまたはアプリケーションが割り当てられるまで完全ではありません。

変更管理システムを統合していない場合、監査アクション・ポリシー画面に移動して手動で監査アクションを作成できます。

この画面にアクセスするには、「ポリシー」→「操作管理」→「監査アクション」の順に移動します。

新しい監査アクションを追加するには、「新規監査アクションの追加」ボタンをクリックします。既存のアクションを編集するには、「監査アクション」の名前のリンクをクリックします。どちらの場合も、「監査アクションの追加または変更」画面が表示されます。次の情報を入力します。

• 監査アクション名: 監査アクションに割り当てる一意の名前。アクション名には一貫したネーミング規則を定義すると便利です。

• 説明: アクションの機能に関するオプションの簡単な説明。

• コンポーネント・インスタンス/アプリケーション: 監査するコンポーネント・インスタンスまたはアプリケーションを指定する必要があります。定義した監査アクションは、選択したコンポーネントまたはアプリケーションに関連するイベントにのみ適用されます。使用可能なドロップダウン・オプションから、「コンポーネント・インスタンス」または「アプリケーション」を選択します。異なる要件に応じて、コンポーネント・インスタンスまたはアプリケーションごとに複数の監査アクションを指定できます。たとえば、同じコンポーネント・インスタンスに対して、ファイル変更には通知を、プロセス変更にはSNMPトラップをそれぞれ送信できます。

• 検出するイベント: ファイル、プロセス、OSユーザーまたはコンポーネント内部の変更イベントのいずれかを選択します。

• 通知: 発生するイベントごとに通知する個人を選択します。ここで指定する個人は、通知を受信するように構成された第1電子メール・アドレスを持っている必要があります。「なし」を選択した場合、通知は送信されません。

• 優先度: 通知エスカレーション用の優先度レベル。優先度レベルは、P1、P2、P3、P4またはP5です（P1の優先度が最高）。

• SNMPサーバー: SNMPサーバーを構成してConfiguration Change Consoleサーバーからトラップを受信している場合、通知を受信可能なSNMPサーバーを選択します。複数のSNMPサーバーを選択できます。

• レポート: レポートを生成し、電子メール通知の添付ファイルとして送信できます。

• チケット・アクション: 「承認済変更」オプションを選択した場合、認可済イベントが発生すると、変更管理サーバーはその認可済イベントの詳細で更新されます。「未承認変更」オプションを選択した場合、Configuration Change Consoleでは、エージェントにより検出されたすべての未認可イベントに対して、デフォルト・アウトバウンド・チケット構成を使用してチケットが作成されます。CT統合が有効化されている場合、未認可イベントは、最初に既存の未認可チケットのCTIと比較されます。一致するCTIが見つかった場合、そのチケットは変更イベント情報とともに追加されます。一致するCTIが見つからない場合、デフォルト・アウトバウンド・チケット構成を使用して新しい未認可チケットが作成されます。

• チケット・カテゴリ: 未認可の変更イベントに使用するデフォルト・アウトバウンド・チケット構成を指定します。

「保存」をクリックして変更を保存します。

「監査アクション」画面で、ポリシーにコンポーネント・インスタンスまたはアプリケーションを割り当て、適切なカウント・リンクをクリックし、表示されたインスタンスからいずれかを選択して監査アクションを完了します。監査アクションは、コンポーネント・インスタンスとアプリケーションの両方に同時に割り当てることはできません。