ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 9.1 ドキュメント > WebLogic リソースのセキュリティ > WebLogic リソースのセキュリティについて

WebLogic リソースのセキュリティ

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

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

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

 

WebLogic リソースの保護の概要

WebLogic リソースとは、WebLogic Security サービスで基底の WebLogic Server エンティティを表すため、またそのエンティティに誰がアクセスできるのかを決定するために作成されるものです。一連の条件下でリソースにアクセスできるユーザ、グループ、またはロールを指定するには、セキュリティ ポリシーを作成します。セキュリティ ロールでは、セキュリティ グループと同様にユーザに ID が付与されます。ただしグループとは違い、ロールのメンバシップは実行時に評価される条件群に基づいて動作できます。

たとえば、エンタープライズ アプリケーション (EAR) をデプロイする際には、WebLogic Security サービスによって ApplicationResource オブジェクトが作成されます。クライアントが EAR と対話しようとすると、アプリケーション コンテナから WebLogic Security サービスにリクエストが転送されます。WebLogic Security サービスでは EAR の ApplicationResource に定義したセキュリティ ポリシーが参照され、その結果クライアントに処理を続行するパーミッションが与えられるか、リクエストが拒否されます。図 2-1 を参照してください。

図 2-1 リソースによるエンティティへのアクセス権の決定

リソースによるエンティティへのアクセス権の決定


 

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

図 2-2 ポリシーによるリソースへのアクセス付与方法

ポリシーによるリソースへのアクセス付与方法


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

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

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

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

  4. 管理者は、自社の確立されたビジネス手順に基づいてセキュリティ ポリシーを作成します。セキュリティ ポリシーは 1 つまたは複数のポリシー文で構成され、各ポリシー文にはポリシー条件が含まれます。ポリシー条件には、特定のセキュリティ ロールに保護対象 WebLogic リソースへのアクセス権を付与する状況が指定されます。
  5. 実行時に、WebLogic Security サービスにより、セキュリティ ポリシーおよび WebLogic リソース自体を使用して、保護対象 WebLogic リソースへのアクセス権を付与するかどうかが決定されます。セキュリティ ロールを付与されたグループのメンバーであるユーザのみが、WebLogic リソースにアクセスできます。図 2-2 のユーザ 3 とユーザ 6 はグループ 2 のメンバーで、グループ 2 に必要なセキュリティ ロールが付与されているので、保護対象 WebLogic リソースにアクセスできます。

 

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

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

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

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

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

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

    3. グローバル ポリシーは、あるリソース タイプの全インスタンスに適用されます。たとえば、アプリケーション リソース タイプにグローバル ポリシーを定義すると、そのポリシーはドメイン内のすべてのアプリケーションに適用されます。

    スコープ指定ポリシーは、特定のリソース インスタンスに適用されます。リソースに子リソースが含まれる場合、スコープ指定ポリシーはすべての子リソースにも適用されます。たとえば、EAR1 というエンタープライズ アプリケーションに対してスコープ指定ポリシーを作成すると、そのポリシーは EAR1 とそれに含まれる全モジュールにのみ適用されます。

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

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

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

  4. Administration Console を使用して、ユーザ、グループ、ロール、およびポリシーを作成します。
    1. ユーザとグループの作成については、Administration Console オンライン ヘルプの「ユーザとグループの管理」を参照してください。
    2. セキュリティ ロールの作成については、Administration Console オンライン ヘルプの「セキュリティ ロールの管理」を参照してください。
    3. セキュリティ ポリシーの作成については、Administration Console オンライン ヘルプの「セキュリティ ポリシーの管理」を参照してください。

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

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

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

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

 

フッタのナビゲーションのスキップ  ページの先頭 前 次