以前に書いた developerWorks の記事「Secure remote data access for Domino®」では、Apache Web サーバーを利用して予算重視の方法でエンタープライズ問題を解決する方法について話しました (「参考文献」を参照)。今回の記事では引き続きこのテーマを取り上げ、Apache Web サーバーを使用して、1 枚のネットワーク・カードでネットワークに接続する単独のサーバーで、複数の SSL (Secure Sockets Layer) Web サイトを提供する方法について説明します。

どうして誰も、１ 台のサーバーに複数の SSL サイトを置こうとしないのでしょう。エンタープライズ内の単一のサーバーで複数の SSL サイトをホストするというビジネス・ニーズは今までになかったのでしょうか。そこで我々は、現実のシナリオを用いてこの問題に取り組んでみたいと思います。革新的なユーザーなら、このアイデアを元に他にも独創的な使い道を必ず見つけ出すはずです。

事例研究: 2 つのアプリケーションと 1 つのサーバー

弊社では以前のプロジェクトで、人事 (HR) 部が Web ベースの給付アプリケーションに対する外部インターネット・アクセスを提供しようと考えていました。この Web アプリケーションは主に企業ネットワーク内からのアクセスを対象としていましたが、ユーザーが外部インターネットからアクセスするケースもありました。セキュリティー要件を満たすため、我々はサーバーを企業ネットワーク内に配置し、Apache の HTTP サーバーを使ってリバース・プロキシー・サーバーを構築することにしました。リバース・プロキシー・サーバーが SSL 接続の終端となり、HR アプリケーションをホストする Web アプリケーションとの別の SSL 接続を再オープンするという考えです。Apache Web サーバーに mod_security モジュールを追加すれば、リバース・プロキシー・サーバーをアプリケーション・ゲートウェイに変更して Web アプリケーションのセキュリティーをさらに強化することができます。HR 部は、わかりやすく覚えやすい完全修飾ドメイン名 (FQDN) を慎重に選びました。我々は順調に SSL 証明書を取得し、それで話は終わったものと思いました。

その一年後、HR アプリケーションと同様の要件を持つ別の企業 Web アプリケーションが出現しました。このアプリケーションにも外部ユーザーがアクセスできるようにする必要がありました。外部ユーザーの数はほんのわずかで、重要な作業のほとんどは企業ネットワーク内で行われることになっていました。そこで即座に思い付いたのが、リバース・プロキシー・サーバーを使って、この新しい Web アプリケーションへの外部アクセスを提供するという方法です。

ところが、この新しいアプリケーションにはいくつかの懸念事項が持ち上がりました。とりわけ懸念されたのはデータ・センターの物理スペースで、サーバーの統合をあらゆるアプリケーションのデプロイメントで真剣に検討しました。第 2 に、リバース・プロキシー・サーバーを追加購入する費用も正当化しなければなりません。この 2 つの懸念事項を考え合わせた上で検討しはじめたのが、既存のリバース・プロキシー・サーバーを使って新しい Web アプリケーションのニーズをどうにか満たせないかということです。唯一問題となったのは、このアプリケーションには既存の HR アプリケーションに確立したものとは異なる FQDN が必要だという点でした。

既存のリバース・プロキシー・サーバーを 2 つ目のアプリケーションに利用する案をいくつか検討してみました。最初の案は、新規アプリケーションと既存のアプリケーション両方のドメイン名を何かしら一般的な名前、例えば rp.company.com などに変更し、それぞれのコンテキスト・パスで 2 つのアプリケーションを区別するというものです。ただしドメイン名の変更には、リバース・プロキシー・サーバーの元々のユーザーが猛反対しました。名前の変更を会社全体に伝え、更新された URL を反映するように印刷物すべてを変更しなければならないためです。また、ヘルプ・デスクにはサイトにアクセスできないユーザーからの電話が殺到することが必至ですが、そんなヘルプ・デスクへの考えられる影響を無視したとしても、このような変更にかかる費用は莫大なものになります。さらに、独自の FQDN を維持したいという両方のアプリケーション・グループの希望もありました。採択されている FQDN の方が提案された汎用 URL より覚えやすく、それぞれの Web アプリケーションの商標を確立するためも使用されているというのが彼らの主張です。

別の案が浮上しました。新しいドメイン名を既存のサーバーに結び付ける DNS エントリーを登録するという方法です。しかしこの提案はすぐに破棄されました。SSL アプリケーションでは、SSL 証明書とユーザーによって要求された URL が一致する必要があり、一致しない場合は、要求 URL が SSL 証明書のドメイン名と一致しないという警告メッセージがポップアップ表示されるためです。ポップアップ広告とマルウェア (破壊工作ソフト) の増加により、社内の全員が、ポップアップ警告ボックスが現れる Web 対話はキャンセルするように訓練されています。そのため、企業アーキテクチャー標準の要件では実動 Web アプリケーションがポップアップ警告メッセージを生成することを禁止していました。

次の案として出されたのは、一方の SSL サイトを実行するサーバー上の別のポートでもう一方の SSL サイトをホストするという方法です。ただし、この方法だとユーザーに大きな混乱を招くことが予想され、そしてサイトの URL だけでなくポート番号も記憶するのはユーザーにとって大変だという感がありました。ユーザーがポート番号宛先を入力せずに URL だけを入力すると、HR アプリケーションにリダイレクトされてしまいます。それでは多くの問題の原因になるだけです。

上に戻る

ソリューション: IP エイリアス

我々が最終的に巡り合ったソリューションは、IP エイリアスです。このソリューションを探求する上で最も難儀だったのは、正しい用語を識別することでした。このコンセプトを初めて紹介されたとき、仮想インターフェースや仮想 IP といった用語を耳にしましたが、この 2 つのコンセプトに関する情報はなかなか見つかりませんでした。苦労の末やっと気付いたのは、我々が探しているものは IP エイリアス機能として知られているコンセプトだったということです。それからは、このトピックに関する資料がいろいろと見つかりました。IP エイリアスは、ネットワーク・インターフェース・エイリアス、または論理インターフェースと呼ばれることがあります。

Linux システムでの IP エイリアス

IP エイリアスの背後にあるコンセプトは単純です。つまり、単一のネットワーク・インターフェースに複数の IP アドレスを構成することによって、1 台のサーバー上で複数の Web サーバーを実行できるようにします。IP エイリアスの設定は極めて簡単で、システムに追加 IP アドレスをリッスンするネットワーク・インターフェースを構成すればいいだけのことです。Linux™ システムでは、標準ネットワーク構成ツール (ifconfig や route コマンドなど) やグラフィカル・ネットワーク管理ツールを使って IP エイリアスを追加できます。

通常、それぞれのイーサネット・カードは物理ユニット番号で構成されます。構成済みのイーサネット・カードに IP エイリアスを追加するには、同じイーサネット・カードの物理装置番号を論理装置番号で修飾してインターフェースを構成します。例えば、既存の IP アドレスが物理装置番号 eth0 のイーサネット・カードに構成されている場合、リスト 1 に示すように物理装置番号に論理装置番号 :1 を追加して IP エイリアスを作成します。この論理装置番号を増やしていけば、IP アドレスをさらに追加できます。(ルート・ユーザーとしてログインしなければならないことに注意してください。)

                
ifconfig eth0:1 192.168.0.2 netmask 255.255.255.0
    

構成中のシステムで Linux カーネルが IP エイリアスをサポートしていないと、この手法は使用できません。サポートしていない場合、カーネルを再ビルドしなければならない場合があります。カーネルが IP エイリアスをサポートしているかどうかを調べるには、/proc/net/alias* ファイルの有無を確認してください。

新しい IP アドレスを構成したら、リスト 2 に示すように、この新規インターフェースのルートを設定します。

                
route add -host 192.168.0.2 dev eth0:1
    

新規 IP アドレスの作成後には、この新規アドレス固有の名前を /etc/hosts ファイルで指定する必要もあります。リスト 3 を参照してください。

                
192.168.0.1 primaryserver
192.168.0.2 secondaryserver
    

Solaris システムでの IP エイリアス

Solaris™ で IP エイリアスを設定する場合は、使用するコマンド・セットが多少異なります。リスト 4 に示すようにネットワーク・インターフェースを構成してください。ルート・ユーザーとしてログインする必要があります。

                
ifconfig eth0:1 plumb
ifconfig eth0:1 192.168.0.2 netmask 255.255.255.0
ifconfig eth0:1 up
    

リブートしてからも仮想 IP を持続させるには、/etc/hosts から IP アドレスまたはホスト名を /etc/hostname.eth0:1 ファイルに追加します。

Linux と Solaris ではいずれも 1 枚の物理イーサネット・カードで、異なるサブネット上の IP アドレスとの仮想インターフェースを複数作成できます。ただし、このように構成することは通常は避けてください。この構成は 2 つのサブネット間のボトルネックとなり、この 2 つのサブネット上のすべてのネットワーク・デバイスのパフォーマンスがある程度影響されるためです。

IP アドレスごとに複数の SSL サイトを構成する方法

2 つ目の IP アドレスを構成すると、リスト 5 に示すように、Apache Web サーバーの構成ファイルに IP アドレスごとの SSL サイトを追加できるようになります。

これで、同じサーバーの同じ物理ネットワーク・カードに複数の SSL Web サイトを構築したことになります。

                
<IfModule mod_ssl.c>
    Listen 443
    <VirtualHost 192.168.0.1:443>
       DocumentRoot "/Web site1/docs"
       ServerName Web site1.company.com:443
       SSLEngine on
       SSLCertificateFile ssl/site1.crt
       SSLCertificateKeyFile ssl/site1.key
    </VirtualHost>

    <VirtualHost 192.168.0.2:443>
       DocumentRoot "/Web site2/docs"
       ServerName Web site2.company.com:443
       SSLEngine on
       SSLCertificateFile ssl/site2.crt
       SSLCertificateKeyFile ssl/site2.key
    </VirtualHost>

</IfModule>

    

上に戻る

他にも考えられる複数 SSL サイトの使用方法

Apache Web サーバー上のトラフィック量は少ないため、このリバース・プロキシー・サーバーは、同じくトラフィック要件が厳しくないバックエンドのサーバーにも利用できるはずです。

より大規模でより強力なサーバーと、より大きな帯域幅に対応するネットワーク・カードが登場すれば、この方法で複数の仮想 SSL サイトをホストすることもできます。帯域幅の制限された複数の SSL サイトをカスタマーに提供する ISP を設定すれば、低トラフィックのサイトで SSL セキュリティーを必要とする少量の販売取引を行うことができます。IP エイリアスでは、一方の IP アドレスで SSL Web サイトをホストし、もう一方の IP アドレスで他のサービス (Web サービスなど) をホストすることも考えられます。その他の可能性としては、主実動システムとフェールオーバー・システムを設定して、QA システムや DR システムとして二重化することも実現可能です。IP エイリアスの基本コンセプトを理解した今、アプリケーションの可能性が広がったはずです。

参考文献

学ぶために

• 「IBM HTTP Server (powered by Apache): An integrated solution for IBM eServer iSeries servers」: IBM iSeries サーバーで稼動する Apache HTTP サーバーを計画、インストール、構成、トラブルシューティング、そして理解する際の支援として、このレッドブックを調べてください。
  
  
• 「Beyond performance testing, Part 13: Testing and tuning load balancers and networks」(Scott Barber 著、developerWorks、2004年6月): IP エイリアスを使ったクライアント側でのパフォーマンス・テストについて学んでください。
  
  
• 「Secure remote data access for Domino」(John Liao 著、developerWorks、2003年7月): 機密性の高いデータをリモート・ユーザーが使用できるようにする方法について説明しています。
  
  
• 「A day in the life of #Apache」(Rich Bowen 著、ONLamp.com、2005年2月): Apache で名前ベースの SSL 仮想ホストを実行する際に伴う問題について説明した記事です。
  
  
• 「Web security appliance with Apache and mod_security」(Ivan Ristic 著、Security Focus、2003 年 10 月): リバース・プロキシーで Web アプリケーションを保護する方法を学んでください。
  
  
• developerWorks Web architecture ゾーン: Web 技術を専門とした記事およびチュートリアルで、サイト開発の技術を磨いてください。
  
  
• developerWorks technical events and webcasts: 学習の早道となり、難しいソフトウェア・プロジェクトの品質とその結果を改善する技術的セッションが満載です。
  
  

製品や技術を入手するために

• IBM 製品の評価版: DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
  
  

議論するために

• developerWorks blogs: developerWorks コミュニティーに参加してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 事例研究: 2 つのアプリケーションと 1 つのサーバー
• ソリューション: IP エイリアス
• 他にも考えられる複数 SSL サイトの使用方法
• 参考文献
• 著者について
• コメント