| 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 |
|
前 |
次 |
Oracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)では、アプリケーション・イベントを監査できます。このフレームワークを使用して、アプリケーション固有のイベントの作成、デプロイ時のアプリケーションの登録、監査レポートの生成を行います。
この章の内容は次のとおりです。
監査の目的は、法令の遵守、事業活動の監視およびリスク分析用のデータの取得にあります。
コンプライアンス
企業で求められる法令を遵守し、コンプライアンス・ポリシーを見直せるように、顧客は、アイデンティティ情報と次のようなユーザー・アクセス・イベントを企業全体のアプリケーションおよびデバイスで監査する必要があります。
ユーザー・プロファイルの変更
アクセス権の変更
ユーザー・アクセス
操作アクティビティ(アプリケーションの起動と停止、アップグレード、バックアップなど)
監視
監査データを使用すると、アクティビティの監視、ダッシュボードの作成、企業内の様々なシステムの状態を監視するためのキー・パフォーマンス・インディケータの構築が可能です。
分析
監査データの分析を使用すると、管理の効果およびリスクを評価できます。履歴データに基づいてリスク・スコアが計算され、ユーザーに割り当てられます。したがって、システムに対するユーザー・アクセスのどの実行時評価にも、アクセス・パーミッションを判別するための追加の基準としてリスク・スコアを含めることができます。
監査サポートは企業間で一様ではありません。たとえば、監査レコードの生成やレコードのフォーマット、監査ポリシーの定義に標準はありません。その結果、監査ソリューションには、次のような多くの問題点があります。
集中管理される監査フレームワークがありません。
アプリケーション間で監査サポートに一貫性がありません。
監査データ、監査ポリシーおよび構成が企業全体に散乱しています。
コンポーネントにまたがった監査の分析は、複雑で多大な時間を要します。
データが散乱し、一貫性もなく、集中管理もされていない状態のため、監査ソリューションは特異性がありながら脆弱になります。
この項では、このドキュメントで使用されている監査の用語をいくつか紹介します。
コンポーネント
コンポーネントとは、Oracle Fusion Middlewareコンポーネントのことです。
監査対応コンポーネント
監査対応コンポーネントとは、OFM監査フレームワークと統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントのことです。
監査ストア
監査ストアは、事前に定義された監査スキーマを持ち、監査イベントが格納されるデータベースです。監査ストアを構成すると、監査ローダーによって定期的にデータがこのデータベースにアップロードされます。監査データは累積的なもので、時間とともにサイズが増大します。監査ストアは監査専用のデータベースとし、他のアプリケーションでは使用しないのが理想です。監査ストアには、コンポーネントの他、OFM監査フレームワークに統合されたユーザー・アプリケーションによって生成された監査イベントが格納されます。
監査定義ファイル
監査定義ファイルとは、アプリケーションにより、監査を管理する固有の監査ルール(イベント、フィルタなど)が指定されるファイルのことです。
監査イベント
監査イベントとは、OFM監査フレームワークによって記録されるイベントのことです。このフレームワークには、アプリケーションの監査共通イベントにマップする一連の汎用イベント(認証、ポリシーの変更など)が用意されています。また、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)コマンドを使用して、特殊なアプリケーション・イベントを定義したり、監査構成を更新することもできます。
監査ローダー
監査ローダーは、サーバーで監査アクティビティをサポートするOracle WebLogic Serverのモジュールです。監査ストアを構成すると、監査ローダーにより、実行されているすべてのコンポーネントの監査レコードが収集され、監査ストアにロードされます。Javaコンポーネントの場合、監査ローダーは、コンテナの起動時に起動されます。監査ローダーを使用してイベントをアップロードするには、システム・コンポーネントを監査に(registerAudit WLSTコマンドを使用して)登録するか、スタンドアロン監査ローダーを使用します。
監査ポリシー
監査ポリシーとは、特定のコンポーネントについてOFM監査フレームワークによって取得されるイベントを指定するものです。ポリシーは、コンポーネント・レベル(特定のコンポーネントに適用)またはドメイン・レベル(ドメイン内のコンポーネントすべてに適用)で定義します。
バスストップ・ファイル
バスストップ・ファイルとは、監査データ・レコードが格納されるローカル・ファイルのことです。バスストップ・ファイルは、特定の監査イベントを探すために簡単に問い合せることができる単純なテキスト・ファイルです。ドメインで監査を構成すると、このようなファイルのデータは、構成可能な時間間隔で定期的に監査ストアにアップロードされます。ドメインで監査を構成しないと、データはバスストップ・ファイルに格納されます。
すべてのミドルウェア・コンポーネントおよびインスタンスで認証の失敗を特定する場合などに、レポートで複数のコンポーネントからの監査データを相互的に関連付けたり、組み合せます。
デフォルトでは、バスストップ・ファイルは次のディレクトリにあります。
Weblogic Domain Home/servers/server_name/logs/auditlogs
コンポーネントのバスストップ・ファイルごとにサブディレクトリがあります。たとえば、OPSSのバスストップ・ファイルは、次のディレクトリに格納されています。
Weblogic Domain Home/servers/server_name/logs/auditlogs/JPS
イベント・フィルタ
イベント・フィルタとは、イベントをログに記録するかどうかを制御するフィルタのことです。たとえば、特定のユーザーについてのみコンポーネントへの成功したログインのイベントがログに記録されます。
監査構成Mbean
監査構成MBeanとは、監査構成を管理するMBeanのことです。Javaコンポーネントおよびアプリケーションの場合、このようなMbeanはWebLogic管理サーバー内に存在し、監査構成が集中管理されます。システム・コンポーネントの場合、コンポーネントごとに異なるMBeanがあります。
次の各項では、コンポーネントを監査するためのOFM監査フレームワークのサポートについて説明します。
OFM監査フレームワークには次の機能があります。
Javaコンポーネント、システム・コンポーネントおよびアプリケーションにわたって監査を管理するための統一された方法。
Javaコンポーネント監査。
非監査対応アプリケーションの監査のサポート。
任意のアプリケーション・レベルでの監査データ検索機能。
認証履歴、認証失敗、認可履歴、ユーザー管理およびその他の共通トランザクション・データの取得。
柔軟なポリシー。
構成を容易にするために使用可能で、最もよく使用される監査イベントを取得する以前にシードされた監査ポリシー。
ツリー状のポリシー構造。
公開された監査スキーマに基づいて独自のレポートを作成する機能。監査分析の詳細は、第15章「監査分析と監査レポートの使用」を参照してください。
レコードのメンテナンスを簡略化する、共通の場所(監査ストア)への監査のデータおよびファイルの格納。
共通の監査レコード・フォーマット。
結果(ステータス)、イベントの日時、ユーザーなどのベースライン属性。
認証方式、ソースIPアドレス、ターゲット・ユーザー、リソースなどのイベント固有の属性。
実行コンテキストID (ECID)、セッションIDなどのコンテキスト属性。
ドメイン全体に対して監査ポリシーを構成するための共通の統一された方法。
監査で次のことを実現するOracle Fusion Middlewareのサポート。
Oracle Fusion Middlewareコンポーネントおよびサービス間での使用が可能。
Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)との統合。
WLSTとの統合。
OFM監査フレームワークと統合され、アプリケーションで次のことを可能にする動的メタデータ・モデル。
任意の時点での登録。
特定の監査イベントの定義およびログへの記録。
イベント定義のバージョンの指定による、リリース・サイクルに依存しない定義のアップグレード。
OFM監査フレームワークは、Oracle Fusion Middlewareの全製品向けの集中管理フレームワークです。特に、次のアプリケーションおよびコンポーネントに監査を提供しています。
ミドルウェア・プラットフォーム - これには、OPSSやOracle Web Services ManagerなどのJavaコンポーネントが含まれます。Javaコンポーネントを利用しているデプロイ済アプリケーションはすべて、プラットフォーム・レベルで発生する監査の恩恵を受けます。
Java EEアプリケーション - フレームワークにより、Java EEアプリケーション(Oracle Java EEベースのコンポーネントを含む)に監査が提供され、アプリケーションおよびコンポーネントでは固有の監査イベントを指定できます。
システム・コンポーネント - フレームワークにより、Oracle HTTP Serverなどのシステム・コンポーネントについても、Javaコンポーネント(CおよびC++アプリケーション用のAPIを含む)の場合と同様のエンドツーエンドのソリューションが提供されます。
|
関連項目: 『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの主要概念の理解に関する項 |
次の各項では、基本的な監査の概念について説明します。
監査モデルは、Oracle Fusion Middleware全体のJava EEおよびJava SEのアプリケーションとコンポーネントに対する標準ベースの統合フレームワークとなります。
動的モデル
OFM監査フレームワークは、アプリケーションで監査イベント定義を管理し、リリース・サイクルに関係なくバージョン変更を行うことが可能になる動的監査モデルを特徴としています。監査イベント定義は、再デプロイメント時に動的に更新できます。
アプリケーション・ライフ・サイクルのサポート
このモデルは、設計から開発、デプロイメントに至るまでのアプリケーション・ライフ・サイクルのすべての側面をサポートします。
アプリケーションの登録
汎用性の高い登録により、様々な方法でアプリケーションを監査に登録できます。
宣言して、META-INFディレクトリのアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルに構成をパッケージ化することによって登録します。
プログラムを使用して、監査登録メソッドをコールすることによって登録します。
コマンドラインで、WLST監査コマンドをコールすることによって登録します。
ドメイン作成時に、製品テンプレートでセキュリティ・アーティファクトを指定することによって登録します。
分散環境
OFM監査フレームワークでは、複数のサーバーがある分散環境をサポートします。監査ストアを監視するため、あるサーバーで加えられた監査ポリシーへの変更はドメイン内の他のサーバーすべてと同期されます。
たとえば、管理サーバー1台と管理対象サーバー3台で構成される分散環境を考えてみます。単一のセキュリティ・ストア(監査データを格納)がドメイン内のサーバーすべてをサポートします。Fusion Middleware Controlを使用して管理サーバーで監査ポリシーを変更すると、その変更はドメイン内の他のサーバーすべてに自動的に伝播され、同期されます。
|
関連項目: 『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のregisterAuditに関する項 |
監査ストアには、コンポーネントのイベント定義、属性表マッピングおよび監査ポリシーが格納されます。
監査ストアには次のものが組み込まれています。
次のことが可能になる監査登録。
イベント定義エントリの作成、変更および削除。
監査データを格納するための属性データベース・マッピングの作成。
イベント定義および実行時ポリシーを取得するサービス。
コンポーネントの監査定義および実行時ポリシーの検索および変更を可能にする監査MBeanコマンド。
OFM監査フレームワークには、監査データを格納するためのデータベースが必要ですが、このデータベースはサポートされているものであれば何でもかまいません。サポートされているタイプの詳細は、第4.1項「サポートされているファイル、LDAPおよびDBのストア」を参照してください。
新しいアプリケーションが監査に登録されると、次のアーティファクトが監査ストアに格納されます。
カスタム属性グループ、カテゴリ、イベントおよび事前設定済フィルタ定義を含む、監査イベント定義
ローカライズされた翻訳エントリ
カスタム属性/データベース列マッピング表
実行時監査ポリシー
監査データは、中間的な記憶域または永続的な記憶域にあります。
中間的な記憶域: バスストップ・ファイル内。コンポーネント・インスタンスはそれぞれ別個のバスストップ・ファイルに書き込みます。バスストップ・ファイルはテキストベースで問合せが容易です。
永続的な記憶域: 監査ストア内(環境で構成されている場合)。ドメイン内のあらゆるコンポーネントで生成された監査レコードは同じストアに書き込まれます。
データベース・ストアを使用する利点
バスストップ・ファイルに監査レコードを格納する場合、次のような制限があります。
ドメイン・レベルの監査データを表示できません。
レポートの取得が困難です。
一方、監査ストアの使用には次のような利点があります。
監査レポートを生成できます。
データベース・ストアには、ドメイン内のあらゆるコンポーネントからのレコードが格納されるのに対して、バスストップには、1つのコンポーネントの監査レコードのみが格納されます。
パフォーマンスが向上します。
OFM監査フレームワークには、統合されている監査対応コンポーネント用に一連のインタフェースが用意されています。アプリケーションでは実行時、これらのAPIをコールして、監査ポリシーを管理したり、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査したりする場合もあります。これらのインタフェースにより、アプリケーションでは、監視対象イベントのコンテキストの提供に必要なイベントの詳細および属性を指定できます。
環境で監査を設定およびメンテナンスする場合に実行する主要なタスクを次に示します。
監査アーキテクチャ、フレームワークの不可欠な要素、アクションのフロー、OFM監査フレームの理解。これらのタスクの詳細は、第14.1項「監査管理タスク」を参照してください。
アプリケーションとフレームワークの統合。統合の詳細は、第22.1項「アプリケーションとOFM監査フレームワークの統合」を参照してください。
アプリケーションの監査イベントと、それらを監査スキーマにマップする方法を指定する監査定義ファイルの作成。監査定義ファイルの詳細は、第22.2項「監査定義ファイルの作成」を参照してください。
監査へのアプリケーションの登録。監査登録の詳細は、第22.3項「サービスへのアプリケーションの登録」を参照してください。
監査情報の移行。監査データの移行の詳細は、第6.6.3項「監査データの移行」を参照してください。
監査レポートの生成。監査レポートの詳細は、第15章「監査分析と監査レポートの使用」を参照してください。
環境で監査ストアを構成しないと、監査レコードはバスストップ・ファイルに格納されます。監査イベントを記録できない場合、アプリケーションは実行を停止しません。
監査イベント・フローを最もよく理解するには、監査を構成した環境で実行されているアプリケーション内で監査イベントが発生した際に実行される次の手順を見ることです。
アプリケーションのデプロイ時またはサービスの起動時に、クライアントJava EEアプリケーションが監査に登録されます。
サービスはアプリケーションの監査定義ファイルを読み取り、監査ストアの定義を更新します。
ユーザーがそのコンポーネントまたはアプリケーションにアクセスすると、イベントを監査するために監査関数がコールされます。
OFM監査フレームワークが、このタイプ、ステータスおよび属性のイベントを監査するかどうかをチェックします。監査が必要な場合は監査関数がコールされてイベントが作成され、ステータス、イニシエータ、リソース、ECIDなどの情報が収集されます。
イベントはバスストップ・ファイルに格納されます。アプリケーションまたはコンポーネントにはそれぞれ個別のバスストップ・ファイルがあります。
監査ローダーはバスストップ・ファイルからイベントをプルし、アプリケーションのメタデータを使用してデータを書式設定し、監査ストアに移動します。
OFM監査フレームワークでは、アプリケーションの監査属性グループ、カテゴリおよびイベントの動的な指定および定義が可能になるモデルをサポートしています。
次の各項では、このサポートについて説明しています。
属性グループは監査属性の広範な分類であり、共通、汎用、カスタムの3つのタイプから構成されます。
共通属性グループには、コンポーネント・タイプ、システムIPアドレス、ホスト名など、すべてのアプリケーションに共通のシステム属性が含まれます。IAU_COMMONデータベース表には、このグループ内の属性が含まれます。
汎用属性グループには、監査認証およびユーザー・プロビジョニングの属性が含まれます。
カスタム属性グループは、特定のニーズに応じてアプリケーションで定義されるグループです。カスタム・グループの属性の有効範囲は、コンポーネントに限定されます。これらの属性グループおよび属性は、IAU_CUSTOMn表(nは1、2などの整数)に格納されます。
汎用属性グループは、ネームスペースおよびバージョン番号を表し、1つ以上の属性が含まれます。次の例は、authorizationネームスペースおよびバージョン1.0の属性グループを示しています。
<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit-2.0.xsd" >
<Attributes ns="authorization" version="1.0">
<Attribute displayName="CodeSource" maxLength="2048" name="CodeSource" type="string"/>
<Attribute displayName="Principals" maxLength="1024" name="Principals" type="string"/>
<Attribute displayName="InitiatorGUID" maxLength="1024" name="InitiatorGUID" type="string"/>
<Attribute displayName="Subject" maxLength="1024" name="Subject" type="string">
<HelpText>Used for subject in authorization</HelpText>
</Attribute>
</Attributes>
……
CodeSource属性は、次のように表します。
<Attribute name="CodeSource" ns="authorization" version="1.0" />
各汎用属性グループは、専用のデータベース表に格納されます。ネーミング規則は次のとおりです。
表名はIAU_GENERIC_ATTRIBUTE_GROUP_NAME
表の列はIAU_ATTRIBUTE_NAME
たとえば、authorization属性グループは、次の列を含むIAU_AUTHORIZATION表に格納されます。
文字列であるIAU_CODESOURCE
文字列であるIAU_PRINCIPALS
文字列であるIAU_INITIATORGUID
カスタム属性グループは、ネームスペース、バージョン番号および1つ以上の属性を表します。各カスタム属性には次のプロパティがあります。
属性名
データ型
属性/データベース列マッピング順序 - このプロパティは、属性が、カスタム属性表内の特定のデータ型のデータベース列にマップされる順序を指定します。
ヘルプ・テキスト(オプション)
最大長
表示名
サイズ - このプロパティは、属性に指定できる同じデータ型の値の数を示します。サイズのデフォルト値は1です。1より大きいサイズは、同じデータ型の値を複数指定できる属性を示します。このような属性では、binary型以外のすべてのデータ型がサポートされます。
次の例は、accountingネームスペースおよびバージョン1.0のAccounting属性グループの定義を示しています。
<Attributes ns="accounting" version="1.0">
<Attribute name="TransactionType" displayName="Transaction Type" type="string" order="1"/>
<Attribute name="AccountNumber" displayName="Account Number" type="int" order="2">
<HelpText>Account number.</HelpText>
</Attribute>
……
</Attributes>
次の例では、複数の値を持つAccountBalance属性を定義します。
<Attribute order="3" displayName="AccountBalance" type="double" name="Balance" size="2" sinceVersion="1.1">
<MultiValues>
<MultiValueName displayName="Previous Balance" index="0">
<HelpText>the previous account balance</HelpText>
</MultiValueName>
<MultiValueName displayName="Current Balance" index="1"/>
</MultiValues>
</Attribute>
表13-1に、サポートされている属性のデータ型とそれに対応するJavaオブジェクト・タイプを示します。
イベント・カテゴリには、機能領域内の監査イベントが含まれます。たとえば、セッション・カテゴリには、ユーザー・セッションのライフ・サイクルで重要なログイン・イベントとログアウト・イベントが含まれます。イベント・カテゴリ自体は属性を定義しません。かわりに、コンポーネント内の属性およびシステム属性グループを参照します。
イベント・カテゴリには次の2つのタイプがあります。
システム・カテゴリ
コンポーネントとアプリケーション・カテゴリ
システム・カテゴリは、共通属性グループと汎用属性グループを参照し、監査イベントが含まれます。システム・カテゴリは、コンポーネント・イベント・カテゴリおよびイベントのベース・セットです。アプリケーションではシステム・カテゴリを参照し、そのイベントを使用して監査イベントをログに記録し、事前設定済フィルタ定義を設定できます。
次の例は、属性およびイベントの定義と、AuthenticationMethod共通属性を参照する属性を持つUserSessionシステム・カテゴリの定義を示しています。
<SystemComponent major="1" minor="0">
<Attributes ns="common" version ="1.0"></Attributes>
<Attributes ns="identity" version ="1.0"></Attributes>
<Attributes ns="authorization" version ="1.0"></Attributes>
<Events>
<Category name="UserSession" displayName="User Sessions">
<Attributes>
<Attribute name="AuthenticationMethod" ns="common" version ="1.0" />
</Attributes>
<HelpText></HelpText>
<Event name="UserLogin" displayName="User Logins" shortName="uLogin"></Event>
<Event name="UserLogout" displayName="User Logouts" shortName="uLogout"
xdasName="terminateSession"></Event>
<Event name="Authentication" displayName="Authentication"></Event>
<Event name="InternalLogin" displayName="Internal Login" shortName="iLogin"
xdasName="CreateSession"></Event>
<Event name="InternalLogout" displayName="Internal Logout" shortName="iLogout"
xdasName="terminateSession"></Event>
<Event name="QuerySession" displayName="Query Session" shortName="qSession"></Event>
<Event name="ModifySession" displayName="Modify Session" shortName="mSession"></Event>
</Category>
<Category displayName="Authorization" name="Authorization"></Category>
<Category displayName="ServiceManagement" name="ServiceManagement"></Category>
</Events>
</SystemComponent>
コンポーネントまたはアプリケーションは、システム・カテゴリを拡張するか、新しいコンポーネント・イベント・カテゴリを定義できます。
次の例は、accounting属性グループのAccountNumber、DateおよびAmountの各属性を持ち、purchaseイベントとdepositイベントが含まれるカテゴリの定義を示しています。
<Category displayName="Transaction" name="Transaction">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0"/>
<Attribute name="Date" ns="accounting" version="1.0" />
<Attribute name="Amount" ns="accounting" version="1.0" />
</Attributes>
<Event displayName="purchase" name="purchase"/>
<Event displayName="deposit" name="deposit">
<HelpText>depositing funds.</HelpText>
</Event>
……
</Category>
アプリケーション監査定義でカテゴリ参照を作成し、カテゴリに含まれるシステム・イベントをリストし、属性参照およびイベントをカテゴリ参照に追加することで、システム・カテゴリを拡張します。
次の例は、ServiceTime属性およびrestartServiceイベントを持つServiceManagementシステム・カテゴリ参照の定義を示しています。
<CategoryRef name="ServiceManagement" componentType="SystemComponent">
<Attributes>
<Attribute name="ServiceTime" ns="accounting" version="1.0" />
</Attributes>
<EventRef name="startService"/>
<EventRef name="stopService"/>
<Event displayName="restartService" name="restartService">
<HelpText>restart service</HelpText>
</Event>
</CategoryRef>
カテゴリ、イベントまたは属性の名前には次の要件があります。
英単語であること
25文字以下であること
文字(a-z、A-Z)および数字(0-9)のみで構成すること
文字で始まること
監査定義ファイルでは、アプリケーション固有の監査ルール(イベント、フィルタなど)を指定します。監査定義ファイルは、イベント定義を外国語に翻訳する手段になります。監査定義ファイルには、2つのタイプがあります。
component_events.xmlファイル。このファイルの詳細は、「component_events.xmlファイルについて」を参照してください。
翻訳ファイル(様々な言語で監査定義を表示するために使用されます)。翻訳ファイルの詳細は、第22.2.2項「翻訳ファイル」を参照してください。
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="0">
<Attributes ns="accounting" version="1.0">
<Attribute name="TransactionType" displayName="Transaction Type" type="string" order="1">
<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">
<HelpText>Account status.</HelpText>
</Attribute>
</Attributes>
<Events>
<Category displayName="Transaction" name="Transaction">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0" />
<Attribute name="Date" ns="accounting" version="1.0" />
<Attribute name="Amount" ns="accounting" version="1.0" />
</Attributes>
<Event displayName="purchase" name="purchase">
<HelpText>direct purchase.</HelpText>
</Event>
<Event displayName="deposit" name="deposit">
<HelpText>depositing funds.</HelpText>
</Event>
<Event displayName="withdrawing" name="withdrawing">
<HelpText>withdrawing funds.</HelpText>
</Event>
<Event displayName="payment" name="payment">
<HelpText>paying bills.</HelpText>
</Event>
</Category>
<Category displayName="Account" name="Account">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0" />
<Attribute name="Status" ns="accounting" version="1.0" />
</Attributes>
<Event displayName="open" name="open">
<HelpText>Open a new account.</HelpText>
</Event>
<Event displayName="close" name="close">
<HelpText>Close an account.</HelpText>
</Event>
<Event displayName="suspend" name="suspend">
<HelpText>Suspend an account.</HelpText>
</Event>
</Category>
</Events>
<FilterPresetDefinitions>
<FilterPresetDefinition displayName="Low" helpText="" name="Low">
<FilterCategory enabled="partial" name="Transaction"> deposit.SUCCESSESONLY(HostId -eq "NorthEast"),withdrawing </FilterCategory>
<FilterCategory enabled="partial" name="Account">open.SUCCESSESONLY,close.FAILURESONLY</FilterCategory>
</FilterPresetDefinition>
<FilterPresetDefinition displayName="Medium" helpText="" name="Medium">
<FilterCategory enabled="partial" name="Transaction">deposit,withdrawing</FilterCategory>
<FilterCategory enabled="partial" name="Account">open,close</FilterCategory>
</FilterPresetDefinition>
<FilterPresetDefinition displayName="High" helpText="" name="High">
<FilterCategory enabled="partial" name="Transaction">deposit,withdrawing,payment</FilterCategory>
<FilterCategory enabled="true" name="Account"/>
</FilterPresetDefinition>
</FilterPresetDefinitions>
<Policy filterPreset="Low">
<CustomFilters>
<FilterCategory enabled="partial" name="Transaction"> purchase </FilterCategory>
</CustomFilters>
</Policy>
</AuditComponent>
</AuditConfig>
実行時のプロパティについて
さらに、Fusion Middleware ControlまたはWLSTコマンドを使用して作成したり、登録時に作成する実行時プロパティがあります。これには、次のようなプロパティがあります。
filterPreset: 監査フィルタ・レベルを指定します。
specialUsers: 常に監査するユーザーを指定します。
maxBusstopFileSize: バスストップ・ファイルのサイズを指定します。
監査登録では、特定のルールを適用してアプリケーションに対して監査データが作成されますが、このデータは監査定義の様々なバージョンを管理したり、レポートを生成するために使用されます。
次の各項では、登録のしくみについて説明します。
監査定義ファイルには、メジャー・バージョン番号とマイナー・バージョン番号があります。監査イベント定義を変更する場合は、バージョン番号を更新する必要があります。この番号は、イベント定義の互換性およびバージョン間の属性マッピングを判別するために監査登録で使用されます。これらのバージョン番号はOracle Fusion Middlewareのバージョン番号とは関係ありません。
コンポーネント・バージョン
コンポーネントの登録時に、監査登録によってこれが初めての登録なのか、アップグレードなのかがチェックされます。
新規登録の場合、サービスは次のように動作します。
コンポーネントの監査および翻訳情報を取得します。
定義を解析して検証し、監査ストアに格納します。
属性/列マッピング表を生成し、監査ストアに保存します。
アップグレードの場合、監査ストア内のコンポーネントの現在のバージョン番号が新しいバージョン番号と比較され、アップグレードを続行するかどうかが決まります。
Java EEアプリケーション・バージョン
アプリケーション監査定義の変更後にバージョン番号を次のように再設定することをお薦めします。
マイナー・バージョン番号は、以前の属性データベース・マッピング表で作成された監査データとでも動作する変更を監査定義に加える場合のみ増やします。
たとえば、現在の定義バージョンが2.1であるとします。属性データベース・マッピング表に影響しない新しいイベントを追加した場合は、バージョンを2.2に変更し、メジャー・バージョンはそのままにします(major=2)。同様に、新しい属性を追加した後は、マイナー・バージョンを増やします。
新しいマッピング表が以前の表と互換性がない変更を加える場合には、メジャー・バージョン番号を増やします。
変更はサーバーを再起動すると有効になります。
新しいコンポーネントまたはアプリケーションを登録する際、監査登録では、カスタム属性から属性/データベース列マッピング表を作成し、この表を監査ストアに保存します。
カスタム属性の数が100を超える場合は、手動で表を追加作成する必要があります。OPSSに同梱されている表は、IAU_CUSTOMおよびIAU_CUSTOM_01のみです。
属性/データベース列マッピング表は、アプリケーションの属性定義とデータベース列間で一意なマッピングを行うために必要です。監査ローダーはマッピング表を使用してデータを監査ストアにロードします。これらの表は、カスタム・データベース表IAU_CUSTOMから監査レポートを生成する場合にも使用されます。
createAuditDBView WLSTコマンドを使用して、コンポーネントについて監査定義のデータベース・ビューを作成するSQLファイルを生成します。
コンポーネントのマッピング表の理解
カスタム属性/データベース列マッピングには、名、データベース列名およびデータ型の各プロパティがあります。
各カスタム属性定義には、マッピング順序番号が含まれている必要があります。同じデータ型の属性は、属性マッピング順序に従ってデータベース列にマップされます。
たとえば、次のような定義ファイルは、
<Attributes ns="accounting" version="1.1"> <Attribute name="TransactionType" type="string" maxLength="0" displayName="Transaction Type" order="1"/> <Attribute name="AccountNumber" type="int" displayName="Account Number" order="2"> <Attribute name="Date" type="dateTime" displayName="Date" order="3"/> <Attribute name="Amount" type="float" displayName="Amount" order="4"/> <Attribute name="Status" type="string" maxLength="0" displayName="Account Status" order="5"/> <Attribute name="Balance" type="float" displayName="Account Balance" order="6"/> </Attributes>
次にマップします。
<AttributesMapping ns="accounting" tableName="IAU_CUSTOM" version="1.1"> <AttributeColumn attribute="TransactionType" column="IAU_STRING_001" datatype="string"/> <AttributeColumn attribute="AccountNumber" column="IAU_INT_001" datatype="int"/> <AttributeColumn attribute="Date" column="IAU_DATETIME_001" datatype="dateTime"/> <AttributeColumn attribute="Amount" column="IAU_FLOAT_001" datatype="float"/> <AttributeColumn attribute="Status" column="IAU_STRING_002" datatype="string"/> <AttributeColumn attribute="Balance" column="IAU_FLOAT_002" datatype="float"/> </AttributesMapping>
属性/データベース列マッピング表のバージョン番号は、カスタム属性グループのバージョン番号に一致します。これにより、アプリケーションは監査定義バージョン間で、属性マッピングの下位互換性を維持できます。
|
関連項目: 『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のcreateAuditDBViewに関する項 |
