目次


WebSphere MQ File Transfer Edition V7 をセキュアにする

Comments

はじめに

IBM® WebSphere® MQ File Transfer Edition (以降、FTE と略称) は、既存の MQ ネットワークと統合することによりファイル転送管理機能を提供します。アーキテクチャーの観点からは、FTE の構成は通常の WebSphere MQ アプリケーションと変わらず、キュー・マネージャーに接続してメッセージをキューに入れたり、キューからメッセージを取得したりします。その点では、FTE は他の MQ アプリケーションと同じく認証とアクセス制御によって保護されていると言えます。ですが他の多くのメッセージング・アプリケーションと異なり、FTE が関与するセキュリティー・ドメインの境界はメッセージングの領域にとどまらず、オペレーティング・システムのファイル・サービスおよびディレクトリー・サービスにまで及びます。ファイル・サービスおよびディレクトリー・サービスのセキュリティー・モデルは、WebSphere MQ で使用されているモデルとは大きく異なります。管理者はこの両方のドメインにまたがるセキュリティーを有意義かつ効果的に実装しなければなりません。そのため、ユーザーと管理者で職務の分離を図り、またほとんどの場合において、複数のエンド・ユーザー・ロールを設けてそれぞれに異なるアクセス権を割り当てる必要があります。

この記事では、何をセキュアにしなければならないのか、そしてどのようなセキュリティー管理を使用できるのかを理解してもらうために、FTE のアーキテクチャーについて概説します。続いて、ファイル転送管理機能が同じ企業内の 2 つの部門に必要となるユース・ケースを取り上げ、部門ごとに異なるアクセス制御を実施できることを説明します。そして最後に、この記事で説明するすべてのタスクを網羅したチェックリストを掲載します。

コンポーネント・アーキテクチャー

FTE がキュー・マネージャーにバインディング・モードで接続するか、またはクライアント・モードで接続するかによって、FTE には異なるバージョンがあります。各バージョンには機能コンポーネントに加え、リモート・ツールとドキュメンテーション・パッケージが含まれるインストール・メディアも付属しています。構成時に、管理者は 3種類のキュー・マネージャーの詳細を提供するように求められます。これらのキュー・マネージャーはそれぞれ、エージェント・キュー・マネージャー、コマンド・キュー・マネージャー、調整キュー・マネージャーと呼ばれます。慣れるまでは混同してしまうかもしれませんが、キュー・マネージャーの違いをいったん理解すれば、構成はいたって単純です。FTE は、エージェントと呼ばれる長時間実行される単一のデーモン・プロセスで、ユーザーがエージェントにコマンドをサブミットしてそのステータスを問い合わせるためのツールを備えています。以上の点をふまえれば、他はすべて構成上の詳細に過ぎません。

図 1 に、典型的な FTE システムを示します (キュー・マネージャーは記載していません)。この図に示されている送信側エージェントと受信側エージェントには、それぞれコマンド・キューがあります。ファイル転送の管理は、ユーザーまたは管理者が、メッセージを送信側エージェントのコマンド・キューに直接、または付属のツールを使って入れることによって行われます。エージェント・プロセスはコマンド・メッセージに応じて、ファイルを WebSphere MQ を介して移動させてから、アクティビティー・ログを SYSTEM.FTE トピックにパブリッシュします。すると、ユーザーと管理者、およびアプリケーションが SYSTEM.FTE トピックのステータス更新をサブスクライブできるようになります。

図 1. WebSphere MQ File Transfer Edition のコンポーネント
Figure 1
Figure 1

用語

キュー・マネージャーへのアクセスは、FTE コンポーネントごとに必要です。最も単純なケースでは、ユーザーとエージェントのすべてが同じキュー・マネージャーに接続します。逆に最も複雑なケースでは、エージェントとユーザーをネットワークに分散させて、WebSphere MQ にコマンドのルーティングとノード間でのデータ・トラフィックを管理させる場合もあります。トポロジーについて検討する際は、さまざまなノードをその役割によって区別しなければなりません。上述したように、ノードは役割に応じて、エージェント・キュー・マネージャー、コマンド・キュー・マネージャー、調整キュー・マネージャーと呼ばれます。

FTE エージェントはそれぞれが、1 つの V6.0 以降のキュー・マネージャーに関連付けられます。エージェントとそのキュー・マネージャーを同じサーバー上でホストすることも、FTE エージェントが WebSphere MQ クライアント・チャネルを使用してリモートのキュー・マネージャーと通信するようにすることもできます。エージェントが使用するキューは、エージェントをデプロイするときに管理者が作成します。キュー名にはエージェントの名前が組み込まれるため、1 つのキュー・マネージャーで複数のエージェントをホストすることも可能です。後でその理由を説明しますが、この配置はいたって一般的なものです。

コマンド・キュー・マネージャー

ユーザーおよびインスツルメンテーションがネットワーク内のさまざまなエージェントにコマンドを発行するには、FTE に付属のコマンド・ライン・ツールと Eclipse プラグインを使用できます。2 つのエージェントが 1 つのキュー・マネージャーに接続しているような小規模なネットワークでは、そのキュー・マネージャーにツールが直接接続するように構成できます。一方、多数のエージェント・キュー・マネージャーがある分散ネットワークでは、ツールを各エージェント・キュー・マネージャーに直接接続してコマンドを発行するというのは実用的ではなく、またその必要もありません。分散ネットワークではすべてのエージェントに接続可能な単一のキュー・マネージャーに接続するようにツールを構成し、WebSphere MQ にコマンド・メッセージを適切にルーティングさせるようにします。ツールが接続するこのキュー・マネージャーが、コマンド・キュー・マネージャーです。各エージェント・キュー・マネージャーへのルーティングを解決できるという点を除けば、コマンド・キュー・マネージャーは特別なものではありません。コマンド・キュー・マネージャーで実行しなければならない FTE コードはなく、必要なキューはツールが実行時に作成する一時的な動的キューのみです。V6.0 以降のキュー・マネージャーであれば、いずれもコマンド・キュー・マネージャーとして機能することができます。さらに、すべてのユーザーが同じコマンド・キュー・マネージャーに接続しなければならないという条件もありません。実際、想定されるデプロイメントでは、ユーザーをロールごとにグループ化して異なるコマンド・キュー・マネージャーに接続することになります。

調整キュー・マネージャー

調整キュー・マネージャーは、FTE ネットワーク内のすべてのコンポーネントが共通して持つものです。エージェントで重要なイベントが発生すると、エージェントは調整キュー・マネージャーでホストされている SYSTEM.FTE トピックにメッセージをパブリッシュします。FTE ネットワーク内で何が起こっているのかを知る必要のあるユーザーあるいはアプリケーションは、これらのパブリケーションをサブスクライブします。パブリケーションを使用するためには、コマンド・ライン・ツールと Eclipse プラグインのいずれの場合も調整キュー・マネージャーへの接続が必要となりますが、エージェントが調整キュー・マネージャーに接続する必要はありません。パブリケーションはエージェント・キュー・マネージャーから WebSphere MQ ネットワークを介して調整キュー・マネージャーに送信できるからです。調整キュー・マネージャーで実行する必要のある FTE コードはありません。作業はすべて、ネイティブ WebSphere MQ 機能によって行われます。FTE では、調整キュー・マネージャーは V7.0 以降である必要があります。これは使用されるパブリッシュ/サブスクライブ機能による要件ですが、この要件を除けば調整キュー・マネージャーに特別な点はありません。

デプロイメント・トポロジー

最も単純な FTE ネットワークの例は、1 つのキュー・マネージャーがエージェント・キュー・マネージャー、調整キュー・マネージャー、そしてコマンド・キュー・マネージャーの 3 つの役割をまとめて務めるというものです。このトポロジーは機能するとは言え、同じサーバー上のディレクトリー間でファイルを移動させるだけであったら、それほど役には立ちません。FTE ネットワークを実用的なものにするために第一に行わなければならないのは、ファイルの供給元と配布先のサーバーにエージェント・プロセスを分散させることです。エージェント・プロセスを分散させると、図 2 に示すようなトポロジーになります。ここには 1 つのキュー・マネージャーと 3 つのノードからなるネットワークがあり、エージェントは WebSphere MQ クライアント・チャネルを使用して接続されます。この例でのキュー・マネージャーは、調整キュー・マネージャー、コマンド・キュー・マネージャー、エージェント・キュー・マネージャーの 3 つの役割を同時に果たします。

図 2. キュー・マネージャーが 1 つしかない小規模な FTE ネットワーク
Figure 2
Figure 2

図 2 の小規模なネットワークは、管理、ライセンス・コスト、効率性のバランスがとれています。ファイルは論理的には Agent01 から Agent02 に移動しますが、物理的なデータ・パスはキュー・マネージャーを経由するため、ファイル転送は 2 つのネットワーク・ホップで行われることになります。つまり、いったん Agent01 からキュー・マネージャーに移動した後、再びキュー・マネージャーから Agent02 に移動するということです。このトポロジーでは移動する部分が比較的少なく、必要な MQ ライセンスも 1 つで済みますが、大量の FTE トラフィックがある場合にはネットワーク帯域幅の消費量が実際のデータ転送量の 2 倍以上になってしまいます。

この問題に対処するのが、キュー・マネージャーとエージェントを同じ場所に配置した、大容量の FTE ネットワークです (図 3 を参照)。このトポロジーでは、コマンドとステータス・メッセージが経由するのは調整キュー・マネージャーとコマンド・キュー・マネージャーを兼任する 1 つのキュー・マネージャーであることに変わりはありませんが、データは 2 つのエージェント・キュー・マネージャーの間で WebSphere MQ チャネル (送信側/受信側がペアになったチャネルなど) によって直接受け渡しされます。

図 3. ローカル・エージェント・キュー・マネージャーを使用した分散 FTE ネットワーク
Figure 3
Figure 3

この記事の残りの部分では、上記の分散トポロジーを用いて説明を進めます。このトポロジーは、クライアントとの接続とキュー・マネージャー間の接続の、両方のセキュリティー構成について検討するのに適しているからです。すべてのコンポーネントが単一のキュー・マネージャーにデプロイされているような単純なトポロジーでのセキュリティー構成にも、これらの手法のサブセットを適用できます。

ファイルおよびオペレーティング・システムのセキュリティー

アプリケーションか、またはインフラストラクチャーか

話を進めるにあたり、FTE エージェントがビジネス・アプリケーションなのか、それとも WebSphere MQ インフラストラクチャーのコンポーネントなのかという疑問があります。FTE をビジネス・アプリケーションとして扱うとしたら、その場合は管理アプリケーションではない他のアプリケーションと同じく、FTE をアプリケーションのサービス・アカウントで実行し、そのアカウントに WebSphere MQ へのアクセスを許可すればいいだけとなります。こうすれば、FTE エージェントにアプリケーション・ファイルの読み取り、削除、作成を行うためのアクセス権を必要に応じて付与することができ、しかも WebSphere MQ に対する FTE エージェントのセキュリティー権限を最低限に抑えられます。ですがこの方法は、FTE の保守およびサポートがさまざまなアプリケーション・サポート・チームに分散されることを意味します。そうなると、アプリケーション・サポート・チームは一定レベルの WebSphere MQ 管理スキルを維持するとともに、FTE 構成に矛盾がないようにチーム間で調整しなければなりません。それでは拡張性がないばかりか、一元管理、および管理者とエンド・ユーザーの職務の分離といった、企業のファイル転送管理ソリューションの目的の一部と食い違うことになります。多くの会社では、規制遵守のために、あるいは単に有効なプラクティスだからという理由で最小特権セキュリティー・モデルに従おうとするはずです。この最小特権モデルを実装するには、職務の分離を達成することが鍵となります。そこで、ここで説明する構成では、FTE エージェントを固有のサービス・アカウントで実装し、WebSphere MQ へのアクセス、そしてビジネス・アプリケーションのファイルおよびプロセスへのアクセスを制限します。

FTE が動作する UNIX、Windows、および z/OS には、それぞれ独自のセキュリティー・メカニズムがあります。z/OS でアクセス制御の基準となるのはファイル名の修飾子です。ファイル名に含まれる共通の高位修飾子に基づいて FTE とエンド・ユーザーとの間でファイルを交換できるようにするプロファイルは比較的簡単に作成できるので、この作業は皆さんの演習として残しておきます。一方 Windows または UNIX でアクセスの基準となるのは、ファイルの所有権、ディレクトリーの所有権、そして所属グループです。そのため、必要なきめ細かいアクセス制御を行うには、所有権と特権とのマッピングを行わなければなりません。ここでの目標は、以下を実現するアクセス・ルールを考案することです。

  • FTE エージェントのアカウントを、FTE の実行可能ファイルと構成ファイルにアクセス可能な唯一のアカウントにします。
  • エージェントとエンド・ユーザーの両方が、転送するファイルの読み取り、書き込み、削除を実行できるようにします。
  • ビジネス・アカウントのみを、アプリケーションの構成ファイルなど、他のビジネス資産にアクセス可能なアカウントにします。

ファイルの作成と所有権

FTE エージェントがファイルを配信すると、ファイルは FTE サービス・アカウントが所有することになります。エンド・ユーザーにはそのファイルへのアクセス権が自動的には与えられません。UNIX の場合、umask 属性を使用して、新しく作成されるファイルが全ユーザーに対して書き込み可能になるように設定すれば問題は解決しますが、それでは最小特権アクセスの原則に従っているとは言えません。それよりも望ましい方法は、新規ファイルがグループに対して書き込み可能になるように umask 属性を設定し、グループごとにアクセス権を与えることです。ですがこの場合、どのグループを使えばよいのでしょうか。

新規ファイルの group 属性は所有者の 1 次グループから継承されます。そのためアクセス権を共有するためのメカニズムとして所属グループを使用するつもりであれば、FTE サービス・アカウントの 1 次グループを専用グループにすることはできません。代わりに、1 次グループに 1 つ以上のエンド・ユーザー・アカウントまたはアプリケーション・サービス・アカウントを含める必要があります。こうすれば、FTE エージェントが実行時に作成したファイルをエンド・ユーザーまたはアプリケーションが読み取ったり、削除したりできます。従って、FTE エージェントの管理サービス・アカウントは、1 つ以上のビジネス・アカウントが含まれる 1 次グループで構成することになります。

上記の方法によって実行時のファイルはセキュアになりますが、ビルド時のファイルは無防備なままです。FTE サービス・アカウントを使用してインストールを実行した場合、インストール・ファイルは同じグループによって所有されますが、このグループには管理アカウントではないアカウントが含まれます。従って、エンド・ユーザーとビジネス・アプリケーションが FTE システム・ファイルおよび構成ファイルの読み取り、書き込み、削除操作を実行できることになります。この問題を解決するためには、FTE システム・ファイルの所属グループを FTE サービス・アカウントの 1 次グループ以外のグループに変更し、FTE サービス・アカウントをこのグループの 2 次メンバーとして登録します。

ファイルを逆方向に移動する場合 (つまりビジネス・ユーザーによってファイルが作成され、FTE エージェントによって使用される場合) にも、アプリケーション・サービス・アカウントで同様に 1 次グループと 2 次グループのマッピングが必要となります。この場合の目標は、FTE エージェントがビジネス・アカウントによって作成されたファイルにアクセスしてこれを転送できるようにする一方、アプリケーションの構成ファイルのようなビジネス資産にはアクセスできないようにすることです。そのためには、FTE エージェントのサービス・アカウントとビジネス・ユーザーのサービス・アカウントに共通の 1 次グループを持たせ、両者の間で双方向の読み取り/書き込みアクセスを可能にする必要があります。

図 4 は、アカウントとグループのマッピング例です。

図 4. アカウントとそれぞれの 1 次グループと 2 次グループとのマッピング
Figure 4
Figure 4

Windows では、新規ファイルの所有権は UNIX と同じくファイルを作成したユーザーから継承されますが、Windows の場合、ファイルには UNIX ファイルと同じような意味でのグループ所有権はありません。幸い、新規ファイルが含まれるフォルダーへのフル・アクセス権が fteuser グループに与えられている限り、所属グループと同じアクセス・モデルが Windows でも同じく有効に機能します。Windows ではユーザー ID アクセス権のみを基準に許可を設定することも可能ですが、それよりも上記で説明したグループ・モデルを使用することをお勧めします。このモデルであれば、両方のプラットフォームで機能するからです。

FTE エージェントの実行

FTE エージェントには、キュー・マネージャーに対する管理権限は必要ありません。ですが残念ながら、FTE エージェントを起動する WebSphere MQ サービスを定義すると FTE エージェントがキュー・マネージャーのサブプロセスとして起動するため、FTE エージェントに管理権限が与えられてしまいます。この場合に危険なのは、FTE エージェントを使用して MQ オブジェクトを操作できるということよりも、FTE エージェントによって WebSphere MQ 構成ファイルがオーバーレイされる可能性があることです。例えばデフォルトの構成では、mqm として実行される FTE エージェントに qm.ini ファイルをフェッチするよう命令できます。アタッカーがこの qm.ini ファイルを編集してオブジェクト権限マネージャーを無効化し、その上で同じ FTE エージェントを使って正当な qm.ini ファイルに不正に細工したファイルをオーバーレイしたとします。すると、次回キュー・マネージャーが起動されるときにはセキュリティーが完全に無効な状態になってしまいます。このような攻撃を避ける最善の手段は、FTE エージェントを実行するためのサービス・アカウントを作成し、そのサービス・アカウントを mqm グループから除外することです。

サンドボックス

サンドボックス機能では、管理者がファイル・システム内の任意の場所にあるディレクトリーを FTE エージェントのルート・ディレクトリーとして指定できます。サンドボックスの外でファイルにアクセスしようとすると、アクセスは拒否されます。サンドボックスを有効にするには、agent.properties ファイルを編集して、sandboxRoot プロパティーに指定ディレクトリーの完全修飾ディレクトリー名を追加します。

FTE エージェントに重要なサーバー構成ファイルをオーバーレイさせるという前述の攻撃は、エージェントがデフォルト設定でインストールされていることを前提とします。具体的に言うと、この種の攻撃を実行するには、サンドボックス機能が無効になっていなければならないということです。それではサンドボックスを有効にすれば、専用のサービス・アカウントでエージェントを実行する必要がなくなるのかと言えば、それはセキュリティーの要件次第です。防御の原則に厳格に従って、サンドボックス機能とサービス・アカウントの分離を両方とも実装することが強く推奨されます。そうすれば、アタッカーがエージェントの脆弱性を発見した場合でも、管理特権が危険にさらされるかわりに、構成が比較的セキュアな状態のままで済みます。FTE システムには、基本的なファイル・システムのセキュリティーと同様、サンドボックスを有効にすることが必須であると考えてください。

サンドボックス・プロパティーは単一の値で、配列ではありません。ファイルを配信または使用するためのディレクトリーが複数ある場合には、ディレクトリーごとに異なるエージェントを構成し、それぞれに適切なサンドボックス・プロパティー値を設定する必要があります。

ファイル転送攻撃の防止

構成ファイルについての最後の注意点は、エージェントはエンド・ユーザーのデータに対し、読み取りも書き込みもできるという点に関連します。qm.ini ファイルに対する前述の攻撃は、読み取り/書き込み操作が可能なエージェントを利用できるかどうかにかかっています。複数のエージェントがあるネットワークでの同様の攻撃として、中間エージェントにファイルを配信し、アタッカーが直接アクセスできない第 3 のエージェントにその中間エージェントからファイルを渡すということが考えられます。エージェント同士はエンド・ユーザーと同じコマンド・キューを使用して通信するため、リモート・エージェントのコマンド・キューへのアクセスをブロックしてこの攻撃を阻止することはできません。しかしながら、同じく agent.properties ファイルを編集することによって、エージェントを読み取り専用または書き込み専用に構成することは可能です。maxSourceTransfers プロパティーをゼロに設定すると、エージェントにアウトバウンド・ファイルの転送を拒否させることができます。同様に、maxDestinationTransfers プロパティーをゼロに設定すれば、エージェントはインバウンド・ファイルを受け取らなくなります。構文的には両方の値をゼロにすることも可能ですが、そうするとエージェントがまったくファイルを転送できなくなってしまうのでお勧めできません。サーバーに 2 つのエージェントがファイル送信側とファイル受信側としてデプロイされている場合は、サンドボックスのディレクトリーが重複しないようにエージェントを構成することで、ファイル中継攻撃から保護できます。

エージェント・キュー・マネージャーのための基本的な MQ セキュリティー

エージェント・キュー・マネージャーに対する管理アクセス権を持つユーザーであれば、エージェントが実行するように構成されているアクションを誰でも操作できます。そのため当然、キュー・マネージャーを管理アクセスから保護することが、FTE エージェントをセキュアにする上での前提条件となります。キュー・マネージャーの保護についての詳細な説明はこの記事の範囲外ですが、ここで簡単に概要を説明しておきます。WebSphere MQ のセキュリティーについての詳細は、記事の最後にある「参考文献」を参照してください。

キュー・マネージャーにバインディング・モード (SVRCONN チャネルではなく共有メモリー) を使用して接続しているローカル・ユーザーの場合には、オペレーティング・システムの認証で十分です。このようなローカル・ユーザーについては mqm グループから除外し、setmqaut コマンドを使ってキュー・マネージャー・オブジェクトに対する適切なアクセス権を与えてください。

難題は、リモート接続されたユーザーと他のキュー・マネージャーからの接続をセキュアにすることです。MCAUSER 属性に低特権アカウントが設定されていないインバウンド・チャネルは、キュー・マネージャーと FTE エージェントを管理できます。リモート接続をセキュアにするためのストラテジーは、接続リクエストを厳格に認証してから、認証された ID に対応する MCAUSER 値がそのチャネルに必ず構成されるようにすることです。

キュー・マネージャーをセキュアにする際の最初のステップは、使用されるべきでないすべてのインバウンド・チャネルを無効にすることです。それには、SYSTEM.DEF.* および SYSTEM.AUTO.* チャネルに MCAUSER('nobody') を設定します。

SYSTEM.ADMIN.SVRCONN チャネルは、管理者とエンド・ユーザーが WebSphere MQ Explorer でキュー・マネージャーにアクセスするために共通して使用します。一般に、これらの接続は SSL 証明書を使用して認証されてから、BlockIP2 などのチャネル・セキュリティー出口によって、SSL 証明書がそのチャネル・インスタンスの MCAUSER 値に動的にマッピングされます。このようにして、多数のユーザーが同時に、そしてセキュアに、さまざまなMCAUSER 値を使用して単一のチャネル定義にアクセスできるようになっています。この構成では、チャネルは通常、MCAUSER('nobody') や別の低特権アカウントで定義されるため、出口で障害があってもチャネルが管理特権を公開することはありません。

あるいは別の方法として、チャネル上の SSLPEER と SSLCAUTH、および静的 MCAUSER 値をうまく使うことによって、出口を使用せずに同じレベルのセキュリティーを達成することもできます。このストラテジーでは、それぞれのセキュリティー役割ごとに SVRCONN チャネルを定義しなければなりません。例えば、管理者は MCAUSER('mqm') または MCAUSER(' ') を設定した 1 つのチャネルを使用し、エンド・ユーザーは MCAUSER が低特権アカウントに相当する空白以外の値で構成された 1 つ以上の追加チャネルによって接続するようにします。これらのセキュア構成のいずれにおいても、対話ユーザーの認証に使用するのは SSL です。チャネルの SSLCAUTH 属性を有効に設定して、ユーザーの MQ クライアントに証明書を提供させ、未使用の認証局をキュー・マネージャーの SSL 鍵リングから除去します。

クライアント接続をセキュアにするだけでなく、RCVR、RQSTR、および CLUSRCVR タイプのチャネルを含めたインバウンド MCA チャネルもセキュアにする必要があります。これらのチャネルをデフォルト設定のままにしておくと、チャネルが管理アクセスを許容してしまうからです。この危険に対処するには、専用グループと併せてサービス・アカウントを設定し、チャネルの MCAUSER 属性をそのアカウント名で構成します。次に、専用グループにキュー・マネージャーへの接続と問い合わせ、および限られた数の正当な宛先への書き込みと問い合わせを許可します。このグループに対しては、管理特権を取得するために使用できるキュー、例えばコマンド・キュー、トランスミッション・キュー、イニシエーション・キューなどへのアクセスが明確に拒否されます。

クラスターでは、この構成にチャネル自動定義 (CHAD) 出口とセキュリティー出口の両方が必要です。CHAD 出口がセキュリティー出口を構成し、セキュリティー出口がチャネルの MCAUSER 属性を適切なサービス・アカウントに設定します。

管理アクセスからキュー・マネージャーを保護する方法についての詳細は、以下を参照してください。

FTE エージェントのための WebSphere MQ セキュリティー

以下に、これまでに行った作業をまとめます。

  • WebSphere MQ FTE エージェントは、共通グループと専用グループを持つ専用のサービス・アカウントで実行中です。
  • エージェントに、独自のディレクトリーに対する読み取りおよび実行アクセスを許可しました。
  • ビジネス・ユーザー・アカウントの所有権でファイル格納ディレクトリーを作成しました。
  • エージェントのサンドボックスを有効に設定し、ファイル格納ディレクトリーを指すようにしています。
  • エージェントに、ファイル格納ディレクトリーに対する読み取り/書き込み/削除のためのアクセス権を与えました。
  • エージェント・キュー・マネージャーがすべての接続を認証し、低特権ユーザーに対しては管理権限を規制します。

次のステップは、FTE アプリケーションが使用する WebSphere MQ オブジェクトをセキュアにすることです。そのためには、エージェントのアクティビティーを操作するために使用するプロトコルを理解しなければなりません。

管理者、エンド・ユーザー、そして他のエージェントはすべて、メッセージをコマンド・キューに入れることによって FTE エージェントと対話します。エージェントは管理者や他のエージェントから受け取ったコマンド・メッセージとエンド・ユーザーから受け取ったコマンド・メッセージとを区別しません。つまり、セキュリティーの基準となるのはエージェントのコマンド・キューにメッセージを入れられるかどうかだけで、このレベルのアクセス権を持っていれば、エージェントが実行するように構成されたアクションを誰でも操作することができます。

対話ツールはいずれも送信側からファイル転送を操作することから、セキュリティーを強化する 1 つの確実な手段は、エンド・ユーザーが受信側エージェントにアクセスできないようにすることです。上記の図 3 に示したネットワークでは、対話ユーザーとエージェント間の管理コマンドは、エージェント同士の通信チャネルとは異なるチャネルで伝送されます。チャネルに異なる MCAUSER 値を設定することで、AGENT01 が AGENT02 のコマンド・キューにメッセージを入れられるようにすると同時に、コマンド・キュー・マネージャーのユーザーがこの同じキューにメッセージを入れられないようにすることができます。以下の図 5 に示すのは、メッセージ・パスに基づいてコマンド・キューを制御する一例です。このセキュリティー強化は、前述の内容に依存します。具体的には、AGENT01 を送信専用エージェントとして構成し、エンド・ユーザーには AGENT01 のキュー・マネージャーの送信キューやその他のキューに対するアクセス権を持たせないようにします。こうすることによって、エンド・ユーザーが細工したファイルを AGENT01 を使用して中継したり、あるいは AGENT02 に直接送信したりといったことができないようにします。

図 5. メッセージ・パスに基づいたエージェント・コマンド・キューへのアクセスの保護
Figure 5
Figure 5

エージェント同士は互いの SYSTEM.FTE.REPLY.<エージェント名> キューによっても通信します。このことから、最小特権モデルに従うとすれば、AGENT01 と AGENT02 の間のチャネルには互いのリプライ・キューにメッセージを入れる権限を与える一方、コマンド・キュー・マネージャーからのチャネルに対してはエージェントのリプライ・キューにメッセージを入れることを禁止する必要があります。

調整キュー・マネージャー

前述したように、任意の V7 キュー・マネージャーを調整キュー・マネージャーとして指定することができます。FTE ネットワーク内のすべてのエージェントは同じ調整キュー・マネージャーに更新をパブリッシュし、アプリケーションやツールはその調整キュー・マネージャーに接続してエージェント・パブリケーションをサブスクライブします。V7 キュー・マネージャーは、V6.0 スタイルのパブリケーション・メッセージをキューで受け入れて V7 トピックに変換することができます。これによって、FTE エージェントを V6.0 キュー・マネージャーにデプロイすることが可能となっているのですが、この配置はセキュリティーに悪影響を及ぼします。

調整キュー・マネージャーを構成すると、SYSTEM.FTE という名前のキューが定義されます。続いて、この SYSTEM.FTE という名前がシステムの特別な名前リストに追加されます。これにより、キュー・マネージャーのパブリッシュ/サブスクライブ・エンジンがこの新しいキューでパブリケーション・メッセージをモニターするようになります。この時点で、正しくフォーマットされて SYSTEM.FTE キューに到着するすべての RFH2 メッセージが V7 パブリケーションに変換されることになります。このプロセスでは、2 つのセキュリティー・チェックが行われます。最初のチェックは、キューに対する物理アクセスです。この例での調整キュー・マネージャーはネットワーク内のすべてのエージェントにとってリモートとなっているため、キューにメッセージを入れるのはメッセージ・チャネル・エージェントです。キュー・マネージャーの基本的なセキュリティー強化の一環として、チャネルの MCAUSER属性は低特権ユーザー ID で構成されています。SYSTEM.FTE キューにメッセージを入れる権限を与える必要があるのは、チャネルの MCAUSER 属性にこのユーザー ID が含まれる専用グループです。

2 つ目のセキュリティー・チェックは、メッセージ・ヘッダーの MQMD.UserID フィールドに含まれるユーザー ID に、SYSTEM.FTE トピックでのパブリッシュが許可されているかどうかです。これは、キュー・マネージャーのコマンド・サーバーが PCF コマンドを実行する前に行う許可チェックと似ていて、基本的なセキュリティー強化が必要な理由はここにあります。エージェントまたは一般のユーザーおよびアプリケーションがネットワーク内のどこかで管理者権限を持っているとしたら、MQMD.UserID に含まれる値は信用できません。つまり、エージェントの接続を認証した後に、エージェントから調整キュー・マネージャーまでのセキュアなパスを提供する必要があります。バインディング・モードで接続するエージェントの場合、MQMD.UserID の値は、そのエージェントを実行するサービス・アカウントになります。クライアント・モードで接続するエージェントの場合には、MQMD.UserID に SVRCONN チャネルの MCAUSER から継承した値が含まれます。これらの値は、メッセージがエージェント・キュー・マネージャーからセキュリティー・チェックが行われる調整キュー・マネージャーに移動しても変わりません。そのため、ネットワーク全体に分散するさまざまなエージェントからメッセージが到着したときに、SYSTEM.FTE へのパブリッシュに対する許可チェックにすべての MQMD.UserID の値を合格させることが秘訣となります。

この場合に有効なストラテジーはいくつかあります。FTE コンポーネントが小規模なクローズド・ネットワークにデプロイされている場合は、SYSTEM.FTE キューの物理アクセスを制御すればそれで十分です。これを実現するには、このキュー・マネージャーのすべてのインバウンド・チャネルに対し、SYSTEM.FTE キューへのアクセスを制限する MCAUSER 値が設定されるようにし、エージェントだけがこのキューにメッセージを入れられるようにします。そうすれば、SYSTEM.FTE トピックに匿名のパブリケーションを許可できます。このストラテジーは、ネットワークが従来のチャネルを使用する場合に最も効果的に機能します。クラスターでは高度なチャネル出口を使用しない限り、接続ごとにセキュリティーを適用することができないからです。また、エージェントが多数の固有のサービス・アカウントで実行している場合にも、このストラテジーが適しています。

別の手段としては、エージェントのために用意したすべてのサービス・アカウントを調整キュー・マネージャーにも定義し、SYSTEM.FTE トピックへのパブリッシュを許可するという方法もあります。WebSphere MQ クラスターを利用して FTE ネットワークがデプロイされている場合には、このストラテジーが適しています。クラスター内のすべてのノードが、SYSTEM.FTE キューにメッセージを入れるためのアクセス権を持つことになるからです。このストラテジーは、エージェント・インスタンスでのエージェント・サービス・アカウントの再使用を促し、調整キュー・マネージャーに定義しなければならない ID の数が最小限になります。この構成では、すべてのエージェント・サービス・アカウントがエージェントのホスト・サーバーだけでなく、調整キュー・マネージャーをホストするサーバーにも定義されます。いったん定義されたアカウントは、調整キュー・マネージャーの SYSTEM.FTE キューに対するアクセス権を持つグループに組み込まれます。

最後に説明する手段は、パブリケーションの MQMD.UserID を任意の値に設定するようにエージェントを構成することです。この振る舞いは、agent.properties ファイルの publicationMDUser プロパティーを使用して制御します。このストラテジーではエージェントをあるユーザー ID で実行し、別のユーザー ID でメッセージをパブリッシュさせることが可能です。それぞれのエージェントに固有のサービス・アカウントがある大規模な FTE ネットワークでは、この設定により、すべてのエージェントが同じ ID を使ってメッセージをパブリッシュできるようになります。理想的なソリューションのように聞こえますが、このソリューションにはエージェントにある程度の管理権限が必要です。一般に、MQMD.UserID を設定する権限をユーザーに与えることは推奨されません。この特権を持つアカウントの情報が漏れた場合、アタッカーが MQMD.UserIDに mqm などの管理アカウントに対応する値を設定するのを防ぐ手だてはありません。さらに、アタッカーがメッセージをキュー・マネージャーのコマンド・キューに送信すれば、そのキュー・マネージャーのセキュリティーは完全に危険にさらされてしまいます。FTE エージェントは調整キュー・マネージャーにつながっている送信キューとの直接アクセスに依存するため、エージェントが MQMD.UserID を設定できるということは、事実上、エージェントに調整キュー・マネージャーへの管理アクセスを与えるということです。このような事態が許容されるとしたら、この記事で説明した他のどのセキュリティー構成も必要ないでしょう。この機能をセキュリティー制御として使用しないでください。

その他の考慮事項

セキュリティー管理としてのトポロジーの役割

これまで説明してきたように、FTE の WebSphere MQ 側のセキュリティー対策は、通常の MQ アプリケーションの場合と変わりません。キューのセキュリティーはサービス・アカウントとグループに基づきます。典型的なネットワークでは、FTE エージェントへのアクセスはリモート接続によって行われ、セキュリティー・ポリシーの一部はメッセージング・ネットワークの物理接続性によって実装されます。異なるアクセス役割が必要になるという点については、さまざまなチャネルの MCAUSER 属性に含まれる異なるサービス・アカウントによって管理されます。こうしたアーキテクチャーの側面をふまえ、対話コマンドとエージェント間のコマンドに別々のパスを提供するトポロジーを紹介しました。このトポロジーでは、エージェントを送信専用と受信専用のペアに区分しています。また、関係するすべてのキュー・マネージャーで、管理特権のエスカレーションに対するセキュリティー強化を行うという前提条件が生じてきます。

ほとんどの会社では、既存の WebSphere MQ ネットワークにここまでのセキュリティーを実装することはありません。例えば、ユーザーに日常的にクラスター送信キューへのアクセス権が付与されている WebSphere MQ クラスターにエージェントを配置したとしたら、どのユーザーでも FTE エージェントを操作することが可能になります。明らかなベスト・プラクティスと言うには時期尚早ですが、FTE エージェントとユーザーからなる小規模なクローズド・ネットワークを作ることが一般的なデプロイメント・パターンになるはずです。新規の WebSphere MQ システムを最小限にとどめるために、既存のキュー・マネージャーと併設するかたちで FTE キュー・マネージャーを作成することもできますが、多数の重要なアプリケーションをサポートする大規模な既存のネットワークにセキュリティーを組み込むよりも、小規模なクローズド・ネットワークを新しく作成してセキュアにするほうが簡単です。

これまでに説明したセキュリティー役割には、管理者、エンド・ユーザー、エージェントがありました。ですが一般的な要件としては、エンド・ユーザーを複数の異なるクラスに分け、ユーザーが互いのファイルにアクセスしないように制限するきめ細かなセキュリティー・モデルが必要になります。FTE のセキュリティーはネットワークの物理トポロジーに大きく依存すること、そして小規模なクローズド・ネットワークは管理者とエンド・ユーザーの職務を分離する 1 つの方法であることはすでに説明したとおりです。エンド・ユーザーの役割に細分性を与えるようにこのモデルを拡張するには、複数のクローズド FTE ネットワークを構築します。例えば、人事部と経理部にそれぞれ別の FTE ネットワークを構築するなどです。

セキュリティー出口について

本製品のこのバージョンで提供されているセキュリティー出口ポイントでは、ファイル転送操作自体をインターセプトできます。コマンドをインターセプトする出口ポイントはないため、出口を使ってコマンド・メッセージを認証することはできません。現段階での製品におけるこの制約により、正当なユーザーのみがエージェントのコマンド・キューにメッセージを入れられることを確実にする最善の方法は、やはり FTE エージェントのクローズド・ネットワークを作成することです。

高度なトポロジー

きめの細かいセキュリティー・モデルをサポートするには FTE エージェントのクローズド・ネットワークが個別に必要だとすると、2 つのクローズド・ネットワーク間でファイルを安全に交換するにはどうすればいいのでしょうか。この場合もベスト・プラクティスと言うにはまだ早いかもしれませが、このニーズを満たす手段は、おそらくサンドボックスをオーバーラップさせることでしょう。例えば、人事部から経理部に新しい従業員マスター・ファイルを送信する必要がある場合、両方の部門のエージェントにそれぞれ異なるエージェント・キュー・マネージャーを使用させる一方、エージェントのサンドボックスは同じディレクトリーを指すように構成するという手段を取れます。サンドボックス内のファイルには両方のエージェントがアクセスできますが、エージェント・コマンド・キューは別々のキュー・マネージャーにあるため、それぞれに対応する部門しかアクセスできません。そのため、アクセスのオーバーラップはファイル・システムに制限され、攻撃面が最小限となり、エージェント・コマンド・キューでのきめの細かいアクセス制御を実装する複雑さも回避できるというわけです。

高度なトポロジーのもう 1 つの例として、企業の境界をまたがる B2B FTE ネットワークも考えられます。あらゆる B2B WebSphere MQ ネットワークに推奨されるトポロジーは、外部接続をセキュリティーが強化されたゲートウェイで終端させ、そこからメッセージを内部サーバーに中継するというものです。さらに、B2B インターフェースがキュー・マネージャーからの接続のみを許容し、クライアントからの接続は一切受け入れないようにすることも推奨されます。この 2 つの推奨プラクティスはどちらも、ビジネス・パートナーに MQ FTE クライアント・エージェントを使って内部ファイル・サーバーに接続させるのではなく、企業の内部ネットワークごとに 1 つのエージェントを配置し、それぞれのエージェントがセキュリティーの強化された MQ ゲートウェイを介してメッセージをルーティングするというソリューションを推奨しています。このソリューションではそれぞれのエージェント・キュー・マネージャーの間に 2 つのホップが増えることになりますが、このトポロジーは他の B2B インターフェースに推奨されているネットワーク・トポロジーとまったく同じです。

FTE 構成ファイルの更新

この記事で説明した構成ステップのなかには、エージェント構成ファイルを変更しなければならないものがいくつかあります。agent.properties ファイルを変更したら、忘れずにエージェントを再起動してください。これを行わないと、新しい値が反映されません。また、エージェント・ログ・ファイルを調べて、新しい構成が正しく構文解析されていることを確認してください。特に、エージェントではプロパティー値の最後の文字に続いてブランクやその他の空白文字が付加されることは許容されませんので注意してください。

FTE セキュリティー・タスクのリスト

以下のリストに、この記事で説明したタスクを要約します。決定的なベスト・プラクティスが明らかになるほど FTE のシステム数がまだ多くないこと、さらにこの製品は引き続き進化していくことから、このリストの内容は変更される可能性があります。

準備

  1. エンド・ユーザーに必要なそれぞれのセキュリティー役割を決定します。
  2. エンド・ユーザーのセキュリティー役割をサポートする FTE ネットワーク (複数の場合もあります) のトポロジーを決定します。
  3. ファイル転送フローを綿密に計画し、エージェントを読み取り専用、書き込み専用、または読み取り/書き込み可能エージェントとして識別します。
  4. 調整キュー・マネージャーでのパブリッシュ許可に適用するストラテジーを特定します。
  5. 上記のステップでの情報を基に、各グループに登録するユーザーと、どのグループが 1 次グループでどのグループが 2 次グループであるかに注意しながら、作成するサービス・アカウントおよびグループを特定します。

エージェントのインストール

  1. WebSphere MQ FTE エージェントのサービス・アカウント、共通グループ、および専用グループを設定します。
  2. エージェントをサーバーにインストールします。
  3. UNIX システムでは、FTE インストール・ファイルの所属グループは、インストールを行ったアカウントの 1 次グループになるため、インストール・ファイルのグループを FTE サービス・アカウントの専用グループ (つまり 2 次グループ) に変更します。
  4. ログ・ファイル、トレース・ファイル、および実行時に書き込まれるその他すべてのファイルを除き、FTE インストール・ファイルおよび構成ファイルを読み取り専用として設定します。
  5. インストールを FTE サービス・アカウント以外のアカウントで行った場合は、この時点で FTE インストール・ファイルの所有権も変更します。
  6. FTE 共通グループに、エンド・ユーザー・ファイルの配信先または提供元のディレクトリーに対する読み取り/書き込み/削除特権を与えます。
  7. エンド・ユーザーまたはアプリケーションのアカウントを FTE 共通グループに追加します。
  8. agent.properties ファイルを編集して sandboxRoot プロパティーを挿入します。このプロパティーの値は、エンド・ユーザーのファイル・ディレクトリーの完全修飾パス名に設定します。
  9. エージェントを読み取り専用にする場合は、maxDestinationTransfers プロパティーを agent.properties ファイルに追加し、値を 0 に設定します。
  10. エージェントを書き込み専用にする場合は、maxSourceTransfers プロパティーを agent.properties ファイルに追加し、値を 0 に設定します。

基本的なキュー・マネージャーのセキュリティー強化

  1. すべての SYSTEM.DEF.* および SYSTEM.AUTO.* チャネルを MCAUSER('nobody') に変更します。
  2. 2 つのサービス・アカウントと専用グループを設定します。「 Hardening WebSphere MQ Security」で説明しているように、RCVR、RQSTR、および CLUSRCVR チャネルで使用する ID を mqmmca とし、SVRCONN チャネルで使用するアカウントを mqmmqi とします。
  3. すべてのユーザー定義 RCVR、RQSTR、および CLUSRCVR チャネルを MCAUSER('mqmmca') に変更します。
  4. すべてのユーザー定義 SVRCONN チャネルを MCAUSER('mqmmqi') に変更します。
  5. mqmmca および mqmmqi グループに、管理キュー (コマンド・キュー、開始キュー、送信キュー、およびほとんどの SYSTEM.* キューなど) を除くすべてのキューへのアクセス権を与えます。

これはすべてのキュー・マネージャーの最小限の基本セキュリティー構成で、目的はキュー・マネージャーに対する管理権限を制限することです。その他の WebSphere MQ セキュリティーはすべて、この基本構成から構築します。具体的に言うと、異なるアクセス権を接続ごとに与えるには、2 つ以上の静的 MCAUSER 値が必要になります。

FTE エージェントのための MQ のセキュリティー強化

  1. 正当なユーザーが接続して転送リクエストをサブミットすることができるすべてのエージェントについて、どのチャネルにユーザー・コマンドが到着するかを識別し、これらのチャネルに対して、メッセージを SYSTEM.FTE.COMMAND.<エージェント名> キューに入れる権限を与えます。そのための手段としては、チャネル定義の静的 MCAUSER、あるいは MCAUSER を設定するチャネル・セキュリティー出口を使用できます。空白の MCAUSER が設定されたチャネルは、FTE エージェントおよびキュー・マネージャー自体に対する管理権限を公開します。
  2. エージェントの公開グループ (この記事の例では fteuser) に SYSTEM.FTE.COMMAND.<エージェント名> キューへのアクセスを許可します。
  3. ステップ 1 でチャネルの MCAUSER に構成したユーザー ID が、必ずステップ 2 で許可したグループのメンバーになっているようにします。
  4. エージェントの専用グループにすべての SYSTEM.FTE.* .<エージェント名> キューへのアクセスを許可します。
  5. エージェントがクライアント・チャネル経由で接続する場合、クライアント・チャネルが必ず SSL を使用して接続を認証し、認証された ID が確実に MCAUSER フィールドの値に設定されるようにします。
  6. 他のエージェントにつながっているインバウンド・チャネルに、ローカル・エージェントのコマンド・キューとリプライ・キューへのメッセージの書き込みが確実に許可されるようにします。ネットワーク内に複数のエージェントがある場合、または複数のローカル・エージェントがある場合には、MCAUSER 設定に複数のチャネル・セットと複数のユーザー ID を作成する必要が生じる場合があります。

調整キュー・マネージャーのための MQ のセキュリティー強化

  1. 匿名パブリケーションを使用する場合、グループ「nobody」に SYSTEM.FTE トピックへのアクセスを許可します。この固有の文字列「nobody」は WebSphere MQ にとって重要で、認証されていないユーザーを表します。
  2. または、fteagents (複数形であることに注意) というグループを作成します。
  3. fteagents グループに SYSTEM.FTE トピックへのアクセスを許可します。
  4. エージェントを実行するサービス・アカウントごとに、同じ名前のアカウントを、調整キュー・マネージャーをホストするサーバー上に作成し、そのアカウントを fteagents グループに登録します。
  5. 対話ユーザーが Eclipse プラグインで接続するための SVRCONN チャネルを作成します。
  6. 新規作成した SVRCONN チャネルの MCAUSER を、SYSTEM.FTE トピックへのサブスクライブが許可されたユーザー ID に設定します。

コマンド・キュー・マネージャーのための MQ のセキュリティー強化

コマンド・キュー・マネージャーは FTE ツールのための単なるネットワークへの接続であることを思い出してください。セキュリティー構成の大部分が焦点とするのは接続のインバウンド側であるため、コマンド・キュー・マネージャーに対して行えることは、キュー・マネージャーの管理上のセキュリティーが確実に侵害されないようにすることだけです。

  1. 基本的な MQ のセキュリティー強化の手法を適用して、ユーザーが認証され、非管理アクセス権のみが付与されるようにします。
  2. コマンド・キュー・マネージャーに必ず、ファイル送信用として構成されたエージェントへのチャネルのみが存在するようにします。

まとめ

FTE はサンドボックス機能などの有益なセキュリティー・ツールを提供するものの、セキュリティー構成の大部分は FTE コンポーネントの外部で行います。その例としては、特殊なサービス・アカウントとグループ、およびクローズド・ネットワークからなるデプロイメント・トポロジーの使用や、前提条件として管理アクセスを制限するための基礎となるキュー・マネージャーのセキュリティー強化などが挙げられます。複数のエンド・ユーザー役割が要求される場合、このようなレベルの細分性を実現するにはエンド・ユーザー役割ごとに分離したクローズド FTE ネットワークが必要になります。FTE ネットワーク間の対話は、メッセージング・ネットワークではなくファイル・システムを介して行い、それによってセキュリティーに対する脅威を最小限にします。これらの推奨事項は、製品の進化や、さらに多くのフィールド・テストの実施に伴い展開していくはずです。どんなガイドラインでも、時間をかけて証明されるまではベスト・プラクティスと呼ぶことはできませんが、これらの推奨事項もその例に漏れません。最後に、この記事で説明した構成タスクを簡潔なタスク・リストにまとめました。このリストを出発点に、それぞれの要件と経験に適合したセキュリティー構成タスクを策定してください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=427004
ArticleTitle=WebSphere MQ File Transfer Edition V7 をセキュアにする
publish-date=02252009