WebLogic リソースのセキュリティについて

この章では、用語と概念を紹介し、処理の流れを概説して WebLogic リソースを保護するための主な手順について簡単に示します。

WebLogic リソースの保護の概要

WebLogic Server ドメインのリソースを保護するには、ポリシーと (必要に応じて) ロールを作成します。リソースとは、エンティティ (Web サービスやサーバインスタンスなど) またはアクション (WebLogic Server 内のメソッドやサーバインスタンスを停止する操作など) です。ポリシーでは、一定の条件下でリソースにアクセスできるユーザ、グループ、またはロールを指定します。セキュリティグループなどのセキュリティ ロールによって、ユーザに ID が付与されます。ただしグループとは違い、ロールのメンバシップは実行時に評価される条件群に基づいて動作できます。

図 2-1 に、ロールとポリシーの作成方法と、Security サービスがそれらを使用してクライアントからリソースにアクセスできるかどうかを決定する方法を示します。図の後には簡単な説明を記載します。

セキュリティポリシーやセキュリティロールを作成する前には、管理者が組織的な境界を表すグループにユーザを静的に割り当てます。同じユーザが複数のグループのメンバーになれます。図 2-1 には、それぞれ 2 ユーザが割り当てられた 3 つのグループが示されています。ユーザ 1 とユーザ 3 は複数のグループのメンバーです。

多数のユーザを抱えている場合に管理者の作業効率を向上できるので、ユーザはグループに割り当てることをお勧めします。

管理者は、自社の確立されたビジネス手順に基づいてセキュリティロールを作成します。セキュリティロールは 1 つまたは複数の条件で構成され、この条件によって特定のユーザ、グループ、または他のロールにセキュリティロールが付与される状況が指定されます。
実行時に、WebLogic Security サービスにより 1 つまたは複数のロール条件とグループが比較され、そのグループのユーザに動的にセキュリティロールを付与するかどうかが決定されます。このロールとグループを比較するプロセスをロールマッピングと呼びます。図 2-1 では、グループ 2 のみにセキュリティロールが付与されています。

個々のユーザにセキュリティロールを付与することもできますが、これは一般的ではありません。

管理者は、自社の確立されたビジネス手順に基づいてセキュリティポリシーを作成します。セキュリティポリシーは 1 つまたは複数のポリシー条件から構成されています。ポリシー条件には、特定のセキュリティロールに WebLogic リソースへのアクセス権を付与する状況が指定されます。
実行時に、WebLogic Security サービスにより、セキュリティポリシーを使用して、保護対象 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 Security サービスは特定のポリシーを適用し、エンタープライズアプリケーション用のポリシーを無視します。

クライアントが EJB メソッド X へのアクセスを要求する際、EJB メソッド X が独自のポリシーによって保護されていない場合には、WebLogic Security サービスから次の情報を求められます。

この EJB メソッドにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。
このメソッドを含む EJB にはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。
このメソッドの親 EJB を含む EJB モジュールにはポリシーがあるか。ない場合は、階層の次の上位レベルに移動します。
この URL パターンを含むエンタープライズアプリケーションにはポリシーがあるか。ある場合、このポリシーを適用します (このようなポリシーが存在しない場合は、EJB に対してデフォルトのルートレベルのポリシーが適用されます)。

図 2-2 リソースとポリシーの階層

リソースとポリシーの階層

セキュリティレルムのロールおよびポリシーに関する Administration Console の [ポリシー] ページで、リソースとポリシーの階層をグラフィカルに確認できます。[ポリシー] ページへのアクセスの詳細については、Administration Console オンラインヘルプの「リソースインスタンスのポリシーの作成」を参照してください。

WebLogic リソースのロールとポリシーの設計 : 主な手順

ドメイン内のリソースを保護する一連のロールとポリシーは、次のような手順で設計できます。

ドメインに含めるリソースをすべてリストアップして、特定のユーザやグループにアクセスを限定するリソースを決定します。

特定のドメインに含められるリソースのタイプの一覧については、「ポリシーで保護できるリソースのタイプ」を参照してください。

プランニングのためにリソースを以下のカテゴリに分類します。

サーバリソース、管理リソース、および 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 のデプロイメント記述子に定義します。

この標準モデルまたは Administration Console を使用してポリシーとロールを定義でき、それによって統合的で動的なセキュリティ管理が可能になります。「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。

上記以外の全リソース。エンタープライズアプリケーション内のビジネスロジックやビジネスコンテンツ、およびドメインにデプロイまたはコンフィグレーションする他のモジュールに対して、誰がアクセスできるのかを決定します。

デフォルトでは、これらのリソースはポリシーによって保護されません。ポリシーを定義して誰がアクセスできるのかを決定する必要があります。

保護の対象とする各リソースのタイプについて、ルートレベルのポリシー、スコープ指定ポリシー、またはその両方の組み合わせが必要がどうかを決定します。

ルートレベルのポリシーは、あるリソースタイプの全インスタンスに適用されます。たとえば、Web サービスリソースタイプにルートレベルのポリシーを定義すると、そのポリシーはドメイン内のすべての Web サービスに適用されます。

スコープ指定ポリシーは、特定のリソースインスタンスに適用され、ルートレベルのポリシーはオーバーライドされます。

「セキュリティポリシー」を参照してください。

アクセス権を付与するリソースとユーザについて分析し、以下のとおりユーザをセキュリティグループとロールにまとめます。

サーバの起動と停止、または他の管理タスクに関わるユーザを 8 つのデフォルトグローバルロールのどれかに追加する。WebLogic Server のセキュリティ方式では、こうしたタスクの多くについて、この 8 つのグローバルロールにのみ実行が許可されます。
これ以外のユーザ (管理リソースやサーバリソースへのアクセスは付与せず、ポリシーが定義された他のリソースへのアクセスは付与するユーザ) 用に、セキュリティグループとロールを別に作成する。ロールメンバシップは実行時に付与できるため、ビジネスルールやリクエストのコンテキストに基づいて、ユーザやグループをロールに設定できます。

すべてのポリシーで使用できるグローバル ロールや、特定のリソースインスタンス用のポリシーでのみ使用できるスコープ指定ロールを作成できます。

「ユーザ、グループ、セキュリティロール」を参照してください。

Administration Console を使用して、ユーザ、グループ、ロール、およびポリシーを作成します。

ユーザとグループの作成については、Administration Console オンラインヘルプの「ユーザとグループの管理」を参照してください。
セキュリティロールの作成については、Administration Console オンラインヘルプの「セキュリティロールの管理」を参照してください。
セキュリティポリシーの作成については、Administration Console オンラインヘルプの「セキュリティポリシーの管理」を参照してください。

ベストプラクティス : ポリシーへの条件指定とロールへの条件指定

ロールとポリシーのどちらを使用しても実行時に一連の条件を評価できます。そのため、セキュリティデータのどの部分を静的とし、どの部分を動的とするかを検討する必要があります。たとえば、あるリソースへのアクセスを 1 つの特定のロールに常に許可するポリシーが複数必要な場合には、ロールの定義で条件を使用して、必要に応じてそのロールにユーザを追加したり削除したりするようにします。一方で、静的なロールを定義して、時間に応じてさまざまなロールにアクセスを許可するポリシーを作成する方式が適していることもあります。

一般的なガイドラインとしては、リソースにアクセスできるエンティティ (ロール) ではなく、リソースに基づいて認可判定を行う場合には、セキュリティポリシーに条件を追加します。リソースに誰がアクセスできるのかということに基づいて認可を行う場合には、セキュリティロールに条件を追加します。

リソースに誰がアクセスできるのかに基づく認可の例として、管理者 (manager) が休暇を取る場合を検討します。このような場合、あるユーザを一時的に Manager セキュリティロールに設定できます。このセキュリティロールを動的に付与することで、こうした一時的な措置のためにアプリケーションを変更したり再デプロイしたりする必要がなくなり、その一時的な管理者が特別な特権を持つ時間を指定するだけで済むようになります。さらに、本来の管理者が戻ってきても、ユーザを一時的に管理者グループに追加した場合のように、特別な特権を取り消す必要もありません。

ベストプラクティス : WebLogic プロバイダの使用時に資格のキャッシングをコンフィグレーションする

WebLogic 認可プロバイダ (DefaultAuthorizer) および WebLogic ロールマッピングプロバイダ (DefaultRoleMapper) は、ロール、述部、およびそれらをルックアップするリソースデータをキャッシュすることでパフォーマンスが向上します。これらの WebLogic プロバイダを使用するようレルムを変更する際、キャッシュ内に格納する項目の最大数をコンフィグレーションできます。

WebLogic 認可プロバイダとロールマッピングプロバイダでは、各キャッシュ内に次の項目数がデフォルトで格納されます。

キャッシュの最大サイズを超えると、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 起動コマンドに次のシステムプロパティを指定します。

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

ロールおよびポリシーによる WebLogic リソースの保護