トピック・ベースのセキュリティー

トピック・ベースのセキュリティーを使用して、パブリッシュ/サブスクライブ・システム内のどのアプリケーションが どのトピックの情報にアクセスできるかを制御してください。

アクセスを制限したいそれぞれのトピックごとに、どのプリンシパル (ユーザー ID およびユーザー ID のグループ) が パブリッシュでき、どのプリンシパルがサブスクライブすることができるかを指定することができます。 また、どのプリンシパルがメッセージの永続的な送達を要求することができるかをも指定できます。

アクセスを明示的に制限しないトピックは、すべてのプリンシパルがパブリッシュ、 サブスクライブすることができ、 そのトピックのメッセージの永続的な送達を要求することができます。

トピック・ベースのセキュリティーは、ユーザー・ネーム・サーバーによって管理され、 これはどの許可を適用するかを決定するために作成する アクセス制御リスト (ACL) を使用します。

プリンシパルおよびユーザー・ネーム・サーバー

WebSphere Business Integration Message Brokerユーザー・ネーム・サーバーは、 ブローカーおよび構成マネージャーのために、 パブリッシュ/サブスクライブで使用するため、 ネットワークですでに定義済みのプリンシパルのセットを管理します。 Windows では、ユーザーのこのリストは mqsicreateusernameserver コマンドで 指定されるドメインから取られます。

ユーザー・ネーム・サーバーは、mqsicreatebroker および mqsicreateconfigmgr コマンドでユーザー・ネーム・サーバー・キュー・マネージャーを指定することにより、ブローカーと構成マネージャーの両方に認識されるようになります。

ブローカー・ドメイン内のメッセージ・ブローカーは、ユーザー・ネーム・サーバーと対話して、 アクセス制御リストの構築元で、パブリッシュ/サブスクライブ要求が有効にされたユーザーとグループのすべてのセットを 検索します。構成マネージャーは、 ユーザー・ネーム・サーバーと対話して、 ワークベンチ「ブローカー管理 (Broker Administration)」パースペクティブでトピック階層エディターを使用して作成された ACL に含まれるユーザーおよびユーザー・グループを表示します。

アクセス制御リスト

アクセス制御リストは、すべてのトピックおよびプリンシパルに対して、あるトピックでパブリッシュしたり、 そのトピックにサブスクライブしたり、そのトピックでパブリケーションの永続的な送達を要求したりする あるプリンシパルの権限を定義するために使用されています。

また、各トピックに対して適用したいメッセージ保護のレベルを定義するために ACL を使用することもできます。

これらの定義は、ワークベンチ「ブローカー管理 (Broker Administration)」パースペクティブにある、トピック階層エディターを使用して指定します。

アクセス制御は、それぞれのトピックごとに明示的に設定することができます。 ただし、トピックに対して明示的 ACL が定義されていない場合には、 アクセス制御はトピック・ツリーの階層構造により定義される祖先または親トピックから継承されます。 トピック・ルートまでの階層のトピックに明示的な ACL がない場合、そのトピックはトピック・ルートの ACL を継承します。

ユーザー・ネーム・サーバーが認識する定義済みプリンシパルは、この方法でトピックと関連付けることができます。

ACL 対立の解決

ブローカー・ドメインのプリンシパルが複数のグループに 1 人以上のユーザーを含む場合、 明示または継承 ACL 値が対立することがあります。 次の規則は、対立の解決方法を示します。
  • ユーザーが、対象のトピックに明示ユーザー ACL を持つ場合、これが常に優先し、 ブローカーはそれを基本として現行の操作を検証します。
  • ユーザーが対象のトピックに明示ユーザー ACL を持たないが、トピック・ツリーに祖先に対する 明示ユーザー ACL がある場合、そのユーザーに最も近い祖先 ACL が優先し、ブローカーはそれを 基本として現行の操作を検証します。
  • 対象トピックまたはその祖先のユーザーに明示ユーザー ACL がない場合、ブローカーは グループ ACL を基本として現行の操作を検証しようとします。
    • ユーザーが対象トピック上に明示グループ ACL を持つグループのメンバーである場合、 ブローカーはそのグループ ACL を基本として現行の操作を検証します。
    • ユーザーは対象のトピックに明示グループ ACL を持つグループのメンバーではないが、 トピック・ツリーに祖先に対する明示グループ ACL を持つグループのメンバーである場合、 に最も近い祖先 ACL が優先し、ブローカーはそれを基本として現行の操作を検証します。
    • トピック・ツリーの特定のレベルで、ユーザー ID が明示 ACL を持つ複数のグループに入っている 場合、肯定の指定が 1 つでもあれば許可が与えられ、なければ拒否されます。

ACL を、1 つ以上のワイルドカードを含むトピックと関連付けることはできません。 しかし、サブスクリプション登録の作成時であれば、そのアプリケーションがトピック中で ワイルドカードを指定していても、クライアント・アプリケーションからのアクセスは正しく解決されます。

PublicGroup 権限

定義するグループに加えて、WebSphere Business Integration Message Broker はすべてのユーザーが自動的に所属する暗黙グループ、 PublicGroup を提供します。この暗黙グループは、トピック・ツリーの ACL の仕様を単純化します。 特に、このグループはトピック・ルートの ACL の仕様で使用されます。 トピック・ルートのデフォルト設定が、PublicGroup へのパブリッシュおよび サブスクライブ操作を許可することに注意してください。 ワークベンチを使用するこの ACL は、 表示したり変更したりすることはできますが、除去することはできません。 これはトピック・ツリー全体のデフォルト許可を決定します。 すべてのユーザーに許可を定義したい場合はどこでも、トピック・ツリー中の別の場所で PublicGroup に ACL を指定できます。

既存のセキュリティー環境で定義される Public という名前のプリンシパルがある場合、 これをトピック・ベースのセキュリティーに使用することはできません。 このプリンシパルを ACL 内で指定すると、PublicGroup と同じになるため、 常にグローバル・アクセスが許可されることになります。

mqbrkrs 権限

WebSphere Business Integration Message Broker は、 mqbrkrs グローバル・グループのメンバー、および適切であれば対応する Domain mqbrkrs に対して、 特殊なパブリッシュ/サブスクライブ・アクセス制御特権を付与します。

ブローカーは、アクセス制御があるネットワークで内部パブリッシュおよびサブスクライブ操作を 実行するために特殊権限を必要とします。 そのようなネットワークでブローカーを作成する場合、ブローカーのサービス・ユーザー ID として グループ mqbrkrs に所属するユーザー ID を指定することが必要です。 mqbrkrs グループは、そのメンバーがトピック・ルート ("") 上で メッセージの持続送達をパブリッシュ、サブスクライブ、および要求できるように指定された 暗黙の特権です。他のすべてのトピックはこれらの許可を継承します。 mqbrkrs グループの ACL をワークベンチを使って構成しようとすると、 この ACL は WebSphere Business Integration Message Broker に無視されます。

ACL およびシステム・トピック

内部パブリッシュおよびサブスクライブ操作に使用されるメッセージは、 ストリング $SYS および $ISYS で始まるシステム・トピックを使用して、 ブローカー・ドメイン全体でパブリッシュされます。これらのトピックは、mqbrkrs のメンバーによってのみパブリッシュ およびサブスクライブされるべきです。ただし、以下の 2 つのシナリオは例外です。
  1. トピックを MQSeries パブリッシュ/サブスクライブ からマイグレーションしている場合、 ストリング "$SYS/STREAM" で始まるトピックで ACL を構成できます。
  2. クライアントは、ストリング "$SYS" で始まるトピックに対してサブスクライブ できます。つまり、管理機能を提供するアプリケーションは、管理イベントのためにブローカーに サブスクライブできます。

ストリング "$ISYS" で始まるトピックでは ACL を構成しないでください。 この構成を実行しても無視されます。

トピックでのアクセス制御の設定

グループ mqbrtpic のすべてのメンバーは、どのプリンシパルがどのトピックで パブリッシュできるか、またどのトピックにサブスクライブできるかを定義する ACL を定義し、 操作することができます。 また、ACL はメッセージの永続的な送達を制限し、メッセージ保護のレベルを定義することもできます。 すべての定義済みプリンシパルはどのトピックとも関連付けることができます。 セットできる許可を次の表に示します。
オプション 説明
パブリッシュ このトピックのメッセージをパブリッシュするプリンシパルを与えるかまたは否認します。
サブスクライブ このトピックのメッセージにサブスクライブするプリンシパルを与えるかまたは否認します。
持続 プリンシパルがメッセージを持続的に受信することができるかどうかを指定します。 プリンシパルが許可されていない場合は、すべてのメッセージが非持続的に送信されます。 それぞれのサブスクリプションは、サブスクライバーが持続メッセージを必要とするかどうかを示します。
QoP レベル 施行されるメッセージ保護のレベルを指定します。以下の 4 つの値から 1 つを選択することができます。
  • なし
  • チャネルの整合性 (Channel Integrity)
  • メッセージの整合性 (Message Integrity)
  • 暗号化
デフォルト値は 'なし' です。
持続アクセス制御の振る舞いは、パブリッシュおよびサブスクライブ制御とは異なります。
  • 拒否されたパブリッシュ・アクセスであるクライアントは、パブリケーション・メッセージを 拒否します。
  • 拒否されたサブスクライブ・アクセスであるクライアントは、パブリケーションを受け取りません。
  • 持続アクセス制御はサブスクライバーへのメッセージは拒否しませんが、その持続性は拒否するので、 拒否されたサブスクライバーはそのサブスクライブアクセス制御にしたがってメッセージを常に受け取り ますが、オリジナル・メッセージの持続性に関係なくそのメッセージを非持続的に送信します。

セキュリティー・ポリシーの継承

通常、トピックは階層ツリーに配列されます。 親トピックの ACL は、明示 ACL を持たない子孫トピックの一部または全部によって継承されます。 したがって、すべてのトピックそれぞれに明示 ACL を関連付ける必要はありません。 すべてのトピックには、その親のものである ACL ポリシーがあります。 ルート・トピックまでのすべての親トピックに明示 ACL がない場合、そのトピックはルート・ トピックの ACL を継承します。

たとえば、以下のトピック・ツリーではトピック・ルートは示されていませんが、 そのメンバーが持続パブリケーションをパブリッシュ、サブスクライブ、および受け取ることができる PublicGroup の ACL を持つという前提です。 (記号 "¬" は "not" を意味します。)

トピック・ツリーでの ACL の継承


この図は、次の構造を持つトピック・ツリーを示します。 A が最上位レベル、B、K および P が次のレベルです。 K にはさらに先のレベルがあり、ノード M、そしてその先にはノード N があります。 ツリー内のノードの一部については、ACL が示されています。 ノード A には joe を含むパブリッシュ ACL、Public Group を持つサブスクライブ ACL、 および ¬Public Group を含む持続 ACL があります。 ノード B には、allen を含むパブリッシュ ACL、HR と ¬Public Group を持つサブスクライブ ACL があります。 明示的に定義されている持続 ACL はありません。 ノード P には joe を含むパブリッシュ ACL があり、明示的に定義されたサブスクライブ ACL はありません。 joe を含む持続 ACL があります。 ノード N には mary と joe を含むパブリッシュ ACL、 nat を含むサブスクライブ ACL、および Public Group と ¬nat を含む持続 ACL があります。 ノード K および M には、明示的に定義されている ACL はありません。
次の表は、図で示されたトピック・ツリーの結果、場合によっては継承される ACL を示します。
トピック (Topic) パブリッシャー サブスクライバー 持続
A joe のみ 全員 なし
A/P joe のみ 全員 joe のみ
A/K joe のみ 全員 なし
A/K/M joe のみ 全員 なし
A/K/M/N mary、joe のみ 全員 nat 以外全員
A/B allen、joe HR なし

動的に作成されるトピック

システム管理者によって明示的に作成されるものではなく、クライアントがメッセージをパブリッシュまたは サブスクライブするときに動的に作成されるトピックは、システム管理者によって 作成されるトピックと同じように処理されますが、これらのトピックには明示的に定義された ACL は ありません。つまり、動的に作成されるトピックの ACL は、明示ポリシーがあるトピック・ツリーで 最も近い祖先から継承されます。 したがって、明示 ACL がなくても、ツリーで葉トピックを定義する必要はありません。

ACL およびワイルドカード・トピック

WebSphere Business Integration Message Broker では、明示セキュリティー・ポリシーをワイルドカード・トピックと関連付けることはできません。たとえば、ACL を 2 つのレベル階層を表し、"A/B"、"A/K"、 および "A/P" を含むトピック "A/+" と関連付けることはできません。

しかし、WebSphere Business Integration Message Broker は、クライアント・アプリケーションがワイルドカード・トピックにサブスクライブする 場合は正しいアクセス仲介を保障します。

たとえば、トピック "A/+" がセキュリティー・ポリシーを明示的に関連付けず、 それを実行することもできません。 したがって、"A/+" は、"A" からポリシーを継承します。 サブスクライブ ACL には 全員が含まれるので、どのユーザーでも "A/+" にサブスクライブできます。

メッセージが "A/P" または "A/K" でパブリッシュされる場合、 ブローカーはそのメッセージを "A/+" にサブスクライブしたユーザーに送達します。 しかし、メッセージが "A/B" にパブリッシュされる場合、そのメッセージは HR グループに 属するサブスクライバーにのみ送達されます。

システム管理者が "A/+" と一致するトピックのサブスクライブ ACL を変更すると、 ブローカーはメッセージ送達時に正しく ACL を施行します。 ワイルドカード・トピックへのサブスクライブは、ワイルドカードに一致し、 サブスクライバーがそのメッセージを受け取るための権限を持つすべてのトピック上で メッセージを送達するセマンティクスを持っています。

ACL およびサブスクリプション解決

ブローカーは、送達されるメッセージのトピックを介してアクセス制御を施行します。 明示的にまたは継承によってそのトピックに対するサブスクライブ・アクセスが 否認されていないクライアントにのみ、メッセージが送達されます。 サブスクリプションにはワイルドカードを含めることができるため、トピック・ネーム・スペースに対する実際の一致、したがってトピック ACL は、サブスクリプションが受け取られるときには作成できません。 サブスクライバーへのメッセージの送達の決定は、トピックを持つ特定のメッセージが メッセージ・ブローカーによって処理されている場合のみに行われます。

トピック ACL 更新を活動化する

トピック ACL への更新は、WebSphere Business Integration Message Broker ワークベンチからブローカー・ドメインを介してデプロイされ 活動化されるまでアクティブにはなりません。ACL をデプロイするには、グループ mqbrops のメンバーであるか、 または、少なくともルート・トピック・オブジェクトへのデプロイ許可を与えている、 オブジェクト・レベル・セキュリティーの ACL を持つグループのユーザーまたはメンバーである必要があります。

関連概念
ユーザー・ネーム・サーバー
トピック
パブリッシャー
サブスクライバー
セキュリティー
ランタイム・リソースのセキュリティー
パブリッシュ/サブスクライブ・セキュリティー

関連タスク
トピック・ベースのセキュリティーの使用可能化
ユーザー・ネーム・サーバーの作成
ACL 項目の作成

関連資料
トピック階層エディター
サブスクリプション照会エディター