B よくある質問

この付録では、Oracle HTTP Serverに関してよくある質問とそれに対する回答について説明します。

該当する場合は、Apache Software Foundationのマニュアルを参照しています。

B.1 アプリケーション固有のエラー・ページはどのように作成しますか

Oracle HTTP Serverには、エラー処理用のデフォルトのコンテンツ・ハンドラが用意されています。ErrorDocumentディレクティブを使用すると、デフォルトを上書きできます。

B.2 HTTPおよびHTTPSでは、どのタイプの仮想ホストがサポートされますか

HTTPの場合、Oracle HTTP Serverでは、名前ベースとIPベースの両方の仮想ホストがサポートされます。名前ベースの仮想ホストは共通のリスニング・アドレス（IPとポートの組合せ）を共有する仮想ホストですが、クライアントにより送信されたHostヘッダーとVirtualHost内のServerNameディレクティブの間の一致に基づいてリクエストをルーティングします。IPベースの仮想ホストは、固有のリスニング・アドレスを持つ仮想ホストです。IPベースの仮想ホストは、リクエストが受信されたアドレスに基づいてリクエストをルーティングします。

HTTPSの場合、Oracle HTTP Serverで使用できるのはIPベースの仮想ホストのみです。これは、名前ベースの仮想ホストの場合、リクエストの処理に使用する仮想ホストを判別するために、リクエストを読み取って調査する必要があるためです。HTTPSが使用されている場合、リクエストを読み取る前にSSLハンドシェイクを実行する必要があります。SSLハンドシェイクを実行するためには、サーバー証明書を提供する必要があります。サーバー証明書が有効であるためには、証明書のホスト名と、クライアントがリクエストしたホスト名とが一致している（つまり、仮想ホストごとに固有のサーバー証明書がある）必要があります。しかし、サーバーはリクエストを読み取るまで、そのリクエストのルーティング先の仮想ホストを認識できず、また提供するサーバー証明書がわからなければリクエストを適切に読み取ることもできないため、HTTPSでは名前ベースの仮想ホスティングを行うことは不可能です。

注意:

これはOracle HTTP Serverの制約ではなく、HTTPSプロトコル自体の制約です。

B.3 Oracle HTTP Serverをキャッシュとして使用できますか

ProxyRequestsおよびCacheRootディレクティブを使用すると、Oracle HTTP Serverをキャッシュとして使用できます。しかし一般には、Oracle HTTP ServerではなくOracle Web Cacheを使用することをお薦めします。Oracle Web Cacheはコンテンツ対応のサーバー・アクセラレータであり、セキュアなリバース・プロキシ・サーバーであるため、Webサイトのパフォーマンス、スケーラビリティおよび可用性を高めます。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

B.4 異なる言語およびキャラクタ・セット・バージョンのドキュメントを使用できますか

使用できます。Apacheサーバーの機能に与えられた汎用名であるMultiviewsを使用すると、リクエストに対するレスポンスで様々なバージョンの言語と文字固有のドキュメントを提供できます。

B.5 ファイアウォールの内側にあるOracle HTTP Serverにプロキシ依存のリクエストをどのように送信しますか

CacheディレクティブではなくProxyディレクティブを使用して、ファイアウォールを介してプロキシ依存のリクエストを送信してください。

B.6 Oracle HTTP ServerにApacheセキュリティ・パッチを適用できますか

適用できません。次の理由で、Oracle HTTP ServerにはApacheセキュリティ・パッチを適用できません。

OracleではOracle HTTP Serverユーザーにリリースする前に、セキュリティ・パッチをテストして適切に変更しています。
Oracleではセキュリティ・パッチのコンポーネントをスタックから削除しているため、多くの場合、openSSLアラートなどのApacheアラートは適用できません。
Oracleでは、パッチを入手する際の影響がオープン・ソース組織から入手する場合と比較して最小限になるように、適宜パッチをリリースしています。Oracleのパッチを使用することは、サポート面で非常に大きなメリットとなります。

Oracle HTTP Serverに対するセキュリティ関連の最新の修正は、Oracle Critical Patch Update（CPU）を介して実行します。詳細は、OracleのWebページ「Critical Patch Updates and Security Alerts」を参照してください。

注意:

CPUを適用した後、Apacheベースのバージョンがそのまま残っていることがありますが、脆弱性は修正されます。バージョンを確認できるサード・パーティのセキュリティ検出ツールがありますが、これらのツールで脆弱性そのものを確認することはできません。

B.7 Oracle HTTP ServerのApacheバージョンをアップグレードできますか

できません。Oracle HTTP Server内のApacheバージョンのみをアップグレードすることはできません。Oracle HTTP ServerのベースとなるApacheの新バージョンが、パッチ更新またはOracle Fusion Middlewareの次期メジャー・リリースかマイナー・リリースの一部として提供されます。

B.8 Oracle HTTP Serverからの出力を圧縮できますか

一般に、この目的ではOracle Web Cacheを使用することをお薦めします。他にもこの目的のためにプラグインできるフリーウェア・モジュール（たとえば、mod_gzipなど）がありますが、その使用はサポートされていません。Oracle Web Cacheでは、オンザフライの圧縮を使用し、圧縮可能なMIMEタイプを動的に認識し、低速のネットワーク・クライアントへのレスポンスを制限することによって、効率的なコンテンツの配信を実現します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

B.9 ファイアウォールおよびクラスタを介して機能するネームスペースはどのように作成しますか

一般的には、1つの分散Webサイトの全サーバーで、単一のURLネームスペースを使用する必要があります。すべてのサーバーでネームスペースの一部を処理し、処理しないURLのリクエストをそのURLにより近いサーバーにリダイレクトまたはプロキシできます。たとえば、次のようなネームスペースがあるとします。

/app1/login.html
/app1/catalog.html
/app1/dologin.jsp
/app2/orderForm.html
/apps/placeOrder.jsp

最初に、server1にapp1、server2にapp2を置いて、これらのネームスペースを2つのWebサーバーにマップします。server1の構成は次のようになります。

Redirect permanent /app2 http://server2/app2
Alias /app1 /myApps/application1
<Directory /myApps/application1>
  ...
</Directory>

server2の構成は補足的です。

ネームスペースをコンテンツ・タイプ（server1ではHTML、server2ではJSP）別にパーティション化すると決定した場合、サーバー構成を変更してファイルを移動できますが、アプリケーション自体を変更する必要はありません。その結果、server1の構成は次のようになります。

RedirectMatch permanent (.*) \.jsp$ http://server2/$1.jsp
AliasMatch ^/app(.*) \.html$ /myPages/application$1.html
<DirectoryMatch "^/myPages/application\d">
  ...
</DirectoryMatch>

実際のリダイレクションの量は、ハードウェアのロード・バランサ（F5システムのBIG-IPなど）を、URLに基づいてserver1またはserver2にリクエストが送信されるように構成することで、最小限に抑えることが可能です。

B.10 Webサイトをハッカーからどのように保護しますか

ハッカーによる攻撃は多く、日々新しい攻撃が開発されています。サイトの保護に関する一般的なガイドラインは、次のとおりです。サイトを完全に保護することはできませんが、攻撃されさやすいターゲットとなることは回避できます。

Oracle HTTP Serverに付属のmod_securityモジュールを構成します。ModSecurityは、Webアプリケーションへの攻撃を事前に検出して回避するための増強された外部セキュリティ層を提供するWebアプリケーション・ファイアウォールです。
ISPとWebサーバーの間に、Checkpoint FW-1やCisco PIXのような市販のファイアウォールを使用します。ただし、すべてのハッカーが組織の外にいるわけではないことに注意してください。
切替式のイーサネットを使用して、セキュリティを破られたサーバーにより検出される可能性のある通信量を制限します。Webサーバー・マシンと、データベースやエンタープライズ・アプリケーションを実行中の機密性の高い内部サーバーの間に、追加のファイアウォールを使用します。
RPC、Finger、telnetなど、不要なネットワーク・サービスをサーバーから削除します。
Webフォームからのすべての入力を慎重に検証します。特に、長い入力文字列や、印刷不能文字、HTMLタグまたはJavaScriptタグを含む入力には注意してください。
機密情報を含むCookieの内容を暗号化（ランダム化）して、ハッカーによる有効なセッションのハイジャックを防止します。たとえば、有効なセッションIDを推測しにくくする必要があります。
すべてのシステムとアプリケーション・ソフトウェアのセキュリティ・パッチを頻繁にチェックし、入手後すぐにインストールします。これらのパッチは必ず信頼できるソースから入手してください。パッチは信頼できるサイトからのみダウンロードし、暗号チェックサムを検証します。
侵入検出パッケージを使用して、改変されたWebページ、ウイルスおよびハッカーがサイトに侵入したことを示すrootkitの有無を監視します。可能な場合は、システムの実行可能ファイルとWebのコンテンツを読取り専用ファイル・システムにマウントしてください。
法的分析パッケージを用意して、侵入が検出されたらすぐにその証拠を取得します。これは、ハッカーを告発する際に役立ちます。

B.11 SSLの有効化と無効化を切り替える場合、SSOサーバーにパートナ・アプリケーションを再登録する必要がありますか

あります。SSLの有効化と無効化を切り替える場合、SSOサーバーにパートナ・アプリケーションを再登録する必要があります。URLに影響を与える変更（ホスト名やポートの変更、SSLの有効化または無効化など）を行う場合、SSOサーバーに登録された古いURLは無効になるため、SSOサーバーにパートナ・アプリケーションを再登録する必要があります。新しいURLを使用してパートナ・アプリケーションを再登録してください。