管理ロールとネーミング・サービスの許可

WebSphere® Application Server では、Java™ Platform, Enterprise Edition (Java EE) セキュリティー・ロール・ベースのアクセス制御を拡張して、製品の管理とネーミングのサブシステムを保護します。

管理ロール

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

表 1. 管理コンソールおよび wsadmin から使用可能な管理ロール.

以下の表には、管理コンソールおよび wsadmin から使用可能な管理ロールがリストされています。

ロール 説明
モニター モニター・ロールを使用する個々のユーザーまたはグループの持つ特権は最少となります。モニターは、 以下のタスクを実行できます。
  • WebSphere Application Server の構成を表示します。
  • Application Server の現在の状態を表示します。
コンフィギュレーター コンフィギュレーター・ロールを使用する個々のユーザーまたはグループは、モニター特権に加え、WebSphere Application Server 構成を変更できる権限を持ちます。 コンフィギュレーターは日常的な構成タスクをすべて行うことができます。例えば、コンフィギュレーターは、以下のタスクを実行できます。
  • リソースを作成します。
  • アプリケーション・サーバーをマップします。
  • アプリケーションをインストールおよびアンインストールします。
  • アプリケーションをデプロイします。
  • アプリケーションに、ユーザーおよびグループからロールへのマッピングを割り当てます。
  • アプリケーションの Java 2 セキュリティー権限をセットアップします。
  • Common Secure Interoperability バージョン 2 (CSIv2)、Secure 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) のパスワード変更、および鍵の生成を行います。
  • 統合リポジトリー構成のユーザーを作成、更新、または削除します。
  • 統合リポジトリー構成のグループを作成、更新、または削除します。
注:

管理者は、ユーザーおよびグループを管理者のロールにマップできません。

WebSphere Application Server 管理者ロールを割り当てられていないユーザーに統合リポジトリー管理権限を割り当てる方法については、 トピック「セキュリティーの提供 (Providing security)」内のトピック「統合リポジトリー管理権限を割り当てるためのユーザーおよびグループのロールへのマップ (Mapping users and groups to roles for assigning federated repository management rights)」を参照してください。

Adminsecuritymanager このロールを付与されたユーザーのみが管理ロールにユーザーをマップすることができます。 また、非常に詳細な管理セキュリティーが使用されている場合、このロールを付与されたユーザーのみが、許可グループを管理することができます。 詳しくは、管理ロールを参照してください。
デプロイヤー このロールを付与されたユーザーは、 アプリケーションで、構成操作および実行時の操作の両方を実行できます。
監査員 このロールを付与されたユーザーは、セキュリティー監査サブシステムの構成設定を表示および変更できます。 例えば、監査員のロールを持つユーザーは、以下のタスクを実行できます。
  • セキュリティー監査サブシステムを使用可能および使用不可にします。
  • イベント・ファクトリーのプラグイン・ポイントで使用するイベント・ファクトリーの実装を選択します。
  • サービス・プロバイダーのプラグイン・ポイントで使用するサービス・プロバイダーまたはエミッター、あるいはその両方を選択し、構成します。
  • セキュリティー監査サブシステムでエラーが発生した場合のアプリケーション・サーバーの動作を記述する監査ポリシーを設定します。
  • 監査対象のセキュリティー・イベントを定義します。
監査員のロールは、モニターのロールを含みます。このため、監査員は残りのセキュリティー構成を表示できますが、変更することはできません。
表 2. 管理コンソールを使用して使用可能な追加の管理ロール.

次の表では、管理コンソールを介して使用可能な追加の管理ロールを示します。

ロール 説明
iscadmins このロールは、管理コンソールのユーザーのみ使用可能です。 wsadmin ユーザーは使用できません。 このロールを付与されたユーザーは、統合リポジトリー内でユーザーおよびグループを管理するための管 理者特権を持ちます。 例えば、iscadmins のロールのユーザーは、以下のタスクを実行できます。
  • 統合リポジトリー構成のユーザーを作成、更新、または削除します。
  • 統合リポジトリー構成のグループを作成、更新、または削除します。
表 3. wsadmin で使用可能な追加の管理ロール.

次の表では、管理コンソールを介して使用可能な追加の管理ロールを示します。

ロール 説明
デプロイヤー このロールは、wsadmin ユーザーのみ使用可能です。 管理コンソールのユーザーは使用できません。 このロールを付与されたユーザーは、 アプリケーションで、構成操作および実行時の操作の両方を実行できます。

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

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

[z/OS]WebSphere Application Server for z/OS® セキュリティー・カスタマイズ・ダイアログは、管理サブシステムが、すべての始動済み WebSphere Application Server システム・タスク (例えば、コントローラー、サーバントなど) の MVS™ ID を WebSphere 管理者および構成済み管理者 ID として受け入れるために事前準備をします。統合リポジトリー、 スタンドアロン Lightweight Directory Access Protocol (LDAP) レジストリー、 またはスタンドアロン・カスタム・レジストリーが指定されている場合、 開始済みタスク ID によって実行される作業ではなく、 システムによって実行される作業に、構成されたサーバー ID を使用します。

[z/OS] com.ibm.security.SAF.authorization 設定の値により、管理プロファイルへのアクセスを制御するため、コンソール・ユーザーではなく、SAF EJBROLE プロファイルまたはコンソール設定を使用するかどうかが制御されます。プロパティー com.ibm.security.SAF.authorizationtrue に設定すると、SAF 許可が選択され、SAF EJBROLE プロファイルが使用されて、管理ロールへのアクセスが制御されます。
注: System Authorization Facility (SAF) 許可の場合は、 コンソール・ユーザーおよびコンソール・グループのすべての値が無視されます。
[z/OS] WebSphere Application Server 許可 (SAF 許可ではなく) を使用して、Java Platform, Enterprise Edition (Java EE) ロールへのアクセスを制限すると、WebSphere Application Server for z/OS は、管理セキュリティーを使用可能にする際に指定されたサーバー ID を、自動的に管理ロールにマップします。管理セキュリティーが使用可能である場合、WebSphere Application Servers for z/OS は、アクティブ・ユーザー・レジストリー構成下で定義されたサーバー ID で稼働します。 管理コンソールやその他のツールに表示されない場合でも、 特別な対象 Server は管理者ロールにマップされます。
  • このサーバー ID で実行される WebSphere Application Server ランタイム・コードには、いくつかのランタイム操作に対する許可が必要です。 サーバー ID とパスワードを明示的に入力することもできますが、 ID は自動生成することもできます。 前者の場合、サーバー ID はレジストリー内の正当なユーザーです。 後者の場合は、internalServerId 機能を使用して、サーバー ID を自動的に生成します。 各ユーザー・レジストリーの構成パネルを使用すると、この選択が可能です。 internalServerId の場合は、 管理者 ID または adminID を「1 次管理ユーザー名」フィールドに入力します。 この adminID は、レジストリー内の正当なユーザーです。 この ID のパスワードは不要で、構成には保存されません。 以下のセクションの『内部サーバー ID』を参照してください。
  • 明示的なユーザーまたはグループが管理ロールに割り当てられていない場合 、internalServerId 機能の使用時、サーバー ID または adminID を使用して、管理コンソールまたは wsadmin スクリプト・ツールにログインすれば、管理操作を実行し、他のユーザーやグループを管理ロールに割り当てることができます。 サーバー ID (または adminID) が adminsecuritymanager ロールに自動的に割り当てられるため、これは可能で す。 すべての管理ロールに対してユーザー/グループを管理できるのは、 adminsecuritymanager に関連したユーザー/グループだけです。 サーバー ID (または adminID) を使用してログインすれば、 管理セキュリティー・ポリシーを使用して、以下のような操作を実行できるようになります。
    • サーバー ID およびサーバー・パスワードを変更する
    • WebSphere Application Server 管理セキュリティー を使用可能または不可にする
    • Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションを使用して、Java 2 セキュリティーを実行します。
    • LTPA パスワードを変更する、または鍵を生成する
  • サーバー ID は自動的に管理者ロールにマップされるので、 管理セキュリティー を管理使用するために使用可能にするとき、 指定されたように、サーバー ID を使用可能にするために特別の構成は必要ありません。 WebSphere Application Server の管理コンソールを使用して、ユーザーやグループを管理ロールに追加したり、管理ロールから除去したりできます。ただし、変更内容を有効にするには、サーバーを再始動する必要があります。ベスト・プラクティスは、 特定のユーザーではなくグループを、管理ロールにマップすることです。 この方法のほうが柔軟性があり、容易であるためです。 グループを管理ロールにマップすることにより、ユーザーのグループへの追加またはグループからの除去が WebSphere Application Server の外側で行われ、変更を有効にするのにサーバーを再始動する必要がなくなります。

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

[AIX Solaris HP-UX Linux Windows][IBM i]
  • サーバー ID およびサーバー・パスワードを変更する
  • WebSphere Application Server 管理セキュリティー を使用可能または不可にする
  • Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションを使用して、Java 2 セキュリティーを実行します。
  • LTPA パスワードを変更する、または鍵を生成する
  • ユーザーおよびグループを管理ロールに割り当てる
WebSphere Application Server のバージョン 6.1 のリリースおよびそれ以降のリリースでは、以下が必要です。
  • 管理アクションの監査能力を向上させるため、サーバー・ユーザー ID とは区別された管理ユーザー。ローカル・オペレーティング・システムで 定義される管理特権を持つユーザーを、 ユーザー名によって指定します。
  • サーバー ID と管理ユーザー ID とを区別して、監査能力を向上させます。サーバー・ユーザー ID は、サーバー間通信の認証に使用されます。
  • 内部サーバー ID を使用すると、 サーバー間認証用のユーザー ID を自動生成できるようになります。 サーバー ID の自動生成は、 バージョン 6.1 以降のノードの場合に限り、 セルに対する監査能力の向上をサポートします。 WebSphere Application Server のバージョン 6.1 リリースでは、内部生成されたサーバー ID を保存できます。 これは、Security WebSphere Common Configuration Model (WCCM) モデルに、新しいタグ internalServerId が組み込まれるためです。 混在しているセル環境以外では、セキュリティー設定中にサーバーのユーザー ID およびパスワードを指定する必要はありません。 内部生成のサーバー ID は、サーバー環境に、さらに上のレベルの保護を追加します。 これは、バージョン 6.1 より前のリリースのようにサーバー・パスワードが公開されることがないためです。 しかし、後方互換性を維持するために、以前のバージョンの WebSphere Application Server を使用する場合には、サーバー・ユーザー ID を指定する必要があります。

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

  • 特別な対象 を管理ロールにマップする機能。特別な対象とは、 特定クラスのユーザーを一般化したものです。特別な対象が AllAuthenticated または AllAuhenticatedInTrustedRealms (相互レルムが関係しているとき) である場合、管理ロールのアクセス検査によって、要求を出しているユーザーが少なくとも認証済みであることを意味します。 特別な対象が 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 操作を使用して、名前空間内のオブジェクトを破棄することができます。 デフォルト・ポリシーとして、対象にはこのロールが割り当てられていません。

[z/OS]WebSphere Application Server for z/OS を使用してローカル・オペレーティング・システム・レジストリーを構成する場合は、要因についてさらに検討する必要があります。 詳しくは、レジストリーまたはリポジトリーの選択およびローカル・オペレーティング・システムのレジストリーの構成を参照してください。統合リポジトリー、スタンドアロン LDAP レジストリー、またはスタンドアロン・カスタム・レジストリーを指定する場合は、コンソール・グループから事前定義済みの WebSphere Application Server 構成グループと管理者 ID を削除することによって、ローカル・オペレーティング・システムのカスタマイズを除去し、コンソール・ユーザーを削除する必要があります。

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

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

[AIX Solaris HP-UX Linux Windows][IBM i]ユーザー、グループ、または特別な対象の AllAuthenticated および Everyone は、WebSphere Application Server の管理コンソールを使用して、いつでもネーミング・ロールに追加したり、ネーミング・ロールから除去したりできます。ただし、変更を有効にするには、サーバーの再始動が必要です。

[z/OS]サーバー ID は自動的に管理者ロールにマップされるので、 管理セキュリティー を管理に使用するために使用可能にするとき、 サーバー ID (指定された) を使用可能にするための構成は必要ありません。 ユーザー、グループ、または特別な対象の AllAuthenticated および Everyone は、WebSphere Application Server の管理コンソールを使用して、いつでもネーミング・ロールに追加したり、ネーミング・ロールから除去したりできます。ただし、変更を有効にするには、サーバーの再始動が必要です。SAF 許可を選択する場合、 追加ユーザーまたはグループを許可するために、サーバーを再始動する必要はありません。

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

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

[AIX Solaris HP-UX Linux Windows][IBM i]個々の CosNaming 機能は、 1 つのロールにのみ割り当てられます。したがって、CosNamingCreate ロールを割り当てられたユーザーは、 CosNamingRead も割り当てられていない限り、名前空間を照会することはできません。 ほとんどの場合、 作成者には 3 つのロール、CosNamingRead、CosNamingWrite、および CosNamingCreate を割り当てる必要があります。 作成者の例の CosNamingRead ロールおよび CosNamingWrite ロールの割り当ては、CosNamingCreate ロールに含まれています。 ほとんどの場合、WebSphere Application Server 管理者は、前のリリースからこのリリースに移行するときに、各ユーザーまたはグループのロールの割り当てを変更する必要はありません。

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


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_adminconsole
ファイル名:csec_adminconsole.html