| Oracle® Fusion Middleware Oracle Entitlements Server管理者ガイド 11g リリース1 (11.1.1) B65044-01 |
|
 前 |
 次 |
この章では、Oracle Entitlements Server 11gR1の機能とアーキテクチャの概要について説明します。この章には次の項目があります。
アクセス制御は、企業の情報、システムまたはリソースへのアクセス権を付与または拒否するのに使用するシステムです。このドキュメントの目的として、保護されているエンティティは保護リソース、アクセス権が付与または拒否されるエンティティはサブジェクト(ほとんどの場合現実の人)と呼ばれます。ポリシーはサブジェクトと、サブジェクトが保護リソース内で表示および実行できる内容を決定する操作のセットを一致させます。保護される操作はリソースのタイプにより異なります。たとえば、テキスト・ファイルに付加される保護される操作(読取り、変更、削除)は、銀行アプリケーションに付加できる操作(口座の表示、送金、プロファイルの変更)とは異なります。
アクセス制御は、認可されたサブジェクトだけが保護リソースにアクセスできることを保証するので、許可されていないまたは不注意によるリソースの変更を防止します。サブジェクトの認可は通常、認証の後に発生します。一般的に、アクセス制御システムは次の2種類の認可から構成されます。
大まかな認可は、主に悪影響のあるものを侵入させないようにすることに焦点を当てた技術を使用する境界認証です。通常、これは認可コールを作成するアプリケーション外のインターセプタにより実行されます。サブジェクトのリクエスタに関するポリシーとURLが考慮されます。
きめ細かな認可は、より詳細で、主に、認可コールを作成するアプリケーションにより制御されます。保護リソースのURLとその構成済のポリシーが、リソース特有またはユーザー属性の情報、およびリクエストのコンテキストなどとともに考慮されます。たとえば、従業員に通常の営業時間中はポータルへのアクセス権を付与し、週末のアクセス権は拒否するには、きめ細やかな認可が必要です。
したがって、アクセス制御システムは、管理しやすいながらも、アクセス権を付与(または拒否)できる複雑な条件のセットを許可できる、ポリシー・モデルをサポートする必要があります。Oracle Entitlements Serverは、ソフトウェア・コンポーネントおよびアプリケーション・ビジネス・オブジェクトを含む、あらゆるタイプのリソースに対する集中または分散アクセス制御の実行を伴う集中ポリシー管理を提供します。
Oracle Entitlements Serverはきめ細やかな認可製品で、これにより組織はリソースへのアクセスと使用を制御するポリシーを定義して管理することで、そのリソースを保護することができます。アクセス権限は、誰が、どのリソースに、いつ、どのように行うことができるかを指定することにより、ポリシーに定義されます。ポリシーでは、ソフトウェア・コンポーネント(URL、Javaサーバー・ページ、Enterprise JavaBeans、メソッド、サーブレッド、およびアプリケーションの構築に使用されるもの)、ビジネス・オブジェクト(銀行アプリケーションでの銀行口座や医療アプリケーションでの患者レコード、ビジネス関係の定義に使用されるものなどの、ユーザー・アカウントの表現、個人プロファイル、契約)を含む、あらゆるタイプのリソースの制御を実行できます。
Oracle Entitlements Serverでは、ロール・ポリシーおよびアクセス制御ポリシーの作成がサポートされます。ロール・ポリシーはユーザーが割り当てられたロールに関する制約を定義するのに使用されます(これはエンタープライズ・グループを使用して直接的または間接的に行われます)。アクセス制御ポリシーはソフトウェア・コンポーネントおよびビジネス・オブジェクトへのアクセスを定義します。次の各項には、前のリリースのOracle Entitlements Serverの情報とこのリリースであるOracle Entitlements Server 11gR1で開発された機能が含まれています。
Oracle Entitlements Server 11gR1はOracle Platform Security ServicesとOracle Entitlements Server 10g (以前のBEA AquaLogic Enterprise Security)の統合を表しています。Oracle Platform Security ServicesがJava認証および認可サービス(JAAS)セキュリティ・プロバイダで、大まかな認可を提供するのに対し、Oracle Entitlements Server 11gR1はJava Standard Edition (SE)およびEnterprise Edition (EE)、サービス指向アーキテクチャ(SOA)、.NETなどの複数のテクノロジを含む、エンドツーエンドのエンタープライズ・ソリューションです。Oracle Entitlements Server 11gR1では、認可リクエストのコンテキストが提供されてそれに基づきアクセス権が付与または拒否される、きめ細やかな認可が提供されます。Oracle Entitlements Server 11gR1の中心機能はeXtensible Access Control Markup Language (XACML)仕様に基づいています。
このリリースでは、認可ポリシー・マネージャがOracle Entitlements Serverの管理コンソールです。Oracle Entitlements Serverのドキュメント・セットの目的では、認可ポリシー・マネージャとさまざまなOracle Entitlements Server Administration Console (管理コンソールおよび同類のコンソールなど)は区別しないで使用されます。
|
注意: Oracle Entitlements ServerはOracle Authorization Policy Manager製品としてリリースされた製品の機能を含むためのものではありません。このドキュメント・セットでは、認可ポリシー・マネージャは単に管理コンソールのことです。 |
Oracle Entitlements Server 11gR1では、異機種間アプリケーション環境での、きめ細やかな認可と、集中化された資格管理が提供されます。さらにOracle Entitlements Serverでは、次のものが実行されます。
管理サーバーから決定エンドポイントへのポリシーの配布。
パフォーマンスのためのポリシーと認可決定のキャッシュ。
実行時のセキュリティ・ポリシーの更新。
埋込みおよびリモートの決定ポイントの両方をサポートする柔軟なアーキテクチャの提供(集中または分散ポリシー決定のため)。
セキュリティの決定とアプリケーション・ロジックの分離。
すべてのアクセス決定と管理操作の監査。
認可の照会用のeXtensible Access Control Markup Language (XACML)リクエスト/レスポンス・プロトコルのサポート。
リレーショナル・データベースおよびLDAPディレクトリのエンタープライズ・データの活用による、既存のセキュリティとアイデンティティ・システムの統合。
高レベルから、Oracle Entitlements Serverは、集中または分散ポリシー決定を伴う集中ポリシー管理から構成されます。Oracle Entitlements ServerのアーキテクチャはXACML仕様で検討されたエンティティの相互作用モデルに基づきます。このモデルは、多くのコンポーネントおよびデプロイメントに適用できる柔軟なアーキテクチャを提供するエンティティを定義します。図1-1に、Oracle Entitlements Serverのコンポーネントを示します。各コンポーネントはXACMLエンティティの1つに対応します。
次の各項には、Oracle Entitlements Serverコンポーネントの情報とコンポーネントがXACMLエンティティに準拠する方法が含まれています。
ポリシー管理ポイント(PAP)は特定の保護リソースを保護するのに使用されるポリシーが作成され管理される場所です(図1-1では、管理サーバーおよび管理APIがPAPを表します)。エンティティが保護リソースへのアクセスのリクエストに対する付与または拒否の決定を行うために、PAPはこれらのルールをポリシー決定ポイントが使用できるようにします。Oracle Entitlements Server PAPは管理コンソール、管理アプリケーション・プログラミング・インタフェース(API)および管理コマンドライン・ユーティリティから構成されます。図1-2にこれらの管理ツールのアーキテクチャを示します。
Oracle Entitlements Serverがデプロイされると、ポリシー決定ポイント(PDP)は認可のリクエストを受信し、適用できるポリシーに基づいて評価して決定し、その決定をポリシー決定ポイント(PEP)である、最初に認可コールを作成したエンティティに返します。
|
注意: PDPは追加のサブジェクト、リソース、アクション、および環境属性をポリシー情報ポイントから取得して、コンテキスト情報をリクエストに追加することもできます。詳細は、1.3.3項「ポリシー情報ポイント」を参照してください。 |
次にPEPが決定を実行します。PEPは保護アプリケーションへのリクエストをインターセプトし、それをPDPへ渡して、PDPから返されたセキュリティの決定を実行するソフトウェア・コンポーネントです。このソフトウェア・コンポーネントは保護アプリケーション自体またはセキュリティ・モジュールである可能性があります。PEPは必ずJave Standard Enterprise (JSE)アプリケーションまたはJava Enterprise Edition (JEE) Webコンテナに統合されています。
|
注意: PDPは決定(義務と呼ばれます)とともに、特定のコンテキスト内で決定を実行できる情報を戻すこともあります。アプリケーションはこれらの義務での動作を実行しません。詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。 |
Oracle Entitlements Serverでは2つのタイプのセキュリティ・モジュールが提供されます。1つのタイプでは、リクエストを受信し決定を下すことで単にPDPとして動作します。もう1つのタイプでは、このPDP機能とPEPの機能が組み合わされます。次の各項では、セキュリティ・モジュールの動作方法を説明します。
セキュリティ・モジュールが単にPDPとして動作する場合、その唯一の機能は意思決定です。認可リクエストを受信し、その決定を認可コールの作成元のPEPへ返します。セキュリティ・モジュールが単にPDPとして動作する場合、外部エンティティはPEPとして動作、つまり認可コールを作成し、返された決定を実行する必要があります。
図1-3に、コールを作成しているPEPエンティティがリソース(アプリケーション)そのものである場合の処理を示します。アクセスのリクエストを受信し、認可を開始して(セキュリティ・モジュールとの通信を介して)、返された決定を実行します。
図1-4に、PEPエンティティが、アプリケーションに到達する前にリクエストをインターセプトするエージェントまたはプラグイン(または同様のソフトウェア・コンポーネント)である場合の処理を示します。ソフトウェアコンポーネントはアクセスのリクエストをインターセプトし、認可を開始して(セキュリティ・モジュールとの通信を介して)、セキュリティ・モジュールから返された決定をアプリケーションに転送します。
これらのシナリオは連携して柔軟な認可サービスを提供することができます。たとえば、中間Webサービス/XMLゲートウェイはサブジェクトのポータルへのアクセスに対する認可決定をリクエストできます。この最初の決定が許可だと仮定すると、Webサービス/XMLゲートウェイ自体は、アクセス権を付与されたユーザー用にポータルをパーソナライズするのに使用される、次の認可決定をリクエストできます。
セキュリティ・モジュールがPDPとPEPとしてタンデムで動作する場合、認可リクエストをインターセプトし、決定を下し、決定を実行します。このリリースのOracle Entitlements Serverでは、このように動作する1つのセキュリティ・モジュールであるWebLogic Serverセキュリティ・モジュールがあります。
WebLogic Serverセキュリティ・モジュールは、保護アプリケーションを実行するOracle WebLogic Serverコンテナに直接接続し、自動的に認可をリクエストします。このシナリオでは、サブジェクト開始のアプリケーションへのリクエストは認可のためにWebLogic Serverによりインターセプトされます。WebLogic Serverは正常な認可後、セキュリティ・モジュールのインストール中に構成された認可プロバイダのセットへのコールを作成することで、リクエストを認可しようとします。
|
注意: Oracle WebLogic Serverの詳細は、Oracle WebLogic Serverドキュメント・ライブラリ( |
ロール・マッピングおよび認可プロキシ・プロバイダはOracle Entitlements Server認可エンジンと通信します(PEP APIをコールし、次にそれがPDPをコール)。PDPは決定を計算し、その決定をPEPへ返します。PEPは適切な応答をWebLogic Serverに返します(オプションで、PDPは決定とともに義務を返すこともあります)。アクセスが拒否された場合、WebLogic Serverはセキュリティ例外をスローし、アクセスを防ぎます。アクセスが許可された場合、WebLogic Serverはアクセスを許可します。図1-5に、このシナリオを示します。
プロバイダを使用する利点は、きめ細やかなレベルの認可を行えることです。たとえば、プロバイダを使用して、サーブレット自体は追加のPEP APIコールを作成して、返されたページでレンダリングされる要素を決定できるようにしながら、サーブレットURLへのアクセスを保護できます。デフォルトでは、ロール・マッピングおよび認可プロキシ・プロバイダは有効ではありません。
|
注意: WebLogic Serverコンソールを使用して認可プロバイダを有効にする手順については、11.1項「WebLogic Serverとの統合」を参照してください。構成後パラメータはA.2.4項「WebLogic Serverセキュリティ・モジュール」に記載されています。 |
前の段落の例に示したように、WebLogic Serverにより保護されたアプリケーションは、1.3.2.1項「PDPとしてのセキュリティ・モジュール」で説明したのと同様の目的で、PEP API (図1-3「PEPとして動作するアプリケーションがPDPからの決定をリクエスト」で説明)を使用して、依然としてOracle Entitlements Serverに直接コールすることができます。
図1-6にさまざまなタイプのセキュリティ・モジュールがどのように開発されたかについて示します。
このトポロジに基づき、セキュリティ・モジュールのサービスはいくつかの方法で起動できます。
Javaセキュリティ・モジュールは一般的なPDPで、Java APIを使用して認可の決定を行います。このセキュリティ・モジュールは次のコンテナでサポートされます。
Java, Standard Edition (JSE)
WebSphere
JBoss
マルチプロトコル・セキュリティ・モジュールは一般的なJavaセキュリティ・モジュールを含む(サービス指向アーキテクチャ原則に基づく)認可サービスです。RMI、Web ServicesおよびXACML (リクエストとレスポンス)を使用して認可の決定を行います。マルチプロトコル・セキュリティ・モジュールは通常、アプリケーションをホストしている個別のマシンではなく中央のサービスにデプロイされます。
|
注意: 図1-4「PEPとして動作するエージェントがリクエストをインターセプトして決定を下す」は、XMLゲートウェイを使用するマルチプロトコル・セキュリティ・モジュールと同様の動作をします。リクエストをインターセプトし、宛先に送信する前に、認可を実行します。 |
WebLogicセキュリティ・モジュールはPDPとPEPの両方を含む特注のJavaセキュリティ・モジュールです。明示的な認可APIコールを必要とせずに、WebLogic Serverから直接リクエストを受信できます。WebLogic Serverコンテナでのみ実行されます。
|
注意: 中央PDPとしてのセキュリティ・モジュールはRMI、Webサービス、またはXACMLコールでサポートされますが、Oracle Entitlements Serverとセキュリティ・モジュールは同じWebLogic Serverドメインには存在できません。 |
認可の決定のリクエストと、セキュリティ・モジュールがポリシー配布サービスを使用してポリシー情報を更新する方法の詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。
XACML仕様で定義されているように、ポリシー情報ポイント(PIP)はデータ・リポジトリであり、認可の決定用にポリシーを評価するときに使用するために取得される情報のソースです。これにより、属性の値がアクセスの決定に影響を与えることができるという点で、ポリシーがデータ駆動となることができます。たとえば、銀行口座からの送金へのアクセスが現在口座にある金額に基づく場合、属性リトリーバ・コンポーネントを使用して現在の残高を取得できます。
Oracle Entitlements Serverデプロイメントでは、属性リトリーバ・コンポーネントがPIPの役目を果たすので、PIPと属性リトリーバ・コンポーネントという用語は区別しないで使用されます。図1-1「Oracle Entitlements Serverのコンポーネント」に示した属性権限コンポーネントがPIPと考えられます。属性リトリーバ・コンポーネントは、LDAPとリレーショナル・データベースのデータ・ソースの両方で即時使用可能です。属性リトリーバ・コンポーネントの詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。
Oracle Entitlements Serverの認可プロセスには、1.3項「Oracle Entitlements Serverのアーキテクチャの概要」で説明したコンポーネントが含まれます。ポリシーの決定がリクエストされると、PDPはリクエストに関連するすべてのポリシーを評価し、付与または拒否の決定をコールしたアプリケーションに返します。図1-7にポリシー認可プロセスでのデータの流れを示します。
Oracle Entitlements Server (PAPとして動作)を使用して特定のリソースを保護するポリシーを作成および管理します。
ポリシー・リポジトリ内のポリシーは、ポリシー配布サービスにより、PDPに対してローカルであるポリシー・キャッシュにプッシュされます。PDPはポリシーをこのキャッシュから読み取ります。詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。
リソースへのリクエストはそれを保護しているPEPにより受信されます。PEPはアプリケーション自体またはセキュリティ・モジュールである可能性があります。どちらであってもOracle Entitlements Serverへの認可コールを作成します。
PEPはPDPへの認可コールを作成します。
セキュリティ・モジュールPDPは適切なデータ・ソースRIPからの追加のサブジェクト、リソース、アクション、および環境属性を問い合せます。
セキュリティ・モジュールPDPはリクエストを評価し、アクセスを付与または拒否する認証の決定の形式で、応答(および適用できる義務)をPEPに返します。
PEPは適用できる場合には義務を遂行します。義務は、決定とともに返される情報で、それに基づいてPEPは動作するまたは動作しない可能性があります。たとえば、義務には拒否する決定に関する追加情報が含まれていることがあります。PEPエンティティはその設定に基づき義務の遂行を担当します。Oracle Entitlements Serverはポリシー構成に基づき義務の転送のみを担当します。
アクセスが許可された場合、PEPは要求元にリソースへのアクセスを付与します。そうでない場合、アクセスは拒否されます。
2.2項「Oracle Entitlements Serverのポリシーの評価方法」に詳細が記載されています。
Oracle Entitlements Serverでは多くのアクセス制御モデルがサポートされます。多くのアクセス制御製品はこれらのモデルのうち1つのみをサポートしますが、Oracle Entitlements Serverでは、これらの多くをサポートする柔軟性を備えたポリシー・モデルが実装されています。厳密に1つのモデルに基づいて、または異なるモデルの一部を組み合わせて、デプロイすることができます。次の各項では、アクセス制御モデルについて説明します。
ロールベースのアクセス制御(RBAC)認可モデルはロールを使用してユーザーの権限を定義します。最初にロールが作成されます。次に特定の操作を実行するための権限がロールに割り当てられ、最後にユーザーまたはエンタープライズ・グループがロールに割り当てられます。ロールの割当てにより、割当て先は割り当てられた操作を実行する権限を取得します。つまり、RBACにより、個別の権限の管理は単に適切なロールを適切なエンティティに割り当てるという問題になります。ロール同士を階層内で結合させて、より高いレベルのロールに下位ロールが所有する権限を含めることもできます。アプリケーション・ロールはRBACに基づくOracle Entitlements Serverデプロイメントをモデル化するときに使用されます。
属性ベースのアクセス制御(ABAC)では属性を使用してきめ細やかな認可を定義する機能が提供されます。ロールを作成する必要はありません。ABACポリシーは、ユーザーにアクセス権を付与する前に満たす必要のある、ユーザーが特定の年齢である必要があるといった、1つまたは複数のクレームを指定します。ユーザーがこのクレームを証明できれば、アクセス権が付与されます。
|
ヒント: ABACに基づくOracle Entitlements Serverのデプロイメントをモデリングするときには制約が使用されます。詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。 |
Oracle Entitlements ServerはOracle Platform Security Services (OPSS)の拡張として構築されています。OPSSセキュリティ・モデルはJava Authentication and Authorization Service (JAAS)キュリティに基づいています。JAASでは原理ベースおよびコード・ベースのポリシーをサポートするJavaベースのセキュリティ標準を実装する、権限ベースの認可システムが導入されます。Java権限オブジェクトはリソースをアクセスする権限を示します。たとえば、次のコードは、/tmpディレクトリのabcという名前のファイルへの読取りアクセス権を示すFilePermissionオブジェクトを作成します。
perm = new java.io.FilePermission("/tmp/abc", "read");
Oracle Entitlements Server 11g R1はJava Development Kitのdeveloperバージョン1.6 (Standard EditionまたはEnterprise Editionプラットフォームのいずれも)をサポートします。
詳細は、Javaのドキュメント(http://www.oracle.com/technetwork/indexes/documentation/index.html)を参照してください。
eXtensible Access Control Markup Language (XACML)はポリシーを解釈する方法とアクセス制御ポリシー言語(XMLを使用して記述)について説明するアクセス制御モデルです。Oracle Entitlements ServerはXACML 2.0リクエストとレスポンスの標準をアーキテクチャ・モデルと同様に(1.3項「Oracle Entitlements Serverアーキテクチャの概要」で説明)実装します。また、XACMLでポリシーを原理、リソース、アクションおよび属性の集合として定義する方法も実装します。詳細は、XACML仕様を参照してください(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml)。
Oracle Entitlements ServerはOpen Azフレームワーク(http://www.openliberty.org)の一部であるPEP決定APIを実装しています。org.openliberty.openaz.azapiパッケージでは、PEPからリモートまたは埋込みPDPへのアクセスが提供されます。org.openliberty.openaz.azapi.pepパッケージ(PEP API)は、PEPにより使用されて認可リクエストをPDPに送信するように、Oracle Entitlements Serverにより実装されています。Open Az APIの詳細は、http://openaz.svn.sourceforge.net/viewvc/openaz/test/doc/index.html?org/openliberty/openaz/azapi/pep/package-summary.htmlを参照してください。PEP APIの実装の詳細は、『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』を参照してください。
|
注意: Oracle Entitlements Serverにより実装されているので、PEP APIはJava権限により保護されたリソースの認可決定はサポートしません。 |
