| Oracle® Fusion Middleware Oracle HTTP Serverの管理 12c (12.2.1) E69936-01 |
|
 前 |
 次 |
この付録では、Oracle HTTP Server (OHS)に関するよくある質問とそれに対する回答について説明します。内容は次のとおりです。
C.4項「Oracle HTTP ServerにApache HTTP Serverのセキュリティ・パッチを適用できますか」
C.5項「Oracle HTTP ServerのApache HTTP Serverバージョンをアップグレードできますか」
C.9項「REDIRECT_ERROR_NOTESが、「ファイルが見つかりません」というエラーに設定されていないのはなぜですか」
C.15項「Oracle HTTP ServerはOracle WebLogic Serverのフロントエンドになれますか」
該当する場合は、Apache Software Foundationのドキュメントを参照しています。
|
注意: このガイドをPDF版またはハード・コピー形式でご利用いただく場合、HTML形式でのみのご提供となるサードパーティのドキュメントを参照できません。文中で参照されているサードパーティのドキュメントをご利用いただくためには、このガイドのHTML版をご利用のうえ、文中のハイパーリンクをクリックしてください。 |
Oracle HTTP Serverには、エラー処理用のデフォルトのコンテンツ・ハンドラが用意されています。ErrorDocumentディレクティブを使用すると、デフォルトをオーバーライドできます。
(Apache 2.4が必要)
HTTPの場合、Oracle HTTP Serverでは、名前ベースとIPベースの両方の仮想ホストがサポートされます。名前ベースの仮想ホストは共通のリスニング・アドレス(IPとポートの組合せ)を共有する仮想ホストですが、クライアントにより送信されたHostヘッダーとVirtualHost内のServerNameディレクティブの間の一致に基づいてリクエストをルーティングします。IPベースの仮想ホストは、固有のリスニング・アドレスを持つ仮想ホストです。IPベースの仮想ホストは、リクエストが受信されたアドレスに基づいてリクエストをルーティングします。
HTTPSの場合、Oracle HTTP Serverで使用できるのはIPベースの仮想ホストのみです。これは、名前ベースの仮想ホストの場合、リクエストを処理する仮想ホストを判別するために、リクエストを読み取って調査する必要があるためです。HTTPSが使用されている場合、リクエストを読み取る前にSSLハンドシェイクを実行する必要があります。SSLハンドシェイクを実行するためには、サーバー証明書を提供する必要があります。意味のあるサーバー証明書を提供するには、証明書のホスト名が、クライアントがリクエストしたホスト名に一致する必要があります。これは、仮想ホストごとにサーバー証明書が一意であることを意味します。しかし、サーバーはリクエストを読み取るまで、そのリクエストのルーティング先の仮想ホストを認識できず、また提供するサーバー証明書がわからなければリクエストを適切に読み取ることもできないため、HTTPSでは名前ベースの仮想ホスティングを行うことは不可能です。
使用できます。Apache HTTP Serverの機能に与えられた汎用名であるMultiviewsを使用すると、リクエストに対するレスポンスで様々なバージョンの言語と文字固有のドキュメントを提供できます。
|
関連項目: コンテント・ネゴシエーションの詳細は、次のApache HTTP ServerのドキュメントのMultiviewsオプションを参照してください。
|
次の理由で、Oracle HTTP ServerにはApache HTTP Serverセキュリティ・パッチを適用できません。
OracleではOracle HTTP Serverユーザーにリリースする前に、セキュリティ・パッチをテストして適切に変更しています。
Oracleではセキュリティ・パッチのコンポーネントをスタックから削除しているため、多くの場合、OpenSSLアラートなどのApache HTTP Serverアラートは適用できません。
Oracle HTTP Serverに対するセキュリティ関連の最新の修正は、Oracle Critical Patch Update (CPU)を介して実行します。詳細は、OracleのWebページ「Critical Patch Updates and Security Alerts」を参照してください。
|
注意: CPUを適用した後、Apache HTTP Serverベースのバージョンがそのまま残っていることがありますが、脆弱性は修正されます。バージョンを確認できるサード・パーティのセキュリティ検出ツールがありますが、これらのツールで脆弱性そのものを確認することはできません。 |
Oracle HTTP Server内のApache HTTP Serverバージョンのみをアップグレードすることはできません。Oracle HTTP ServerのベースとなるApache HTTP Serverの新バージョンが、パッチ更新またはOracle Fusion Middlewareの次期メジャー・リリースかマイナー・リリースの一部として提供されます。
一般に、Oracle HTTP Serverに組み込まれているmod_deflateを使用することをお薦めします。mod_deflateに関する詳細は、http://httpd.apache.org/docs/current/mod/mod_deflate.htmlを参照してください。
一般的には、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にリクエストが送信されるように構成することで、最小限に抑えることが可能です。
Webサイトの保護に関する一般的なガイドラインは、次のとおりです。
ISPとWebサーバーの間に市販のファイアウォールを使用します。
切替式のイーサネットを使用して、セキュリティを破られたサーバーにより検出される可能性のある通信量を制限します。Webサーバー・マシンと、データベースやエンタープライズ・アプリケーションを実行中の機密性の高い内部サーバーの間に、追加のファイアウォールを使用します。
RPC、Finger、telnetなど、不要なネットワーク・サービスをサーバーから削除します。
Webフォームからの入力と、アプリケーションからの出力を常にすべて検証します。エンコーディング、長い入力文字列、印刷不能文字やHTMLタグ、またはJavaScriptタグを含む入力は必ず検証してください。
重要情報を含むCookieの内容は、暗号化します。
すべてのシステムとアプリケーション・ソフトウェアのセキュリティ・パッチを頻繁にチェックし、入手後すぐにインストールします。パッチは、OracleまたはOracleサポート担当者からのもののみ受け入れます。
該当する場合は、侵入検出パッケージを使用して、改変されたWebページ、ウィルスおよびrootkitの有無を監視します。可能な場合は、システムの実行可能ファイルとWebのコンテンツを読取り専用ファイル・システムにマウントしてください。
アプリケーションに対して侵入テストやその他の適切なセキュリティ・テストを使用することを検討してください。アプリケーションを保護するために適切なカスタムmod_securityルールを使用してWebセキュリティを構成することを検討してください。mod_securityの詳細は、5.4項「mod_securityモジュールの構成」および9.6項「mod_securityの使用」を参照してください。
不要なコンテンツをhttpd.confファイルから削除します。詳細は、5.3.9項「不要コンテンツへのアクセスの削除」を参照してください。
Webページをクリックジャック攻撃から保護するための予防措置を講じます。インターネットには多くの使用可能な参考情報があります。クリックジャックの詳細は、Oracle DatabaseおよびFusion Middlewareのセキュリティ脆弱性に関するFAQ (Doc ID 1074055.1)のセキュリティのベスト・プラクティスに関する項を参照してください。
Apache HTTP Serverとの互換性によって、この条件でのCGIおよび他のアプリケーションで、この情報を使用可能にしていないため、Oracle HTTP Serverでは、REDIRECT_ERROR_NOTES CGI環境変数は「ファイルが見つかりません」というエラーに設定されていません。
この情報をWebサーバーで生成されたレスポンスから削除するには、ServerSignature Offを指定します。Oracle HTTP ServerがWebサーバー・レスポンス・ヘッダーを生成したときにWebサーバー・ソフトウェアを非表示にするには、ServerTokens Custom some-server-stringを指定します。(バックエンド・サーバーがレスポンスを生成するときは、プロキシ・メカニズムに応じてバックエンド・サーバーからサーバー・レスポンス・ヘッダーが生成される場合があります。)
|
注意: ServerTokens Custom some-server-stringは、Oracle HTTP Server 10gのServerHeader Off設定の置換文字列です。 |
Oracle HTTP Server 12c (12.2.1)のプロセス管理はノード・マネージャによって処理されます。startComponentコマンドを使用して、WLSTまたはFusion Middleware Controlを直接使用せずに、Oracle HTTP Serverを起動することができます。詳細は、4.3.3.3項「コマンド行を使用したOracle HTTP Serverインスタンスの起動」を参照してください。
デフォルトでは、Oracle HTTP Serverは、UNIXでの予約済の範囲内にあるポート(通常1024未満)にバインドできません。4.3.3.4項「特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)」の手順に従って、Oracle HTTP Serverが予約済の範囲内にあるポート(たとえば、デフォルトのポート80)でリスニングするようにできます。
mod_wl_ohsモジュールがWebLogic Serverにリクエストを転送する、Oracle HTTP Serverの前あるいはその中で、SSLを使用してリクエストを停止できます。リクエストがOracle HTTP Serverに届く前にSSLを停止するか、リクエストがサーバーの中にある時に停止するかは、トポロジによります。詳細は、8.7.1.1項「ロード・バランサでのSSLの停止」および8.7.2.1項「Oracle HTTP ServerでのSSLの停止」を参照してください。
Secure Sockets Layer (SSL)のサポートは、Oracle WebLogic Serverプラグインにより提供されます。SSLプロトコルを使用することで、プラグインとOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、プラグインとWebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。SSLライブラリの設定およびWebサーバーとOracle WebLogic Server間の一方向または双方向のSSL通信の設定については、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のプラグインを使用したSSLの使用に関する項を参照してください。
SSLをOracle HTTP Serverでは構成し、Oracle WebLogic Serverでは構成しない場合、Oracle HTTP Serverから送信されるリクエストに対するSSLを停止できます。このシナリオの構成の詳細は、8.7.2.1項「Oracle HTTP ServerでのSSLの停止」を参照してください。
Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。サーバーはWebLogic Management Frameworkを活用して、Oracle HTTP Server、Oracle WebLogic Serverおよびその他のFusion Middlewareスタックを管理するための簡単で一貫性のある分散環境を提供します。これは、組込みのOracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohsモジュール)を使用し、静的コンテンツを内部からホストすることによって、HTTPのフロントエンドとして機能して、動的コンテンツのリクエストをWebLogic管理対象サーバーにルーティングします。
Oracle HTTP Serverをインストールできるトポロジの詳細は、1.2項「Oracle HTTP Server 12c (12.2.1)のトポロジ」を参照してください。
Oracle HTTP Serverはスタンドアロン、Full-JRFまたはRestricted-JRFドメインのいずれかにインストールできます。スタンドアロン・ドメインは、Oracle HTTP Serverなどのシステム・コンポーネントのコンテナです。これはオーバーヘッドが最小のため、DMZ環境に理想的です。スタンドアロン・ドメインにはOracle WebLogic Serverドメインに類似したディレクトリ構造がありますが、これには管理サーバー、管理対象サーバーまたは管理サポートは含まれていません。スタンドアロン・ドメインには、同一タイプのシステム・コンポーネント(Oracle HTTP Serverなど)、またはタイプの混在したシステム・コンポーネントの1つ以上のインスタンスが含まれます。
WebLogic ServerドメインではすべてのWebLogic Management Frameworkツールがサポートされています。Oracle WebLogic ServerドメインはFull-JRFまたはRestricted JRFのいずれかです。Full-JRFモードのWebLogic Serverドメインには、WebLogic管理サーバー、0台以上のWebLogic管理対象サーバーおよび0個以上のシステム・コンポーネント・インスタンス(Oracle HTTP Serverインスタンスなど)が含まれます。このタイプのドメインは、システム全体に存在するFusion Middleware ControlおよびWebLogic Management Frameworkを介して拡張管理機能を提供します。WebLogic Serverドメインは、複数の物理マシンにまたがって設定でき、管理サーバーによって一元管理されます。これらのプロパティのために、WebLogic Serverドメインは、使用しているシステムのコンポーネントとJava EEコンポーネント間の最高の統合を提供します。
Restricted-JRFドメインは12.2.1リリースの新機能で、WebLogicサーバー・ドメインを使用してOracle HTTP Serverの管理を簡素化することが目的です。Oracle WebLogic ServerのRestricted-JRFドメインは、外部データベースへの接続が必要ない点を除き、Full-JRFドメインと似ています。Fusion MiddleWare ControlおよびWLSTを介するOracle HTTP Server機能のすべては引き続き使用可能です。
これらの各ドメインの詳細は、1.4項「ドメイン・タイプ」を参照してください。
Oracle HTTP Serverはレスポンス・データをキャッシュするApache mod_cacheおよびmod_cache_diskモジュールを含むようになりました。
mod_cacheおよびmod_cache_diskでの詳細は、Apacheドキュメントのmod_cacheに関する項を参照してください。
各VirtualHostディレクティブ内で、Apache LogFormatおよびCustomLogディレクティブを使用して、仮想ホスト固有のアクセス・ログ形式およびログ・ファイルを構成できます。詳細は、8.4.2.3項「LogFormat」および8.4.2.4項「CustomLog」を参照してください。
