| Oracle Collaboration Suiteファイアウォールおよびロード・バランサ・アーキテクチャ リリース2（9.0.4） 部品番号: B15726-01 |
|
 戻る |
Copyright © 2004, Oracle.All rights reserved.
OracleはOracle Corporationおよびその関連会社の登録商標です。その他の名称は、Oracle Corporationまたは各社が所有する商標または登録商標です。
ファイアウォールおよびロード・バランサ・アーキテクチャ
リリース2（9.0.4）
部品番号: B15726-01
原典情報: B15609-01 Oracle Collaboration Suite Firewall and Load Balancer Architecture Release 2 (9.0.4)
2005年3月
このドキュメントでは、Oracle Collaboration Suiteリリース2でのファイアウォールおよびロード・バランサの使用方法について説明します。Oracle Application Server Containers for J2EE（OC4J）コンポーネントを例として使用し、主にOracle Collaboration Suite Infrastructureでのファイアウォールおよびロード・バランサの使用方法に重点を置いて説明します。Oracle Emailサーバーなどの他のOracle Collaboration Suiteコンポーネントをファイアウォールおよびロード・バランサとともに使用する場合も、同様の考慮事項が適用されます。
このドキュメントでは、次の内容について説明します。
インターネット・アプリケーションを正常に配置するには、Oracle製品をファイアウォール、ロード・バランサおよびSecure Sockets Layer（SSL）アクセラレータ製品と統合する必要があります。このドキュメントでは、Oracle Collaboration Suiteリリース2コンポーネントをファイアウォール、ロード・バランサおよびSSLアクセラレータ・デバイスとともに使用する場合に可能な構成の概要を示します。また、インターネット上に配置されるアプリケーションの様々なアーキテクチャおよびコンポーネントを選択する基準についても説明します。このドキュメントは、顧客の様々な要求に対応することを目的としています。
このドキュメントでは、主に、インターネット・アクセスが可能なアプリケーション用に、Oracle Collaboration Suiteリリース2コンポーネントをファイアウォールおよびロード・バランサとともに配置する場合に使用可能なアーキテクチャおよび方法について説明します。この場合、特定のOracle製品、Radware社、F5社、Check Point社、Cisco社、Sonic Wall社およびNortel社のベンダー製品についての記述があります。オラクル社では、ロード・バランサ、ファイアウォールなどと使用した場合のテストを実行していますが、このようなテストの結果として、修正プログラムおよび拡張機能がこれらの製品に追加される場合があります。これらの修正プログラムおよび拡張機能は、現在出荷中の製品またはベンダーから提供されるアップグレードで入手可能です。Oracle製品に関する問題は、Oracle Collaboration Suiteリリース2の初期リリースですべて修正されています。
オラクル社では、これらのファイアウォール製品およびロード・バランシング製品の受容性を判断するテストを実行していますが、それによって、これらの製品を保証したり、他の製品（オラクル社でテストされている製品とテストされていない製品の両方を含む）と比較してこれらの製品を推奨しているわけではありません。また、オラクル社では、これらの構成によって大部分の顧客の要求に対応できるものと確信していますが、顧客の特定の状況に関してこれらの製品が適しているかどうかは明言していません。特定のベンダーの装置に関する記述がない場合でも、オラクル社がこれらを推奨していないことを示しているわけではありません。将来のリリースで製品のテストを希望するベンダーは、オラクル社の製品管理部門に連絡してください。
Oracle Collaboration Suiteコンポーネントは、インターネット環境で正常に機能するように設計およびテストされています。この項では、Oracle製品でインターネット・アクセスに対応するネットワークを構成する場合に利用可能な情報を提供します。
特定のテスト済構成について説明する前に、インターネット・アクセスが可能なアプリケーションの配置に適したネットワーク・アーキテクチャの一般的な推奨事項について説明します。通常は、インターネット、ファイアウォール、非武装地帯（DMZ）、ファイアウォールおよびイントラネット・コンポーネントで構成される一般的なアーキテクチャお薦めします。次に、このアーキテクチャを簡略化した図を示します。
このドキュメントでは、DMZは、顧客のネットワークの中の、顧客のイントラネットとインターネットとの間にある部分で構成されています。このネットワーク・ゾーンは、境界ネットワークと呼ばれることがあります。DMZは、必ずしも図1に示すように単純な1セグメントLANである必要はありません。
次に、Oracle製品の配置に使用するDMZに関する推奨事項を示します。
DMZのハードウェアは、バス接続ではなくスイッチ接続で接続します。スイッチ接続では、送信デバイスおよび受信デバイスでのみ交換メッセージを表示できます。バス接続では、メッセージ交換に正式に関与していないデバイスでも交換メッセージを表示できます。
インターネットとDMZとの間のファイアウォールでは、DMZハードウェアの送信者アドレスを持つインターネット・トラフィックの着信は許可されません。
DMZとイントラネットとの間のファイアウォールでは、DMZ送信者アドレスを持つ、DMZからイントラネットへのメッセージのみが許可されます。
図1は、FW1とFW2の2つのファイアウォールを示していますが、実際には、このようなネットワーク接続使用例では、単一または複数のハードウェア・コンポーネントを使用してこの設定を実装できます。
図2に示すように、推奨ハードウェアでは、DMZハードウェア間でのスイッチ接続、および接続されているデバイス（インターネット・デバイスとイントラネット・デバイス）の通過ルール（各ペアで異なる場合あり）が提供されます。このようなハードウェアの例としては、Cisco社のCSS 11000シリーズ製品またはRadware社のWSDおよびFireproofシリーズ製品があります。これらのルールで、特定のデバイス・ペア間でのメッセージ交換に特定のプロトコルおよびポートが使用されるように指定できます。たとえば、このような構成では、HTTPメッセージをシステムAからポート8080上のシステムBにのみ送信できます。このようなハードウェアが推奨される場合は、複数のファイアウォールを使用することもできます。
次の図に、この推奨アーキテクチャを示します。
図1と同様に、図2も、インターネット、ファイアウォール、DMZ、ファイアウォールおよびイントラネット・コンポーネントで構成されるアークテクチャを示します。ただし、この場合は、統合スイッチ・ファイアウォールによって、接続されているコンポーネント（インターネット、イントラネット、Oracle HTTP Server、OracleAS Single Sign-On Serverなど）の各ペアに切替えルールが提供されます。統合スイッチ・ファイアウォールは、単一または複数のデバイスで構成できることに注意してください。
ファイアウォールは、インターネット・アクセスを提供するサイトで使用される主要な防御テクノロジです。ファイアウォールの機能およびパフォーマンスは、製品によって大幅に異なります。ファイアウォールを適切に使用すると、File Transfer Protocol（FTP）、リモート・シェル（rsh）などのサービス（特に、インターネット・サーバー上で実行されている場合）へのインターネット・アクセスを禁止して、多くの一般的な脆弱性を保護することができます。
ファイアウォールは、セキュリティの目的で、異なるLANセグメント間でのアクセスを制御するデバイスです。ファイアウォールでは、トラフィックを分析することによってこの機能を実行し、IPアドレス、ポート、使用されるプロトコル、プロトコル・トランジションおよびメッセージ・コンテンツに基づいて通信を制限できます。たとえば、オラクル社でテスト済のCheck Point Firewall-1製品では、「ステートフル・インスペクション」と呼ばれる、不正なインターネット・プロトコル・トランジションに基づいてアクセスを制限できる機能が組み込まれたソフトウェア・ソリューションが提供されます。ハードウェアとソフトウェアの統合ファイアウォール・ソリューションの例には、オラクル社でテスト済のCisco社のPIXがあります。
ファイアウォールには、クライアントまたはサーバー・コンピュータにロードされるソフトウェア製品もあります。これらの製品は、ある程度までは有効ですが、アプリケーションまたはインフラストラクチャ・ソフトウェアを配置しているシステムとは別のシステムに配置する必要がある企業ファイアウォールには不適切です。
ロード・バランシング・ハードウェアを使用すると、複数のプロセッサにロードを分散することによって、スケーラビリティおよびフォルト・トレランス（プロセッサに障害が発生した場合）の両方が提供されます。
ロード・バランサには、2つの重要な機能があります。1つ目の機能は、トラフィックのロードを複数のサーバーに分散することによって、スケーラビリティを向上させる機能です。トラフィックが多い場合、ロード・バランサが非常に重要となる可能性があります。このように使用されるテスト済ロード・バランサの例としては、F5社のBIG-IP製品があります。
ロード・バランサの2つ目の機能は、サーバーにフォルト・トレランスを提供する機能です。ロード・バランサによって、1台のサーバーに障害が発生しても、重要なリソースが失われることがなくなります。これは、1台のサーバーに障害が発生した場合に、新規リクエストを代替サーバーにルーティングすることによって実現されます。
通常、ロード・バランサは、Infrastructureでアプリケーションのステートが保持される場合およびトラフィックがステートレスになっている場合の両方で、トラフィックをルーティングできます。ステートレス通信の場合、メッセージの適切な処理のためにサーバーでステートを保持する必要がないため、任意の管理サーバーにトラフィックをルーティングできます。一般的に、この方法は、使用率の最も低いサーバーにリクエストをルーティングできるため、より効率的な方法です。ただし、ステートレス操作は、アプリケーション作成者にとって大きな負担になる場合があります。多くのOracle製品が、Infrastructureでアプリケーションのステートを保持する必要があるためです。
「スティッキー・トランザクション」または「永続トランザクション」という用語は、ロード・バランサで管理される特定のハードウェア（アプリケーション・トランザクションの中間ステートを保持）にルーティングする必要があるトランザクションを表します。
Infrastructureでステートが保持されるトランザクションの場合は、ロード・バランサによって、ステートを保持しているサーバーに着信メッセージが切り替えられます。切替え基準は、Cookie、ヘッダーまたはその他の属性を分析して決定されます。ステートを保持しているサーバーが1台のみの場合もあります。この場合、プロセッサに障害が発生すると、障害が発生したプロセッサ内にステートを保持しているすべてのトランザクションに障害が発生します。これらのすべてのトランザクションを再度開始する必要があります。
優先されるプロセッサがあるにもかかわらず、すべてのプロセッサでステートを取得できる場合があります。このような状況で障害が発生した場合は、障害が原因で実行されるリダイレクトが正常に処理されます。ただし、これによって、障害が発生したプロセッサ内にステートを保持しているトランザクションで、追加のオーバーヘッドが発生することがあります。
多くのサイトでは、SSLキー交換操作でCPU使用率が占有される可能性があります。このようなサイトでは、SSLアクセラレータ・デバイスを使用して、コストの大幅な削減およびパフォーマンスの向上を実現できます。
このプロジェクトの一環として、SSL処理を加速させるデバイスが含まれています。理由は次のとおりです。
SSLアクセラレータは、BIG-IP SSLアクセラレータなどのロード・バランシング装置の一部として含まれている場合があります。
SSLアクセラレータは、スケーラビリティの向上またはコストの削減のために必要となる場合があります。このようなアクセラレータの例としては、Cisco社の装置とともに使用されるSonic Wall Acceleratorがあります。
SSLアクセラレータは、ロード・バランシング装置が組み込まれたスケーラブルなソリューションの一部として配置できます。このようなソリューションによって、追加のパフォーマンスとスケーラビリティが提供されます。このようなソリューションの例としては、Radware Web Server DirectorおよびCT-100 SSL Acceleratorがあります。
HTTPSを広範囲にわたって使用すると、セキュリティが向上します。HTTPSの使用がパフォーマンスの考慮事項によって制限されている場合は、SSLアクセラレータの使用を検討する必要があります。
SSLアクセラレータには、様々なタイプがあります。1つ目のタイプは、汎用CPU（テスト済CPUはありません）から負荷の高い暗号化操作をオフロードする演算用コプロセッサです。2つ目のタイプは、HTTPSプロトコルをHTTPプロトコルに変換するスタンドアロン・デバイスです。着信HTTPSプロトコルをHTTPに変換します。HTTPSプロトコルのSSL処理によって、ほとんどのCPUタイムが消費される場合があるため、SSL処理のオフロードを行うと、ワークロードのサポートに必要なCPUの数を大幅に削減できるようになります。このような削減（特に、キャッシュ・サーバーの数を削減してキャッシュ機能を向上できる場合）を行うと、コストを削減し、パフォーマンスを向上させることができます。
クライアント側のX.509証明書が使用される場合は、HTTPSからHTTPへのコンバータ・アプライアンスで問題が発生します。これは、これらのアプライアンスによってSSLセッションが終了され、転送されたメッセージとともにクライアント側のX.509証明書情報を提供する標準的な方法がないためです。クライアント側の証明書が、サイトや仮想ホストへのアクセスの許可または拒否にのみ使用される場合は、このソリューションを適用できます。ただし、アプリケーションまたはその他のインフラストラクチャ項目で証明書情報が必要な場合は、カスタム・ソリューションが必要となります。
現時点では、クライアント側の証明書は頻繁に使用されないため、この考慮事項は（ほとんどのサイトで）重要ではありません。このようなデバイスでクライアント側のX.509証明書を使用する可能性がある場合は、標準でサポートされるソリューションを開発中のため、オラクル社またはアプライアンス・プロバイダに連絡してください。
オラクル社でのテストは、様々なOracle Collaboration Suiteおよびベンダー・コンポーネントを使用して行われました。
次の項では、Oracle Collaboration Suiteのコア・コンポーネントの配置に関する特定の推奨事項について説明します。その次の項では、他のOracle Collaboration Suiteコンポーネントの特定のテスト済構成について説明します。オラクル社でテストされた構成には、次のハードウェアが含まれています。
Check Point Firewall-1 NG（Dell GX-1にインストール）
Cisco CSS 11050
Cisco Catalyst 6506 W/Content Switching Moduleブレード
Cisco PIX 520
F5 Networks BIG-IP 520および540
Nortel Alteon ACEdirector
SonicWall SSL-R3
Radware WSD、CID Fireproof、LinkproofおよびCT-100
次に、テストを行った際の注意事項を示します。
永続性: Radware、F5、Nortel ACEdirectorおよびCisco CSS 11050の場合、ヘッダーに挿入されたアクティブなHTTP Cookieを使用しました。これらのCookieの有効期限を0（ゼロ）に設定しました。これによって、これらのCookieがセッションCookieになります。
バランス方法: テストしたデバイスには、それぞれ異なるトラフィック・バランシング・アルゴリズムが用意されています。今回のテストでは、ラウンド・ロビンによる巡回的処理のみを行いました。
プロキシ: Sonic Wall SSL-R3および組込みF5 HTTPSアクセラレータの両方が、同様のアプリケーション構成ルールを持つプロキシとして機能します。
プール: ロード・バランシング・プールは、均衡化された2つまたは3つのデバイスで構成されています。
ロード: テストは、軽量のロード（シミュレーション・クライアントが10）および中程度のロード（シミュレーション・クライアントが50を超える）で行われました。これらのテストは、最大ロードを決定することを目的とはしていません。
Oracle Collaboration Suiteに関連付けられたコア・コンポーネント（Oracle Application Server Web Cache、Oracle HTTP Server、Oracle Internet Directory、Oracle Application Server Single Sign-On、様々な中間層プロトコル・サーバー、OC4Jなど）には、多くの許容可能な構成があります。これらの構成は、使用されるコンポーネント、必要なスケーラビリティの程度、セキュリティ要件および高可用性要件によって異なります。次の項では、代表的なテスト済構成について説明します。これらの構成は、このドキュメントで前述した接続を前提としています。
図3に、特別な高可用性またはスケーラビリティ要件がない場合のOracle Collaboration Suiteのコア・コンポーネントの推奨構成を示します。図3では、1つのOracle Collaboration Suite Middle-Tierインスタンスを除き、すべてのOracle Collaboration SuiteコンポーネントがDMZ内に存在しています。
許容可能なイントラネット・セキュリティを提供するための1つのルールとして、すべての着信メッセージを、まず、DMZのデバイスによって処理してからイントラネットに転送する必要があります。これは、障害を封じ込めるためのルールです。DMZに接続されたデバイスが攻撃によって影響を受けた場合でも、損害はイントラネット全体ではなくDMZデバイスに制限されます。イントラネット・デバイスに対する攻撃が成功した場合、その損害を抑えることは非常に難しくなります。
DMZにバス接続よりスイッチ接続をお薦めする理由は、これらのデバイス間のプロトコルが暗号化されていない場合があるためです。たとえば、Oracle HTTP ServerとOC4Jとの間のApache Jserv Protocol（AJP）は暗号化されません。スイッチ接続を使用すると、1つのDMZデバイスへの侵入に成功しても、このデバイスで別のDMZ通信を読み取ることはできません。各接続間のセキュリティ制限を実行できるスイッチ装置を使用する理由は、侵入が成功した場合、この装置によって損害を制限できるためです。
高可用性は、多くのアプリケーションで非常に重要です。インターネット・アプリケーションに高可用性を提供する場合は、ロード・バランシング製品が重要となります。
|
注意: 高可用性を実現するには、OracleAS Single Sign-OnおよびOracle Internet Directoryなどの重要なリソースを同じハードウェア上に配置する必要がある場合があります。この場合、冗長CPUが無視されると、正常な操作に必要なハードウェアの数が少なくなるため、信頼性が向上します。 |
図3では、Oracle Collaboration Suite Middle-Tierインスタンスは、DMZおよびイントラネットの両方に存在しています。ここでは、ペア単位のルールまたは複数のファイアウォールを持つスイッチ装置が存在していることが前提となっています。たとえば、インターネット、ファイアウォール、Oracle HTTP Server/OracleAS Single Sign-On、ファイアウォール、Oracle Collaboration Suite Middle-Tierインスタンス/Oracle Internet Directory、ファイアウォール、イントラネットのような順序になります。
OracleAS Web CacheをHTTPSアクセラレータとともに使用すると、多くのアプリケーションのパフォーマンスが大幅に向上します。
OracleAS Web Cacheを追加すると、Oracle HTTP Serverのフロント・エンドとして配置されます。これらの接続はスイッチ接続であるため、フロントまたはバックという概念はありません。ただし、ペア単位のルールを持つスイッチ装置を使用する場合、OracleAS Web Cacheは、Oracle HTTP Serverのフロント・エンドとして配置されます。
OracleAS Web Cacheの構成にロード・バランサが含まれている場合は、OracleAS Web Cacheへのアクセスに使用するURLを構成する際にロード・バランサのアドレスが使用されます。また、ネットワーク内の他のコンポーネント（OracleAS Single Sign-On、Oracle HTTP Server、Oracle Internet Directoryなど）に、関連付けられたハードウェア・ロード・バランサがあることにも注意してください。
前述のとおり、OracleAS Single Sign-OnおよびOracle Internet Directoryは、特定のサイトで多くのアプリケーション・サブシステムおよびインフラストラクチャ・セットによって使用される可能性があるため、これらの高可用性を構成することが重要になります。したがって、OracleAS Single Sign-OnまたはOracle Internet Directoryでは、スケーラビリティが重要な問題とならない場合も、高可用性の理由から、ロード・バランサの使用を検討する必要があります。
図4に、OracleAS Single Sign-On Serverの推奨ロード・バランシング構成を示します。この構成では、OracleAS Single Sign-On Serverは、インターネット・デバイスで必要なアクセスを可能にするため、DMZに接続されています。
OracleAS Single Sign-On Serverのこのロード・バランシング構成には複数のデータベースが含まれていないため、可用性を向上させるためにOracle Real Application Clusterで構成されたデータベースを使用することをお薦めします。この図の高可用性構成にOracle Internet Directoryサーバーは含まれていませんが、この構成については後述します。次の項で説明するように、OracleAS Single Sign-Onは、Oracle HTTP Serverのmod_ossoおよびOracleAS Portalでテスト済です。
HTTPSからHTTPへの変換アプライアンスでは、保護されているトランザクション用の個別のOracle HTTP Serverハードウェアへのルーティング、または保護されているトランザクション・アクセスと保護されていないトランザクション・アクセスの両方を提供するハードウェア上の個別のポートへのルーティングを行うことができます。HTTPS処理のパフォーマンスが重要な場合は、これらのアプライアンスを使用することをお薦めします。図5に、Oracle HTTP Serverの前でアクセラレータが使用されるアーキテクチャを示します。
この図では、HTTPSアクセラレータは、ロード・バランサとは別のデバイスとして示されています。この構成は、Sonic Wallを使用した場合のテスト済構成です。F5を使用した場合のテスト済構成では、HTTPSからHTTPへの変換アクセラレータはロード・バランサの一部になります。いずれのHTTPプロセッサもSSLを実行しないことに注意してください。
別のアーキテクチャでは、HTTPSアクセラレータの出力を通常のHTTPサーバーにルーティングできますが、別のポート・アドレスを使用します。これによって、実際にSSLで保護されているメッセージと保護されていないメッセージをサーバーで区別できます。
OracleAS Portalは、重要なOracleテクノロジとして、多くのアプリケーションで使用されています。また、ユーザー・アプリケーションでも使用されています。ファイアウォールおよびロード・バランサは、Portalアプリケーション用の安全でパフォーマンスに優れたユーザー・インタフェースを実現する場合に重要となります。
OracleAS Portalは、実行時の主要機能、ユーザーのプロビジョニング、DB Explorer、Portlet Builder、Content ManagementとPage User InterfaceおよびProviderに対して広範囲にわたってテストされています。図6に、Portalの配置を示します。Portalの配置には、OracleAS Single Sign-On、Oracle Internet Directory、Oracle HTTP ServerおよびOC4Jが必要です。OracleAS PortalのParallel Page Engine（PPE）は、OC4J上で動作します。OracleAS Single Sign-Onは、ログイン・アクセスに使用されます。OracleAS Single Sign-Onでは、Oracle Internet Directoryをコールしてユーザー情報を取得します。OracleAS Portalでは、Single Sign-Onツールキットを介してmod_ossoと同等の機能が独自に提供されるため、mod_ossoは使用されません（図4を参照）。
図6に、テスト済のOracleAS Portalアーキテクチャを示します。Oracle HTTP Serverでは、ロード・バランシングが行われ、OC4Jで実行されているPPEにOracleAS Portalリクエストを転送します。PPEでは、HTTPを介してこれらのリクエストをプロバイダに転送し、mod_plsqlを使用してデータベースへのデータベース・リクエストを行います。PPEは、ロード・バランサのURLを使用してOracle HTTP Serverにアクセスするように構成されています。
このドキュメントに向けての製品の構成および管理のテストには、OracleAS Enterprise Managerを使用しました。これらの製品には、Oracle Internet Directory、Oracle HTTP Server、OC4J、Jserv、OracleAS Web Cacheなどがあります。Oracle Application Server Enterprise Managerは、この目的に有効でした。
Oracle Internet Directoryは、スケーラビリティの欠如によって多くのアプリケーションのパフォーマンスが低下する可能性がある場合、および可用性の低下によってビジネス処理が完全に停止する可能性がある場合に重要なコア・テクノロジです。Oracle Internet Directoryのロード・バランサによって実現できるスケーラビリティおよび可用性は、アプリケーションの許容可能な配置のための重要な要素となります。
図7に、Oracle Internet Directoryの高可用性構成を示します。この構成はテスト済ではありませんが、高可用性およびロード・バランシングのために多くのクライアントでこのような構成が必要となるため、ここで説明しています。
Oracle Internet Directoryでは、Oracle Internet Directoryインスタンスごとに個別のデータベースが提供されることに注意してください。これらの個別のデータベースは、アドバンスト・レプリケーションおよびレプリケートされたデータを処理するOracle Internet Directory機能を使用して、相互に同期化できます。これによって、優れたフォルト・トレランス機能が提供されます。また、この構成は、様々な地域から高速アクセスできるように、世界規模での配置に使用することもできます。
オラクル社では、多くの一般的なファイアウォール、ロード・バランサおよびHTTPSからHTTPへの変換アプライアンスとともに使用した場合のOracle Collaboration Suiteのコア・コンポーネントの推奨構成を実際に構成し、テストしました。これらのテストの結果に基づいて、Oracle製品のインターネット配置に必須となるこれらの製品とともに使用した場合に、Oracle Collaboration Suiteコンポーネントが正常に機能することを確認しています。
テストでは、Oracle製品とベンダー製品の両方に問題が検出されました。これらの問題はすべて修正され、修正プログラムがOracle Collaboration Suiteリリース2の初期リリースで出荷されています。このドキュメントに記載されているベンダーの現在出荷中の製品にも、対応する修正プログラムが組み込まれているか、または対応する修正プログラムが製品ベンダーから提供されています。
ファイアウォール、ロード・バランサおよびHTTPSからHTTPへの変換アプライアンスとOracle Collaboration Suiteコンポーネントの統合テストは、ベンダー製品を追加するのみでなく、より広範囲のOracle製品（現行および将来のバージョン）が対象となるように拡張されます。
インターネット-DMZ-イントラネット・アーキテクチャの詳細は、次のURLの「HTTPセキュリティにおけるBest Practices」を参照してください。
http://otn.oracle.co.jp/products/9ias/archive1022.html
このドキュメントには、HTTPセキュリティの他の領域に関する重要な推奨事項も含まれています。
