ヘッダーをスキップ
Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド
11g リリース1(11.1.1)
B56235-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

12 Oracle Fusion Middleware監査フレームワークの概要

Oracle Fusion Middleware 11g リリース1 (11.1.1)において、監査はアカウンタビリティを実現する手段であり、また、誰が、いつ、何を行ったかというタイプの質問への回答を提供します。この章では、Oracle Fusion Middlewareにおける監査の概要を説明します。次のトピックが含まれます:

12.1 Oracle Fusion Middleware監査フレームワークの利点と機能

この項の内容は次のとおりです。

12.1.1 監査の目的

コンプライアンスがビジネス要件の不可欠な要素になりつつある現在、監査のサポートもエンタープライズ・デプロイメントにおける注目の的になりつつあります。顧客は、追加設定なしですぐに使用できる監査サポートを提供するアプリケーション・ベンダーを探しています。また、カスタム・アプリケーションをデプロイするミドルウェアの顧客は、デプロイされる監査が必要な全アプリケーションの監査を集中管理したいと考えています。

IT 組織では、コンプライアンス、監視および分析という要件の観点から、主要な監査機能を探しています。

コンプライアンス

コンプライアンスがエンタープライズにおける主要な要件であることは、明白です。Sarbanes-Oxley法(財務)やHealth Insurance Portability and Accountability Act (HIPAA: 医療保険)のような規制により、多くの顧客は現在、アプリケーションやデバイスで、アイデンティティ情報およびユーザー・アクセスの監査を実行できる必要があります。これらには、次のようなイベントが含まれます。

  • ユーザー・プロファイルの変更

  • アクセス権の変更

  • ユーザー・アクセス・アクティビティ

  • 操作アクティビティ(アプリケーションの起動と停止、アップグレード、バックアップなど)

これにより、コンプライアンス担当者は、コンプライアンス・ポリシーを定期的に見直すことができます。

監視

監査データからは通常、監視目的のために、豊富なデータ・セットが得られます。公開されるログ・データおよびコンポーネント・メトリックだけでなく、監査データを使用してダッシュボードを作成したり、アラート用のキー・パフォーマンス・インディケータ(KPI)を設定したりして、様々なシステムの状態を継続的に監視することもできます。

分析

また、監査データを分析し、管理効果を評価することもできます。監査データは、リスク分析にも使用できます。履歴データに基づいてリスク・スコアを計算し、任意のユーザーに割り当てることもできます。ユーザー・アクセスのどのような実行時評価にも、システムに対するアクセスを保護するための追加の基準として様々なリスク・スコアを含めることができます。

12.1.2 現在の監査の課題

監査要件を満たすため、IT組織ではしばしばデプロイされるアプリケーションに対する監査サポートの欠如と闘っています。それは、次の点に対して信頼できる標準が存在していないからです。

  • 監査レコードの生成

  • 監査レコードのフォーマットと格納

  • 監査ポリシーの定義

その結果、現在の監査ソリューションには、次のような多くの大きな問題点があります。

  • 集中管理される監査フレームワークがありません。

  • 監査サポートの品質がアプリケーションごとにまちまちです。

  • 監査データがエンタープライズ全体に散乱しています。

  • コンポーネント間の意味のある分析を実行するには、その前に複雑なデータの関係付けが必要となります。

  • 監査ポリシーとその構成も散乱しています。

これらの要因により、IT組織は適切な監査ソリューションの構築および維持にかなりの時間とリソースを割いています。データが個々のサイロに散乱していて、一貫性も集中管理もない状態では、様々なベンダーが現時点における独自の監査機能を使用して実現しているアプリケーション間に統一性がなく、監査ソリューションも脆弱になりがちです。

12.1.3 Oracle Fusion Middleware 11gの監査フレームワーク

11gリリース1 (11.1.1)で導入されたOracle Fusion Middleware監査フレームワークは、集中管理された監査フレームワークをミドルウェアの製品ファミリに提供するよう設計されています。このフレームワークは、次のものに対して監査サービスを提供します。

  • ミドルウェア・プラットフォーム: これには、Oracle Platform Security Services (OPSS)やOracle Web ServicesなどのJavaコンポーネントが含まれます。これらは、ミドルウェアでデプロイされるアプリケーションによって使用されるコンポーネントです。これらのJavaコンポーネントを使用するデプロイされたアプリケーションはすべて間接的に、プラットフォーム・レベルで発生するイベントを監視する際、監査フレームワークから恩恵を受けることになります。

  • Java EEアプリケーション: 目的は、Oracle自体のJava EEベースのコンポーネントをはじめとするJava EEアプリケーションにフレームワークを提供することです。Java EEアプリケーションは、アプリケーションに固有な監査イベントを作成できます。

  • システム・コンポーネント: Oracle Process Manager and Notification Serverによって管理されるミドルウェア内のシステム・コンポーネントの場合、監査フレームワークはJavaコンポーネントのエンドツーエンド構造に類似したエンドツーエンド構造も提供します。


関連項目:

Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項


12.2 監査機能の概要

Oracle Fusion Middleware監査フレームワークの主要な機能には、次のものがあります。

12.3 Oracle Fusion Middleware監査フレームワークの概念

この項では、Oracle Fusion Middleware監査フレームワークの次の基本概念を説明します。

12.3.1 監査アーキテクチャ

Oracle Fusion Middleware監査フレームワークは、次の主要なコンポーネントから構成されています。

  • 監査API

    このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。アプリケーションは実行時、これらのAPIを適宜コールして、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査する場合もあります。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。

  • 監査フレームワークにより、次のAPIが提供されます。

    • 監査サービスAPI

    • 監査クライアントAPI

  • 監査イベントと構成

    Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。また、アプリケーションはこのフレームワークにより、アプリケーションに固有なイベントを定義することもできます。

    これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンドライン・ツール)により更新できます。

  • 監査バスストップ

    バスストップは、監査データ・レコードが監査データ・ストアにプッシュされる前に格納されるローカル・ファイルです。監査データ・ストアが構成されていない場合、監査データはこれらのバスストップ・ファイルに残ります。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。監査データ・ストアが配備されている場合、バスストップはコンポーネントと監査データ・ストア間の中間的な場所として機能します。これらのローカル・ファイルは、構成可能な時間間隔に基づいて、監査データ・ストアに定期的にアップロードされます。

    監査データ・ストアの主な利点は、複数のコンポーネントの監査データ(すべてのミドルウェア・コンポーネントやインスタンスにおける認証失敗など)をレポート内で関係付けて結合できる点です。

  • 監査ローダー

    名前からわかるように、監査ローダー(構成されている場合)は監査バスストップの監査データを監査データ・ストアにロードします。Javaコンポーネントの監査の場合、監査ローダーはコンテナ起動の一部として起動される起動クラスです。システム・コンポーネントの場合、監査ローダーはOPMNによって起動される、定期的に作成されるプロセスです。

  • 監査データ・ストア

    監査データ・ストアは、リポジトリ作成ユーティリティ(RCU)によって作成される、事前定義済のOracle Fusion Middleware監査フレームワーク・スキーマが含まれるデータベースです。構成が完了すると、すべての監査ローダーが監査データ・ストアを認識し、データを監査データ・ストアに定期的にアップロードします。監査ストア内の監査データは累積されることが想定され、時間の経過に伴って増加します。監査ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型RDBMSであるのが理想的です。

    監査データベースには、Oracleコンポーネントおよび監査フレームワークに統合されたユーザー・アプリケーションによって生成された監査イベントが格納されます。

  • 監査メタデータ・ストア

    監査メタデータ・ストアには、コンポーネントおよびアプリケーションに対する監査イベント定義が含まれます。

  • 監査構成用Mbeans

    監査構成はすべて、監査構成用Mbeansによって管理されます。Javaコンポーネントおよびアプリケーションの場合、これらのMbeansはドメイン管理サーバー内に存在し、監査構成は集中管理されます。システム・コンポーネントの場合は、コンポーネント・インスタンスごとに別々のMbeanインスタンスが存在します。Enterprise ManagerのUIおよびコマンドライン・ツールでは、これらのMbeansを使用して、監査構成を管理します。

  • Oracle Business Intelligence Publisher

    監査データ・ストア内のデータは、Oracle Business Intelligence Publisherの事前定義済のレポートにより公開されます。ユーザーは、これらのレポートにより、様々な基準に基づいて監査データをドリルダウンすることができます。例:

    • ユーザー名

    • 時間範囲

    • アプリケーション・タイプ

    • 実行コンテキストID (ECID)

    Oracle Business Intelligence Publisherを使用して、独自の監査レポートを作成することもできます。

図12-1 監査イベントのフロー

図12-1については周辺のテキストを参照

監査フロー

このプロセスは、アプリケーション・サーバー・インスタンス内で監査可能なイベント(たとえばログイン)が発生した場合に、フレームワーク内で実行されるアクションを示すことにより説明できます。


注意:

図12-1で示したアーキテクチャには、監査データ・ストアが含まれています。監査データ・ストアが構成されていないサイトの場合、監査レコードはバスストップ・ファイル内にあります。


  1. アプリケーションのデプロイメント時または監査サービスの起動時に、Java EEアプリケーションまたはOracleコンポーネントなどのクライアントが監査サービスに登録されます。

  2. サービスはアプリケーションの事前構成済の監査定義ファイルを読み取り、監査定義でメタデータ・ストアを更新します。

  3. ユーザーがそのコンポーネントまたはアプリケーションにアクセスすると、イベントを監査するために監査API関数がコールされます。

  4. 監査フレームワークは、このタイプ、ステータス、および特定の属性のイベントを監査する必要があるかどうかを確認します。

  5. 監査が必要な場合は監査関数が起動され、監査イベント構造体が作成されて、ステータス、イニシエータ、リソース、ECIDなどのイベント情報が収集されます。

  6. イベントは、バスストップとして知られる中間的な場所にあるローカル・ファイルに格納されます。各コンポーネントは個別のバスストップを持ちます。

  7. 監査ストアとしてデータベースが構成されている場合、監査ローダーはバスストップからイベントをプルし、アプリケーションのメタデータを使用してデータを書式化し、データを監査ストアに移動します。

  8. Oracle BI Publisherを使用して、監査データからレポートを生成することもできます。事前定義済のレポート・セットも使用できます(第14章「監査分析と監査レポートの使用」を参照してください)。

監査が失敗した場合のアプリケーションの動作

アプリケーションは、どのような理由で監査イベントを記録できない場合であっても、実行を中止することはありません。

12.3.2 重要な技術的概念

この項では、Oracle Fusion Middleware監査フレームワークの重要な概念を説明します。

監査対応コンポーネント

監査対応とは、Oracle Fusion Middleware監査フレームワークに統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントを指します。Oracle Internet Directoryは監査対応コンポーネントの一例です。

スタンドアロン・アプリケーションは、jps-config.xmlファイルを使用して構成を行うことで、Oracle Fusion Middleware監査フレームワークとの統合が可能です。詳細は、第28章を参照してください。

監査メタデータ・ストア

監査メタデータ・ストアには、コンポーネント、および監査フレームワークに統合されたアプリケーションに対する監査イベント定義が格納されます。

監査データ・ストア

監査データ・ストアは、監査イベント・データ用のリポジトリです。


注意:

メタデータ・ストアは監査データ・ストアとは別のものです。


監査ローダー

監査ローダーは、Oracle WebLogic Serverインスタンスのモジュールであり、そのインスタンスに対するプロセス管理を行います。監査ローダーは、そのインスタンス内で実行されているすべてのコンポーネントに対する監査レコードを収集し、監査データ・ストアにロードします。

監査ポリシー

監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

Oracle Fusion Middleware監査フレームワークには、次のようないくつかの事前定義済のポリシー・タイプが用意されています。

  • なし

  • 低(少数のイベントを監査し、定義はコンポーネントによって異なります)

  • 中(多数のイベントを監査し、定義はコンポーネントによって異なります)

  • カスタム(監査イベントの範囲を絞るためにフィルタを実装します)

監査ポリシーのコンポーネント・タイプ

監査するコンポーネントのタイプを指します。たとえば、Oracle Internet Directoryは認証時の監査可能イベントのソースになります。

コンポーネントごとに監査可能なイベントのリストは、第C.1項「監査イベント」を参照してください。

イベント・フィルタ

一部の監査イベントには、イベントをログに記録する時点を制御するフィルタが実装されています。たとえば、特定のユーザーのOracle Internet Directoryコンポーネントへの正常なログインのイベントにフィルタを適用できます。

詳細は、第13.3項「監査ポリシーの管理」を参照してください。

Oracle Platform Security Services

Oracle Fusion Middleware 11gの主要コンポーネントであるOracle Platform Security Servicesは、Java Authentication and Authorization Service (JAAS)やJava EEセキュリティなどのJava機能に対応するOracle Fusion Middlewareのセキュリティの実装です。

OPSSの詳細は、第1.1項「Oracle Platform Security Servicesとは」を参照してください。

12.3.3 監査メタデータ記憶域

監査メタデータとは、監査イベント、その属性およびカテゴリに関する情報を指します。

詳細は第28章を参照してください

12.3.4 監査データ記憶域

図12-1に示すように、監査データは2つのタイプの記憶域に配置できます。

  • 監査データの中間的な記憶域となるバスストップ・ファイル。各コンポーネント・インスタンスは個別のバスストップにデータを書き込みます。

    バスストップ・ファイルは、監査レコード用にすぐに使用できるデフォルトの記憶域メカニズムです。

    • Javaコンポーネントの場合は、Oracle WebLogic Serverインスタンスごとに1つのバスストップが存在します。特定のOracle WebLogic Serverインスタンスで実行されるすべてのJava EEコンポーネントに対して生成された監査レコードが、同じバスストップに格納されます。

    • システム・コンポーネントの場合は、コンポーネントごとに独立したバスストップが存在します。たとえば、Oracle Internet Directoryの各インスタンスは、個別にバスストップを持ちます。

    バスストップ・ファイルはテキストベースで問合せが容易です。詳細は、第12.3.1項「監査アーキテクチャ」を参照してください。

  • データベース内の永続的記憶域(監査データ・ストアとも呼ばれます)。

    データベースを使用する場合は、ドメイン内のすべてのOracle Fusion Middleware 11gインスタンスのすべてのコンポーネントによって生成された監査レコードが、同じストアに格納されます。Oracle Business Intelligence Publisherレポートを利用するには、監査データ・ストアを使用する必要があります。

ファイルベースの記憶域から監査データ・ストアに移行できます。これには固有の構成手順を実行する必要があります。詳細は、第13.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

データベース・ストアを使用する利点

バスストップ・ファイルに監査レコードを格納する場合、実用面で次のような制限があります。

  • ドメイン・レベルの監査データを表示できません。

  • Oracle BI Publisherでレポートを実行できません。

一方、データベース監査データ・ストアを使用すると、次のような利点が得られます。

  • Oracle Business Intelligence Publisherを使用してレポートを作成できます。

  • バスストップでは監査レコードがインスタンス単位で格納されますが、データベース・ストアではドメイン内のすべてのコンポーネントのレコードを集中管理できます。

  • ファイルベースの記憶域と比較してパフォーマンスが向上する可能性があります。

このような理由から、オラクル社は、監査機能を拡張するためにデータベース・ストアへの切替えをお薦めします。

12.3.5 分析

Oracle Fusion Middleware 11gでは、構造化レポート作成用のフル機能ツールとしてOracle Business Intelligenceを利用できます。

また、次のような多数の事前定義済レポートも使用できます。

  • 作成済ユーザーおよび削除済ユーザー

  • ユーザー・トランザクション

  • 認証と認可の失敗

  • ポリシー違反

Oracle Business Intelligenceの使用

  • ユーザー名や日時の範囲などの基準に基づいてレコードを選択できます。

    Oracle Business Intelligenceは、データベース監査ストアでのみ機能します。バスストップ・ファイルでは使用できません。

BI Publisherのページ
illustration cafintro1.gifの説明

Oracle Business Intelligenceで使用可能な事前定義済監査レポートのタイプは、次のとおりです。

  • エラーと例外

  • 操作

  • ユーザー・アクティビティ

  • 認証と認可の履歴

  • トランザクション履歴

詳細は、第C.2項「ビルトイン監査レポート」を参照してください。また、監査スキーマの詳細情報を使用して、必要に応じてカスタム監査レポートを作成することもできます。