Oracle® Fusion Middleware Oracle Entitlements Serverの管理 11gリリース2 (11.1.2.3.0) E67353-01 |
|
![]() 前 |
![]() 次 |
この章では、Oracle Entitlements Serverの機能とアーキテクチャの概要について説明します。この章には次の項目があります。
アクセス制御は、企業の情報、システムまたはリソースへのアクセス権を付与または拒否するのに使用するシステムです。このドキュメントの目的として、保護されているエンティティは保護リソース、アクセス権が付与または拒否されるエンティティはサブジェクトまたはプリンシパル(ほとんどの場合現実の人)と呼ばれます。認可ポリシーはサブジェクトと、サブジェクトが保護リソース内で表示および実行できる内容を決定する操作のセットを一致させます。操作はリソースのタイプにより異なります。たとえば、テキスト・ファイルに付加される操作(読取り、変更、削除)は、銀行アプリケーションに付加できる操作(口座の表示、送金、プロファイルの変更)とは異なります。
アクセス制御は、認可されたサブジェクトだけが保護リソースにアクセスできることを保証するので、許可されていないまたは不注意によるリソースの変更を防止します。サブジェクトの認可は通常、認証の後に発生します。一般的に、アクセス制御システムは次の2種類の認可から構成されます。
大まかな認可は、主に悪影響のあるものを侵入させないようにすることに焦点を当てた技術を使用する境界認証です。通常、これは認可コールを作成するアプリケーション外のインターセプタにより実行されます。サブジェクトのリクエスタに関するポリシーとURLが考慮されます。
きめ細かな認可は、より詳細で、主に、認可コールを作成するアプリケーションにより制御されます。保護リソースのURLとその構成済のポリシーが、リソース特有またはユーザー特有の属性の情報、およびリクエストのコンテキストなどとともに考慮されます。たとえば、従業員に通常の営業時間中はポータルへのアクセス権を付与し、週末のアクセス権は拒否するには、きめ細やかな認可が必要です。
したがって、アクセス制御システムは、管理しやすいながらも、アクセス権を付与(または拒否)できる複雑な条件のセットを許可できる、ポリシー・モデルをサポートする必要があります。Oracle Entitlements Serverは、ソフトウェア・コンポーネントおよびアプリケーション・ビジネス・オブジェクトを含む、あらゆるタイプのリソースに対する集中または分散アクセス制御の実行を伴う集中ポリシー管理を提供します。
Oracle Entitlements Serverはきめ細やかな認可製品で、これにより組織はリソースへのアクセスと使用を制御するポリシーを定義して管理することで、そのリソースを保護することができます。アクセス権限は、誰が、どのリソースに、いつ、どのように行うことができるかを指定することにより、ポリシーに定義されます。ポリシーでは、ソフトウェア・コンポーネント(URL、Javaサーバー・ページ、Enterprise JavaBeans、メソッド、サーブレット、およびアプリケーションの構築に使用されるもの)、ビジネス・オブジェクト(銀行アプリケーションでの銀行口座や医療アプリケーションでの患者レコード、ビジネス関係の定義に使用されるものなどの、ユーザー・アカウントの表現、個人プロファイル、契約)を含む、あらゆるタイプのリソースの制御を実行できます。
Oracle Entitlements Serverでは、ロール・マッピング・ポリシーおよび認可ポリシーの作成がサポートされます。ロール・マッピング・ポリシーは、ロールを割り当てるユーザーに関する制約を定義し、ポリシー・ストア内のアプリケーション・ロールをアイデンティティ・ストア内の外部グループにマッピングできます。このマッピングにより、外部グループのユーザーは、アプリケーション・ロールの指定に従って、リソースにアクセスできます。このマッピングは多対多にすることができます。認可ポリシーは、保護されたソフトウェア・コンポーネントおよびビジネス・オブジェクトへのアクセスを定義します。次の各項では、前のリリースのOracle Entitlements Serverの情報とこのリリースのOracle Entitlements Serverで開発された機能について説明します。
Oracle Entitlements Server 11gはOracle Platform Security ServicesとOracle Entitlements Server 10g(以前のBEA AquaLogic Enterprise Security)の統合を表しています。Oracle Platform Security Services (OPSS)がJava認証および認可サービス(JAAS)セキュリティ・プロバイダで、大まかな認可を提供するのに対し、Oracle Entitlements Server 11gはJava Standard Edition (SE)およびEnterprise Edition (EE)、サービス指向アーキテクチャ(SOA)、.NETなどの複数のテクノロジを含む、エンドツーエンドのエンタープライズ・ソリューションです。Oracle Entitlements Server 11gでは、認可リクエストのコンテキストを提供でき、それに基づきアクセス権が付与または拒否される、きめ細やかな認可が提供されます。Oracle Entitlements Server 11gのアーキテクチャはコアのeXtensible Access Control Markup Language (XACML)仕様で記述されている相互作用モデルに基づきます。詳細は、1.3項「Oracle Entitlements Serverのアーキテクチャの概要」を参照してください。
Authorization Policy Managerは、Oracle Entitlements Serverの管理コンソールです。Oracle Entitlements Serverのドキュメント・セットの目的では、Authorization Policy Managerと様々なOracle Entitlements Server Administration Console(管理コンソールおよび同類のコンソールなど)は区別しないで使用されます。管理コンソールの詳細は、第3章「Oracle Entitlements Serverの使用のスタート・ガイド」を参照してください。
注意: Oracle Entitlements ServerはOracle Authorization Policy Manager製品としてリリースされた製品の機能を含むためのものではありません。このドキュメント・セットでは、認可ポリシー・マネージャは単に管理コンソールのことです。 |
Oracle Entitlements Server 11gR2では、異機種間アプリケーション環境での、きめ細やかな認可と、集中化された資格管理が提供されます。さらに、Oracle Entitlements Server 11gR2のこのリリースでは、次の機能が提供されています。
XACML 3.0仕様で定義されているすべてのデータ型と関数のサポート
Oracle Platform Security Servicesで作成されたアプリケーション権限(アプリケーション・ポリシー)の表示と変更のサポート
ロギングの機能拡張によるポリシー評価分析の単純化
ポリシー・シミュレータ
デバッグの機能拡張
権限ベースの拡張ポリシーのサポート
拡張PEP API問合せリクエスト
管理コンソールにおける複数のアイデンティティ・ストアの接続のサポート
SMConfig UI(セキュリティ・モジュール構成インタフェース)
.NETリソースのサポート
Javaコンテナ、Webサービス(WebLogic Server上)、Oracle Service Bus、Microsoft Sharepoint、JBossおよびTomcatのセキュリティ・モジュール
高レベルから、Oracle Entitlements Server (OES)は、集中または分散ポリシー決定を伴う集中ポリシー管理から構成されます。Oracle Entitlements ServerのアーキテクチャはXACML仕様で検討されたエンティティの相互作用モデルに基づきます。このモデルは、多くのコンポーネントおよびデプロイメントに適用できる柔軟なアーキテクチャを提供するエンティティを定義します。図1-1に、Oracle Entitlements Serverのコンポーネントを示します。各コンポーネントはXACMLエンティティの1つに対応します。
次の各項には、Oracle Entitlements Serverコンポーネントの情報とコンポーネントがXACMLエンティティに準拠する方法が含まれています。
ポリシー管理ポイント(PAP)は特定の保護リソースを保護するのに使用されるポリシーが作成され管理される場所ですエンティティが保護リソースへのアクセスのリクエストに対する付与または拒否の決定を行うために、PAPはこれらのルールをポリシー決定ポイントが使用できるようにします。Oracle Entitlements Server PAPは認可管理アプリケーション・プログラミング・インタフェース(API)から構成されます。(図1-1では、管理サーバーおよび管理APIがPAPを表します。)PAPには、管理コンソール、WebLogic Scripting Tool (WLST)、ポリシー配布コンポーネントまたは他の様々なツール(migrateSecurityStore
および再関連付けツール)から、アクセス(および使用)できます。図1-2は、アーキテクチャを示しています。
Oracle Entitlements Serverがデプロイされると、ポリシー決定ポイント(PDP)は認可のリクエストを受信し、適用できるポリシーに基づいて評価して決定し、その決定をポリシー決定ポイント(PEP)である、最初に認可コールを作成したエンティティに返します。次にPEPが決定を実行します。
注意: PDPは追加のサブジェクト、リソース、アクションおよび環境属性をポリシー情報ポイントから取得して、コンテキストをリクエストに追加できます。詳細は、1.3.3項「ポリシー情報ポイントの理解」を参照してください。 |
PEPは、認可リクエストをインターセプトするのではなく、アプリケーションに送信されたアクセス・リクエストをインターセプトし、リクエストを認可するために、認可リクエストを形成してPDPに送信します。PDPから付与または拒否の決定を受信すると、その決定を実行します。PEPは、それ自体が保護アプリケーションまたはセキュリティ・モジュールである可能性があるソフトウェア・コンポーネントです。
注意: PDPは決定(責任と呼ばれます)とともに、特定のコンテキスト内で決定を実行できる情報を戻すこともあります。アプリケーションはこれらの責任での動作を実行しません。詳細は、第2章「ポリシー・モデルの理解」を参照してください。 |
Oracle Entitlements Serverでは2つのタイプのセキュリティ・モジュールが提供されます。1つのタイプは、リクエストを受信し決定を下すことで単にPDPとして動作するように開発されました。もう1つのタイプは、このPDP機能にPEPの機能を組み合せたセキュリティ・モジュール・タイプであり、リクエストを受信し、認可決定を下して、この決定を実行します。第7章「ポリシー決定ポイントのデプロイ」では、セキュリティ・モジュールのデプロイ方法について説明します。次の各項では、セキュリティ・モジュールの動作方法を説明します。
注意: セキュリティ・モジュールは、インストール・プロセスの実行前および実行中は、OESクライアントと呼ばれます。 |
セキュリティ・モジュールが単にPDPとして動作する場合、その唯一の機能は意思決定です。認可リクエストを受信し、その決定を認可コールの作成元のPEPへ返します。セキュリティ・モジュールが単にPDPとして動作する場合、外部エンティティはPEPとして動作、つまり(Oracle Entitlements Server認可APIを使用して)認可コールを作成し、返された決定を実行する必要があります。
図1-3に、コールを作成しているPEPエンティティがリソース(アプリケーション)そのものである場合の処理を示します。アクセスのリクエストを受信し、認可を開始して(セキュリティ・モジュールとの通信を介して)、返された決定を実行します。
図1-4に、PEPエンティティが、アプリケーションに到達する前にリクエストをインターセプトするエージェントまたはプラグイン(または同様のソフトウェア・コンポーネント)である場合の処理を示します。ソフトウェアコンポーネントはアクセスのリクエストをインターセプトし、認可を開始して(セキュリティ・モジュールとの通信を介して)、セキュリティ・モジュールから返された決定をアプリケーションに転送します。
これらのシナリオは連携して柔軟な認可サービスを提供することができます。たとえば、中間Webサービス/XMLゲートウェイはサブジェクトのポータルへのアクセスに対する認可決定をリクエストできます。この最初の決定が許可だと仮定すると、Webサービス/XMLゲートウェイ自体は、アクセス権を付与されたユーザー用にポータルをパーソナライズするのに使用される、次の認可決定をリクエストできます。
セキュリティ・モジュールがPDPとPEPとしてタンデムで動作する場合、認可リクエストをインターセプトし、決定を下し、決定を実行します。このリリースのOracle Entitlements Serverでは、WebLogic Server、Oracle Service BusおよびMicrosoft SharePointの各セキュリティ・モジュールは、この方法で動作します。
たとえば、WebLogic Serverセキュリティ・モジュールは、保護アプリケーションを実行するOracle WebLogic Serverコンテナに直接接続し、自動的に認可をリクエストします。このシナリオでは、サブジェクト開始のアプリケーションへのリクエストは認可のためにWebLogic Serverによりインターセプトされます。WebLogic Serverは正常な認可後、セキュリティ・モジュールのインストール中に構成された認可プロバイダのセットへのコールを作成することで、リクエストを認可しようとします。
ロール・マッピングおよび認可プロキシ・プロバイダはOracle Entitlements Server認可エンジンと通信します(PEP APIをコールし、次にそれがPDPをコール)。PDPは決定を計算し、その決定をPEPへ返します。PEPは適切な応答をWebLogic Serverに返します。(オプションで、PDPは決定とともに責任を返すこともあります。)アクセスが拒否された場合、WebLogic Serverはセキュリティ例外をスローし、アクセスを防ぎます。アクセスが許可された場合、WebLogic Serverはアクセスを許可します。図1-5に、このシナリオを示します。
プロバイダを使用する利点は、きめ細やかなレベルの認可です。たとえば、プロバイダを使用することによって、サーブレットURLへのアクセスを保護すると同時に、返されたページにレンダリングする必要がある要素を決定するためにさらにPEP APIをコールすることをサーブレット自体に許可することができます(図1-3「PEPとして動作するアプリケーションがPDPからの決定をリクエスト」を参照)。デフォルトでは、ロール・マッピングおよび認可プロキシ・プロバイダは有効ではありません。
注意: WebLogic Serverコンソールを使用して認可プロバイダを有効にする手順については、9.4項「WebLogic Serverリソースの保護」を参照してください。構成後パラメータはA.2.5項「WebLogic Serverセキュリティ・モジュール」に記載されています。 |
図1-6に様々なタイプのセキュリティ・モジュールがどのように開発されたかについて示します。
このトポロジに基づき、セキュリティ・モジュールのサービスはいくつかの方法で起動できます。
Javaセキュリティ・モジュールは一般的なPDPで、Java APIまたは.NET APIを使用して認可の決定を行います。このセキュリティ・モジュールは次のコンテナでサポートされます。
Java, Standard Edition (JSE)
WebSphere
JBoss
Tomcat
Microsoft Sharepoint Server
マルチプロトコル・セキュリティ・モジュールは一般的なJavaセキュリティ・モジュールを含む(サービス指向アーキテクチャ原則に基づく)認可サービスです。RMI、Web ServicesおよびXACML (リクエストとレスポンス)を使用して認可の決定を行います。マルチプロトコル・セキュリティ・モジュールは、保護されたアプリケーションと同一場所に配置するか、または中央のサーバーにデプロイすることができます。
注意: 図1-4「PEPとして動作するエージェントがリクエストをインターセプトして決定を下す」は、XMLゲートウェイを使用するマルチプロトコル・セキュリティ・モジュールと同様の動作をします。リクエストをインターセプトし、宛先に送信する前に、認可を実行します。 |
WebLogic、Oracle Service Bus (OSB)およびSharepointの各セキュリティ・モジュールは、PDPとPEPを両方含むセキュリティ・モジュールです。明示的な認可APIコールを必要とせずに、コンテナから直接リクエストを受信できます。
注意: RMI、WebサービスまたはXACMLコールでは中央にデプロイされるセキュリティ・モジュールがサポートされますが、Oracle Entitlements Serverとセキュリティ・モジュールは同じWebLogic Serverドメインには存在できません。デプロイメント・モデルの詳細は、第7章「ポリシー決定ポイントのデプロイ」を参照してください。 |
認可の決定のリクエストと、セキュリティ・モジュールがポリシー配布サービスを使用して更新されたポリシー情報を取得する方法の詳細は、『Oracle Entitlements Server開発者ガイド』を参照してください。セキュリティ・モデルの構成と使用の詳細は、第8章「セキュリティ・モジュールの構成の管理」と第9章「環境固有のリソースの保護」を参照してください。
ポリシー情報ポイント(PIP)はデータ・リポジトリであり、認可の決定用にポリシーを評価するときに使用するために取得できる情報のソースです。これにより、属性の値がアクセスの決定に影響を与えることができるという点で、ポリシーがデータ駆動となることができます。たとえば、銀行口座からの送金へのアクセスが現在口座にある金額に基づく場合、属性リトリーバ・コンポーネントを使用して現在の残高を取得できます。
Oracle Entitlements Serverデプロイメントでは、属性リトリーバがPIPの役目を果たすので、このマニュアルではPIPと属性リトリーバという用語は区別しないで使用されます。図1-1「Oracle Entitlements Serverのコンポーネント」に示した属性権限コンポーネントがPIPと考えられます。属性リトリーバ・コンポーネントは、LDAPとリレーショナル・データベースのデータ・ソースの両方で即時使用可能です。属性リトリーバの詳細は、『Oracle Entitlements Server開発者ガイド』および付録B「属性リトリーバの構成」を参照してください。
Oracle Entitlements Serverの認可プロセスには、1.3項「Oracle Entitlements Serverのアーキテクチャの概要」で説明したコンポーネントが含まれます。ポリシーの決定がリクエストされると、PDPはリクエストに関連するすべてのポリシーを評価し、付与または拒否の決定をコールしたアプリケーションに返します。図1-7にポリシー認可プロセスでのデータの流れを示します。
Oracle Entitlements Server (PAPとして動作)を使用して特定のリソースを保護するポリシーを作成および管理します。
ポリシー・リポジトリ内のポリシーは、ポリシー配布サービスにより、PDPに対してローカルであるポリシー・キャッシュにプッシュされます。PDPはポリシーをこのキャッシュから読み取ります。詳細は、『Oracle Entitlements Server開発者ガイド』を参照してください。
リソースへのリクエストはそれを保護しているPEPにより受信されます。PEPはアプリケーション自体またはセキュリティ・モジュールである可能性があります。どちらであってもOracle Entitlements Serverへの認可コールを作成します。
PEPはPDPへの認可コールを作成します。
セキュリティ・モジュールPDPは適切なデータ・ソースPIPからの追加のサブジェクト、リソース、アクション、および環境属性を問い合せます。
セキュリティ・モジュール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のデプロイメントをモデリングするときには条件が使用されます。詳細は、4.6項「条件ビルダーの使用」を参照してください。
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は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リクエストとレスポンスの標準をアーキテクチャ・モデルと同様に(1.3項「Oracle Entitlements Serverアーキテクチャの概要」で説明)実装します。また、XACMLでポリシーをプリンシパル、リソース、アクションおよび属性の集合として定義する方法も実装します。詳細は、XACML仕様を参照してください(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
)。
注意: このリリースのOracle Entitlements Serverには、XACML 3.0のデータ型と関数のサポートのみが追加されています。 |
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.sourceforge.net
で説明されています。PEP APIの実装の詳細は、『Oracle Entitlements Server開発者ガイド』を参照してください。
注意: Oracle Entitlements Serverにより実装されているので、PEP APIはJava権限により保護されたリソースの認可決定はサポートしません。 |