| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11gリリース1(11.1.1) B56235-07 |
|
 前 |
 次 |
この章では、日常的な監査管理タスクの実行方法を説明します。
監査管理者は、次の手順に従って、サイトの監査の設定を注意深く計画する必要があります。
実装の計画
これには、監査レコード用に使用するストアのタイプやデータ・ストアの詳細構成などの計画が含まれます。
詳細は、第13.2項「監査データ・ストアの管理」を参照してください。
ポリシー管理
管理者は、必要な監査イベントが確実に生成されるように、適切な監査ポリシーを構成する必要があります。
アプリケーション環境の変化やコンポーネントおよびユーザーの追加などを監査ポリシーに反映する必要があるため、ポリシー管理は継続的なアクティビティになります。
詳細は、第13.3項「監査ポリシーの管理」を参照してください。
レポート管理
これには、監査レポートと監査問合せの計画と構成が含まれます。
詳細は、第14章「監査分析と監査レポートの使用」を参照してください。
データ管理
これには、企業ポリシーに基づいた、生成される監査データの格納に必要なデータベース・サイズの計画/増加、監査データのバックアップ、監査データの消去が含まれます。
監査データ・ストアの管理の詳細は、第13.6項「データベース・ストアの拡張管理」を参照してください。
監査フレームワークでは、追加設定なしですぐに、ファイル・システムを使用して監査レコードを格納します。ただし本番環境では、データベース監査データ・ストアを使用して、監査フレームワークのスケーラビリティと高可用性を確保することをお薦めします。
また、データベース内の監査データ・ストアを使用すると、Oracle Business Intelligence Publisherで使用可能な事前パッケージ済の監査レポートにより監査データを表示することができます。Oracle Business Intelligence Publisherは、11g リリース1 (11.1.1)のCDパックで使用できます。
この項では、監査データ・ストアの次のような管理タスクについて詳細に説明します。
監査レコードの永続的ストアとしてデータベースに切り替えるには、最初にリポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・ストアを作成する必要があります。
|
注意: バスストップ・ファイルは、データベース記憶域が存在しない場合の監査レコードの格納先になります。 |
この項では、監査スキーマの作成方法を説明します。データベース・スキーマの作成後は、次のことが可能になります。
このスキーマを指し示すデータソースを作成します。
ドメインの構成を更新し、監査レコードの監査データ・ストアを切り替えます(第13.2.3.2項「監査データ・ストアとバスストップ・ストレージの構成」を参照)。
|
注意: この説明では、RCUおよびデータベースが環境にインストール済であることを前提としています。詳細は、インストレーション・ガイドを参照してください。 |
開始する前に
作業を開始する前に、使用するデータベースの詳細情報を収集し、DBA資格証明を入手してください。
データベース・スキーマの構成
ここに示す手順で、監査データ・ストアのスキーマを構成します。
手順は次のとおりです。
$RCU_HOME/binに移動し、RCUユーティリティを実行します。
開始画面で「作成」を選択します。「次へ」をクリックします。
「データベース接続の詳細」ページが表示されます。データベースの詳細を入力します。
「次へ」をクリックします。
「コンポーネントの選択」ページが表示されます。接頭辞の新規作成を選択して、IDMなどを入力します。接頭辞がスキーマ所有者および表領域の名前に適用されます。スキーマ・ユーザーが接頭辞を使用して作成されます。この例では、スキーマ・ユーザーはIDM_IAU、IDM_IAU_APPENDおよびIDM_IAU_VIEWERです。
また、スキーマのリストから「監査サービス」を選択します。
「次へ」をクリックします。
「スキーマ・パスワード」ページが表示されます。
パスワードを入力し、「次へ」をクリックします。
「表領域のマップ」ページが表示されます。「次へ」をクリックして、表領域の作成を承認します。
「サマリー」ページが表示されます。
詳細を確認し、「作成」をクリックします。
スキーマの作成中にエラーが発生していないか確認します。「完了サマリー」ページでジョブが成功したことを確認します。
このプロセスの完了には数分かかります。
第13.2.1項「RCUによる監査スキーマの作成」で説明したように、データベースに監査レコードを格納するデータベース・スキーマを作成した後、そのスキーマを指すOracle WebLogic Serverの監査データソースを設定する必要があります。
監査データソースを設定するには、次の手順を実行します。
|
注意: このタスクは、Oracle WebLogic Server管理コンソールで実行します。 |
Oracle WebLogic Server管理コンソールに接続します。
http://host:7001/console
「JDBC」で、「データソース」リンクをクリックします。
「データソース」ページが表示されます。「新規」をクリックして新しいデータソースを作成します。
新しいデータソースに関して、次の詳細情報を入力します。
名前: Audit_Data_Source-0などの名前を入力します。
JNDI名: jdbc/AuditDB。
データベースのタイプ: Oracle
データベース・ドライバ: Oracleドライバ(Thin XA)バージョン9.0.1、9.0.2、10、11。
管理対象クラスタ・サーバーにデプロイする場合は、「管理サーバー」も選択します。これにより、ファイルからデータベース・ストアに切り替える際、該当するデータソースが監査データ・ストアに表示されます。
「次へ」をクリックします。
「トランザクション・オプション」ページが表示されます。「次へ」をクリックします。
「接続プロパティ」ページが表示されます。次の情報を入力します。
データベース名: 接続先のデータベース名を入力します。これは通常SIDに対応します。
ホスト名: データベースのホスト名を入力します。
ポート: データベース・ポートを入力します。
データベース・ユーザー名: RCUで作成した監査スキーマ名です。次の規則がこのエントリに適用されます。
すべて大文字を使用します。
データベースで監視スキーマを作成する際に使用したスキーマ接頭辞を付加します。
スキーマ名を追加します。このデータソースでは、スキーマ名はIAU_APPENDです。
たとえば、スキーマ接頭辞に"ENG"を使用した場合は、ここで入力する値は"ENG_IAU_APPEND"となります。
パスワード: RCUで作成した監査スキーマのパスワードです。
「次へ」をクリックします。
次のページに、JDBCドライバ・クラスとデータベースの詳細情報が表示されます。デフォルトを選択し、「構成のテスト」をクリックして、接続をテストします。「接続は正常に確立されました」というメッセージが表示されたら、「次へ」をクリックします。エラーが表示された場合は、接続の詳細情報に戻って確認します。
「ターゲットの選択」ページで、このデータソースを構成するサーバーを選択して、「終了」をクリックします。
スケーラビリティおよび高可用性を実現するために、監査データのOracle Real Application Clustersを構成できます。
詳細は、次を参照してください:
『Oracle Fusion Middleware高可用性ガイド』のRACデータベース・ストアを使用した監査の設定に関する項
『Oracle Fusion Middleware高可用性ガイド』のWebLogic Serverを使用した監査データ・ソースおよびマルチ・データ・ソースの構成に関する項
『Oracle Fusion Middleware高可用性ガイド』の監査ローダー用JDBC文字列の構成に関する項
スキーマの作成後にデータベース・ベースの監査データ・ストアを構成するには、次の作業を行います。
作成した監査スキーマを指し示すデータソースの作成
データソースを指し示す監査データ・ストアの構成
この項では、監査データ・ストアの構成に関連する次のタスクを説明します。
|
注意: この手順で構成されるのは、Javaコンポーネント用の監査データ・ストアのみです。システム・コンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第13.2.4項「システム・コンポーネント用のデータベース監査データ・ストアの構成」を参照してください。 同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。 |
|
注意: このタスクは、Oracle Enterprise Manager Fusion Middleware Controlで実行します。 |
現在の監査データ・ストアの構成を確認する手順は次のとおりです。
「ドメイン」→「セキュリティ・プロバイダ構成」に移動します。
「監査サービス」セクションで、「構成」をクリックします。
このページには、次の項目が表示されます。
データソースのJNDI名 - 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソースのJNDI名が表示されます。監査データ・ストアが構成されていない場合、このフィールドは空になります。デフォルトでは、データベースは構成されておらず、監査レコードはバスストップ・ファイルに格納されています。
監査ローダー頻度 - このフィールドは、バスストップ・ファイルから監査データ・ストアへデータを移動する頻度を秒数で表示します。
データソースの例は、第13.2.2項「監査データソースの設定」を参照してください。
監査ストアの構成に関連する特定のタスクを実行できます。
これらの機能を構成するには、次の手順を実行します。
「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
「監査サービス構成」ボタンをクリックします。「監査サービス構成」ページが表示されます。
監査データ・ストアを構成する手順は次のとおりです。
「データソースのJNDI名」フィールドの横にあるサーチライトのアイコンをクリックします。
ダイアログ・ボックスが表示され、ドメイン内で監査レコード用に使用可能なデータソースのリストが表示されます。目的のデータソースを選択して、「OK」をクリックします。
選択されたデータソースが「データソースのJNDI名」フィールドに表示されます。「適用」をクリックして続行するか、「元に戻す」をクリックして更新を中止します。
|
注意: 監査データ・ストアの設定は、WLST |
監査ローダーの頻度を秒単位で入力します。監査ローダーは指定された間隔でリポジトリをチェックし、レコードをリポジトリにプッシュします。
「適用」をクリックします。
コンポーネント用にバスストップ・ファイルのパラメータを構成する手順は次のとおりです。
「監査コンポーネント名」ドロップダウン・リストからコンポーネントを選択します。
最大ファイル・サイズを入力します。
最大ディレクトリ・サイズを入力します。
「適用」をクリックします。
ドメイン内のすべてのOracle WebLogic Serverを再起動します。これにより、Oracle WebLogic Server内の起動クラス監査ローダーが構成を再度読み込むことができます。
変更は、監査ポリシーでイベント収集のテストを設定することによってテストできます。たとえば、Oracle Platform Security Servicesの監査ポリシーを「中」に設定することもできます。詳細は、第13.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。
監査によって監査イベントが生成されるように、シナリオを実行します。たとえば、ステップ6で構成したポリシーに基づき、資格証明の作成によって監査レコードがトリガーされます。
サーバー・ログ内のエラーおよび例外をチェックします。
$DOMAIN_HOME/jrfServer_admin.outをチェックします。
$DOMAIN_HOME/servers/$SERVER_NAME/logs/をチェックします。
データベースは監査レコードの推奨ストアであるため、データベースからファイル・モードへの切替えはお薦めできません。ただし、第13.3.4項「監査ポリシーの手動による管理」では、audit.repositoryTypeというプロパティの値をFileに設定することで、ファイルに格納する方式に切り替えることができると説明されています。
|
注意: Fusion Middleware ControlやWLSTを使用してデータベースからファイル・モードに切り替えることはできません。この切替えを実現するには、第13.3.4項「監査ポリシーの手動による管理」で説明するように、手動による構成が必要です。 |
データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。
Oracle Process Manager and Notification Server (OPMN)は、Oracle WebLogic Server内で実行されるいくつかのシステム・コンポーネントを管理します。これらのコンポーネントの場合、ローカルなバスストップ・ファイルからデータベース監査データ・ストアに監査イベントがプッシュされるメカニズムは、OPMNによって処理されます。
|
注意: システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアを、すべてのインスタンスがレコードを該当ストアにプッシュするよう構成する必要があります。 |
監査データ・ストアを構成するには、コンポーネントの各インスタンスで、次の手順を実行する必要があります。
|
注意: この手順で構成されるのは、システム・コンポーネント用の監査データ・ストアのみです。Javaコンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第13.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。 同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。 |
次の場所にあるopmn.xmlファイルを開きます。
(UNIX) $ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml (Windows) %ORACLE_INSTANCE%/config/OPMN/opmn/opmn.xml
次のようなrmd-definitions要素を見つけます。
(UNIX)
<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:
$COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.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>
(Windows)
<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;
%COMMON_COMPONENTS_HOME%\modules\oracle.jps_11.1.1\jps-manifest.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>
監査ローダーの既存のRMD定義を置き換えます。変更する値は、次のものだけです。
jdbcString - これは、データベースJDBC接続文字列です。これをデフォルト文字列から有効な接続文字列に変更します。
username
interval - 監査レコードは、この間隔(秒)で、コンポーネントのバスストップ・ファイルから監査データ・ストアにプッシュされます。
デフォルトでは、intervalに非常に大きな値(31536000秒)が設定されるので、監査ローダーは実質的に無効です。この値を、15(秒)のような妥当な値に変更します。
|
注意: これらの行を、 |
ORACLE_HOME、ORACLE_INSTANCEおよびCOMMON_COMPONENTS_HOMEが定義されていることを確認します。例:
(UNIX) ORACLE_HOME = /u01/oracle/as11_oh ORACLE_INSTANCE = /u01/oracle/instances/instance COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common (Windows) ORACLE_HOME = \u01\oracle\as11_oh ORACLE_INSTANCE = \u01\oracle\instances\instance COMMON_COMPONENTS_HOME = %MW_HOME%\oracle_common
シークレット・ストアの監査データ・ストア・パスワード(RCUで監査スキーマを作成した際に指定したパスワード)を移入します。
(UNIX) 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:
$COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.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
(Windows) 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;
%COMMON_COMPONENTS_HOME%\modules\oracle.jps_11.1.1\jps-manifest.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に適切な値を入力します。
ファイルを保存し、終了します。
次のようにしてOPMNをリロードします。
$ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits)
$ORACLE_INSTANCE/bin/opmnctl reload
監査対象コンポーネントでなんらかのシナリオを実行して、監査イベントを生成します。たとえば、Oracle HTTP Serverが「ユーザー・セッション」カテゴリの"User Logins"を監査するよう構成されており、ログインによって監査イベントが生成される場合は、Oracle HTTP Serverインスタンスにログインします。
$ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.outにアップロードされるエラーとイベントを確認します。この出力は次の例のようになります。
8/08/26 10:54:24 global:AuditLoader
データベースは監査レコードの推奨ストアなので、データベースからファイル・モードへの切替えはお薦めできません。ただし、必要であれば、opmn.xmlファイルを使用して監査データ・ストアを構成する前述のタスクで示したものと同じ手順により、RMDの定義を更新し、監査データ・ストアの構成を解除することもできます。rmd-definitions要素を見つけ、監査ローダーの既存のRMD定義を置き換えます。
|
注意: システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアの構成を解除する必要があります。 |
jdbcString - データベースJDBC接続文字列をデフォルト文字列jdbc:oracle:thin:@host:port:sidに戻します。
interval - デフォルト値31536000に戻します。
ファイルを保存して終了し、OPMNをリロードします。
この項では、監査レコードのファイルベースの記憶域の管理に関連する次のトピックを説明します。
バスストップ・ファイルの場所
ファイル・サイズ
ディレクトリ・サイズ
|
注意: 監査ファイルを手動で消去して領域を解放することは、お薦めしません。かわりに、後述のようなファイルおよびディレクトリのサイズ調整機能を使用して、領域を制御してください。 |
バスストップ・ファイルの場所
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項「システム・コンポーネント用の監査の手動構成」を参照してください。
図12-1に示すように、共通監査フレームワークの監査ローダーは、レコードをバスストップ・ファイルから監査データ・ストアに移動します。監査ローダーを駆動するメカニズムは、アプリケーション環境に応じて変わります。
Oracle WebLogic ServerにデプロイされたJava EEコンポーネントおよびアプリケーションでは、アプリケーション・サーバーによって提供された監査ローダー機能を使用します。
システム・コンポーネントおよび非Javaアプリケーションでは、Oracle Process Manager and Notification Server (OPMN)によって提供された監査ローダー機能を使用します。
アプリケーション・サーバー・コンテナの外部で実行されたJava SEアプリケーションでは、スタンドアロン監査ローダーを使用します。
この項では、スタンドアロン監査ローダーの設定および実行方法を説明します。
スタンドアロン監査ローダーを実行する前に、a) 特定のプロパティの構成、およびb) データベース・スキーマ・ユーザーのパスワードがシークレット・ストアに存在することの確認を行う必要があります。
次のプロパティを構成する必要があります。
ORACLE_HOME環境変数
COMMON_COMPONENTS_HOME環境変数
ORACLE_INSTANCE環境変数
auditloader.jdbcStringシステム・プロパティ
auditloader.usernameシステム・プロパティ
データベース・スキーマ・ユーザーのパスワードは、シークレット・ストアに格納されます。パスワードの格納は、javaのStandAloneAuditLoaderコマンドを-Dstore.password=trueプロパティ付きで使用する1回かぎりの操作です。
次のようにStandAloneAuditLoaderコマンドを発行してパスワードを格納します。
$COMMON_COMPONENTS_HOME/jdk/jre/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.iau_11.1.1/fmw_audit.jar: $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar: $COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=db-user-name -Dstore.password=true oracle.security.audit.ajl.loader.StandaloneAuditLoader
パスワードがコマンドラインに含まれているかどうかによって、パスワードを格納するStandAloneAuditLoaderコマンドには2つのバリエーションがあります。
コマンドの発行時にパスワード・プロパティ(-Dauditloader.password)を含めていない場合は、パスワードの入力を求められます。
コマンドの発行時にパスワード・プロパティを含めることができます。
|
注意: クラスパスの指定には空白文字を使用しないでください。 |
このコマンドにより、cwallet.ssoファイルが生成されます。
次のようにStandAloneAuditLoaderコマンドを発行して監査レコードをロードします。
$COMMON_COMPONENTS_HOME/jdk/jre/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.iau_11.1.1/fmw_audit.jar: $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar: $COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar: $COMMON_COMPONENTS_HOME/modules/oracle.jps_11.1.1/jps-manifest.jar -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=db-user-name oracle.security.audit.ajl.loader.StandaloneAuditLoader
監査レコードを監査データ・ストアに定期的にアップロードするように、バッチ・ジョブまたはkronジョブによってこのコマンドをスケジュールできます。
監査ポリシーとは
監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。
たとえば、監査ポリシーでは、Oracle Internet Directoryインスタンスに対するすべての認証の失敗を監査するように指定することができます。
ポリシーの構成方法
Oracle Fusion Middleware監査フレームワークを使用すると、監査ポリシーを構成し、監視対象のイベントおよびデータのタイプをきわめて詳細に制御することができます。ポリシーは、Enterprise ManagerのUIツールまたはOPSSスクリプトを使用して構成できます。
ポリシーの変更にはサーバーまたはインスタンスの再起動は不要です。
この項の残りの部分では、監査ポリシーの表示および更新方法を説明します。
|
関連項目:
|
ドメインの「監査ポリシー設定」ページでは、Oracle Access ManagerなどのすべてのJavaコンポーネントの監査イベントと、Oracle Platform Security Servicesなどのシステム・ライブラリの監査イベントを管理します。
|
注意:
|
現在構成されている監査ポリシーを表示および更新するには、次の手順を実行します。
Fusion Middleware Controlにログインします。
左側のトポロジ・パネルを使用して、「WebLogicドメイン」の下の目的のドメインに移動します。
ドメイン・メニューから、「ドメイン」→「セキュリティ」→「監査ポリシー」に移動します。「監査ポリシー」ページが表示されます。
「監査コンポーネント名」ドロップダウン・リストを使用して、構成したい監査ポリシーがあるJavaコンポーネントを選択します。
コンポーネントを選択すると、そのコンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」というページ領域に表示されます。Oracle Access Managerの場合の例を示します。
「監査レベル」ドロップダウン・リストを使用して、そのコンポーネントの監査イベントのサブセットを選択します。次の選択肢があります。
なし - イベント・カテゴリは選択されません。
低、中、高 - 監査の事前定義済レベルを表すイベント・カテゴリのサブセット。
カスタム - カスタムのフィルタ定義を作成または変更できます。
選択するレベルに応じて、「監査用に選択」列にチェック・フラグが表示されます。選択されたカテゴリのイベントが監査されます。Oracle Access Managerの「中」レベルの例を示します。
フラグ付きのカテゴリが監査用に選択されています。フラグ付きカテゴリ内のイベントを確認するには、カテゴリ表でその行をクリックします。たとえば、「サーバー」カテゴリをクリックすると下部に次のようなイベント表が生成されます。
|
注意: イベントの表はカスタム・レベルでのみ編集できます。事前定義済レベルでは編集できません。 |
多くの場合、事前定義済レベルで十分ですが、コンポーネントの監査ポリシーの微調整が必要な場合もあります。
監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより事前定義済カテゴリは保持されたまま、チェック・ボックスとして緑色のチェックマークが表示され、すべてのカテゴリの選択が可能になります。
目的のカテゴリとイベントを選択して監査ポリシーを微調整できます。たとえば、「サーバー」カテゴリで、失敗した認証試行のみを監査したい場合があります。
フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。ポリシーをさらに微調整して、失敗した認証試行のタイプを絞り込んで監査する場合の例を示します。
「フィルタの編集」列の鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。アイコンをクリックし、「フィルタの編集」ダイアログを表示します。
「条件」ボックスを使用して、フィルタ条件、演算子および値で構成されるフィルタを指定します。条件を指定したら、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックして変更を保存します。
この例では、保護されたアプリケーションをホストするサーバーの名前がmyhost1の場合のみ、失敗した認証試行が監査イベントをトリガーします。
|
注意: 各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。 |
インポート/エクスポート - これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。
必要に応じ、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。
|
注意:
|
ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。Javaコンポーネントの場合、この変更を有効にするには、管理対象Oracle WebLogic Server(影響を受けるJavaコンポーネントが実行されている)を再起動する必要があります。変更は、事前定義済のリフレッシュ間隔(デフォルトでは10分間)の経過後に有効になります。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。
コンポーネント・イベントについて
ドメイン内の各コンポーネントおよびアプリケーションでは、監査可能なイベントの独自のセットを定義します。そのため、表の「名前」列を開くと、コンポーネントごとにそのコンポーネントのインスタンスに適用されるイベントのリストが表示されます。
この項では、OPMNを使用して管理されるシステム・コンポーネントの監査ポリシーを表示および更新する方法を説明します。
|
注意:
|
システム・コンポーネントの監査ポリシーは、それぞれのホーム・ページで管理されます。ドメインの「監査ポリシー設定」ページでは、ドメイン内で実行されるJavaコンポーネントの監査イベントを管理します。
イベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。
OPMN管理コンポーネントの監査ポリシーを表示および更新するには、次の手順を実行します。
Fusion Middleware Controlにログインします。
左側のトポロジ・パネルを使用して、Oracle HTTP Serverなど、目的のシステム・コンポーネントに移動します。
コンポーネント・メニューから、「セキュリティ」→「監査ポリシー」とナビゲートします。「監査ポリシー設定」ページが表示されます。
事前構成済監査レベルのドロップダウン・リストから選択できます。3つの事前定義済レベル(「低」、「中」、高)では、コンポーネントの監査イベントのサブセットを自動的に選択します。
|
注意: 事前定義済レベルについて、ドロップダウン・ボックスの下のイベント選択を編集することはできません。カスタム・レベルでの編集のみが可能です。 |
なし - 監査対象のイベントは選択されません。
低 - 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。
中、高 - より大きなイベントのセット。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。
カスタム - このレベルではポリシーを微調整できます。後述のステップ5を参照してください。
次の表は、コンポーネント・インスタンスに対して監査できるイベントを示しています。Oracle HTTP Serverの例を示します。
表は、次の列から構成されています。
名前 - タイプ別にまとめられたコンポーネント・イベント(認可イベントなど)が表示されます。
監査の有効化 - 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。
フィルタ - イベント・タイプで有効なフィルタが表示されます。
監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより、「監査用に選択」列の関連するボックスを選択することで、イベント・カテゴリを選択できます。
2つ目の表は各カテゴリのイベントを一覧表示しており、ステップ6に示すように、個々のイベント結果(成功および失敗)に対して追加のフィルタを使用して監査方法をより詳細に制御できます。
フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。
鉛筆アイコンをクリックし、「フィルタの編集」ダイアログを表示します。
|
注意: 各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。 |
「障害のみ選択」をクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。
インポート/エクスポート - これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。
オプションで、「常に監査するユーザー」の下にあるユーザーのカンマ区切りリストを指定し、監査フレームワークでこれらのユーザーによって起動されたイベントを監査するようにすることができます。監査は、指定された監査レベルやフィルタに関係なく行われます。
|
注意:
|
ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。
この項では、Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーの表示や更新を実行する方法を説明します。
|
注意:
|
WLSTを使用した監査ポリシーを表示するには、次の手順を実行します。
|
注意: ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびWLSTを起動する際の様々なオプションの詳細は、『Oracle Fusion Middleware管理者ガイド』のWebLogic Scripting Tool (WLST)の使用方法の概要に関する項を参照してください。 |
次のコマンドを使用して、WebLogicサーバーに接続します。
>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')
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")
Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーを更新するには、次の手順を実行します。
|
注意: ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびWLSTを起動する際の様々なオプションの詳細は、『Oracle Fusion Middleware管理者ガイド』のWebLogic Scripting Tool (WLST)の使用方法の概要に関する項を参照してください。 |
次のコマンドを使用して、WebLogicサーバーに接続します。
>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')
Bean階層を移動し、目的のドメインにアクセスします。たとえば、ドメインがmydomainという名前の場合は、次のようになります。
wls:/mydomain/serverConfig>
setAuditPolicyコマンドを使用して、監査ポリシーの構成を更新します。
ポリシーをローカルで管理するコンポーネントの場合は、setAuditPolicyコマンドを使用し、MBean名を含めると、監査ポリシーの構成が更新されます。
setAuditPolicyコマンドまたはimportAuditConfigコマンドを発行した後、saveを明示的にコールします。
saveを呼び出さないと、新しい設定が有効になりません。
このコールの例については、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のWLSTを使用した監査の管理に関する項を参照してください。このコールによるOracle Internet Directoryの監査が具体的に説明されています。
このシナリオでは、ドメインの現在のポリシーにより、user1というユーザーが監査されています。ここでは、常に監査されるユーザーのリストにuser2およびuser3という2つの名前を追加し、user1をリストから削除します。
このタスクは、setAuditPolicyを次のように起動して実行します。
setAuditPolicy (filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")
このシナリオでは、ドメインの現在のポリシーにより、ユーザーのログアウト・イベントが監査されています。ここでは、ポリシーからログアウト・イベントを削除し、ログイン・イベントを監査するようにします。
このタスクは、setAuditPolicyを次のように起動して実行します。
|
注意: この例では、Oracle HTTP Serverのコンポーネント・タイプOHSを使用します。コマンドの使用時に、適切なコンポーネント・タイプに置き換えてください。 |
setAuditPolicy (filterPreset="Custom",addCustomEvents="OHS:UserLogin", removeCustomEvents="OHS:UserLogout")
イベントを追加および削除するには、Customフィルタを事前設定する必要があることに注意してください。
カスタム・レベルで監査を構成しているときに、WLSTを使用して別の(カスタムではない)監査レベルに切り替えても、明示的にそれらのカスタム監査設定を削除しないかぎり、そのカスタム監査設定は保持されます。
|
注意: この動作は、WLSTを使用している場合にのみ得られます。Fusion Middleware Controlを使用して監査の構成を管理している場合は、カスタム監査レベルから別の監査レベルに切り替えると、カスタム監査の設定はクリアされます。 |
この動作を示す例は、次のとおりです。
カスタム監査レベルはコンポーネントのポリシーに対して設定します。構成の過程で監査フィルタを指定します。
実行時には、指定したフィルタに従って監査データが収集されます。
WLSTコマンドのsetauditpolicyを使用して、コンポーネントの監査ポリシーをカスタム監査レベルから、たとえば低い監査レベルに変更したとします。しかし、カスタム監査レベルの中で設定したフィルタは監査構成にそのまま残ります。
監査データの収集は、カスタム・レベルではなく、低い監査レベルに基づいています。
コンポーネントの監査ポリシーはカスタム・レベルに戻されます。別のフィルタが追加され、元々構成されているフィルタに追加されます。元のフィルタを明示的に削除しないかぎり、このフィルタは構成の中で保持されます。
実行時には、効力があるすべてのフィルタに基づいてカスタム・レベルで監査データが収集されます。
この項では、次のファイルを手動で更新することによって監査ポリシーなどの機能を構成する方法について説明します。
プラットフォーム構成ファイルjps-config.xml: Javaコンポーネントの場合
コンポーネントに固有のファイル: システム・コンポーネントの場合
この項の内容は次のとおりです。
jps-config.xmlドメイン構成ファイルは、次の場所にあります。
$DOMAIN_HOME/config/fmwconfig/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>
まれに、監査レコードへの(データベース)データ・ストアの使用を、ファイルの使用に戻すことが必要になる場合もあります。その場合は、表F-9に記載されているプロパティaudit.loader.repositoryTypeを手動で構成する必要があります。
データベースからファイルに切り替えるには、audit.loader.repositoryTypeをFileに設定します。
データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。
システム・コンポーネントでは、監査構成の格納に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,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>
11gリリース1(11.1.1.7)より前のリリースでは、監査サービスはアプリケーション・サーバーのタイムゾーンを使用してデータベース・レコードを書き出していました。11gリリース1(11.1.1.7)では、監査サービスはアプリケーション・サーバーと監査データ・ストアに対して異なるタイムゾーンを構成できます。
詳細は、次のとおりです。
新しい11gリリース1(11.1.1.7)のサイトは、監査イベントが協定世界時(UTC)で書かれていると見なします。
11gリリース1(11.1.1.6)から11gリリース1(11.1.1.7)にアップグレードするサイトは、デフォルトでは、明示的にUTCに切り替えないかぎり監査レコードに対してアプリケーション・サーバーのタイムゾーンを引き続き使用します。
|
注意: バスストップ・ファイルへのレコードは常にUTCを使用します。 |
新しい11gリリース1(11.1.1.7)のサイト
11gリリース1(11.1.1.7)以降の新しいインストールでは、監査レコードは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リリース1(11.1.1.7)にアップグレードするサイト
アップグレードの前に存在していた監査レコードでは、アプリケーション・サーバーのタイムスタンプが使用されていました。アップグレード後、監査サービスの構成には変化がなく、デフォルトでは、レコードは引き続きアプリケーション・サーバーのタイムスタンプを使用して書き込まれます。
アップグレード後にUTCタイムスタンプを使用したい場合は、構成ファイルに新しいサービス・プロパティaudit.timezone=utcを追加してUTCの動作を有効にすることができます。
アップグレード後にUTCに切り替える場合は、レポート作成に影響をおよぼす可能性がある潜在的な矛盾を回避するため、まず既存のレコードを移動することをお薦めします。
この項の内容は、次のとおりです。
Fusion Middleware監査フレームワークでは、監査管理に役立つように、一連のログ・ファイルを提供しています。それらのログを使用すると、監査フレームワークが正しく機能しないときに、エラーをトレースしたり、診断を行うことができます。
すべての監査ログの場所のリスト、ロガーの構成方法およびログによる問題の診断方法は、第L.1.1.7項「監査ロガー」を参照してください。
監査のバスストップ・ファイルのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。
監査スキーマは、リポジトリ作成ユーティリティ(RCU)によって作成されます。この項では、監査スキーマの編成について説明し、スキーマの管理に関する次のトピックについて説明します。
|
関連項目: RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。 |
Oracle Fusion Middleware監査フレームワーク・スキーマの共通の表は、次のものから構成されています。
IAU_COMMON表の共通属性
専用表の汎用属性
IAU_CUSTOM_nnn表のカスタム属性表
これらの表の詳細は、第12.4項を参照してください。
監査スキーマには、次のものが含まれます。
実表
変換表
監査データのコンポーネントに固有な表のセット
これらの表の詳細は、第13.6.2項を参照してください。
バスストップ・ファイルについて
デフォルトでは、バスストップ・ファイルは次のディレクトリ内に保持されます。
WebLogic Domain Home/servers/server_name/diagnostics/auditlogs/JPS/audit.log
Oracle Platform Security Servicesのバスストップ・ファイルの次に例を示します。
#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-2は、実表内のデータと、それがコンポーネントに固有な表にどのように関係しているのかを示しています。
監査レコードは生成時、1つのファイルに格納されます。監査データベース・ストアが構成されていると、監査ローダーは各監査レコードを実表の1つの行およびコンポーネント表の1つの行に格納します。
一般的な情報(Time、EventType、EventStatusなど)は、実表に書き込まれます。
コンポーネントに固有な情報(CodeSourceなど)は、コンポーネント表に書き込まれます。
実表IAU_BASEの平均的なレコード・サイズは、約0.3 KBです。表領域のサイズを計画する際は、次のようにしてください。
この数値を、平均的なレコード・サイズのガイドラインとして使用してください。
選択した監査ポリシーおよびアクティビティのレベルに基づいて、監査データベースのサイズが増加する様子を監視してください。
監査データの格納期間を考慮してください。
実表およびコンポーネントに固有な表の属性はそれぞれ、次のファイルから派生しています。
$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 |
監査イベントが生成された日付と時刻(データ型 |
|
IAU_EventType |
監査イベントのタイプ(名前) |
|
IAU_EventCategory |
監査イベントのカテゴリ |
|
IAU_EventStatus |
監査イベントの結果(失敗または成功) |
|
IAU_MessageText |
監査イベントの説明 |
|
IAU_Initiator |
操作を実行していたユーザーのUID |
|
注意: Oracleデータベース・オブジェクトの1つである |
OPSSスクリプトlistAuditEventsを使用すると、各コンポーネント表のすべての属性名のリストを取得することができます。
問合せを効率よく実行できるように、デフォルトでは、実表およびコンポーネントに固有の各表のタイムスタンプ(IAU_TSTZORIGINATING)に対して索引が作成されます。
デフォルトの索引は、IAU_BASEの場合はEVENT_TIME_INDEX、コンポーネント表の場合はtableName_INDEX(OVDCOMPONENT_INDEX、OIDCOMPONENT_INDEX、JPS_INDEXなど)です。
コンプライアンスの規制では、監査データを長期間保存する必要があります。データを保護するには、バックアップおよびリカバリの計画が必要です。
優れたバックアップ計画を作成するには、次のような基本的なガイドラインを考慮します。
監査イベントの増加率
生成される監査イベントの数は、監査ポリシーによって決まります。監査データの消失を最小限に抑えるようバックアップを実行する頻度は、日々生成される監査イベントの数によって決まります。
コンプライアンスの規制
バックアップの実行頻度および監査データの必須保存年数は、各組織のコンプライアンス規制を参照して決定してください。
オンラインおよびオフラインのデータ管理
バックアップの実行頻度および簡単にアクセスできる必要がある監査データの割合は、各組織のコンプライアンス規制を参照して決定してください。
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
|
注意: 変換表 |
複数の監査データベースで開始した後、それらのデータベースを結合して単一の監査データ・ストアを構築する場合や、データベースを変更して規模を拡張する場合は、監査スキーマのインポートおよびエクスポートを実行して、データを移行することができます。
Oracle Databaseサイトでは、Oracle Data Pumpのユーティリティを使用してデータのインポートおよびエクスポートを実行できます。詳細は、次のサイトを参照してください。
http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html
すべてのデータベース・システムでパーティション化がサポートされているわけではなく、監査スキーマ内の表は、デフォルトではすべてパーティション化されていません。
監査データは累積され、古いデータが削除されることはありません。そのため、大量の監査データを格納する場合は、監査スキーマのパーティション化を考慮し、アーカイブ処理を容易にする必要があります。
パーティション化には、次のような利点があります。
パフォーマンスの向上: 表がタイムスタンプでレンジ・パーティション化されていると、たとえばタイムスタンプによる問合せを処理できるのは、該当する時間枠内のパーティションのみとなります。
管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、比較的古いデータは比較的遅くて大きなディスクに移動し、比較的新しいデータは比較的高速で小型のディスクに保持することができます。
また、パーティション化により、アーカイブ処理もはるかに容易になります。たとえば、表全体をパーティション化することなく、単一のパーティションを圧縮することができます。
可用性の拡張: 単一のパーティションが使用できない場合、たとえば問合せでそのパーティションを処理対象から外しても問題がないことが判明しているのであれば、使用できないパーティションを待つことなく、問合せを正常に処理することができます。
|
注意: この説明は11gリリース1(11.1.1.7)より前のリリースに適用されます。11gの新しいリリース1(11.1.1.7)のインストールではこれらの表を使用しないでください。 |
ここの例では、IAU_BASEを例として使用し、監査スキーマ内のパーティション化されていない表をパーティション化された表に変換する方法を示します。
アプリケーションの停止時間を最小化するため、監査データ・ストアにこのスキーマを使用する前にパーティション化を実行することをお薦めします。
|
注意: この製品には、サンプルのSQLスクリプトが2つ含まれています。
|
パーティション化の手順は、次のとおりです。
パーティション化されていない既存の表の名前を変更します。例:
RENAME IAU_BASE TO IAU_BASE_NONPART;
パーティション化されていない表の表構造に従う、新しいパーティション化された表を作成します。この例では、タイムスタンプによりレンジ・パーティション化するスキームを使用します。
CREATE TABLE IAU_BASE
PARTITION BY RANGE (IAU_TSTZORIGINATING)
(
PARTITION IAU_BASE_DEFAULT VALUES LESS THAN (MAXVALUE)
)
AS SELECT * FROM IAU_BASE_NONPART;
行の移動を有効にし、新しいパーティションの作成時にデータがパーティション間で自動的に移動できるようにします。例:
ALTER TABLE IAU_BASE ENABLE ROW MOVEMENT;
パーティション表のローカルな接頭辞索引を作成します。例:
ALTER INDEX EVENT_TIME_INDEX RENAME TO EVENT_TIME_INDEX_NONPART; CREATE INDEX EVENT_TIME_INDEX ON IAU_BASE(IAU_TSTZORIGINATING) LOCAL;
これでパーティションを作成できます。この例では、暦の四半期別にパーティションを作成します。
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.6.4項「バックアップとリカバリ」を参照してください。バックアップ・コピーが作成されているかぎり、データベースのバックアップ全体から読取り専用の表領域を除外することができます。そのため、それらの表領域上に存在するアーカイブ・データのパーティションに対するバックアップを反復的に実行する必要がなくなり、パフォーマンスが向上します。
インポートとエクスポートについては、第13.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');
パーティションを作成したら、特定のパーティションの消去またはバックアップを実行できます。詳細は、13.6.6.4項を参照してください。
データベース・モードの場合、バスストップ・ファイルは監査ローダーによって自動的に管理されます。
Oracle Fusion Middleware監査フレームワークでは、監査ストアからのレコードの削除を可能にするSQLスクリプトが提供されています。
スクリプトの場所
削除スクリプトは、次の場所にあります。
[Unix] RCU_HOME/rcu/integration/iau/scripts [Windows] RCU_HOME\rcu\integration\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> @auditDataPurge.sql DEV_IAU
レコードの削除と領域の再要求
監査レコードの削除と領域の再要求の両方を実行するには、auditDataPurge.sqlスクリプトを使用します。このスクリプトは2つのパラメータを使用します。
監査スキーマ・ユーザー
保持する日数 - 古いレコードは削除されます。
@auditDataPurge.sql audit_schema_user number_of_days_to_keep
例:
sqlplus> @auditDataPurge.sql DEV_IAU 100
100日より古いレコードをすべて削除し、領域を小さくするために行の移動を有効にします。
パーティション化により、それぞれのパーティション(またはパーティションのグループ)を、記憶域の様々な層に格納できます。表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成できます。また、パーティション内のデータを表領域(記憶域の層)間で移動することも容易です。
次に例を示します。
ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008 TABLESPACE AUDITARCHIVE UPDATE INDEXES;
|
注意: パーティションは、範囲、リスト、システムおよびハッシュのパーティション化スキームでのみ移動できます。 |
Oracle Information Lifecycle Management (ILM)はパーティション化と圧縮による合理化されたデータ管理を特徴としています。詳細は、次のサイトを参照してください。
http://www.oracle.com/us/technologies/information-lifecycle-management/overview/index.html
