コンポーネント内部ルール・セット機能の詳細

Oracle 8i/9i/10g（監査）

この監視機能では、Oracle監査サブシステムを使用して変更の監査証跡を収集します。Configuration Change Consoleでは、監査ログをフィルタしたり、コンポーネントのルール・セットおよびルール構成を使用してConfiguration Change Consoleに重要なものを特定できます。

エージェントは、監査サブシステム設定を設定しません。これらの設定は、Oracleを監査モードで監視するように、エージェントのインストールの一環として手動で行う必要があります。監査監視用にOracleデータベースを設定する方法は、インストレーション・ドキュメントを参照してください。この章の残りの部分では、監視するデータベースがすでに監査用に構成されており、Configuration Change Console内から監視するエンティティを監査するように監査システムが設定されていることを前提としています。

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-1 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
接続URL	データベースへの接続URL。書式は次のとおりです。 jdbc:oracle:thin:@localhost:1521:oraclesid 通常の操作において、この書式で変更する部分は、ホスト名（localhostと表示）およびデータベースのSID（oraclesidと表示）のみです。
ユーザー名	Oracleデータベースの監査証跡データへの読取り権限を持つデータベース・ユーザー。このユーザーが本番データへの書込み権限を持たないようにします。
パスワード	監査読取り専用ユーザーのパスワード。
エージェント更新前にイベントを無視	コンポーネントが作成されたときにかぎりConfiguration Change Console監視を開始する場合に、このボックスを選択します。データベースの監査ログに古いレコードがある場合にこのチェック・ボックスを選択していないと、それらの古いイベントも監視対象となります。
ユーザー・ログイン・フィルタ	エージェントがルールに定義されたユーザーのログイン/ログアウト・イベントに加えて、他のタイプのイベントも取得するかどうかを選択します。
成功イベントのみレポート	成功したイベントのみを取得するか、失敗した試行（レコードを削除しようとして削除できなかった場合など）も取得するかどうかを選択します。

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-2 ルールのパターン・タイプ

パターン・タイプ	説明
ユーザー	変更を行ったデータベース・ユーザー名。パターン内のどこでも単一のワイルドカードを使用できます。たとえば、パターンA*を使用すると文字Aで始まるユーザーをすべて含めることができます。
ホスト	データベース接続の接続元となるホスト。特定のホストから別のホストに対するアクティビティを監視する場合に使用できます。パターン内のどこでも単一のワイルドカードを使用できます。
ターミナル	データベース接続の接続元となるホスト上のターミナル。ホスト上の特定のターミナルから別のターミナルに対するアクティビティを監視する場合に使用できます。パターン内のどこでも単一のワイルドカードを使用できます。
OSユーザー	データベースに接続しているオペレーティング・システム・ユーザー。データベースの変更はデータベース・ユーザーによって行われますが、SQL*Plusを使用した変更などでは、先に接続したオペレーティング・システム・ユーザーが存在します。パターン内のどこでも単一のワイルドカードを使用できます。
オブジェクト名	監視するオブジェクトの名前。オブジェクト名には、必要に応じてスキーマ所有者を含めても含めなくてもかまいません。所有者を含めない場合、変更があると、すべてのスキーマにおいて同一のオブジェクト名がイベントをトリガーします。パターンの（スキーマ所有者名ではなく）エンティティ名部分のどこでも単一のワイルドカードを使用できます。
イベント	取得するイベント・タイプ。次の例を示します。選択作成削除更新

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
「オブジェクト名」パターン・タイプには、ObjnameとSchema.Objnameの両方の書式がサポートされています。たとえば、fooを含めるというパターンを指定すると、すべてのスキーマでfooに関するすべてイベントが取得されます。system.foo*を含めると指定すると、systemスキーマでのみfooに関するイベントが取得されます。
Schema.Objnameパターンを使用する場合、スキーマ名ではワイルドカードがサポートされません。ワイルドカード（*）は、必要に応じてObjnameの中で1つのみ使用します。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Oracle 8i（スナップショット）とOracle 9i/10g（スナップショット）

この監視機能では、定期的に実行されるSQL問合せを使用して、毎回、変更を検索するために問合せの出力が比較されます。これらのスナップショット・ルール・セットと監査ルール・セットの違いは、イベントがリアルタイムで検出されないことと、変更を行ったユーザー、変更が発生した正確な時刻などの特定の情報が失われることです。しかし、監視対象のエンティティまたは問合せの前後の値を取得できるという利点が、これらのルール・セットにはあります。

包含/除外ルール（SQL問合せルールではなく）を使用してスキーマの監視を実行するように構成されるユーザーには、監視を実行するために次の表への読取り権限が必要です。

Oracle8i（スナップショット）の場合

sys.dba_tables
sys.dba_tab_columns
sys.dba_constraints
sys.dba_views
sys.dba_objects

Oracle9i/10g（スナップショット）の場合

sys.dba_tables
sys.dba_tab_columns
sys.dba_constraints
sys.dba_views
sys.dba_objects
sys.dba_procedures

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-3 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
接続URL	データベースへの接続URL。書式は次のとおりです。 jdbc:oracle:thin:@localhost:1521:oraclesid 通常の操作において、この書式で変更する部分は、ホスト名（localhostと表示）およびデータベースのSID（oraclesidと表示）のみです。
ユーザー名	スキーマ定義を格納するsys.*表の他、SQL問合せを使用して監視するすべての表への読取り権限を持つデータベース・ユーザー。スナップショット・ルール・セットの一部として作成したSQL問合せは、ここで定義されたユーザーによって実行可能である必要があります。このユーザーが重大なデータおよび本番データへの書込み権限を持たないようにします。
パスワード	監査読取り専用ユーザーのパスワード。
スキーマ/データベースを含む	この監視に含めるスキーマ。たとえば、SYSのみの場合は、ここにSYSと入力します。
返された最大行	定義したSQL問合せをこのルール・セットを使用して監視する場合に、ベースライン間隔を設定すると、この問合せの出力はサーバーに戻されて格納され、ユーザー・インタフェースで表示できるようになります。このオプションを入力すると、Configuration Change Consoleを圧迫しないように、各SQL問合せの実行で返される行数を制限できます。返される行を1000以下にすることをお薦めします。これを超える必要がある場合は、複数のSQL問合せを作成し、リクエストを分割して問合せを小さくすることを検討してください。
ベースライン間隔	エージェントが取得したSQL結果のコピーを格納する間隔。エージェントは、自動的に問合せを5分ごとに実行しますが、この間隔に基づいてのみ結果のコピーを保存します。オプションは次のとおりです。なし日: 1日に1回、午前0時時: 1時間に1回、毎正時月: 1か月に1回、1日目の午前0時週: 1週間に1回、1日目の午前0時

ルール

データベース・スナップショット・ルール・セットに追加できるルールには、次の2つのタイプがあります。

SQL問合せ: エージェントによって定期的に実行される非定型SQL問合せを定義できます。SQL問合せの出力に変更があると、Configuration Change Consoleエージェントによって1つのイベントがレポートされます。

1つのコンポーネントでは、このルール・セット用に実行するSQL文を最大50まで作成できます。SQL問合せを作成する際に、前述のルール・セット構成設定で構成されたユーザーが問合せを実行できるようにする必要があります。問合せの最後に、セミコロン（;）などの終端文字列を使用しないようにします。

ルール・セット構成画面で定義した「ベースライン間隔」に従ってSQL文からの出力のコピーを保存する場合は、「レコード・ベースライン」オプションを選択します。これらのベースラインは「データベース・インベントリ」画面で表示でき、比較も実行できます。

包含/除外: 選択したスキーマ/データベースのスキーマ（前述したようにルール・セット構成画面で定義）のみを監視します。変更について監視するスキーマ要素のパターンを包含/除外できます。

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-4 ルールのパターン・タイプ

パターン・タイプ	説明
テーブル	入力するパターンはテーブル名です。イベントは、表の追加、削除、変更など、表レベルでレポートされます（表の変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
table.attribute	入力するパターンはtable.attribute名です。イベントは、属性が変更されたときに属性レベルでレポートされます（属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
table.column	入力するパターンはtable.column名です。イベントは、列が追加、削除または変更されると、列レベルでレポートされます（列の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
table.column.attribute	入力するパターンはtable.column.attribute名です。イベントは、属性が変更されたときに属性レベルでレポートされます（列属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
table.constraint	入力するパターンはtable.constraint名です。イベントは、制約レベルでレポートされます（制約の変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
table.constraint.attribute	入力するパターンはtable.constraint.attribute名です。イベントは、属性レベルでレポートされます（制約属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
ビュー	入力するパターンはビュー名です。イベントは、ビューが追加、削除または変更されると、ビュー・レベルでレポートされます（ビューの変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
view.attribute	入力するパターンはview.attribute名です。イベントは、属性レベルでレポートされます（属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
view.column	入力するパターンはview.column名です。イベントは、列レベルでレポートされます（列の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
view.column.attribute	入力するパターンはview.column.attribute名です。イベントは、属性レベルでレポートされます（列属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
プロシージャ	入力するパターンはプロシージャ名です。イベントは、プロシージャ・レベルでレポートされます（プロシージャの変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
procedure.attribute	入力するパターンはprocedure.attribute名です。イベントは、属性レベルでレポートされます（属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
すべて	入力するパターンはすべてのパターン・タイプに当てはまります。イベントは、表レベルでレポートされます。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。スキーマ変更についてすべてのスキーマ・オブジェクトを監視するように、*のみのパターンを指定することもできます。

Oracle8iについては、現在のバージョンではパッケージおよびパッケージ内のオブジェクトは監視されません。Oracle9エージェント・モジュールについては、パッケージ内のプロシージャ・オブジェクトがprivateではなくpublicとして定義されていれば、それらの変更アクティビティを追跡できます。パッケージのプロシージャは、他のプロシージャと同じように監視されます。パッケージ自体と、その属性はいずれも監視されません。

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Microsoft SQL Server 2000（監査）

この監視機能では、SQL Serverトレース・サブシステムを使用して変更の監査証跡を収集します。このモジュールとトレース版との違いは、このモジュールでは実行されたSQL文ではなく、アクセスまたは変更されたオブジェクトを使用することです。Configuration Change Consoleでは、ログをフィルタしたり、コンポーネントのルール・セットおよびルール構成を使用してConfiguration Change Consoleに重要なものを特定できます。

エージェントは、トレース・サブシステム設定を構成しません。これらの設定は、エージェントのインストールの一環として手動で行う必要があります。監査モードでSQL Server 2000を監視するための前提条件の詳細は、インストレーション・ドキュメントを参照してください。この章の残りの部分では、監視するデータベースがすでに監査用に構成されており、Configuration Change Console内から監視するエンティティを監査するように監査システムが設定されていることを前提としています。

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-5 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
接続URL	データベースへの接続URL。書式は次のとおりです。 jdbc:sqlserver://localhost:1433;databaseName=<server-name> 通常の操作において、この書式で変更する部分は、ホスト名（localhostと表示）およびデータベースの名前（<server-name>と表示）のみです。
ユーザー名	データベースの監査証跡データへの読取り権限を持つデータベース・ユーザー。このユーザーが本番データへの書込み権限を持たないようにします。
パスワード	監査読取り専用ユーザーのパスワード。

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-6 ルールのパターン・タイプ

パターン・タイプ	説明
ユーザー	変更を行ったデータベース・ユーザー名。パターン内のどこでも単一のワイルドカードを使用できます。たとえば、パターンA*を使用すると文字Aで始まるユーザーをすべて含めることができます。
ホスト	データベース接続の接続元となるホスト。特定のホストから別のホストに対するアクティビティを監視する場合に使用できます。パターン内のどこでも単一のワイルドカードを使用できます。このパターン・タイプのパターンでは大文字と小文字は区別されません。
アプリケーション名	変更またはアクセスを行うためにデータベースへの接続に使用されるアプリケーション名。パターン内のどこでも単一のワイルドカードを使用できます。このパターン・タイプのパターンでは大文字と小文字が区別されます。
オブジェクト名	監視するオブジェクトの名前。オブジェクト名には、必要に応じてスキーマ所有者を含めても含めなくてもかまいません。所有者を含めない場合、変更があると、すべてのスキーマにおいて同一のオブジェクト名がイベントをトリガーします。パターンの（スキーマ所有者名ではなく）エンティティ名部分のどこでも単一のワイルドカードを使用できます。
DB名	SQL Serverインストールでの監視対象データベースの名前。

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Microsoft SQL Server 2000（SQLトレース）

この監視機能では、SQL Serverトレース・サブシステムを使用して変更の監査証跡を収集します。このモジュールと監査版との違いは、このモジュールでは変更またはアクセスが行われたオブジェクトによる監視ではなく、使用されたSQL文を使用することです。Configuration Change Consoleでは、ログをフィルタしたり、コンポーネントのルール・セットおよびルール構成を使用してConfiguration Change Consoleに重要なものを特定できます。

エージェントは、トレース・サブシステム設定を構成しません。これらの設定は、エージェントのインストールの一環として手動で行う必要があります。監査モードでSQL Server 2000を監視するための前提条件の詳細は、インストレーション・ドキュメントを参照してください。この章の残りの部分では、監視するデータベースがすでに監査用に構成されており、Configuration Change Console内から監視するエンティティを監査するように監査システムが設定されていることを前提としています。

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-7 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
接続URL	データベースへの接続URL。書式は次のとおりです。 jdbc:sqlserver://localhost:1433;databaseName=<server-name> 通常の操作において、この書式で変更する部分は、ホスト名（localhostと表示）およびサーバーの名前（<server-name>と表示）のみです。
ユーザー名	データベースの監査証跡データへの読取り権限を持つデータベース・ユーザー。このユーザーが本番データへの書込み権限を持たないようにします。
パスワード	監査読取り専用ユーザーのパスワード。

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-8 ルールのパターン・タイプ

パターン・タイプ	説明
ユーザー	変更を行ったデータベース・ユーザー名。パターン内のどこでも単一のワイルドカードを使用できます。たとえば、パターンA*を使用すると文字Aで始まるユーザーをすべて含めることができます。
ホスト	データベース接続の接続元となるホスト。特定のホストから別のホストに対するアクティビティを監視する場合に使用できます。パターン内のどこでも単一のワイルドカードを使用できます。
アプリケーション名	変更またはアクセスを行うためにデータベースへの接続に使用されるアプリケーション名。パターン内のどこでも単一のワイルドカードを使用できます。
SQL文	照合するSQLテキストのパターン。この入力ではワイルドカードはサポートされていませんが、テキストは自動的により長いSQL文の断片とみなされます。表名やwhere句など、文の任意の部分を検索できます。
DB名	SQL Serverインストールでの監視対象データベースの名前。

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Microsoft SQL Server（スナップショット）

この監視機能では、定期的に実行されるSQL問合せを使用して、毎回、変更を検索するために問合せの出力が比較されます。これらのスナップショット・ルール・セットと監査ルール・セットの違いは、イベントがリアルタイムで検出されないことと、変更を行ったユーザー、変更が発生した正確な時刻などの特定の情報が失われることです。しかし、監視対象のエンティティまたは問合せの前後の値を取得できるという利点が、これらのルール・セットにはあります。

包含/除外ルール（SQL問合せルールではなく）を使用してスキーマの監視を実行するように構成されるユーザーには、監視を実行するために次の表への読取り権限が必要です。

<database_name>.dbo.sysuserssystables
<database_name>.dbo.sysobjectssysprocedures
<database_name>.dbo.syscolumnssyscolumns
<database_name>.dbo.systypessysconstraints
<database_name>.dbo.sysconstraintssyschecks

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-9 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
接続URL	データベースへの接続URL。書式は次のとおりです。 jdbc:sqlserver://localhost:1433;databaseName=<server-name> 通常の操作において、この書式で変更する部分は、ホスト名（localhostと表示）およびサーバーの名前（<server-name>と表示）のみです。
ユーザー名	スキーマ定義を格納するdbo.*表の他、SQL問合せを使用して監視するすべての表への読取り権限を持つデータベース・ユーザー。スナップショット・ルール・セットの一部として作成したSQL問合せは、ここで定義されたユーザーによって実行可能である必要があります。このユーザーが重大なデータおよび本番データへの書込み権限を持たないようにします。
パスワード	監査読取り専用ユーザーのパスワード。
スキーマ/データベースを含む	この監視に含めるスキーマ。
返された最大行	定義したSQL問合せをこのルール・セットを使用して監視する場合に、ベースライン間隔を設定すると、この問合せの出力はサーバーに戻されて格納され、ユーザー・インタフェースで表示できるようになります。このオプションを入力すると、Configuration Change Consoleを圧迫しないように、各SQL問合せの実行で返される行数を制限できます。返される行を1000以下にすることをお薦めします。これを超える必要がある場合は、複数のSQL問合せを作成し、リクエストを分割して問合せを小さくすることを検討してください。
ベースライン間隔	エージェントが取得したSQL結果のコピーを格納する間隔。エージェントは、自動的に問合せを5分ごとに実行しますが、この間隔に基づいてのみ結果のコピーを保存します。オプションは次のとおりです。なし日: 1日に1回、午前0時時: 1時間に1回、毎正時月: 1か月に1回、1日目の午前0時週: 1週間に1回、1日目の午前0時

ルール

データベース・スナップショット・ルール・セットに追加できるルールには、次の2つのタイプがあります。

SQL問合せ: エージェントによって定期的に実行される非定型SQL問合せを定義できます。SQL問合せの出力に変更があると、Configuration Change Consoleエージェントによって1つのイベントがレポートされます。

1つのコンポーネントでは、このルール・セット用に実行するSQL文を最大50まで作成できます。SQL問合せを作成する際に、前述のルール・セット構成設定で構成されたユーザーが問合せを実行できるようにする必要があります。問合せの最後に、セミコロン（;）などの終端文字列を使用しないようにします。

ルール・セット構成画面で定義した「ベースライン間隔」に従ってSQL文からの出力のコピーを保存する場合は、「レコード・ベースライン」オプションを選択します。これらのベースラインは「データベース・インベントリ」画面で表示でき、比較も実行できます。

包含/除外: 選択したスキーマ/データベースのスキーマ（前述したようにルール・セット構成画面で定義）のみを監視します。変更について監視するスキーマ要素のパターンを包含/除外できます。

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-10 ルールのパターン・タイプ

パターン・タイプ	説明
テーブル	入力するパターンはテーブル名です。イベントは、表の追加、削除、変更など、表レベルでレポートされます（表の変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
table.column	入力するパターンはtable.column名です。イベントは、列が追加、削除または変更されると、列レベルでレポートされます（列の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
table.column.attribute	入力するパターンはtable.column.attribute名です。イベントは、属性が変更されたときに属性レベルでレポートされます（列属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
table.constraint	入力するパターンはtable.constraint名です。イベントは、制約レベルでレポートされます（制約の変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
table.constraint.attribute	入力するパターンはtable.constraint.attribute名です。イベントは、属性レベルでレポートされます（制約属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
ビュー	入力するパターンはビュー名です。イベントは、ビューが追加、削除または変更されると、ビュー・レベルでレポートされます（ビューの変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
view.attribute	入力するパターンはview.attribute名です。イベントは、属性レベルでレポートされます（属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
view.column	入力するパターンはview.column名です。イベントは、列レベルでレポートされます（列の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
view.column.attribute	入力するパターンはview.column.attribute名です。イベントは、属性レベルでレポートされます（列属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
プロシージャ	入力するパターンはプロシージャ名です。イベントは、プロシージャ・レベルでレポートされます（プロシージャの変更ごとに1つのイベント）。パターン内のどこでも単一のワイルドカードを使用できます。
procedure.attribute	入力するパターンはprocedure.attribute名です。イベントは、属性レベルでレポートされます（属性の変更ごとに1つのイベント）。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。
すべて	入力するパターンはすべてのパターン・タイプに当てはまります。イベントは、表レベルでレポートされます。パターンの各要素内のどこでも1つのワイルドカードを使用できます（各要素はピリオド（.）で区切られます）。スキーマ変更についてすべてのスキーマ・オブジェクトを監視するように、*のみのパターンを指定することもできます。

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Microsoft Active Directory（トレース）

この監視機能では、Active Directory監査APIを使用して変更の監査証跡を収集します。このモジュールとスナップショット版との違いは、このモジュールでは変更が発生した正確な時刻と変更を行ったユーザーを取得できることです。このルール・セットは、Microsoft Active Directoryがインストールされているデバイス上に実際に存在するエージェントに割り当てる必要があります。Configuration Change Consoleでは、ログをフィルタしたり、コンポーネントのルール・セットおよびルール構成を使用してConfiguration Change Consoleに重要なものを特定できます。

Active Directoryルール・セットでは、次のタイプのアクティビティを検出できます。

ユーザーの追加または削除
ユーザー・パスワードの変更
グループに対するユーザーの追加または削除
コンピュータを管理するためのユーザーの割当て
グループの追加または削除
ドメインを対象とするコンピュータの追加または削除
コンピュータ属性の変更

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-11 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。

このルール・セットに他の構成パラメータはありません。これは、このルール・セットの監視対象となるデバイスが、Active Directoryがインストールされているのと同じデバイスであると認識されるためです。必要なAPIはすべてエージェントでローカルに使用できます。

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-12 ルールのパターン・タイプ

パターン・タイプ	説明
ユーザー	Active Directoryに定義されたユーザーに対する変更を監視します。パターン内のどこでも単一のワイルドカードを使用できます。
コンピュータ	Active Directoryに定義されたコンピュータに対する変更を監視します。パターン内のどこでも単一のワイルドカードを使用できます。
グループ	Active Directoryに定義されたグループに対する変更を監視します。パターン内のどこでも単一のワイルドカードを使用できます。

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Active Directory/LDAP（スナップショット）

この監視機能では、LDAP APIを使用して、ユーザー、グループまたはコンピュータに対する変更についてActive Directoryまたは他の標準準拠のLDAPサーバーのいずれかを監視します。このモジュールとトレース版との違いは、このモジュールではポーリング/スナップショット方式を使用していることです。この方式では、内容が定期的にチェックされ、変更を特定するために比較されます。このルール・セットを使用すると、変更の正確な時刻や変更を行ったユーザーを検出できません。このルール・セットは、LDAPサーバーとは異なるデバイス上にあるエージェントに存在してもかまいません。

Active Directoryルール・セットでは、次のタイプのアクティビティを検出できます。

ユーザーの追加または削除
ユーザー・パスワードの変更
グループに対するユーザーの追加または削除
コンピュータを管理するためのユーザーの割当て
グループの追加または削除
ドメインを対象とするコンピュータの追加または削除
コンピュータ属性の変更

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-13 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
LDAP URL	LDAPサーバーへの接続URL。書式は次のとおりです。ホスト名（127.0.0.1）とポート（389）を置き換えます。 ldap://127.0.0.1:389
ユーザー名	エンティティを監視するためにLDAP内に接続するユーザー名。このユーザーには、監視するLDAPエンティティへの読取り専用アクセス権が必要です。
パスワード	監視ユーザーのパスワード。
テンプレート・ベース	監視を開始するLDAPテンプレート・ベース。template.base値は、次の書式で入力する必要があります。 DC=<node element> すべてのノード値に対してです。ノード名にピリオド（.）が含まれる場合、ピリオドに続く文字列ごとに、カンマ（,）で区切った別のDC=<node element>マーカーを追加する必要があります。ただし、ピリオド自体は含めません。たとえば、template.base値としてmydomain.comというドメイン/ベース・ノードを指定する場合、template.baseフィールドに次のように入力します。 DC=mydomain,DC=com

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-14 ルールのパターン・タイプ

パターン・タイプ	説明
ユーザー	Active Directoryに定義されたユーザーに対する変更を監視します。パターン内のどこでも単一のワイルドカードを使用できます。
コンピュータ	Active Directoryに定義されたコンピュータに対する変更を監視します。パターン内のどこでも単一のワイルドカードを使用できます。
グループ	単一のパターンを使用して、これらのいずれかに対する変更を監視します。パターン内のどこでも単一のワイルドカードを使用できます。LDAP内のすべてのオブジェクトを監視する場合は、すべてのパターン・タイプに対応する*を単一のルールに指定できます。

Configuration Change ConsoleサーバーをLDAPサーバーと統合している場合、グループおよびユーザーをパターンとして直接入力するかわりに、LDAPサーバーからインポートすることもできます。LDAPサーバーでグループ構造が変更されると、エージェントに対して自動的に更新され、監視のニーズが調整されます。LDAPユーザーおよびグループは、「ルール」画面の「LDAPユーザーおよびグループ」セクションのインスタンスの追加リンクをクリックすると追加できます。

パターン・タイプ「ユーザー」または「OSユーザー」のパターンを追加する際、Configuration Change Consoleエージェントにより一定期間にわたって検出されたユーザーを選択してこれらのパターンを移入することもできます。パターンを手入力するかわりにすでに検出されているユーザーを選択するには、「検出済ユーザーから選択」リンクをクリックします。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Microsoft Windowsレジストリ

この監視機能では、Microsoft Windowsレジストリ監査APIを使用して変更の監査証跡を収集します。このルール・セットは、監視するレジストリのデバイス上に実際に存在するエージェントに割り当てる必要があります。

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-15 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。

このルール・セットに他の構成パラメータはありません。これは、このルール・セットの監視対象となるデバイスが、監視しているのと同じデバイスであると認識されるためです。必要なAPIはすべてエージェントでローカルに使用できます。

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-16 ルールのパターン・タイプ

パターン・タイプ	説明
キー	キー値にのみ基づいて変更を監視します。キー名の最初のn個の文字のみを使用でき、このパターンと一致するすべてのキーが監視されます（ファイル監視ルールと同様）。最後の要素内でのみ1つのワイルドカードを使用できます（要素は/で区切られます）。
値	キーに対する値にのみ基づいて変更を監視します。値名の最初のn個の文字のみを使用でき、このパターンと一致するすべてのキーが監視されます（ファイル監視ルールと同様）。最後の要素内でのみ1つのワイルドカードを使用できます（要素は/で区切られます）。
すべて	キーおよび値の両方に対してこのパターンをチェックします。キー名の最初のn個の文字のみを使用でき、このパターンと一致するすべてのキーが監視されます（ファイル監視ルールと同様）。最後の要素内でのみ1つのワイルドカードを使用できます（要素は/で区切られます）。

変更を行ったユーザーによりWindowsレジストリに対する変更をフィルタする場合は、OSユーザー・ルール・セットを同じコンポーネントに追加し、そのルール・セットに関するボックスを選択し、これらのユーザーが他のタイプのルール・セットのフィルタリング用であることを指定します。次に、このWindowsレジストリ・ルール画面で、「コンポーネントに定義されているユーザーによる変更データのフィルタリング」ボックスを選択します。

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

Windowsレジストリ監視ポリシーは、レジストリのキーおよび値の追加、変更、削除に基づきます。

パターンは、HKEY_LOCAL_MACHINE、HKEY_CURRENT_USER、HKEY_CLASSES_ROOT、HKEY_USERSまたはHKEY_CURRENT_CONFIGから始める必要があります。

監視に含めるディレクトリ内で、除外するサブディレクトリを指定することもできます。たとえば、次のようにHKEY_LOCAL_MACHINE\Softwareを監視する一方で、HKEY_LOCAL_MACHINE\Software\Oracleを除外できます。

含める: HKEY_LOCAL_MACHINE\Software

除外: HKEY_LOCAL_MACHINE\Software\Oracle

HKEY_LOCAL_MACHINE\Softwareにおける変更はすべてレポートされます。HKEY_LOCAL_MACHINE\Software\Oracleまたは子キーにおける変更はレポートされません。

SNMPトラップ

この監視機能は、エージェントが任意のシステムから送信されるSNMPトラップをリスニングできるようにします。構成の変更が発生したときにSNMPトラップを送信するように、ネットワーク・ハードウェアを構成できます。多くのソフトウェア・アプリケーションは、監視する必要がある構成またはクリティカル・アラートがある場合にもトラップを送信できます。このルール・セットは、トラップをリスニングするようにエージェントを構成し、このエージェントが収集してサーバーに送り返すことに意味があるSNMPトラップをフィルタするためのルールの定義に使用されます。

ルール・セット構成

このルール・セットをコンポーネントに追加する際、ルール・セットに表示される「構成」リンクのオプションを設定する必要があります。構成するオプションは次のとおりです。

表C-17 ルール・セットのオプション

オプション	説明
有効	このルール・セットを有効化する場合は、このボックスを選択します。
トランスポート	トラップのリスニングに使用されるトランスポート・メカニズム。デフォルトはUDPです。この値は、システムが別のトランスポート・メカニズム（TCPなど）を使用することが判明した場合にのみ変更します。
ポート	エージェントがトラップをリスニングするポート。この値は、トラップの送信時に外部システムが接続するポートと一致する必要があります。
OID	変更を行ったユーザー名が含まれる、カンマで区切られたOIDのリスト。この値は、変更を行ったユーザーをレポートする際に重要です。たとえば、1.2.4,5,1.2.3.5

このルール・セットに他の構成パラメータはありません。これは、このルール・セットの監視対象となるデバイスが、監視しているのと同じデバイスであると認識されるためです。必要なAPIはすべてエージェントでローカルに使用できます。

ルール

1つのコンポーネントでは、このルール・セットに対して包含または除外ルールを最大50まで作成できます。ルールの作成時に使用できるパターン・タイプは次のとおりです。

表C-18 ルールのパターン・タイプ

パターン・タイプ	説明
コミュニティ	照合するコミュニティ文字列（publicなど）。このパターンでは、文字列内のどこにでも1つのワイルドカードを含めることができます。
エンタープライズ	照合するエンタープライズOID文字列（1.3.4.*など）。このパターンでは、文字列内のどこにでも1つのワイルドカードを含めることができます。
AgentAddress	照合するIPアドレス（変更の発生元）。このパターンでは、文字列内のどこにでも1つのワイルドカードを含めることができます。
SourceAddress	照合するIPアドレス（変更の発生元）。このパターンでは、文字列内のどこにでも1つのワイルドカードを含めることができます。通常、ソース・アドレスとエージェント・アドレスは同じです。ただし、変更を行う個人とトラップをトリガーするシステムとの間になんらかのプロキシ・システムが存在する場合を除きます。
GenericType	トラップのGenericTypeと一致する数値。
SpecificCode	トラップのSpecificCodeと一致する数値。
バインディング	OIDの値でのプレーン・テキスト検索。たとえば、OID 1.3.6.1.2.1.2.2.1にテキストIP Packetが含まれるイベントのみを取得するには、次のようなパターンとなります。 1.3.6.1.2.1.2.2.1=IP Packet

このルール・セットのルールを作成するときは、次のガイドラインに従います。

ルールが定義されていない場合、イベントは取得されません。
ルールが一部のパターン・タイプにのみ定義されている場合、そのパターン・タイプのみが評価されます。
同じパターン・タイプでは、ワイルドカード（*）を使用しないパターンが、ワイルドカードを使用するパターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める system」と「除外 syst*」の2つのルールがある場合、ユーザーsystemによるアクションが取得されます。
特定のパターン・タイプでパターンの長さが同じ場合は、包含パターンが除外パターンより優先されます。たとえば、「ユーザー」パターン・タイプに「含める *」と「除外 *」の2つのルールがある場合、すべてのイベントが取得されます。

C コンポーネント内部ルール・セット機能の詳細

Oracle 8i/9i/10g（監査）

ルール・セット構成

ルール

Oracle 8i（スナップショット）とOracle 9i/10g（スナップショット）

ルール・セット構成

ルール

Microsoft SQL Server 2000（監査）

ルール・セット構成

ルール

Microsoft SQL Server 2000（SQLトレース）

ルール・セット構成

ルール

Microsoft SQL Server（スナップショット）

ルール・セット構成

ルール

Microsoft Active Directory（トレース）

ルール・セット構成

ルール

Active Directory/LDAP（スナップショット）

ルール・セット構成

ルール

Microsoft Windowsレジストリ

ルール・セット構成

ルール

SNMPトラップ

ルール・セット構成

ルール