| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
前 |
次 |
この章では、主要な管理タスクと、監査ストア、監査ポリシーおよびバスストップ・ファイルの管理に使用するツールについて説明します。
この章の内容は次のとおりです。
環境での監査の設定では、次の主なタスクを実行します。
監査レコードに使用するストアのタイプやストア構成の詳細の計画。監査ストアの管理の詳細は、「監査ストアの管理」を参照してください。
監査イベントが生成されるようにするための監査ポリシーの構成およびメンテナンス。監査ポリシーの詳細は、「監査ポリシーの管理」を参照してください。
監査レポートおよび監査問合せの構成。レポートの詳細は、第15章「監査分析と監査レポートの使用」を参照してください。
アプリケーションの登録。アプリケーション登録の詳細は、第22.3項「サービスへのアプリケーションの登録」を参照してください。
監査情報の移行。監査データの移行の詳細は、第6.6.3項「監査データの移行」を参照してください。
監査データベースの管理(生成された監査データを格納するデータベースのサイズの増加やそのデータのバックアップおよびパージを含む)監査の管理の詳細は、「監査データベースの管理」を参照してください。
監査ストアは、監査レコードの格納に必要なスケーラビリティと高可用性を備え、レポートの表示および生成を可能にするデータベースです。
次の各項では、監査ストアとその管理方法について説明します。
ドメインを作成すると、データベースに監査レコードを格納するために必要なデータ構造である監査スキーマが生成されます。また、監査スキーマを使用するサーバーで監査データ・ソースが設定されます。レコードを格納するデータベースを使用して環境を設定しないと、監査レコードはバスストップ・ファイルに格納されます。
バスストップ・ファイルが一定のサイズに到達し、すべてのデータがデータベースにアップロードされると、監査ローダーによってファイルはファイル・システムから削除されます。バスストップ・ファイルの場所および最大サイズを指定し、バスストップ・ファイルが自動的に削除されるようにします。監査ファイルを手動で削除することは、お薦めしません。
バスストップ・ファイルの場所
Javaコンポーネント用のバスストップ・ファイルは、次のディレクトリにあります。
$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type
システム・コンポーネント用のバスストップ・ファイルは、次のディレクトリにあります。
$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name
バスストップ・ファイルのサイズ
Javaコンポーネントでは、バスストップ・ファイルの最大サイズはaudit.maxFileSizeプロパティを使用して設定します。
システム・コンポーネントでは、バスストップ・ファイルの最大サイズはauditconfig.xmlファイルで設定します。
<serviceInstance name="audit" provider="audit.provider"> <property name="audit.maxFileSize" value="10240" /> <property name=" audit.loader.repositoryType " value="Db" /> </serviceInstance>
監査データ用のストアをファイルからデータベースに切り替えると、ファイルに収集されたイベントはすべてデータベース表に移動され、監査ファイルは削除されます。
スタンドアロン監査ローダーは、レコードをバスストップ・ファイルから監査ストアに定期的に移動します。監査ローダーを駆動するメカニズムは、アプリケーション環境に応じて変わります。
Java EEコンポーネントおよびアプリケーションでは、OPSSランタイムによって提供される監査ローダー機能を使用します。スタンドアロン監査ローダーはそのような環境では不要です。
システム・コンポーネントおよび非Javaアプリケーションでは、StandAloneAuditLoaderコマンドによって提供される監査ローダー機能を使用します。
Java SEアプリケーションでは、バスストップ・ファイルが書き込まれる場所に応じて、スタンドアロン監査ローダーを使用することもあります。Java SEアプリケーション用の監査の詳細は、第24.5.4項「Java SEアプリケーションでの一般的な監査シナリオ」を参照してください。
次の各項では、スタンドアロン監査ローダーの設定および実行方法について説明します。
次の設定は、非Javaアプリケーションおよびシステム・コンポーネントにのみ適用されます。
スタンドアロン監査ローダーを実行する前に、次の監査ローダーのパラメータを設定します。
ORACLE_HOME: ホーム・ディレクトリへのフルパス
COMMON_COMPONENTS_HOME: Java Required Files (JRF)ディレクトリへのフルパス
ORACLE_INSTANCE: Oracleインスタンス・ディレクトリへのフルパス
auditloader.jdbcString: 監査データが格納されるデータベースのJava Database Connectivity (JDBC)接続文字列
auditloader.username: 監査ローダーを実行するユーザーの名前
さらに、データベース・スキーマ・ユーザーのパスワードが使用可能であり、格納されていることを確認します。このパスワードは1回指定します。
データベース・スキーマ・ユーザーのパスワードを指定するには、Java StandAloneAuditLoaderコマンドを-Dstore.password=trueプロパティを指定して使用します。
$JDK_HOME/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.2.1/jps-manifest.jar
-Doracle.home=$ORACLE_INSTANCE -Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
-Dstore.password=true
oracle.security.audit.ajl.loader.StandaloneAuditLoader
パスワードの入力を求められます。コマンドにより、入力したパスワードを含むcwallet.ssoファイルが生成されます。
ローダーを実行するには、StandAloneAuditLoaderコマンドを使用します。
$JDK_HOME/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.2.1/jps-manifest.jar
-Doracle.home=$ORACLE_INSTANCE -Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
oracle.security.audit.ajl.loader.StandaloneAuditLoader
このコマンドは通常、監査レコードが監査ストアに定期的にアップロードされるように、自動的に実行されるようスケジュールされます。
監査ポリシーとは、特定のコンポーネントについてOracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)によって記録されるイベントのタイプの宣言です。Javaコンポーネントでは、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントでは、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。
コンポーネントやユーザーを追加したり、削除するなど、アプリケーション環境を変更した場合は、監査ポリシーを更新する必要があることに注意してください。ポリシーの変更にはサーバーまたはインスタンスの再起動は不要です。
OFM監査フレームワークを使用すると、監査ポリシーを構成でき、監視対象のイベントおよびデータのタイプはきめ細かく制御されます。監査ポリシーは、次の各項で説明しているように、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)、WebLogic Scripting Tool (WLST)またはプログラムを使用して構成します。
この項に記載されている手順に従って、Fusion Middleware Controlを使用してJavaコンポーネントおよびシステム・コンポーネントの監査ポリシーを管理します。
タスク1: 「監査」ページのオープン
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「監査ポリシー」の順に移動します。「監査ポリシー」ページが表示されます。
タスク2: Javaコンポーネント用の監査対象イベントの選択
「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
|
注意: 「監査ポリシー設定」領域で入力する値は、Oracle Access Manager監査には適用されません。 |
「監査レベル」ドロップダウンで、ニーズに応じて監査レベルを選択します。
なし - イベント・カテゴリを選択しません。
低、中、高 - 事前に定義された監査レベルを表すイベント・カテゴリのサブセットを選択します。
カスタム - カスタム・フィルタを選択します。
チェック・フラグが「監査用に選択」列に表示され、選択したカテゴリのイベントが監査対象となります。フラグ付きカテゴリ内のイベントを表示するには、カテゴリ表でその行をクリックします。イベントの表はカスタム・レベルでのみ編集できます。
タスク3: Javaコンポーネント用の監査ポリシーのカスタマイズ
「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
「監査レベル」ドロップダウンで、「カスタム」を選択します。すべてのカテゴリが使用可能になります。
「監査用に選択」列のボックスを選択して、監査ポリシーをカスタマイズするカテゴリおよびイベントを選択します。
「適用」をクリックして変更を保存します。
タスク4: Javaコンポーネント用の監査フィルタの作成
「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
「フィルタの編集」列の鉛筆アイコンは、そのイベントでフィルタを使用できることを示します。イベントの鉛筆アイコンをクリックします。「フィルタの編集」ダイアログが表示されます。
各フィルタ属性には、正式名と表示名があります。いずれかの名前が「フィルタの編集」編集ダイアログに表示されます。
「条件」ドロップダウンから項目を選択し、さらに演算子と値を選択してフィルタ条件を作成します。次に、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックします。
必要に応じて、「常に監査するユーザー」で、ユーザーのカンマ区切りリストを指定し、そのユーザーによって起動されるイベントを監査します。監査は、指定された監査レベルやフィルタとは関係なく行われます。このフィールドに入力するユーザー名は検証されません。
Javaコンポーネントが実行されているOracle WebLogic Serverを再起動し、変更を反映します。
タスク5: Javaコンポーネント用の監査ポリシーのインポートとエクスポート
「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
ポリシーを編集している間、いつでも次のいずれかを実行できます。
「エクスポート」をクリックして現在の設定をファイルに保存します。
「インポート」をクリックしてファイルから設定をロードします。
タスク6: システム・コンポーネント用の監査対象イベントの選択
システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
「監査レベル」ドロップダウンで、監査レベルを選択します。
なし - イベント・カテゴリを選択しません。
低、中、高 - 事前に定義された監査レベルを表すイベント・カテゴリのサブセットを選択します。
カスタム - カスタム・フィルタを選択します。
チェック・フラグが「監査用に選択」列に表示され、選択したカテゴリのイベントが監査対象となります。フラグ付きカテゴリ内のイベントを表示するには、カテゴリ表でその行をクリックします。イベントの表はカスタム・レベルでのみ編集できます。
タスク7: システム・コンポーネント用の監査ポリシーのカスタマイズ
システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
「監査レベル」ドロップダウンで、「カスタム」を選択します。すべてのカテゴリが使用可能になります。
「監査用に選択」列のボックスを選択して、監査ポリシーをカスタマイズするカテゴリおよびイベントを選択します。
「適用」をクリックして変更を保存します。
タスク8: システム・コンポーネント用の監査フィルタの作成
システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
「フィルタの編集」列の鉛筆アイコンは、そのイベントでフィルタを使用できることを示します。イベントの鉛筆アイコンをクリックします。「フィルタの編集」ダイアログが表示されます。フィルタ属性には、正式名と表示名があります。いずれかの名前が「フィルタの編集」編集ダイアログに表示されます。
「条件」ドロップダウンから項目を選択し、さらに演算子と値を選択してフィルタ条件を作成します。次に、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックします。
必要に応じて、「常に監査するユーザー」で、ユーザーのカンマ区切りリストを指定し、そのユーザーによって起動されるイベントを監査します。監査は、指定された監査レベルやフィルタとは関係なく行われます。このフィールドに入力するユーザー名は検証されません。システム管理者などの特定のユーザーがコンポーネントの監査可能なイベントを実行するときはいつでも監査トラフィックが発生します。
システム・コンポーネントが実行されているWebLogic Serverを再起動します。
タスク9: システム・コンポーネント用の監査ポリシーのインポートとエクスポート
システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。
ポリシーを編集している間、いつでも次のいずれかを実行できます。
「エクスポート」をクリックして現在の設定をファイルに保存します。
「インポート」をクリックしてファイルから設定をロードします。
この項に従って、WLSTを使用して監査ポリシーを管理します。
WebLogic Serverに接続します。
>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')
ドメインまたはJavaコンポーネントの監査ポリシーを表示するには、getAuditPolicyコマンドを使用します。
(view domain audit policies) wls:/mydomain/serverConfig> getAuditPolicy() (view component audit policies) wls:/mydomain/serverConfig> getAuditPolicy(componentType="JPS")
システム・コンポーネントの監査ポリシーを表示するには、次のようにします。
getNonJava EEAuditMBeanNameコマンドを使用してシステム・コンポーネントMBean名を取得します。
getAuditPolicyコマンドを使用します。
wls:/mydomain/serverConfig> getAuditPolicy (on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")
次のように、WebLogic Serverに接続します。
>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')
階層を移動し、目的のドメインにアクセスします。
wls:/mydomain/serverConfig>
setAuditPolicyコマンドを使用して、監査ポリシーの構成を更新します。
システム・コンポーネントの場合は、setAuditPolicyコマンドを使用し、MBean名を含めると、監査ポリシーの構成が更新されます。監査MBeanの名前の書式は次のとおりです。
oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=INSTANCE,component=COMPONENT_NAME
例:
oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=instance1,component=oid1
Oracle HTTP ServerやLDAPなどのシステム・コンポーネントの場合は、setAuditPolicyコマンドまたはimportAuditConfigコマンドの発効後にsaveを明示的にコールします。
次の例では、この手順を示します。つまり、ツリーのルート・プロキシMBeanに移動し、invokeコマンドを使用してsetAuditPolicyをコールし、saveコマンドを使用しています。
ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('username', 'password', 'protocol://localhost:7001', 'localhost:7001')
custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=oid1,instance=instance1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],
java.lang.String))
setAuditPolicy(filterPreset='None',
on='oracle.as.management.mbeans.register:type=component.auditconfig,
name=auditconfig1,instance=instance1,component=oid1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],
java.lang.String))
ドメインの現在のポリシーによってuser1というユーザーが監査されていますが、常に監査対象とするユーザーのリストに2つの名前(user2およびuser3)を追加し、監査対象ユーザーのリストからuser1を削除することにします。
このようなタスクを実行するには、次のコマンドを実行します。
setAuditPolicy (filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")
ドメインの現在のポリシーによってユーザーのログアウト・イベントが監査されていますが、ログアウト・イベントを削除し、監査ログイン・イベントを追加することにします。
このようなタスクを実行するには、次のコマンドを実行します。
setAuditPolicy (on="OHS mbean name")
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")
イベントを追加および削除するために、Custom事前設定済フィルタがコールされたことに注意してください。
カスタム監査レベルで監査を構成し、WLSTを使用して別の(カスタム以外の)監査レベルに切り替えても、明示的に削除しないかぎり、カスタム監査設定は保持されます。
次の手順では、監査レベルの変更が監査データ・コレクションにどのように影響するかを示します。
カスタム監査レベルはコンポーネントのポリシーで設定し、監査フィルタを構成の一部として指定します。
実行時に、フィルタに従って監査データが収集されます。
setAuditPolicyコマンドを使用して、たとえばコンポーネントの監査ポリシーをカスタム監査レベルから低監査レベルに変更します。カスタム監査レベルの一部として設定されたフィルタは監査構成に残ります。
それ以降、監査データは低監査レベルに基づいて収集されます。
コンポーネントの監査ポリシーをカスタム・レベルに戻し、追加フィルタを追加します。この新しいフィルタは、元のフィルタに追加されます。元のフィルタを明示的に削除しないかぎり、このフィルタは構成の中で保持されます。
それ以降、監査データはカスタム・レベルの両方のフィルタに基づいて収集されます。
OFM監査フレームワークには、アプリケーションで監査ポリシーの取得および更新に使用できる一連のインタフェースが用意されています。ポリシーの管理の詳細は、第22.4項「プログラムによるポリシーの管理」を参照してください。
リリース11.1.1.7.0より前の監査では、アプリケーション・サーバーのタイムゾーンを使用して監査レコードが書き出されていました。リリース11.1.1.7.0以降、監査およびサーバーでは別のタイムゾーンを使用することもできます。つまり、次のことを意味します。
新しいサイトは、監査イベントが協定世界時(UTC)で書かれているとみなします。
リリース11.1.1.6.0からアップグレードされたサイトは、UTCの使用を明示的に指定しないかぎり、デフォルトでは、監査レコードに対してアプリケーション・サーバーのタイムゾーンを引き続き使用します。
バスストップ・ファイル内のレコードは、UTCを使用します。
新しいサイトでの監査タイムスタンプ
新しいインストールでは、監査レコードはUTCタイムスタンプを使用します。それは、監査構成でaudit.timezoneプロパティを使用して指定します。
<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>
アップグレードされたサイトでの監査タイムスタンプ
リリース11.1.1.7より前の監査レコードは、アプリケーション・サーバーのタイムスタンプを使用していました。そのリリースからアップグレードした後も、サービスの構成に変更はなく、デフォルトでは、レコードはアプリケーション・サーバーのタイムスタンプを使用して書き込まれます。
12cへのアップグレード後にUTCを使用する場合は、不一致の可能性を回避するために現在のレコードを移動し、audit.timezoneサービス・プロパティを構成ファイルに挿入します。
OFM監査フレームワークには、エラー・メッセージをログに記録する実行時コンポーネントがいくつかあります。このフレームワークには、OFM監査フレームワークで例外が発生した場合に、エラーのトレースや障害の診断に使用する一連のログ・ファイルが用意されています。
監査のバスストップ・ファイルのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。
この項の次のトピックでは、監査スキーマの編成および管理について説明します。
OFM監査フレームワーク・スキーマの表は、次のものから構成されています。
実表の基本データ。この表には監査レコードの基本データが含まれており、IAU_ID属性を使用してコンポーネント固有の表に関連づけられています。
IAU_COMMON表の共通属性。この表には監査レコードの基本データが含まれており、IAU_ID属性を使用してカスタム表に関連づけられています。
専用表の汎用属性。
IAU_CUSTOM_nnn表のカスタム属性。
同時にこれらすべての表が使用されるわけではありません。動的モデルでは、共通表とカスタム表を使用しています。静的(従来の)モデルでは、実表とコンポーネント固有の表を使用しています。
監査ローダーにより、2種類のデータ・レコードが表に格納されます。
一般的な情報(時間、イベント・タイプ、イベント・ステータスなど): 共通表(動的モデル)または実表の1行に格納されます。
コンポーネント固有の情報: カスタム表(動的モデル)またはコンポーネント表の1行に格納されます。
平均的な監査レコード・サイズは約0.3KBです。この平均値は、データベース表のサイズ変更を計画する際の他、監査データベース・サイズがポリシーおよびアクティビティのレベルに応じて増加する様子を監視する際に使用します。
実表の属性は次のファイルから導出されます。
$ORACLE_HOME/modules/oracle.iau_12.2.1/components/generic/generic_events.xml
コンポーネント表の属性は次のファイルから導出されます。
$ORACLE_HOME/modules/oracle.iau_12.2.1/components/componentName/component_events.xml
表C-6に、IAU_BASE実表で定義されている属性を示します。表C-7に、IAU_COMMON共通表で定義されている属性を示します。
個々のコンポーネント表の属性名リストを取得するには、listAuditEvents WLSTコマンドを使用します。
効率よく問い合せるために、実表IAU_TSTZORIGINATING列およびコンポーネント固有の各表に対して索引がデフォルトで作成されます。
デフォルトの索引は、IAU_BASEではEVENT_TIME_INDEX、コンポーネント表ではtableName_INDEX (OVDCOMPONENT_INDEX、OIDCOMPONENT_INDEX、JPS_INDEXなど)です。
共通表の追加の列および索引は次のとおりです。
IAU_TSTZORIGINATING: 索引はDYN_EVENT_TIME_INDEX
IAU_AuditUser: 索引はDYN_USER_INDEX
IAU_ComponentType: 索引はDYN_COMPONENT_TYPE_INDEX
IAU_EventCategory: 索引はDYN_EVENT_CATEGORY_INDEX
IAU_EventType: 索引はDYN_EVENT_TYPE_INDEX
監査データベースのバックアップを計画する際、次の点を考慮します。
監査イベントの増加率
フレームワークで生成される監査イベントの数は監査ポリシーによって決まり、ストアをバックアップする頻度は日々生成される監査イベントの数によって決まります。
コンプライアンスの規制
バックアップの実行頻度および監査データの必須保存年数は、各組織のコンプライアンス規制を参照して決定してください。
Oracle DatabaseユーティリティのRecovery Manager (RMAN)を使用してOracle Databaseをバックアップおよびリカバリします。IAU_DISP_NAMES_TL変換表は通常、時間の経過とともに変化しないため、バックアップが必要なのは1回のみです。
たとえば、複数の監査リポジトリを結合して単一の監査ストアとする場合やデータベースの規模を拡大する場合は、監査スキーマをインポートおよびエクスポートしてデータを移行します。Oracle Data Pumpを使用してOracle Databaseからデータをインポートおよびエクスポートします。
フレームワークには、監査ストアからレコードをパージするために、次のSQLスクリプトが$MW_HOME/oracle_common/common/sql/iau/scriptsディレクトリに用意されています。
auditDataPurge.sql
auditDeleteData.sql
auditReclaimSpace.sql
他のアクションを実行せずにレコードを削除するには、auditDeleteData.sqlを使用します。このスクリプトの構文は次のとおりです。
auditDeleteData.sql audit_schema_user number_of_days_to_keep
たとえば、100日を超過したレコードを削除するには、次のようにします。
sqlplus> @auditDeleteData.sql DEV_IAU 100
領域を再要求するには、auditReclaimSpace.sqlを使用します。このスクリプトの構文は次のとおりです。
auditReclaimSpace.sql audit_schema_user
監査レコードを削除して領域を再要求するには、auditDataPurge.sqlを使用します。このスクリプトの構文は次のとおりです。
auditDataPurge.sql audit_schema_user number_of_days_to_keep
たとえば、100日を超過したレコードをすべて削除し、領域を小さくするために行の移動を有効にするには、次のようにします。
sqlplus> @auditDataPurge.sql DEV_IAU 100
すべてのデータベース・システムでパーティション化がサポートされているわけではなく、デフォルトでは、監査スキーマ内の表はすべてパーティション化されていません。
監査データは時間の経過とともに増えるため、大量のデータを格納する場合は、アーカイブが容易になるように監査スキーマのパーティション化を検討します。
パーティション化には、次のような利点があります。
パフォーマンスの向上: たとえば、表がタイムスタンプによってレンジ・パーティション化されている場合、タイムスタンプによる問合せを処理できるのは、その時間枠内のパーティションのみとなります。
管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、古いデータは低速で大型のディスクに移動する一方、新しいデータは高速で小型のディスクに保持できます。
また、パーティション化により、アーカイブ処理もはるかに容易になります。
可用性の拡張: たとえば、単一のパーティションが使用不可の場合に、問合せでそのパーティションを対象から外せることが判明しているのであれば、使用不可のパーティションが使用可能になるのを待たずに、問合せを処理できます。
表のパーティション化により、個々のパーティションを記憶域の様々な層に格納できます。通常、表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成します。
Oracle Information Lifecycle Management (ILM)はパーティション化および圧縮による合理化されたデータ管理を特徴としています。
データベース・ビューを使用すると、監査レコードに対して問合せを実行できます。さらに、カスタム表で、索引付け可能ビューを使用して属性に索引を作成できます。アプリケーションでは、まず簡易ビューを作成し、後で必要なときに索引付け可能ビューに切り替えることをお薦めします。
索引付け可能ビューを作成するには、次の手順を実行します。
component_events.xmlファイルにイベント属性を指定します。リリース12c (12.2.1)では、新しいindexable属性がAttributeType要素に追加されています。
Component_events.xml
<?xml version="1.0"?>
<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit-2.0.xsd">
<AuditComponent componentType="ApplicationAudit" major="1" minor="1">
<Attributes ns="accounting" version="1.0">
<Attribute name="TransactionType" displayName="Transaction Type" type="string" order="1" indexable="true">
<HelpText>Transaction type.</HelpText>
</Attribute>
<Attribute name="AccountNumber" displayName="Account Number" type="int" order="2">
<HelpText>Account number.</HelpText>
</Attribute>
<Attribute name="Date" displayName="Date" type="dateTime" order="3"/>
<Attribute name="Amount" displayName="Amount" type="float" order="4">
<HelpText>Transaction amount.</HelpText>
</Attribute>
<Attribute name="Status" displayName="Account Status" type="string" order="5" indexable="true">
<HelpText>Account status.</HelpText>
</Attribute>
</Attributes>
...
</AuditComponent>
</AuditConfig>
登録時または登録後のいずれかに索引付け可能ビューを作成します。
登録時の場合は、次のいずれかを実行します。
weblogic-application.xmlでopss.audit.iauviewデプロイメント・パラメータをINDEXABLEと指定します。
createView=INDEXABLEオプションをregisterAuditコマンドに渡します。
AuditRegistrationExtインタフェースを実装し、getIAUViewSupportTypeメソッドからAuditRegistrationExt.TYPE.INDEXABLEを戻します。
登録後の場合は、次のいずれかを実行します。
createIAUViewコマンドを実行してINDEXABLEビューに切り替えます。
INDEXABLEビュー・タイプを指定してcreateAuditDBViewコマンドを使用するSQLスクリプトを生成します。次に、管理者としてそのスクリプトを実行します。
イベント定義を変更する場合は、再デプロイの前に関連するマテリアライズド・ビューを削除します。
この項の次のトピックでは、監査構成を管理し、収集された監査データの価値を最大限生かすためのガイドラインを示します。
監査名はすべて、次のネーミング規則に準拠する必要があります。
componentType、Category、EventまたはAttributeの名前では、!、@、"、#、$、%、', (、)、*、+、カンマ、ピリオド、-、_、/、空白、:、;、<、=、>、?、{、}、~、^の各文字を使用できません。
表示名でのみ、空白文字を使用できます。
監査イベントに名前を付ける場合は、次のようにします。
イベント名の接頭辞としてコンポーネント名を付けないでください。
できるだけ具体的な名前を付けてください。たとえば、HTTPレスポンス・コードを定義する際には、ResponseではなくHTTPResponseを使用します。
すべてのイベント名の接尾辞としてEventを付けないでください。たとえば、AuthenticationEventではなく、Authenticationを使用します。
イベントの使用を最適にするには、次のようにします。
操作ごとに異なるイベントを定義します。たとえば、属性Deleteと属性Createを指定してイベントPolicyを定義するのではなく、イベントPolicyCreateとイベントPolicyDeleteを別々に定義します。
イベントの成功および失敗について別々のイベントを定義しないでください。たとえば、イベントPolicyCreateSuccessとイベントPolicyCreateFailureを別々に定義しないでください。かわりに、属性EventStatusを使用して成否を記録します。
イベントを分類するには、次のようにします。
必要に応じて、システム・カテゴリを参照します。たとえば、UserSessionやAuthorizationを参照します。
構成操作では、操作のグループを基準にカテゴリを作成します。たとえば、PolicyCreateやPolicyDeleteは、コンポーネント固有のカテゴリPolicyに入れます。
汎用属性を定義する場合は、次のようにします。
次のイベント属性を含めます。
Initiator - イベント・アクションを実行したユーザー
MessageText - 何が起こったのかについての簡単な説明。
EventStatus - イベントの結果
FailureCode - 失敗に該当するエラー・コード。
属性Resource(アクセスされたURIや付与されたパーミッションなど、影響を受けたオブジェクト)を使用します。
OFM監査フレームワークでは、各イベントの共通属性すべての和集合と見なし、各属性についてデータベース列を定義します。したがって、できるだけ多くの共通属性を定義するようにしてください。
コンポーネントによって生成されたイベントが他のイベントとクロスリンクできるように、十分な情報を定義します。
component_events.xmlファイルではバージョン・サポートがあります。イベント定義を変更することにした場合は、必ず関連付けられたマテリアライズド・ビューを削除します。
