| Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 11gリリース1 (10.3.6) B55556-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 11gリリース1 (10.3.6) B55556-04 |
|
前 |
次 |
この章では、用語と概念を紹介し、処理の流れを概説してWebLogicリソースを保護するための主な手順について簡単に示します。
WebLogic Serverドメインのリソースを保護するには、ポリシーと(必要に応じて)ロールを作成します。リソースとは、エンティティ(Webサービスやサーバー・インスタンスなど)またはアクション(Webサービス内のメソッドや、サーバー・インスタンスを停止する操作など)です。ポリシーでは、一定の条件下でリソースにアクセスできるユーザー、グループ、またはロールを指定します。セキュリティ・グループなどのセキュリティロールによって、ユーザーにIDが付与されます。ただしグループとは違い、ロールのメンバーシップは実行時に評価される条件群に基づきます。
図2-1に、ロールとポリシーの作成方法と、セキュリティ・サービスがそれらを使用してクライアントからリソースにアクセスできるかどうかを決定する方法を示します。図の後には簡単な説明を記載します。
セキュリティ・ポリシーやセキュリティ・ロールを作成する前には、管理者が組織的な境界を表すグループにユーザーを静的に割り当てます。同じユーザーが複数のグループのメンバーになれます。図2-1には、それぞれ2ユーザーが割り当てられた3つのグループが示されています。ユーザー1とユーザー3は複数のグループのメンバーです。
多数のユーザーを抱えている場合に管理者の作業効率を向上できるので、ユーザーはグループに割り当てることをお薦めします。
管理者は、自社の確立されたビジネス手順に基づいてセキュリティ・ロールを作成します。セキュリティ・ロールは1つまたは複数の条件で構成され、この条件によって特定のユーザー、グループ、または他のロールにセキュリティ・ロールが付与される状況が指定されます。
実行時に、セキュリティ・サービスにより1つまたは複数のロール条件とグループが比較され、そのグループのユーザーに動的にセキュリティ・ロールを付与するかどうかが決定されます。このロールとグループを比較するプロセスをロール・マッピングと呼びます。図2-1では、グループ2のみにセキュリティ・ロールが付与されています。
個々のユーザーにセキュリティ・ロールを付与することもできますが、これは一般的ではありません。
管理者は、自社の確立されたビジネス手順に基づいてセキュリティ・ポリシーを作成します。セキュリティ・ポリシーは1つまたは複数のポリシー条件から構成されています。ポリシー条件には、特定のセキュリティ・ロールにWebLogicリソースへのアクセス権を付与する状況が指定されます。
実行時に、WebLogicセキュリティ・サービスにより、セキュリティ・ポリシーを使用して、保護対象WebLogicリソースへのアクセス権を付与するかどうかが決定されます。セキュリティ・ロールを付与されたグループのメンバーであるユーザーのみが、WebLogicリソースにアクセスできます。図2-1のユーザー3とユーザー6はグループ2のメンバーで、グループ2に必要なセキュリティ・ロールが付与されているので、保護対象WebLogicリソースにアクセスできます。
WebLogic Serverでは、1つのポリシーを使用してリソースの集合を保護する方法が2つあります。
特定のタイプのリソースをすべて保護するポリシーを作成することができます。このようなポリシーをルート・レベルのポリシーといいます。たとえば、Webサービス・タイプのルート・レベルのポリシーを作成することもできます。このルート・レベルのポリシーを定義したドメインにデプロイされるすべてのWebサービスは、ルート・レベルのポリシーによって保護されます。
特定のWebサービスのポリシーが定義されている場合は、Webサービスはそれぞれのポリシーによって保護され、ルート・レベルのポリシーは無視されます。
デプロイ対象のJava EEアプリケーションまたはモジュール内のすべてのリソースは階層内に存在し、階層の上位に存在するリソースのポリシーは、同じ階層の下位に存在するリソースに対してデフォルトのポリシーとして機能します。下位階層のポリシーは、常に上位階層のポリシーをオーバーライドします。
たとえば、EnterpriseApp1にはWebアプリケーションとJDBCモジュールとともに、EJB ModuleAが含まれています(図2-2を参照)。EnterpriseApp1用とEJB ModuleA内のメソッドY用にポリシーを作成します。EJBクライアントがメソッドYを呼び出す際、WebLogicセキュリティ・サービスは特定のポリシーを適用し、エンタープライズ・アプリケーション用のポリシーを無視します。
クライアントがEJBメソッドXへのアクセスを要求する際、EJBメソッドXが独自のポリシーによって保護されていない場合には、WebLogicセキュリティ・サービスから次の情報を求められます。
このEJBメソッドにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。
このメソッドを含むEJBにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。
このメソッドの親EJBを含むEJBモジュールにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。
このURLパターンを含むエンタープライズ・アプリケーションにはポリシーがあるか。ある場合、このポリシーを適用します(このようなポリシーが存在しない場合は、EJBに対してデフォルトのルート・レベルのポリシーが適用されます)。
管理コンソールにおいて、セキュリティ・レルムの「ロールとポリシー: ポリシー」ページで、リソースとポリシーの階層をグラフィカルに確認できます。このページへのアクセスについては、Oracle WebLogic Server管理コンソール・ヘルプの「リソース・インスタンスのポリシーの作成」を参照してください。
ドメイン内のリソースを保護する一連のロールとポリシーは、次のような手順で設計できます。
ドメインに含めるリソースをすべてリストアップして、特定のユーザーやグループにアクセスを限定するリソースを決定します。
特定のドメインに含まれるリソースのタイプの一覧については、第3章「ポリシーで保護できるリソースのタイプ」を参照してください。
プランニングのためにリソースを以下のカテゴリに分類します。
サーバー・リソース、管理リソース、およびJMXリソース。サーバー・リソースは、サーバー・インスタンスの起動と停止を誰が実行できるのかを決定します。管理リソースでは、アカウントからロックアウトされたユーザーのロック解除、ファイルのアップロード(デプロイ中に使用)、ドメインおよびサーバーのログの表示といった作業を誰が実施できるのかが決定されます。JMXリソースでは、サーバー、クラスタ、マシン、およびドメインの構成ドキュメント(config.xml)に定義されている他のコンポーネントの構成の変更を誰が実施できるのかが決定されます。
これらのタスクについては階層化された詳細なセキュリティ方式があらかじめ用意されていて、それによって8つのセキュリティ・ロール(Admin、Deployer、Operator、Monitor、Anonymous、AppTester、CrossDomainConnector、AdminChannelUser)に対し様々なタイプのアクセスが付与されます。ほとんどの環境においては、このセキュリティ方式で十分に対応できます。その場合、必要な作業は上記の8つのデフォルト・セキュリティ・ロールに適切にユーザーを割り当てることだけです(手順3を参照)。
この階層化されたセキュリティ方式は部分的に変更することもできますが、そうした変更は通常であれば必要ありません。変更する場合には、別のレイヤーとの間で一貫性を維持するために綿密な計画を立てる必要があります。「管理リソース」、「サーバー・リソース」、および「JMXリソース」を参照してください。
Webアプリケーション・リソースとEJBリソース。ドメインにデプロイしたWebアプリケーションやEJBに誰がアクセスできるのかを決定します。
Java EEプラットフォームでは、以前からWebアプリケーションとEJBを保護するための標準モデルが提供されています。この標準モデルでは、開発者がロール・マッピングやポリシーをWebアプリケーションまたはEJBのデプロイメント記述子に定義します。
この標準モデルまたは管理コンソールを使用してポリシーとロールを定義でき、それによって統合的で動的なセキュリティ管理が可能になります。第4章「WebアプリケーションおよびEJBリソースの保護のオプション」を参照してください。
上記以外の全リソース。エンタープライズ・アプリケーション内のビジネス・ロジックやビジネス・コンテンツ、およびドメインにデプロイまたは構成する他のモジュールに対して、誰がアクセスできるのかを決定します。
デフォルトでは、これらのリソースはポリシーによって保護されません。ポリシーを定義して誰がアクセスできるのかを決定する必要があります。
保護の対象とする各リソースのタイプについて、ルート・レベルのポリシー、スコープ指定ポリシー、またはその両方の組合せが必要がどうかを決定します。
ルート・レベルのポリシーは、あるリソース・タイプの全インスタンスに適用されます。たとえば、Webサービス・リソース・タイプにルート・レベルのポリシーを定義すると、そのポリシーはドメイン内のすべてのWebサービスに適用されます。
スコープ指定ポリシーは、特定のリソース・インスタンスに適用され、ルート・レベルのポリシーはオーバーライドされます。
第5章「セキュリティ・ポリシー」を参照してください。
ユーザーと、ユーザーがアクセスするリソースを分析します。ユーザーを次のようにセキュリティ・グループとロールに分類します。
サーバーの起動と停止、または他の管理タスクに関わるユーザーを8つのデフォルト・グローバル・ロールのどれかに追加します。WebLogic Serverのセキュリティ方式では、こうしたタスクの多くについて、この8つのグローバル・ロールにのみ実行が許可されます。
これ以外のユーザー(管理リソースやサーバー・リソースへのアクセスは付与せず、ポリシーが定義された他のリソースへのアクセスは付与するユーザー)用に、セキュリティ・グループとロールを別に作成します。ロール・メンバーシップは実行時に付与できるため、ビジネス・ルールやリクエストのコンテキストに基づいて、ユーザーやグループをロールに設定できます。
すべてのポリシーで使用できるグローバルロールや、特定のリソース・インスタンス用のポリシーでのみ使用できるスコープ指定ロールを作成できます。
第6章「ユーザー、グループ、セキュリティ・ロール」を参照してください。
管理コンソールを使用して、ユーザー、グループ、ロール、およびポリシーを作成します。
ロールとポリシーのどちらを使用しても実行時に一連の条件を評価できます。そのため、セキュリティ・データのどの部分を静的とし、どの部分を動的とするかを検討する必要があります。たとえば、あるリソースへのアクセスを1つの特定のロールに常に許可するポリシーが複数必要な場合には、ロールの定義で条件を使用して、必要に応じてそのロールにユーザーを追加したり削除したりするようにします。一方で、静的なロールを定義して、時間に応じて様々なロールにアクセスを許可するポリシーを作成する方式が適していることもあります。
一般的なガイドラインとしては、リソースにアクセスできるエンティティ(ロール)ではなく、リソースに基づいて認可判定を行う場合には、セキュリティ・ポリシーに条件を追加します。リソースに誰がアクセスできるのかということに基づいて認可を行う場合には、セキュリティ・ロールに条件を追加します。
リソースに誰がアクセスできるのかに基づく認可の例として、管理者(manager)が休暇を取る場合を検討します。このような場合、あるユーザーを一時的にManagerセキュリティ・ロールに設定できます。このセキュリティ・ロールを動的に付与することで、そうした一時的な措置のためにアプリケーションを変更したり再デプロイしたりする必要はなくなります。一時的な管理者が特別な権限を持つ期間を指定するだけです。さらに、本来の管理者が戻ってきても、ユーザーを一時的に管理者グループに追加した場合のように、特別な特権を取り消す必要もありません。
WebLogic認可プロバイダ(DefaultAuthorizer)およびWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)は、ロール、述部、およびそれらをルックアップするリソース・データをキャッシュすることでパフォーマンスが向上します。これらのWebLogicプロバイダを使用するようレルムを変更する際、キャッシュ内に格納する項目の最大数を構成できます。
|
注意: デフォルトでは、新しく作成されるドメイン内のセキュリティ・レルムにはXACML認可プロバイダとロール・マッピング・プロバイダが含まれています。XACMLプロバイダは独自のキャッシュを使用しますが、このキャッシュは構成できません。WebLogic Serverには、独自のポリシー言語を使用するWebLogic認可プロバイダ(DefaultAuthorizer)とWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)も用意されています。DefaultAuthorizerとDefaultRoleMapperは、資格データのキャッシュを構成できる唯一のWebLogic提供のセキュリティ・プロバイダです。 |
WebLogic認可プロバイダとロール・マッピング・プロバイダでは、各キャッシュ内に次の項目数がデフォルトで格納されます。
2,000項目(ロールのキャッシュ内)
このキャッシュには、ルックアップされた各ロールの名前やロールを保護するポリシーが格納されます。
200項目(述部のキャッシュ内)
このキャッシュには、WebLogic資格エンジンによってルックアップされた各述部が格納されます。
5,000項目(リソースのキャッシュ内)
このキャッシュには、ルックアップされた各リソースの名前やリソースを保護するポリシーが格納されます。
キャッシュの最大サイズを超えると、WebLogic資格エンジンは最長時間未使用(LRU)項目をキャッシュから削除します。
WebLogic Serverインスタンスのアプリケーションで2,000ロールまたは5,000リソースを超えて使用する場合は、キャッシュ・サイズを増やす必要があります(述部の場合はWebLogicプロバイダに含まれる項目数が50未満なので、このキャッシュのサイズを増やす必要はありません)。
キャッシュに格納される項目の最大数を変更するには、WebLogic Serverインスタンスのjava起動コマンドに次のシステム・プロパティのいずれかを指定します。
-Dweblogic.entitlement.engine.cache.max_role_count=max-roles
ただし、max-rolesはキャッシュするロールの最大数です。
-Dweblogic.entitlement.engine.cache.max_predicate_count=max-predicates
ただし、max-predicatesはキャッシュする述部の最大数です。
-Dweblogic.entitlement.engine.cache.max_resource_count=max-resources
ただし、max_resource_countはキャッシュするリソースの最大数です。
デフォルトでは、WebLogicプロバイダは項目の使用時にその項目をキャッシュに追加します。この構成によって、資格データの最初のルックアップは、以降のルックアップよりも時間がかかります。ただし、WebLogic Serverインスタンスの起動サイクル中にキャッシュをロードするよう構成することによって、最初のルックアップにかかる時間を短縮できます。それには、サーバーのjava起動コマンドに次のシステム・プロパティを指定します。
-Dweblogic.entitlement.engine.cache.preload=true
例:
java -Dweblogic.entitlement.engine.cache.max_role_count=6001 -Dweblogic.entitlement.engine.cache.max_resource_count=3001 -Dweblogic.entitlement.engine.cache.preload=true weblogic.Server
