IBM WebSphere 開発者向け技術ジャーナル: WebSphere Application Server V6 高度なセキュリティーへの強化 -- パート 1

セキュリティー強化の概要とその取り組み方法

セキュリティーを構成するのは、ネットワークのエッジで外部から保護するファイアウォールだけではありません。セキュリティーは、システムをできる限り適切に強化することを目的とした、困難で複雑な一連の措置と手順です。この記事は、一般的なセキュリティーのさまざまな側面を取り上げるとともに、IBM® WebSphere® Application Server セキュリティー・アーキテクチャーの詳細と WebSphere Application Server 環境の強化について説明する 2 部構成のパート 1 です。

Keys Botzum, Senior Technical Staff Member , EMC

Keys Botzum 氏IBM Software Services for WebSphere の上級テクニカル・スタッフ・メンバーです。大規模分散システムの設計に 10 年以上携わっており、セキュリティーの専門家でもあります。使用経験のある分散テクノロジーは、Sun RPC、DCE、CORBA、AFS、DFS など多岐にわたります。最近は、J2EE および関連テクノロジーの研究を行っています。Stanford University でコンピューター・サイエンスの修士号を取得しており、Carnegie Mellon University で応用数学/コンピューター・サイエンスの理学修士号を取得しています。 Botzum 氏は WebSphere および WebSphere セキュリティーに関する論文を多数出版している他、記事や発表も http://www.keysbotzum.com ならびに IBM developerWorks WebSphere に掲載されています。『IBM WebSphere: Deployment and Advanced Configuration』(Bill Hines との共著) の著者でもあります。


developerWorks
        プロフェッショナル著者レベル

2005年 12月 07日

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 認証 - 証明書の作成と配布
サーバーの 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 構成
SSL 構成

ここで重要な項目は、以下のとおりです。

  • Client authentication (クライアント認証)
    この項目を設定すると、クライアント証明書認証を使用してインバウンド要求を認証するように WebSphere Application Server が設定されます。つまり、クライアントは証明書を提示するよう求められ、その証明書が、構成されたトラスト・ストアに指定された署名者に対して照合されることになります。その ID で何かが行われるかどうかは、プロトコルに依存します。多くの場合、WebSphere Application Server は証明書内の ID では何も行いません。これが、前述した SSL の機能がなぜそれほど役に立つかという理由です。

  • Security level (セキュリティー・レベル)
    この項目は正当な理由がない限り、HIGH (デフォルト) に設定して許容される暗号を制限してください。必要な場合は、使用する暗号をピック・リストではっきりと指定できますが、通常その必要はありません。

SSL パネルの下半分では、鍵ストア・ファイルとトラスト・ストア・ファイルを指定できます。図 3 を見てください。ここでは、ファイル・システムの場所 (すべてのサーバーで同じでなければなりません)、鍵ファイルのパスワード (サーバーがファイルを暗号化解除するために使用します)、そして鍵ファイル・フォーマットを指定します。WebSphere Application Server はいくつかの標準フォーマットをサポートしますが、デフォルトは JKS です。前にも言ったように、鍵ファイルには秘密鍵が含まれ、トラスト・ファイルには署名鍵が含まれます。

図 3. SSL 構成の続き
SSL 構成の続き

WebSphere Application Server での SSL の基礎について説明したので、いよいよセキュリティーの真の目的、セキュア環境の作成に話題を移します。

インフラストラクチャー・ベースの予防対策

インフラストラクチャーをセキュリティー保護する際には、まず保護対象となるコンポーネントを理解する必要があります。それには脆弱性分析の場合と同じく、コンポーネントとその外部通信パスを識別するところから始めます。この分析で内部アプリケーションの脆弱性が洗い出されることはありませんが、他のほとんどすべてが明らかになります。有益なのは、標準 WebSphere Application Server トポロジーを検討し、ネットワークのリンクとプロトコルのすべてを調べることです。誰かがセキュリティーに懸念を抱いているとしたら、そのすべてのリンクを把握し、該当リンクをセキュリティー保護することに集中してください。これらのリンクは、前述の最も大まかなシステム境界を表します。図 4 を参照してください。

図 4. ネットワーク・リンクの全体像
ネットワーク・リンクの全体像

図 4 のリンクに示した文字は、通信リンクで使用するプロトコルを表します。それぞれのプロトコルについて、以下に使用法をリストするとともに、ファイアウォールでの使いやすさについて説明します。

  • H = HTTP トラフィック

    • 使用法: ブラウザーと Web サーバー間、Web サーバーとアプリケーション・サーバー間、および管理 Web クライアント
    • ファイアウォール・フレンドリー
  • W = WebSphere Application Server 内部通信

    • 使用法: 管理クライアント、および WebSphere Application Server 内部サーバーの管理トラフィック。WebSphere Application Server 内部通信では、次のサーバー・プロトコルのいずれかを使用することに注意してください。
      • RMI/IIOP または SOAP/HTTP: 管理クライアント・プロトコルは構成可能
      • ファイル転送サービス (dmgr とノード・エージェント間): HTTP(S) を使用
      • DCS (Distributed Consistency Service) RMM (Reliable Multicast Messaging): プライベート・プロトコルを使用。メモリー間の複製、ステートフル・セッション EJB、動的キャッシュ、および高可用性マネージャーに使用されます。
    • SOAP/HTTP ファイアウォール・フレンドリー。DCS がファイアウォール・フレンドリーになる場合もあります。
  • I = RMI/IIOP 通信

    • 使用法: EJB クライアント (スタンドアロンおよび Web コンテナー)
    • 動的ポートと組み込み IP アドレス (NAT (ネットワーク・アドレス変換) を実行するファイアウォールに干渉する可能性がある) のため、一般的にファイアウォールに不都合。
  • M = SIB メッセージング・プロトコル

    • 使用法: JMS クライアントとメッセージング・エンジン間
    • プロトコル: 独自仕様
    • 使用ポートを修正可能であるためファイアウォール・フレンドリー。NAT ファイアウォールには不都合な可能性があります。
  • MQ = MQ プロトコル

    • 使用法: WebSphere MQ クライアント (実際のクライアントおよびアプリケーション・サーバー)
    • プロトコル: 独自仕様
    • ファイアウォールを実現可能 (多数のポートを検証する必要があります)。WebSphere MQ サポート・パック MA86 を参照。
  • L = LDAP 通信

    • 使用法: レジストリー内にあるユーザー情報の WebSphere Application Server 検証
    • プロトコル: LDAP RFC の定義に従ってフォーマット設定された TCP ストリーム
    • ファイアウォール・フレンドリー
  • J = ベンダーの JDBC ドライバーを介した JDBC データベース通信

    • 使用法: アプリケーションの JDBC アクセス、および WebSphere Application Server セッションのデータベース・アクセス。
    • プロトコル: ネットワーク・プロトコルは各データベースに専有
    • ファイアウォールについてはデータベースに依存 (一般的にファイウォール・フレンドリー)
  • S = SOAP

    • 使用法: SOAP クライアント
    • プロトコル: 通常は SOAP/HTTP
    • SOAP/HTTP の場合はファイアウォール・フレンドリー

図 4 に示すように、典型的な WebSphere Application Server 構成には多数のネットワーク・リンクがあります。侵入者を阻止するには、それぞれのリンクでトラフィックを可能な限り保護しなければなりません。このセクションでは以降、上記で説明したインフラストラクチャーをセキュリティー保護するために必要なステップを説明します。

1. Web サーバーは WebSphere Application Server とは離して DMZ 内に配置すること
attack code

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. 実動ネットワークをイントラネットから分離すること
attack code

今日、ほとんどの組織はインターネット上の部外者をイントラネットから隔離する DMZ の価値を理解しています。その一方で、かなり多くの組織が多くの侵入者は内部にいるということを認識していません。前にも述べたように、外部の脅威だけでなく内部の脅威に対しても保護手段が必要です。信頼できない大規模インターネットから自己防衛するのと同じく、大規模で信頼できないイントラネットから実動システムを保護しなければなりません。それには、ファイアウォールを使って実動ネットワークを内部ネットワークから分離してください。このようなファイアウォールはインターネットに対するファイウォールよりは寛大ですが、それでもさまざまな形態の攻撃を阻止します。このステップと前述のステップを適用すると、図 5 に示すようなファイアウォール・トポロジーになります。ファイアウォールのポート割り当てについての詳細は、「Firewall Port Assignments in WebSphere Application Server」を参照してください。

wsadmin をファイアウォールのエッジに配置している点に注目してください。wsadmin は実動ネットワーク内 (保護されたエリア内) だけから実行するほうがいいのですが、ファイアウォールを介してwsadmin を実行することも非常に簡単だということを示すために、以下のようなトポロジーにしています。また、EJB クライアントはファイアウォールの内側にも外側にも配置できるためエッジに示しています。

図 5. 推奨されるファイアウォール構成
推奨されるファイアウォール構成

ここでは敢えて、単一のファイアウォールだけを示し、イントラネットに対向する完全な DMZ は示していません。これは最も一般的なトポロジーですが、実動ネットワークを非実動イントラネットから保護する完全な DMZ (内部 DMZ 内に Web サーバーを配置) も増えつつあります。そのような DMZ は確かに妥当な手段です。

3. グローバル・セキュリティーを有効にすること
attack code

デフォルトでは、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 について触れていないのは、以下の理由により使用しないほうがいいと思うからです。

  1. 今後、使用が推奨されない予定であるため。
  2. WebSphere Application Server ND (Network Deployment) ではサポートされないため。
  3. セキュリティーを HTTP セッションに依存するため。HTTP セッションは安全を確保するように設計されていないので推奨できません。

グローバル・セキュリティーを有効にしてもすべてのネットワーク・リンクが保護されるわけではなく、いくつかの重要な内部リンクが保護されるだけであることに注意してください。その他のネットワーク・リンクのセキュリティー保護については、この後に説明します。また、有効にされた WebSphere Application Server セキュリティーを利用してアプリケーションを保護する方法についても説明します。

4. ブラウザーから HTTPS を使用すること
attack code

サイトが何らかの認証を行う場合、あるいはサイトで保護しなければならないアクティビティーがある場合は、ブラウザーと Web サーバーの間で HTTPS を使用してください。HTTPS を使用しないと、トラフィックが外部ネットワークを行き来する際に、パスワード、ユーザー操作、WebSphere Application Server セッション ID、LTPA セキュリティー・トークンなどの情報が侵入者に知られてしまう可能性があります。

LTPA トークンは非暗号化チャネルで送信できますが、保護を最大限にするには、暗号化したリンクで送信するのが最善の方法です。LTPA トークンが盗まれてしまうと、その有効期限が過ぎるまで、トークンを盗んだ者が該当ユーザーになりすます恐れがあります。

5. セキュアなファイル転送を構成すること
attack code

セキュリティーが有効になっていても、デプロイメント・マネージャーは引き続き、非認証プロトコルを使って構成の更新内容をノード・エージェントに伝えます。もっと具体的に言うと、ノード・エージェントは非認証ファイル転送サービスによって、デプロイメント・マネージャーから管理構成の更新を取得します。そのため、外部クライアントがデプロイメント・マネージャーに接続して任意のファイルをアップロードする可能性があります。多数のファイルがアップロードされると、オペレーティング・システムのディスク・スペースが不足し、全体的な故障につながる恐れがあります。また、理論的には複製したファイルをデプロイメント・マネージャーからノードにダウンロードすることも可能です。ただし、これらのファイルが本質的に短命で過渡的なものであれば、その可能性は低くなります。

デプロイメント・マネージャーがセル内の信頼できるサーバーからのファイル転送要求だけに応答することを確実にするには、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 ベースの管理証明書が適切に検証されるように証明書を構成すること
attack code

セキュリティーを有効にして Web 管理コンソールを使用すると、Web ブラウザーが、証明書が信頼できるものではなく、ホスト名が証明書にあるホスト名と一致しないと警告するはずです。そのような場合は、図 6 と図 7 のようなメッセージが表示されます (ここでは、Mozilla Web ブラウザーを使用しています)。

図 6. 信頼できる証明書ではないことをユーザーに通知する Mozilla
信頼できる証明書ではないことをユーザーに通知する Mozilla

図 7. 証明書にブラウザーが期待するホスト名とは異なるホスト名が指定されていることをユーザーに通知する Mozilla

Figure 7. Mozilla informing the user that the certificate is specifying a different hostname than the browser is expecting

上記のメッセージは、WebSphere Application Server が使用している証明書に関するセキュリティー問題がある可能性を警告しています。このような警告を防ぐには、デフォルトの鍵リングを更新するときに、管理 Web アプリケーションを実行しているマシン (ベースにあるサーバー、またはその他のエディションのデプロイメント・マネージャー) のホスト名と同じ Subject 名の証明書を生成します。これにより、2 つ目のブラウザー・エラー・メッセージを防ぐことができます。最初のメッセージを防ぐには、WebSphere Application Server 管理コンソールの既知の CA から証明書を購入するか (これはやり過ぎかもしれません)、あるいは証明書を永久的に受け入れます。このメッセージが再び表示された場合は、セキュリティー違反の兆候である可能性が高いということを覚えておいてください。システムの管理スタッフは、この警告は証明書の更新時に一度だけ発生することを認識するよう訓練されていなければなりません。それ以外のときにこの警告が発生した場合は、システムのセキュリティーが侵害されているという警告になります。

7. JNDI を保護すること
attack code

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 だけが読み取りアクセスを持つ命名許可
EVERYONE だけが読み取りアクセスを持つ命名許可

上記の設定によって、アタッカーが JNDI 名前空間を変更できないことが確実になります。WebSphere Application Server は常に、必要なアクセス権を自己付与するため、この設定によって独自の操作 (JNDI へのリソースの登録など) に影響を受けることはありません。JNDIに書き込むアプリケーションは失敗しますが、そのようなアプリケーションは珍しいため、この設定によって支障がでることはほとんどありません。アプリケーションに JNDI への書き込みアクセスが必要な場合は、必要なアクセス権をそのアプリケーションに付与しなければなりませんが、JNDI アクセス権は名前空間の一部だけでなく、全体に適用されることに注意してください。

8. デフォルト・メッセージングでの有効な許可を確実にすること
attack code 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 メッセージングへのアクセスを制限すること
attack code

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 間のリンクを暗号化すること
attack code

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 の有効化
LDAP SSL の有効化

カスタム・レジストリーを使用する場合は、何らかの利用可能なメカニズムを使って、このトラフィックを保護する必要があります。

11. デフォルト鍵ファイルを作成すること
attack code

デフォルト鍵リングを変更する際の考慮事項

デフォルト証明書を変更する際には、念頭に置いておかなければならないことが 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 サーバー・ホストを強化すること
attack code

前に推奨した標準トポロジーに従っている場合は、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. 実動環境でサンプルを実行しないこと
attack code

WebSphere Application Server には、製品のさまざまな部分を実演する優れたサンプルがいくつか付属しています。これらのサンプルは、実動環境で使用するためのものではありません。重大なセキュリティー上のリスクをもたらすので、実動環境ではサンプルを実行しないでください。特に、showCfg およびスヌープするサーブレットは、システムに関する非常に多くの情報を部外者に提供する恐れがあります。この情報はまさに、潜在的侵入者に与えたくないタイプのものです。server1 (サンプルを含む) を実動環境で実行しなければ、このような事態は簡単に防げます。WebSphere Application Server ベースを使用している場合は、server1 からサンプルを除去しなければなりません。

14. Web サーバーのトラスト境界を検討すること
attack code

環境を構成する際には常に、トラスト境界について慎重に検討してください。不幸にも、トラスト境界を不適切に拡張することで、誤ってごく簡単に脆弱なセキュア環境を作れてしまいます。通常、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 リンクの認証を検討すること
attack code

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 トリックを適用して、アクセスできる関係者を制限してください。この場合、具体的には以下を行います。

  1. ikeyman を使用して、Web コンテナー用の鍵ストアとトラスト・ストアおよび Web Server プラグイン用の鍵ストアを作成します。
  2. トラスト・ストアを含め、すべての鍵ストアから既存の署名証明書をすべて削除します。この時点で、鍵ストアを使って証明書を検証することはできなくなりますが、これは意図的なことです。
  3. 2 つの鍵ストアに自己署名証明書を作成し、証明書だけをエクスポートします (秘密鍵はエクスポートしません)。
  4. Web コンテナーの鍵ストアからエクスポートした証明書をプラグインの鍵ストアにインポートします。Web コンテナーのトラスト・ストアには、プラグインの証明書をインポートします。これで、それぞれの側に署名証明書が 1 つだけが含まれることになります。つまり、検証できるのは唯一、ピアに作成した自己書名証明書だけです。
  5. 新しく作成した鍵ストアを Web コンテナーと Web サーバー・プラグインにインストールします。

16. 秘密鍵を保護すること
attack code

WebSphere Application Server は、秘密鍵のセットを複数管理しています。なかでも最も重要なのは、内部通信用の主要鍵ストア、そしてWeb サーバーとアプリケーション・サーバー間の通信に使用される鍵ストアです。これらの秘密鍵は秘密のままとし、共有してはいけません。秘密鍵の保管場所はコンピューターのファイル・システムであるため、これらのファイル・システムは慎重に保護する必要があります。鍵ストア内の情報は機密事項なので、共有ネットワークがアクセス可能なファイル・システムに配置することはお勧めできません。

また、これらの鍵が誤って共有されないように十分注意してください。例えば、実動環境とそれ以外の環境で同じ鍵を使用することは禁物です。開発マシンとテスト・マシンおよびそれぞれの秘密鍵にアクセスできる人は大勢いるからです。実動鍵は慎重に守ってください。

17. TAI は慎重に構成して使用すること
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 つのステップが必要となります。

  1. WebSEAL が SSL を使用して WebSphere Application Server と通信するように構成します。この SSL 構成には、アプリケーション・サーバーの Web コンテナーにしか知らされないクライアント証明書を含めます。
  2. アプリケーション・サーバーの Web コンテナーがクライアント証明書認証を行うように構成します。また、Web コンテナーのトラスト・ストアを変更して、WebSEAL が使用するクライアント証明書だけが含まれるようにします。このステップは非常に重要です。なぜなら、これによって、アプリケーション・サーバーの Web コンテナーに対する要求が WebSEAL からだけ送信され、侵入者からは送信されないことが保証されるからです (相互認証された SSL を使用するだけでは不十分です)。さらに、Web コンテナーから非 HTTPS トランスポートを除去して、サーバーにアクセスするときには相互認証された SSL だけが使用されるようにする必要もあります。
  3. プロパティーに mutualSSL=true を設定して WebSEAL TAI を構成します。ここで理解しておかなければならないのは、この最後のステップは、接続がセキュアであること、そして相互認証された SSL を使用していることを、TAI に示すだけだということです。上記の 2 つのステップのいずれかが正確で正しく構成されていないと、環境は完全に非セキュアになります。そのため、mutualSSL を使用する際には、十分慎重に検討してください。構成に何かしらの間違いがあると、どのユーザーにもなりすませる環境になってしまいます。

Web サーバーを混合環境に追加する場合、複雑さはさらに増します。この場合、WebSEAL と Web サーバー間の相互 SSL 構成の他、Web サーバー・プラグインと WebSphere Application Server の Web コンテナー間にも別の相互 SSL 構成を慎重に構成する必要があります。

18. 新しい LTPA cookie フォーマットのみを使用すること
attack code

WebSphere Application Server V5.1.1 では、サブジェクト伝搬をサポートする新しい LTPA cookieフォーマット (LTPAToken2) を導入しています (「Advanced Authentication in WebSphere Application Server」を参照)。それと同時に、古いフォーマットでの理論上の弱点にも対処しています。ただし、これらの弱点はあくまでも理論上のものであることを頭に置いておいてください。既知のセキュリティー侵害は発生していないので、古いフォーマットを使用しなければならない場合を除き、新しく強化されたフォーマットを使用するのが理想です。

新しい LTPA トークンでは、以下の強力な暗号化手法を使用しています。

  • ランダム・ソルト
  • 強力な AES ベースの暗号
  • データの署名
  • データの暗号化

参考までに、署名には 1024 ビットの RSA 鍵ペアが使用され、暗号化には 128 ビットの秘密鍵 (AES) が使用されています。暗号化に使用される暗号は AES/CBC/PKCS5Paddin です。

LTPA cookie の作成時には、旧バージョンの WebSphere Application Server、Lotus® Domino®、TAM WebSEAL などの他のシステムとの互換性を確実にするため、デフォルトで新旧の cookie 両方が同時にサポートされます。このような互換性が必要ない場合は、このサポートを無効にしてください。それには Security => Authentication Mechanisms => LTPA => SSO で Configuration (構成) パネルに進み、Interoperability Mode を選択解除します。図 10 を参照してください。

図 10. SSO 相互運用性モードの設定
SSO 相互運用性モードの設定

19. パスワードをコマンド・ラインで指定しないこと
attack code

セキュリティーが有効にされると、WebSphere Application Server 管理ツールを機能させるためには認証が必要になります。デフォルト、あるいは当たり前の認証方法は、ツールへのパラメーターとしてユーザー ID とパスワードをコマンド・ラインで指定することですがこれは禁物です。肩越しに覗き見している誰かに管理パスワードを見られてしまうからです。さらに、多くのオペレーティング・システムでは、プロセスのリストを表示可能なユーザーであれば誰でもコマンド・ラインの引数を調べることができます。そのため、コマンド・ラインで指定する代わりに、管理ツールがユーザー ID とパスワードを求めるプロンプトを表示するようにしてください。WebSphere Application Server V6.0.2 では、コマンド・ラインで指定されていないと、すべての管理ツールが自動的にユーザー ID とパスワードを求めるプロンプトを表示します。それ以上の措置は必要ありません。

それより古いバージョンの WebSphere Application Server を使用している場合は、ツールに RMI (デフォルトでは SOAP) 通信を使用するように指示すると、ツールにプロンプトを表示するよう強制できます。RMI エンジンは必要に応じてプロンプトを表示します。その方法は単に、-conntype RMI -port <bootstrap port> を指定するだけです。以下は、このようにして wsadmin を開始し、デフォルト・ポートでリッスンするデプロイメント・マネージャーに接続する例です。

wsadmin.sh -connectype RMI -port 9809

コマンド・ライン・ツールがユーザー ID とパスワードを求めるプロンプトをグラフィカルに表示するのは煩わしいと思うかもしれません。その場合は、ありがたいことに、この動作をオーバーライドして、ツールが単純なテキスト・ベースのプロンプトを表示するようにできます。それには該当する構成ファイルを編集して、loginSource を prompt から stdin に変更します。デフォルトでは管理ツールは SOAP を使用するため、soap.client.props ファイルを編集します。RMI を使用している場合は、sas.client.props を編集します。該当するファイルで loginSource プロパティーを探し、このプロパティーが stdin を指定するように変更してください。

20. 信頼できる署名者を慎重に制限すること
attack code

証明書認証 (クライアントまたはサーバー) を使用している場合に理解しておかなければならないのは、トラスト・ストアのそれぞれの署名者が、信頼できる ID 情報 (証明書) のプロバイダーを表すということです。信頼する署名者の数はできる限り少なくしなければなりません。そうでないと、2 人の署名者が同じユーザー ID にマップされる証明書を発行する可能性があります。この場合、アーキテクチャーに深刻なセキュリティー・ホールを作ってしまうことになります。

ikeyman を使用してクライアントとサーバーのトラスト・ストアを調べ、必要のない署名者をすべて除去してください。

21. デフォルトのメッセージング・リンクを暗号化すること
attack codeV6 のみ

デフォルトでは、メッセージングは非暗号化リンクで行われますが、当然、これは望ましくありません。これを修正するには、構成を変更する必要があります。それぞれのアプリケーション・サーバー (クラスターではなく) で、メッセージング・エンジンの inbound transport (インバウンド・トランスポート) パネルに進み、InboundBasicMessaging トランスポートを無効に設定してください。こうすると、クライアントが InboundSecureMessaging トランスポートしか使用できないようになります。図 11 を参照してください。

バージョンについての注意

MDB のトランスポート・チェーンを指定する機能は、WebSphere Application Server V6.0.2 で追加されました。

作業を完了するには、すべてのクライアントが InboundSecureMessaging トランスポートを使用するように構成しなければなりません。それには、クライアントのタイプに応じたいずれかの場所で、このトランスポートを指定します。通常の JMS クライアント (サーバー側でも) は、connection factory (接続ファクトリー) パネルで InboundSecureMessaging transport (InboundSecureMessaging トランスポート) を指定する必要があります。図 12 を参照してください。MDB には、activation specification (起動仕様) パネルで InboundSecureMessaging を指定します。最後に、バス間通信が使用されている場合は bus configuration (バス構成) パネルで InboundSecureMessaging を inter-engine transport chain (内部エンジン・トランスポート・チェーン) として指定する必要があります。

図 11. InboundBasicMessaging の無効化
InboundBasicMessaging の無効化
図 12. セキュア・トランスポートを使用する接続ファクトリーの構成
セキュア・トランスポートを使用する接続ファクトリーの構成

詳細は、「メッセージング・セキュリティーの管理」を参照してください。

22. WebSphere MQ メッセージング・リンクは暗号化すること
attack code

デフォルトのメッセージング・プロバイダーではなく MQ を使用する場合は当然、MQ に対して SSL を使用しなければなりません。それには、SSLCIPHERSUITE プロパティーを指定します。詳細は、WebSphere Application Server インフォメーション・センターおよび WebSphere MQ の資料を参照してください。

23. Distribution and Consistency Services のトランスポート・リンクを暗号化すること
attack codeV6 のみ

コア・グループは、DCS (Distribution and Consistency Services) に依存します。DCS は信頼性の高いマルチキャスト・メッセージ (RMM) システムをトランスポートに用います。 RMM はワイヤー・トランスポート技術のいずれかを使用します。セキュリティーを最大限にするには、暗号化されたリンクを使用してください。各コア・グループに対して確実に暗号化されたリンクを使用するには、CHANNEL_FRAMEWORK (チャネル・フレームワーク) の Transport type (トランスポート・タイプ) を選択し、DCS-Secure を Channel chain name (チャネル・チェーン) として選択します。図 13 を参照してください。

図 13. 保護されたリンクを使用する DCS の構成
保護されたリンクを使用する DCS の構成

グローバル・セキュリティーが有効に設定されていると、DCS は常にメッセージを認証します。トランスポートを暗号化すると、非常にセキュアなチャネルになります。

このような構成にすると、DCS に依存するすべてのサービスが、暗号化および認証されたトランスポートを使用するようになります。これらのサービスとは、DynaCache、メモリーとメモリー・セッション間の複製、コア・グループ、Web サービスのキャッシング、そしてステートフル・セッション Bean パーシスタンスです。

24. Distributed Replication Service ネットワーク・リンクを暗号化すること
attack code

WebSphere Application Server V6 を使用していて、DCS が暗号化リンクを使うように構成されている場合は、DRS (Distributed Replication Service) が DCS リンクで実行されるため、このステップは必要ありません。

グローバル・セキュリティーが有効になっていても、デフォルトでは DRS トラフィックは暗号化されません。DRS 暗号化を構成するには、複製ドメインの Configuration (構成) パネル (environment => Replication domains => <自分のドメイン>) で DES または 3DES を暗号化タイプとして指定します。

25. アプリケーション・サーバーとデータベース間のリンクを保護すること
attack code

他のすべてのネットワーク・リンクの場合と同様に、機密情報はデータベースでの読み取り/書き込みが可能です。ほとんどのデータベースは何らかの形の認証をサポートしますが、そのすべてがクライアント (この場合は WebSphere Application Server アプリケーション) とデータベース間の JDBC トラフィック (データベース・ベンダーの資料を参照) の暗号化をサポートするわけではありません。そのため、この弱点を認識して適切な対策を講じる必要があります。VPN (Virtual Private Network) などのネットワーク・レベルで IPSEC (IP Security Protocol) を使用するという暗号化形式が最も明らかなソリューションですが、その他にも適切な選択肢があります。例えば、データベースを WebSphere Application Server の近くに (ネットワークという意味で) 配置することができる場合、各種のファイアウォールと単純なルーティング・トリックによって、データベースに向かうネットワーク・トラフィックへのアクセスを大幅に制限することが可能です。ここで鍵となるのは、このリスクを識別して適切に対処するということです。

26. 個別の管理ユーザー ID を作成すること
attack code

WebSphere Application Server セキュリティーを構成すると、最初に単一のセキュリティー ID が Security Server ID として構成されます。この ID は事実上、WebSphere Application Server 内のルートに相当するため、すべての管理操作を実行できます。この ID は重要なので、パスワードを広範囲で共有しないことが最善策です。

コンソール・ログインについての注意

WebSphere Application Server V6 では、前に提案したように JNDI の強化を構成すると、管理コンソールに (security server ID 以外では) 管理者としてログインできなくなります。管理者がログインできるようにするには、すべての CosNaming アクセス権を管理者に明確に付与する必要があります。

ほとんどのシステムと同じく、WebSphere Application Server では管理者として活動するためのプリンシパルを複数許可します。管理アプリケーションを使って System Administration/Console Users (または Groups) セクションに進むと、管理権限を付与しなければならない追加のユーザーやグループを指定できます。こうすることで、それぞれの個人が WebSphere Application Server を管理するときに自己認証できるようになります。すべての管理者は、そのセル内で同じ権限を持つことに注意してください。WebSphere Application Server はインスタンス・ベースの管理許可をサポートしていません。

WebSphere Application Server 5.0.2 では、WebSphere Application Server の構成を変更する結果となるすべての管理操作は、変更を行ったプリンシパルの ID を含め、デプロイメント・マネージャーによって監査されます。管理者によって ID が異なる場合は明らかに、これらの監査レコードが役に立ちます。監査レコードは重要なメッセージとして扱われ、デフォルトではデプロイメント・マネージャーから SystemOut.log に送信されます。

個別の管理者に固有の管理アクセスを与えるという方法は、中心となる管理者が複数の WebSphere Application Server セルを管理する環境では重宝です。すべてのセルが共通レジストリーを共有するように構成できるため、セルごとに独自のローカル「ルート」ID およびパスワードがあっても、管理者は同じ ID とパスワードを使ってそれぞれのセルを管理できます。

27. 管理上の役割を利用すること
attack code

WebSphere Application Server では、管理者、オペレーター、モニター、コンフィギュレーターという 4 つの管理上の役割を使用できます。これらの役割によって、それぞれの個人 (および自動化システム) に必要なレベルに応じたアクセスを与えることができます。可能な場合は常にこれらの役割を利用することを強くお勧めします。権限が低いモニターおよびオペレーターの役割を使用すると、管理者が実行できる操作を制限できます。例えば、位の低い管理者にはサーバーを起動および停止する権限を与え、夜間オペレーターにはシステムを監視する権限 (モニター) を与えるなどです。このようにそれぞれの個人に必要な権限だけを与えると、損害のリスクが大幅に抑えられます。

ここで興味深いのは、モニターの役割です。ユーザーまたはシステムにこのアクセス・レベルを指定することは、システムの状態をモニターする権限だけを与えることになります。状態を変更したり、構成を変更することはできません。例えば、システムの正常性をチェックする監視スクリプトを開発する際に、ユーザー ID とパスワードをそのスクリプトと一緒にローカルに保管しなければならない場合は、モニターの役割を持つ ID を使用します。この ID が悪用されたとしても、それほど深刻な被害にはなりません。

28. Web サーバーおよびプラグイン・インストーラーが残した JDK を除去すること
attack code

IBM の HTTP Server をインストールすると、インストーラーはインストール・ルートの _jvm ディレクトリーに JDK を残したままにします。これは完全な JDK (開発ツールが含まれる) であるため、DMZ 内のマシンに存在していてはなりません。この JDK は除去する必要があります。除去すると、この Web サーバー上で ikeyman などのツールを実行できなくなりますが、これらのツールを DMZ 内で実行するのは問題があるため、JDK を除去しても支障はないことを覚えておいてください。

IBM のインストーラーを使って WebSphere Application Server の HTTP Server プラグインをインストールすると、同じく JDK が残されます。この場合、残されるのは 2 つの JDK です。最初の JDK はアンインストーラーが使用するもので、プラグイン・インストール・ルートの下の _uninstPlugin ディレクトリー内にあります。2 つ目の JDK は java ディレクトリー内にあり、ikeyman やその他の Java ツールが使用します。これも同じく、インストール後に除去しなければなりません。

JDK を除去する際は、今後使用する場合に備えてバックアップ・コピーを作成してください。方法の 1 つとして、JDK を zip または tar し、WebSphere Application Server 更新インストーラーに必要になったときに (フィックスを適用する際など) 置き換えることが考えられます。プロセスが完了したら、再び zip/tar して除去します。

29. 適切なプロセス ID を選択すること
attack code

WebSphere Application Server のプロセスはオペレーティング・システム上で実行するため、オペレーティング・システム ID を使用する必要があります。オペレーティング・システム ID に応じて WebSphere Application Server を実行する方法には、以下の 3 通りがあります。

  • すべてをルートとして実行する。
  • すべてを単一のユーザー ID (「was」など) として実行する。
  • ノード・エージェントをルートとして実行し、個別のアプリケーション・サーバーは固有の ID で実行する。

IBM では、最初の 2 つについてテストを行い、これらの方法を完全にサポートしています。3 番目の方法は、オペレーティング・システムのアクセス権を利用できるため使いたくなるかもしれませんが、実際にはそれほど効果的ではありません。その理由は、以下のとおりです。

  • 構成が難しく、手順も文書化されていません。多くの WebSphere Application Server プロセスには多数のファイルに対する読み取りアクセス、そしてログとトランザクション・ディレクトリーに対する書き込みアクセスが必要です。
  • ノード・エージェントをルートとして実行すると、WebSphere Application Server 管理者、そして WebSphere Application Server で実行するアプリケーションに事実上、ルート権限を与えることになります。
  • この方法の主な価値は、アプリケーションごとにファイル・システム・アクセスをコントロールすることです。これは Java 2 アクセス権を使えば実現できます。
  • この方法は、アプリケーションが互いに分離されるという誤った印象を作り出しますが、実際は違います。WebSphere Application Server の内部セキュリティー・モデルは J2EE および Java 2 セキュリティー・モデルに基づいているため、オペレーティング・システムのアクセス権には影響されません。そのため、「不正な」アプリケーションからの自己防御のためにこの方法を採択するのは見当違いです

最初の方法は明らかに望ましいものではありません。一般的なベスト・プラクティスとして、プロセスをルートとして実行することはできるだけ避けるのが最善であるためです。後に残るのは 2 番目の方法で、これは完全にサポートされていて、Java 2 セキュリティーと併用するとアプリケーションを分離できます (分離するのが理想的なはずです)。そのため、私たちはこの方法を推奨します。

WebSphere Application Server プロセス ID を選択したら、当然のことながら、オペレーティング・システムのファイル・アクセス権を利用して、WebSphere Application Server のファイルに対するファイル・システムのアクセスを制限しなければなりません。WebSphere Application Server はあらゆる複合システムと同じく、相当な量の機密情報を使用し、管理します。通常、ほとんどの WebSphere Application Server 情報に対する読み取りまたは書き込みアクセスは誰にも与えてはなりません。特に WebSphere Application Server 構成ファイル (<root>/config) には、構成情報とパスワードが含まれているので要注意です。

ただし、やりすぎは禁物です。私たちは、開発中に開発者がアプリケーション・サーバーのログ・ファイルでさえ見ることができないというケースをあまりにも多く目にしてきました。そのような被害妄想には根拠がなく、開発中にセキュリティーを最大限にするのは生産的ではありません。実動中の WebSphere Application Server は可能な限り保護しなければなりませんが、開発中は多少寛大になってください。

30. CSIv2 トランスポートで SSL を使用すること
attack code

WebSphere Application Server のサーバーとクライアントが CSIv2 IIOP を使用して通信するときには、トランスポート・セキュリティーのネゴシエーションが行われ、両方が許容するものが選択されます。通常はこれで問題ありませんが、1 つの弱点が考えられます。WebSphere Application Server は SSL または平文で CSIv2 をサポートします。デフォルトでは、両方とも SSL を使用するようにネゴシエーションして、暗号化通信チャネルを確実にするのが一般的です。ただし、ネゴシエーションでどちらかが平文を要求すると、平文が使用されます。この場合、トラフィックの送信が公然となっていることにさえ気付かないことがあります。このような事態は例えば、クライアントが不適切に構成されていると発生します。トラフィックを確実に暗号化するには (当然のことです)、SSL が常に使用されるようにしたほうが安全です。

IIOP で SSL が使用されることを確実にするには、CSIv2 transport (トランスポート) パネル (Security => Authentication Protocol => CSIv2 Inbound Transport) で、SSL がオプションではなく必須であると指定します。CSIv2 Outbound Transport (CSlv2 アウトバウンド・トランスポート) についても同じようにします。図 14 を参照してください。

図 14. CSIv2 トランスポート・パネル
CSIv2 トランスポート・パネル

31. パッチとフィックスを最新のものにすること
attack code

あらゆる複合製品と同様に、IBM は WebSphere Application Server、IBM HTTP Server、そしてその他の製品でセキュリティー・バグを発見して修正することが時折あります。これらのフィックスでは最新の状態を保つことが不可欠です。そのため、使用している製品のサポート掲示板にサブスクライブすることをお勧めします。WebSphere Application Server の場合は、推奨される更新のサポート・ページをモニターしてください。これらの掲示板には度々、最近見つかったセキュリティー・バグとバグ修正に関する注意事項が掲載されます。セキュリティー・ホールに関する情報を潜在的侵入者が即刻入手するのは確実です。そのため、対処するのが早ければ早いほど安全です。

WebSphere Application Server のセキュリティー・フィックスは通常、サポートされるリリースごとの次の累積フィックスに統合されるので、統合された後には推奨される更新のページに掲載されないことに注意してください。既知のセキュリティー・ホールをすべて塞ぐには、常に最新の累積フィックスが必要だということです。

32. 未使用ポートを無効に設定すること
attack code

セキュリティー強化の基本原則は、攻撃が考えられる面を最小限にすることです。この原則は、特定のサービスに既知のセキュリティー問題がない場合にも当てはまります。そのサービスがなくてもサイトが正常に機能するのであれば、サービスを除去して、アタッカーが将来その追加機能を利用する可能性を小さくしなければなりません。図 15 を見ると、典型的な WebSphere Application Server アプリケーション・サーバーは多数のポートをリッスンしていることがわかります。

図 15. WebSphere Application Server ND アプリケーション・サーバーのデフォルト・ポート
WebSphere Application Server ND アプリケーション・サーバーのデフォルト・ポート

特定のサービスが必要ないのであれば、そのサービスがリッスンするポートを無効にしても構いません。上記のリストで無効にする候補は以下のとおりです。

  • SAS_SSL_SERVERAUTH_LISTENER_ADDRESS -- WebSphere Application Server V4 以前のリリースとの互換性のために使用されます。これは古い IIOP セキュリティー・プロトコルです。CSIv2 では V5 の時点でこれを置き換えています。
  • SIB_ENDPOINT_* -- 組み込みメッセージング・エンジンが使用します。メッセージングを使用していない場合は必要ありません。
  • SIB_MQ_* -- メッセージング・エンジンが WebSphere MQ と接続するときに使用します。
  • WC_adminhost* -- 管理 Web ブラウザーへのアクセスに使用されます。セルの一部となっているアプリケーション・サーバーではすでに無効にされています。
  • WC_defaulthost* -- デフォルト Web コンテナーがリッスンするポートです。カスタム・リスナー・ポートを追加した場合は、必要ない可能性があります。

それぞれのポートのインプリメンテーション方法によって、ポートを無効にする方法は以下のように異なります。

  • SAS_SSL_SERVERAUTH_LISTENER_ADDRESS をサービスから除去するには、global security (グローバル・セキュリティー) パネルで、CSI を active protocol (アクティブ・プロトコル) として選択します。
  • WC_* ポートは Web コンテナー専用です。除去するのが最善ですが、Web コンテナーの transport chain configuration (トランスポート・チェーン構成) パネル (application servers => servername => web container => transport chain) で無効に設定することもできます。リッスンする必要のある Web ポートは、アプリケーションが使用するポートだけです。
  • SIB_* ポートはメッセージング・エンジンが有効でない限り起動されないので、必要な措置はありません。

アプリケーション・ベースの予防対策: 構成

ここまでは、WebSphere Application Server アーキテクチャーと管理チームが確実なセキュア・インフラストラクチャーを作成するために実行可能な基本的なステップに焦点を当ててきました。これは当然重要なステップですが、それだけでは十分でありません。インフラストラクチャーを強化したら、アプリケーションをセキュアにするために必要な事項についても検討しなければなりません。もちろん、アプリケーションは WebSphere Application Server によって提供されるインフラストラクチャーを利用しますが、アプリケーション開発者が実行しなければならない措置は他にも多数あります。以下に、それらの措置について詳しく説明します。

33. Web サーバーの doc ルートは決して WAR に設定しないこと
attack code

WAR ファイルにはアプリケーション・コードと大量の機密情報が含まれています。Web でサービス可能なコンテンツの情報はそのうちのほんの一部なので、Web サーバー文書のルートを WAR ルートに設定するのは適切ではありません。そのように設定すると、Web サーバーが WAR のすべてのコンテンツを解釈することなく処理します。その結果、エンド・ユーザーに対してコード、未処理の JSP などが処理されることになります。

この推奨事項は、Web サーバーが Application Server と同じ場所にある場合にのみ適用されますが、そのような構成はお勧めしません。

34. すべてのサーブレット・エイリアスがセキュアであることを慎重に検証すること
attack code

WebSphere Application Server は URL ごとにサーブレットを保護します。保護されるそれぞれの URLは、アプリケーションについて記述する web.xml ファイルで指定します。サーブレットに複数のエイリアスがあったり (つまり、複数の URL が同じサーブレット・クラスにアクセスする)、多数のサーブレットがあると、エイリアスを保護するのをうっかり忘れてしまいがちなので、気をつけてください。WebSphere Application Server が保護するのは基礎となるクラスではなく URL なので、サーブレットの URL が 1 つでも非セキュアだと、侵入者がセキュリティーをバイパスする恐れがあります。これを防ぐには、可能な場合は常にワイルドカードを使ってサーブレットを保護します。それが適切でない場合は、デプロイメントの前に web.xml ファイルを念入りにダブルチェックしてください。

エイリアスの問題は、次の推奨事項で説明するクラス名別サーブレットの処理として知られる機能によってさらに深刻化します。

35. クラス名別にサーブレットを処理しないこと
attack code

サーブレットはクラス名別、または標準の URL エイリアスを使用して処理できます。通常アプリケーションで選ばれるのは後者です。つまり、開発者が手作業で、あるいは各種の WebSphere Application Server 開発ツールのいずれかを使って各 URL とサーブレット・クラス間の正確なマッピングを web.xml ファイルで定義します。

一方、WebSphere Application Server ではサーブレットをクラス名別に処理することもできます。これは、サーブレットごとにマッピングを定義する代わりに、単一の汎用 URL (/servlet など) ですべてのサーブレットを処理するという方法です。このパスを構成する部分でベースに続くものは、サーブレットのクラス名として見なされます。例えば「/servlet/com.ibm.sample.MyServlet」の場合、サーブレット・クラスは「com.ibm.sample.MyServlet」となります。

クラス名別にサーブレットを処理するには、ibm-web-ext.xmi ファイルで serveServletsByClassnameEnabled プロパティーを true に設定するか、IBM Rational® Application Developer の WAR エディターでクラス名別サーブレットの処理 (serve servlets by classname) にチェック・マークを付けます。ですが、この機能は有効にしないでください。この機能によって、サーブレットのクラス名を知っている誰もがサーブレットを直接起動できるようになるからです。サーブレットの URL がセキュアだとしても、アタッカーは通常の URL ベースのセキュリティーをバイパスする可能性があります。さらに、クラス・ローダーの構造によっては、アタッカーが Web アプリケーションの外部でサーブレットを起動する恐れもあります。

35. 機密情報は WAR ルートに置かないこと
attack code

(訳注: 35 が 2 つありますが原文にあわせてあります。) WAR ファイルにはサービス可能なコンテンツが含まれます。Web コンテナーは、WAR ファイルのルートで見つかった HTML ファイルと JSP ファイルを処理します。ルートにサービス可能なコンテンツだけを配置している限り、これで問題はありません。したがって、WAR のルートにはエンド・ユーザーに表示すべきでないコンテンツは決して置かないでください。置いてはいけないコンテンツは、例えばプロパティー・ファイル、クラス・ファイル、あるいはその他の重要な情報などです。WAR に情報を配置しなければならない場合は、サーブレット仕様で許可されているように、WEB-INF ディレクトリーに配置してください。このディレクトリーにある情報が Web コンテナーによって処理されることはありません。

36. デフォルトのエラー・ハンドラーを定義すること
attack code

Web アプリケーションでエラーが発生した場合、アプリケーションのディスパッチ前だとしても (例えば、WebSphere Application Server がターゲット・サーブレットを検出できない場合など)、エラー・メッセージがユーザーに表示されます。デフォルトでは、WebSphere Application Server はエラーの未処理の例外スタック・ダンプを表示します。これではエンド・ユーザーに非常にわかりにくいだけでなく、アプリケーションに関する情報まで明かされてしまいます。スタック情報には、クラスの名前やメソッドが含まれるためです。例外メッセージも同じく表示されますが、このメッセージに機密情報が含まれている可能性があります。

エンド・ユーザーには未加工のエラー・メッセージを表示しないことが最善です。1 つひとつのサーブレッドで例外が常にキャッチされることを確実にすることもできますが、それではあらゆるケースを網羅しません (前述したように)。そうではなく、デフォルト・エラー・ページを定義してください。デフォルト・エラー・ページは未処理の例外が発生するたびに表示されます。スタック・トレースよりも、このページのほうがわかりやすいエラー・メッセージになるはずです。デフォルト・エラー・ページは ibm-web-ext.xmi の defaultErrorPage 属性で定義します。Web Deployment Descriptor エディター (拡張機能タブ) を使って Rational Application Developer で設定することもできます。

37. ファイルの処理とディレクトリーのブラウズの無効化を検討すること
attack code

Web アプリケーションでのファイル処理とディレクトリーのブラウズを無効に設定することで、コンテンツが不適切に処理されるリスクをさらに制限することができます。もちろん、WAR にサービス可能な静的コンテンツが含まれている場合は、ファイル処理を有効にしなければなりません。

38. セッション・セキュリティーを有効にすること
attack code

WebSphere Application Server は通常、HTTP セッション・アクセスの許可を行いません。有効なセッション ID を持っていれば誰でも、どのセッションにでもアクセスできます。セッション ID は推測できそうにありませんが、他の手段でセッション ID を取得する可能性があります。

このような形態の攻撃のリスクを抑えるには、セッション・セキュリティーを有効にすることを検討する必要があります。この設定は、application server => <サーバー名> => web container => session management (セッション管理) のパネルで構成します。security integration (セキュリティー統合) というラベルが付いたボックスにチェック・マークを付けると、WebSphere Application Server がどのユーザー (ユーザーが提示する LTPA 資格情報によって判別) がどのセッションを所有しているかを追跡し、該当ユーザーしか該当セッションにアクセスできないようにします。

あまりないケースですが、この設定によって Web アプリケーションが壊れることがあります。アプリケーションにセキュア・サーブレット (許可制限を持つサーブレット) と非セキュア・サーブレットが混在している場合、非セキュア・サーブレットはセッション・オブジェクトにアクセスできません。セキュア・サーブレットがセッションにアクセスすると、ユーザーによって「所有」されているものとしてマークが付けられます。匿名で実行する非セキュア・サーブレットがこれらのページにアクセスしようとすると、許可の失敗を受け取ります。

39. カスタム JMX ネットワーク・アクセスに用心すること
attack code

JMX とカスタム MBean によって、アプリケーションの強力なリモート・カスタマイズ管理をサポートすることが可能になります。ただし、JMX MBean はネットワークでアクセスできることに注意してください。JMX MBean をデプロイすることにした場合は、十分注意して行い、操作が適切に許可されることを確実にしてください。WebSphere Application Server は、MBean JAR ファイルに含まれる記述の情報に基づいて MBeans のデフォルト許可制限を自動的に指定します。これが適切かどうかは、使用しているアプリケーション次第です。詳細は、「IBM WebSphere: Deployment and Advanced Configuration」を参照してください。

アプリケーション・ベースの予防対策: 設計およびインプリメンテーション

ここからは、アプリケーション開発者と設計者がセキュア・アプリケーションをビルドするために必要な措置に目を向けます。これらのステップは非常に重要なのですが、残念ながら見落とされがちです。

40. WebSphere Application Server セキュリティーを使用してアプリケーションを保護すること
attack code

通常、アプリケーション・チームは自分たちのアプリケーションにある程度のセキュリティーが必要であることを認識しています。これは多くの場合、ビジネス要件です。ですが残念なことに、独自のセキュリティー・インフラストラクチャーを開発するチームは少なくありません。これが上手くいく場合もありますが、非常に難しいことなので、ほとんどのチームでは失敗に終わります。つまり、強力だと錯覚しているシステム・セキュリティーが実際は極めて脆弱だったりするということです。セキュリティーはひとえに難問です。暗号化、リプレイ・アタック、そしてその他のさまざまな形態の攻撃など、アプリケーション・チームが見逃しやすい難解な問題があります。ここで伝えたいことは、WebSphere Application Server セキュリティーを使用するべきだということです。それがニーズにまったく合わないというのであれば別ですが、そのような場合はめったにありません。

J2EE 定義の宣言型セキュリティー・モデルに関する苦情のなかで最も多いのは、粒度が十分に細かくないという点です。例えば、許可を実行できるのは EJB またはサーブレットのメソッド・レベルのみで、インスタンス・レベルでは実行できません。このコンテキストでは、サーブレットでのメソッドは HTTP メソッドのGET、POST、PUT などのひとつです。例えばすべての銀行口座には同じセキュリティー制限が設定されますが、それよりは、特定のユーザーに自分の口座に対する特別なアクセス権を持たせたほうがいいという場合があります。

この問題に対処するのが、J2EE セキュリティー API (isCallerInRole および getCallerPrincipal) です。この 2 つの API を使用すると、アプリケーションが独自の強力かつ柔軟な許可ルールを開発できると同時に、正確であることがわかっている情報、つまり WebSphere Application Server ランタイムのセキュリティー属性によってこれらのルールを運用することができます。

脆弱なセキュリティーの例

ここで、脆弱なセキュリティー・システムの一例を紹介しましょう。WebSphere Application Server セキュリティーを使用しないアプリケーションは、独自のセキュリティー・トークンを作成し、それをアプリケーション内で渡すという傾向があります。これらのトークンには通常、ユーザーの名前といくつかのセキュリティー属性 (ユーザーのグループ・メンバーシップなど) が含まれます。セキュリティー・トークンに暗号化によって検証可能な情報が含まれていないことは、まったく珍しくありません。トークンに含まれる情報に基づいてセキュリティーを判断できるという想定ですが、これは誤りです。トークンはユーザー特権を表明するだけでしかありません。

上記の例で問題となるのは、あらゆる Java プログラムがこれらのセキュリティー・オブジェクトのいずれかを偽造し、バックドアからシステムに忍び込むことが可能だという点です。その最適な例は、アプリケーションがサーブレット・レイヤーでトークンを作成して EJB レイヤーに渡すという場合です。EJB レイヤーが保護されていなければ (次のセクションを参照)、侵入者は偽の資格情報を使って EJB を直接呼び出すことができるので、アプリケーションのセキュリティーは無意味になります。かなりの設計努力が行われていない場合、ユーザー情報の唯一信頼できるセキュア・ソースは WebSphere Application Server インフラストラクチャーだけです。(WebSphere Application Server セキュリティー・インフラストラクチャーはその他の認証または許可製品と統合できます。例えば、Tivoli Access Manager は認証および許可サポートを提供します。)

41. アプリケーションのすべてのレイヤー (特に EJB) を保護すること
attack code

サーブレット・レイヤーにはある程度のセキュリティー (自作または WebSphere Application Server ベースのセキュリティー) を備えて Web アプリケーションをデプロイする一方、アプリケーションの一部である他のレイヤーが非セキュアのままという事態は珍しくありません。これは、アプリケーションで保護する必要があるのはアプリケーションの表玄関であるサーブレットのみであるという誤った前提に基づいています。どの警察官も言うように、家の裏口と窓にも鍵をかけなければなりません。

このような事態はいろいろな形態で起こりますが、Java クライアントがアプリケーションの一部ではなく、多層アーキテクチャーの一部として EJB が使用されている場合に起こるのが最も一般的です。この場合、開発者はアプリケーションの設計上では、EJB は「ユーザー・アクセスが不可能」なため、EJB を保護する必要はないだろうと思いがちですが、このような想定は非常に危険な誤りです。侵入者はサーブレット・インターフェースをバイパスして直接 EJB レイヤーに行くことが可能なので、EJB レイヤーにセキュリティーが設けられていなければ、大きな損害に至る恐れがあります。このようなバイパスは、使用可能な Java IDE を使えば簡単なことです。Java IDE は実行中の EJB を検査してそのメタデータを取得し、動的にテスト・クライアントを作成します。Rational Application Developer にはこの機能があり、開発者は毎日、統合テスト・クライアントを使うときにこれを目にしているはずです。

この問題に対してよくある最初の反応は、すべての認証済みユーザーがアクセス可能であるというマークを EJB に付けるなどの平凡な手段で EJB を保護するというものです。ただし、レジストリーによっては、「すべての認証済みユーザー」が会社内の全従業員である場合もあります。これよりもう一歩進んだ手段としては、特定グループのメンバーにアクセスを制限し、「このアプリケーションにアクセス可能なすべてのユーザー」とすることもあります。そのほうがまだましですが、通常は十分ではありません。該当アプリケーションにアクセス可能なすべてのユーザーが必ずしもそのアプリケーションであらゆる操作を実行できるべきではないからです。正しい対処方法は、EJB に許可チェックをインプリメントすることです。また、EJB をローカル EJB としてインプリメントし、リモートからは接続できないようにするのも一案です。

42. ユーザーの識別を HTTP セッションに依存しないこと
attack code

残念なことに、独自のセキュリティーを使用するアプリケーションのなかには、ユーザーの認証セッションを HTTP セッションを使用して追跡するものがあります。これは危険です。セッションは、セッション ID (URL または cookie に含まれる) によって追跡されます。この ID は任意に生成されますが、タイムアウトが発生しないため (アイドルの場合を除く)、リプレイ・アタックの危険にさらされます。その一方、アプリケーションで WebSphere Application Server セキュリティーを使用する場合に作成される LTPA トークンは、一層強力な認証トークンを提供するように設計されています。特に、LTPA トークンの存続期間には限りがあり、強力な暗号化を使用します。セキュリティー・サブシステムが、偽造された恐れのある LTPA トークンの受信を監査します。

43. すべてのユーザー入力を検証すること
attack code

クロスサイト・スクリプティングは、かなり油断のならない攻撃です。この攻撃は、Web ブラウザーの柔軟性と能力を利用します。大部分の Web ブラウザーは JavaScript をはじめとする各種のスクリプト言語を解釈できます。ブラウザーは特殊な一連のエスケープ文字に基づいて、実行可能なものであるかどうかを判断します。ここに、Web ブラウザー・セキュリティー・モデルの能力、そして危険な弱点があります。

侵入者は Web サイトをだまし、サイトに実行させたいスクリプトをブラウザーに表示させるという方法で、このホールを利用します。任意のユーザー入力が許可されているサイトでは、これを実行するのはわけありません。例えば、サイトにアドレスの入力フォームが記載されている場合、ユーザーはアドレスの代わりに JavaScript を入力します。サイトがそのアドレスを後で表示すると、Web ブラウザーはそのスクリプトを実行します。スクリプトは、サイトから Web ブラウザーの内部で実行されるため、ユーザーの cookie などといったセキュアな情報にアクセスすることが可能です。

ここまでのところは危険ではなさそうですが、侵入者はこれをもう一歩進歩させます。彼らはユーザーに E メールで何気なく URL を送信するなどして、ユーザーをだまして Web サイトを表示させ、「悪意のスクリプト」を入力させるのです。これで、侵入者がユーザーの ID を使って悪事を働くことが可能になります。詳細は、「Understanding Malicious Content Mitigation for Web Developers」を参照してください。

この問題は実際には、ユーザー入力の検証に関連したかなり大規模な類の問題のなかでは特殊な事例です。ユーザーに自由にテキストを入力できるようにする場合は常に、害を及ぼす特殊文字が入力テキストに含まれていないことを確実にする必要があります。例えば、ユーザーが特定の索引を検索するためのストリングを入力することになっていたら、ストリングをフィルタリングして、検索を無限にする可能性のある不適切なワイルドカード文字を除去します。クロスサイト・スクリプティングを防ぐ場合は、ブラウザーでサポートされているスクリプト言語のエスケープ文字をフィルタリングで除去してください。ここで伝えたいのは、すべての外部入力を疑ってかかり、慎重に検証しなければならないということです。

44. 情報を安全に保管すること
attack code

セキュア・システムを作成するには、情報の保管場所と表示場所を検討しなければなりません。時として、かなり深刻なセキュリティー・リークが偶然できてしまうことがあります。例えば、非常に機密度の高い情報を HTTP セッション・オブジェクトに保管する際には用心してください。このオブジェクトはデータベースにシリアライズされるかもしれないので、情報がそこから読み取られてしまう恐れがあります。侵入者がデータベースにアクセスできる場合、あるいはデータベース・ボリュームにさえもマシン・レベルで直接アクセスできる場合、セッションの情報が見られてしまう可能性があります。言うまでもなく、そのような攻撃は高度なスキルを使用します。

45. 監査および追跡は機密情報として扱うこと
attack code

重要なアプリケーションは、ビジネス目的とデバッグ目的でかなりの量のログ情報および追跡情報を生成します。それ自体には問題ありませんが、ファイル内の情報は最終的に多数の場所 (おそらく社外) に散らばる傾向があることに注意してください。極めて重要な情報については追跡を行ってはなりません。また、可能な場合は監査もできるだけ控えるようにしてください。例えば、クライアントがトレース・ファイルのユーザー・パスワードを印刷するのを見たことがあります。そのファイルが誤った人物 (ユーザー支援のためにいるコンサルタントなど) に読み取られた場合、機密情報を不適切に明かしてしまったことになります。

ログに記録する内容は制限し、ログに記録する内容については安全であるかどうかを確認することを強くお勧めします。

46. アイドル・ユーザーは無効にすること
attack code

ユーザーの HTTP セッションおよび認証セッションは完了と同時に無効にしてください。そうすることにより、アイドル・セッションが別のユーザーによって乗っ取られる可能性が少なくなります。また、他の作業のためにリソースを解放することにもなります。

HTTP セッションを破棄するには HTTPSession.invalidate() メソッドを使用します。WebSphere Application Server 認証セッション情報は、ユーザーを ibm_security_logout URL に移動させることによって破棄されます。詳細は、WebSphere Application Server インフォメーション・センターを参照してください。注目すべきこととして、ブラウザーの cookie を排除するのに最も信頼性の高い方法は、Web ブラウザーを単に終了することだけです。この方法は多数の Web サイトではっきりと推奨しているので、ご自分のサイトでも同じく推奨したほうがいいかもしれません。ブラウザーを閉じてもサーバー側の状態は除去されません。サーバー側がタイムアウトするまで状態は保留されます。このことが懸念事項である場合は、JavaScript を使ってブラウザーのクローズ・イベントを捕捉するという方法が考えられます。


パート 2 に続く

この記事は、「WebSphere Application Server V6 高度なセキュリティーへの強化 -- パート 2: 拡張セキュリティーの考慮事項」に続きます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=278242
ArticleTitle=IBM WebSphere 開発者向け技術ジャーナル: WebSphere Application Server V6 高度なセキュリティーへの強化 -- パート 1
publish-date=12072005