4

LinuxプラットフォームにWebSphereMQ7.1をインストールした後、WebSphere MessageBroker8.0.0.1をインストールしました。ここで、実行グループを作成しようとすると、例外が発生します：理由コード2035。この例外は、ユーザーがキュー・マネージャーに接続する権限がないことを示しています。このユーザーをmqmグループに追加しました。MQ 7.0.xを使用していたとき、このような問題は発生しませんでした。よく調べてみると、MQ7.1にはユーザーIDがブロックされていることがわかりました。しかし、このユーザーが実行グループを作成できるようにしたいのですが、どうすればよいですか？お知らせ下さい。

4

2 に答える 2

6

MQセキュリティはMQv7.1で大幅に改善されており、以前のMQバージョンで使用されていたものとは異なります。MQ v7.1では、デフォルトですべてのシステム。チャネルはブロックされています。これらのシステムのいずれかを使用しようとしている場合。チャネルの場合、MQRC_NOT_AUTHORIZEDである2035を取得します。推奨される方法は、ブローカー用に独自のSVRCONNチャネルを作成し、チャネル認証レコードを作成して、ユーザーがキュー・マネージャーにアクセスできるようにすることです。

同様の問題に関するT.Robからの詳細な回答については、このリンクを参照してください。

アップデート：

SVRCONNチャネルは、キュー・マネージャーのエンドポイントを定義します。これは、クライアントがキュー・マネージャーに接続するために必要な接続情報を意味します。クライアントアプリケーションは、このタイプのチャネルを使用して、キューまたはトピックとの間でメッセージを送受信します。

メッセージブローカーツールキットは、メッセージブローカーの管理に使用できるGUIです。たとえば、実行グループの作成、フローの作成、バーファイルの展開などです。ツールキットはWindowsで利用でき、Linuxでも利用できると思います。

MBツールキットには、キューマネージャーに接続するためのSVRCONNチャネルであるSYSTEM.BRK.CONFIGチャネルが必要であることがわかりました。これは、MessageBrokerがMQに接続できるようにするために承認する必要があるチャネルだと思います。これが当てはまるかどうかを確認し、当てはまる場合は、そのチャネルのチャネル認証レコードを作成できますか？

于 2012-10-15T06:02:59.717 に答える
5

V7.1以降で新しいQMgrを作成する場合、次のデフォルトのCHLAUTHルールが付属しています。

SET CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
    DESCR(Default rule to allow MQ Explorer access)
    ADDRESS(*) 
    MCAUSER( )                              USERSRC(CHANNEL)

SET CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
    DESCR(Default rule to disable all SYSTEM channels)
    ADDRESS(*)
    MCAUSER( )                              USERSRC(NOACCESS)

SET CHLAUTH(*)                              TYPE(BLOCKUSER)
    DESCR(Default rule to disallow privileged users)
    USERLIST(*MQADMIN)

下部にあるものは、QMgrに「誰かが管理ユーザーIDを使用してSVRCONNを介して接続しようとした場合、すべての場合に接続をブロックする」ことを示しています。

Broker Toolkitからの接続を許可するには、次の2つの選択肢があります。

  1. mqmグループからmqbrkrsを削除します。これにより、管理者ユーザーをブロックするCHLAUTHルールを実行せずに接続できます。もちろん、mqbrkrsグループはMQ管理者ではなくなったため、アクセスが必要なすべてのブローカーおよびアプリケーションキューにmqbrkrsグループの許可を付与する必要があります。
  2. CHLAUTHルールをオーバーライドして、ブローカーツールキットがSYSTEM.BROKER.CONFIGチャネルの管理者として接続できるようにします。

セキュリティスペシャリストとして、私は最初のオプションを好みます。MQ管理者がブローカーを管理できることは避けられません。ただし、ブローカー（ひいてはすべてのブローカーフロー）がQMgrを管理できるようにすることを回避することは可能です。

ただし、2番目のルートを使用する場合は、管理者アクセスをブロックするCHLAUTHルールをオーバーライドする必要があります。これを行うにはいくつかの方法があります。ルールを削除することもできますが、それによりすべてのチャネルが管理者接続に開かれます。より正確なアプローチは、管理者が接続するチャネルに対してのみルールを提供することです。例えば：

SET CHLAUTH(SYSTEM.BKR.CONFIG) TYPE(BLOCKUSER) +
    USERLIST('*NOACCESS')

WMQは最も具体的なルールを適用するため、デフォルトのルールは新しいルールによって上書きされますが、SYSTEM.BKR.CONFIGチャネルに対してのみです。ルール構文を使用すると、誰を拒否するかを指定できますが、誰を許可するかは指定できません。またBLOCKUSER、グループIDではなくユーザーIDを使用します。管理者アクセスを許可するには、ではないIDを指定する必要があります*MQADMIN。*NOACCESS実際のユーザーIDにすることはできず、他の場所でWMQが使用する予約語であるため、選択しました。nobodyまたはなどの任意のユーザーIDを簡単に使用できますmqm。（ブロックmqmは許可しますmqbrkrsがmqm、グループmqbrkrs内にあるため、mqmmqbrkrsによるQMgrの管理を制限しません。）

最後に、管理者アクセスを許可するチャネルはすべて強力に認証される必要があることに注意してください。設定したCHLAUTHルールが上記のルールのみである場合、 QMgrへのネットワークルートを持っている人は誰でもmqbrkrs、接続でユーザーIDをアサートすることにより、そのチャネルに接続できます。接続すると、QMgrを完全に制御し、mqmまたはmqbrkrsユーザーIDを使用してリモートで匿名でコマンドを実行できるようになります。少なくとも、CHLAUTHルールを追加して、このチャネルの接続をIPアドレスでフィルタリングします。または、SSLを使用し、証明書の識別名で接続をフィルタリングすることをお勧めします。

于 2012-10-16T12:35:20.163 に答える