ヘッダーをスキップ
Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド
11g リリース1(11.1.1)
B56235-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

13 監査の構成と管理

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


関連項目:

Oracle Fusion Middlewareでの監査の予備知識については、第12章「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。


13.1 監査管理タスク

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

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

監査フレームワークでは、追加設定なしですぐに、ファイル・システムを使用して監査レコードを格納します。ただし本番環境では、データベース監査データ・ストアを使用して、監査フレームワークのスケーラビリティと高可用性を確保することをお薦めします。

また、データベース内の監査データ・ストアを使用すると、Oracle Business Intelligence Publisherで使用可能な事前パッケージ済の監査レポートにより監査データを表示することができます。Oracle Business Intelligence Publisherは、11g リリース1 (11.1.1)のCDパックで使用できます。

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

13.2.1 RCUによる監査スキーマの作成

監査レコードの永続的ストアとしてデータベースに切り替えるには、最初にリポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・ストアを作成する必要があります。


注意:

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


この項では、監査スキーマの作成方法を説明します。データベース・スキーマの作成後は、次のことが可能になります。


注意:

この説明では、RCUおよびデータベースが環境にインストール済であることを前提としています。詳細は、インストレーション・ガイドを参照してください。


開始する前に

作業を開始する前に、使用するデータベースの詳細情報を収集し、DBA資格証明を入手してください。

データベース・スキーマの構成

監査データ・ストア用のスキーマを構成するには、次の手順を実行します。

  1. $RCU_HOME/binに移動し、RCUユーティリティを実行します。

  2. 開始画面で「作成」を選択します。「次へ」をクリックします。

  3. データベースの詳細情報を入力して、「次へ」をクリックします。

  4. 接頭辞の新規作成を選択して、IDMなどを入力します。

  5. また、スキーマのリストから「監査サービス」を選択します。

  6. 次へ」をクリックして、表領域の作成を承認します。

  7. スキーマの作成中にエラーが発生していないか確認します。

このプロセスの完了には数分かかります。

13.2.2 監査データソースの設定

第13.2.1項「RCUによる監査スキーマの作成」で説明したように、データベースに監査レコードを格納するデータベース・スキーマを作成した後、そのスキーマを指すOracle WebLogic Serverの監査データソースを設定する必要があります。

監査データソースを設定するには、次の手順を実行します。


注意:

このタスクは、Oracle WebLogic Server管理コンソールで実行します。


  1. Oracle WebLogic Server管理コンソールに接続します。

    http://host:7001/console
    
  2. 「JDBC」で、「データソース」リンクをクリックします。

  3. 「データソース」ページが表示されます。「新規」をクリックして新しいデータソースを作成します。

  4. 新しいデータソースに関して、次の詳細情報を入力します。

    • 名前: Audit Data Source-0などの名前を入力します。

    • JNDI名: jdbc/AuditDB。

    • データベースのタイプ: Oracle

    • データベース・ドライバ: Oracleドライバ(Thin XA)バージョン9.0.1、9.0.2、10、11。

    管理対象クラスタ・サーバーにデプロイする場合は、「管理サーバー」も選択します。これにより、ファイルからデータベース・ストアに切り替える際、該当するデータソースが監査データ・ストアに表示されます。

    次へ」をクリックします。

  5. 「トランザクション・オプション」ページが表示されます。「次へ」をクリックします。

  6. 「接続プロパティ」ページが表示されます。次の情報を入力します。

    • データベース名: 接続先のデータベース名を入力します。これは通常SIDに対応します。

    • ホスト名: データベースのホスト名を入力します。

    • ポート: データベース・ポートを入力します。

    • データベース・ユーザー名: RCUで作成した監査スキーマ名です。監査スキーマの場合、接尾辞は常にIAUです。たとえば、接頭辞をtestとした場合、スキーマ名はtest_iauになります。

    • パスワード: RCUで作成した監査スキーマのパスワードです。

    次へ」をクリックします。

  7. 次のページに、JDBCドライバ・クラスとデータベースの詳細情報が表示されます。デフォルトを選択し、「構成のテスト」をクリックして、接続をテストします。「接続は正常に確立されました」というメッセージが表示されたら、「次へ」をクリックします。エラーが表示された場合は、接続の詳細情報に戻って確認します。

  8. 「ターゲットの選択」ページで、このデータソースを構成するサーバーを選択して、「終了」をクリックします。

13.2.2.1 複数のデータソース

スケーラビリティおよび高可用性を実現するために、監査データのOracle Real Application Clustersを構成できます。

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

  • Oracle Fusion Middleware高可用性ガイド』のRACデータベース・ストアを使用した監査の設定に関する項

  • Oracle Fusion Middleware高可用性ガイド』のWebLogic Serverを使用した監査データ・ソースおよびマルチ・データ・ソースの構成に関する項

  • Oracle Fusion Middleware高可用性ガイド』の監査ローダー用JDBC文字列の構成に関する項

  • Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のOracle RACとともに使用するWebLogic Serverの使用に関する項

13.2.3 Javaコンポーネント用のデータベース監査データ・ストアの構成

スキーマの作成後にデータベース・ベースの監査データ・ストアを構成するには、次の作業を行います。

  • 作成した監査スキーマを指し示すデータソースの作成

  • データソースを指し示す監査データ・ストアの構成

この項では、監査データ・ストアの構成に関連する次のタスクを説明します。


注意:

この手順で構成されるのは、Javaコンポーネント用の監査データ・ストアのみです。システム・コンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第13.2.4項「システム・コンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。


13.2.3.1 監査データ・ストアの構成の表示


注意:

このタスクは、Oracle Enterprise Manager Fusion Middleware Controlで実行します。


現在の監査データ・ストアの構成を表示するには、ドメイン→「セキュリティ」→「監査ストア」に移動します。

監査ストアの構成
図audrepos1.gifの説明

このページには、次の項目が表示されます。

  • データベースが監査データ・ストアとして構成されているかどうか。デフォルトでは、データベースは構成されておらず、監査レコードはバスストップ・ファイルに格納されています。

  • データソースのJNDI名: 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソースのJNDI名が表示されます。監査データ・ストアが構成されていない場合、このフィールドは空になります。

  • データソース名: 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソース名が表示されます。監査データ・ストアがファイルベースである場合、このフィールドは表示されません。

  • URL: 監査レコード用にデータベース・リポジトリが構成されている場合は、このフィールドにデータソースのURL(データベースへの接続に使用される接続文字列)が表示されます。監査データ・ストアがファイルベースである場合、このフィールドは表示されません。

データソースの例は、第13.2.2項「監査データソースの設定」を参照してください。

13.2.3.2 監査データ・ストアの構成

監査レコードをファイルに格納する方式からデータベース監査データ・ストアを使用する方式に変更できます。

監査データ・ストアを構成するには、次の手順を実行します。

  1. ドメイン→「セキュリティ」→「監査ストア」に移動します。「監査ストア」ページが表示されます。

  2. 「データソースのJNDI名」フィールドの横にあるサーチライトのアイコンをクリックします。

  3. ダイアログ・ボックスが表示され、ドメイン内で監査レコード用に使用可能なデータソースのリストが表示されます。目的のデータソースを選択して、「OK」をクリックします。

  4. 選択されたデータソースが「データソースのJNDI名」フィールドに表示されます。「適用」をクリックして続行するか、「元に戻す」をクリックして更新を中止します。


    注意:

    監査データ・ストアの設定は、WLST setAuditRepository()コマンドを使用して変更することもできます。詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。


  5. ドメイン内のすべてのOracle WebLogic Serverを再起動します。これにより、Oracle WebLogic Server内の起動クラス監査ローダーが構成を再度読み込むことができます。

  6. 変更は、監査ポリシーでイベント収集のテストを設定することによってテストできます。たとえば、Oracle Platform Security Servicesの監査ポリシーを「中」に設定することもできます。詳細は、第13.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。

  7. 監査によって監査イベントが生成されるように、シナリオを実行します。たとえば、ステップ6で構成したポリシーに基づき、資格証明の作成によって監査レコードがトリガーされます。

  8. サーバー・ログ内のエラーおよび例外をチェックします。

    • $DOMAIN_HOME/jrfServer_admin.outをチェックします。

    • $DOMAIN_HOME/servers/$SERVER_NAME/logs/をチェックします。

13.2.3.3 監査データ・ストアの構成解除

データベースは監査レコードの推奨ストアであるため、データベースからファイル・モードへの切替えはお薦めできません。ただし、第13.3.4項「監査ポリシーの手動による管理」では、audit.repositoryTypeというプロパティの値をFileに設定することで、ファイルに格納する方式に切り替えることができると説明されています。


注意:

Fusion Middleware ControlやWLSTを使用してデータベースからファイル・モードに切り替えることはできません。この切替えを実現するには、第13.3.4項「監査ポリシーの手動による管理」で説明するように、手動による構成が必要です。


データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。

13.2.4 システム・コンポーネント用のデータベース監査データ・ストアの構成

Oracle Process Manager and Notification Server (OPMN)は、Oracle WebLogic Server内で実行されるいくつかのシステム・コンポーネントを管理します。これらのコンポーネントの場合、ローカルなバスストップ・ファイルからデータベース監査データ・ストアに監査イベントがプッシュされるメカニズムは、OPMNによって処理されます。


注意:

システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアを、すべてのインスタンスがレコードを該当ストアにプッシュするよう構成する必要があります。


監査データ・ストアを構成するには、コンポーネントの各インスタンスで、次の手順を実行する必要があります。


注意:

この手順で構成されるのは、システム・コンポーネント用の監査データ・ストアのみです。Javaコンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第13.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。


  1. 次の場所にあるopmn.xmlファイルを開きます。

    $ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml 
    
  2. 次のようなrmd-definitions要素を見つけます。

    <rmd-definitions>
             <rmd name="AuditLoader" interval="15">
                <conditional>
                <![CDATA[({time}>=00:00)]]>
                </conditional>
                <action value="exec $ORACLE_HOME/jdk/bin/java -classpath 
     $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: 
     $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: 
     $ORACLE_HOME/jdbc/lib/ojdbc5.jar: 
     $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: 
     $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar           
                     -Doracle.home=$ORACLE_HOME 
                     -Doracle.instance=$ORACLE_INSTANCE           
                     -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid           
                     -Dauditloader.username=username 
                     oracle.security.audit.ajl.loader.StandaloneAuditLoader"/>
                <exception value="exec /bin/echo 
    PERIODICAL CALL For Audit Loader FAILED"/> </rmd> </rmd-definitions>
  3. 監査ローダーの既存のRMD定義を置き換えます。変更する値は、次のものだけです。

    • jdbcString: これは、データベースJDBC接続文字列です。これをデフォルト文字列から有効な接続文字列に変更します。

    • username

    • interval: 監査レコードは、この間隔(秒)で、コンポーネントのバスストップ・ファイルから監査データ・ストアにプッシュされます。

      デフォルトでは、intervalに非常に大きな値(31536000秒)が設定されるので、監査ローダーは実質的に無効です。この値を、15(秒)のような妥当な値に変更します。


      注意:

      これらの行を、<ias-instance>タグを閉じた後ろに挿入します。


  4. ファイルを保存し、終了します。

  5. ORACLE_HOMEORACLE_INSTANCEおよびCOMMON_COMPONENTS_HOMEが定義されていることを確認します。例:

    ORACLE_HOME = /u01/oracle/as11_oh
    ORACLE_INSTANCE = /u01/oracle/instances/instance 
    COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common
    
  6. 監査データ・ストアのパスワードをシークレット・ストアに移入します。これは、RCUで監査スキーマを作成する際に指定したパスワードです。

    ORACLE_HOME/jdk/bin/java -classpath 
          $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
          $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
          $ORACLE_HOME/jdbc/lib/ojdbc5.jar:
          $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
          $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar 
          -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE 
          -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
          -Dauditloader.username=username 
          -Dstore.password=true 
          -Dauditloader.password=password 
          oracle.security.audit.ajl.loader.StandaloneAuditLoader
    

    jdbcString、usernameおよびpasswordに適切な値を入力します。


    注意:

    前述の構文は、Linuxの場合の構文です。Windowsの場合は、クラスパス内のjarを区切る":"を";"に置換します。


  7. 次のようにしてOPMNをリロードします。

     $ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits)
          $ORACLE_INSTANCE/bin/opmnctl reload
    
  8. 監査対象コンポーネントでなんらかのシナリオを実行して、監査イベントを生成します。

  9. $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.outにアップロードされるエラーとイベントを確認します。この出力は次の例のようになります。

    8/08/26 10:54:24 global:AuditLoader
    

13.2.4.1 監査データ・ストアの構成解除

データベースは監査レコードの推奨ストアなので、データベースからファイル・モードへの切替えはお薦めできません。ただし、必要であれば、opmn.xmlファイルを使用して監査データ・ストアを構成する前述のタスクで示したものと同じ手順により、RMDの定義を更新し、監査データ・ストアの構成を解除することもできます。rmd-definitions要素を見つけ、監査ローダーの既存のRMD定義を置き換えます。


注意:

システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアの構成を解除する必要があります。


  • jdbcString: データベースJDBC接続文字列をデフォルト文字列jdbc:oracle:thin:@host:port:sidに戻します。

  • interval: デフォルト値31536000に戻します。

ファイルを保存して終了し、OPMNをリロードします。

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

この項では、監査レコードのファイルベースの記憶域の管理に関連する次のトピックを説明します。

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

  • ファイル・サイズ

  • ディレクトリ・サイズ


注意:

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


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

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

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

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

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

ファイル・サイズ

Javaコンポーネント

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

第13.3.4項「監査ポリシーの手動による管理」でも説明されていますが、このサイズはバイト単位で指定します。

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

ファイル記憶域モードのファイルのサイズは、auditconfig.xmlファイル内で設定できます。第13.3.4.4項「システム・コンポーネント用の監査の手動構成」を参照してください。


注意:

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


ディレクトリ・サイズ

Javaコンポーネント

ファイルのディレクトリのサイズは、構成ファイルjps-config.xmlで示されているmax.DirSizeプロパティを使用して管理できます。このプロパティは、バスストップ・ディレクトリの最大サイズを制御します。

第13.3.4項「監査ポリシーの手動による管理」でも説明されていますが、このサイズはバイト単位で指定します。

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

ファイル記憶域モードのディレクトリのサイズは、auditconfig.xmlファイル内で設定できます。第13.3.4.4項「システム・コンポーネント用の監査の手動構成」を参照してください。

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

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

  • Oracle WebLogic ServerにデプロイされたJava EEコンポーネントおよびアプリケーションでは、アプリケーション・サーバーによって提供された監査ローダー機能を使用します。

  • システム・コンポーネントおよび非Javaアプリケーションでは、Oracle Process Manager and Notification Server (OPMN)によって提供された監査ローダー機能を使用します。

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

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

13.2.6.1 環境の構成

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

13.2.6.1.1 プロパティの構成

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

  • ORACLE_HOME環境変数

  • COMMON_COMPONENTS_HOME環境変数

  • ORACLE_INSTANCE環境変数

  • auditloader.jdbcStringシステム・プロパティ

  • auditloader.usernameシステム・プロパティ

13.2.6.1.2 データベース・スキーマ・ユーザーのパスワード記憶域

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

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

$ORACLE_HOME/jdk/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar: 
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar 
-Doracle.instance=$ORACLE_INSTANCE 
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
-Dauditloader.username=username 
-Dstore.password=true 
oracle.security.audit.ajl.loader.StandaloneAuditLoader 

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

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

$ORACLE_HOME/jdk/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar 
-Doracle.home=$ORACLE_HOME
-Doracle.instance=$ORACLE_INSTANCE 
-Dauditloader.jdbcString=jdbc:oracle:thin:host:port:sid 
-Dauditloader.username=username 
oracle.security.audit.ajl.loader.StandaloneAuditLoader 

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

13.3 監査ポリシーの管理

監査ポリシーとは

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

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

ポリシーの構成方法

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

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

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


関連項目:

  • 補足的な予備知識については、第12.3.2項「重要な技術的概念」を参照してください。

  • Javaコンポーネントおよびシステム・コンポーネントのリストは、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

  • サード・パーティのアプリケーション・サーバー上での監査コマンドの実行の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。


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

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


注意:



関連項目:

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


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

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

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

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

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

  4. 事前構成済監査レベルのドロップダウン・リストを選択できます。2つの事前定義済レベル(「低」、「中」)では、すべてのコンポーネントの監査イベントのサブセットを自動的に選択します。ほとんどの場合は、事前定義済のレベルで十分です。

    audpol1.gifについては周囲のテキストで説明しています。

    注意:

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


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

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

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

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

    次の表は、ドメイン内で実行中のアプリケーションを示しています。

    audpol5.gifについては周囲のテキストで説明しています。

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

    • 名前: ドメイン内のコンポーネントとアプリケーションが表示されます。

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

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

  5. 監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより、すべてのイベントを選択するか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択することができます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用でき、後述のステップ6に示すように、監査方法をより詳細に制御できます。

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

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

    audpol2.gifについては周囲のテキストで説明しています。

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

    audpol3.gifについては周囲のテキストで説明しています。

    注意:

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


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

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

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

    audpol4.gifについては周囲のテキストで説明しています。

    注意:

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

    • このフィールドに入力するユーザー名に対する検証は行われません。


  10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。Javaコンポーネントの場合、この変更を有効にするには、管理対象Oracle WebLogic Server(影響を受けるJavaコンポーネントが実行されている)を再起動する必要があります。

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

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

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

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

この項では、OPMNを使用して管理されるシステム・コンポーネントの監査ポリシーを表示および更新する方法を説明します。


注意:


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


関連項目:

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


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

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

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

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

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

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

    audpol6.gifについては周囲のテキストで説明しています。

    注意:

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


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

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

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

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

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

    audpol7.gifについては周囲のテキストで説明しています。

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

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

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

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

  5. 監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより、すべてのイベントを選択するか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択することができます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用でき、後述のステップ6に示すように、監査方法をより詳細に制御できます。

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

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

    audpol8.gifについては周囲のテキストで説明しています。

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

    audpol9.gifについては周囲のテキストで説明しています。

    注意:

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


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

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

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

    audpol4.gifについては周囲のテキストで説明しています。

    注意:

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

    • このフィールドに入力するユーザー名に対する検証は行われません。


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

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

13.3.3 WLSTを使用した監査ポリシーの管理

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


注意:

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


13.3.3.1 WLSTを使用した監査ポリシーの表示

WLSTを使用した監査ポリシーを表示するには、次の手順を実行します。


注意:

ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびWLSTを起動する際の様々なオプションの詳細は、『Oracle Fusion Middleware管理者ガイド』のWebLogic Scripting Tool (WLST)の使用方法の概要に関する項を参照してください。


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

    java weblogic.WLST
    connect('servername', 'password', 'localhost:portnum')
    
  • getAuditPolicyコマンドを使用して、監査ポリシーの構成を表示します。例:

    wls:/mydomain/serverConfig> getAuditPolicy()
    
  • システム・コンポーネントの場合:

    • getNonJava EEAuditMBeanNameコマンドを使用してMBean名を取得します。詳細は、第C.4.1項「getNonJava EEAuditMBeanName」を参照してください。

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

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

13.3.3.2 WLSTを使用した監査ポリシーの更新

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


注意:

ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびWLSTを起動する際の様々なオプションの詳細は、『Oracle Fusion Middleware管理者ガイド』のWebLogic Scripting Tool (WLST)の使用方法の概要に関する項を参照してください。


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

    java weblogic.WLST
    connect('servername', 'password', 'localhost:portnum')
    
  • Bean階層を移動し、目的のドメインにアクセスします。たとえば、ドメインがmydomainという名前の場合は、次のようになります。

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

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

  • setAuditPolicyコマンドまたはimportAuditConfigコマンドを発行した後、saveを明示的にコールします。

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

    このコールの例については、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のWLSTを使用した監査の管理に関する項を参照してください。このコールによるOracle Internet Directoryの監査が具体的に説明されています。


関連項目:

監査用のWLSTコマンドの詳細は、WLSTコマンド・リファレンスを参照してください。


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

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

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

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

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

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

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


注意:

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


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

イベントを追加および削除するには、Customフィルタを事前設定する必要があることに注意してください。

13.3.3.5 監査レベルを変更する際に保持されるカスタム構成

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


注意:

この動作は、WLSTを使用している場合にのみ得られます。Fusion Middleware Controlを使用して監査の構成を管理している場合は、カスタム監査レベルから別の監査レベルに切り替えると、カスタム監査の設定はクリアされます。


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

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

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

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

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

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

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

13.3.4 監査ポリシーの手動による管理

この項では、次のファイルを手動で更新することによって監査ポリシーなどの機能を構成する方法について説明します。

  • プラットフォーム構成ファイルjps-config.xml: Javaコンポーネントの場合

  • コンポーネントに固有のファイル: システム・コンポーネントの場合

この項の内容は次のとおりです。

13.3.4.1 Javaコンポーネントの構成ファイルの場所

jps-config.xmlドメイン構成ファイルは、次の場所にあります。

$DOMAIN_HOME/config/fmwconfig/jps-config.xml

13.3.4.2 Javaコンポーネントのjps-config.xml内の監査サービス構成プロパティ

jps-config.xml内の監査サービス構成は、表F-9に示すプロパティで構成されています。一連のプロパティとその値は、まとめて監査ポリシーと呼ばれています。

jps-config.xmlファイルの例

監査ポリシーのサンプル・ファイルを次に示します。

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">
 
    <serviceProviders>
     <serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
     </serviceProvider>
    </serviceProviders>
 
  <serviceInstances>
   <serviceInstance name="audit" provider="audit.provider">
      <property name="audit.filterPreset" value="Low"/>
      <property name="audit.specialUsers" value ="admin, fmwadmin" />
      <property name="audit.customEvents" value ="JPS:CheckAuthorization,          CreateCredential; OIF:UserLogin"/>
      <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
      <property name="audit.loader.interval" value="15" />
      <property name="audit.maxDirSize" value="102400" />
      <property name="audit.maxFileSize" value="10240" />      
      <property name=" audit.loader.repositoryType " value="Db" />      
   </serviceInstance>
  </serviceInstances>
    <jpsContexts default="default">
        <jpsContext name="default">
            <serviceInstanceRef ref="audit"/>
        </jpsContext>
    </jpsContexts>
</jpsConfig>

13.3.4.3 Javaコンポーネントのデータベースからファイルへの切替え

まれに、監査レコードへの(データベース)データ・ストアの使用を、ファイルの使用に戻すことが必要になる場合もあります。その場合は、表F-9に記載されているプロパティaudit.loader.repositoryTypeを手動で構成する必要があります。

データベースからファイルに切り替えるには、audit.loader.repositoryTypeFileに設定します。

データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。

13.3.4.4 システム・コンポーネント用の監査の手動構成

システム・コンポーネントでは、監査構成の格納にjps-config.xmlファイルを使用しません。かわりに次のようにします。

  • Oracle HTTP Serverの場合は、次の場所にあるauditconfig.xmlファイルを使用します。

    ORACLE_INSTANCE/instance_name/config/OHS/<ohs_name>/auditconfig.xml
    
  • Oracle Web Cacheの場合は、次の場所にあるauditconfig.xmlファイルを使用します。

    ORACLE_INSTANCE/instance_name/config/WebCache/<webcache_name>/auditconfig.xml
    
  • Oracle Reportsの場合は、次の場所にあるjps-config-jse.xmlファイルを使用します。

    $DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml
    
  • Oracle Virtual Directoryの場合は、次の場所にあるjps-config.-jse.xmlファイルを使用します。

    ORACLE_INSTANCE/instance_name/config/JPS/jps-config-jse.xml
    
  • Oracle Internet Directoryの監査構成は、データベースに格納されます。

auditconfig.xmlファイルの形式

auditconfig.xmlファイルの形式は次のとおりです。

<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd">
  <Filters>
    <!-- FilterPreset can be None,Low,Medium,All or Custom.  Default value: None -->
    <FilterPreset>Low</FilterPreset>
 
    <!-- Comma separated list of special users for whom auditing is always turned on. Default value: no users -->
    <SpecialUsers>u1,u2</SpecialUsers>
 
    <!-- In case of custom, a comma separate list of events that are to be enabled for auditing. Default value: no events -->
    <CustomEvents>e1,e1</CustomEvents>
 
  </Filters>
  <LogsDir>
 
    <!-- Maximum dir size of the log directory (busstop). 0 implies unlimited size. Default value: 0 -->
    <MaxDirSize>0</MaxDirSize>
 
    <!-- Maximum file size of each audit.log file. Default value: 100MB -->
   <MaxFileSize>104857600</MaxFileSize>
 
 </LogsDir>
<AuditConfig>

13.4 監査ログ

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

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

13.4.1 監査ログの場所

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

13.4.2 監査ログのタイムスタンプ

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

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

監査スキーマは、リポジトリ作成ユーティリティ(RCU)によって作成されます。この項では、監査スキーマの編成について説明し、スキーマの管理に関するトピックについて説明します。


関連項目:

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


13.5.1 スキーマの概要

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

  • 実表: IAU_BASE

  • 変換表: IAU_DISP_NAMES_TL

  • 監査データから構成される、コンポーネントに固有な一連の表(OVDCOMPONENTOIDCOMPONENTJPSなど)

監査レコードは生成時、1つのファイルに格納されます。監査データベース・ストアが構成されていると、監査ローダーは各監査レコードを実表の1つの行およびコンポーネント表の1つの行に格納します。

  • 一般的な情報(Time、EventType、EventStatusなど)は、実表に書き込まれます。

  • コンポーネントに固有な情報(CodeSourceなど)は、コンポーネント表に書き込まれます。


注意:

レコードが格納されるコンポーネント表は、バスストップ・ファイル内の属性ComponentTypeによって決定されます。


監査ローダーは格納時、すべてのレコードに一意な連番を割り当てます。

Oracle Platform Security Servicesのバスストップ・ファイルの次に例を示します。デフォルトでは、このファイルは次のディレクトリ内に保持されます。

WebLogic Domain Home/servers/server_name/diagnostics/auditlogs/JPS/audit.log

#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" - "[]" - - - -

図13-1は、実表内のデータと、それがコンポーネントに固有な表にどのように関係しているのかを示しています。

図13-1 監査スキーマ

図13-1については周囲のテキストで説明しています。

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

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

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

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

13.5.2 表の属性

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

  • $ORACLE_HOME/modules/oracle.iau_11.1.1/components/generic/generic_events.xml
    

    (実表用)

  • $ORACLE_HOME/modules/oracle.iau_11.1.1/components/componentName/component_events.xml
    

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

表13-1に、実表IAU_BASEで定義されている重要な属性をいくつか示します。最初の4つの属性は、その実表とすべてのコンポーネント表に共通する属性です。主キーは、IAU_ID + IAU_TSTZORIGINATINGと定義されます。

表13-1 実表IAU_BASEの属性

属性 説明

IAU_ID

各監査レコードの一意な連番

IAU_TstzOriginating

監査イベントが生成された日付と時刻(データ型TIMESTAMP)

IAU_EventType

監査イベントのタイプ(名前)

IAU_EventCategory

監査イベントのカテゴリ

IAU_EventStatus

監査イベントの結果(失敗または成功)

IAU_MessageText

監査イベントの説明

IAU_Initiator

操作を実行していたユーザーのUID



注意:

Oracleデータベース・オブジェクトの1つであるSEQUENCEは、監査レコードの連番(IAU_ID)の割当てを調整するために作成されます。


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

13.5.3 索引スキーム

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

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

13.5.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は、時間が経過しても変化しないため、バックアップの実行は一度だけで十分です。


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

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

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

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

13.5.6 パーティション化

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

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

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

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

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

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

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

13.5.6.1 パーティション表

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

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


注意:

この製品には、サンプルのSQLスクリプトが2つ含まれています。

  • $RCU_HOME/rcu/integration/iau/scripts/convertPartitionedTables.sql(linux)または%RCU_HOME\rcu\integration\iau\scripts\convertPartitionedTables.sql(Windows)は、監査スキーマ内の実表およびコンポーネント表をパーティション化された表に変換します。

  • $RCU_HOME/rcu/integration/iau/scripts/createPartitionsByQuarter.sql(linux)または%RCU_HOME\rcu\integration\iau\scripts\createPartitionsByQuarter.sql(Windows)は、監査スキーマ内の実表およびコンポーネント表に対し、四半期別のパーティションを作成します。


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


注意:

パーティション化を実行する前に監査ローダーを非アクティブ化するようお薦めします。詳細は、第13.2.4.1項「監査データ・ストアの構成解除」を参照してください。


  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;
    

    注意:

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


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

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

13.5.6.3 データのインポート、エクスポート、消去

インポートとエクスポートについては、第13.5.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');

パーティションを作成したら、特定のパーティションの消去およびバックアップを実行できます。詳細は、データベースのドキュメントを参照してください。

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

13.5.6.4 階層アーカイブ

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

次に例を示します。

ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008
TABLESPACE AUDITARCHIVE UPDATE INDEXES;

注意:

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


Oracle Information Lifecycle Management (ILM) Assistantというフリーのツールを使用すると、表をパーティション化する方法を知ることができ、パーティションを移動する時期についての助言が得られます。詳細は、次のサイトを参照してください。

http://www.oracle.com/technology/deploy/ilm/index.html