| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
前 |
次 |
この章では、Oracle Fusion Middlewareの監査サービスの概要を示します。
Oracle Fusion Middlewareにおいて、監査はアカウンタビリティを実現する手段であり、また、だれが、いつ、何を行ったかというタイプの質問への回答を提供します。この章の内容は次のとおりです。
この項の内容は次のとおりです。
コンプライアンスがビジネス要件の不可欠な要素になりつつある現在、監査のサポートもエンタープライズ・デプロイメントにおける注目の的になりつつあります。顧客は、追加設定なしですぐに使用できる監査サポートを提供するアプリケーション・ベンダーを探しています。また、カスタム・アプリケーションをデプロイするミドルウェアの顧客は、デプロイされる監査が必要な全アプリケーションの監査を集中管理したいと考えています。
IT組織では、コンプライアンス、監視および分析という要件の観点から、主要な監査機能を探しています。
コンプライアンス
コンプライアンスがエンタープライズにおける主要な要件であることは、明白です。Sarbanes-Oxley法(財務)やHealth Insurance Portability and Accountability Act (HIPAA: 医療保険)のような規制により、多くの顧客は現在、アプリケーションやデバイスで、アイデンティティ情報およびユーザー・アクセスの監査を実行できる必要があります。これらには、次のようなイベントが含まれます。
ユーザー・プロファイルの変更
アクセス権の変更
ユーザー・アクセス・アクティビティ
操作アクティビティ(アプリケーションの起動と停止、アップグレード、バックアップなど)
これにより、コンプライアンス担当者は、コンプライアンス・ポリシーを定期的に見直すことができます。
監視
監査データからは通常、監視目的のために、豊富なデータ・セットが得られます。公開されるログ・データおよびコンポーネント・メトリックだけでなく、監査データを使用してダッシュボードを作成したり、アラート用のキー・パフォーマンス・インディケータ(KPI)を設定したりして、様々なシステムの状態を継続的に監視することもできます。
分析
また、監査データを分析し、管理効果を評価することもできます。監査データは、リスク分析にも使用できます。履歴データに基づいてリスク・スコアを計算し、任意のユーザーに割り当てることもできます。ユーザー・アクセスのどのような実行時評価にも、システムに対するアクセスを保護するための追加の基準として様々なリスク・スコアを含めることができます。
監査要件を満たすため、IT組織ではしばしばデプロイされるアプリケーションに対する監査サポートの欠如と闘っています。それは、次の点に対して信頼できる標準が存在していないからです。
監査レコードの生成
監査レコードのフォーマットと格納
監査ポリシーの定義
その結果、現在の監査ソリューションには、次のような多くの大きな問題点があります。
集中管理される監査フレームワークがありません。
監査サポートの品質がアプリケーションごとにまちまちです。
監査データがエンタープライズ全体に散乱しています。
コンポーネント間の意味のある分析を実行するには、その前に複雑なデータの関係付けが必要となります。
監査ポリシーとその構成も散乱しています。
これらの要因により、IT組織は適切な監査ソリューションの構築および維持にかなりの時間とリソースを割いています。データが個々のサイロに散乱していて、一貫性も集中管理もない状態では、様々なベンダーが現時点における独自の監査機能を使用して実現しているアプリケーション間に統一性がなく、監査ソリューションも脆弱になりがちです。
Oracle Fusion Middleware監査フレームワークは、集中管理された監査フレームワークをミドルウェアの製品ファミリに提供するよう設計されています。このフレームワークは、次のものに対して監査サービスを提供します。
ミドルウェア・プラットフォーム - これには、Oracle Platform Security Services (OPSS)やOracle Web ServicesなどのJavaコンポーネントが含まれます。これらは、ミドルウェアにデプロイされたアプリケーションによって活用されるコンポーネントです。間接的には、これらのJavaコンポーネントを使用するデプロイ済アプリケーションはすべて、プラットフォーム・レベルで発生する監査イベントから利点を得られます。
Java EEアプリケーション - 目的は、Oracle自体のJava EEベースのコンポーネントをはじめとするJava EEアプリケーションにサービスを提供することです。Java EEアプリケーションは、アプリケーションに固有な監査イベントを作成できます。
システム・コンポーネント - Oracle HTTP Serverなどのシステム・コンポーネントについても、監査サービスによって、Javaコンポーネントの場合と同様のエンドツーエンドの構造(C/C++ベースのアプリケーション用の監査APIなど)が実現されます。
|
関連項目: 『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware主要概念の理解に関する説明 |
Oracle Fusion Middleware監査フレームワークおよび監査サービスの主な機能には、次のものがあります。
一連のJavaコンポーネント、システム・コンポーネントおよびアプリケーション全体にわたって監査を管理するための統一的なシステム
次の機能を含む、Javaコンポーネント監査の広範なサポート
Oracle Platform Security Servicesによる非監査対応アプリケーションの監査のサポート
任意のアプリケーション・レベルでの監査データ検索機能
認証履歴および認証失敗、認可履歴、ユーザー管理およびその他の共通トランザクション・データの取得
柔軟な監査ポリシー
事前生成済の監査ポリシーや顧客でよく使用される監査イベントの取得機能などを利用した、容易なポリシー構成
ツリー状のポリシー構造による簡便なポリシー設定
ビルトインのコンプライアンス・レポート作成機能
Oracle Fusion Middleware監査フレームワークは、Oracle BI Publisherのすぐに使用可能な分析レポート作成機能を提供します。複数のコンポーネントにわたって複数の次元(実行コンテキストID (ECID)やユーザーIDなど)でデータを分析できます。また、これらのレポートをプリファレンスに従ってカスタマイズすることもできます。
集中管理された監査データに基づいてレポートを作成します。
顧客は、レポートをカスタマイズしたり、公開された監査スキーマに基づいて独自のレポートを作成することができます。
詳細は、第15章「監査分析と監査レポートの使用」を参照してください。
監査レコードの格納
監査データ・ストア(データベース)とファイル(バスストップ)を使用できます。すべての監査レコードに共通の場所を維持することにより、管理が容易になります。
監査データ・ストアを使用することにより、Oracle Business Intelligence Publisherを使用したレポートの生成が可能になります。
共通の監査レコード・フォーマット
監査証跡は次の特徴を持ちます。
結果(ステータス)、イベントの日時、ユーザーなどのベースライン属性
認証方式、ソースIPアドレス、ターゲット・ユーザー、リソースなどのイベント固有の属性
実行コンテキストID (ECID)やセッションIDなどのコンテキスト属性
監査ポリシー構成用の共通のメカニズム
Oracle Fusion Middleware監査フレームワークは、ドメイン内で監査ポリシーを構成するための統一的な手段を提供します。
Oracle Fusion Middlewareのインフラストラクチャの活用
Oracle Fusion Middlewareコンポーネントおよびサービス間での使用が可能
Oracle Enterprise Manager Fusion Middleware Controlとの統合により、UIベースの構成と管理が可能
wlstとの統合により、コマンドラインでのスクリプトベースの構成が可能
Oracle Platform Security ServicesのSPIインフラストラクチャを活用
アプリケーションでの監査フレームワークとの統合を可能にする動的メタデータ・モデルの使用
アプリケーションはいつでも監査サービスに登録が可能
監査イベントを定義および記録するために監査フレームワークをアプリケーションが活用する機能を簡素化
イベント定義のバージョニングを提供し、監査クライアントによるリリース・サイクルに依存しない定義のアップグレードが可能に
この項では、Oracle Fusion Middleware監査フレームワークの次の基本概念を説明します。
図13-1は、Oracle Fusion Middleware監査フレームワークのアーキテクチャを示しています。
この図は、開発時および実行時のサービス、監査イベント・フローおよび主要機能を含めた、アーキテクチャの必須要素を示しています。これらの要素については、次に説明しています。
フレームワークの中心に監査サービス・モデルがあり、他のOPSSサービスと同様に、このモデルではJava EEおよびSEアプリケーションおよびOracleコンポーネントに一様に標準ベースの統合フレームワークが提供されます。
Oracle Fusion Middleware全体で使用することによって、このモデルでは、プラットフォームの次のような監査機能を効率的に使用できるようになります。
監査クライアントが監査イベント定義を管理し、ビルドおよびリリース・サイクルに関係なくバージョン変更を行うことができる動的監査メタデータ・モデル。監査イベント定義は、再デプロイメント時に動的に更新できます。
設計から開発およびデプロイメントに至るまでのアプリケーション・ライフサイクルのすべての側面のサポート。
監査サービスにアプリケーションを登録する登録サービス。
宣言的: Java EEアプリケーションでは、デプロイメント時にMETA-INFディレクトリのearファイルとしてXML構成をパッケージ化することによって登録が実行されます。
プログラムの使用: 監査登録APIを呼び出すことによって登録します。
コマンドラインで、WLSTコマンドによって登録します。
製品テンプレートでセキュリティ・アーティファクトをバンドルすることによって登録します(第7.1項を参照)。
このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。アプリケーションでは実行時、これらのAPIを適宜コールして、監査ポリシーを管理したり、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査したりする場合もあります。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。
監査フレームワークにより、次のAPIが提供されます。
監査サービスAPI
監査クライアントAPI
監査管理サービスAPI
詳細は、第25章を参照してください。
このプロセスは、アプリケーション・サーバー・インスタンス内で監査可能なイベント(たとえばログイン)が発生した場合に、フレームワーク内で実行されるアクションを示すことにより説明できます。
アプリケーションのデプロイメント時または監査サービスの起動時に、Java EEアプリケーションまたはOracleコンポーネントなどのクライアントが監査サービスに登録されます。
サービスはアプリケーションの事前構成済の監査定義ファイルを読み取り、監査定義でメタデータ・ストアを更新します。
ユーザーがそのコンポーネントまたはアプリケーションにアクセスすると、イベントを監査するために監査API関数がコールされます。
監査フレームワークは、このタイプ、ステータス、および特定の属性のイベントを監査する必要があるかどうかを確認します。
監査が必要な場合は監査関数が起動され、監査イベント構造体が作成されて、ステータス、イニシエータ、リソース、ECIDなどのイベント情報が収集されます。
イベントは、バスストップとして知られる中間的な場所にあるローカル・ファイルに格納されます。各コンポーネントは個別のバスストップを持ちます。
監査ストアとしてデータベースが構成されている場合、監査ローダーはバスストップからイベントをプルし、アプリケーションのメタデータを使用してデータを書式化し、データを監査ストアに移動します。
Oracle BI Publisherを使用して、監査データからレポートを生成することもできます。事前定義済のレポート・セットも使用できます。(第15章「監査分析と監査レポートの使用」を参照してください。)
監査が失敗した場合のアプリケーションの動作
アプリケーションは、どのような理由で監査イベントを記録できない場合であっても、実行を中止することはありません。
この項では、Oracle Fusion Middleware監査フレームワークの重要な概念を説明します。
監査対応コンポーネント
監査対応とは、Oracle Fusion Middleware監査フレームワークに統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントを指します。Oracle Internet Directoryは監査対応コンポーネントの一例です。
スタンドアロン・アプリケーションは、jps-config.xmlファイルを使用して構成を行うことで、Oracle Fusion Middleware監査フレームワークとの統合が可能です。詳細は、付録Aの<serviceInstances>を参照してください。
監査メタデータ・ストア
監査メタデータ・ストアには、コンポーネント、および監査フレームワークに統合されたアプリケーションに対する監査イベント定義が格納されます。
詳細は、13.3.3項を参照してください。
監査データ・ストア
監査データ・ストアは、監査イベント・レコードのリポジトリです。これは、リポジトリ作成ユーティリティ(RCU)によって作成される、事前定義済のOracle Fusion Middleware監査フレームワーク・スキーマが含まれるデータベースです。監査データ・ストアを構成すると、監査ローダーが監査データ・ストアを認識し、データが監査データ・ストアに定期的にアップロードされるようになります。監査ストア内の監査データは累積されることが想定され、時間の経過に伴って増加します。監査データ・ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型データベースであるのが理想的です。
監査データベースには、Oracleコンポーネントおよび監査フレームワークに統合されたユーザー・アプリケーションによって生成された監査イベントが格納されます。
|
注意: 監査メタデータ・ストアは、監査データ・ストアとは別のものです。 |
このデータ・ストアの詳細は、第13.3.4項を参照してください。RCUを使用した監査スキーマの作成の詳細は、第14.2.1項を参照してください。
監査定義ファイル
アプリケーションでは、監査定義ファイルを使用して、監査サービスに、監査アクションを管理する監査ルール(イベント、フィルタなど)を指定します。
詳細は、13.5項を参照してください。
監査イベント
Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。また、アプリケーションはこのフレームワークにより、アプリケーションに固有なイベントを定義することもできます。
これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンドライン・ツール)により更新できます。
監査ローダー
監査ローダーは、Oracle WebLogic Serverインスタンスのモジュールであり、そのインスタンスの監査アクティビティをサポートします。監査データ・ストを構成すると、監査ローダーは、そのインスタンス内で実行されているすべてのコンポーネントについての監査レコードを収集し、それらのレコードをデータ・ストアにロードします。
Javaコンポーネントの場合、監査ローダーは、コンテナ起動の一部として起動されます。
システム・コンポーネントでは、(registerAudit() WLSTコマンドを使用して)監査ストアに登録し、コンテナの監査ローダーを使用してイベントをアップロードすることも、コマンドラインのスタンドアロン監査ローダーを使用することもできます。
監査ポリシー
監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーは、コンポーネント・レベルまたはドメイン・レベルのいずれかで定義できます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。
Oracle Fusion Middleware監査フレームワークには、次のようないくつかの事前定義済のポリシー・タイプが用意されています。
なし(対象のコンポーネントに対して監査は無効になっています)
低(定義はコンポーネントによって異なります)
中(定義はコンポーネントによって異なります)
高(定義はコンポーネントによって異なります)
カスタム(監査イベントの範囲を絞るためにフィルタを実装します)
監査ポリシーのコンポーネント・タイプ
監査するコンポーネントのタイプを指します。たとえば、Oracle Internet Directoryは認証時の監査可能イベントのソースになります。
コンポーネントごとに監査可能なイベントのリストは、第C.1項「監査イベント」を参照してください。
監査サービス
監査サービス・モデルは、Java EEおよびSEアプリケーションで監査機能を利用できるように、標準ベースの統合フレームワークを提供します。
バスストップ
バスストップは、監査データ・レコードが監査データ・ストアにプッシュされる前に格納されるローカル・ファイルです。監査データ・ストアが構成されていない場合、監査データはこれらのバスストップ・ファイルに残ります。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。監査データ・ストアが配備されている場合、バスストップはコンポーネントと監査データ・ストア間の中間的な場所として機能します。これらのローカル・ファイルは、構成可能な時間間隔に基づいて、監査データ・ストアに定期的にアップロードされます。
監査データ・ストアの主な利点は、複数のコンポーネントの監査データ(すべてのミドルウェア・コンポーネントやインスタンスにおける認証失敗など)をレポート内で関係付けて結合できる点です。
イベント・フィルタ
一部の監査イベントには、イベントをログに記録する時点を制御するフィルタが実装されています。たとえば、特定のユーザーのOracle Internet Directoryコンポーネントへの正常なログインのイベントにフィルタを適用できます。
詳細は、第14.3項「監査ポリシーの管理」を参照してください。
構成MBean
監査構成はすべて、監査構成用Mbeansによって管理されます。Javaコンポーネントおよびアプリケーションの場合、これらのMbeansはドメイン管理サーバー内に存在し、監査構成は集中管理されます。システム・コンポーネントの場合は、コンポーネント・インスタンスごとに別々のMbeanインスタンスが存在します。Enterprise ManagerのUIおよびコマンドライン・ツールでは、これらのMbeansを使用して、監査構成を管理します。
Oracle Business Intelligence Publisher
監査データ・ストア内のデータは、Oracle Business Intelligence Publisherの特定のコンポーネント(主にシステム・コンポーネント)で使用可能な事前定義済のレポートにより公開されます。ユーザーは、これらのレポートにより、様々な基準に基づいて監査データをドリルダウンすることができます。例:
ユーザー名
時間範囲
アプリケーション・タイプ
実行コンテキストID (ECID)
Oracle Business Intelligence Publisherを使用して、独自の監査レポートを作成することもできます。
Oracle Platform Security Services
Oracle Fusion Middlewareの主要コンポーネントであるOracle Platform Security Servicesは、Java Authentication and Authorization Service (JAAS)やJava EEセキュリティなどのJava機能に対応するOracle Fusion Middlewareのセキュリティの実装です。
OPSSの詳細は、第1.1項「Oracle Platform Security Servicesとは」を参照してください。
監査メタデータ・ストアはメタデータ・モデルに対するリポジトリを提供し、コンポーネント監査定義、NLS翻訳エントリ、実行時ポリシーおよびデータベース・マッピング表を含みます。
|
注意: 監査メタデータ・ストアは、実際の監査レコードが格納される監査データ・ストアとは別のものです。 |
監査メタデータ・ストアは、次のような重要な監査機能をサポートします。
監査登録サービスは、イベント定義エントリを作成、変更および削除します。
監査実行時サービスは、イベント定義および実行時ポリシーを取得します。
監査データ・ローダーは、監査データを格納するための属性データベース・マッピングを作成します。
監査MBeanコマンドは、コンポーネント監査定義および実行時ポリシーを検索して変更します。
監査フレームワークは、次の3つのタイプのメタデータ・ストアをサポートしています。
XMLファイルベース
データベース
LDAP
新しいアプリケーションが監査サービスに登録されると、次の監査アーティファクトが監査ストアに格納されます。
カスタム属性グループ、カテゴリ、イベントおよびフィルタ・プリセット定義を含む監査イベント定義
ローカライズされた翻訳エントリ
カスタム属性/データベース列マッピング表
実行時監査ポリシー
図13-1に示すように、監査データは2つのタイプの記憶域に配置できます。
監査データの中間的な記憶域となるバスストップ・ファイル。各コンポーネント・インスタンスは個別のバスストップにデータを書き込みます。
バスストップ・ファイルは、監査レコード用にすぐに使用できるデフォルトの記憶域メカニズムです。コンポーネントごとに個別のバスストップ・ファイルがあります。
バスストップ・ファイルはテキストベースで問合せが容易です。詳細は、第13.3.1項「監査アーキテクチャ」を参照してください。
データベース内の永続的記憶域(監査データ・ストアとも呼ばれます)。
データベースを使用する場合は、ドメイン内のすべてのOracle Fusion Middlewareインスタンスのすべてのコンポーネントによって生成された監査レコードが、同じストアに書き込まれます。Oracle Business Intelligence Publisherレポートを利用するには、監査データ・ストアを使用する必要があります。
ファイルベースの記憶域から監査データ・ストアに移行できます。これには固有の構成手順を実行する必要があります。詳細は、第14.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。
データベース・ストアを使用する利点
バスストップ・ファイルに監査レコードを格納する場合、実用面で次のような制限があります。
ドメイン・レベルの監査データを表示できません。
Oracle BI Publisherでレポートを実行できません。
一方、データベース監査データ・ストアを使用すると、次のような利点が得られます。
Oracle Business Intelligence Publisherを使用してレポートを作成できます。
バスストップでは監査レコードがインスタンス単位で格納されますが、データベース・ストアではドメイン内のすべてのコンポーネントのレコードを集中管理できます。
ファイルベースの記憶域と比較してパフォーマンスが向上する可能性があります。
このような理由から、オラクル社は、監査機能を拡張するためにデータベース・ストアへの切替えをお薦めします。
Oracle Fusion Middlewareでは、構造化レポート作成用のフル機能ツールとして、Oracle Business Intelligence Publisherを利用できます。独自のレポート作成アプリケーションを使用することもできます。
Oracle Business Intelligence Publisherでは、次のような多様な事前定義済レポートを使用できます。
作成済ユーザーおよび削除済ユーザー
ユーザー・トランザクション
認証と認可の失敗
ポリシー違反
Oracle Business Intelligenceの使用
ユーザー名や日時の範囲などの基準に基づいてレコードを選択できます。
Oracle Business Intelligenceは、データベース監査ストアでのみ機能します。バスストップ・ファイルでは使用できません。
Oracle Business Intelligenceで使用可能な事前定義済監査レポートのタイプは、次のとおりです。
エラーと例外
操作
ユーザー・アクティビティ
認証と認可の履歴
トランザクション履歴
詳細は、第C.2項「ビルトイン監査レポート」を参照してください。また、監査スキーマの詳細情報を使用して、必要に応じてカスタム監査レポートを作成することもできます。
Oracle Fusion Middlewareコンポーネントおよびアプリケーションで構成される環境を監査している管理者の観点からすると、機能的な監査システムの実装における重要な段階は、次のとおりです。
共通監査フレームワークのアーキテクチャを理解します。
フレームワークの必須要素、アクションのフローおよび監査サービス・モデルの機能を確認するには、第13.3.1項を参照してください。
アプリケーションを監査フレームワークと統合します。
統合手順の詳細は、第25.2項を参照してください。
アプリケーションの監査イベントおよびそれらを監査スキーマにマップする方法を記述した監査定義ファイルを作成します。
このトピックの詳細は、第25.3項を参照してください。
アプリケーションを監査サービスに登録します。
登録を有効にする方法はいくつかあります。詳細は、25.4項を参照してください。
監査情報をテスト環境から本番環境に移行します。
第6.6.3項を参照してください。
監査レポートを生成します。
監査フレームワークは、アプリケーションがその監査アーティファクトを柔軟に指定することを可能にするメタデータ・モデルをサポートしています。アプリケーションは属性グループ、カテゴリおよびイベントを動的に定義できます。
この項の内容は次のとおりです。
次のネーミング規則が、カテゴリ名、イベント名および属性名に適用されます。
すべて英語のみで記述する必要があります。
25文字以下にする必要があります。
使用できる文字は、aからz、AからZおよび0から9のみです。
先頭は英字にする必要があります。
属性グループは監査属性の広範な分類を提供し、次の3つのタイプから構成されます。
共通属性グループには、コンポーネント・タイプ、システムIPアドレス、ホスト名など、すべてのアプリケーションに共通のシステム属性が含まれます。
IAU_COMMONデータベース表には、このグループ内の属性が含まれます。
汎用属性グループには、認証やユーザー・プロビジョニングなどの監査アプリケーション領域に対する属性が含まれます。
カスタム属性グループには、特定のニーズに応じてアプリケーションで定義された属性が含まれます。カスタム・グループの属性は、そのコンポーネントのスコープに限定されます。
共通属性グループは、IAU_COMMONデータベース表に格納されています。
汎用属性グループは、ネームスペース、バージョン番号および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>
カスタム属性グループおよび属性は、IAU_CUSTOM表に格納されます。
監査イベント・カテゴリには、機能領域内の関連イベントが含まれます。たとえば、セッション・カテゴリには、ユーザー・セッションのライフサイクルで重要なログインおよびログアウト・イベントが含まれます。
イベント・カテゴリ自体は属性を定義しません。かわりに、コンポーネント内の属性およびシステム属性グループを参照します。
イベント・カテゴリには次の2つのタイプがあります。
システム・カテゴリ
コンポーネントとアプリケーション・カテゴリ
システム・カテゴリは、共通および汎用属性グループを参照し、監査イベントを含みます。システム・カテゴリは、コンポーネント・イベント・カテゴリおよびイベントのベース・セットです。アプリケーションはそれらを直接参照し、監査イベントを記録して、フィルタ・プリセット定義を設定できます。
次の例は、メタデータ・モデルのいくつかの要素を示しています。
共通属性グループ
汎用属性グループidentityとauthorization
共通属性AuthenticationMethodを参照する属性を持つシステム・カテゴリUserSession
UserLoginおよびUserLogoutなどの監査イベント
<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>
次の2種類の定義ファイルがあります。
component_events.xml定義ファイル
翻訳ファイル
component_events.xmlファイルでは、監査サービスで監査イベントをログに記録する際に必要な次のようなプロパティを指定します。
基本プロパティとメジャーおよびマイナー・バージョン
コンポーネント・タイプ(アプリケーションが監査サービスに登録し、実行時監査インスタンスを取得するために使用するプロパティ)
アプリケーションのメジャーおよびマイナー・バージョン
1つのカスタム属性グループ(含まれない場合もある)
属性参照およびイベントを含むイベント・カテゴリ
コンポーネント・レベル・フィルタ定義
次を含む実行時ポリシー
filterPreset - 監査フィルタ・レベルを指定します。
specialUsers - 常に監査するユーザーを指定します。
maxBusstopDirSize
maxBusstopFileSize
実行時ポリシーの詳細は、第14.3項を参照してください。
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>
登録サービスでは、特定のルールを使用して、アプリケーションに対して監査メタデータが作成されます。このメタデータは、監査定義の様々なバージョンを管理し、監査データをロードしてレポートを生成するために使用されます。
各監査定義には、整数のメジャーおよびマイナー・バージョン番号が必要です(例: major = 1 minor=3)。監査イベント定義を変更した場合は、マイナーまたはメジャー番号あるいはその両方を変更することによりバージョンIDを変更する必要があります。
監査登録サービスは、バージョン番号を使用してイベント定義の互換性およびバージョン間の属性マッピングを決定します。
|
注意: これらのバージョン番号はOracle Fusion Middlewareのバージョン番号とは関係ありません。 |
Oracleコンポーネントのバージョニング
Oracleコンポーネントの登録時、監査登録サービスは、これが初めての登録であるかアップグレードであるかを確認します。
新規登録では、サービスは次の操作を実行します。
コンポーネントの監査および翻訳情報を取得します。
定義を解析して検証し、監査メタデータ・ストアに格納します。
属性/列マッピング表を生成し、監査メタデータ・ストアに保存します。
アップグレードについては、メタデータ・ストア内のコンポーネントの現在のメジャーおよびマイナー番号が新しいメジャーおよびマイナー番号と比較され、アップグレードを続行するかどうかを決定します。
JavaEEアプリケーションのバージョニング
アプリケーションの監査定義の変更時には、メジャーおよびマイナー番号を次のように設定することをお薦めします。
マイナー・バージョン番号は、バージョン互換の変更(新しい監査定義から生成される属性データベース・マッピング表が、以前の属性データベース・マッピング表で作成された監査データでもそのまま使用できるような監査定義の変更)を加える場合にのみ増やします。
たとえば、現在の定義バージョンがmajor=2およびminor=1であるとします。属性データベース・マッピング表に影響しない新規イベントの追加時には、マイナー・バージョンを2に変更し(minor=2)、メジャー番号はそのままにします(major=2)。
新しいマッピング表が以前の表と互換性がないようなバージョン変更を加える場合には、メジャー・バージョン番号を増やします。
新しいコンポーネントまたはアプリケーションの登録時、登録サービスはコンポーネントのカスタム属性から属性/データベース列マッピング表を作成し、この表を監査メタデータ・ストアに保存します。
属性/データベース列マッピング表は、アプリケーションの属性定義とデータベース列間で一意なマッピングを行うために必要です。監査ローダーはマッピング表を使用してデータを監査ストアにロードします。表はカスタム・データベース表IAU_CUSTOMから監査レポートを生成するためにも使用されます。
コンポーネントの監査定義の表示
WLSTコマンドcreateAuditDBViewを使用して、コンポーネントの監査定義のデータベース・ビューを作成できます。
コマンド構文の詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。
createAuditDBViewコマンドを使用するには、コンポーネントの属性がデータベース列にマップされるしくみを理解しておく必要があります。詳細は次の説明を参照してください。
コンポーネントのマッピング表の理解
カスタム属性/データベース列マッピングには、属性名、データベース列名およびデータ型のプロパティがあります。
各カスタム属性定義には、マッピング順序番号が含まれている必要があります。同じデータ型の属性は、属性マッピング順序に従ってデータベース列にマップされます。たとえば、次のような定義ファイルがあるとします。
<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>
属性/データベース列マッピング表のバージョンIDは、カスタム属性グループのバージョンIDに一致します。これにより、アプリケーションは異なる監査定義バージョン間でも、属性マッピングの後方互換性を維持できます。バージョニングの詳細は、第13.5.3.1項を参照してください。
