WebSphere Application Server, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

管理役割およびネーミング・サービスの許可

WebSphere Application Server では、 Java 2 Platform, Enterprise Edition (J2EE) セキュリティーの役割ベースのアクセス制御を拡張して、 製品管理サブシステムおよびネーミング・サブシステムを保護します。

管理役割

多くの管理 役割が定義され、管理コンソールまたは wsadmin と呼ばれるシステム管理スクリプト・インターフェースから、 特定の WebSphere Application Server 管理機能を実行するのに必要なさまざまな度合いの権限を提供します。 許可ポリシーは、管理セキュリティーが使用可能になっている場合にのみ実行されます。 次の表は、管理の役割についての説明です。

表 1. 管理コンソールおよび wsadmin から使用可能な管理役割
役割 説明
モニター モニター役割を使用する個々のユーザーまたはグループの持つ特権は最少となります。モニターは、 以下のタスクを実行できます。
  • WebSphere Application Server の構成を表示します。
  • Application Server の現在の状態を表示します。
コンフィギュレーター コンフィギュレーター役割を使用する個々のユーザーまたはグループは、モニター特権に加え、 WebSphere Application Server 構成を変更できる権限を持ちます。 コンフィギュレーターは日常的な構成タスクをすべて行うことができます。例えば、コンフィギュレーターは、以下のタスクを実行できます。
  • リソースを作成します。
  • アプリケーション・サーバーをマップします。
  • アプリケーションをインストールおよびアンインストールします。
  • アプリケーションをデプロイします。
  • アプリケーションに、ユーザーおよびグループから役割へのマッピングを割り当てます。
  • アプリケーションの Java 2 セキュリティー許可をセットアップします。
  • Common Secure Interoperability バージョン 2 (CSIv2)、Security Authentication Service (SAS)、および Secure Sockets Layer (SSL) の構成をカスタマイズします。
    重要: SAS がサポートされるのは、 バージョン 6.1 セルに統合されたバージョン 6.0.x と、 それより前のバージョンの間のサーバーに限られます。
オペレーター オペレーター役割を使用する個々のユーザーまたはグループは、 モニター特権に加え、ランタイムの状態を変更できる権限を持ちます。 例えば、オペレーターは、以下のタスクを実行できます。
  • サーバーを停止および開始します。
  • 管理コンソールでサーバーの状態をモニターします。
管理者 管理者役割を使用する個々のユーザーまたはグループは、 オペレーター特権とコンフィギュレーター特権に加え、 管理者役割にのみ与えられる追加特権を持ちます。 例えば、管理者は、以下のタスクを実行できます。
  • サーバー・ユーザー ID およびパスワードを変更します。
  • 認証メカニズムおよび許可メカニズムを構成します。
  • 管理セキュリティー セキュリティーを使用可能または使用不可にします。
    注: WebSphere Application Server の以前のリリースでは、 「管理セキュリティーを有効にする」オプションは「グローバル・セキュリテ ィーの使用可能化 」オプションです。
  • Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションを使用して、 Java 2 セキュリティーを実行します。
  • Lightweight Third Party Authentication (LTPA) のパスワード変更、および鍵の生成を行います。
  • フェデレーテッド・リポジトリー構成のユーザーを作成、更新、または削除します。
  • フェデレーテッド・リポジトリー構成のグループを作成、更新、または削除します。
注: 管理者は、ユーザーおよびグループを管理者の役割にマップできません。
Adminsecuritymanager この役割を付与されたユーザーのみが管理の役割にユーザーをマップすることができます。 また、非常に詳細な管理セキュリティーが使用されている場合、この役割を付与されたユーザーのみが、許可グループを管理することができます。 詳しくは、管理の役割 を参照してください。
デプロイヤー この役割を付与されたユーザーは、 アプリケーションで、構成操作および実行時の操作の両方を実行できます。
表 2. 管理コンソールを使用して使用可能な追加の管理役割
役割 説明
iscadmins この役割は、管理コンソールのユーザーのみ使用可能です。 wsadmin ユーザーは使用できません。この役割を付与されたユーザーには、統合リポジトリー内でユーザーおよびグループを管理する管理者特権が付与されます。 例えば、iscadmins の役割のユーザーは、以下のタスクを実行できます。
  • フェデレーテッド・リポジトリー構成のユーザーを作成、更新、または削除します。
  • フェデレーテッド・リポジトリー構成のグループを作成、更新、または削除します。

管理セキュリティー が使用可能である場合、 管理サブシステムの役割ベースのアクセス制御が実行されます。 管理サブシステムには、セキュリティー・サーバー、管理コンソール、 wsadmin スクリプト・ツール、およびすべての Java Management Extensions (JMX) MBeans が組み込まれています。 管理セキュリティーが使用可能である場合、管理コンソールおよび管理スクリプト・ツールの両方は、 必要な認証データの提供をユーザーに要求します。 さらに、管理コンソールは、 ページに表示される制御機能がユーザーの持つセキュリティー役割に従って調整されるように設計されています。 例えば、モニター役割のみを持つユーザーが参照できるのは、 機密情報ではない構成データのみです。 オペレーター役割を持つユーザーは、システム状態を変更できます。

レジストリーを変更する場合 (例えば、フェデレーテッド・リポジトリーから LDAP へ)、 以前に構成された、コンソール・ユーザーおよびコンソール・グループのレジストリーに関する情報を必ず除去してください。

管理セキュリティー が使用可能である場合、 WebSphere Application Server は、 アクティブ・ユーザー・レジストリー構成で定義されたサーバー ID で稼働します。 管理コンソールやその他のツールに表示されない場合でも、 特別な対象 Server は管理者役割にマップされます。 サーバー ID で実行される WebSphere Application Server ランタイム・コードには、 ランタイム操作に対する許可が必要です。 他のどのユーザーも管理役割に割り当てられていない場合、 サーバー ID を使用して管理コンソールまたは wsadmin スクリプト・ツールにログインすれば、 管理操作を実行したり、他のユーザーやグループを管理役割に割り当てたりすることができます。 このサーバー ID はデフォルトで管理役割に割り当てられているため、 管理セキュリティー・ポリシーは管理役割に以下の操作を実行するように要求します。

  • サーバー ID およびサーバー・パスワードを変更する
  • WebSphere Application Server 管理セキュリティー を使用可能または不可にする
  • Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションを使用して、 Java 2 セキュリティーを実行します。
  • LTPA パスワードを変更する、または鍵を生成する
  • ユーザーおよびグループを管理役割に割り当てる

1 次管理ユーザー名

WebSphere Application Server の バージョン 6.1 リリースでは、 管理アクションの監査能力を向上させるため、 サーバー・ユーザー ID とは別の管理ユーザーが必要です。 ローカル・オペレーティング・システムで 定義される管理特権を持つユーザーを、 ユーザー名によって指定します。

サーバー・ユーザー ID

WebSphere Application Server の バージョン 6.1 リリースでは、 監査能力を向上させるために、 サーバー ID と管理ユーザー ID が区別されます。 サーバー・ユーザー ID は、サーバー間通信の認証に使用されます。

内部サーバー ID

内部サーバー ID を使用すると、 サーバー間認証用のユーザー ID を自動生成できるようになります。 サーバー ID の自動生成は、 バージョン 6.1 以降のノードの場合に限り、 セルに対する監査能力の向上をサポートします。 バージョン 6.1 リリースの WebSphere Application Server では、内部生成されたサーバー ID を保管できます。 これは、Security WebSphere Common Configuration Model (WCCM) モデルに、 新しいタグ (internalServerId) が組み込まれたためです。 混在しているセル環境以外では、セキュリティー設定中にサーバーのユーザー ID およびパスワードを指定する必要はありません。 内部生成のサーバー ID は、サーバー環境に、さらに上のレベルの保護を追加します。 これは、バージョン 6.1 より前のリリースのようにサーバー・パスワードが公開されることがないためです。 しかし、後方互換性を維持するために、以前のバージョンの WebSphere Application Server を使用する場合には、 サーバー・ユーザー ID を指定する必要があります。

セキュリティーを使用可能にすると、1 つ以上のユーザーおよびグループをネーミング役割に割り当てることができます。 詳しくは、ネーミング役割へのユーザーの割り当てを参照してください。ただし、ユーザーをネーミング役割に割り当てる前に、アクティブ・ユーザー・レジストリーを構成してください。 ユーザーとグループの検証はアクティブ・ユーザー ・レジストリーに依存します。詳しくは、ユーザー・レジストリーの構成を参照してください。

特別な対象

ユーザーまたはグループのマッピング以外に、 特別な対象 を管理役割にマップすることができます。 特別な対象とは、 特定クラスのユーザーを一般化したものです。特別な対象が AllAuthenticated である場合、 管理の役割のアクセス検査によって、要求を出しているユーザーが少なくとも認証済みであることを意味します。 特別な対象が Everyone である場合、認証されているか否かにかかわらず、 セキュリティーが使用可能になっていない場合と同様に、すべてのユーザーがアクションを実行できることを意味します。

ネーミング・サービスの権限

CosNaming セキュリティーでは、CosNaming 機能に対する セキュリティー管理の細分性が高まりました。CosNaming 機能は、WebSphere Application Server などの CosNaming サーバー上で使用可能です。 これらの機能は、WebSphere Application Server ネーム・スペースの内容に影響を与えます。通常、クライアント・プログラムが 最終的に CosNaming 呼び出しを行う方法は 2 つあります。1 つは、Java Naming and Directory Interface (JNDI) 呼び出しを介する方法です。2 つ目は、 CosNaming メソッドを直接呼び出す Common Object Request Broker Architecture (CORBA) クライアントを使用する方法です。

次の 4 つのセキュリティー役割が導入されています。
  • CosNamingRead
  • CosNamingWrite
  • CosNamingCreate
  • CosNamingDelete
役割には、以下のような低から高までの権限レベルがあります。
CosNamingRead
ユーザーは、例えば、JNDI ルックアップ・メソッドを使用して、WebSphere Application Server ネーム・スペースの照会が 可能です。特別な対象の Everyone が、この役割のデフォルト・ポリシーです。
CosNamingWrite
ユーザーは、JNDI バインド、再バインド、またはアンバインド、および CosNamingRead 操作といった書き込み操作を実行できます。デフォルト・ポリシーとして、対象にはこの役割が割り当てられていません。
CosNamingCreate
ユーザーは、JNDI の createSubcontext 操作および CosNamingWrite 操作などによって、 ネーム・スペース内に新規オブジェクトを作成することができます。デフォルト・ポリシーとして、対象にはこの役割が割り当てられていません。
CosNamingDelete
ユーザーは、例えば、JNDI の destroySubcontext メソッドおよび CosNamingCreate 操作を使用して、ネーム・スペース内のオブジェクトを破棄することができます。 デフォルト・ポリシーとして、対象にはこの役割が割り当てられていません。

Server という特別な対象は、デフォルトで 4 つの CosNaming 役割すべてに割り当てられています。Server という特別な対象を使用すると、サーバー ID で実行する WebSphere Application Server プロセスは、 すべての CosNaming 操作にアクセスできます。 Server という特別な対象は表示されず、管理コンソールでもその他の管理ツールでも変更することができません。

サーバー ID は自動的に管理者役割にマップされるので、 管理セキュリティー を管理に使用するために使用可能にするとき、 指定されたサーバー ID を使用可能にするための特別の構成は必要ありません。

ユーザー、グループ、または特別な対象の AllAuthenticated および Everyone は、 いつでも、WebSphere Application Server の管理コンソールから、ネーミング役割に追加したり、 ネーミング役割から除去したりすることができます。 ただし、変更を有効にするには、サーバーの再始動が必要です。

ベスト・プラクティスは、特定のユーザーではなくグループまたは特別な対象の 1 つを、 ネーミング役割にマップすることです。 これは結局、グループや特別な対象を管理する方が柔軟性があり、 容易であるためです。 グループをネーミング役割にマップすることにより、 ユーザーのグループへの追加またはグループからの除去が WebSphere Application Server の外側で行われ、 変更を有効にするのにサーバーを再始動する必要がなくなります。

CosNaming 許可ポリシーは、管理セキュリティー が使用可能になっている場合にのみ実行されます。 管理セキュリティー が使用可能であるときに、 適切な役割の割り当てをしないで、CosNaming 操作を実行しようとすると、 CosNaming サーバーから org.omg.CORBA.NO_PERMISSION 例外が出されます。

個々の CosNaming 機能は、 1 つの役割にのみ割り当てられます。したがって、CosNamingCreate 役割を割り当てられたユーザーは、 CosNamingRead も割り当てられていない限り、ネーム・スペースを照会することはできません。 ほとんどの場合、 作成者には 3 つの役割、CosNamingRead、CosNamingWrite、および CosNamingCreate を割り当てる必要があります。 作成者の例の CosNamingRead 役割および CosNamingWrite 役割の割り当ては、CosNamingCreate 役割に含まれています。 ほとんどの場合、WebSphere Application Server 管理者は、 前のリリースからこのリリースに移行するときに、 各ユーザーまたはグループの役割の割り当てを変更する必要はありません。

デフォルト・ポリシーを変更することによってネーム・スペースへのアクセスを大幅に制限することができますが、 実行時に予期しない org.omg.CORBA.NO_PERMISSION 例外が発生する可能性があります。 通常は、J2EE アプリケーションがネーム・スペースにアクセスし、 その際に使用される ID は、J2EE アプリケーションにアクセスするときに WebSphere Application Server で認証されたユーザーの ID と同じものです。 J2EE アプリケーション・プロバイダーが予期されたネーミング役割を明確に伝達しない場合は、 デフォルトのネーミング許可ポリシーの変更時に注意が必要です。




関連概念
許可テクノロジー
関連タスク
ネーミング役割へのユーザーの割り当て
レジストリーまたはリポジトリーの選択
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 5:05:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/csec_adminconsole.html