ランタイム・リソースのセキュリティー: アクセス制御リスト

変更の始まりアクセス制御リスト (ACL) 項目に基づいて、特定のランタイム・リソースへのユーザーのアクセスが許可または拒否されます。 ランタイム・リソースは、実行時にブローカー・ドメインに存在する WebSphere® Event Broker オブジェクトです。変更の終わり

変更の始まりランタイム・オブジェクトごとに、オブジェクトにアクセスできるユーザーとグループを判別するための ACL があります。 ACL 項目を使用することによって、ブローカー・ドメイン内の特定のオブジェクトに対するユーザーのアクセスを制御すること、 およびユーザーまたはグループにオブジェクトを表示、変更、またはデプロイすることを許可できます。 ワークベンチ、Java 構成マネージャー・プロキシー API、 または mqsicreateaclentrymqsideleteaclentry、 および mqsilistaclentry コマンドを使用して、 ACL 項目を取り扱うことができます。変更の終わり

変更の始まり例えば、USER1 は BROKERA を変更するためにアクセスすることはできても、BROKERB へのアクセス権限がないかもしれません。さらに別の例として、どちらのグループも BROKERA のメンバーであるのに、同じユーザーが実行グループ EXEGRP1 のデプロイのためにアクセスすることができても、EXEGRP2 にはアクセスできないということがあります。変更の終わり

許可が必要なオブジェクトを表示または変更しようとすると、以下の情報が構成マネージャーに渡されます。

変更の始まり構成マネージャーは ACL 表を検査します。ユーザー ID が名前付きオブジェクトの ACL 項目に含まれているユーザーは、操作を実行する権限があります。変更の終わり

ユーザーまたはグループに付与できる 4 つの異なるアクセス・レベルがあります。すなわち、フル・コントロール表示デプロイ、および編集です。すべてのオブジェクト・タイプに対して必ずしもすべてのアクセス・レベルが有効だとは限りません。各オブジェクト・タイプに適用できる許可のリストと、ユーザーまたはグループが実行できる操作の要約については、ACL 許可を参照してください。

ACL 項目にはユーザー名が含まれ、ホスト名またはドメイン名も指定することができます。 例えば、ユーザーは、権限のある Windows ドメイン名と同じホスト名を持つコンピューターにアカウントを作成することにより、オブジェクトにアクセスできるようになります。 ACL 項目を使用してブローカー・ドメイン内のオブジェクトへのアクセスを制御できますが、ブローカー・ドメインの保護に関しては ACL 項目を頼りにしないでください。ブローカー・ドメイン内のコンポーネント間のチャネルの保護には、SSL またはセキュリティー出口を使用します。 ACL 項目はユーザー ID に基づいてオブジェクトに対するユーザーのアクセスを許可または拒否しますが、 ACL 項目はユーザーの同一性を検証できないので、オブジェクトを保護することはありません。

ブローカー管理者が作成しなければならない ACL 項目の数を削減するために、ACL 許可は階層に従って機能します。 ツリーのルートは ConfigManangerProxy オブジェクトで、これには RootTopic、Subscriptions、および PubSubTopology という 3 つの子があります。PubSubTopology オブジェクトは子としてゼロ個以上のブローカーを持ち、それぞれのブローカーは子としてゼロ個以上の実行グループを持ちます。あるオブジェクトに ACL 項目を追加すると、許可はそのオブジェクト自体に付与されるとともに、別の ACL 項目によって指定変更されないかぎり、階層内でそのオブジェクトの下に位置するすべてのオブジェクトにも付与されます。次に示す図は、 アクセス制御リスト項目の階層の例です。

この図は階層例を示します。ルートは CMP で、これには RootTopic、Subscriptions、および PubSubTopology という 3 つの子があります。PubSubTopology には 2 つの子、Broker1 および Broker2 があります。それぞれのブローカーには 2 つの子、Eg1A および Eg1B があります。

変更の始まりこの階層が実際にどのよう機能するかを示す例については、 ドメイン・コンポーネントのセキュリティーの構成を参照してください。変更の終わり

オブジェクトのアクセス制御項目を変更するには、ユーザーにはそのオブジェクト、または階層の親に対する「フル」権限がなければなりません。これはつまり、ACL 自体を変更する許可は上記と同様に作動するものの、例外として、ツリーのより下の部分に対してより下位の許可を付与しても ACL へのアクセスは除去できないということです。これは必要な事柄です。というのは、さもないと、ユーザーが自分自身に対して「表示」項目を付与した後でそれを除去できなくなってしまうからです。

z/OS® 上では、構成マネージャーが外部セキュリティー・マネージャー (ESM) データベースからユーザー ID とグループの情報を取得できるようにするために、ユーザー ID とグループの OMVS セグメントを定義する必要があります。

ACL 項目とグループ

以前のバージョンの WebSphere Event Broker では、ランタイム・オブジェクトへのアクセスは、グループのセットを定義してユーザーをグループに割り当てることによって制御していました。ACL 項目による制御では、グループよりも細かくアクセスを制御できます。また、ACL 項目による制御では、各ブローカーへのユーザーのアクセスを別々に構成することにより、開発システム、テスト・システム、実動システムを単一の構成マネージャーで管理できます。グループを使用した場合は、開発システム、テスト・システム、実動システムを別々のブローカー・ドメインに配置し、各ドメインを別々の構成マネージャーで制御する必要があります。

以前のバージョンの WebSphere Event Broker から構成マネージャーをマイグレーションする場合、以下のグループの ACL 項目が自動的に定義されます。
  • mqbrkrs
  • mqbrops
  • mqbrdevt
  • mqbrasgn
  • mqbrtpic
これらの ACL 項目がないと、これらのグループに属するユーザーには、ドメイン内のオブジェクトに対して操作を実行する権限がありません。

単一ユーザー ACL を使用する場合、オブジェクトにアクセスしているワークステーション (つまり Toolkit が実行しているマシン) でユーザーを定義しなければなりませんが、構成マネージャーを実行しているワークステーションではこれらを定義する必要はありません。 しかし、グループ ACL を使用している場合、ユーザーを両方のワークステーションに定義する必要があり、それから、ユーザーをグループに追加する前に、構成マネージャーを実行しているワークステーションにグループを定義する必要があります。 これは、ワークステーション間でグループ情報が渡されないために必要になります。

関連概念
セキュリティーの概要
ユーザー ID 情報を取得するための z/OS 上の構成マネージャーの使用可能化
トピック・ベースのセキュリティー
関連タスク
ドメイン・コンポーネントのセキュリティーの構成
ブローカー・ドメインのセキュリティーのセットアップ
トピック・ベースのセキュリティーの使用可能化
進行中のデプロイメントのキャンセル
関連資料
管理用タスクでのセキュリティーの要件
mqsicreateaclentry コマンド
mqsideleteaclentry コマンド
mqsilistaclentry コマンド
ACL 許可
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. All Rights Reserved.
最終更新 : 2009-02-13 10:23:38

ap01380_