14 監査の構成と管理

この章では、日常的な監査管理タスクの実行方法を説明します。

関連項目: Oracle Fusion Middlewareでの監査の予備知識については、第13章「Oracle Fusion Middleware監査サービスの概要」を参照してください。

• 監査管理タスクの理解

• 監査データ・ストアの管理

• 監査ポリシーの管理

• 監査のタイムスタンプの理解

• 監査ログとバスストップ・ファイルについて

• データベース・ストアの拡張管理

• 監査イベント定義の管理のベスト・プラクティス

14.1 監査管理タスクの理解

監査管理者は、次の手順に従って、サイトの監査の設定を注意深く計画する必要があります。

• 実装の計画

  これには、監査レコード用に使用するストアのタイプやデータ・ストアの詳細構成などの計画が含まれます。

  詳細は、第14.2項「監査データ・ストアの管理」を参照してください。

• ポリシー管理

  必要な監査イベントが確実に生成されるように、適切な監査ポリシーを構成する必要があります。

  アプリケーション環境の変化やコンポーネントおよびユーザーの追加などを監査ポリシーに反映する必要があるため、ポリシー管理は継続的なアクティビティになります。

  詳細は、第14.3項「監査ポリシーの管理」を参照してください。

• レポート管理

  これには、監査レポートと監査問合せの計画と構成が含まれます。

  詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

• データ管理

  これには、企業ポリシーに基づいた、生成される監査データの格納に必要なデータベース・サイズの計画/増加、監査データのバックアップ、監査データの消去が含まれます。

  監査データ・ストアの管理の詳細は、第14.6項「データベース・ストアの拡張管理」を参照してください。

14.2 監査データ・ストアの管理

本番環境では、データベース監査ストアが監査レコードの格納に必要なスケーラビリティと高可用性を提供します。

さらに、データベースに存在する監査データ・ストアでは、問合せツールやレポート・ツールを使用して監査データを表示できます。

この項では、監査データ・ストアの次のような管理タスクについて詳細に説明します。

• 監査スキーマについて

• 監査データ・ソースについて

• バスストップ・ファイルのチューニング

• スタンドアロン監査ローダーの構成

14.2.1 監査スキーマについて

監査スキーマ(IAUスキーマ)は監査レコードを格納するためのデータベース構造で、セキュリティ・ストア(OPSSスキーマ)とともに作成されます。

セキュリティ・スキーマ作成の詳細は、第9章「OPSSセキュリティ・ストアの構成」を参照してください。

注意: バスストップ・ファイルは、データベース記憶域が存在しない場合の監査レコードの格納先になります。

データベース・スキーマの作成後、ドメイン構成を更新して、監査レコード用の監査データ・ストアを切り替えることができます。

14.2.2 監査データ・ソースについて

WebLogic Serverでデータベース接続を構成するには、データ・ソースをWebLogicドメインに追加します。WebLogic JDBCデータ・ソースにより、データベースへのアクセスおよびデータベース接続管理が可能になります。

第14.2.1項で説明されているとおり、ドメイン作成により、データベースに監査レコードを格納するために必要なデータ構造、監査スキーマが生成されます。また、監査スキーマを指し示すOracle WebLogic Server監査データ・ソースも設定されます。したがって、この監査データ・ソースにより、ユーザーはデータベース内の監査レコードに直接問合せ、レポートを作成できるようになります。

OPSSコンテキストでのドメイン作成の詳細は、第7.3項「FMWドメインの作成」を参照してください。

14.2.3 バスストップ・ファイルのチューニング

バスストップ・ファイルが一定のサイズに到達し、すべてのデータがデータベースにアップロードされると、監査ローダーはこのファイルをオペレーティング・システムから削除します。バスストップ・ファイルを効果的に管理するには、このファイルをチューニングします。

この項では、監査レコードを格納するバスストップ・ファイルの管理に関連する次のトピックを説明します。

• バスストップ・ファイルの場所

• ファイル・サイズ

注意: 監査ファイルを手動で消去して領域を解放することは、お薦めしません。かわりに、後述のようなファイルのサイズ調整機能を使用して、領域を制御してください。

14.2.3.1 バスストップ・ファイルの位置

Javaコンポーネント用のバスストップ・ファイルは、次の場所にあります。

$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type 

システム・コンポーネント用のバスストップ・ファイルは、次の場所にあります。

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

14.2.3.2 バスストップ・ファイルのサイズ指定

Javaコンポーネント

ファイル記憶域モードのファイルのサイズは、構成ファイルjps-config.xmlで示されているaudit.maxFileSizeプロパティを使用して管理できます。このプロパティは、Javaコンポーネントのバスストップ・ファイルの最大サイズを制御します。

サイズはバイト単位で指定します。

システム・コンポーネント

バスストップ・ファイルのサイズはauditconfig.xmlファイルで設定します。例:

<serviceInstance name="audit" provider="audit.provider">
      <property name="audit.maxFileSize" value="10240" />      
      <property name=" audit.loader.repositoryType " value="Db" />      
   </serviceInstance>

注意: 監査データをファイルからデータベース・ストアに切り替えると、監査ファイルに収集されたすべてのイベントがデータベース表にプッシュされ、監査ファイルが削除されます。

14.2.4 スタンドアロン監査ローダーの構成

図13-1に示すように、共通監査フレームワークの監査ローダーは、レコードをバスストップ・ファイルから監査データ・ストアに移動します。監査ローダーを駆動するメカニズムは、アプリケーション環境に応じて変わります。

• Oracle WebLogic ServerにデプロイされたJava EEコンポーネントおよびアプリケーションでは、アプリケーション・サーバーによって提供された監査ローダー機能を使用します。スタンドアロン監査ローダーを実行できますが、これはJavaEE環境では必要ありません。

• システム・コンポーネントおよび非Javaアプリケーションでは、StandAloneAuditLoader javaコマンドによって提供された監査ローダー機能を使用します。

• アプリケーション・サーバー・コンテナの外部で実行されたJava SEアプリケーションでは、スタンドアロン監査ローダーも使用します。

この項では、スタンドアロン監査ローダーの設定および実行方法を説明します。

• 環境の構成

• スタンドアロン監査ローダーの実行

14.2.4.1 環境の構成

スタンドアロン監査ローダーを実行する前に、a) 特定のプロパティの構成、およびb) データベース・スキーマ・ユーザーのパスワードがシークレット・ストアに存在することの確認を行う必要があります。

14.2.4.1.1 監査ローダーで使用されるプロパティの構成

次のプロパティを構成する必要があります。

• ORACLE_HOME環境変数。Oracleホームのフルパスに設定します。

• COMMON_COMPONENTS_HOME環境変数。Java Required File (JRF)が保存されている場所を設定します。

• ORACLE_INSTANCE環境変数。Oracleインスタンスのフルパスに設定します。

• auditloader.jdbcStringシステム・プロパティ。監査データが存在するデータベースへのJDBC接続文字列に設定します。

• auditloader.usernameシステム・プロパティ。監査ローダーを実行できるユーザーのユーザー名に設定します。

14.2.4.1.2 データベース・スキーマ・ユーザーのパスワードの格納

データベース・スキーマ・ユーザーのパスワードは、シークレット・ストアに格納されます。パスワードの格納は、javaのStandAloneAuditLoaderコマンドを-Dstore.password=trueプロパティ付きで使用する1回かぎりの操作です。

次のようにStandAloneAuditLoaderコマンドを発行してパスワードを格納します。

$JDK_HOME/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.1.3/jps-manifest.jar -Doracle.home=$ORACLE_INSTANCE -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=username oracle.security.audit.ajl.loader.StandaloneAuditLoader

パスワードを要求されます。

注意: クラスパスの指定には空白文字を使用しないでください。

このコマンドにより、cwallet.ssoファイルが生成されます。

14.2.4.2 スタンドアロン監査ローダーの実行

次のようにStandAloneAuditLoaderコマンドを発行して監査レコードをロードします。

$JDK_HOME/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.1.3/jps-manifest.jar -Doracle.home=$ORACLE_INSTANCE -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=username oracle.security.audit.ajl.loader.StandaloneAuditLoader

監査レコードを監査データ・ストアに定期的にアップロードするように、バッチ・ジョブまたはkronジョブによってこのコマンドをスケジュールできます。

14.3 監査ポリシーの管理

監査ポリシーとは

監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

たとえば、監査ポリシーでは、Oracle Internet Directoryインスタンスに対するすべての認証の失敗を監査するように指定することができます。

ポリシーの構成方法

Oracle Fusion Middleware監査フレームワークを使用すると、監査ポリシーを構成し、監視対象のイベントおよびデータのタイプをきわめて詳細に制御することができます。Oracle Enterprise Manager Fusion Middleware Control UIツールまたはWLSTコマンドを使用して、ポリシーを構成できます。

ポリシーの変更にはサーバーまたはインスタンスの再起動は不要です。

この項の残りの部分では、監査ポリシーの表示および更新方法を説明します。

• Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理

• Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理

• コマンド・ライン(WLST)での監査ポリシーの管理

• APIプログラミングを介した監査ポリシーの管理

関連項目: 補足的な予備知識については、第13.3.2項「監査に関する重要な技術的概念の理解」を参照してください。 Javaコンポーネントおよびシステム・コンポーネントのリストは、付録Cを参照してください。

14.3.1 Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理

ドメインの「監査ポリシー設定」ページでは、Oracle Access ManagerなどのすべてのJavaコンポーネントの監査イベントと、Oracle Platform Security Servicesなどのシステム・ライブラリの監査イベントを管理します。

注意: システム・コンポーネントの監査ポリシーは、該当するコンポーネントのホーム・ページで管理されます。第14.3.2項「Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理」を参照してください。 第14.3項「監査ポリシーの管理」の最初にある「ポリシーの変更にはサーバーまたはインスタンスの再起動が必要」というタイトルの注意を参照してください。

関連項目: 監査可能なコンポーネントのリストは、第C.1.1項「監査可能なコンポーネント」を参照してください。

現在構成されている監査ポリシーを表示および更新するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 左側のトポロジ・パネルを使用して、「WebLogicドメイン」の下の目的のドメインに移動します。

3. ドメイン・メニューから、「ドメイン」→「セキュリティ」→「監査ポリシー」に移動します。「監査ポリシー」ページが表示されます。

4. 「監査コンポーネント名」ドロップダウン・リストを使用して、構成したい監査ポリシーがあるJavaコンポーネントを選択します。

   
   

   コンポーネントを選択すると、そのコンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」というページ領域に表示されます。Oracle Access Managerの場合の例を示します。

   
   

5. 「監査レベル」ドロップダウン・リストを使用して、そのコンポーネントの監査イベントのサブセットを選択します。次の選択肢があります。

   
   

   • なし - イベント・カテゴリは選択されません。

   • 低、中、高 - 監査の事前定義済レベルを表すイベント・カテゴリのサブセット。

   • カスタム - カスタムのフィルタ定義を作成または変更できます。

   選択するレベルに応じて、「監査用に選択」列にチェック・フラグが表示されます。選択されたカテゴリのイベントが監査されます。Oracle Access Managerの「中」レベルの例を示します。

   
   

   フラグ付きのカテゴリが監査用に選択されています。フラグ付きカテゴリ内のイベントを確認するには、カテゴリ表でその行をクリックします。たとえば、「OAMサーバー」カテゴリをクリックすると、下部に次のようなイベント表が生成されます。

   
   
   
   

   注意: イベントの表はカスタム・レベルでのみ編集できます。事前定義済レベルでは編集できません。

   
   

6. 多くの場合、事前定義済レベルで十分ですが、コンポーネントの監査ポリシーの微調整が必要な場合もあります。

   監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより事前定義済カテゴリは保持されたまま、チェック・ボックスとして緑色のチェックマークが表示され、すべてのカテゴリの選択が可能になります。

   
   

   目的のカテゴリとイベントを選択して監査ポリシーを微調整できます。たとえば、「サーバー」カテゴリで、失敗した認証試行のみを監査したい場合があります。

   
   

7. フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。ポリシーをさらに微調整して、失敗した認証試行のタイプを絞り込んで監査する場合の例を示します。

   「フィルタの編集」列の鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。アイコンをクリックし、「フィルタの編集」ダイアログを表示します。

   
   

   「条件」ボックスを使用して、フィルタ条件、演算子および値で構成されるフィルタを指定します。条件を指定したら、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックして変更を保存します。

   この例では、保護されたアプリケーションをホストするサーバーの名前がmyhost1の場合のみ、失敗した認証試行が監査イベントをトリガーします。

   
   
   
   

   注意: 各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。

   
   

8. インポート/エクスポート - これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。

9. オプションで、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。

   
   
   
   

   注意: この機能を使用して、システム管理者などの主要ユーザーを監査するようにした場合は、そのユーザーがどのコンポーネントの監査可能イベントに関与しても監査トラフィックが発生します。たとえば、コンポーネントの監査ポリシーが「なし」に設定されている場合もありますが、該当するユーザーがコンポーネント・インスタンス内のアクティビティを実行すると、それも監査の対象となります。 このフィールドに入力するユーザー名は検証されません。

   
   

10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。Javaコンポーネントの場合、この変更を有効にするには、管理対象Oracle WebLogic Server(影響を受けるJavaコンポーネントが実行されている)を再起動する必要があります。事前定義済のリフレッシュ間隔(デフォルトは10分)の後で、変更が有効になります。

    ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。

コンポーネント・イベントについて

ドメイン内の各コンポーネントおよびアプリケーションでは、監査可能なイベントの独自のセットを定義します。そのため、表の「名前」列を開くと、コンポーネントごとにそのコンポーネントのインスタンスに適用されるイベントのリストが表示されます。

14.3.2 Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理

この項では、システム・コンポーネントに対する監査ポリシーの表示方法および更新方法について説明します。

注意: Javaコンポーネントの監査ポリシーは、ドメイン・コンテキスト内で管理されます。第14.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。 第14.3項「監査ポリシーの管理」の最初にある「ポリシーの変更にはサーバーまたはインスタンスの再起動が必要」というタイトルの注意を参照してください。Oracle Internet Directoryインスタンスの場合、再起動は不要です。

システム・コンポーネントの監査ポリシーは、それぞれのホーム・ページで管理されます。ドメインの「監査ポリシー設定」ページでは、ドメイン内で実行されるJavaコンポーネントの監査イベントを管理します。

関連項目: 監査可能なコンポーネントのリストは、第C.1.1項「監査可能なコンポーネント」を参照してください。

イベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。

システム・コンポーネントの監査ポリシーを表示および更新するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 左側のトポロジ・パネルを使用して、Oracle HTTP Serverなど、目的のシステム・コンポーネントに移動します。

3. コンポーネント・メニューから、「セキュリティ」→「監査ポリシー」とナビゲートします。「監査ポリシー設定」ページが表示されます。

4. 事前構成済監査レベルのドロップダウン・リストから選択できます。3つの事前定義済レベル(「低」、「中」、高)では、コンポーネントの監査イベントのサブセットを自動的に選択します。

   
   
   
   

   注意: 事前定義済レベルについて、ドロップダウン・ボックスの下のイベント選択を編集することはできません。カスタム・レベルでの編集のみが可能です。

   
   

   • なし - 監査対象のイベントは選択されません。

   • 低 - 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。

   • 中または高 - より大きなイベントのセット。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。

   • カスタム - このレベルではポリシーを微調整できます。後述のステップ5を参照してください。

   次の表は、コンポーネント・インスタンスに対して監査できるイベントを示しています。Oracle HTTP Serverの例を示します。

   
   

   表は、次の列から構成されています。

   • 名前 - タイプ別にまとめられたコンポーネント・イベント(認可イベントなど)が表示されます。

   • 監査の有効化 - 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。

   • フィルタ - イベント・タイプで有効なフィルタが表示されます。

5. 監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これによって、イベント・カテゴリの選択、開始、カスタマイズするカテゴリの「監査用に選択」ボックスのチェックが可能になります。

   2つ目の表は各カテゴリのイベントを一覧表示しており、個々のイベント結果(成功および失敗)に対して追加のフィルタを使用して監査方法をより詳細に制御できます。手順6に示すように、フィルタを微調整できます。

6. フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。

   鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。

   
   

   鉛筆アイコンをクリックし、「フィルタの編集」ダイアログを表示します。

   
   
   
   

   注意: 各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。

   
   

7. 「障害のみ選択」をクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。

8. インポート/エクスポート - これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。

9. オプションで、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。

   
   
   
   

   注意: この機能を使用して、システム管理者などの主要ユーザーを監査するようにした場合は、そのユーザーがどのコンポーネントの監査可能イベントに関与しても監査トラフィックが発生します。たとえば、コンポーネントの監査ポリシーが「なし」に設定されている場合もありますが、該当するユーザーがコンポーネント・インスタンス内のアクティビティを実行すると、それも監査の対象となります。 このフィールドに入力するユーザー名に対する検証は行われません。

   
   

10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。

    ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。

14.3.3 コマンド・ライン(WLST)での監査ポリシーの管理

この項では、Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーの表示や更新を実行する方法を説明します。

• コマンド・ライン(WLST)での監査ポリシーの表示

• コマンド・ライン(WLST)での監査ポリシーの更新

• 例1: WLSTを使用したユーザーに対する監査ポリシーの構成

• 例2: WLSTを使用したイベントに対する監査ポリシーの構成

• 監査レベルを変更するとカスタム構成はどうなるか

注意: WLSTの監査コマンドを実行するには、Oracle共通ホームからWLSTスクリプトを呼び出します。詳細は、『Oracle Fusion Middlewareの管理』のカスタムWLSTコマンドの使用に関する説明を参照してください。

14.3.3.1 コマンド・ライン(WLST)での監査ポリシーの表示

コマンド・ラインに監査ポリシーを表示するには、次の手順を実行します。

注意: ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびツールを起動する様々なオプションについては、『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)の使用の開始に関する説明を参照してください。

• 次のコマンドを使用して、WebLogicサーバーに接続します。

  >java weblogic.WLST
  >connect('userName', 'userPassword', 'url', 'adminServerName')
  

• getAuditPolicyコマンドを使用して、監査ポリシーの構成を表示します。たとえば、次のコマンドは、ドメイン・レベルで設定された監査ポリシーを表示します。

  wls:/mydomain/serverConfig> getAuditPolicy()
  

  次のコマンドでは、特定のコンポーネントの監査ポリシーが表示されます。

  wls:/mydomain/serverConfig> getAuditPolicy(componentType="JPS")
  

• システム・コンポーネントの場合:

  • getNonJava EEAuditMBeanNameコマンドを使用してMBean名を取得します。詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

  • getAuditPolicyコマンドを使用してMBean名を含め、監査ポリシーの構成を表示します。例:

    wls:/mydomain/serverConfig> getAuditPolicy
     (on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")
    

14.3.3.2 コマンド・ライン(WLST)での監査ポリシーの更新

Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーを更新するには、次の手順を実行します。

注意: ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびツールを起動する様々なオプションについては、『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)の使用の開始に関する説明を参照してください。

• 次のコマンドを使用して、WebLogicサーバーに接続します。

  >java weblogic.WLST
  >connect('userName', 'userPassword', 'url', 'adminServerName')
  

• Bean階層を移動し、目的のドメインにアクセスします。たとえば、ドメインがmydomainという名前の場合は、次のようになります。

  wls:/mydomain/serverConfig>
  

• setAuditPolicyコマンドを使用して、監査ポリシーの構成を更新します。

• ポリシーをローカルで管理するコンポーネントの場合は、setAuditPolicyコマンドを使用し、MBean名を含めると、監査ポリシーの構成が更新されます。監査MBeanの名前の書式は次のとおりです。

  oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=INSTANCE,component=COMPONENT_NAME
  

  例:

  oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=instance1,component=oid1
  

• Oracle HTTP ServerやOracle Internet Directoryのようなシステム・コンポーネントについては、setAuditPolicyまたはimportAuditConfigコマンドの実行後、明示的にsaveを呼び出します。

  saveを呼び出さないと、新しい設定が有効になりません。

  次の例では、ツリーのルート、Proxy MBeanに移動し、invokeコマンドを使用してsetAuditPolicyとsaveを順に呼び出します。

  ORACLE_COMMON_HOME/common/bin/wlst.sh
  connect('username', 'password', 'protocol://localhost:7001', 'localhost:7001')
  custom()
  cd('oracle.as.management.mbeans.register')
  cd('oracle.as.management.mbeans.register:type=component,name=oid1,instance=instance1')
  invoke('load',jarray.array([],java.lang.Object),jarray.array([],
  java.lang.String)) 
  setAuditPolicy(filterPreset='None',
   on='oracle.as.management.mbeans.register:type=component.auditconfig,
   name=auditconfig1,instance=instance1,component=oid1')
  invoke('save',jarray.array([],java.lang.Object),jarray.array([],
  java.lang.String))
  

  JavaEEコンポーネントではこの手順は必要ありません。

14.3.3.3 例1: WLSTを使用したユーザーに対する監査ポリシーの構成

このシナリオでは、ドメインの現在のポリシーにより、user1というユーザーが監査されています。管理者は、常に監査対象とするユーザーのリストに2つの名前(user2およびuser3)を追加し、リストからuser1を削除します。

このタスクは、setAuditPolicyを次のように起動して実行します。

setAuditPolicy
   (filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")

関連項目: 付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

14.3.3.4 例2: WLSTを使用したイベントに対する監査ポリシーの構成

このシナリオでは、ドメインの現在のポリシーにより、ユーザーのログアウト・イベントが監査されています。管理者は、ポリシーからログアウト・イベントを削除し、ログイン・イベントを監査するようにします。

次のようにOracle HTTP Server (OHS)でsetAuditPolicyを起動すると、このタスクが実行されます。

setAuditPolicy (on="OHS mbean name")
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")

イベントを追加および削除するために、Customフィルタ・プリセットが起動されたことに注意してください。

注意: この例では、Oracle HTTP Serverのコンポーネント・タイプOHSを使用します。コマンドの使用時に、適切なコンポーネント・タイプに置き換えてください。

14.3.3.5 監査レベルを変更するとカスタム構成はどうなるか

カスタム・レベルで監査を構成しているときに、WLSTを使用して別の(カスタムではない)監査レベルに切り替えても、明示的にそれらのカスタム監査設定を削除しないかぎり、そのカスタム監査設定は保持されます。

この動作を示す例は、次のとおりです。

1. カスタム監査レベルはコンポーネントのポリシーに対して設定します。構成の過程で監査フィルタを指定します。

2. 実行時には、指定したフィルタに従って監査データが収集されます。

3. ここで、WLST setAuditPolicyコマンドを使用して、コンポーネントの監査ポリシーがカスタム監査レベルから低監査レベルに変更されます。しかし、カスタム監査レベルの中で設定したフィルタは監査構成にそのまま残ります。

4. 監査データの収集は、カスタム・レベルではなく、低い監査レベルに基づいています。

5. コンポーネントの監査ポリシーはカスタム・レベルに戻されます。その他のフィルタが追加されます。このフィルタは、最初に構成されていたフィルタに追加されます。元のフィルタを明示的に削除しないかぎり、このフィルタは構成の中で保持されます。

6. 実行時には、効力があるすべてのフィルタに基づいてカスタム・レベルで監査データが収集されます。

14.3.4 APIプログラミングを介した監査ポリシーの管理

監査管理サービスは、アプリケーションが監査ポリシーの取得や更新に使用できるAPIを提供します。詳細は、23.5項を参照してください。

14.4 監査のタイムスタンプの理解

11gリリース1 (11.1.1.7)より前のリリースでは、監査サービスはアプリケーション・サーバーのタイムゾーンを使用してデータベース・レコードを書き出していました。11gリリース1 (11.1.1.7)以降、監査サービスはアプリケーション・サーバーと監査データ・ストアに対して異なるタイムゾーンを構成できるようになります。

詳細は、次のとおりです。

• 新しいサイトは、監査イベントが協定世界時(UTC)で書かれているとみなします。

• 11gリリース1 (11.1.1.6)からアップグレードされたサイトは、デフォルトでは、明示的にUTCに切り替えないかぎり監査レコードに対してアプリケーション・サーバーのタイムゾーンを引き続き使用します。

注意: バスストップ・ファイルへのレコードは常にUTCを使用します。

新しいサイトでの監査タイムスタンプ

新しいインストールでは、監査レコードはUTCタイムスタンプを使用します。デフォルトの監査サービス構成のサービス・プロパティ(audit.timezone=utc)にはこの規則が実装されます。

すぐに使用できる監査サービス構成は、次のようになります。

<serviceInstance name="audit" provider="audit.provider"       location="./audit-store.xml">
   <property name="audit.filterPreset" value="None"/>
   <property name="audit.timezone" value="utc" />
   <property name="audit.loader.repositoryType" value="File" />
   <property name="auditstore.type" value="file"/>
</serviceInstance>

アップグレードされたサイトでの監査タイムスタンプ

11g Release 1 (11.1.1.7)以前に存在していた監査レコードでは、アプリケーション・サーバーのタイムスタンプが使用されていました。以前のリリースからアップグレードしても、監査サービスの構成には変化がなく、デフォルトでは、レコードは引き続きアプリケーション・サーバーのタイムスタンプを使用して書き込まれます。

12c (12.1.3)へのアップグレード後にUTCタイムスタンプを使用する場合は、構成ファイルにサービス・プロパティaudit.timezone=utcを追加してUTCの動作を有効にすることができます。

アップグレード後にUTCに切り替える場合は、レポート作成に影響をおよぼす可能性がある潜在的な矛盾を回避するため、まず既存のレコードを移動することをお薦めします。

関連項目: 第F.2.8項

14.5 監査ログとバスストップ・ファイルについて

この項には次のトピックが含まれます:

• 監査ログの場所

• バスストップ・ファイルのタイムスタンプについて

14.5.1監査ログの場所

Fusion Middleware監査フレームワークでは、監査管理に役立つように、一連のログ・ファイルを提供しています。それらのログを使用すると、監査フレームワークが正しく機能しないときに、エラーをトレースしたり、診断を行うことができます。

すべての監査ログの場所のリスト、ロガーの構成方法およびログによる問題の診断方法は、第J.1.1.7項「監査ロガーについて」を参照してください。

14.5.2 バスストップ・ファイルの監査タイムスタンプについて

監査のバスストップ・ファイルのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。

関連項目: 第14.4項

14.6 データベース・ストアの拡張管理

OPSSセキュリティ・スキーマを作成すると、監査スキーマも作成されます。この項では、監査スキーマの編成について説明し、スキーマの管理に関する次のトピックについて説明します。

• 監査スキーマの概要

• 表のサイズ: 実表およびコンポーネント表の属性

• パフォーマンスのチューニング

• バックアップとリカバリのプランニング

• データのインポートおよびエクスポート

• パーティション化

関連項目: RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

14.6.1 監査スキーマの概要

Oracle Fusion Middleware監査フレームワーク・スキーマの共通の表は、次のものから構成されています。

• 実表の基本データ

• IAU_COMMON表の共通属性

• 専用表の汎用属性

• IAU_CUSTOM_nnn表のカスタム属性

一度にすべての表が使用されるわけではありません。一般に、動的メタデータ・モデル(第13.3.1.1項を参照)を使用しているサイトは、共通表およびカスタム表を使用しています。従来のモデルは実表とコンポーネント固有の表を使用しています。

これらの表の詳細は、第13.4項を参照してください。

バスストップ・ファイルについて

デフォルトでは、バスストップ・ファイルは次のディレクトリ内に保持されます。

Weblogic Domain Home/servers/server_name/logs/auditlogs

コンポーネントのサブディレクトリも同時に保持されます。たとえば、Oracle Platform Security Services (OPSS)バスストップ・ファイルは次の場所にあります。

Weblogic Domain Home/servers/server_name/logs/auditlogs/JPS

次に示すのはOPSSのバスストップ・ファイルのサンプルです。

#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key
#Remark Values:ComponentType="JPS"
2008-12-08 10:46:05.492  - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - -

共通表とカスタム表

共通表には監査レコードの基本データが含まれています。この表はIAU_ID属性を通じて、追加のデータを含むカスタム表に関連づけられています。

実表とコンポーネント表

同様に、実表には基本的な監査レコードが含まれています。この表はIAU_ID属性を通じて、追加のデータを含むコンポーネント固有の表に関連づけられています。

14.6.2 表のサイズ: 実表およびコンポーネント表の属性

監査レコードは生成時、1つのファイルに格納されます。監査データベース・ストアが構成されている場合、監査ローダーは各監査レコードを次のように格納します。

• 一般的な情報(Time、EventType、EventStatusなど)は、共通表の1行(動的モデル)または実表に書き込まれます。

• コンポーネント固有の情報(CodeSourceなど)は、カスタム表の1行(動的モデル)またはコンポーネント表に書き込まれます。

基本的な監査レコードの平均レコード・サイズは約0.3 KBです。表領域のサイズを計画する際は、次のようにしてください。

• この数値を、平均的なレコード・サイズのガイドラインとして使用してください。

• 選択した監査ポリシーおよびアクティビティのレベルに基づいて、監査データベースのサイズが増加する様子を監視してください。

• 監査データの格納期間を考慮してください。

実表およびコンポーネントに固有な表の属性はそれぞれ、次のファイルから派生しています。

• $ORACLE_HOME/modules/oracle.iau_12.1.3/components/generic/generic_events.xml
  

  (実表用)

• $ORACLE_HOME/modules/oracle.iau_12.1.3/components/componentName/component_events.xml
  

  (各コンポーネント表用)

表C-6に、実表IAU_BASEで定義されている属性を示します。同様に、表C-7に、共通表IAU_COMMONで定義されている属性を示します。

WLSTコマンドlistAuditEventsを使用すると、各コンポーネント表のすべての属性名のリストを取得することができます。

関連項目: 付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」 第C.2項「監査スキーマ」

14.6.3 パフォーマンス・チューニング

問合せを効率よく実行できるように、デフォルトでは、実表およびコンポーネントに固有の各表のタイムスタンプ(IAU_TSTZORIGINATING)に対して索引が作成されます。

デフォルトの索引は、IAU_BASEの場合はEVENT_TIME_INDEX、コンポーネント表の場合はtableName_INDEX (OVDCOMPONENT_INDEX、OIDCOMPONENT_INDEX、JPS_INDEXなど)です。

追加の索引付き列とその索引は次のとおりです。

• 共通表のTimestamp (IAU_TSTZORIGINATING)。索引DYN_EVENT_TIME_INDEX付き。

• IAU_AuditUser、IAU_ComponentType、IAU_EventCategory、IAU_EventType列。これらはすべて共通表にあります。索引は順にDYN_USER_INDEX、DYN_COMPONENT_TYPE_INDEX、DYN_EVENT_CATEGORY_INDEX、DYN_EVENT_TYPE_INDEXです。

14.6.4 バックアップとリカバリのプランニング

コンプライアンスの規制では、監査データを長期間保存する必要があります。データを保護するには、バックアップおよびリカバリの計画が必要です。

優れたバックアップ計画を作成するには、次のような基本的なガイドラインを考慮します。

• 監査イベントの増加率

  生成される監査イベントの数は、監査ポリシーによって決まります。監査データの消失を最小限に抑えるようバックアップを実行する頻度は、日々生成される監査イベントの数によって決まります。

• コンプライアンスの規制

  バックアップの実行頻度および監査データの必須保存年数は、各組織のコンプライアンス規制を参照して決定してください。

• オンラインおよびオフラインのデータ管理

  バックアップの実行頻度および簡単にアクセスできる必要がある監査データの割合は、各組織のコンプライアンス規制を参照して決定してください。

Oracle Databaseでは、Oracle Recovery Manager (RMAN)を使用してバックアップおよびリカバリを実行します。詳細は、次を参照してください:

http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm

http://www.oracle.com/technology/deploy/availability/htdocs/rman_overview.htm

注意: 変換表IAU_DISP_NAMES_TLは、時間が経過しても変化しないため、バックアップの実行は一度だけで十分です。

14.6.5 データのインポートとエクスポート

複数の監査データベースで開始した後、それらのデータベースを結合して単一の監査データ・ストアを構築する場合や、データベースを変更して規模を拡張する場合は、監査スキーマのインポートおよびエクスポートを実行して、データを移行することができます。

Oracle Databaseサイトでは、Oracle Data Pumpのユーティリティを使用してデータのインポートおよびエクスポートを実行できます。詳細は、次のサイトを参照してください。

http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html

14.6.6 パーティション化

すべてのデータベース・システムでパーティション化がサポートされているわけではなく、監査スキーマ内の表は、デフォルトではすべてパーティション化されていません。

監査データは累積され、古いデータが削除されることはありません。そのため、大量の監査データを格納する場合は、監査スキーマのパーティション化を考慮し、アーカイブ処理を容易にする必要があります。

パーティション化には、次のような利点があります。

• パフォーマンスの向上: 表がタイムスタンプでレンジ・パーティション化されていると、たとえばタイムスタンプによる問合せを処理できるのは、該当する時間枠内のパーティションのみとなります。

• 管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、比較的古いデータは比較的遅くて大きなディスクに移動し、比較的新しいデータは比較的高速で小型のディスクに保持することができます。

  また、パーティション化により、アーカイブ処理もはるかに容易になります。たとえば、表全体をパーティション化することなく、単一のパーティションを圧縮することができます。

• 可用性の拡張: 単一のパーティションが使用できない場合、たとえば問合せでそのパーティションを処理対象から外しても問題がないことが判明しているのであれば、使用できないパーティションを待つことなく、問合せを正常に処理することができます。

14.6.6.1 パーティション表

注意: この説明は11gリリース1 (11.1.1.7)より前のリリースに適用されます。11gの新しいリリース1 (11.1.1.7)のインストールではこれらの表を使用しないでください。

ここの例では、IAU_BASEを例として使用し、監査スキーマ内のパーティション化されていない表をパーティション化された表に変換する方法を示します。

アプリケーションの停止時間を最小化するため、監査データ・ストアにこのスキーマを使用する前にパーティション化を実行することをお薦めします。

注意: この製品には、サンプルのSQLスクリプトが2つ含まれています。 $MW_HOME/oracle_common /common/sql/iau/scripts/convertPartitionedTables.sql (linux)または%MW_HOME\oracle_common \common\sql\iau/scripts\convertPartitionedTables.sql (Windows)では、監査スキーマの実表およびコンポーネント表がパーティション表に変換されます。 $MW_HOME/oracle_common /common/sql/iau/scripts/createPartitionsByQuarter.sql (linux)または%MW_HOME\oracle_common \common\sql\iau/scripts\createPartitionsByQuarter.sql (Windows)では、監査スキーマの実表およびコンポーネント表に対して、四半期のパーティションが作成されます。

パーティション化の手順は、次のとおりです。

1. パーティション化されていない既存の表の名前を変更します。例:

   RENAME IAU_BASE TO IAU_BASE_NONPART;
   

2. パーティション化されていない表の表構造に従う、新しいパーティション化された表を作成します。この例では、タイムスタンプによりレンジ・パーティション化するスキームを使用します。

   CREATE TABLE IAU_BASE
   PARTITION BY RANGE (IAU_TSTZORIGINATING)
   (
       PARTITION IAU_BASE_DEFAULT VALUES LESS THAN (MAXVALUE)
   )
   AS SELECT * FROM IAU_BASE_NONPART;
   

3. 行の移動を有効にし、新しいパーティションの作成時にデータがパーティション間で自動的に移動できるようにします。例:

   ALTER TABLE IAU_BASE
   ENABLE ROW MOVEMENT;
   

4. パーティション表のローカルな接頭辞索引を作成します。例:

   ALTER INDEX EVENT_TIME_INDEX
   RENAME TO EVENT_TIME_INDEX_NONPART;
    
   CREATE INDEX EVENT_TIME_INDEX
   ON IAU_BASE(IAU_TSTZORIGINATING) LOCAL;
   

5. これでパーティションを作成できます。この例では、暦の四半期別にパーティションを作成します。

   ALTER TABLE IAU_BASE
   SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/04/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q1_2008, PARTITION IAU_BASE_DEFAULT)
   UPDATE INDEXES;
    
   ALTER TABLE IAU_BASE
   SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/07/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q2_2008, PARTITION IAU_BASE_DEFAULT)
   UPDATE INDEXES;
    
   ALTER TABLE IAU_BASE
   SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/10/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q3_2008, PARTITION IAU_BASE_DEFAULT)
   UPDATE INDEXES;
    
   ALTER TABLE IAU_BASE
   SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/01/2009', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q4_2008, PARTITION IAU_BASE_DEFAULT)
   UPDATE INDEXES;
   

   
   

   注意: 新しい四半期別に合わせて定期的に、新しいパーティションを作成する必要があります。

   
   

14.6.6.2 パーティション表のバックアップとリカバリ

バックアップとリカバリについては、第14.6.4項「バックアップとリカバリのプランニング」を参照してください。バックアップ・コピーが作成されているかぎり、データベースのバックアップ全体から読取り専用の表領域を除外することができます。そのため、それらの表領域上に存在するアーカイブ・データのパーティションに対するバックアップを反復的に実行する必要がなくなり、パフォーマンスが向上します。

14.6.6.3 データのインポートとエクスポート

インポートとエクスポートについては、第14.6.5項「データのインポートとエクスポート」を参照してください。レンジ・パーティション化された表で旧データを削除する際は、行を個別に削除するよりパーティションを削除した方がはるかに効率的であることを覚えておいてください。

ALTER TABLE IAU_BASE DROP PARTITION IAU_BASE_Q4_2008;

また、表全体を変更することなく新しいデータのパーティションをロードするのも簡単です。ただし、次のようなコマンドを使用して、まず"values less than (MAXVALUE)"のデフォルト・パーティションを削除し、完了後に付加しなおす必要があります。

ALTER TABLE IAU_BASE ADD PARTITION IAU_BASE_Q4_2008 VALUES LESS THAN ('01-JAN-2009');

パーティションを作成したら、特定のパーティションの消去またはバックアップを実行できます。詳細は、14.6.6.4項を参照してください。

データベース・モードの場合、バスストップ・ファイルは監査ローダーによって自動的に管理されます。

14.6.6.4 データのパージ

Oracle Fusion Middleware監査フレームワークでは、監査ストアからのレコードの削除を可能にするSQLスクリプトが提供されています。

スクリプトの場所

削除スクリプトは、次の場所にあります。

[Linux]
$MW_HOME/oracle_common/common/sql/iau/scripts


[Windows]
%MW_HOME\oracle_common\common\sql\iau\scripts

次のスクリプトがこの場所にあります。

• auditDataPurge.sql

• auditDeleteData.sql

• auditReclaimSpace.sql

監査レコードの削除

その他のアクションなしにレコードを削除するには、auditDeleteData.sqlを使用します。このスクリプトは2つのパラメータを使用します。

• 監査スキーマ・ユーザー

• 保持する日数 - 古いレコードは削除されます。

auditDeleteData.sql audit_schema_user number_of_days_to_keep

例:

sqlplus> @auditDeleteData.sql DEV_IAU 100

100日を超過したレコードはすべて削除されます。

データ・ストアでの領域の再要求

領域を再要求するには、auditReclaimSpace.sqlスクリプトを使用します。このスクリプトは、監査スキーマ・ユーザーという1つのパラメータのみを使用します。

@auditReclaimSpace.sql audit_schema_user

例:

sqlplus> @auditReclaimSpace.sql DEV_IAU

レコードの削除と領域の再要求

監査レコードの削除と領域の再要求の両方を実行するには、auditDataPurge.sqlスクリプトを使用します。このスクリプトは2つのパラメータを使用します。

• 監査スキーマ・ユーザー

• 保持する日数 - 古いレコードは削除されます。

@auditDataPurge.sql audit_schema_user number_of_days_to_keep

例:

sqlplus> @auditDataPurge.sql DEV_IAU 100

100日より古いレコードをすべて削除し、領域を小さくするために行の移動を有効にします。

14.6.6.5 階層アーカイブの実行

パーティション化により、それぞれのパーティション(またはパーティションのグループ)を、記憶域の様々な層に格納できます。表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成できます。また、パーティション内のデータを表領域(記憶域の層)間で移動することも容易です。

次に例を示します。

ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008
TABLESPACE AUDITARCHIVE UPDATE INDEXES;

注意: パーティションは、範囲、リスト、システムおよびハッシュのパーティション化スキームでのみ移動できます。

Oracle Information Lifecycle Management (ILM)はパーティション化と圧縮による合理化されたデータ管理を特徴としています。詳細は、次のサイトを参照してください。

http://www.oracle.com/technetwork/database/enterprise-edition/index-090321.html

14.7 監査イベント定義の管理のベスト・プラクティス

この項では、サイトの監査構成を管理し、収集した監査データの価値を最大限生かすためのヒントやコツを説明します。内容は次のとおりです。

14.7.1 一般的なネーミング・ガイドライン

コンポーネントのタイプ、カテゴリ、イベント、属性を含む監査オブジェクトはすべて、このネーミング規則に準拠する必要があります。

• componentType、Category、EventまたはAttributeで使用される名前にはスペースや特殊文字は使用できません。使用できるのは英文字のみです。

• 表示名のみ、スペースを使用できます。

14.7.2 イベントのネーミング

監査イベントに名前を付ける場合は次のガイドラインに従ってください。

• 接頭辞として、あらゆるものにコンポーネント名を付けないでください。

• できるだけ具体的な名前を付けてください。たとえば、HTTP応答コード400、302などを定義する場合は「Response」ではなく「HTTPResponse」を使用します。

• すべてのイベント名の接尾辞に「Event」を付けないでください。たとえば、「AuthenticationEvent」や「PolicyEvent」などのかわりに「Authentication」、「Policy」などを使用します。

14.7.3 イベント粒度の最適化

イベントの粒度を最適化する場合は次のガイドラインに従ってください。

• 操作ごとに異なるイベントを定義するようにします。たとえば、すべてのイベントを「Policy」イベントにまとめて「Operation」属性で区別するのではなく、「PolicyCreate」や「PolicyDelete」のように異なるイベントにします。

• SuccessイベントやFailureイベントを定義しないでください。たとえば、「PolicyCreateSuccess」や「PolicyCreateFailure」を独立したイベントとするかわりに、EventStatus属性を使用して、失敗や成功を記録します。

14.7.4 イベントの分類

イベントを分類する場合は次のガイドラインに従ってください。

• 必要に応じて、システム・カテゴリを参照します。たとえば、「UserSession」や「Authorization」などを参照します。

• 構成操作では、操作のグループを基準にカテゴリを作成します。たとえば、PolicyCreateやPolicyDeleteは、コンポーネント固有のカテゴリ「Policy」に入れます。

14.7.5 汎用属性の使用

汎用属性を使用する場合は次のガイドラインに従ってください。

• 次の主要なイベント属性を持たせるようにします。

  • Initiator - このアクションを実行したユーザー。

  • MessageText - 何が起こったのかについての簡単な説明。「認証イベント」のような変化しないテキストを使用するかわりに、たとえば、「jdoeのログインに成功」のように実際のデータ値を入れ、人間が読んでわかる説明にします。

  • EventStatus - イベントの結果。true (成功)またはfalse (失敗)

  • FailureCode - 失敗の場合、その失敗に該当するエラー・コード。

• また、影響を受けた「オブジェクト」を表すResource属性もよく使用されます。たとえば、アクセス先のURIや付与されたPermissionなどがこれに該当します。必要に応じて、Resourceではなく、独自のカスタム属性を使用することもできます。

14.7.6 コンポーネント属性の使用

最終的には、監査フレームワークは各イベントについて定義された属性すべての和集合をとり、各属性についてデータベース列を定義します。したがって、できるだけ多くの共通属性を定義するようにしてください。

14.7.7 クロスリンク

たとえば、ECID、セッションID、ユーザー名など、コンポーネントにより生成されたイベントを他のイベントとクロスリンクするために十分な情報を入れるようにしてください。