WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

System Authorization Facility のクラスおよびプロファイル

Resource Access Control Facility (RACF) または System Authorization Facility (SAF) を使用する場合は、以下の点を考慮に入れる必要があります。
  1. エンタープライズ Bean と Web アプリケーションの 役割およびサーブレットの使用
  2. RACF クラス・プロファイルの使用
    1. CBIND を使用した、サーバーおよびサーバー内のオブジェクトへのアクセス
    2. SERVER を使用した、サーバント領域を使用するコントローラーへのアクセス
    3. STARTED を使用した、ユーザー ID およびグループと開始済みプロシージャーの関連付け
    4. FACILITY を使用した、Synch to OS Thread Allowed を使用可能にする許可の設定
    5. SURROGAT を使用した、Synch to OS Thread Allowed を使用可能にする許可のオプション での設定
  3. シスプレックス内での複数のセキュリティー構成の作成
  4. 新規サーバーの新規ユーザー ID およびプロファイルの生成
  5. Minimalist プロファイルの使用

Enterprise JavaBeans と Web アプリケーションの役割およびサーブレット

役割は、Java 2 platform Enterprise Edition (J2EE) アプリケーションに関連付けられています。アプリケーション内のモジュールは、 アプリケーション役割を指す役割参照を使用して、役割を参照します。 Web アプリケーション、サーブレット、または EJB メソッドへのアクセスは、ユーザーまたは呼び出し元を基にしています。 役割は、アセンブル時に Web アプリケーション、およびサーブレットまたはエンタープライズ Bean に関連付けられています。 サーブレットまたは EJB メソッドを使用する必要がある役割は、アプリケーションのデプロイメント記述子で指定されます。

どのユーザーおよびグループがどの役割を持つかは、EJBROLE クラス内の RACF プロファイルを使用して 決定されます (SAF 許可が選択されている場合)。ユーザーが EJBROLE プロファイルのアクセス・リスト内にある場合、ユーザーはその役割を持ちます。グループが EJBROLE プロファイルのアクセス・リスト内にある場合、そのグループ内のユーザーはその役割を持ちます。 EJBROLE プロファイルが ACCESS(READ) を持つ場合、すべてのユーザーがその役割を持ちます。

セキュリティー・ドメインが指定されている場合、このセキュリティー・ドメインは、EJBROLE プロファイルを検査する際に、 WebSphere Application Server for z/OS および RACF が使用するプレフィックスになります。これは、セル・レベルの役割の 細分性を提供します。これを実現するために、アプリケーションで役割を変更する必要はありません。

以下に例を示します。
Test Cell has Security Domain=TEST Production Cell has Security Domain=PROD

例えば、役割 Clerk を使用するアプリケーションは両方のセルでデプロイされます。 テスト・セルでは、ユーザーは EJBROLE プロファイル TEST.Clerk への READ アクセスが必要です。 実動セルでは、ユーザーは EJBROLE プロファイル PROD.Clerk への READ アクセスが必要です。

管理許可用の RACF EJBROLE クラスで定義されるプロファイルは 6 つあります。 管理者、コンフィギュレーター、モニター、オペレーター、デプロイヤー、および adminsecuritymanager です。役割マッピング用に RACF を使用する場合、ユーザーに与える管理権限に応じて、 これらのプロファイルのいずれかに対して、RACF ユーザー ID またはグループ READ アクセスを定義する必要があります。

J2EE ベースの役割許可における SAF の使用方法について詳しくは、役割ベースの許可の System Authorization Facility を参照してください。

RACF プロファイルの使用

RACF (あるいは同等のセキュリティー製品) で CBIND、SERVER、お よび STARTED クラスによるサーバー・リソースの保護に使用される、セキュリティー・メカニズムについて理解しておく ことは重要です。 セキュリティー環境を管理する手法を知っておく必要があります。

WebSphere Application Server for z/OS リソースを保護する RACF プロファイルは、 以下のクラスを使用します。
  1. CBIND: サーバーへのアクセスと、そのサーバー内のオブジェクトへのアクセスには、このクラスを使用します。
  2. SERVER: サーバント領域によるコントローラーへのアクセスには、このクラスを使用します。
  3. STARTED: ユーザー ID とグループを開始済みプロシージャーへ関連づけるには、このクラスを使用します。
  4. FACILITY: ユーザー ID とグループを、Synch to OS Thread Allowed オプションに関連付けるには、このクラスを使用します。
  5. SURROGAT: ユーザー ID とグループを、Synch to OS Thread Allowed オプションに関連付けるには、このオプション・クラスを使用します。
詳しくは、System Authorization Facility (SAF) のオペレーティング・システムおよびアプリケーション・レベルに関する考慮事項 を参照してください。

WebSphere Application Server for z/OS で使用される RACF プロファイルの基本的な情報は、SAF ベースの許可に記載されています。このセクションでは、CBIND、SERVER、FACILITY、SURROGAT、および STARTED クラスのプロファイルに関する追加情報について述べます。

ユーザー ID およびグループ ID

BBOCBRAJ ジョブは、WebSphere Application Server for z/OS カスタマイズ・ダイアログの一部として RACF コマンドを生成し、そのコマンドによって BBOWBRAK ジョブが実行できます。 以下の情報を入力します。
CR = コントローラー領域 SR = サーバント領域 CFG = 構成 (グループ) server = サーバーのショー
ト・ネー
ム cluster = 汎用サーバーの (ショート) ネーム (クラスター遷移名ともいう) 
次のように、6 人のユーザーと 6 つのグループを定義します。ここでは、そのユーザーとグループが 後にさまざまな許可でどのように使用されるかをわかりやすくするために、ユーザーとグループを記号で表します。
<CR_userid> <CR_groupid>, <CFG_groupid> <SR_userid> <SR_groupid>, <CFG_groupid> <demn_userid> <demn_groupid>, <CFG_groupid> <admin_userid> <CFG_groupid> <client_userid> <client_groupid> <ctracewtr_userid> <ctracewtr_groupid> 

WebSphere Application Server for z/OS のリソースを保護するために、許可やアクセス・レベルとあわせて使用される各種のプロファイルは次のとおりです。

CBIND クラス・プロファイルの使用

CBIND クラス・プロファイルは、アプリケーション・サーバーとそのサーバー内のオブジェクトへのアクセスを保護す るためのもので、次の 2 つのフォーマットとレベルがあります。
CBIND クラス・プロファイル - 汎用サーバーへのアクセス CB.BIND.<cluster>
UACC(READ); PERMIT <CR_group> ACC(CONTROL)  CBIND Class profiles - access
to objects in servers CB.<cluster> UACC(READ) PERMIT <CR_group> ACC(CONTROL) 
「セキュリティー・ドメイン ID」を使用している場合、CBIND プロファイルは、次のように 「domainId」で修飾されます。
CBIND Class profiles - access to generic
servers  CB.BIND.<domainId>.<cluster> 	UACC(READ)   CBIND Class profiles
- access to objects in servers CB.<domainId>.<cluster> 	UACC(READ) 
CBIND プロファイルは、Java アプリケーション・クライアントおよびその他の WebSphere Application Server サーバーから、 WebSphere Application Server プラグインを実行する Web サーバーを含む WebSphere Application Server for z/OS サーバー、 およびそのサーバー内のオブジェクトへのアクセスを制御します。サーバーへアクセスするには、以下を入力します。
CB.CBIND.<cluster>
CB.CBIND.<security domain>.<cluster>
サーバー内のオブジェクトへアクセスするには、以下を入力します。
CB.<cluster> CB.<security domain>.<cluster> 

SERVER クラス・プロファイルの使用

SERVER クラス・プロファイルは、サーバー・コントローラーへのアクセスを保護するためのもので、現時点では 2 つ のフォーマットがあります。
SERVER
class profiles – access to controllers using static Application Environments
 CB.<server>.<cluster>   	UACC(NONE) PERMIT <SR_userid> ACC(READ)
             SERVER class profiles – access to controllers using dynamic Application
Environments  CB.<server>.<cluster>.<cell> 	UACC(NONE) PERMIT <SR_userid>
ACC(READ)
カスタマイズ・ダイアログでは、両方のフォーマットが事前定義されていますが、実行時に実際必要になるのは、そのうちの 1 つです。 必要なフォーマットは、WebSphere Application Server for z/OS Runtime が 、Dynamic Application Environment (DAE) サポートの可用性に基づいて、動的に決定します。以下のコマンドは、 静的アプリケーション環境を使用したコントローラーへのアクセスを提供します。
RDEFINE
CB.&<server<cluster> UACC(NONE); PERMIT &<SR_userid> ACCESS(READ) 
この例で、server = サーバー名、cluster = クラスター名またはクラスター遷移名 (クラスターがまだ作成されていない場合)、SR はサーバー領域の MVS ユーザー ID です。
以下のコマンドは、動的アプリケーションを使用したコントローラーへのアクセスを提供します。
CB.& <server>.&<cluster>.<cell> UACC(NONE); PERMIT &<SR_userid> ACC(READ) 
この例で、server = サーバー名、cluster = クラスター名またはクラスター遷移名 (クラスターがまだ作成されていない場合)、cell = セルのショート・ネーム、 および SR はサーバー領域の MVS ユーザー ID です。

SERVER クラス・プロファイルは、サーバントが関連コントローラーで権限ルーチンを呼び出すことができるかどうかを 制御します。

静的アプリケーション環境を使用するコントローラーへアクセスするには、以下を入力します。
CB.<server>.<cluster>
CB.<security domain>.<server>.<cluster>
動的アプリケーション環境を使用するコントローラーへアクセスするには、以下を入力します。
CB.<server>.<cluster>.<cell>
22

STARTED クラス・プロファイルの使用

ユーザー ID およびグループ ID をコントローラーに割り当てるために使用する STARTED クラス・プロファイルには 3 つのフォーマットがあります。
STARTED クラス・プロファイル - (MGCRE) <<CR_proc>.<CR_jobname>
STDATA(USER(CR_userid) GROUP(CFG_groupid)) <demn_proc>.* STDATA(USER(demn_userid)
GROUP(CFG_groupid))  STARTED クラス・プロファイル - (ASCRE) <SR_jobname>.<SR_jobname>
STDATA(USER(SR_userid) GROUP(CFG_groupid))  IJP 用 STARTED クラス・プロファイル
- (MGCRE) <MQ_ssname>.* STDATA(USER(IJP_userid) GROUP(CFG_groupid)) 
STARTED クラス・プロファイルは、ユーザー ID をさまざまな WebSphere Application Server for z/OS 領域に割り当てるために生成されます。次のような領域があります。

APPL クラス・プロファイルは、認証済みユーザーがセル内で任意のアプリケーションを使用できるかどうかを制御します。 セキュリティー・ドメインが指定されている場合、APPL クラス・プロファイル名はセキュリティー・ドメイン名です。 セキュリティー・ドメインが指定されていない場合、 APPL クラス・プロファイル名は CBS390 です。詳しくは、System Authorization Facility (SAF) のオペレーティング・システムおよびアプリケーション・レベルに関する考慮事項 を参照してください。

シスプレックス内での複数のセキュリティー構成の作成

企業内で論理的 WebSphere Application Server for z/OS セキュリティー・ドメインを 分離するために、指定された RACF データベース内にプロファイルの明確なセットが必要となる場合があります (例えば、テストおよび実動ユーザー)。

ISPF ダイアログ・パネルを使用したカスタマイズ (「セキュリティー・ドメイン構成」) 中、または管理コンソールの 「グローバル・セキュリティー」プロパティー・パネルでセキュリティー・ドメイン ID を定義することができます (security.zOS.domainName, security.zOS.domainType)。「ISPF Security Domain Configuration」パネルで、以下のように入力します。
Use Security
Domain Identifier in RACF Definitions:  <Y/N>     Security Domain Identifier....................:
 <domainId> 

WebSphere Application Server for z/OS 管理コンソールを使用して、「セキュリティー」>「管理、アプ リケーション、インフラストラクチャーの保護」>「カ スタム・プロパティー 」の下で、これらの変数を設定します。これにより、セルのディレクトリー内の security.xml ファイルに以下のプロパティーが作成されます。

xmi:id="Property_47" name="security.zOS.domainType"
value="cellQualified"  required="false"/> xmi:id="Property_48" name="security.zOS.domainName"
value="<domain_name>" required="false"/> 

これにより、サーバーのディレクトリー内の was.env ファイルに以下の変数が作成されます。security_zOS_domainName=<domain_name> security_zOS_domainType=1

セキュリティー・ドメイン ID が設定されており、「Use security domain flag」が指定されている場合、セキュリティー・ドメイン ID を使用すると、 以下のプロファイル定義および検査は影響を受けます。
 Class
   	domainType=None  		 domainType=cellQualified  CBIND 	    CB.clustername
       CB.domainId.clustername            CB.BIND.clustername   CB.BIND.domainId.clustername
 APPL       CBS390            	  domainId EJBROLE	  ApplicationRoleName 	
 domainId.ApplicationRoleName 

新規サーバーの新規ユーザー ID およびプロファイルの生成

新規のアプリケーション・サーバーごとに固有のユーザー ID を使用する場合は、これらのユーザー、グループ、およびプロファイルを RACF データベースで定義する必要があります。

ISPF カスタマイズ・ダイアログのターゲット .DATA 区分データ・セットの BBOWBRAK メンバーのコピーを編集して、以下のエントリーを新規のユーザー、 グループ、および固有の New_server 名、および New_cluster 名のプロファイルに変更します。

FACILITY および SURROGAT クラス・プロファイルの使用 (OS スレッド許可オプションとの同期)

FACILITY および SURROGAT クラス・プロファイルは RACF 管理者に、Synch to OS Thread Allowed の使用に対する制御を与えます。
重要: これらのプロファイルが RACF で定義されていない場合、スレッドへの同期は許可されません。
FACILITY および SURROGAT クラス・プロファイルのフォーマットと使用法は、以下のとおりです。
BBO.SYNC.<cell
short name>.<cluster short name> RDEF FACILITY BBO.SYNC.<cell short
name or security domain prefix>.<cluster short name> UACC NONE PE BBO.SYNC.<cell
short name or security domain prefix>.<cluster short name> CLASS(FACILITY)
ID<CR userid> ACC(READ or CONTROL)  RDEF SURROGAT BBO.SYNC.<SR userid>
UACC NONE PE BBO.SYNC.<SR userid> CLASS(SURROGAT) ID(application userid)
ACC(READ)
注: クラスタリングが定義されていない場合、クラスターのショート・ネームはサーバー汎用ショート・ネームです。 また、アクセス検査のパフォーマンスを改善するには、SURROGAT クラス・プロファイルを (RACLIST されている) メモリー・テーブルに置く必要があります。
<CR userid>CONTROL アクセス権が与えられていた場合、Synch to OS Thread Allowed を要求する個々のユーザー ID は同期をとることができます。 <CR userid>READ アクセス権が与えられた場合、Synch to OS Thread Allowed を要求するすべての個々のユーザー ID も、アプリケーション・ユーザー ID に対してサーバント領域 (SR) における Synch to OS Thread Allowed への明示的な許可を与える SURROGAT クラス・プロファイルへの READ アクセス権が必要です。例えば、セル・ショート・ネームが SY1、クラスター・ショート・ ネーム (サーバーの汎用ショート・ネーム) が BBOC001、CR userid が CBSYMCR、 SR userid が CBSYMSR であるシステムで、アプリケーションが APPUSER のユーザー ID で実 行されていると仮定します。Synch to OS Thread Allowed 制御を確立するには、 次のコマンドを使用します。
RDEF FACILITY BBO.SYNC.SY1.BBOC001 UACC NONE PE BBO.SYNC.SY1.BBOC001
CLASS(FACILITY) ID(CBSYMCR) ACC(READ) RDEF SURROGAT BBO.SYNC.APPUSER UACC
NONE PE BBO.SYNC.APPUSER CLASS(SURROGAT) ID(CBSYMSR) ACC(READ)

FACILITY クラス・プロファイルの使用 (信頼されたアプリケーションの使用可能化 )

FACILITY クラス・プロファイルは、RACF 管理者に、信頼されたアプリケーションの使用 可能化を制御します。 信頼されたアプリケーションを使用可能にするには、使用可能化を管理コンソールで実行することが必要な だけではなく、次の FACILITY クラス・プロファイルを定義して、コントローラー領域ユーザー ID にそのプロファイル に対する READ アクセス権を与える必要があります。
RDEF FACILITY BBO.TRUSTEDAPPS.<cell
short name or security domain prefix>.<cluster short name> UACC NONE PE
BBO.TRUSTEDAPPS.<cell short name or security domain prefix>.<cluster
short name> CLASS(FACILITY) ID(CR userid) ACC(READ)
以下の凡例は、すべてのサーバーのユーザーが対象となります。
RDEFINE FACILITY BBO.TRUSTEDAPPS.mycell01.**UACC(NONE)
PERMIT BBO.TRUSTEDAPPS.mycell01.**  CLASS(FACILITY) ID(MYCBGROUP) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
次の例は、特定のユーザーが対象となります。 具体的には、システムのセルのショート・ネームが SY1、 クラスターのショート・ネーム (サーバーの汎用ショート・ネーム) が BBOC001、 およびコントローラー領域のユーザー ID が CBSYMCR の場合です。
RDEF FACILITY BBO.TRUSTEDAPPS.SY1.BBOC001 UACC
NONE PE BBO.TRUSTEDAPPS.SY1.BBOC001 CLASS(FACILITY) ID(CBSYMCR) ACC(READ)

Minimalist プロファイルの使用

RACF データ・セットでユーザー、グループ、およびプロファイルの数を最小限にとどめるために、1 つのユーザー ID と 1 つのグループ ID、および汎用性の高いプロファイルを使用して、同一セル内の複数のサーバーに対応できるようにするものです。 この手法は、統合 JMS プロバイダーおよび Network Deployment の構成でも使用できます。

Minimalist プロファイルを使用する利点は、以下が少ないことです。 欠点は、アプリケーションをより詳しくモニターする必要があることです。 これは、複数のサーバーが同一のユーザー ID またはグループで実行する場合、 1 つのサーバー内でアプリケーションが問題を発生し、独自のサーバーの構成を破壊してしまったり (例えば、セキュリティーをオフにする)、他のサーバーの構成を破壊したりする可能性があるためです。



関連資料
制御の要約
概念トピック    

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

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/csec_safclasses.html