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