第 10 章 監査ログ

この章では、監査システムでのイベントの記録方法について説明します。

これらの情報は、次のトピックで構成されています。

• 「監査ログの概要」

• 「Identity Manager 監査の機能」

• 「ワークフローからの監査イベントの作成」

• 「監査設定」

• 「データベーススキーマ」

• 「監査ログ設定」

• 「監査ログからのレコードの削除」

• 「カスタム監査パブリッシャーの使用」

• 「カスタム監査パブリッシャーの開発」

監査ログの概要

Identity Manager 監査の目的は、誰が何をいつどの Identity Manager オブジェクトに対して行なったかを記録することです。

監査イベントは、1 つ以上のパブリッシャーによって処理されます。デフォルトでは、Identity Manager はリポジトリパブリッシャーを使用してリポジトリに監査イベントを記録します。管理者は、監査グループを使用してフィルタすることにより、記録する監査イベントのサブセットを選択できます。各パブリッシャーには、最初に有効にされた 1 つ以上の監査グループを割り当てることができます。

ユーザーの違反の監視と管理については、第 13 章アイデンティティー監査: 基本概念を参照してください。

Identity Manager 監査の機能

ほとんどのデフォルトの監査は、Identity Manager の内部コンポーネントによって実行されます。ただし、ワークフローまたは Java コードからイベントを生成できるようにしているインタフェースもあります。

デフォルトの Identity Manager 監査インストゥルメンテーションでは、次の 4 つの主要領域に焦点が当てられます。

• 「プロビジョニングツール」。プロビジョニングツールと呼ばれる内部コンポーネントは監査イベントを生成します。

• 「ビューハンドラ」。ビューアーキテクチャーでは、ビューハンドラが監査レコードを生成します。ビューハンドラは常に、オブジェクトの作成または変更時に監査を行います。

• 「セッション」。セッションメソッド (checkinObject、createObject、runTask、login、logout など) は、監査処理の終了後に、監査レコードを作成します。ほとんどのインストゥルメンテーションはビューハンドラにプッシュされます。

• 「ワークフロー」。デフォルトでは、承認ワークフローだけが監査レコードを生成するように設定されています。これらは、リクエストが承認または却下されたときに、監査イベントを生成します。ワークフロー機能は、com.waveset.session.WorkflowServices アプリケーションを介して、監査ロガーとやり取りします。詳細については、次の節を参照してください。

ワークフローからの監査イベントの作成

デフォルトでは、承認ワークフローだけが監査レコードを生成するように設定されています。この節では、com.waveset.session.WorkflowServices アプリケーションを使用して、任意のワークフロープロセスから追加の監査イベントを生成する方法について説明します。

追加の監査イベントは、カスタムワークフローのレポートで必要になる場合があります。ワークフローに監査イベントを追加する方法については、「標準監査イベントをログするためのワークフローの変更」を参照してください。

ワークフローレポートのサポートとして、ワークフローに特別な監査イベントを追加することもできます (「ワークフローレポート」)。ワークフローレポートでは、ワークフローが完了するまでの時間をレポートします。特別監査イベントは、時間計算で使用するデータの格納に必要です。タイミング監査イベントをワークフローに追加する方法については、「タイミング監査イベントをログするためのワークフローの変更」を参照してください。

com.waveset.session.WorkflowServices アプリケーション

com.waveset.session.WorkflowServices アプリケーションは、任意のワークフロープロセスから監査イベントを生成します。表 10–1 に、このアプリケーションに指定できる引数を示します。

標準監査イベントをログするためのワークフローの変更

ワークフロー内に標準監査イベントを作成するには、ワークフローに次の <Activity> 要素を追加します。

<Activity name=’createEvent’>

次に、<Activity> 要素の入れ子として、com.waveset.session.WorkflowServices アプリケーションを参照する <Action> 要素を記述します。

<Action class=’com.waveset.session.WorkflowServices’>

<Action> 要素の入れ子として、必須およびオプションの <Argument> 要素を記述します。引数の一覧については、表 10–1 を参照してください。

標準監査イベントをログするには、op 引数を audit に設定します。

「ワークフローの例」では、標準監査イベントの作成に必要な最小限のコードを示しています。

ワークフローの例

次の例は、簡単なワークフローアクティビティーを示しています。この例では、ResourceAdministrator によって実行される、ADSIResource1 という名前のリソース削除アクティビティーをログに記録するイベントを生成しています。

例 10–1 単純なワークフローアクティビティー

<Activity name=’createEvent’> <Action class=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’audit’/> <Argument name=’type’ value=’Resource’/> 
<Argument name=’action’ value=’Delete’/> <Argument name=’status’ value=’Success’/> 
<Argument name=’subject’ value=’ResourceAdministrator’/> 
<Argument name=’name’ value=’ADSIResource1’/> </Action> <Transition to=’end’/> </Activity>

次の例では、承認プロセスで各ユーザーが適用した変更を詳細なレベルまで追跡するワークフローに、特定の属性を追加する方法を示しています。この追加は通常、ユーザーからの入力をリクエストする ManualAction のあとに行われます。

ACTUAL_APPROVER は、実際に承認を実行した人物に基づいて、フォームおよびワークフロー (承認テーブルから承認する場合) で設定されます。APPROVER は、それが割り当てられた人物を識別します。

例 10–2 承認プロセスでの変更追跡への属性の追加

 
<Action name=’Audit the Approval’ application=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’audit’/> <Argument name=’type’ value=’User’/> 
<Argument name=’name’ value=’$(CUSTOM_DESCRIPTION)’/> <Argument name=’action’ value=’approve’/> 
<Argument name=’accountId’ value=’$(accountId)’/> <Argument name=’status’ value=’success’/> 
<Argument name=’resource’ value=’$(RESOURCE_IF_APPLICABLE)’/> 
<Argument name=’loginApplication’ value=’$(loginApplication)’/> 
<Argument name=’attributes’> <map> 
<s>fullname</s><ref>user.accounts[Lighthouse].fullname</ref> 
<s>jobTitle</s><ref>user.accounts[Lighthouse].jobTitle</ref> 
<s>location</s><ref>user.accounts[Lighthouse].location</ref> 
<s>team</s><ref>user.waveset.organization</ref> <s>agency</s>
<ref>user.accounts[Lighthouse].agency</ref> </map> </Argument> 
<Argument name=’originalAttributes’> <map> <s>fullname</s> <s>User’s previous fullname</s> 
<s>jobTitle</s> <s>User’s previous job title</s> <s>location</s> <s>User’s previous location</s> 
<s>team</s> <s>User’s previous team</s> <s>agency</s> <s>User’s previous agency</s> </map> 
</Argument> <Argument name=’attributes’> <map> <s>firstname</s> <s>Joe</s> <s>lastname</s> 
<s>New</s> </map> </Argument> <Argument name=’subject’> <or> <ref>ACTUAL_APPROVER</ref> 
<ref>APPROVER</ref> </or> 
</Argument> <Argument name=’approver’ value=’$(APPROVER)’/> </Action>

タイミング監査イベントをログするためのワークフローの変更

ワークフローレポートのサポートとして、計時イベントをログに記録するようにワークフローを変更できます (「ワークフローレポート」)。標準監査イベントではイベントが発生したことのみをログしますが、タイミング監査イベントではイベントの開始時刻と停止時刻を記録して、時間計算の実行を可能にします。計時イベントデータに加えて、標準監査イベントでログに記録される情報の大部分が格納されます。詳細については、「タイミング監査イベントで格納される情報」を参照してください。

タイミング監査イベントをログに記録するには、監査を行うワークフロータイプごとに、ワークフローの監査を有効にする必要があります。

• タスクテンプレートを使用して管理者インタフェースで設定できるワークフローの場合は、最初に、監査するワークフローに対応するタスクテンプレートを有効にします。手順については、「タスクテンプレートの有効化」を参照してください。

  次に、「ワークフロー全体の監査」チェックボックスを選択して、ワークフローの監査を有効にします。手順については、「「監査」タブの設定」を参照してください。

• タスクテンプレートのないワークフローの場合は、そうする代わりに、auditWorkflow という名前の変数を定義してその値を true に設定します。

ワークフローの監査を行うとパフォーマンスは低下します。

例 10–3 に、タイミング監査イベントの作成に必要なコードを示します。タイミング監査イベントをログするには、op 引数を auditWorkflow に設定します。

action 引数も必須で、次のいずれかの値に設定します。

• StartWorkflow

• EndWorkflow

• StartProcess

• EndProcess

• StartActivity

• EndActivity

auditconfig.xml にそのほかの action 引数も定義できます。

例: ワークフローでの監査イベントの開始と停止

例 10–3 は、ワークフローでタイミング監査イベントを有効にする場合を示しています。ワークフローを設定するには、ワークフロー、プロセス、アクティビティーの最初と最後に auditWorkflow イベントを追加してください。

auditWorkflow の処理は com.waveset.session.WorkflowServices で定義されています。詳細については、「com.waveset.session.WorkflowServices アプリケーション」を参照してください。

例 10–3 ワークフローでのタイミング監査イベントの開始

<Action application=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’auditWorkflow’/> 
<Argument name=’action’ value=’StartWorkflow’/> 
</Action>

ワークフローでタイミング監査イベントのログを停止するには、ワークフローの終わりにある pre-end アクティビティーに例 10–4 のコードを追加します。ワークフローまたはプロセスの設定時には、end アクティビティーには何も追加できません。最後の auditWorkflow イベントの実行後、無条件に end イベントに移行する pre-end アクティビティーを作成してください。

例 10–4 ワークフローでのタイミング監査イベントの停止

<Action application=’com.waveset.session.WorkflowServices’> 
<Argument name=’op’ value=’auditWorkflow’/> <Argument name=’action’ value=’EndWorkflow’/> 
</Action>

タイミング監査イベントで格納される情報

デフォルトでは、タイミング監査イベントは、次に示す属性など通常の監査イベントで保存されるほとんどの情報をログに記録します。

これらの属性は auditableAttributesList にあり、logattr テーブルに格納されます。Identity Manager は、workflowAuditAttrConds 属性が定義されているかどうかもチェックします。

プロセスまたはワークフローの 1 つのインスタンス内でアクティビティーを複数回呼び出すことができます。監査イベントを特定のアクティビティーインスタンスと対応させるために、ワークフローインスタンス内で一意の識別子が logattr テーブルに格納されます。

ワークフローの logattr テーブルに追加の属性を格納するには、workflowAuditAttrConds リストを定義します。 これは GenericObjects のリストと見なされます。workflowAuditAttrConds リストに attrName 属性を定義すると、Identity Manager はコード内のオブジェクトから attrName を取得します。最初に attrName をキーとして使用し、続いて attrName 値を保存します。すべてのキーと値は、大文字の値として記録されます。

監査設定

監査設定は、1 つ以上のパブリッシャーと定義済みの複数のグループで構成されます。

監査グループは、オブジェクトタイプ、アクション、アクションの結果に基づいて、すべての監査イベントのサブセットを定義します。各パブリッシャーには 1 つ以上の監査グループが割り当てられます。デフォルトで、すべての監査グループにリポジトリパブリッシャーが割り当てられます。

監査パブリッシャーは、特定の監査出力先に監査イベントを配信します。デフォルトのリポジトリパブリッシャーは、監査レコードをリポジトリに書き込みます。それぞれの監査パブリッシャーには、実装専用のオプションを指定できます。監査パブリッシャーには、テキストフォーマッタを割り当てることができます。(テキストフォーマッタは監査イベントのテキスト表現を提供します。

監査設定 (#ID#Configuration:AuditConfiguration) オブジェクトは、sample/auditconfig.xml ファイルで定義されます。この設定オブジェクトには、汎用オブジェクトである拡張機能があります。

最上位には次の属性があります。

• 「filterConfiguration 属性」

• 「extendedTypes 属性」

• 「extendedActions 属性」

• 「extendedResults 属性」

• 「publishers 属性」

filterConfiguration 属性

filterConfiguration 属性には、1 つ以上のイベントがイベントフィルタを通過できるようにするための、イベントグループのリストを指定します。filterConfiguration 属性に指定した各グループには、表 10–2 に示す属性が含まれます。

例 10–5 に、デフォルトのリソース管理グループを示します。

例 10–5 デフォルトのリソース管理グループ

<Object name=’Resource Management’> <Attribute name=’enabled’ value=’true’/> 
<Attribute name=’displayName’ value=’UI_RESOURCE_MGMT_GROUP_DISPLAYNAME’/> 
<Attribute name=’enabledEvents’> <List> <Object> <Attribute name=’objectType’ value=’Resource’/> 
<Attribute name=’actions’ value=’ALL’/> <Attribute name=’results’ value=’ALL’/> </Object> <Object> 
<Attribute name=’objectType’ value=’ResourceObject’/> <Attribute name=’actions’ value=’ALL’/> 
<Attribute name=’results’ value=’ALL’/> </Object> </List> </Attribute> </Object>

Identity Manager には、デフォルトの監査イベントグループが用意されています。これらのイベントグループと、イベントグループによって有効にされるイベントについては、以降の節で説明します。

• 「アカウント管理グループ」

• 「アイデンティティーシステム外部での変更グループ」

• 「コンプライアンス管理グループ」

• 「設定管理グループ」

• 「イベント管理グループ」

• 「ログイン/ログオフグループ」

• 「パスワード管理グループ」

• 「リソース管理グループ」

• 「ロール管理グループ」

• 「セキュリティー管理グループ」

• 「サービスプロバイダ グループ」

• 「タスク管理グループ」

監査イベントグループは、Identity Manager 管理者インタフェースの「監査設定」ページ (「設定」 > 「監査」) で設定できます。手順については、「監査グループおよび監査イベントの設定」を参照してください。

また、「監査設定」ページでは、成功したイベントと失敗したイベントをグループごとに設定できます。このインタフェースでは、グループで有効にしたイベントの追加や変更はサポートされていません。これらの操作は、Identity Manager デバッグページ (「Identity Manager デバッグページ」) を使用して実行できます。

監査イベントグループに選択できるアクションのすべてが、ログレコードに記録されるとは限りません。また、「すべてのアクション」オプションを選択しても、一覧に表示されたすべてのアクションが、すべての監査イベントグループで利用可能になるわけではありません。

アカウント管理グループ

このグループはデフォルトで有効になっています。

アイデンティティーシステム外部での変更グループ

このグループはデフォルトで無効になっています。

コンプライアンス管理グループ

このグループはデフォルトで有効になっています。

設定管理グループ

このグループはデフォルトで有効になっています。

イベント管理グループ

このグループはデフォルトで有効になっています。

ログイン/ログオフグループ

このグループはデフォルトで有効になっています。

パスワード管理グループ

このグループはデフォルトで有効になっています。

リソース管理グループ

このグループはデフォルトで有効になっています。

ロール管理グループ

このグループはデフォルトで無効になっています。

セキュリティー管理グループ

このグループはデフォルトで有効になっています。

サービスプロバイダ グループ

このグループはデフォルトで有効になっています。

タスク管理グループ

このグループはデフォルトで無効になっています。

extendedTypes 属性

com.waveset.object.Type クラスに追加する新しいタイプを、それぞれ監査できます。新しいタイプには一意の 2 文字のデータベースキーが割り当てられ、このキーはデータベースに格納されます。新しいタイプはすべて、さまざまな監査レポートインタフェースに追加されます。フィルタされずにデータベースにログされる新しいタイプは、監査イベントグループの enabledEvents 属性にそれぞれ追加する必要があります (enabledEvents 属性の説明を参照)。

関連付けられた com.waveset.object.Type を持たない対象を監査したり、既存のタイプをさらに細かく表したりする必要が生じる場合があります。

たとえば、WSUser オブジェクトは、ユーザーのアカウント情報をすべてリポジトリに格納します。監査プロセスは、各イベントに USER タイプとしてマークを付けるのではなく、WSUser オブジェクトを 2 つの異なる監査タイプ (Resource Account と Identity Manager Account) に分割します。このようにオブジェクトを分割することにより、監査ログでの特定のアカウント情報が検索しやすくなります。

extendedObjects 属性に追加することによって、拡張された監査タイプを追加します。拡張された各オブジェクトには、次の表に示す属性が必要になります。

すべての顧客固有のキーには # の記号を先頭に付け、新しい内部キーが追加されたときにキーが重複するのを防止します。

例 10–6 に、拡張タイプの Identity Manager アカウントを示します。

例 10–6 拡張タイプの Identity Manager アカウント

<Object name=’LighthouseAccount’> <Attribute name=’displayName’ value=’LG_LIGHTHOUSE_ACCOUNT’/> 
<Attribute name=’logDbKey’ value=’LA’/> <Attribute name=’mapsToType’ value=’User’/> 
<Attribute name=’supportedActions’> <List> <String>Disable</String> <String>Enable</String> 
<String>Create</String> <String>Modify</String> <String>Delete</String> <String>Rename</String> 
</List> </Attribute> </Object>

extendedActions 属性

監査アクションは通常、com.waveset.security.Right オブジェクトにマップします。新しい Right オブジェクトを追加するときに、一意の 2 文字の logDbKey を指定する必要があります。 これはデータベースに格納されます。監査する必要のある特定のアクションに対応する権利がない状況に遭遇することがあります。extendedActions 属性のオブジェクトのリストに追加することにより、アクションを拡張できます。

それぞれの extendedActions オブジェクトは、表 10–16 に示す属性を含んでいる必要があります。

すべての顧客固有のキーには # の記号を先頭に付け、新しい内部キーが追加されたときにキーが重複するのを防止します。

表 10–16 に、ログアウトのアクションを追加する例を示します。

例 10–7 ログアウトのアクションの追加

<Object name=’Logout’> <Attribute name=’displayName’ value=’LG_LOGOUT’/> 
<Attribute name=’logDbKey’ value=’LO’/> </Object>

extendedResults 属性

監査のタイプおよびアクションを拡張する以外に、結果を追加できます。デフォルトで、成功と失敗の 2 つの結果があります。extendedResults 属性のオブジェクトのリストに追加することにより、結果を拡張できます。

それぞれの extendedResults オブジェクトは、表 10–17 に示す属性を含んでいる必要があります。

すべての顧客固有のキーには 0 ～ 9 の範囲を使用して、新しい内部キーを追加するときにキーの重複を防止します。

publishers 属性

publishers リスト中の各項目は汎用オブジェクトです。各 publishers オブジェクトには次の属性があります。

データベーススキーマ

監査データを格納する Identity Manager リポジトリには、次の 2 つのテーブルがあります。

• waveset.log– イベントの詳細のほとんどを格納します。

• waveset.logattr– 各イベントが属する組織の ID を格納します。

これらのテーブルについてはこの節で説明します。

監査ログデータがこれらのテーブルに指定された列の長さ制限を超えると、Identity Manager は 制限に合わせてデータを切り捨てます。監査ログの切り捨てについては、「監査ログの切り捨て」を参照してください。

監査ログには、列の長さ制限を変更できる列がいくつかあります。これらの列の詳細と、長さ制限を変更する方法については、「監査ログ設定」を参照してください。

waveset.log テーブル

この節では、waveset.log テーブルで使用される列名とデータ型を説明します。データ型は、Oracle データベース定義から取得され、データベースごとに異なります。サポートされるすべてのデータベースのデータスキーマ値の一覧については、付録 B 監査ログデータベーススキーマを参照してください。

いくつかの列値は、領域を最適化するために、キーとしてデータベースに格納されます。キーの定義については、「監査ログデータベースマッピング」を参照してください。

• objectType CHAR(2) – 監査されているオブジェクトタイプを表す 2 文字のキー。

• action CHAR(2) – 実行されたアクションを表す 2 文字のキー。

• actionStatus CHAR(1) – 実行されたアクションの結果を表す 1 文字のキー。

• reason CHAR(2) – 障害が発生した場合に、ReasonDenied オブジェクトを記述するための 2 文字のデータベースキー。ReasonDenied は、メッセージカタログエントリをラップするクラスで、無効な資格や不十分な特権などの一般的なエラーに使用されます。

• actionDateTimeVARCHAR(21) – 上記のアクションが実行された日時。この値はグリニッジ標準時で格納されます。

• objectName VARCHAR(128) – 操作中に影響を受けたオブジェクトの名前。

• resourceName VARCHAR(128) – 操作中に使用されたリソース名 (該当する場合)。リソースを参照しないイベントもありますが、多くの場合、操作の実行で使用したリソースをログすると、より詳しい詳細が得られます。

• accountName VARCHAR(255) – 影響を受けているアカウント ID (該当する場合)。

• server VARCHAR(128) – アクションが実行される (イベントロガーによって自動的に割り当てられた) サーバー。

• message VARCHAR(255*) または CLOB – エラーメッセージなど、アクションに関連するローカライズされたメッセージ。テキストはローカライズして格納されます。 したがって国際化されません。この列の長さ制限は設定可能です。デフォルトのデータ型は VARCHAR で、デフォルトのサイズ制限は 255 文字です。サイズ制限を調整する方法については、「監査ログ設定」を参照してください。

• interface VARCHAR(50) – 操作が実行された Identity Manager インタフェース (管理者、ユーザー、IVR、SOAP などのインタフェース)。

• acctAttrChanges VARCHAR(4000) または CLOB – 作成および更新中に変更されたアカウント属性を格納します。属性変更フィールドは常に、リソースアカウントまたは Identity Manager アカウントオブジェクトの作成または更新中に設定されます。アクション中に変更されたすべての属性は、文字列としてこのフィールドに格納されます。データは NAME=VALUE NAME2=VALUE2 の形式です。このフィールドは、名前または値に対して contains SQL 文を実行して問い合わせることができます。

  次のコード例は、acctAttrChanges 列の値を示しています。

  COMPANY="COMPANY" DEPARTMENT="DEPT" DESCRIPTION="DSMITH DESCRIPTION" FAX NUMBER="5122222222" HOME ADDRESS="12282 MOCKINGBIRD LANE" HOME CITY="AUSTIN" HOME PHONE="5122495555" HOME STATE="TX" HOME ZIP="78729" JOB TITLE="DEVELOPER" MOBILE PHONE="5125551212" WORK PHONE="5126855555" EMAIL="someone@somecompany.COM" EXPIREPASSWORD="TRUE" FIRSTNAME="DANIEL" FULLNAME="DANIEL SMITH" LASTNAME="SMITH"

  ---

  注 –

  Identity Manager のインストールで Oracle リポジトリを使用しているときに、監査ログに切り捨てエラーが見つかった場合は、監査ログテーブルの accountAttrChanges フィールドを VARCHAR(4000) から CLOB に変換できます。Identity Manager には、/web/sample ディレクトリにサンプルの DDL スクリプトが用意されています。このスクリプトは、log.acctAttrChanges を VARCHAR(4000) から CLOB に変換します。convert_log_acctAttrChangesCHAR2CLOB.oracle.sql スクリプトは、既存のデータを保存し、4000 文字を超える accountAttrChanges フィールドを読み取ることができます。

  この変換はオプションです。切り捨てエラーに気付いたときにだけ実行してください。また、変換スクリプトを実行する前に、影響を受けるテーブルを必ずバックアップしてください。

  変換スクリプトを実行したあとに、Web アプリケーションサーバーを停止し、再起動してください。新しいレポートを実行したときに、正しく表示されます。

  ---

• acctAttr01label-acctAttr05label VARCHAR(50) – これらの 5 つの追加 NAME スロットは、最大 5 つの属性名を、大きな塊 (ブロブ) ではなく独立した列に格納されるように格上げできる列です。「リソーススキーマの設定」ページで "audit?" 設定を使用して、属性を格上げできます。これにより、属性をデータマイニングに利用できます。

• acctAttr01value-acctAttr05value VARCHAR(128) – ブロブではなく、個別の列に格納されるように最大 5 つの属性値を格上げできる 5 つの追加 VALUE スロット。

• parm01label-parm05label VARCHAR(50) – イベントに関連するパラメータの格納に使用される 5 つのスロット。例として、Client IP 名と Session ID 名があります。

• parm01value-parm05value VARCHAR(128*) または CLOB – イベントに関連するパラメータの格納に使用される 5 つのスロット。例として、Client IP 値と Session ID 値があります。これらの列の長さ制限は設定可能です。デフォルトのデータ型は VARCHAR で、デフォルトのサイズ制限は 128 文字です。サイズ制限を調整する方法については、「監査ログ設定」を参照してください。

• id VARCHAR(50) – waveset.logattr テーブルで参照されるリポジトリによって各レコードに割り当てられた一意の ID。

• name VARCHAR(128) – 各レコードに割り当てられた生成名。

• xml BLOB – Identity Manager で内部的に使用されます。

waveset.logattr テーブル

waveset.logattr テーブルは、イベントごとに組織のメンバーシップの ID を格納するために使用されます。 このテーブルを使用して、組織別に監査ログの範囲が設定されます。

• id VARCHAR(50) – waveset.log レコードの ID。

• attrname VARCHAR(50) – 現在は、常に MEMBEROBJECTGROUPS です。

• attrval VARCHAR(255) – イベントが属する MemberObject グループの ID。

監査ログの切り捨て

監査ログデータの 1 つ以上の列が、指定した列の長さ制限を超えると、その列のデータは制限内になるように切り捨てられます。具体的には、切り捨て後のデータは指定された制限値より 3 文字短くなります。次に列データに省略記号 (...) が付加され、データが切り捨てられたことを示します。

さらに、切り捨てられたレコードを見つけやすいように、その監査レコードの NAME 列の先頭に #TRUNCATED# という文字列が付加されます。

Identity Manager では、UTF–8 エンコーディングを想定して、メッセージを切り捨てる位置を計算します。UTF–8 以外のエンコーディングを使用する設定では、切り捨て後のデータがデータベース内の実際の列サイズをまだ超過する可能性があります。こうした状態が発生すると、切り捨て後のメッセージは監査ログに表示されず、エラーがシステムログに出力されます。

監査ログ設定

監査ログには、リポジトリに大容量のデータを格納するように設定できる列があります。

列の長さ制限の変更

監査ログのいくつかの列では、列の長さの制限を変更できます。長さの制限を変更できる列は次のとおりです。

• message 列

• parmNNvalue 列 (NN = 01、02、03、04、 または 05)

• xml 列

監査ログ列の詳細については、「データベーススキーマ」を参照してください。

列の長さ制限は、RepositoryConfiguration オブジェクトを編集することで変更できます。RepositoryConfiguration オブジェクトの編集方法については、「Identity Manager 設定オブジェクトの編集」を参照してください。

• message 列の長さ制限を変更するには、maxLogMessageLength 値を変更します。

• parmNNvalue 列の長さ制限を変更するには、maxLogParmValueLength 値を変更します。5 つの列すべてに同じ制限値が適用されます。(列ごとに長さの値を定義することはできません。

• xml 列の長さ制限を変更するには、maxLogXmlLength 値を変更します。

新しい値を有効にするには、サーバーの再起動が必要です。

RepositoryConfiguration オブジェクト内の列の長さ制限の設定値によって、列に格納できるデータの最大量が決まります。格納されるデータがこれらの設定値を超える場合は、Identity Manager によりデータが切り捨てられます。詳細については、「監査ログの切り捨て」を参照してください。

RepositoryConfiguration オブジェクト内の列の長さの設定値を大きくする場合は、データベースの列サイズの設定値が RepositoryConfiguration オブジェクトで設定されるサイズ以上であることも確認してください。

監査ログからのレコードの削除

監査ログは、サイズが大きくなりすぎないよう定期的に切り捨てるようにしてください。監査ログメンテナンスタスクを使用して、監査ログから古いレコードを削除するタスクをスケジュールできます。

1. 管理者インタフェースで、「サーバータスク」、「スケジュールの管理」の順にクリックします。

2. 「スケジューリング可能なタスク」セクションで「監査ログメンテナンスタスク」をクリックします。

   「AuditLog Maintenance Task タスクのスケジュールの新規作成」ページが開きます。

3. フォームに値を入力し、「保存」をクリックします。

カスタム監査パブリッシャーの使用

Identity Manager では、カスタム監査パブリッシャーへ監査イベントを送信できます。

次のカスタムパブリッシャーが提供されています。

• コンソール。標準出力または標準エラーに監査イベントを出力します。

• ファイル。フラットファイルへ監査イベントを書き込みます。

• JDBC。JDBC データストアに監査イベントを記録します。

• JMS。JMS キューかトピックに監査イベントを記録します。

• JMX。JMX (Java Management Extensions) クライアントで Identity Manager の監査ログアクティビティーを監視できるように、監査イベントをパブリッシュします。

• スクリプト。カスタムスクリプトで監査イベントを保存できるようにします。

独自のパブリッシャーを作成する場合は、「カスタム監査パブリッシャーの開発」を参照してください。

この節では、次のトピックについて説明します。

• 「カスタム監査パブリッシャーを有効にする」

• 「コンソール、ファイル、JDBC、およびスクリプトのパブリッシャータイプ」

• 「JMS パブリッシャータイプ」

• 「JMX パブリッシャータイプ」

カスタム監査パブリッシャーを有効にする

カスタム監査パブリッシャーは「監査設定」ページから有効にします。

1. 管理者インタフェースのメインメニューで「設定」をクリックし、二次的なメニューで「監査」をクリックします。

   「監査設定」ページが開きます。

2. ページの下にある「カスタムパブリッシャーの使用」オプションを選択します。

   現在設定されている監査パブリッシャーの一覧表が表示されます。

3. 新しい監査パブリッシャーを設定するには、「新規パブリッシャー」ドロップダウンメニューからカスタムパブリッシャータイプを選択します。

   「新規監査パブリッシャーの設定」フォームに入力します。「OK」をクリックします。

4. 重要: 「保存」をクリックして、新しい監査パブリッシャーを保存してください。

コンソール、ファイル、JDBC、およびスクリプトのパブリッシャータイプ

コンソール、ファイル、JDBC、またはスクリプトの監査パブリッシャーを有効にする場合は、「カスタム監査パブリッシャーを有効にする」の手順に従ってください。「新規パブリッシャー」ドロップダウンメニューから適切なパブリッシャータイプを選択します。

「新規監査パブリッシャーの設定」フォームに入力します。このフォームの詳細については、i-Helps およびオンラインヘルプを参照してください。

• コンソール監査パブリッシャーは、監査イベントを標準出力または標準エラーに出力します。

• ファイル監査パブリッシャーは、監査イベントをフラットファイルに書き込みます。

• JDBC 監査パブリッシャーは、監査イベントを JDBC データストアに記録します。

• スクリプト監査パブリッシャーでは、JavaScript または BeanShell で記述したカスタムスクリプトで監査イベントを格納できます。

JMS パブリッシャータイプ

JMS 監査ログカスタムパブリッシャーでは、JMS (Java Message Service) キューまたはトピックに監査イベントレコードをパブリッシュできます。

JMS の利点

JMS にパブリッシュすると、Identity Manager サーバーが複数ある環境でより柔軟な相関を実現できます。加えて、JMS はファイル監査ログパブリッシャーの使用が制限される状況でも使用できます。 たとえば、Windows 環境では、サーバーの稼動中にクライアントのレポートツールからログにアクセスできない場合があります。

複数サーバー環境での JMS の利点は次のとおりです。

• JMS のメッセージストアにより、メッセージ記憶領域と検索が一元化および単純化される。

• JMS アーキテクチャーは、サービスにアクセス可能なクライアント数に制限がない。

• JMS プロトコルはファイアウォールその他のネットワークインフラストラクチャーを通過しやすい。

ポイントツーポイントとパブリッシュ/サブスクライブ

Java Message System は 2 つのメッセージングモデルを提供します。ポイントツーポイントのキューイングモデルと、パブリッシュ/サブスクライブのトピックモデルです。Identity Manager は両方のモデルをサポートします。

ポイントツーポイントモデルでは、「プロデューサ」が特定のキューにメッセージを送信し、「コンシューマ」がキューからメッセージを読み取ります。この場合、プロデューサはメッセージの宛先を知っており、メッセージをコンシューマのキューに直接送信します。

ポイントツーポイントモデルの特性は次のとおりです。

• 1 つのコンシューマのみがメッセージを取得する。

• プロデューサは受信側がメッセージを読み取るときに稼動している必要はなく、受信側もメッセージの送信時に稼動している必要はない。

• 正常に処理されたすべてのメッセージの確認応答が受信側で行われる。

これに対し、パブリッシュ/サブスクライブモデルでは、特定のメッセージ「トピック」へのメッセージのパブリッシュをサポートします。0 個以上のサブスクライバが、特定のメッセージトピックのメッセージを受信対象とするための登録を行えます。このモデルでは、パブリッシャーもサブスクライバも互いを認識しません。このモデルの例として、匿名の掲示板があります。

パブリッシュ/サブスクライブモデルの特性は次のとおりです。

• 複数のコンシューマがメッセージを受信できる。

• パブリッシャーとサブスクライバの間に時間的な依存関係が存在する。クライアントがサブスクライブする前に、パブリッシャーでサブスクリプションを作成する必要があります。一度サブスクライブすると、永続サブスクリプションが確立されないかぎり、サブスクライバはメッセージを受信するためにアクティブであり続けます。永続サブスクリプションの場合は、サブスクライバが未接続の間にパブリッシュされたメッセージが、サブスクライバの再接続時に再配信されます。

JMS の詳細については、http://www.sun.com/software/products/message_queue/index.xml を参照してください。

JMS パブリッシャータイプの設定

JMS パブリッシャーでは、監査イベントが JMS テキストメッセージにフォーマットされます。次にこれらのテキストメッセージが、設定に応じてキューまたはトピックに送信されます。テキストメッセージは、設定に応じて XML または Universal Logging Format (ULF) としてフォーマットできます。

JMS パブリッシャータイプを有効にするには、「カスタム監査パブリッシャーを有効にする」の手順に従って、「新規パブリッシャー」ドロップダウンメニューから「JMS」を選択します。

JMS パブリッシャータイプを設定するには、「新規監査パブリッシャーの設定」フォームに入力します。このフォームの詳細については、i-Helps およびオンラインヘルプを参照してください。

JMX パブリッシャータイプ

JMX 監査ログパブリッシャーは、JMX (Java Management Extensions) クライアントで Identity Manager の監査ログアクティビティーを監視できるように、監査イベントをパブリッシュします。

JMX の説明

JMX (Java Management Extensions) は、アプリケーション、システムオブジェクト、デバイス、およびサービス指向ネットワークの管理や監視を可能にする Java テクノロジです。管理/監視対象のエンティティーは、MBean (Managed Bean) と呼ばれるオブジェクトによって表されます。

Identity Manager の JMX パブリッシャー実装

Identity Manager の JMX 監査ログパブリッシャーでは、イベントの監査ログを監視します。イベントが検出されると、監査イベントレコードが JMX パブリッシャーによって MBean でラップされ、メモリーに保持されている一時履歴も更新されます。JMX クライアントには、イベントごとに個別の短い通知が送信されます。そのイベントが処理対象の場合、JMX クライアントから監査イベントをラップしている MBean に問い合わせを行なって詳細な情報を取得できます。

監査イベントレコードの詳細については、com.waveset.object.AuditEvent Javadoc を参照してください。Javadoc は REF キットから入手できます。REF キットについては、「カスタム監査パブリッシャーの開発」を参照してください。

適切な MBean から情報を取得するには、履歴シーケンス番号が必要です。この番号はイベント通知に含まれています。

各イベント通知に含まれる情報は次のとおりです。

• 種類。イベントの種類を示す文字列。文字列は、AuditEvent.<ObjectType>.<Action> の形式に従います。ObjectType および Action は、com.waveset.AuditEvent から返されます。たとえば、ロック解除イベントが送信されると、種類は AuditEvent.LighthouseAccount.Unlock となります。

• シーケンス番号。MBean への情報の問い合わせに使用する履歴バッファーキー。

JMX パブリッシャータイプを設定する

1. JMX パブリッシャータイプを有効にするには、「カスタム監査パブリッシャーを有効にする」の手順に従って、「新規パブリッシャー」ドロップダウンメニューから「JMX」を選択します。

2. JMX パブリッシャータイプを設定するには、「新規監査パブリッシャーの設定」フォームに入力します。このフォームの詳細については、i-Helps およびオンラインヘルプを参照してください。

   • 「パブリッシャー名」。JMX 監査イベントパブリッシャーの一意の名前を入力します。

   • 「履歴制限」。必要に応じてデフォルト値を変更し、パブリッシャーがメモリーに保持するイベント項目の数を指定します (デフォルトは 100)。

3. 「テスト」をクリックして、「パブリッシャー名」が使用可能であることを確認します。

4. 「OK」をクリックします。「新規監査パブリッシャーの設定」フォームが閉じます。

5. 重要: 「保存」をクリックします。

JMX クライアントを使用した監査イベントの表示

JMX パブリッシャーの表示には JMX クライアントを使用します。次のスクリーンショットの作成では、JDK 1.5 に含まれている JConsole を使用しました。

JConsole を使用する場合は、IDM:type=AuditLog MBean を表示するプロセスへの接続を指定します。JConsole を JMX クライアントとして使用する場合の設定方法については、『Sun Identity Manager 8.1 System Administrator’s Guide』の「Viewing JMX Data」を参照してください。

JConsole の「通知」タブをクリックして監査イベントを表示します。通知のシーケンス番号に注意してください。シーケンス番号は、MBean に詳細な情報を問い合わせる際に必要です。

図 10–1 JConsole による JMX 監査イベント通知の表示

MBean への詳細情報の問い合わせ

JConsole の「Operations」タブをクリックします。通知のシーケンス番号を使用して、イベントの詳細を MBean に照会します。各操作の先頭に「get」が付加され、「シーケンス」番号が唯一のパラメータになります。

図 10–2 JConsole による MBean への詳細情報の問い合わせ

MBean は、com.waveset.object.AuditEvent クラスに 1 対 1 でマッピングされます。表 10–19 に、MBean が提供する各属性と操作の説明を示します。

Jconsole で、「属性」タブをクリックします。属性の先頭に Current が付加され、システムに送信された最新の監査イベントがその属性に含まれていることを示します。

図 10–3 JConsole による MBean 属性の表示

カスタム監査パブリッシャーの開発

この節では、新しいカスタム監査パブリッシャーを Java で作成する方法を説明します。

Identity Manager が提供するコンソール、ファイル、および JDBC のカスタムパブリッシャーは、AuditLogPublisher インタフェースを実装します。これらのパブリッシャーのソースコードは REF キットにあります。REF キットでは、Javadoc 形式で記されたインタフェースのマニュアルも用意されています。(インタフェースの詳細については、Javadoc を参照してください。

REF (Resource Extension Facility) キットは、製品 CD の /REF ディレクトリまたはインストールイメージにあります。

開発者には、AbstractAuditLogPublisher クラスを拡張するようにお勧めします。このクラスは設定を解析し、すべての必要なオプションがパブリッシャーに用意されていることを確認します。(REF キットのパブリッシャーの例を参照してください。

パブリッシャーには no-arg コンストラクタが必要になります。

パブリッシャーのライフサイクル

パブリッシャーのライフサイクルを、次の手順で説明します。

1. オブジェクトがインスタンス化されます。

2. setFormatter() メソッドを使用して、フォーマッタ (存在する場合) が設定されます。

3. オプションは、configure( Map) メソッドを使用して指定します。

4. イベントは、publish( Map, LoggingErrorHandler) メソッドを使用してパブリッシュされます。

5. shutdown() メソッドを使用して、パブリッシャーが終了します。

手順 1 ～ 3 は、Identity Manager の起動時と監査設定の更新ごとに実行されます。シャットダウンが呼び出される前に監査イベントが生成されていない場合には、手順 4 は行われません。

configure(Map) は、同じパブリッシャーオブジェクトに対して一度だけ呼び出されます。パブリッシャーは、実行時の設定変更に備える必要はありません。監査設定が更新されると、まず現在のパブリッシャーが停止され、新しいパブリッシャーが作成されます。

手順 3 の configure() メソッドは、WavesetException をスローする場合があります。この場合、パブリッシャーは無視され、パブリッシャーに対してほかの呼び出しは行われません。

パブリッシャーの設定

パブリッシャーにはオプションを付けないことも、1 つ以上のオプションを付けることもできます。getConfigurationOptions() メソッドは、パブリッシャーがサポートするオプションのリストを返します。オプションは、PublisherOption クラス (クラスの詳細については Javadoc を参照) を使用してカプセル化されます。監査設定ビューアは、パブリッシャー用の設定インタフェースを構築するときに、このメソッドを呼び出します。

Identity Manager は、サーバーの起動時と監査設定の変更後に、configure( Map) メソッドを使用してパブリッシャーを設定します。

フォーマッタの開発

REF キットには、次のフォーマッタのソースコードが収められています。

• XmlFormatter。監査イベントを XML 文字列としてフォーマットします。

• UlfFormatter。汎用ログ形式 (ULF) に従って、監査イベントをフォーマットします。Sun Application Server はこの形式を使用します。

フォーマッタは、AuditRecordFormatter インタフェースを実装する必要があります。さらに、フォーマッタには no-arg コンストラクタが必要になります。詳細については、REF キットに収録された Javadoc を参照してください。

パブリッシャー/フォーマッタの登録

#ID#Configuration:SystemConfiguration オブジェクトの監査属性は、登録済みのパブリッシャーとフォーマッタをすべて一覧表示します。これらのパブリッシャーとフォーマッタだけが、監査設定ユーザーインタフェースで使用できます。