レベル: 中級 Keys Botzum, Senior Technical Staff Member , IBM India Software Lab Services and Solutions
2005年 12月 07日 セキュリティーを構成するのは、ネットワークのエッジで外部から保護するファイアウォールだけではありません。セキュリティーは、システムをできる限り適切に強化することを目的とした、困難で複雑な一連の措置と手順です。この記事は、一般的なセキュリティーのさまざまな側面を取り上げるとともに、IBM® WebSphere® Application Server セキュリティー・アーキテクチャーの詳細と WebSphere Application Server 環境の強化について説明する 2 部構成のパート 2 です。
この記事は、著書『IBM WebSphere: Deployment and Advanced Configuration』のセキュリティーに関する章をベースに、WebSphere Application Server V6 用に大幅に更新し、セキュリティーの強化方法にのみ焦点を絞って編集されています。本文は単独の記事として掲載するために編集および構成されています。記事は WebSphere Application Server V6 に基づいていますが、ここに記載するほとんどの問題は V5 および V 5.1 にも等しく当てはまります。V6 に特有の問題については、その旨を明確に示しています。その他のほとんどすべては、この 3 つの主要なリリースに共通の問題ですが、スクリーン・ショットと例には V6 を使用しています。
パート 1 からの続き
この記事は、「WebSphere Application Server V6 高度なセキュリティーへの強化 -- パート 1: セキュリティー強化の概要とその取り組み方法」の続きです。
高度な考慮事項
ここからは、強化に関わるより高度な問題を取り上げます。内容は以下のとおりです。
- セル間の信頼
- アプリケーションの分離
- ID の伝搬
- WebSphere Application Server セキュリティーでの制約事項
多くの場合は特定の推奨事項を記載する代わりに、セキュア・インフラストラクチャーの維持および管理の取り組みに役立つ重要な情報を提供します。
セルの信頼と分離
WebSphere Application Server のセルはトラスト境界にまたがってはなりません。他の誰かを完全に信頼できない場合は、セルを管理させたり、セル内のマシンを管理させないでください。WebSphere Application Server 管理インフラストラクチャーがセル全体で前提とするのは、粒度の粗い共有トラスト・モデルです。そのため、すべてのアプリケーション・サーバーはその中に、内部 API を含め、管理インフラストラクチャーを含んでいます。この利点は、制御の共通点を排除することによってアプリケーション・サーバーの独立性と堅牢性が極めて高くなるということです。ただし残念ながらそれと同時に分離性には悪影響を与えます。この方法により以下のことが予想されます。
- WebSphere Application Server セル内のすべてのアプリケーション・サーバーが、セル全体に対する完全な管理権限を持ちます。アプリケーション・サーバーが 1 つでも侵害されると、セル内のすべてのアプリケーション・サーバーのセキュリティーが侵害されます。
- 物理的マシン境界 (別個のコンピューター、LPAR、ノードなど) は実質上、セルのセキュリティーに何の影響もありません。セル内での信頼度の単位は、すべてのノード上にあるすべてのアプリケーション・サーバーです。
- プロセス境界はセルのセキュリティーにほとんど影響しません。個別のアプリケーション・サーバー JVM 内にそれぞれアプリケーションを配置しても、セル内のセキュリティーという観点では、アプリケーションの分離性はほとんど向上しません。
- 個別のオペレーティング・システム ID はセルのセキュリティーにほとんど影響しません。アプリケーション・サーバーは、オペレーティング・システムが管理していない各種のプロトコルを使ってセル内の残りのアプリケーション・サーバーと通信するため、通常のオペレーティング・システム展開はほとんど影響がありません。
- すべての管理者は、セル全体に対して同じ管理権限 (管理者、コンフィギュレーター、オペレーター、またはモニターとして割り当てられた権限の範囲内で) を持ちます。
以上のことは 2 つの重要な話題、管理の分離とアプリケーションの分離に関連します。
管理の分離
WebSphere Application Server では、すべての管理者がセル全体に対する管理権限を持ちます。個別の管理者にアプリケーションごと、アプリケーション・サーバーごと、またはノードごとに異なる権限を割り当てることは不可能です。
管理の分離を懸念している場合、こうした懸念に対して今すぐ行うことができる対処方法があります。まず、WebSphere Application Server の異なる管理役割を利用するという方法です。
次に、最も一般的な管理操作 (アプリケーションの更新、サーバーの再起動など) を対象としたカスタム管理ツールを作成する方法があります。これらのカスタム・ツールは、管理者とアプリケーションごとに制限できます。制限するための方法は 2 つあります。1 つは、カスタム wsadmin スクリプトを作成し、これらのスクリプトをオペレーティング・システムのアクセス権を使用して保護することです。それによって、それぞれの管理者が自分のサーバーのスクリプトしか実行できないようになります。もう 1 つの方法は、J2EE™ セキュリティーを用いて管理者を認証する小規模な Web アプリケーションを作成し、管理者が実行可能な操作をそれぞれのアクセス権限に応じて制限することです。このアプリケーション自体は、JMX API を使用してセルを管理できます。いずれの方法も、IBM のカスタマーによって有効に使用されています。
アプリケーションの分離
ここからは、この記事でおそらく最も難しい部分に目を向けます。このコンテキストでのアプリケーションの分離は、基本的には、あるアプリケーションの不正な操作によって他のアプリケーションが被害を受けないようにすることです。このようなタイプの攻撃を防ぐのは非常に困難です。J2EE アプリケーション・サーバーなどのインフラストラクチャー・ソフトウェア製品は、マルチユーザー・オペレーティング・システムとして成熟したレベルにまだ達していないのが現実です。オペレーティング・システムが一般的に提供するような複数ユーザー間の確実な分離は、まだ実現していません。
自分に関わるのかどうか
何よりもまず、ここで説明する弱点は内部的なものだけです。内部の弱点を悪用できるのは、セル内にインストールされたアプリケーションだけです。IBM の経験では、WebSphere Application Server のユーザーの大多数は、共有インフラストラクチャーを使っているユーザーも含め、そのような問題の影響は受けていません。その理由は、共有インフラストラクチャーは社内にあり、会社が承認したコードを実行していることを認識しているからです。そのため、通常は完全なアプリケーションのセキュリティー分離は必要とされません。
ここで説明する問題に影響される WebSphere Application Server のユーザーは、一般的に以下のような極めて厳しいセキュリティー・ポリシーを持っています。
- 正式なポリシーによって、アプリケーションが他のアプリケーションのデータにアクセスしないように定められています。このポリシーは、アプリケーションが共有インフラストラクチャー内で実行している場合でさえも適用されます。
- WebSphere Application Server 以前のシステムでは、共有サーバー上で個別のユーザー ID を使って実行しているすべてのアプリケーションに、ファイル・システムへのアクセス権に関する詳細なルールを持たせ、アプリケーションごとに専用プロセスを持たせるという要件があり、そしてこれらの要件を実施するための厳しい監査手順がありました。
- アプリケーション・アーキテクチャーおよびコードの検査を含めた厳格な企業セキュリティー・ガイドラインがあり、確実に準拠するよう厳格に実施されます。コードの検査を行わないと、開発者が企業ポリシーに違反したコードを挿入する可能性があります。
- WebSphere Application Server のユーザーは、あるアプリケーションのセキュリティーを侵害することによって他のアプリケーションのセキュリティーも侵害するリモート攻撃を、ことのほか危惧しているという場合もあります。
上記のカテゴリーに当てはまらなければ、あなたにとってアプリケーションの分離は対象外の問題なので、このセクションの残りをスキップしても構いません。
どんな軽減措置を取れるのか
アプリケーションが他のアプリケーションのセキュリティーを侵害することを懸念している場合、そうした懸念に対処するために、以下のステップを今すぐ実行できます。
- すべてのアプリケーション・コードで厳しいコード検査を実施します。これを、セキュアなソース・コード管理システムと組み合わせてください。そうすることで、あらゆるコード変更がその変更者に対して追跡記録され、すべてのコード変更に対するコード検査がスケジュールされてその進捗が見守られます。このような状況では、プログラマーが単独で悪意のコードをシステムに挿入することは不可能です。複数の人が協力しないと、セキュリティーを侵害できなくなります。
- 市販のアプリケーションを購入して WebSphere Application Server の最上位で実行することにした場合、確実に信頼できるベンダーのみから製品を購入してください。実動環境にデプロイする前にアプリケーションを慎重にテストおよびモニターし、実動中にもモニターしてください。
- やむを得ない場合は、アプリケーションを専用 WebSphere Application Server セルにデプロイしてください。事業単位ごとに異なるセルを使用するか、リスクと信頼に基づいて他の組織単位を使用することも考慮できます。単一のマシンまたは LPAR で複数のセルにあるノードを安全に実行すると、ハードウェアのコストを抑えることができます。異なるオペレーティング・システム・ユーザー ID、異なる暗号鍵、そして異なる管理パスワードを使ってそれぞれのセルを実行するだけで、セキュリティー上の完全な分離が実現されます。
上記のアプローチがいずれも容認できないのであれば、インフラストラクチャーに対するアプリケーションの分離を強化する手法を適用できます。ただし、相当な作業が必要になることを覚悟してください。さらに重大なことに、これらの手法は分離を保証するものではありません。同じセル内にあるアプリケーションは、グローバル・セキュリティーと Java™ 2 セキュリティーを有効にしても、同じセル内にある別のアプリケーションのリソースにアクセスしたり、あるいはセルの構成を変更したりすることで、この別のアプリケーションのセキュリティーを侵害する恐れがあります。そのようなセキュリティー侵害は今まで報告されていませんが、単一のセルの構成を介したセキュリティー侵害を不可能にする方法はありません。
以上の警告とは別に、ここからはセル内でのアプリケーションのセキュリティー分離を大幅に促進させるための措置について説明します。パート 1 と同様に、これらの措置は優先順位に従ってリストします。この記事で説明する強化手法をパート 1 で紹介した攻撃クラスに結び付けられるようにするため、それぞれの手法には以下のグラフィックを記載しています。
4 つの四角のそれぞれに陰影を付けて、その手法が防ぐ攻撃のタイプを示します。
-
N = ネットワーク・ベース
-
M = マシン・ベース
-
E = 外部アプリケーション・ベース
-
I = 内部アプリケーション・ベース
47. J2EE リソースではコンポーネントが管理するエイリアスを指定しないこと
セル内で実行するあらゆる J2EE アプリケーションは、どの J2EE リソースにでもアクセスする可能性があります。これは、リソースの持つ JNDI 名はアプリケーションが検索可能で、リソース・アクセスについて承認をする作業が行われないためです。例えば、アプリケーション A がエンタープライズ・データベースを使用する場合、そのデータベースをデータ・ソースとして定義するだけで、同じセル内のアプリケーション B がこのデータベースにアクセス可能になります。
アプリケーションがリソース・ファクトリー (データ・ソースまたは JMS 接続ファクトリーなど) で getConnection() を呼び出してリソースにアクセスしようとすると、WebSphere Application Server は、基礎リソースが利用できる場合は暗黙的に認証情報をそのリソースに提供します。提供する認証情報は、認証モードおよび使用可能な J2C 認証エイリアスによって決まります。詳細は非常に複雑なのですが、簡単に言うと、アプリケーションは JNDI 名前空間でリソースを検索することが可能だということです。リソースが検索されると、「アプリケーション」の認証モードが暗黙的に使用されます。つまりコンポーネント認証エイリアスがあれば、WebSphere Application Server がこれを使用するということです。その結果、コンポーネント・エイリアスで定義されたリソースは、セル内のどのアプリケーションでもアクセスできるようになります。異なる有効範囲でリソースを定義しても、セキュリティーには何の影響もないことに注意してください。リソース有効範囲は、単なる管理上の便宜でしかありません。
一方、リソースでコンテナー・エイリアスしか定義されていなければ (または指定されているエイリアスがなければ)、不正なアプリケーションがリソースにアクセスできなくなります。その理由は、アプリケーションがグローバル JNDI 名前空間でリソースを検索すると、アプリケーション認証が使用され、その結果コンポーネント・エイリアスが使用されるためです。コンポーネント・エイリアスがなければ、暗黙的な認証は行われません。
この手法を使うことにしても、当然のことながら、適切なアプリケーションがリソースにアクセスできるようにしなければなりません。そのためには、これらのアプリケーションがリソースにアクセスするためのデプロイメント記述子でローカル・リソース参照を指定する必要があります。ローカル・リソース参照はデプロイメント時に正しいリソースに設定できます。アプリケーションがその参照にコンテナーが管理する認証を指定すると、リソース自体に定義されたコンテナー管理対象のエイリアスが暗黙的に使用されることになります。これは図で見るとわかりやすいかもしれません。図 16 は、IBM Rational® Application Developer 参照エディターの画面です。ここでは、JMS 接続参照にコンテナーが管理する認証が指定されています。
図 16. コンテナーが管理する認証を使用したデータベース・リソース参照
 |
XA リカバリー・エイリアスは問題ではありません
コンポーネントの管理対象であるエイリアスを、リソースに指定された XA リカバリー・エイリアスと混同しないでください。XA リカバリー・エイリアスは、処理失敗に関する特定のリカバリー・シナリオでのみ使用されます。通常、Java 2 セキュリティーが有効で、デフォルトのアクセス権が使用されている場合、XA リカバリー・エイリアスはアプリケーションにアクセスできません。
|
|
この手法には 2 つの問題があります。まず、コンテナー管理対象のエイリアスは正常に機能しますが、使用は推奨されていないという点です。さらに重要なことに、もうお気付きかもしれませんが、すべてのリソースでコンテナーが管理するエイリアスを指定できるわけではありません (JMS ファクトリーなど)。指定できない場合は、リソースにデフォルト認証情報を指定しないでください。その代わり、デプロイメント・プロセスのときと同じように、アプリケーションでリソース参照ごとに認証情報を指定します (この場合、認証方法は問題ではありません)。この作業は厄介ですが、wsadmin を使用して自動化することもできます。少なくとも MDB の場合には、起動仕様に認証情報を指定できます。
48. リソースにデフォルト・ユーザー ID とパスワードを定義しないこと
上記項目の当然の結果として、リソースにはデフォルト・ユーザー ID とパスワードを定義してはならないことになります。定義した場合、セル内のどのアプリケーションでもリソースを検索できるようになるため、定義されたユーザー ID とパスワードが暗黙的に使用されることになります。
49. Java 2 セキュリティーを有効にすること
前にも説明したように、すべてのアプリケーション・サーバーには WebSphere Application Server 管理インフラストラクチャーが含まれるため、API でほとんどの管理操作を実行できます。API がわかるアプリケーション・プログラマーなら、これらの API を呼び出すアプリケーションを作成して基本的にはどの管理操作も実行可能です。さらに、ファイル・システム構成リポジトリーには相当な量の機密情報 (パスワードなど) が含まれますが、アプリケーションが平凡な Java I/O を使ってこれらのファイルを読み取ることができてしまいます。
WebSphere Application Server には、標準 JDK が提供する Java 2 セキュリティーのサポートが備わっています。IBM ではこの Java 2 サポートを強化して、J2EE 仕様を実施するとともに WebSphere Application Server 内部 API を未許可アクセスから保護しています。Java 2 セキュリティーを有効にするだけで、これらのルールが自動的に施行されます。つまり、Java 2 セキュリティーを有効にすると不正なアプリケーション・アクセスを防ぐための大幅な保護手段がランタイムに追加されます。
Java 2 セキュリティーが有効になると、アプリケーションはデフォルトで、極めて少数の「安全な」アクセス権セットに制限されます。アプリケーションにそれ以上のアクセス権が必要な場合、通常は EAR と一緒に含まれている was.policy ファイルで、必要なアクセス権を定義します。アプリケーションを実行すると was.policy ファイルが読み取られ、定義されたアクセス権が標準のアクセス権セットに追加されます。これは明らかに、セキュリティー・ホールになる可能性がありますが、幸いアプリケーションが追加アクセス権を要求すると、WebSphere Application Server 管理ツールが管理者に警告してくれます。私たちのアドバイスとして、要求されたアクセス権は十分に検討してください。予期しないアクセス権が要求されたら (予期されるアクセス権セットは、慎重にレビューされたアプリケーション配布文書内に記載されています)、そのアプリケーションを拒否してください。そのためには、アプリケーションで承認するアクセス権を決定するためのセキュリティー・レビューが組み込まれた公式プロセスが必要となります。
インストール時のレビューと検証のプロセスが面倒であれば、別の方法もあります。まず、大規模な環境セットの場合は、大部分のアプリケーションに共通の追加アクセス権セットが必要です。可能であれば、インフラストラクチャー･チームは app.policy ファイルに、該当ノードのすべてのアプリケーションに対するデフォルト・アクセス権を配置しても構いません。特殊なアクセス権を必要とするアプリケーションについてだけ、そのアクセス権を was.policy に配置し、追加の検証を要求するようにします。この方法をさらに進めて、was.policy の使用を禁止し、すべてのアクセス権が管理チームによって app.policy に追加されるようにすることもできます。共通ファイルの編集と同じ意味でデプロイメントが複雑になりますが、アプリケーションが不適切なアクセス権を獲得するリスクは少なくなります。
50. セキュア・チェーン代行を利用すること
アプリケーション・サーバーの最大の利点の 1 つは、ユーザー ID 情報がシステム・レイヤー間とアプリケーション間で自動的に送信されることです。そのため、シングル･サインオンは透過的に行われます。ただし残念なことに、これには 1 つの危険な副次作用が考えられます。それは、不正ななりすましです。
ここでの問題は、ユーザーがアプリケーション A を使用するために認証する場合、アプリケーション A はアプリケーション B に対してリモート EJB コールを行う可能性があるため、アプリケーション B が元のユーザーの資格情報を見るという点にあります。通常はこれで問題ありませんが、アプリケーション A が信頼できないとしたらどうなるでしょう。アプリケーション A にアクセスするユーザーには、誰かがそのユーザーになりすましてアプリケーション B にアクセスするかもしれないと心配するだけの理由があります。例えば、アプリケーション A は「重要でない」ため臨時に開発されている一方、アプリケーション B は機密情報を管理する非常に慎重を期するアプリケーションである場合を想像してみてください。ここでの問題は、アプリケーション B はアプリケーション A と共通のセキュリティー領域を共有しているというだけの理由で、アプリケーション A を信頼せざるを得ないという点です。これはまずいことです。
幸いなことに、この問題の回避方法はあります。それは、「セキュア・チェーン代行」として概説される WebSphere Application Server の新しい機能を使用するという方法です。アプリケーション B は WSSecurityHelper.getCallerList() または getServerList() を使用して、要求が通過したアプリケーションとサーバーを判断できます。これらの API は単にエンド・ユーザー ID を返すだけでなく、中間サーバーからの情報も返します。アプリケーション B が機密性の高いアプリケーションである場合は、リストを空にするよう要求できます。このことは、アプリケーション B をユーザーが直接使っていることを意味しています。WSSecurityHelper についての詳細は、WebSphere Application Server インフォメーション・センターを参照してください。
51. TAM WebSEAL の TAI パスワードを保護すること
SSO が Tivoli® Access Manager WebSEAL と WebSphere Application Server の間に構成されると、WebSEAL は要求ごとにその秘匿用のパスワードを HTTP ヘッダーで送信し、TAI が起動時に確実に機能するようにします。この接続は SSL で暗号化されるため通常は心配ありませんが、WebSEAL パスワードが WebSphere Application Server 内で実行中の Web アプリケーションにさらされることは確かです。
WebSphere Application Server 内で実行中の Web アプリケーションのいずれかが信頼できないとしたら、このパスワードを使ってアプリケーション・サーバーへの HTTTP 接続をオープンし、ユーザーの ID を表明してしまう恐れがあります。これによって、巧妙に作成された「悪意の」アプリケーションは誰にでもなりすますことが可能になります。
このような攻撃を心配している場合、コードを検査することによって簡単に攻撃は防げます。コードを検査して、信頼できないクライアントを Web コンテナーに接続させなければいいのです。方法は簡単で、Web コンテナーに相互認証された HTTPS リスナーを構成するだけです。こうすると、アプリケーションは正しい秘密鍵を持っていないために Web コンテナーへの HTTPS 接続をオープンできなくなります (WebSEAL または Web サーバーのみが正しい秘密鍵を持ちます)。
52. カスタム JMX コードのアクセス権の引き上げに注意すること
MBean を使用するには、Java 2 セキュリティー・アクセス権を高くしなければならないことに注意が必要です。アプリケーションがプログラマチックに MBean をアプリケーション・サーバー・ランタイムに登録するには、呼び出しコードに RuntimePermission Admin Permission を付与します。これによって、この呼び出しコードが管理操作を実行できるようになります。ただし、これは十分注意して行ってください。適切な方法は、MBean を登録するためだけのモジュールを個別に作成し、そのモジュールに必要なアクセス権のみを与えることです。
MBean をロードするもう 1 つの方法は、管理上で拡張 MBean として指定することです (推奨される方法)。これによって、アプリケーション・コードに管理権限を明示的に与える手間はなくなりますが、新しい問題が持ち上がります。この方法では、かなり低位レベルの WebSphere Application Server クラス・ローダーによって MBean がロードされますが、このクラス・ローダーの信頼度は高いため、MBean は通常のユーザー・コードよりかなり多くの WebSphere Application Server API にアクセスするようになります。
カスタム MBean を開発することにしたら、コードと使用方法を十分に検討して、システムにセキュリティー上の弱点をもたらしていないことを確実にするよう強くお勧めします。詳細は、『IBM WebSphere: Deployment and Advanced Configuration』を参照してください。
53. dynaCache は注意して使用すること
DynaCache は、WebSphere Application Server アプリケーションの強力かつ高性能の分散共有キャッシュになります。ただし、DynaCache ではアクセス制御は行われません。アプリケーション・サーバーで実行中のアプリケーションであればどれでも、そのアプリケーション・サーバーがアクセスできるキャッシュにアクセスできます。もっと正確に言うと、そのサーバーからキャッシュにアクセスできれば、すべてのアプリケーションが JNDI でキャッシュを検索し、そのコンテンツのすべてを覗く (または変更する) ことが可能です。
幸いにもリモート・サーバーでのキャッシュの検索は上手くいかないため、アプリケーションが覗けるのはサーバーに複製されているキャッシュのみです。このリスクを制限するためには、2 つのことを行います。まず、可能な場合はキャッシュに機密情報を置かないことです。次に、アプリケーションを個別の複製ドメインを持つ個々のアプリケーション・サーバーに配置して、確実に互いのキャッシュにアクセスできないようにすることです。
54. すべてのリソースを注意して使用すること
作業域 (Work Area) などの他の多くの WebSphere Application Server リソースではアプリケーション・レベルの許可を行いません。DynaCache の場合と同様に、これらのリソースは注意して使用する必要があります。この点について私たちはまだ、1 つひとつの WebSphere Application Server コンポーネントをすべて調べていません。アプリケーションの分離について懸念している場合は、すべての使用シナリオを注意深く評価し、潜在的な弱点を見つけたらそれに応じて対策を講じてください。
セル間の信頼
通常、WebSphere Application Server セルは互いを信頼しないため、セル間のシングル・サインオン (SSO) は不可能です。ただし、セル間 SSO をサポートするようにセルを構成することは可能です。このようにする正当な理由はたくさんありますが、この構成を行うとセルのトラスト・ドメインを拡大することになるため、セキュリティーとの関連を意識しなければなりません。考慮すべき点は、共有 LTPA 鍵、セル間のサブジェクト伝搬、そして CSIv2 ID 表明の 3 つです。
共有 LTPA 鍵
2 つのセルが透過的に 1 つの SSO ドメインに参加するには、2 つのセルは、同じ領域を共有し、同じ LTPA 暗号鍵を共有し、互換性のある SSL 鍵リング (サーバー間トラフィック用) を使用しなればなりません。通常、領域はレジストリーとまったく同じですが、WebSphere Application Server 6.0.2 では com.ibm.websphere.security.ldap.logicRealm プロパティーを設定することで、これを緩和できます。詳細は、WebSphere Application Server インフォメーション・センターを参照してください。
|
製品についての注意
同じ LTPA 暗号鍵を共有する目的が、カスタマイズしたサブジェクトを共有しないで Web SSO を作成することだけであったら、Tivoli Access Manager WebSEAL などの認証プロキシー・サーバーを使用すれば、LTPA 暗号鍵を共有しなくても同じ結果を達成できます。
|
|
互換性のある SSL 鍵リングとは、SSL 通信の場合と同じく、呼び出し側サーバーが受信側サーバーの証明書に対応する署名証明書にアクセスできなければならないことを意味します。
2 つのセルが同じ LTPA 暗号鍵を共有するようになると、それぞれのセルが互いの資格情報を作成できるという状況になります。そのため、一方のセルのセキュリティーが侵害されると、両方のセルのセキュリティーが侵害されます。セキュリティー目的でのアプリケーションの分離を達成する方法として複数のセルを使用している場合は、Java 2 セキュリティーを有効にして、WebSphere Application Server 内部 API へのアクセスを制限してください。
CSIv2 ID 表明
セル間で IIOP 呼び出しを行う一方、LTPA 暗号鍵を共有しないことは可能ですが、その代わりに CSIv2 ID 表明 (WebSphere Application Server 以外の EJB サーバーに接続する際にも機能します) を使用する必要があります。単純なシナリオとして、セル A とセル B という 2 つのセルがあり、どちらにもサーバーが含まれているとします。セル A 内のサーバーは、セル B 内のサーバーに対して RMI/IIOP 呼び出しを行う必要がありますが、その逆は不要です。これを実現するには、CSIv2 ID 表明を構成して、セル A 内のサーバーがセル B 内のサーバーに対して ID を表明するようにします。ここでは CSIv2 ID 表明の構成方法は説明しませんが、これを構成する意味は以下のとおりです。
セル B 内のサーバーが ID 表明を承認するには、セル A 内の上流サーバーがまず自己認証を行わなければなりません。これを CSIv2 で行うには、2 つの方法があります。1 つは基本認証で、この場合、上流サーバーがそのユーザー ID とパスワード (サーバー・ユーザー ID とパスワード) を送信します。もう 1 つの方法は上流サーバーが固有の証明書を使って認証を行うクライアント証明書認証です。WebSphere Application Server では両方の方法をサポートします。
認証が完了すると、受信側サーバーが、上流サーバーの ID 表明が信頼できることを検証します。これは CSIv2 構成パネルで構成されます。その後、上流サーバーが下流サーバーにターゲット・ユーザーの ID 情報を送信します。
この方法での信頼が意味することについて考えてみましょう。セル B 内のサーバーはセル A からの ID 表明を受け入れたので、セル A を信頼していることは明らかです。セル A のセキュリティーが侵害されている場合はセル B も同様ですが、それではセル A にとって信頼が意味するものとは何でしょう。
- セル A がユーザー ID とパスワードを送信して信頼を確立すると、セル B 内のサーバーに対してセル A のサーバー・ユーザー ID とパスワードが明らかになりますが、これには完全な管理権限があります。そのため、セル A は完全にセル B を信頼するようになります。これでは LTPA 鍵を共有するのと比べ、何の改善もありません。
- セル A が固有の証明書を使って認証を行う場合は、セル B には何も明らかにされません。セル A はセル B を信頼していないためです。
つまり、セル A がセル B に ID を表明するには、セル B がセル A を信頼しなければならないということです。それは確かにそうですが、セル A にセル B を信頼させたくない場合は、基本認証ではなく、サーバー間の認証手順として証明書認証を使ってください。
サブジェクト伝搬のコールバック
セル間でサブジェクト伝搬を利用している場合 (「Advanced Authentication in WebSphere Application Server」を参照)、これがセル同士の高い信頼を意味することを理解しておかなければなりません。共有 LTPA 暗号鍵の要件の他、セル・レベルのサーバー ID がセル境界を越えて多大な権限を持つことになります。
わかりやすくするため、例を用いて説明してみましょう。例えば、SSO ドメインを共有する 2 つのサーバーがあるとします。ユーザーは Web ブラウザーでサーバー A にアクセスし、認証セッション (ブラウザーの LTPA cookie によって表される) を取得します。次に、このユーザーはサーバー B にアクセスします。サーバー B はユーザーのサブジェクトをサーバー A から取得しようとします。これが、サブジェクト伝搬と呼ばれるものです。2 つのサーバーが同じ DynaCache 複製ドメイン内にあれば、サブジェクト伝搬は普通に行われます。ただし同じドメイン内にない場合には、サブジェクトを取得するために JXM コールバックが使用されます。異なるセル内にあるサーバーは当然、同じ DynaCache 複製ドメイン内にはありません。具体的には、サーバー B はサーバー A に対してセキュア JMX コールを行って、ユーザーのサブジェクトを取得します。
管理呼び出しと同じく、JMX 呼び出しには認証と許可が必要です。この例の場合は、サーバー B がそのサーバー・ユーザー ID とパスワードをサーバー A に送信します。サーバー A は送信されたパスワードを検証し、このユーザー ID にサーバー A のセルに対する管理権限があることを確実にします。
これには重要な意味があります。つまり、セル間 Web レイヤー (水平方向と呼ばれる) サブジェクト伝搬が機能するには、以下が条件となります。
- 受信側サーバー (サーバー B) は、その管理上の秘密のパスワードをサーバー Aに送信しなければなりません。サーバー A はそれによって、サーバー B のセルのサーバー・ユーザー ID とパスワードを知り、該当 ID に完全な管理権限があることを認識します。
- サーバー A (実際はサーバー A のセル) は管理権限をサーバー B のサーバー ID に付与する必要があります。その結果、サーバー B がサーバー A のセルに対する管理権限を取得します。
最終的な結果として両方のセルが互いを完全に信頼し、それぞれのセルがもう一方のセルに対する管理権限を持つことになります。これと同じ振る舞いがセル内での伝搬でも行われますが、その場合、同じセル内のサーバーはすでに互いを信頼して共通管理 ID を共有しているため、問題となる点は何もありません。
注意すべき点は、この振る舞いは、IIOP によって下流への伝搬が発生した場合には適用されないということです。その場合、上流サーバーは単純に下流サーバーにサブジェクトを送信するだけなので、JMX コールバックは必要ありません。
ID の伝搬
この話題はセキュリティーの強化には直接関係しませんが、早い段階でセキュリティーが考慮されていないシステム設計に紛れ込む共通の問題です。常に十分な注意を払って、ID が確立される場所と (該当する場合は) 伝搬される方法を追跡する必要があります。単純に ID が既知のものだと想定する設計をあまりにも多く目にしてきましたが、ID の伝搬は実用的技術をもってすれば実行可能です。アプリケーション内での ID の流れを慎重に分析して、開発サイクルの後になってから最悪の事態にならないようにしてください。ここで、外部リソースが関係する 2 つの一般的なケースを紹介しましょう。いずれも WebSphere Application Server V6 ユーザーとソリューションの場合です。
データベース対 WebSphere Application Server の認証
エンタープライズ・システムの主要な課題の 1 つは、強力なシステム・セキュリティー・コントロールを適切にインプリメントするということです。簡単に言うと、重要なデータは適切な許可を行って保護しなければなりません。これは、J2EE アプリケーション・コードが (JDBC、SQLJ、または CMP Bean を使って) データベースに接続する多層 J2EE システムではとりわけ難しい課題です。なぜなら、このようなシステムでは従来、エンド・ユーザーの ID 情報が失われてしまうからです。ここで言う「エンド・ユーザー」とは、自分のためにアプリケーションを実行しているユーザーを意味します。例えば、Bob が標準 J2EE セキュリティーを使用してアプリケーションに対して認証を行う場合、エンド・ユーザーは Bob となります。
典型的な J2EE ベースのシステムでは、コンテナーが認証済み接続プールを管理します。それぞれのエンド・ユーザーがアプリケーション・サーバーに対して (J2EE 認証メカニズムのいずれかを使用して) 認証を行いますが、そのユーザーの ID 情報はデータベースでは使用できません。その理由は、すべてのデータベース・アクセスは、接続プールにある一般的な共有接続のいずれかを使用して行われるためです。そのため、アプリケーションが既存のデータベース・レベルの許可を与え直し、アプリケーション・レイヤー内の関数を監査しなければならない結果となっていました。これは適切に行われれば無駄となり、適切に行われなければ十中八九、安全でありません。
WebSphere Application Server V6 では、この問題に対する優れたソリューションがあります。このソリューションについての詳細は、「Advanced Authentication in WebSphere Application Server」を参照してください。
キューイングした ID では実行されない MDB
メッセージがメッセージング・システムのキューに入れられると、通常は元の呼び出し側 ID は関係なくなります。つまり、メッセージング・エンジンは前述の接続 ID に基づいてキューへのアクセスを許可します。キューはエンド・ユーザーの ID を記録さえしないのが一般的です。
メッセージは通常、J2EE 内の MDB によってデキューされますが、この際、元の呼び出し側の ID は使用できません。使用できるとしても無視されます。MDB は匿名 J2EE ID または静的 run-as ID で実行されるため、メッセージをキューイングした ID は使用されないのです。
WebSphere Application Server には、この問題に対処するための直接的サポートはありません。ただしデータベース ID の展開と同じく、カスタム・コードを作成するのが億劫でなければ対処可能です。V6.0.2 の時点で、WebSphere Application Server はサーバー側の ID 表明をサポートするようになっています。つまり、パスワードを提供しなくても、サーバー側コードが JAAS を使用して J2EE run-as ID を変更することが可能です。サーバー側コードはパスワードを提供する代わりに、ただユーザー ID 情報を宣言するだけです。当然、サーバー側の ID 表明はセキュリティーに重大な影響を及ぼすため、デフォルトでは無効に設定されていますが、アプリケーション・コードに必要な Java 2 セキュリティー許可を与え、適切な JAAS ログイン・モジュールを作成すれば有効にしても構いません。これについては、WebSphere Application Server インフォメーション・センターの「信頼性検証での ID 表明」セクションで説明しています。
WebSphere Application Server の制約事項
慎重な構成によって、WebSphere Application Server を使った頑強で極めてセキュアな環境を作成できます。ただし、影響を及ぼす可能性がある、ささいで曖昧な制約事項について認識しておく必要があります。
CRL はチェックされません
クライアント認証で証明書を使用する際に認識しておかなければならないのは、WebSphere Application Server では CRL (Certificate Revocation List) をチェックしないという点です。そのため、クライアント証明書が改ざんされると取り消せなくなります。実際問題として、自己署名証明書とサーバー間通信を使用する特殊な状況を除き、これによって証明書認証が実行不可能になります。
一般的にこれは重大な問題ではありません。証明書は Web ブラウザー認証に使用される可能性が高いためです。このシナリオでは、証明書は実際には WebSphere Application Server ではなく Web サーバーによって検証されるため、IBM HTTP Server には CRL チェックが組み込まれていません。
Web サービス・レイヤーやカスタム UserRegistry (証明書チェックのコールアウトが含まれる) に十分なカスタム・コードがあれば、独自のカスタム CRL チェックを作成できます。
ターゲット ID は検証されません
セキュア・システムの微妙な側面の 1 つは、要求のターゲットを検証するというコンセプトです。通常、認証について考えるとき、クライアントを認証するサーバーについては考慮しますが、その逆となるとどうでしょう。クライアントは、どのようにしてサーバーが実際に対象のサーバーであることを識別するのでしょうか。我々の多くは認識していませんが、Web ブラウザーはこのチェックを毎日、暗黙的に行っています。HTTPS が使用されている場合、Web ブラウザーは Web サーバーのホスト名が Web サーバーの証明書にあるサブジェクトと同じであることを検証します。これによって、サーバーが実際にユーザーが意図するサーバーであることが確実になります (使用したホスト名をユーザーがわかっていることを前提としますが、ユーザーの多くはそれほど慎重ではありません)。
ここで明らかでないかもしれないのは、Web ブラウザーが行うチェックは、SSL に備わっているものではなく、SSL 外部で実行されるブラウザー固有のチェックであるという点です。イニシエーター (呼び出し側サーバー) は、この証明書チェックを明確に行う必要がありますが、WebSphere Application Server ではこのチェックを行いません。そのため、アプリケーション・サーバー (クライアント) がサーバーとの SSL 接続をオープンするときには、そのサーバーが本当に対象のサーバーであるかどうかを確認していないことになります。可能性としては極めて低いのですが、ハッカーが内部 DNS またはネットワークに侵入できるハッカーであれば、不正なサーバーを WebSphere Application Server セルに忍び込ませて情報を盗むことも可能です。 この攻撃は極めて難度の高いものですが (多くの攻撃はこれより遥かに簡単です)、この可能性を認識しておく必要があります。
この攻撃は防ぐには、不要な一切の署名鍵をアプリケーション・サーバーのトラスト・ストア・ファイルから除去してください。この攻撃を実行するには、信頼できる署名者が発行した証明書だけを使用しなければなりませんが、SSL ハンドシェークの間はクライアントが検証不可能なサーバー側証明書を拒否します。使用できるリストが短ければ (自己署名証明書だけが含まれるなど)、この攻撃は非常に難しくなります。
デスクトップ開発環境の保護
セキュリティーの強化について考えるとき、人々は実動システムだけに目を向けがちです。実動システムは明らかに最も重要ですが、デスクトップ・システムを含めたその他のコンピューターも十分にセキュアであることを確実にするために時間を費やすべきです。
Rational Application Developer (以前の WebSphere Studio) を実行するコンピューターの場合は、これは重大な懸案です。デスクトップ IDE には完全に機能的な WebSphere Application Server ランタイム環境が組み込まれていますが、このアプリケーション・サーバーにはオープン・ポートがあり、まさにこの記事で前述した意味でリモート・アクセスに対して脆弱なためです。この脆弱性に対処しなければなりません。
組み込みアプリケーション・サーバーの強化
少なくとも、組み込みアプリケーション・サーバーのテスト環境でグローバル・セキュリティーを有効にすることをお勧めします。これにより、侵入者が組み込みの管理インフラストラクチャーを使用して不正なアプリケーションをデスクトップにデプロイするという、ひどく悪質なタイプの攻撃をほとんど防止できます。Rational Application Developer を管理権限で実行している場合、これは極めて重大です。この記事で紹介した他の強化手順を使用することもできますが、管理インフラストラクチャーがセキュアであることを確実にすることのほうが遥かに重要です。
グローバル・セキュリティーを有効にする場合、レジストリーが必要になります。WebSphere Application Server では LocalOS と LDAP の 2 つをそのまま使用できます。このレジストリー・タイプのいずれも、デスクトップ・ワークステーションから使用するのは難しいと思うのであれば、代わりにカスタム・ファイル・レジストリーを構成するのが最善の方法です。IBM では、デスクトップで使用するのに適したサンプル・ファイル・レジストリーを用意しています。このサンプルは、WebSphere Application Server インフォメーション・センターのソース・フォームにあります。
組み込みアプリケーション・サーバーを強化する代わりに、コンピューターへのアクセスをブロックするデスクトップ・ファイアウォール製品を使用することもできます。このような方法は、正しく構成すれば非常に効果的です。つまり、このコンテキストでは内部企業ネットワーク全体を信頼するファイアウォールにはほとんど価値がありません。
エージェント・コントローラーの強化
Rational Application Developer にはエージェント・コントローラーとして知られるコンポーネントが含まれています。これはアプリケーション・サーバーの監視に使用されるツールですが、残念ながらデフォルト構成は完全に非セキュアで、どのホストからの要求も認証なしで受け入れます。そのため、このツールを利用してコンピューターのあらゆるファイルが読み取られる恐れがあります。エージェント・コントローラーを最初にインストールするときに、「このコンピューター」からの要求だけを受け入れるように構成するか、または要求を認証するように構成してください。このコントローラーだけで組み込みアプリケーション・サーバーを監視する場合 (これが通常です)、コントローラーが「このコンピューター」からの要求のみを受け入れるように構成するのが最善の方法です。
エージェント・コントローラーをすでにインストールしている場合は、以下のようにインストールを修正すると、ローカル要求だけが受け入れられるようになります。まず、<RAC_INSTALL>\config\serviceconfig.xml ファイルで Hosts 構成スタンザを見つけてください。以下のようになっているはずです。
<Hosts configuration="default">
<Allow host="ALL"/>
</Hosts> |
上記の内容を以下のように変更してください。
<Hosts configuration="default">
<Allow host="LOCAL"/>
</Hosts> |
まとめ
この 2 部構成の記事ではセキュリティーが持つ数え切れないほどの側面を取り上げましたが、焦点となった主題は WebSphere Application Server 環境の強化です。この記事を読んで、J2EE システムを保護するために必要な基礎知識が身に付いたことと思います。ここには記載しませんが、インフラストラクチャーのその他の部分を強化するための情報源も探してください。WebSphere Application Server は壮大なパズルのほんの 1 つのピースでしかありません。
最後に、IBM Security Scanner for WebSphere Application Server として知られる自動ツールを使って、この記事に記載した項目の一部をチェックできることを付け加えておきます。
謝辞
貴重な情報と支援を提供してくれた同僚の Cameron Martin 氏、Bill Hines 氏、Paul Ilechko 氏、Tom Alcott 氏に感謝します。また、Ching-Yun (C.Y.) Chao 氏と Peter Birk 氏、そしてWebSphere Application Server セキュリティー開発チームのメンバーにも感謝の言葉を送ります。
参考文献
著者について
記事の評価
| 
