この章では、日常的な監査管理タスクの実行方法を説明します。
監査管理者は、次の手順に従って、サイトの監査の設定を注意深く計画する必要があります。
実装の計画
これには、監査レコード用に使用するストアのタイプやデータ・ストアの詳細構成などの計画が含まれます。
詳細は、第11.2項「監査ストアの管理」を参照してください。
ポリシー管理
管理者は、必要な監査イベントが確実に生成されるように、適切な監査ポリシーを構成する必要があります。
アプリケーション環境の変化やコンポーネントおよびユーザーの追加などを監査ポリシーに反映する必要があるため、ポリシー管理は継続的なアクティビティになります。
詳細は、第11.3項「監査ポリシーの管理」を参照してください。
レポート管理
これには、監査レポートと監査問合せの計画と構成が含まれます。
詳細は、第12章「監査分析と監査レポートの使用」を参照してください。
データ管理
これには、企業ポリシーに基づいた、生成される監査データの格納に必要なデータベース・サイズの計画/増加、監査データのバックアップ、監査データの消去が含まれます。
監査ストアの管理の詳細は、第11.5項「データベース・ストアの拡張管理」を参照してください。
監査フレームワークでは、追加設定なしですぐに、ファイル・システムを使用して監査レコードを格納します。ただし、本番環境の場合、オラクル社では、データベース監査ストアを使用して、監査フレームワークのスケーラビリティと高可用性を実現するようお薦めしています。
また、データベース内の監査ストアを使用すると、Oracle Business Intelligence Publisherで使用可能な事前パッケージ済の監査レポートにより監査データを表示することができます。Oracle Business Intelligence Publisherは、11gリリース1(11.1.1)のCDパックで使用できます。
この項では、監査ストアの次のような管理タスクについて詳細に説明します。
監査レコードの永続的ストアとしてデータベースに切り替えるには、最初にリポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・ストアを作成する必要があります。
注意: バスストップ・ファイルは、データベース記憶域が存在しない場合の監査レコードの格納先になります。 |
この項では、監査スキーマの作成方法を説明します。データベース・スキーマの作成後は、次のことが可能になります。
このスキーマを指し示すデータソースを作成する。
ドメインの構成を更新し、監査レコードの監査ストアを切り替える(第11.2.3.2項「監査ストアの構成」を参照)。
注意: この説明では、RCUおよびデータベースが環境にインストール済であることを前提としています。詳細は、インストール・ガイドを参照してください。 |
開始する前に
作業を開始する前に、使用するデータベースの詳細情報を収集し、DBA資格証明を入手してください。
データベース・スキーマの構成
監査ストア用のスキーマを構成するには、次の手順を実行します。
$RCU_HOME/bin
に移動し、RCUユーティリティを実行します。
開始画面で「作成」を選択します。「次へ」をクリックします。
データベースの詳細情報を入力して、「次へ」をクリックします。
接頭辞の新規作成を選択して、IDM
などを入力します。
また、スキーマのリストから「監査サービス」を選択します。
「次へ」をクリックして、表領域の作成を承認します。
スキーマの作成中にエラーが発生していないか確認します。
このプロセスの完了には数分かかります。
第11.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
です。たとえば、接頭辞をtest
とした場合、スキーマ名はtest_iau
になります。
パスワード: RCUで作成した監査スキーマのパスワードです。
「次へ」をクリックします。
次のページに、JDBCドライバ・クラスとデータベースの詳細情報が表示されます。デフォルトを選択し、「構成のテスト」をクリックして、接続をテストします。「接続は正常に確立されました」というメッセージが表示されたら、「次へ」をクリックします。エラーが表示された場合は、接続の詳細情報に戻って確認します。
「ターゲットの選択」ページで、このデータソースを構成するサーバーを選択して、「終了」をクリックします。
スケーラビリティおよび高可用性を実現するために、監査データのOracle Real Application Clustersを構成できます。
詳細は、次のサイトを参照してください。
『Oracle Fusion Middleware高可用性ガイド』の「RACデータベース・ストアでの監査の設定」
『Oracle Fusion Middleware高可用性ガイド』の「WebLogic Serverによる監査データソースおよびマルチ・データソースの構成」
『Oracle Fusion Middleware高可用性ガイド』の「監査ローダーのためのJDBC文字列の構成」
『Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server』の「WebLogic Server とOracle RACの併用」
スキーマの作成が終わったら、次の操作から構成されるデータベースベースの監査ストアの構成を実行します。
作成した監査スキーマを指し示すデータソースの作成
データソースを指し示す監査ストアの構成
この項では、監査ストアの構成に関連する次のタスクを説明します。
注意: ここの手順で構成するのは、Javaコンポーネント用の監査ストアのみです。システム・コンポーネント用の監査ストアを構成するには、別の手順が必要です。第11.2.4項「システム・コンポーネント用のデータベース監査ストアの構成」を参照してください。 同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。 |
注意: このタスクは、Oracle Enterprise Manager Fusion Middleware Controlで実行します。 |
現在の監査ストアの構成を表示するには、ドメイン→「セキュリティ」→「監査ストア」に移動します。
このページには、次の項目が表示されます。
データベースが監査ストアとして構成されているかどうか。デフォルトでは、データベースは構成されておらず、監査レコードはバスストップ・ファイルに格納されています。
データソースのJNDI名: 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソースのJNDI名が表示されます。監査ストアが構成されていない場合、このフィールドは空になります。
データソース名: 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソース名が表示されます。監査ストアがファイルベースである場合、このフィールドは表示されません。
URL: 監査レコード用にデータベース・リポジトリが構成されている場合は、このフィールドにデータソースのURL(データベースへの接続に使用される接続文字列)が表示されます。監査ストアがファイルベースである場合、このフィールドは表示されません。
データソースの例は、第11.2.2項「監査データソースの設定」を参照してください。
監査レコードをファイルに格納する方式からデータベース監査ストアを使用する方式に変更できます。
監査ストアを構成するには、次の手順を実行します。
ドメイン→「セキュリティ」→「監査ストア」に移動します。「監査ストア」ページが表示されます。
「データソースのJNDI名」フィールドの横にあるサーチライトのアイコンをクリックします。
ダイアログ・ボックスが表示され、ドメイン内で監査レコード用に使用可能なデータソースのリストが表示されます。目的のデータソースを選択して、「OK」をクリックします。
選択されたデータソースが「データソースのJNDI名」フィールドに表示されます。「適用」をクリックして続行するか、「元に戻す」をクリックして更新を中止します。
注意: 監査ストアの設定は、WLSTsetAuditRepository() コマンドを使用して変更することもできます。詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。 |
ドメイン内のすべてのOracle WebLogic Serverを再起動します。これにより、Oracle WebLogic Server内の起動クラス監査ローダーが構成を再度読み込むことができます。
変更は、イベント収集をテストするよう監査ポリシーを設定することによりテストできます。たとえば、Oracle Platform Security Servicesの監査ポリシーを「中」に設定することもできます。詳細は、第11.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。
監査によって監査イベントが生成されるように、シナリオを実行します。たとえば、手順6で構成したポリシーに基づき、資格証明の作成によって監査レコードがトリガーされます。
サーバー・ログ内のエラーおよび例外をチェックします。
$DOMAIN_HOME/jrfServer_admin.outをチェックします。
$DOMAIN_HOME/servers/$SERVER_NAME/logs/をチェックします。
データベースは監査レコードの推奨ストアなので、データベースからファイル・モードへの切替えはお薦めできません。ただし、第11.3.4項「監査ポリシーの手動による管理」で説明するaudit.repositoryType
というプロパティの値をFile
に設定することで、ファイルに格納する方式に切り替えることができます。
注意: Fusion Middleware ControlやWLSTではデータベースからファイル・モードに切り替えることはできません。この切替えを実現するには、第11.3.4項「監査ポリシーの手動による管理」で説明するように、手動による構成が必要です。 |
データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。
Oracle Process Manager and Notification Server(OPMN)は、Oracle WebLogic Server内で実行されるいくつかのシステム・コンポーネントを管理します。これらのコンポーネントの場合、ローカルなバスストップ・ファイルからデータベース監査ストアに監査イベントがプッシュされるメカニズムは、OPMNによって処理されます。
注意: システム・コンポーネントがクラスタ化されたデプロイ内で実行される場合は、コンポーネントの各インスタンスにある監査ストアを、すべてのインスタンスがレコードを該当ストアにプッシュするよう構成する必要があります。 |
監査ストアを構成するには、コンポーネントの各インスタンスで、次の手順を実行する必要があります。
注意: ここの手順で構成するのは、システム・コンポーネント用の監査ストアのみです。Javaコンポーネント用の監査ストアを構成するには、別の手順が必要です。第11.2.3項「Javaコンポーネント用のデータベース監査ストアの構成」を参照してください。 同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。 |
次の場所にあるopmn.xml
ファイルを開きます。
$ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
次のような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>
監査ローダーの既存のRMD定義を置き換えます。変更する値は、次のものだけです。
jdbcString: これは、データベースJDBC接続文字列です。これをデフォルト文字列から有効な接続文字列に変更します。
username
interval: 監査レコードは、この間隔(秒)で、コンポーネントのバスストップ・ファイルから監査ストアにプッシュされます。
デフォルトでは、intervalに非常に大きな値(31536000秒)が設定されるので、監査ローダーは実質的に無効です。この値を、15(秒)のような妥当な値に変更します。
注意: これらの行を、<ias-instance> タグを閉じた後ろに挿入します。 |
ファイルを保存し、終了します。
ORACLE_HOME
、ORACLE_INSTANCE
およびCOMMON_COMPONENTS_HOME
が定義されていることを確認します。次に例を示します。
ORACLE_HOME = /u01/oracle/as11_oh ORACLE_INSTANCE = /u01/oracle/instances/instance COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common
監査ストアのパスワードをシークレット・ストアに移入します。これは、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を区切る":"を";"に置換します。 |
次のようにしてOPMNをリロードします。
$ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits) $ORACLE_INSTANCE/bin/opmnctl reload
監査対象コンポーネントでなんらかのシナリオを実行して、監査イベントを生成します。
$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コンポーネントのバスストップ・ファイルの最大サイズを制御します。
第11.3.4項「監査ポリシーの手動による管理」で説明しているとおり、このサイズはバイト単位で指定します。
システム・コンポーネント
ファイル記憶域モードのファイルのサイズは、auditconfig.xmlファイル内で設定できます。第11.3.4.4項「システム・コンポーネント用の監査の手動構成」を参照してください。
注意: 監査データをファイルからデータベース・ストアに切り替えると、監査ファイルに収集されたすべてのイベントがデータベース表にプッシュされ、監査ファイルが削除されます。 |
ディレクトリ・サイズ
Javaコンポーネント
ファイルのディレクトリのサイズは、構成ファイルjps-config.xml
で示されているmax.DirSize
プロパティを使用して管理できます。このプロパティは、バスストップ・ディレクトリの最大サイズを制御します。
第11.3.4項「監査ポリシーの手動による管理」で説明しているとおり、このサイズはバイト単位で指定します。
システム・コンポーネント
ファイル記憶域モードのディレクトリのサイズは、auditconfig.xmlファイル内で設定できます。第11.3.4.4項「システム・コンポーネント用の監査の手動構成」を参照してください。
監査ポリシーとは
監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。
たとえば、監査ポリシーでは、Oracle Internet Directoryインスタンスに対するすべての認証の失敗を監査するように指定することができます。
ポリシーの構成方法
Oracle Fusion Middleware監査フレームワークを使用すると、監査ポリシーを構成し、監視対象のイベントおよびデータのタイプをきわめて詳細に制御することができます。ポリシーは、Enterprise ManagerのUIツールおよびWLSTコマンドライン・インタフェースを使用して構成できます。
ポリシーの変更にはサーバーまたはインスタンスの再起動が必要
監査ポリシーを作成または更新する際は、次の点に注意してください。
Javaコンポーネントの場合、ドメイン・レベルでポリシーを変更するには、(影響を受けるコンポーネントおよびアプリケーションが実行されている)すべての管理対象サーバーを再起動する必要があります。
システム・コンポーネントの場合、ポリシーを変更するには、影響を受けるコンポーネント・インスタンスを再起動する必要があります。
この項の残りの部分では、監査ポリシーの表示および更新方法を説明します。
関連項目:
|
ドメインの「監査ポリシー設定」ページでは、Oracle Identity FederationなどのすべてのJavaコンポーネントの監査イベントと、Oracle Platform Security Servicesなどのシステム・ライブラリの監査イベントを管理します。
注意:
|
各コンポーネントとそのイベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。
現在構成されている監査ポリシーを表示および更新するには、次の手順を実行します。
Fusion Middleware Controlにログインします。
左側のトポロジ・パネルを使用して、「WebLogicドメイン」の下の目的のドメインに移動します。
ドメイン・メニューで、「ドメイン
」→「セキュリティ
」→「監査ポリシー設定
」に移動します。「監査ポリシー設定」ページが表示されます。
事前構成済監査レベルのドロップダウン・リストを選択できます。2つの事前定義済レベル(「低」、「中」)では、すべてのコンポーネントの監査イベントのサブセットを自動的に選択します。ほとんどの場合は、事前定義済のレベルで十分です。
注意: 事前定義済レベルについて、ドロップダウン・ボックスの下のイベントの表を編集することはできません。編集できるのは、カスタム・レベルのみです。 |
なし: 監査対象のイベントは選択されません。
低: 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。
中: 「低」のイベント・セットのスーパーセットです。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。
カスタム: このレベルではポリシーを微調整できます。後述の手順5を参照してください。
次の表は、ドメイン内で実行中のアプリケーションを示しています。
表は、次の列から構成されています。
名前: ドメイン内のコンポーネントとアプリケーションが表示されます。
監査の有効化: 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。
フィルタ: イベント・タイプで有効なフィルタが表示されます。
監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。ここでは、すべてのイベントを選択するか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択することができます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用でき、後述の手順6に示すように、監査方法をより詳細に制御できます。
フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。
アイコンをクリックし、「フィルタの編集」ダイアログを表示します。
注意: 各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。 |
「障害のみ選択」ボタンをクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。
インポート/エクスポート: これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。
必要に応じ、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。
注意:
|
ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。Javaコンポーネントの場合、この変更を有効にするには、管理対象Oracle WebLogic Server(影響を受けるJavaコンポーネントが実行されている)を再起動する必要があります。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。
コンポーネント・イベントについて
ドメイン内の各コンポーネントおよびアプリケーションでは、監査可能なイベントの独自のセットを定義します。そのため、表の「名前」列を開くと、コンポーネントごとにそのコンポーネントのインスタンスに適用されるイベントのリストが表示されます。
この項では、OPMNを使用して管理されるシステム・コンポーネントの監査ポリシーを表示および更新する方法を説明します。
注意:
|
システム・コンポーネントの監査ポリシーは、それぞれのホーム・ページで管理されます。ドメインの「監査ポリシー設定」ページでは、ドメイン内で実行されるJavaコンポーネントの監査イベントを管理します。
イベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。
OPMN管理コンポーネントの監査ポリシーを表示および更新するには、次の手順を実行します。
Fusion Middleware Controlにログインします。
左側のトポロジ・パネルを使用して、Oracle Internet Directoryなど、目的のシステム・コンポーネントに移動します。
コンポーネント・メニューで、「セキュリティ
」→「監査ポリシー
」に移動します。「監査ポリシー設定」ページが表示されます。
事前構成済監査レベルのドロップダウン・リストを選択できます。2つの事前定義済レベル(「低」、「中」)では、すべてのコンポーネントの監査イベントのサブセットを自動的に選択します。
注意: 事前定義済レベルについて、ドロップダウン・ボックスの下のイベントの表を編集することはできません。カスタム・レベルでの編集のみが可能です。 |
なし: 監査対象のイベントは選択されません。
低: 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。
中: 「低」のイベント・セットのスーパーセットです。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。
カスタム: このレベルではポリシーを微調整できます。後述の手順5を参照してください。
次の表は、コンポーネント・インスタンスに対して監査できるイベントを示しています。この例は、Oracle Internet Directoryの場合です。
表は、次の列から構成されています。
名前: タイプ別にまとめられたコンポーネント・イベント(認可イベントなど)が表示されます。
監査の有効化: 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。
フィルタ: イベント・タイプで有効なフィルタが表示されます。
監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。ここでは、すべてのイベントを選択できるほか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択することもできます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用でき、後述の手順6に示すように、監査方法をより詳細に制御できます。
フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。
アイコンをクリックし、「フィルタの編集」ダイアログを表示します。
注意: 各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。 |
「障害のみ選択」をクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。
インポート/エクスポート: これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。
オプションで、「常に監査するユーザー」の下にあるユーザーのカンマ区切りリストを指定し、監査フレームワークでこれらのユーザーによって起動されたイベントを監査するようにすることができます。監査は、指定された監査レベルやフィルタに関係なく行われます。
注意:
|
ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。
この項では、Oracle WebLogic Scripting Tool(WLST)コマンドライン・ツールを使用して監査ポリシーの表示や更新を実行する方法を説明します。
注意: 監査のためのWLST コマンドを実行するときには、Oracle CommonホームからWLST スクリプトを呼び出す必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のカスタム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()
システム・コンポーネントの場合:
getNonJavaEEAuditMBeanName
コマンドを使用してMBean名を取得します。詳細は、第C.4.1項「getNonJavaEEAuditMBeanName」を参照してください。
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 Serverに接続します。
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コマンド・リファレンスを参照してください。 |
このシナリオでは、ドメインの現在のポリシーにより、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
内の監査サービス構成は、表11-1に示すプロパティで構成されています。一連のプロパティとそれらの値は、まとめて監査ポリシーと呼ばれています。
表11-1 jps-config.xml内の監査プロパティ
プロパティ | 説明 | 例 |
---|---|---|
audit.filterPreset |
監査のレベル: None、Low、Medium、Custom |
|
audit.customEvents |
Customの場合、監査の対象となる監査イベントのリスト。イベントは、コンポーネント・タイプを使用して修飾する必要があります。イベントはカンマ、コンポーネント・タイプはセミコロンで区切ります。 |
JPS:CheckAuthorization, CreateCredential; OIF:UserLogin |
audit.specialUsers |
アクティビティが常に監査の対象となる1名以上のユーザーから構成されるリスト(filterPresetがNoneの場合も有効)。 |
カンマが含まれるユーザー名は、適切にエスケープ処理する必要があります。たとえば、Fusion Middleware Controlを使用する場合、3名のユーザーは"admin, fmwadmin, cn=test\,cn=user\,ou:ST\,L=RS\,c=is\,"のように指定します。
setAuditPolicy(addSpecialUsers="cn=orcladmin\\\,cn=com") 詳細は、第C.4.3項「setAuditPolicy」を参照してください。 |
audit.loader.repositoryType |
監査イベントのストア・タイプ。タイプがDatabase(DB)の場合は、audit.loader.jndiプロパティも定義する必要があります。 |
FileまたはDB |
audit.loader.jndi |
DBの場合は、監査イベントがアップロードされるjndiデータソース |
jdbc/AuditDB |
audit.loader.interval |
データベースへの監査ローダーのアップロードの頻度を制御します(秒単位)。 |
15 |
audit.maxDirSize |
監査ファイルが書き込まれるディレクトリのサイズを制御します(バイト単位)。 |
102400000 |
audit.maxFileSize |
監査イベントが書き込まれるバスストップ・ファイルのサイズを制御します(バイト単位)。 |
10240000 |
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>
まれですが、監査レコードに対して(データベース)データ・ストアを使用する方式からファイルを使用する方式に戻したい場合もあります。その場合は、表11-1で示したプロパティ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,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>
この項の内容は次のとおりです。
Fusion Middleware監査フレームワークでは、監査管理に役立つように、一連のログ・ファイルを提供しています。それらのログを使用すると、監査フレームワークが正しく機能しないときに、エラーをトレースしたり、診断を行うことができます。
すべての監査ログの場所のリスト、ログ出力の構成方法およびログによる問題の診断方法は、第J.1.1.3項「監査診断のログ・ファイル」を参照してください。
監査ログのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。
監査スキーマは、リポジトリ作成ユーティリティ(RCU)によって作成されます。この項では、監査スキーマの編成について説明し、スキーマの管理に関する次のトピックについて説明します。
関連項目: RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。 |
Oracle Fusion Middleware監査フレームワークのスキーマは、次のものから構成されています。
実表: IAU_BASE
変換表: IAU_DISP_NAMES_TL
監査データから構成される、コンポーネントに固有な一連の表(OVDCOMPONENT
、OIDCOMPONENT
、JPS
など)
監査レコードは生成時、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" - "[]" - - - -
図11-1は、実表内のデータと、それがコンポーネントに固有な表にどのように関係しているのかを示しています。
実表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
(各コンポーネント表用)
表11-2に、実表IAU_BASE
で定義されている重要な属性をいくつか示します。最初の4つの属性は、その実表とすべてのコンポーネント表に共通する属性です。主キーは、IAU_ID + IAU_TSTZORIGINATING
として定義されます。
表11-2 実表IAU_BASEの属性
属性 | 説明 |
---|---|
IAU_ID |
各監査レコードの一意な連番 |
IAU_TstzOriginating |
監査イベントが生成された日付と時刻(データ型 |
IAU_EventType |
監査イベントのタイプ(名前) |
IAU_EventCategory |
監査イベントのカテゴリ |
IAU_EventStatus |
監査イベントの結果(失敗または成功) |
IAU_MessageText |
監査イベントの説明 |
IAU_Initiator |
操作を実行していたユーザーのUID |
注意: Oracleデータベース・オブジェクトの1つであるSEQUENCE は、監査レコードの連番(IAU_ID )の割当てを調整するために作成されます。 |
WLSTコマンド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
注意: 変換表IAU_DISP_NAMES_TL は、時間が経過しても変化しないため、バックアップの実行は一度だけで十分です。 |
複数の監査データベースで開始した後、それらのデータベースを結合して単一の監査ストアを構築する場合や、データベースを変更して規模を拡張する場合は、監査スキーマのインポートおよびエクスポートを実行して、データを移行することができます。
Oracle Databaseサイトでは、Oracle Data Pumpのユーティリティを使用してデータのインポートおよびエクスポートを実行できます。詳細は、次のサイトを参照してください。
http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html
すべてのデータベース・システムでパーティション化がサポートされているわけではなく、監査スキーマ内の表は、デフォルトではすべてパーティション化されていません。
監査データは累積され、古いデータが削除されることはありません。そのため、大量の監査データを格納する場合は、監査スキーマのパーティション化を考慮し、アーカイブ処理を容易にする必要があります。
パーティション化には、次のような利点があります。
パフォーマンスの向上: 表がタイムスタンプでレンジ・パーティション化されていると、たとえばタイムスタンプによる問合せを処理できるのは、該当する時間枠内のパーティションのみとなります。
管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、比較的古いデータは比較的遅くて大きなディスクに移動し、比較的新しいデータは比較的高速で小型のディスクに保持することができます。
また、パーティション化により、アーカイブ処理もはるかに容易になります。たとえば、表全体をパーティション化することなく、単一のパーティションを圧縮することができます。
可用性の拡張: 単一のパーティションが使用できない場合、たとえば問合せでそのパーティションを処理対象から外しても問題がないことが判明しているのであれば、使用できないパーティションを待つことなく、問合せを正常に処理することができます。
ここの例では、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;
注意: 新しい四半期別に合わせて定期的に、新しいパーティションを作成する必要があります。 |
バックアップとリカバリについては、第11.5.4項「バックアップとリカバリ」を参照してください。バックアップ・コピーが作成されているかぎり、データベースのバックアップ全体から読取り専用の表領域を除外することができます。そのため、それらの表領域上に存在するアーカイブ・データのパーティションに対して、不要なバックアップを繰り返して実行する必要がないので、パフォーマンスが向上します。
インポートとエクスポートについては、第11.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');
パーティションを作成したら、特定のパーティションの消去およびバックアップを実行できます。詳細は、データベースのドキュメントを参照してください。
データベース・モードの場合、バスストップ・ファイルは監査ローダーによって自動的に管理されます。
パーティション化により、それぞれのパーティション(またはパーティションのグループ)を、記憶域の様々な層に格納できます。表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成できます。また、パーティション内のデータを表領域(記憶域の層)間で移動することも容易です。
次に例を示します。
ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008 TABLESPACE AUDITARCHIVE UPDATE INDEXES;
注意: パーティションは、範囲、リスト、システムおよびハッシュのパーティション化スキームでのみ移動できます。 |
Oracle Information Lifecycle Management(ILM)Assistantという無料ツールを使用すると、表をパーティション化する方法を知ることができ、パーティションを移動する時期についての助言が得られます。詳細は、次のサイトを参照してください。