IBM FileNet P8, バージョン 5.2.1            

監査

監査とは、ソース・オブジェクトのイベントを記録することです。Content Engine クラス上のほとんどのイベントは監査できます。Content Engine サーバーは、監査が構成されている場合、イベント・オブジェクトを作成し、監査ログ (オブジェクト・ストアのデータベースの Event テーブル) に格納します。イベント・オブジェクトからは、作成日、発生元ユーザー、結果状況、イベントのソース・オブジェクト、およびその他の情報を入手できます。

注:
  • Content Engine サーバーで実行される操作のみを監査できます。成功または失敗したクライアント操作はサーバーから監査できません。
  • 今回のリリースでは、Content Engine での監査可能な失敗は、操作の結果がアクセス拒否である場合に制限されています。
  • クライアントが読み取り専用プロパティーを更新すると、Content Engine API は直ちに例外をスローします。しかし、Web サービス・インターフェースを使用しているクライアント・アプリケーションの場合、またはクライアント側メタデータ・キャッシュを Content Engine API で無効にしたクライアントの場合、クライアント側で例外は発生しません。代わりに、クライアント・タイプが読み取り専用プロパティーを変更する際に、サーバー側で監査の失敗が記録されます。

監査のコード例については、「監査関連オブジェクトの操作」を参照してください。IBM® Administration Console for Content Platform Engine を使用して監査するには、オブジェクトのアクティビティーのトラッキングを参照してください。

セットアップ要件

監査の構成は、オブジェクト・ストア・レベルで、クラスごとに行います。監査をセットアップするには、以下のようにします。

  • オブジェクト・ストアの監査を有効にします。ObjectStore オブジェクト の AuditLevel プロパティーを調べると、監査が有効になっているかどうかを判別できます。監査が無効になっていると、イベントは監査イベント・ログに記録されません。
  • 監査可能なクラスを入手します。これは、Subscribable オブジェクトで表されます。
  • クラスで監査を行うイベントごとに、AuditDefinition オブジェクトを 構成し、それをクラスに設定します。AuditDefinition オブジェクトには、以下のプロパティーが含まれています。
    • 監査対象のシステムまたはカスタム・イベント。監査されるイベントは EventClassDefinition オブジェクトで表されます。監査可能イベントのリストについては、「サブスクライブ可能イベントと監査可能イベント」を参照してください。
    • ソース・オブジェクト (変更されたイベント後のオブジェクトと元のイベント前オブジェクト) を監査レコードに記録するオプション。詳細については、ソース・オブジェクトの永続化を参照してください。
    • フィルター式をイベントのソース・オブジェクトに適用するオプション。イベントが監査されるかどうかを判別します。例えば、フィルター式は、ソース・オブジェクトのプロパティーが変更されたかどうかを テストでき、プロパティーが変更されていなければ、イベントの監査は行われません。フィルター式は、正常な操作のみに適用されます。
    • 監査定義の名前を指定して、監査処理クライアントまたはクライアント機能に関連付けるオプション。
    • 監査処理クライアントの対象ではなくなった監査定義を無効にするオプション。

さらに、1 つのクラスに同じイベント・タイプの AuditDefinition オブジェクトを複数配置することもできます。例えば、Document クラスに 2 つの監査定義 (両方とも更新イベント用) を設定するなどです。詳しくは、「同じイベントの複数の監査定義を構成する」を参照してください。

ソース・オブジェクトの永続化

監査済みイベントのソース・オブジェクト (イベントを生成したオブジェクト) は、監査ログに永続化可能です。ソース・オブジェクトには、次の 2 つの種類があります。変更されたイベント後のオブジェクトと元のイベント前のオブジェクト。変更されたオブジェクトの権限、プロパティー、およびコンテンツは、オブジェクトの現在の状態を反映し、元のオブジェクトは、イベント前のオブジェクトのスナップショットを提供します。デフォルトでは、変更されたオブジェクトと元のオブジェクトは、監査レコードで永続化されます。

注: データベース内に変更されたオブジェクトと元のオブジェクトを保持すると、ラージ・オブジェクト (LOB) 格納域がかなり消費される可能性があります。データベース内の監査済みレコードのサイズを制御するには、AuditDefinition.ObjectStateRecordingLevel プロパティーを使用して、監査レコード内のオブジェクトの永続化のレベルを指定します。

変更されたソース・オブジェクトは、タイプが ObjectChangeEvent のイベントに対して永続化できます。監査イベント・ログから変更されたソース・オブジェクトを取得するには、ObjectChangeEvent オブジェクトの SourceObject プロパティーを取得します。

オブジェクト値プロパティーを元のソース・オブジェクトから取得すると、オブジェクト値プロパティーの値として参照されるオブジェクトは、イベントが記録された時点での該当するオブジェクトになります。ただし、これらのオブジェクトはそのイベント以降に変更されている可能性があります。参照されているこれらのオブジェクトへのメソッド呼び出しはいずれも、現時点で存在するオブジェクトに対して実行されます。参照されているオブジェクトがそれ以降に削除された場合、これらのオブジェクトにアクセスを試みると、Object Not Found 例外 (オブジェクトが見つかりません) が発生します。

元のソース・オブジェクトは、タイプが ObjectChangeEvent のほとんどのイベントに対して永続化できます。監査イベント・ログから元のソース・オブジェクトを取得するには、ObjectChangeEvent オブジェクトから OriginalObject プロパティーを取得します。ただし、 イベント CancelCheckoutEventCreationEventDeletionEventFileEventPublishRequestEvent、および UnfileEvent から 元のソース・オブジェクトを取得することはできないので注意してください。

同じイベントの複数の監査定義を構成する

1 つのクラスに同じイベント・タイプの複数の監査定義を構成できます。これは、異なる監査条件を必要とする複数のアプリケーションが共存できる環境をサポートするものです。一般的に、重複したイベントを持つ監査定義はそれぞれ別のフィルター式で区別され、複数のアプリケーションの異なる要件に対応しています。 1 つのクラスに同じイベント・タイプの監査定義が複数ある場合、その同一イベントは異なるトリガー条件の下で監査されます。 1 つのクラス・インスタンスでイベントがトリガーされると、Content Engine はそのイベントの 1 つの監査操作のみを実行します。つまり、そのイベントの複数の監査定義の内 1 つのみを使用します。

同一クラスで重複したイベントを使用した監査定義の場合、以下のロジックによって Content Engine が使用する監査定義が判別されます。

  1. 有効な監査定義。有効なものがない場合は、何も使用されません。
  2. 2 つ以上の監査定義が有効な場合は、最も高い ObjectStateRecordingLevel 値 (ORIGINAL_AND_MODIFIED_OBJECTS の値が最大のもの) がある監査定義が最初に考慮されます。それらの監査定義の内、 フィルター式のないものが使用されます。

    2 つ以上の監査定義が有効で、これらに同等の ObjectStateRecordingLevel 値があり、さらにフィルター式がある場合は、true を返す最初のフィルター式が使用されます。

    すべてのフィルター式が false を返した場合は、より低い ObjectStateRecordingLevel プロパティーのレベルを持つ監査定義に対してこのステップが繰り返されます。この時、フィルタリングされない監査定義が最優先となります。

プロパティーの監査

監査済みイベントのソース・オブジェクトを永続化する代わりに、 個々のソース・オブジェクト・プロパティーを監査して、このイベントの詳細な情報を永続化できます。 1 つのイベントについてソース・オブジェクトの個々のプロパティーを監査できます。例えば、Claim クラスのドキュメントのタイプ、状況、 および調整者情報が必要な場合は、ClaimType、ClaimStatus、および AdjustorID プロパティーを監査できます。 個々のプロパティーを監査する機能は、分析データや履歴データを収集するクライアント・アプリケーションや、監査イベントのソース・オブジェクトに含まれるデータのすべてを必要とするわけではないクライアントに特に役立ちます。Event テーブルに記録されたソース・オブジェクトにより、ラージ・オブジェクト (LOB) 格納域がかなり消費される可能性があります。

タイプ ObjectChangeEvent のイベントとそのサブクラスのプロパティーを監査できます。 ソース・オブジェクト・プロパティーを監査するようにイベント・クラスを構成すると、Content Engine は、 そのプロパティーに対応する列を組み込んで Event テーブルを拡張します。そのソース・オブジェクトに対する監査対象イベントがトリガーされると、Content Engine はそのイベントのインスタンスをテーブルに保管し、監査対象のプロパティーの値をソース・オブジェクトからイベント・インスタンス内の該当する列にコピーします。

Event オブジェクトから監査済みソース・オブジェクトのプロパティーを取得するには、Event オブジェクトから 任意の値を取得するのと同じように操作します。例えば、以下のようにします。

String monitoredProperty = myUpdateEvent.getProperties().getStringValue("myMonitoredProperty");

基本の監査のセットアップ要件に加えて、プロパティーの監査では、 以下のようにイベント・クラスとソース・オブジェクトのクラスを構成することも必要になります。

  1. カスタム・プロパティーを監査するには、その PropertyTemplate オブジェクトを取得します。

    システム・プロパティーを監査するには、新規の PropertyTemplate オブジェクトを作成します。

  2. PropertyTemplate オブジェクトを使用して、タイプ ObjectChangeEvent の イベントに PropertyDefinition カスタム・オブジェクトを作成します。
  3. ソース・オブジェクト・クラスで、監査対象プロパティー用の PropertyDefinition オブジェクトを取得します。
  4. PropertyDefinition オブジェクトで、AuditAs プロパティーを、イベント・クラスの PropertyDefinition カスタム・オブジェクトの作成に使用した PropertyTemplate オブジェクトに設定します。

可能な場合は常に、監査対象のプロパティーと、監査済みの値が保管されるイベントのカスタム・プロパティーに同じデータ型を使用します。 次に例を示します。

ソース・オブジェクト・クラスの PropertyDefinition データ型 == AuditAs プロパティーのデータ型 == ObjectChangeEvent またはサブクラスの PropertyDefinition データ型。

ただし、必要であれば、あるデータ型の監査済みプロパティーを別のデータ型のイベント・プロパティーにマップできます。サポートされるデータ型変換は、整数から文字列、日付から文字列、オブジェクトから文字列 (GUID 形式)、およびブールから文字列です。

データ型変換が必要な 1 つのシナリオとして、複数のソース・オブジェクト・クラスからプロパティーを監査する際に、監査済みの各プロパティーをイベント・クラスの単一のプロパティーにマップします。例えば、クラス A に日付プロパティー、クラス B にオブジェクト値を持つプロパティーがあり、いずれもイベントの propertyZ (文字列型) に監査されるとします。いずれの場合も、監査済みの値は文字列に変換され、propertyZ に保管されます。

注: Content Engine でプロパティーの監査を効果的にセットアップするには、AuditAs プロパティーの設定可能性の制約を考慮に入れてください。

監査廃棄

規制のない監査はサーバーのリソースに悪影響を及ぼす可能性があるため、監査廃棄を使用して監査ログからのイベント・レコードを自動的に削除することができます。監査廃棄は、Content Engine 監査ログ (Event テーブル) 内の監査済みイベントを自動削除するサブシステムです。監査廃棄は、Content Engine 内でバックグラウンド・スレッドとして実行されます。ソース・オブジェクトを監査ログに永続化する場合などは、長期間の監査を行えるようにこの機能を使用することをお勧めします。

管理クライアント・アプリケーションは、以下のクラスの監査廃棄スレッドを構成できます。

  • CmAuditingConfiguration は、1 つ以上の CmTimeslot オブジェクトを使用して定義された廃棄スケジュールを設定します。これは、廃棄を実行するタイミングおよび期間を指定します。CmAuditingConfiguration オブジェクトは、サーバー階層のオブジェクト (DomainSiteVirtualServer、 および ServerInstance) に割り当てることができます。
  • CmAuditDispositionPolicy は、 廃棄ルール (廃棄用の監査レコードが識別される条件) を設定します。 オブジェクト・ストア・レベルで 1 つ以上の CmAuditDispositionPolicy オブジェクトを指定できます。

監査廃棄スレッドを実行するには、以下のオブジェクトが必要です。

  • 有効な CmAuditingConfiguration オブジェクト。このオブジェクトには、1 つ以上の CmTimeslot オブジェクトが含まれます。
  • 少なくとも 1 つの有効な CmAuditDispositionPolicy オブジェクト。このオブジェクトはオブジェクト・ストアに定義されます。

CmAuditingConfiguration オブジェクトと CmAuditDispositionPolicy オブジェクトを使用すると、例えば、廃棄スレッドを構成して、更新イベントを 3 カ月後に削除するようにしたり、毎週火曜日と木曜日は午前 2 時から 4 時間のタイム・スロットで、毎週土曜日は午前 12 時から 48 時間のタイム・スロットで廃棄を行うようにしたりすることができます。

ブックマークの設定

効率的な監査廃棄操作のサポート、および監査ログ内のレコードの正確な処理を行うには、Content Engine の API が提供するブックマーク・メカニズムを監査処理クライアント・アプリケーションで使用する必要があります。CmAuditProcessingBookmark オブジェクトで表されるブックマークは、監査ログ内の終了ポイントであり、監査処理クライアントによって処理される最後のレコードを示します。 監査処理クライアントは、セッションの終了時に監査のシーケンス番号を使用してブックマークを設定し、その後、新規セッションの開始時にそのブックマークを取得して、次の監査のシーケンス番号で処理を再開します。

ブックマークは複数存在する場合があり、それぞれ別の監査処理クライアントを反映しています。 監査廃棄は、クライアントによって既に処理された監査済みイベントのみを削除することを意図して、監査のシーケンス番号が最低値のブックマークよりも小さいレコードのみを考慮します。

監査処理クライアントがその CmAuditProcessingBookmark オブジェクトを作成せずにいると、監査廃棄は CmAuditDispositionPolicy オブジェクトのみに制御されるため、未処理の監査済みレコードが予期せずに削除される可能性があります。クライアントがその CmAuditProcessingBookmark オブジェクトを更新せずにいると、廃棄スレッドは、既に処理済みの削除対象レコードをスキップする可能性があります。監査処理クライアントの実行を永続的に中止する場合は、クライアントに関連付けられたブックマークを削除するか、 あるいは Content Engine 管理者に削除を依頼してください。



最終更新日: 2015 年 10 月
audit_concepts.htm

© Copyright IBM Corp. 2015.