レベル: 中級 Keys Botzum, Senior Technical Staff Member , IBM
2005年 12月 07日 セキュリティーを構成するのは、ネットワークのエッジで外部から保護するファイアウォールだけではありません。セキュリティーは、システムをできる限り適切に強化することを目的とした、困難で複雑な一連の措置と手順です。この記事は、一般的なセキュリティーのさまざまな側面を取り上げるとともに、IBM® WebSphere® Application Server セキュリティー・アーキテクチャーの詳細と WebSphere Application Server 環境の強化について説明する 2 部構成のパート 1 です。
IBM WebSphere 開発者向け技術ジャーナルより。
この記事は、著書『IBM WebSphere: Deployment and Advanced Configuration』のセキュリティーに関する章をベースに、WebSphere Application Server V6 用に大幅に更新し、セキュリティーの強化方法にのみ焦点を絞って編集されています。本文は単独の記事として掲載するために編集および構成されています。記事は WebSphere Application Server V6 に基づいていますが、ここに記載するほとんどの問題は V5 および V 5.1 にも等しく当てはまります。V6 に特有の問題については、その旨を明確に示しています。その他のほとんどすべては、この 3 つの主要なリリースに共通の問題ですが、スクリーン・ショットと例には V6 を使用しています。
はじめに
この記事では、セキュリティーのさまざまな側面を取り上げます。セキュリティーの重要性を簡単に説明した後、WebSphere Application Server セキュリティー・アーキテクチャーの詳細を説明します。次に WebSphere Application Server セキュリティーについての細かいポイントをいくつか取り上げてから、WebSphere Application Server 環境を強化してセキュアにする具体的方法の説明に移ります。最後に、セキュリティー問題のトラブルシューティングのためのヒントを紹介します。掲載スペースに限りがあるため、記事の大部分は概要にとどめ、詳細を徹底的に掘り下げることはしません。詳細情報については、可能な限り参照先を記載するようにしています。
セキュリティーがなぜ必要なのか
おそらく読者のほとんどはセキュリティーがエンタープライズ・システムの重要な側面であると認識していると思いますが、セキュリティーについての一般的な考え方を紹介するために、セキュリティーの根拠を簡単に説明します。
セキュリティーの基本的な目的は、システムから悪い連中を排除することです。具体的に言うと、セキュリティーとは、侵入者として知られる未許可のユーザーが不当なアクセスをすることがないように各種の手法を適用するプロセスです。
侵入者にはさまざまなタイプがあります。例えば、外国の諜報機関、競合会社、ハッカー、そして自社の従業員でさえ侵入者になり得ます。侵入者によってその動機、スキルと知識、アクセス、そして必要性のレベルは異なります。例えば、以下のとおりです。
- 従業員が会社に対して恨みを持っている可能性もあります。従業員は内部アクセスとシステムに関する知識レベルは著しく高いものを持っていますが、おそらくリソースとハッキングのスキルは限られています。
- 外部のハッカーはおそらくセキュリティー攻撃については熟知していますが、特別な恨みは持っていないと思われます。
- ビジネスによっては外国の諜報機関が会社に非常に大きな興味を持っていて、多大なリソースを所有している場合があります。
侵入者があなたのシステムを狙う理由は 2 つ考えられます。1 つは、禁じられた情報にアクセスするため、そしてもう 1 つはシステムの動作をどうにかして変えるためです。後者の場合、システムの動作を変えることで、侵入者の利益になるトランザクションを実行しようともくろんでいたり、あるいは何かしらうまい方法で単にシステムを故障させて組織に被害を与えようとしている可能性があります。
このように、侵入者とその動機にはさまざまなタイプがあり、後で説明するように攻撃のタイプもさまざまです。セキュリティーを計画するときには、この点を認識していなければなりません。
もう 1 つ強調したい点は、セキュリティーは「部外者」を遮断する単なるゲートとして見なしてはならないということです。それはあまりにも単純な見方です。今日の多くの組織では、部外者が唯一の脅威だという誤った考えで、組織の部外者だけに集中してセキュリティーの取り組みを行っていますが、そう単純にはいきません。組織内の人間がシステムを攻撃する可能性も大いに考えられます。最近のいくつかの研究では、侵入件数の約半分が、組織の従業員または契約者によって直接的あるいは間接的に行われたものであると報告されています。
ネットワーク上の全員が事実上信頼できる人間だと見込んだとしても、誰一人として間違いを犯すことはないと言えますか？E メールによるウィルスが増えるなか、内部ネットワークを全面的に信頼できると信じるのは無謀です。実際、信頼できません。
セキュリティーの取り組みによって、考えられるあらゆる侵入者からシステムを守ることが不可欠です。それが、この記事がこれほど長く、2 つのパートに分かれている理由です。セキュリティーを構成するのは、ネットワークのエッジで「外部」からネットワークを保護するファイアウォールだけではありません。セキュリティーとは、システムをできる限り適切に強化することを目的とした、難しく複雑な一連の措置と手順です。
制約と現実
完璧なセキュア・システムなどというものは存在しないということを認識することが重要です。目標とするのは、ビジネスの制約のなかでできるだけシステムを保護することです。セキュリティーについて考える際には、理想的には以下の作業を行います。
- 攻撃を受けるさまざまなポイントを分析する。
- 各ポイントでの攻撃のリスクを検討する。
- セキュリティー侵害となる攻撃が成功した場合の損害の可能性を判断する。
- 各攻撃を防ぐ費用を見積もる。
セキュリティー侵害による損害を見積もる際には、セキュリティー侵害によってシステムのユーザーを信頼できなくなるという可能性も決して忘れないでください。そのため、「セキュリティー侵害のコスト」には多大な間接費 (投資家の信頼損失など) が含まれる場合があります。
上記に挙げたステップを実行すると、リスク対コストの適切なトレードオフを判断できます。必然的な目標は、侵入者にとってシステムに忍び込むときの代価を、それによって得られる対価よりも大きくすると同時に、ビジネスがセキュア・システムの維持費を確実に負担できるようにすることです。(ただし、ハッカーが娯楽のためだけにシステムに侵入する場合は、この目標では対処できない可能性があります。その場合の望みは、かなりセキュアな環境を作り出して、侵入者がもっと楽なターゲットに目を向けるようにすることです。) 必要なセキュリティーのレベルは結局のところ、技術的な判断ではなくビジネス上の判断によりますが、私たちは技術者として、すべての関係者がセキュリティーの価値と重要性を理解できるようにしなければなりません。そのようなわけで、内部のアプリケーション攻撃に対する保護は除き、この記事で提案するセキュリティー強化のステップのほとんどはコストをかなり抑えたものにしています。そのため、大抵の組織はそのすべてをインプリメントできるはずです。この記事では、WebSphere Application Server 製品が本来持つ機能の枠を超えた高度で費用のかかるセキュリティー・アプローチ (認証の強化、監査、侵入検知など) は対象外とします。
セキュリティーは壮大な話題であるため、この記事でセキュリティーのすべての側面を完全に取り上げるのは不可能です。この記事はセキュリティー入門でも、WebSphere Application Server ベース・システムをセキュアにする方法のチュートリアルでもありません。それよりむしろ、WebSphere Application Server に関連して考慮する必要がある中核的な技術的問題の概要あるいはチェックリストです。この記事に記載する情報は、セキュア・エンタープライズの実現に向けた大々的な取り組みと併せて使用してください。
詳細を知りたいという読者は、「参考文献」セクションを参照してください。特に、私の Web サイトには、多少古いながらもアプリケーション・セキュリティーの基礎知識についての概要が記載されています。
ソーシャル・エンジニアリング
この記事は技術に関するものなので、セキュリティー・システムに対する技術的ソリューションに話題を絞ります。主に焦点にするのは、セキュリティーというパズルのなかの WebSphere Application Server です。とはいえ、ソーシャル・エンジニアリングの手法を使って比較的簡単にシステムのセキュリティーを侵害できることを念頭に置いておく必要はあります。つまり、アタッカーが組織で働く人間をだまして、本来はアクセスできないシステムや情報にアクセスするということです。(詳細は、「What is social engineering?」を参照してください。)
この記事の説明に関連して、ソーシャル・エンジニアリングの攻撃手法から学べる 1 つの結論は、アタッカーはソーシャル・エンジニアリングを用いてネットワーク内部から侵入する可能性があるということです。このような事実もまた、ネットワーク外部からの侵入者だけに焦点を絞ったセキュリティーでは不十分だという前述の論点を際立たせます。そのような理由から、この記事の説明は複数のレベルでのセキュリティーに焦点を当てます。各レベルでさまざまなタイプの攻撃を阻止するとともに、アタッカーに対するバリアを重ねて設けるわけです。
総合的なシステムの見解: 詳細の重要性
特定のポイントごとに推奨事項を説明する前に、セキュア・システムを作成するための基本的手法を大まかに説明させてください。基本的な考えは、あらゆるシステム境界または共有ポイントに目を向け、これらの境界や共有コンポーネントにアクセスできるアクターを検討することです。つまり、こうした境界が存在するとしたら (サブシステム内はそれなりに信頼できると仮定)、その境界を突破するために侵入者が実行可能なことは何か、あるいは何かを共有しているとしたら、侵入者が不適切にそれを共有できるかということを検討します。ほとんどの境界は明らかで、ネットワーク接続、プロセス間通信、ファイル・システム、オペレーティング・システムのインターフェースなどが挙げられますが、捕らえにくい境界もあります。例えば、あるアプリケーションが WebSphere Application Server 内の J2C リソースを使用している場合は、他のアプリケーションが同じ J2C リソースにアクセスしようとする可能性を考慮してください。これは、最初のアプリケーションと WebSphere Application Server、そして 2 つ目のアプリケーションと WebSphere Application Server の間にシステム境界が存在するために起こることです。おそらく両方のアプリケーションがこの共通リソースにアクセスできるはずです (実際、それは可能です)。これが、不適切な共有の例です。
このようにさまざまな形態がある攻撃を防ぐには、よく知られた手法を複数適用します。例えば、下位レベルのネットワーク・ベースの攻撃に対しては、暗号化とネットワーク・フィルタリングを適用します。これにより、侵入者は未許可のものを表示あるいはアクセスすることができなくなります。また、オペレーティング・システムのリソースが不正に利用されないようにするには、オペレーティング・システムが提供するメカニズムに依存します。例えば、一般ユーザー・レベルのコードでは、システム・バスにアクセスして内部通信を直接読み取れないようにします。さらに、現代のほとんどのオペレーティング・システムには、システム API に対するかなり強固な保護機能があります。残念ながら、WebSphere Application Server 環境では、これらのオペレーティング・システムの保護機能はプロセス ID に基づいて行われるため、その価値は限られます。アプリケーション・サーバーが何千ものユーザーからの要求を一度に処理することを考えると、プロセス ID に基づいた保護機能は非常に大ざっぱなコンセプトです。
上位レベルでは、厳格な認証と許可を適用します。あらゆる API、あらゆるメソッド、そしてあらゆるリソースは、何らかの形で許可を求めることになります。つまり、これらのものへのアクセスは、必要に応じて制限されるということです。そしてもちろん、強固な認証がなければ許可の価値はほとんどありません。認証は、呼び出し側の ID の識別に関係します。「強固な」という言葉を付け足したのは、簡単に偽造できる認証にはまるで価値がないからです。
適切な認証と許可が使用できない場合は、巧妙な設計と手順によって考えられる問題を防ぎます。J2C リソースはまさにこのようにして保護されています。WebSphere Application Server では J2C リソースへのアクセスの許可を行わないため、代わりに他の手法 (構成に基づく) でアプリケーションが J2C リソースを不適切に参照できないように制限しています。
ご想像のとおり、システム境界と共有コンポーネントのすべてを検討するのは難しい仕事です。そして実際、システムを保護する際にはシステムの複雑性について深く考えることになります。セキュリティーに関する最もやっかいな真実は、セキュア・システムの作成は抽象化に反するということかもしれません。すなわち、優れた抽象化の中心的原則の 1 つは、高位レベルのコンポーネントに対してコンサーン (関係性) を隠すようにするということです。それが、極めて理想的で良いこととされています。ただし残念ながら、侵入者は手加減しません。抽象化だろうと、優れた設計だろうと、彼らの関するところではありません。侵入者の目標は、どうにかしてシステムに侵入することであり、その目標を達成するために設計のあらを探します。そのため、システムのセキュリティーを検証するには、抽象化のあらゆるレベルで考えなければなりません。全体的なアーキテクチャーから最下位レベルの詳細に至るまで、すべてを徹底的に検討する必要があります。
ほんのささいな間違いが、システム全体の完全性を台無しにすることがあります。これを最も表す良い例は、バッファー・オーバーラン手法を使って C/C++ ベースのシステムを支配下に置くという手法です。この手法では基本的に、侵入者が既存のバッファーには大きすぎるストリングを渡します。するとバッファーからあふれた情報が実行中のプログラムの一部にオーバーレイし、ランタイムが本来実行してはならない命令を実行することになります。慎重にやれば、ほとんど何でもプログラムに実行させることができます。(詳細は、「Buffer Overflows -- What Are They and What Can I Do About Them?」を参照してください。) C/C++ ランタイムがどのようにメモリーを管理してプログラムを実行するかをセキュリティー・アーキテクトが十分に理解していなければ、この攻撃を識別さえできません。また、このような攻撃が存在することを理解しているとしても、この特定のセキュリティー・ホールを見つけ出すにはコードのすべての行を検討しなければなりません。
今日、これは周知の攻撃となっていますが、依然として攻撃は成功しています。その理由は、それぞれのプログラマーがほんのささいな誤った決定をして、システム全体を危険にさらしているためです。ありがたいことに、この特定の攻撃は Java™ では実行不可能のようですが、それでも一瞬たりとして、危険につながる小さなエラーは他にないと確信してはなりません。セキュリティーについて真剣に考えてください。セキュリティーは難しい課題です。
セキュリティー強化の概要
J2EE™ 仕様と WebSphere Application Server は、セキュア・システムをインプリメントするための強力なインフラストラクチャーになります。残念ながら、セキュアな WebSphere Application Server ベース・システムの作成に関連する課題をすべて認識している人は多くありません。システム作成の自由度も情報源もさまざまです。そのため人々はセキュリティーに関する問題を見過ごして、セキュアではないシステムをデプロイしがちです。そこで、このセクションでは重要な課題を要約してみようと思います。
セキュリティーの強化とは、WebSphere Application Server の構成、アプリケーションの開発、そしてその他の各種関連コンポーネントの構成を行って最大限のセキュリティーを実現するという行為です。要するに、さまざまな形態の攻撃を防ぐこと、阻止すること、あるいは和らげることを目的としています。これを効果的に行うには、攻撃の形態について考慮することが肝心です。アプリケーション・サーバーに対する基本的な攻撃方法は 4 通りあります。
J2EE ベースのシステム対する基本的な攻撃方法は、以下の 4 通りです。
-
ネットワーク・ベースの攻撃
ネットワーク・ベースの攻撃は、ネットワーク・パケットへの低位レベルのアクセスに依存し、このトラフィックを変えたり、あるいはネットワーク・パケットから情報を盗むことよってシステムに悪影響を与えようとします。
-
マシン・ベースの攻撃
この場合、侵入者は WebSphere Application Server が稼動しているマシンにアクセスします。その目的は、マシンの機能を制限して構成にダメージを与えたり、表示されるべきでないものを表示することです。
-
アプリケーション・ベースの外部攻撃
このシナリオでは、侵入者はアプリケーション・レベルのプロトコル (HTTP、IIOP、JMX、Web サービスなど) を使用して、Web ブラウザーやその他のタイプのクライアントを介してアプリケーションにアクセスします。このアクセスによって、通常のアプリケーション使用法に従わず、不適切なことを実行しようとします。重要な点は、明確に定義された API とプロトコルを使用して攻撃が行われるということです。侵入者は必ずしも会社の部外者というわけではありませんが、アプリケーションの外部からコードを実行します。このようなタイプの攻撃は、最小限のスキルで、IP 接続が利用可能な限り、遠距離から実行できるため最も危険です。
-
アプリケーション・ベースの内部攻撃
この場合の懸念は、不正なアプリケーションの危険性です。このシナリオでは、1 つの WebSphere Application Server インフラストラクチャーが複数のアプリケーションによって共有されますが、それぞれのアプリケーションは完全には信頼できません。内部攻撃に対する完璧なセキュリティーは実現不可能ですが、それぞれのアプリケーションが及ぼすダメージを制限できる手法はいくつかあります。内部攻撃は通常、「悪意」のある信頼できないコードを表すもので、大抵の場合はそれが内部攻撃の懸念事項となります。ただし、常に留意しておかなければならないのは、ハッカーがリモートから (前述の手法で) アプリケーションのセキュリティーを侵害し、それから内部攻撃という手段を用いてさらに大きな害を及ぼす可能性があるということです。
ここでは、もう 1 つの技術的攻撃の形態であるサービス妨害 (DoS) 攻撃については考慮していません。この形態の攻撃は非常に重要ですが、この記事の範囲外です。DoS 攻撃を防ぐには、アプリケーション・サーバーの機能を超えた別の手法が必要で、ネットワーク・トラフィックのモニター、レート・リミッター、侵入検出ツールなどを検討しなければなりません。
強化手段
ここからは、WebSphere Application Server インフラストラクチャーとアプリケーションを上記の 4 つの形態の攻撃から守るために行うさまざまな既知のステップを特定していきます。攻撃の形態別に情報を整理できれば理想的なのですが、残念ながら、攻撃はこの 4 種類に明確に区別されていません。複数の形態を持つ攻撃を防ぐには複数の異なる手法が役立ちます。また、1 つの攻撃が目標を達成するために複数の侵入形態を利用することもあります。最も単純な例として、ネットワーク・スニッフィングを使ってパスワードを取得し、そのパスワードでアプリケーション・レベルの攻撃を開始することがあります。そのため、ここではこうしたアクティビティーが発生する時機、またはこのような問題に関係する人の役割に基づいて、セキュリティーを強化する手段を以下の論理構造に体系化しています。
-
インフラストラクチャー
最大限のセキュリティーを目的とした WebSphere Application Server インフラストラクチャーを構成するために講じる措置。これらの措置は通常、インフラストラクチャーを構築するときに一度行われ、システム管理者だけが関わります。
-
アプリケーションの構成
アプリケーション開発者と管理者が行う措置で、デプロイメント・プロセス中に明らかになります。これらの措置は本質的にアプリケーションの設計およびインプリメンテーションを決定するもので、WebSphere Application Server 管理者が確認し、デプロイメント・プロセスの一環として (おそらく困難が伴いますが) 検証できます。このセクションには多数の手法があることからも、セキュリティーはおまけの事柄ではなく、アプリケーションの設計、開発、デプロイメントに関わる全員の責任であるということが明らかです。
-
アプリケーションの設計とインプリメンテーション
開発者と設計者が開発中に行う措置。セキュリティーに極めて重要な一方、デプロイメント・プロセスの一環としてはなかなか認められない場合があります。
-
アプリケーションの分離
これについては複雑な問題が絡むため、別途説明します。
それぞれのセクションでは、各種の手法を優先順位に従って記載します。優先順位はもちろん主観的なものですが、だいたい以下の方法で各分野内での脅威に優先順位を付けるようにしました。
- マシン・ベースの脅威は、ネットワークの脅威より可能性が低いものとします。これは、実動環境では一般的に、マシンへのアクセスは限られているためです。これがご使用の環境に当てはまらない場合、マシン・ベースの脅威の可能性は非常に高くなるため、マシンへのアクセスを制限する必要があります。
- 最も深刻な攻撃は、IP 接続だけを使ってリモートから行われます。つまり、すべての通信に認証が必要であることを意味します。
- トラフィックを保護するには暗号化が必要ですが、WebSphere Application Server の内部トラフィックの暗号化は「WebSphere Application Server の枠外」を行き交うトラフィックの暗号化よりは重要でありません。中継ネットワークのほうが、アタッカーがトラフィックをスヌープできるポイントが多いためです。
上記の手法を前述の攻撃の種類に対応させやすいように、それぞれの手法には以下のグラフィックを記載しています。
4 つの四角のそれぞれに陰影を付けて、その手法が防ぐ攻撃のタイプを示します。
-
N = ネットワーク・ベース
-
M = マシン・ベース
-
E = 外部アプリケーション・ベース
-
I = 内部アプリケーション・ベース
内部アプリケーション・ベースの攻撃は常に「外部」の攻撃手法を利用するので、E を示す場合は、I を明示的にリストすることはしません。ただし、その脆弱性が内部アプリケーション・ベースの攻撃に特有のセキュリティー・ホールになる場合には「I」をリストします。
SSL の概要
セキュア・ソケット・レイヤー (SSL) は、WebSphere Application Server セキュリティー・アーキテクチャーの重要なコンポーネントです。通信のセキュリティー保護には SSL が広範に使用されています。SSL を使用して保護するのは、HTTP トラフィック、IIOP トラフィック、LDAP トラフィック、そして SOAP トラフィックです。SSL には公開鍵と秘密鍵のペアが必要で、WebSphere Application Server ではこれらの鍵を鍵ストアに保管します。このインフラストラクチャーを保護するには SSL が非常に重要なため、少々話題をそれて、WebSphere Application Server との関連における SSL の重要な側面をいくつか取り上げます。説明は表面的な内容にとどめ、SSL を適切に構成するために必要な要点だけを記載します。
公開鍵暗号方式は基本的に公開鍵と秘密鍵のペアに基づいています。この 2 つの鍵は、暗号化において関連しています。重要な点は、これらの鍵は非対称であるということです。一方の鍵で暗号化された情報は、もう一方の鍵を使って暗号化解除できます。秘密鍵は当然、秘密です。つまり、秘密鍵は常に保護しなければなりません。他の誰かが秘密鍵にアクセスしたとすると、この鍵を身元の「証明」として使って、該当ユーザーになりすます恐れがあります。秘密鍵はパスワードのようなものですが、パスワードより変更するのが困難です。秘密鍵を持っていることが身元の証明となります。公開鍵は、鍵のペアの片割れで、他のユーザーと共有できます。
信頼できる関係者に公開鍵を配布するための安全な方法があれば、それで十分なのですが、公開鍵暗号化方式はもう一歩踏み込んで、署名付き公開鍵という考え方を導入しています。署名付き公開鍵には (人間の署名によく似た) デジタル署名があり、これによって署名者が公開鍵を保証していることを示します。署名者は、署名付き公開鍵に対応する秘密鍵を所有する関係者が、その鍵によって識別される関係者であることを保証します。このような署名付き公開鍵は証明書と呼ばれます。周知の署名者は認証局 (CA) と呼ばれます。さらに、公開鍵自体を使って公開鍵に署名することも可能で、これは自己署名証明書として知られています。自己署名証明書の安全性が認証局によって署名された証明書に劣ることはありません。自己署名証明書は管理が難しいだけのことです。それについてはこの後説明します。
図 1 に、CA を使った証明書を作成して配布する基本プロセスを示します。ここで目的としているのは、SSL でサーバー認証を行うことです。つまりサーバーが、クライアントに対してサーバー自体を識別するための証明書を所有します。クライアントは証明書を持っていないため、SSL にとっては匿名です。
図 1. サーバーの SSL 認証 - 証明書の作成と配布
上記の図を見ると、クライアントは、生成されたサーバーの公開鍵に署名した証明書を所有していなければならないことがわかります。これは信頼のために不可欠な部分です。クライアントは所有する証明書をすべて (この場合、CA 証明書も含む) 信頼しているので、CA が署名した証明書を信頼します。注目すべき点は、自己署名証明書を使用するとしたら、クライアントにおそらくすでに組み込まれている既知の CA 証明書に依存するのではなく、その自己署名証明書を各クライアントに配布する必要があるということです。これは確かに安全ですが、クライアントの数が多い場合、全クライアントに自己署名証明書すべて (サーバーごとに 1 つ) を配布するとなると管理が大変です。それよりも、多数の証明書に署名する CA 証明書を 1 つだけ配布するほうが遥かに簡単です。SSL を使用したサーバー認証については、大体そんなところです。認証後は、SSL が秘密鍵の暗号化を使用してチャネルのセキュリティーを保護しますが、詳細はこの説明の対象外です。
クライアントがサーバーに対して自己認証する場合、そのプロセスは同様ですが役割が逆になります。サーバーがクライアントを認証するためには (クライアント証明書認証と呼ばれます)、クライアントが秘密鍵とそれに対応する証明書を所有する一方、サーバーが対応する署名証明書を所有する必要があります。クライアントの自己認証については、ただそれだけのことです。ここで、必要とされていないものにお気付きですか。SSL 証明書認証は単に証明書が有効であることを判断するだけのもので、証明書が何を表すかについては関与しません。それはその後の SSL 処理の役目で、このことは、後に説明するように重要な意味があります。
要約すると、SSLは証明書認証を使用するため、SSL 接続の両方の側が鍵ストア・ファイルに適切な鍵を持っていなければなりません。SSL 鍵ストアを構成する際は、どちらの側にどの鍵が必要であるかという基本ルールを考慮してください。それによって、何が必要なのかが分かるはずです。
強力な SSL のトリック
今さっき述べたように、SSL が証明書の有効性を確認すると、SSL の視点からは認証プロセスが終了したことになります。次の処理として理想的なのは、別のコンポーネントが証明書に含まれる ID を調べ、その ID を使用して、許可を決定することです。この許可の決定は、クライアントがサーバーを信頼できるかどうかを決定することであったり (これは、Web ブラウザーが証明書に含まれる名前が Web サーバーのホスト名と同じであることを検証するときに行います)、サーバーがユーザーの名前を抽出し、その名前を使って今後許可を決定するための資格情報を作成することであったりします (これは、WebSphere Application Server がエンド・ユーザーを認証するときに行います)。残念ながら、すべてのシステムにこのような機能があるわけではありません。そこで利用できるのが、有効な証明書を制限するという人気の高い SSL の機能です。
クライアント認証を伴う前述のシナリオでは、クライアントによって提示された証明書は、サーバーが一連の信頼できる証明書に照合して有効性を確認します。有効性が確認された時点で、SSLハンドシェークが完了します。サーバー上で信頼できる署名者を制限すれば、誰が SSL ハンドシェークを完了できるかまで制限できます。自己署名証明書による極端な手段では、署名者は唯一、自己署名証明書だけという状況を作り出すことができます。すなわち、この SSL エンドポイントへの接続に使用できる有効なクライアント側の秘密鍵は 1 つしかないということです。この秘密鍵は、最初に自己署名証明書を作成したときに生成されたものです。このようにして、サーバー側のコンポーネントが許可を行わないとしても、SSL でシステムに接続できるユーザーを簡単に制限することができます。この方法は、ネットワーク・レイヤーでセキュア・トンネルを作成するのと同じことです。すべてが正しく構成されていれば、信頼できる特別なクライアントだけがこのトランスポートで接続できるようになります。これは、後で説明する WebSphere Application Server でのさまざまな状況で非常に役立ちます。
SSL の管理
すでに説明したように、WebSphere Application Server は鍵を鍵ストア・ファイルで管理します。鍵ファイルには、鍵ストアとトラスト・ストアという 2 つのタイプがあります。トラスト・ストアは従来、信頼できる署名者だけが含まれる単なる鍵ストアでしかありません。したがって、CA 証明書やその他の署名証明書はトラスト・ストアに配置し、個人情報 (秘密鍵を持つ個人証明書) は鍵ストアに配置します。
残念なことに、この単純なシステムには問題点があります。ほとんどの WebSphere Application Server は、JKS (Java Key Stores) として知られる新しい Java 定義の鍵ストア・フォーマットを使用します(実際、WebSphere Application Server の SSL 構成では 3 つの最新の鍵データベース・フォーマット、JKS、JCEKS、および PKCS12 をサポートしています)。一方、IBM HTTP Server と WebSphere Application Server Web サーバー・プラグインは、KDB フォーマット (正確に言うと、CMS フォーマット) という、それよりも古いフォーマットを使用します。JKS と KDB は機能の上では似ていますが、フォーマットには互換性がありません。この 2 つを混同しないよう気を付けてください。
IBM では鍵ストアを管理するためのツール、ikeyman を用意しています。これは非常に単純なツールで、鍵ストアの作成、自己署名証明書の生成、鍵のインポートとエクスポート、そして CA に対する証明書要求の生成を行います。鍵ストアを管理するときには、このツールを使用してください。WebSphere Application Server V5.1 では、単一の ikeyman バージョンで必要な鍵ストア・フォーマットのすべてがサポートされます。それより古いバージョンの WebSphere Application Server を使用している場合、bin ディレクトリーにある WebSphere Application Server 付属の ikeyman は KDB をサポートしません。KDB ファイルを作成するには、WebSphere Application Server とともにインストールされる GSK5 インストール・ディレクトリー内の古い ikeyman を実行する必要があります。GSK は通常、Windows™ では c:\program files\ibm\gsk5、Solaris™ では /opt/ibm/gsk5 にあります。その他のプラットフォームでも同様です。
WebSphere Application Server の SSL 構成
参考のために、SSL 構成が WebSphere Application Server でどのように機能するかを簡単に説明しておきましょう。WebSphere Application Server のサーバー・コードは、SSL ベースのトランスポートを使用するときには常に SSL 構成を使用します。つまり、HTTPS、IIOP/SSL、SSL チャネル、および LDAP/SSL はすべて、同じコードを共有して SSL 構成を管理するということです。そのため、後で SSL を構成するときに、この共通の情報が必要になる場合があります。SSL 構成は、SSL エリアのグローバル・セキュリティー・パネルから管理します。このパネルでクリックすると、該当セルに対して定義された SSL 構成のリストが表示されるので、そこで新しいユーザー用に独自の SSL 構成を追加したり、既存の構成を変更することができます。当然のことながら、既存の構成は複数のコンポーネントで共有されているので変更する際には注意が必要です。
図 2 は、SSL 構成の一例です。
図 2. SSL 構成
ここで重要な項目は、以下のとおりです。
-
Client authentication (クライアント認証)
この項目を設定すると、クライアント証明書認証を使用してインバウンド要求を認証するように WebSphere Application Server が設定されます。つまり、クライアントは証明書を提示するよう求められ、その証明書が、構成されたトラスト・ストアに指定された署名者に対して照合されることになります。その ID で何かが行われるかどうかは、プロトコルに依存します。多くの場合、WebSphere Application Server は証明書内の ID では何も行いません。これが、前述した SSL の機能がなぜそれほど役に立つかという理由です。
-
Security level (セキュリティー・レベル)
この項目は正当な理由がない限り、HIGH (デフォルト) に設定して許容される暗号を制限してください。必要な場合は、使用する暗号をピック・リストではっきりと指定できますが、通常その必要はありません。
SSL パネルの下半分では、鍵ストア・ファイルとトラスト・ストア・ファイルを指定できます。図 3 を見てください。ここでは、ファイル・システムの場所 (すべてのサーバーで同じでなければなりません)、鍵ファイルのパスワード (サーバーがファイルを暗号化解除するために使用します)、そして鍵ファイル・フォーマットを指定します。WebSphere Application Server はいくつかの標準フォーマットをサポートしますが、デフォルトは JKS です。前にも言ったように、鍵ファイルには秘密鍵が含まれ、トラスト・ファイルには署名鍵が含まれます。
図 3. SSL 構成の続き
WebSphere Application Server での SSL の基礎について説明したので、いよいよセキュリティーの真の目的、セキュア環境の作成に話題を移します。
インフラストラクチャー・ベースの予防対策
インフラストラクチャーをセキュリティー保護する際には、まず保護対象となるコンポーネントを理解する必要があります。それには脆弱性分析の場合と同じく、コンポーネントとその外部通信パスを識別するところから始めます。この分析で内部アプリケーションの脆弱性が洗い出されることはありませんが、他のほとんどすべてが明らかになります。有益なのは、標準 WebSphere Application Server トポロジーを検討し、ネットワークのリンクとプロトコルのすべてを調べることです。誰かがセキュリティーに懸念を抱いているとしたら、そのすべてのリンクを把握し、該当リンクをセキュリティー保護することに集中してください。これらのリンクは、前述の最も大まかなシステム境界を表します。図 4 を参照してください。
図 4. ネットワーク・リンクの全体像
図 4 のリンクに示した文字は、通信リンクで使用するプロトコルを表します。それぞれのプロトコルについて、以下に使用法をリストするとともに、ファイアウォールでの使いやすさについて説明します。
図 4 に示すように、典型的な WebSphere Application Server 構成には多数のネットワーク・リンクがあります。侵入者を阻止するには、それぞれのリンクでトラフィックを可能な限り保護しなければなりません。このセクションでは以降、上記で説明したインフラストラクチャーをセキュリティー保護するために必要なステップを説明します。
1. Web サーバーは WebSphere Application Server とは離して DMZ 内に配置すること
DMZ には、考慮しなければならない以下の 3 つの基本原則があります。
- 外部からのインバウンド・ネットワーク・トラフィックの着信点は DMZ 内になければなりません。ネットワークに透過的なロード･バランサー (Network Dispatcher など) は、単独ではこの要件に適合しません。
- DMZ からイントラネットへのトラフィックのタイプとオープン・ポートの数は、制限する必要があります。
- DMZ 内で稼動するコンポーネントを強化するとともに、機能と複雑さを最小限にするという原則に従わなくてはなりません。
典型的な DMZ 構成には、外部ファイアウォール、最小限の内容の DMZ ネットワーク、そして実動ネットワークを保護する内部ファイアウォールがあります。
したがって、通常は Web サーバーを DMZ 内に配置し、WebSphere Application Server アプリケーション・サーバーは内部ファイウォール内に配置します。このようにすると、Web サーバー・マシンの構成が単純になり、ソフトウェアもほとんど必要ないため理想的です。また、この Web サーバー・マシンは DMZ 内でインバウンド要求の着信点としても機能します。そのため、内部ファイウォールでオープンしなければならないポートは唯一、ターゲット・アプリケーション・サーバーのための HTTP(S) ポートだけになります。このようなステップにより、DMZ はアタッカーにとって非常に不利な場所になります。WebSphere Application Server を DMZ 内のマシンに配置した場合、WebSphere Application Server が実動ネットワークにアクセスできるようにするためには、マシンにインストールしなければならないソフトウェアが飛躍的に多くなり、内部ファイアウォールでオープンしなければならないポートも増えます。それでは、DMZ の価値が台無しにされてしまいます。
2. 実動ネットワークをイントラネットから分離すること
今日、ほとんどの組織はインターネット上の部外者をイントラネットから隔離する DMZ の価値を理解しています。その一方で、かなり多くの組織が多くの侵入者は内部にいるということを認識していません。前にも述べたように、外部の脅威だけでなく内部の脅威に対しても保護手段が必要です。信頼できない大規模インターネットから自己防衛するのと同じく、大規模で信頼できないイントラネットから実動システムを保護しなければなりません。それには、ファイアウォールを使って実動ネットワークを内部ネットワークから分離してください。このようなファイアウォールはインターネットに対するファイウォールよりは寛大ですが、それでもさまざまな形態の攻撃を阻止します。このステップと前述のステップを適用すると、図 5 に示すようなファイアウォール・トポロジーになります。ファイアウォールのポート割り当てについての詳細は、「Firewall Port Assignments in WebSphere Application Server」を参照してください。
wsadmin をファイアウォールのエッジに配置している点に注目してください。wsadmin は実動ネットワーク内 (保護されたエリア内) だけから実行するほうがいいのですが、ファイアウォールを介してwsadmin を実行することも非常に簡単だということを示すために、以下のようなトポロジーにしています。また、EJB クライアントはファイアウォールの内側にも外側にも配置できるためエッジに示しています。
図 5. 推奨されるファイアウォール構成
ここでは敢えて、単一のファイアウォールだけを示し、イントラネットに対向する完全な DMZ は示していません。これは最も一般的なトポロジーですが、実動ネットワークを非実動イントラネットから保護する完全な DMZ (内部 DMZ 内に Web サーバーを配置) も増えつつあります。そのような DMZ は確かに妥当な手段です。
3. グローバル・セキュリティーを有効にすること
デフォルトでは、WebSphere Application Server はセキュリティーを提供しません。つまり、すべてのネットワーク・リンクでは暗号化も認証も行われません。その結果、デプロイメント・マネージャーへのアクセス (Web 管理コンソールに対する HTTP、または JXM 管理ポートに対する SOAP/IIOP) を持つ任意のユーザーが、WebSphere Application Server 管理ツールを使って既存のサーバーの除去までを含めた管理操作を実行できることになります。言うまでもなく、これは大きなセキュリティーのリスクです。
このように最もありそうな形態の攻撃を防ぐには、実動環境で最低でも WebSphere Application Server グローバル・セキュリティーを有効にしなければなりません。WebSphere Application Server のグローバル・セキュリティーが有効になると、デプロイメント・マネージャーとアプリケーション・サーバー間の WebSphere Application Server の内部リンク、そして管理クライアント (Web およびコマンド・ライン) からデプロイメント・マネージャーへのトラフィックに対して暗号化と認証が行われるようになります (図 5 を参照)。この場合、何よりも管理ツールを実行する際に管理者による認証が必要になります。
 |
シングル・サインオンの有効化
LTPA (Lightweight Third Party Authentication) による WebSphere Application Server グローバル・セキュリティーを有効にする場合は必ず、シングル・サインオン (SSO) を有効にしてください。この設定により、WebSphere Application Server は LTPA cookie を作成してブラウザーに送信するため、アプリケーション・サーバーがその後の要求でユーザーの ID を記憶していられます。SSO が有効でないと WebSphere Application Server は cookie を作成しないため、要求ごとにユーザーを再認証しなければなりません。大抵の場合、これは上手くいきません。SSO を使用しないフォーム・ベースのログインでは、ログインのたびにユーザーにログイン・ページが再表示されます。これは、WebSphere Application Server はユーザーのログイン直後にそのユーザーの ID を忘れてしまうため、それ以降にログイン・ページにリダイレクトしようとしても成功しないためです。さらに重要なことには、これでは非効率的です。すべての要求でユーザーを再認証しなければならなくなるため、システムのパフォーマンスが大幅に劣化します。
ここで SWAM について触れていないのは、以下の理由により使用しないほうがいいと思うからです。
- 今後、使用が推奨されない予定であるため。
- WebSphere Application Server ND (Network Deployment) ではサポートされないため。
- セキュリティーを HTTP セッションに依存するため。HTTP セッションは安全を確保するように設計されていないので推奨できません。
|
|
グローバル・セキュリティーを有効にしてもすべてのネットワーク・リンクが保護されるわけではなく、いくつかの重要な内部リンクが保護されるだけであることに注意してください。その他のネットワーク・リンクのセキュリティー保護については、この後に説明します。また、有効にされた WebSphere Application Server セキュリティーを利用してアプリケーションを保護する方法についても説明します。
4. ブラウザーから HTTPS を使用すること
サイトが何らかの認証を行う場合、あるいはサイトで保護しなければならないアクティビティーがある場合は、ブラウザーと Web サーバーの間で HTTPS を使用してください。HTTPS を使用しないと、トラフィックが外部ネットワークを行き来する際に、パスワード、ユーザー操作、WebSphere Application Server セッション ID、LTPA セキュリティー・トークンなどの情報が侵入者に知られてしまう可能性があります。
LTPA トークンは非暗号化チャネルで送信できますが、保護を最大限にするには、暗号化したリンクで送信するのが最善の方法です。LTPA トークンが盗まれてしまうと、その有効期限が過ぎるまで、トークンを盗んだ者が該当ユーザーになりすます恐れがあります。
5. セキュアなファイル転送を構成すること
セキュリティーが有効になっていても、デプロイメント・マネージャーは引き続き、非認証プロトコルを使って構成の更新内容をノード・エージェントに伝えます。もっと具体的に言うと、ノード・エージェントは非認証ファイル転送サービスによって、デプロイメント・マネージャーから管理構成の更新を取得します。そのため、外部クライアントがデプロイメント・マネージャーに接続して任意のファイルをアップロードする可能性があります。多数のファイルがアップロードされると、オペレーティング・システムのディスク・スペースが不足し、全体的な故障につながる恐れがあります。また、理論的には複製したファイルをデプロイメント・マネージャーからノードにダウンロードすることも可能です。ただし、これらのファイルが本質的に短命で過渡的なものであれば、その可能性は低くなります。
デプロイメント・マネージャーがセル内の信頼できるサーバーからのファイル転送要求だけに応答することを確実にするには、filetransferSecured アプリケーションをインストールして、既存の非セキュア・アプリケーションと置き換える必要があります。このアプリケーションはシステム・アプリケーションであるため、普段は目立ちませんが存在することは確かです。wsadmin を使用して、このシステム・アプリケーションを除去し、新しいものをインストールします。IBM ではそのためのスクリプトを用意していますが、この記事を書いている時点では、V6 のインフォメーション・センターに記載されている手順はあまり正しくないということに注意してください (V5 または V5.1 のインフォメーション・センターには記載されていません)。filetransferSecured アプリケーションをインストールするには、以下の手順に従ってください (Windows の場合を説明しますが、UNIX® での手順も基本的に同じです)。
cd <profilehome>\bin
wsadmin.bat -user <wasadminuser> -password
<waspassword>
wsadmin>source ../../../bin/redeployFileTransfer.jacl
wsadmin>fileTransferAuthenticationOn <your cell
name> <dmgr node name> dmgr
wsadmin>$AdminConfig save |
上記は WebSphere Application Server ND 環境を前提としています。WebSphere Application Server ベースを使用している場合、サーバー名は当然、dmgr ではなく、おそらく server1 になります。
セル名とノード名が思い出せない場合は、config ディレクトリーでプロファイルを調べるとわかります。このノードはデプロイメント・マネージャーのノードであるため、名前は「CellManager」で終わっているはずです。
6. Web ベースの管理証明書が適切に検証されるように証明書を構成すること
セキュリティーを有効にして Web 管理コンソールを使用すると、Web ブラウザーが、証明書が信頼できるものではなく、ホスト名が証明書にあるホスト名と一致しないと警告するはずです。そのような場合は、図 6 と図 7 のようなメッセージが表示されます (ここでは、Mozilla Web ブラウザーを使用しています)。
図 6. 信頼できる証明書ではないことをユーザーに通知する Mozilla
図 7. 証明書にブラウザーが期待するホスト名とは異なるホスト名が指定されていることをユーザーに通知する Mozilla
上記のメッセージは、WebSphere Application Server が使用している証明書に関するセキュリティー問題がある可能性を警告しています。このような警告を防ぐには、デフォルトの鍵リングを更新するときに、管理 Web アプリケーションを実行しているマシン (ベースにあるサーバー、またはその他のエディションのデプロイメント・マネージャー) のホスト名と同じ Subject 名の証明書を生成します。これにより、2 つ目のブラウザー・エラー・メッセージを防ぐことができます。最初のメッセージを防ぐには、WebSphere Application Server 管理コンソールの既知の CA から証明書を購入するか (これはやり過ぎかもしれません)、あるいは証明書を永久的に受け入れます。このメッセージが再び表示された場合は、セキュリティー違反の兆候である可能性が高いということを覚えておいてください。システムの管理スタッフは、この警告は証明書の更新時に一度だけ発生することを認識するよう訓練されていなければなりません。それ以外のときにこの警告が発生した場合は、システムのセキュリティーが侵害されているという警告になります。
7. JNDI を保護すること
J2EE アプリケーションは JNDI を使用して、その他のアプリケーションやリソースを見つけます。そのため、WebSphere Application Server では JNDI を広範に使用しますが、JNDI 名前空間はデフォルトでセキュリティー保護されていません。すべてのユーザーに読み取りアクセス権があると同時に、すべての認証済みユーザーに読み取り/書き込みアクセス権があります。その結果、セルに対して IIOP でアクセスするクライアント (JNDI 名前空間には IIOP を介してリモートからアクセス可能) は、WebSphere Application Server レジストリー内の有効なユーザー ID とパスワードを持っていれば、名前空間をどのような方法でも変更できてしまいます。もちろん、これはかなり危険なことです。
この問題に対処するには、管理コンソールで、Environment => Naming => CORBA Naming Service Groups によって、一層限定的な管理能力を指定して、JNDI 名前空間へのアクセスを制限します。例えば、「Everyone」だけが読み取りアクセスを持ち、読み取り/書き込みアクセスは誰にも与えないように名前空間を制限することをお勧めします。このようにすると、JNDI には機密事項が一切保管されないため (パスワードがここに保管されません)、かなり安全です。侵入者がサーバーのエンドポイントなどを見分ける可能性はありますが、それ以外はほとんど考えられません。重要なのは、悪意のある更新を防ぐことです。図 8 の例では、デフォルトの ALL AUTHENTICATED (すべての認証) 付与が選択解除されていることに注目してください。
図 8. EVERYONE だけが読み取りアクセスを持つ命名許可
上記の設定によって、アタッカーが JNDI 名前空間を変更できないことが確実になります。WebSphere Application Server は常に、必要なアクセス権を自己付与するため、この設定によって独自の操作 (JNDI へのリソースの登録など) に影響を受けることはありません。JNDIに書き込むアプリケーションは失敗しますが、そのようなアプリケーションは珍しいため、この設定によって支障がでることはほとんどありません。アプリケーションに JNDI への書き込みアクセスが必要な場合は、必要なアクセス権をそのアプリケーションに付与しなければなりませんが、JNDI アクセス権は名前空間の一部だけでなく、全体に適用されることに注意してください。
8. デフォルト・メッセージングでの有効な許可を確実にすること
V6 のみ
WebSphere Application Server セキュリティーが有効になっていても、デフォルトではサービス統合バス (SIB) に有効な許可がありません。これは、WebSphere Application Server レジストリーに有効なユーザー ID とパスワードを持つ誰もが (おそらく会社内の誰もが)、任意のキューに対して任意のアクションを実行できることを意味します。これを管理コンソールで確認したり、構成することは一切できないため、wsadmin を使用することになります。メッセージング・バスの管理タスクは、wsadmin の $AdminTask コマンドで制御します。listGroupsInBusConnectorRole を使用している場合は、デフォルトですべての認証ユーザーにバスへのアクセスがあることが一目でわかります。これでは、あまり安全ではありません。
直ちに、removeGroupFromBusConnectorRole タスクと addUserToBusConnectorRole/addGroupToBusConnectorRole タスクを使用して修正することをお勧めします。例えば、以下のコマンドを使用します。
wsadmin>$AdminTask removeGroupFromBusConnectorRole {-bus mySIB -group AllAuthenticated}
wsadmin>$AdminTask addUserToBusConnectorRole {-bus mySIB -user bususeryoudetermine}
許可を構成して接続可能な関係者を制限したら、当然、クライアント・コンポーネント (MDB、JMS など) が適切な ID を使って認証するようにする必要があります。
9. WebSphere MQ メッセージングへのアクセスを制限すること
WebSphere MQ をメッセージング・プロバイダーとして使用している場合は、他の手法でキューの許可に対処しなければなりません。クライアント/サーバー・モードを使用している場合、WebSphere MQ はデフォルトではユーザー認証を行いません (バインディング・モードは、マシン内の認証を処理するプロセスに依存します)。実際、WebSphere MQ の接続ファクトリーでユーザー ID とパスワードを指定しても、WebSphere MQ はこれらの値を無視します。
この問題に対処する 1 つの方法は、独自のカスタム WebSphere MQ 認証プラグインを WebSphere MQ サーバー側にインプリメントして、WebSphere Application Server が送信するユーザー ID とパスワードを検証することです。あるいは、それより単純な手法として、クライアント認証で SSL を使用するように WebSphere MQ を構成し、WebSphere Application Server サーバーのみに WebSphere MQ との接続に有効な証明書を所有させることもできます (前述の SSL クライアント認証のトリックを使用)。
10. WebSphere Application Server と LDAP 間のリンクを暗号化すること
LDAP レジストリーを使用している場合、WebSphere Application Server はユーザーのパスワードを標準 ldap_bind で検証します。それには、WebSphere Application Server がユーザーのパスワードを LDAP サーバーに送信する必要があります。その要求が暗号化されていないと、ハッカーがネットワーク・スニファーによってユーザー認証のパスワード (管理パスワードも含め) を盗む恐れがあります。大抵の LDAP ディレクトリーは SSL による LDAP をサポートするため、これを使用するように WebSphere Application Server を構成することができます。LDAP ユーザー・レジストリー・パネル (図 9 を参照) で、SSL を使用するオプションにチェック・マークを付けてから、LDAP ディレクトリーに適切な SSL configuration を構成してください。LDAP サーバーの証明書用の署名鍵は、おそらくトラスト・ストアに配置する必要があります。既存の SSL の使用方法に支障を与えないようにするには、LDAP 専用の SSL configuration (SSL 構成) を新しく作成するのが最善の方法です。
図 9. LDAP SSL の有効化
カスタム・レジストリーを使用する場合は、何らかの利用可能なメカニズムを使って、このトラフィックを保護する必要があります。
11. デフォルト鍵ファイルを作成すること
|
デフォルト鍵リングを変更する際の考慮事項
デフォルト証明書を変更する際には、念頭に置いておかなければならないことが 1 つあります。それは、SSL ベースのシステムと同じく、サーバーによって提示された証明書をクライアントが検証できるようにしなければならないということです。それにはクライアントが、サーバーによって提示された証明書の署名者に対する署名証明書を保持する必要があります。
出荷時の WebSphere Application Server は、wsadmin や Tivoli™ Performance Viewer (V6 より前のバージョンに対応) などの IBM 提供のツールを含め、Java クライアントならびにカスタム作成のクライアントを対象にしています。ただし、新しい秘密鍵と特定の署名者が署名した証明書を使うようにサーバーの鍵ファイルを更新する場合は、Java クライアントがこれらの証明書を検証できることを確実にしなければなりません。そのためには、クライアントのトラスト・ファイルを更新して、新しいサーバー証明書を発行した関係者の署名者証明書を含めます。つまり、WebSphere Application Server 管理クライアントなどの Java クライアントに、新しいクライアントの鍵ファイルが必要になる可能性があるということです。既知の CA (Verisign など) から発行された証明書を使用する場合には、その必要はありません。デフォルトのクライアント鍵リングには最も一般的な公開 CA からの署名証明書がすでに含まれているためです。WebSphere Application Server の内部通信用に CA から証明書を買うのはお勧めできません。Java クライアントがほとんどないのであれば、ただ単に自己署名証明書を生成して、少数のクライアント鍵リングを手動で更新したほうが簡単で安上がりです。
この問題は、Web サーバーとアプリケーション・サーバー間の通信にも影響します。Web サーバー・プラグインはデフォルトで HTTPS をサポートするため、Web サーバー・プラグインの鍵リングには WebSphere Application Server のサンプル署名証明書のコピーが含まれています。デフォルトの鍵リングを変更する際には忘れずに、Web サーバー・プラグインの鍵リングを更新して新しい証明書を含めてください。
|
|
前述したように、WebSphere Application Server セキュリティーを有効にすると、ほとんどの内部トラフィックが SSL を使用して各種の形態のネットワーク攻撃から内部トラフィックを保護するようになります。ただし、SSL 接続を確立するには、サーバーが証明書とそれに対応する秘密鍵を所有していなければなりません。初期インストール・プロセスを簡単にするため、WebSphere Application Server にはサンプル秘密鍵が含まれるサンプル鍵ファイルが付属しています。この「秘密」鍵は、販売される WebSphere Application Server のすべてのコピーに含まれているため、それほど秘密ではありません。この鍵ファイルの名前である DummyServerKeyFile を見ても、それは明らかです。
自分の環境を保護するには、通信用の独自の秘密鍵と証明書を作成しなければなりません。この作業はすべて、ikeyman ツールを使用して行います。ikeyman を使用して、新しい鍵ストアとトラスト･ストアを作成し、次に既存の SSL 構成を更新してこれらの新しいファイルを使用するようにします。詳細は、WebSphere Application インフォメーション・センターおよび WebSphere Application Security 6.0 Security Redbook を参照してください。
新しい鍵ストアとトラスト･ストアを作成する際には、トラスト・ストアに配置するすべての署名者は信頼に関するステートメントであることを忘れないでください。その署名者を信頼してシステム内のプリンシパルを識別することになります。複数の署名者を信頼する場合、証明書とユーザー ID のマッピング方法によっては複数の署名者が同一のユーザーと思われる証明書を作成してしまうという極めて現実的なリスクが付きものです。クライアント認証に証明書を使用しているとしたら、このリスクを減らすため、トラスト･ストアの署名者の数をできるだけ少なくしてください。
証明書について説明しているところですが、ここで本筋からそれて、証明書の有効期限という重大な点について簡単にふれておきます。WebSphere Application Server 証明書の有効期限が切れると、WebSphere Application Server が機能しなくなり、通信が一切不可能になります。そのため、ここで推奨するように、新しい証明書を作成する際には必ず、カレンダーで有効期限の日付にマークを付けてください。このアドバイスに従わずにデフォルト鍵を使用するとしても、同様に有効期限はあります。証明書の有効期限について事前に計画を立て、その期限が来る前に新しい証明書を取得または生成してください。
12. Web サーバー・ホストを強化すること
前に推奨した標準トポロジーに従っている場合は、Web サーバーは DMZ 内で稼動していることになります。DMZ は考えられる侵入者に対する最前線の防御となるため、このサーバーを強化するには特別な注意が必要です。
この記事では Web サーバーの強化についての詳細を説明しませんが、オペレーティング・システムの強化、ロード対象の Web サーバー・モジュールの制限、そしてその他の Web サーバーの構成手順などは十分検討しなければなりません。詳細は、『Linuxサーバセキュリティ』を参照してください。
Web サーバーの管理 (V6 のみ）
Web サーバーを強化する際、WebSphere Application Server の場合に特有の考慮事項が 1 つあります。それは、WebSphere Application Server 管理インフラストラクチャーで Web サーバーを管理することが可能だということです。これは使いやすさの点からは適切なように思えますが、セキュリティーに関しては重大な問題が持ち上がります。Web サーバーの管理には 2 通りの方法があります。1 つは、管理対象ノードを使用する方法、そしてもう 1 つはネイティブ IBM HTTP Server (IHS) Admin Server を使用する方法です。
管理対象ノードを使用するには、ノード・エージェントを Web サーバー・マシン (通常は DMZ 内) に配置し、このエージェントを WebSphere Application Server セルの一部にする必要があります。これはセキュリティーの観点からは絶対に許容できないことなので、DMZ が一切必要ないという珍しい場合を除き、この方法は使用すべきではありません。許容されない理由は、次の 2 つです。
- ノード・エージェントは完全にセルの機能メンバーであり、完全な管理権限を持ちます。ノード・エージェントが DMZ 内で危険にさらされると、セル全体が危険にさらされることになります。
- WebSphere Application Server は大規模で強力な製品であるため、この記事で説明するように強化することは困難です。このような製品は DMZ 内には属しません。
2 番目の方法では、IBM HTTP Server を使用して HTTP Admin Server を構成する必要があります。このシナリオでは、デプロイメント・マネージャーが、Web サーバー・ホスト上で稼動する HTTP Admin Server に管理要求を送信します。妥当な方法のように思えますが、このようなタイプのトラフィックでさえ懸念する人もいます。
13. 実動環境でサンプルを実行しないこと
WebSphere Application Server には、製品のさまざまな部分を実演する優れたサンプルがいくつか付属しています。これらのサンプルは、実動環境で使用するためのものではありません。重大なセキュリティー上のリスクをもたらすので、実動環境ではサンプルを実行しないでください。特に、showCfg およびスヌープするサーブレットは、システムに関する非常に多くの情報を部外者に提供する恐れがあります。この情報はまさに、潜在的侵入者に与えたくないタイプのものです。server1 (サンプルを含む) を実動環境で実行しなければ、このような事態は簡単に防げます。WebSphere Application Server ベースを使用している場合は、server1 からサンプルを除去しなければなりません。
14. Web サーバーのトラスト境界を検討すること
環境を構成する際には常に、トラスト境界について慎重に検討してください。不幸にも、トラスト境界を不適切に拡張することで、誤ってごく簡単に脆弱なセキュア環境を作れてしまいます。通常、WebSphere Application Server は強力なメカニズムを使用して独自の認証を行います。その一方で、WebSphere Application Server がインフラストラクチャー内の別のコンポーネントを信頼して認証を行うことも可能です。正しく認証を行えば問題は何もありませんが、不適切に認証が行われたり、十分に考慮されていないと、安全でないシステムになったり、そうでなくてもトラスト関係がほとんど不明のシステムになってしまいます。言い古された格言を思い出してください。セキュリティーの強さは、そのなかの最も弱いリンクによって決まります。WebSphere Application Server のトラスト・ドメインは慎重に制限してください。
WebSphere Application Server のトラスト・ドメインは通常、TAI、ログイン・モジュール、またはその他のカスタム・コードを作成すると明示的に拡張されるものですが、証明書を使用するときなどにも暗黙的に拡張される場合があります。
Web クライアントに対してクライアント証明書の認証を行っている場合は、Web サーバーがトラスト・ドメインの一部になるということを認識してください。WebSphere Application Server プラグインはユーザーの証明書に関する情報をアプリケーション・サーバーに転送します。アプリケーション・サーバーは、Web サーバーが正しい証明書認証を行ったと信頼せざるを得ません。WebSphere Application Server が SSL 認証ハンドシェークを繰り返すことは不可能です (これを行えるのは、SSL ターミネーターのみです)。そのため、Web サーバーのセキュリティーが侵害されることによって WebSphere Application Server のセキュリティーが完全に侵害されます。
さらに、Web サーバーに対してクライアント証明書認証を行っている場合、WebSphere Application Server は Web サーバーを完全に信頼することになるため、証明書の情報を偽造するという攻撃を防ぐには Web サーバーとアプリケーション・サーバーの間に認証済み HTTPS を構成する必要があります。次の話題はこれに関連します。
15. Web サーバーと WebSphere Application Server 間の HTTP リンクの認証を検討すること
WebSphere Application Server の Web サーバー・プラグインは、Web サーバーからの要求をターゲット・アプリケーション・サーバーに転送します。デフォルトでは、Web サーバーへのトラフィックが HTTPS を使用している場合、プラグインは自動的に HTTPS を使用して要求をアプリケーション・サーバーに転送して機密性を保護します。
さらに用心のために、(小規模な HTTP リスナーが組み込まれた) アプリケーション・サーバーを構成して、既知の Web サーバーからの要求しか許容しないようにすることもできます。これにより、Web サーバーの前面あるいは内部のセキュリティーをバイパスするさまざまな奇襲を防ぐことになり、信頼できるネットワーク・パスが作られます。このような事態は起こりそうにありませんが、それでも可能性はあります。以下のような例があります。
- 認証プロキシー・サーバーが、ユーザー ID を HTTP ヘッダーとして認証情報なしで送信したとします。Web コンテナーに直接アクセスできる侵入者は同じヘッダーを提供するだけで、誰にでもなりすますことができます。Tivoli Access Manager WebSEAL には、このような弱点はありません。
- Web サーバーに対してクライアント証明書の認証を行っているとします。この場合、WebSphere Application Server プラグインは Web サーバーからの証明書情報をアプリケーション・サーバーに転送し、このサーバーを信頼します。侵入者は有効な証明書を表明して誰かになりすますことができるため、クライアント証明書の使用中は侵入者による Web コンテナーへの直接アクセスによって、WebSphere Application Server セキュリティーが完全に侵害されます。
Web サーバーからアプリケーション・サーバーへの信頼できるネットワーク・パスを作成するには、アプリケーション・サーバーの Web コンテナーの SSL 構成でクライアント認証が使用されるように構成します。確実にクライアント認証が使用されるようにしたら、信頼できる Web サーバーしか Web コンテナーにアクセスできないようにする必要があります。それには SSL トリックを適用して、アクセスできる関係者を制限してください。この場合、具体的には以下を行います。
- ikeyman を使用して、Web コンテナー用の鍵ストアとトラスト・ストアおよび Web Server プラグイン用の鍵ストアを作成します。
- トラスト・ストアを含め、すべての鍵ストアから既存の署名証明書をすべて削除します。この時点で、鍵ストアを使って証明書を検証することはできなくなりますが、これは意図的なことです。
- 2 つの鍵ストアに自己署名証明書を作成し、証明書だけをエクスポートします (秘密鍵はエクスポートしません)。
- Web コンテナーの鍵ストアからエクスポートした証明書をプラグインの鍵ストアにインポートします。Web コンテナーのトラスト・ストアには、プラグインの証明書をインポートします。これで、それぞれの側に署名証明書が 1 つだけが含まれることになります。つまり、検証できるのは唯一、ピアに作成した自己書名証明書だけです。
- 新しく作成した鍵ストアを Web コンテナーと Web サーバー・プラグインにインストールします。
16. 秘密鍵を保護すること
WebSphere Application Server は、秘密鍵のセットを複数管理しています。なかでも最も重要なのは、内部通信用の主要鍵ストア、そしてWeb サーバーとアプリケーション・サーバー間の通信に使用される鍵ストアです。これらの秘密鍵は秘密のままとし、共有してはいけません。秘密鍵の保管場所はコンピューターのファイル・システムであるため、これらのファイル・システムは慎重に保護する必要があります。鍵ストア内の情報は機密事項なので、共有ネットワークがアクセス可能なファイル・システムに配置することはお勧めできません。
また、これらの鍵が誤って共有されないように十分注意してください。例えば、実動環境とそれ以外の環境で同じ鍵を使用することは禁物です。開発マシンとテスト・マシンおよびそれぞれの秘密鍵にアクセスできる人は大勢いるからです。実動鍵は慎重に守ってください。
17. TAI は慎重に構成して使用すること
WebSphere Application Server が Web SSO プロキシー・サーバー (Tivoli Access Manager WebSEAL など) からの既存の認証情報を認識できるようにするためによく使用されるのは TAI (トラスト・アソシエーション・インターセプター) です。通常はそれで問題ありませんが、TAI を開発、選択、そして構成する際には注意してください。TAI はトラスト・ドメインを拡張します。WebSphere Application Server は TAI および TAI が信頼するものを何でも信頼するようになります。そのため、TAI が不適切に開発または構成されると、WebSphere Application Server のセキュリティーが完全に危険にさらされる可能性があります。TAI を独自に開発する場合は、要求で渡されたパラメーターを TAI が慎重に検証すること、そしてその検証がセキュアな方法で行われることを確実にしてください。HTTP ヘッダー内のユーザー名を単純にそのまま受け入れるような愚かな TAI を目にしたことがあります。WebSphere Application Server で受信するすべてのトラフィックが確実に認証プロキシー経由で送信されるようにされていなければ、これでは何の意味もありません。HTTP ヘッダーは偽造が可能なため、例えば前述の手法を使用すれば、認証プロキシーが常にクライアントによって設定された HTTP ヘッダーをオーバーライドするようになります。
WebSEAL TAI 構成
|
TAI バージョンについての注意
相互 SSL 認証は、WebSphere Application Server V5.1.1 以降に含まれる、TAMTrustAssociationInterceptorPlus というクラス名の新しい WebSEAL TAI ではサポートされていません。WebSphere Application Server では今でも相互 SSL を構成できますが (これが役に立つ場合はよくあります)、TAI ではこれを受け入れません。新しい TAI では、WebSEAL のパスワード・ベースの認証を使用する必要があります。以前の TAI (WebSealTrustAssociationInterceptor) は引き続き含まれているので、必要に応じて使用できます。
|
|
慎重に構成することの重要性を明確にするため、IBM 提供の WebSEAL TAI について具体的に説明しますが、いずれの TAI も慎重な設計および構成でセキュアにする必要があります。セキュアな構成を作るには、WebSphere Application Server と Tivoli Access Manager WebSEAL のトラスト関係を適切に構成することが不可欠です。また、そのようなセキュア構成を実現するには、WebSphere Application Server と WebSEAL の両方で対策を講じなければなりません。つまり、WebSphere Application Server 内で Web コンテナー構成と WebSEAL TAI 構成の両方を適切に設定する必要があります。
WebSphere Application Server 内の WebSEAL TAI は WebSEAL からの ID 表明を受け入れるため、この 2 つの製品間のトラスト関係は極めて重要です。このリンクのセキュリティーが侵害されると、侵入者が任意の ID を表明してインフラストラクチャーのセキュリティーを完全に侵害することが可能になります。WebSphere Application Server と WebSEAL のトラスト関係を確立するメカニズムは、相互 SSL 認証またはパスワード･ベース認証のいずれかです。いずれのメカニズムもセキュア環境内では適切ですが、それぞれを適切に構成しないと、重大なセキュリティー侵害が発生する恐れがあります。いずれの場合も、WebSEAL は HTTP 要求でエンド・ユーザーのユーザー ID を iv-user ヘッダーとして送信します。2 つの構成の違いは、WebSEAL がアプリケーション・サーバーに対してどのように自己証明を行うかという点です。
WebSEAL パスワード構成
パスワード認証が使用されている場合、WebSEAL はそのユーザー ID とパスワードを基本 auth ヘッダーとして HTTP 要求で送信します (ユーザーのユーザー ID は、iv-user ヘッダー内にあります)。パスワード・ベースの認証は、2 箇所で構成します。まず TAM WebSEAL を構成して、そのユーザー ID とパスワードを構成対象のジャンクション用のアプリケーション･サーバーに送信するようにします。このパスワードはもちろん秘密なので、慎重に保護しなければなりません。WebSEAL TAI はパスワードを受信すると、レジストリーと照合して検証します。
一方、微妙で見過ごしやすいことが 1 つあります。それは、LoginId プロパティーが WebSEAL プロパティーで設定されていないと、TAI は WebSEAL から送信されたユーザー ID とパスワードの組み合わせを検証し、有効なユーザー ID とパスワードの組み合わせであればそれを信頼するという点です。つまり、有効なユーザー ID とパスワードの組み合わせを知っていれば誰でも WebSphere Application Server に接続してユーザーの ID を表明できるため、セキュアな構成とは言えません。LoginId プロパティーを指定すれば、WebSEAL TAI は基本 auth ヘッダー内のインバウンド・ユーザー ID を無視し、LoginId と WebSEAL パスワードの組み合わせを検証します。その場合、WebSEAL から送信される (おそらく厳密に保護された秘密の) 有効なパスワードは 1 つだけとなります。もちろん、秘密のパスワードが平文で送信されないようにするため、WebSEAL とアプリケーション・サーバー間の SSL を構成する必要があります。
WebSEAL mutualSSL 構成
相互 SSL を構成するには、以下の非常に重要な 3 つのステップが必要となります。
- WebSEAL が SSL を使用して WebSphere Application Server と通信するように構成します。この SSL 構成には、アプリケーション・サーバーの Web コンテナーにしか知らされないクライアント証明書を含めます。
- アプリケーション・サーバーの Web コンテナーがクライアント証明書認証を行うように構成します。また、Web コンテナーのトラスト・ストアを変更して、WebSEAL が使用するクライアント証明書だけが含まれるようにします。このステップは非常に重要です。なぜなら、これによって、アプリケーション・サーバーの Web コンテナーに対する要求が WebSEAL からだけ送信され、侵入者からは送
| 
