MQセキュリティプレゼンテーションから、必要のない場合にコマンドサーバーを停止するという推奨事項が1つあります。私の質問は、本当に必要かどうかをどのように判断できるかです。私の見解では、MQ ExplorerやQMGRにコマンドメッセージを送信する他のプログラムなど、ターゲットQMGRの管理プログラムが実行されていない場合は、そのコマンドサーバーを停止できます。
ありがとう
質問する
1777 次
1 に答える
5
コマンド サーバーは、WebSphere MQ Explorer や SupportPac MO71 などのデスクトップ ツールと、IR-360、AppWatch、QPasa! などの中央生産性/管理ツールで使用されます。その他。これは、Tivoli Omegamon XE for Messaging などのモニター・エージェントや、ユーザーが作成するカスタム・スクリプトなどの他のインスツルメンテーションでも使用されます。これらのツールを使用しない場合は、コマンド サーバーを停止できます。
原則として、コマンド サーバーを使用しない場合は、コマンド サーバーを停止することをお勧めします。ほとんどの場合はオフにしてから、承認された変更期間中にオンにするという代替案は、もう少し複雑です。その場合、実際に得られるのは、攻撃者にとって機会のウィンドウが減少することですが、それと引き換えに複雑さが増します。たとえば、コマンド サーバーをオンにするときは、まずキューがクリアされていることを確認する必要があります。そうしないと、攻撃者がコマンド キューにコマンドを事前にロードすることができます。また、QMgr へのアクセス権を持つ攻撃者がサーバー上でバックグラウンド プロセスを実行したままにしておくことができる場合、コマンド キューをポーリングし、コマンドをキューに入れる前に入力ハンドルを監視することができます。
QMgr へのアクセス権とデーモン プログラムを実行する機能の前提条件を設定するのは高いハードルだと思うかもしれませんが、ほとんどのショップでは完全な MQ 管理者権限で WebSphere App Server と WebSphere Message Broker を実行していると考えてください。このような場合、すべてのプログラムまたはワークフローが攻撃者になる可能性があります。MQ が関与する外部の違反はまだ公に報告されていませんが、私は、仕事を片付けようとしている善意の従業員によって WMQ が違反され、アプリケーションの管理者権限を使用して簡単に何かを「修正」するQMgr。
私が通常行う例外は、B2B ゲートウェイの QMgr です。私は通常、これらに多くのセキュリティを設定しますが、複雑さが増すことは気にしません。実際、B2B にゲートウェイ QMgr を使用する理由の 1 つは、外部接続を多くの QMgr で終了させてそれらすべてに追加のセキュリティを配置するのではなく、その複雑さを 1 つのホストに制限できるようにするためです。そのため、ゲートウェイを使用して、ネットワーク全体で実行するのは現実的ではない程度にセキュリティを確保しています。
要約すると、リモート生産性ツールや管理ツールを使用しない場合は、コマンド サーバーをシャットダウンしてください。ときどき実行する必要がある場合は、コマンド サーバーを起動する前に、コマンド キューがクリアされるように起動を自動化します (深さがゼロであることを確認するための後続のチェックを含む)。これは、チャネルが管理者アクセスを許可している場合にのみ有効性が制限されるため、二次的なセキュリティ コントロールと見なす必要があります。そのため、できるだけ早く V7.1 以降に移行してから、CHLAUTH ルールとSET AUTHRECコマンドを使用してチャネルをロックダウンしてから、コマンド サーバーについてあまり心配する必要はありません。
于 2012-09-05T11:28:17.427 に答える