| Oracle Fusion Middleware Oracle Web Cache管理者ガイド 11g リリース1(11.1.1) B56248-02 |
|
 前 |
 次 |
Webコンテンツへのユーザー・アクセスを制御する機能、および侵入から保護する機能は、エンタープライズ・デプロイメントに影響する重要な課題です。この章では、Oracle Web Cacheのセキュリティを構成する方法について説明します。
セキュリティの詳細は、Oracle Fusion Middlewareセキュリティ・ガイドを参照してください。
この章の項目は次のとおりです。
この項では、Oracle Web Cacheのセキュリティ・モデルについて説明します。次のトピックが含まれます:
Oracle Web Cacheでは、次のセキュリティ関連の機能が提供されています。
|
注意: Oracle Web Cacheは、HTTPの認証タイプの1つであるBasic認証をサポートしているページをキャッシュしません。したがって、これらのページはキャッシュ・ミスになります。 |
Oracle Web Cacheでは、次の機能によって管理を制限します。
管理および無効化処理のパスワード認証
管理および無効化処理に使用されるポートの制御
IPおよびサブネットの管理制限
HTTPSプロトコル(HTTP over SSL)を使用して、ネットワーク・トラフィックは暗号化されます。Oracle Web Cacheでは、HTTPクライアント、管理、無効化および統計のリクエストを含めて、そのすべてのネットワーク・トラフィックでHTTPSがサポートされ、そのオリジン・サーバーとキャッシュ・クラスタ・ピアとの通信でもHTTPSがサポートされます。
図5-1に示すように、クライアントからのHTTPSリクエストを受信し、オリジン・サーバーにHTTPSリクエストを送信するようにOracle Web Cacheを構成できます。
オリジン・サーバーにリクエストを送信するとき、HTTPS通信の場合にはプロセッサに負荷がかかることがあります。Oracle Web Cacheからオリジン・サーバーへの通信で、オープンなインターネットを経由する必要がある場合は、オリジン・サーバーにHTTPSリクエストを送信するようにOracle Web Cacheを構成します。データ・センター内のLANによる通信のみ行う場合は、オリジン・サーバーの負荷を軽くするためにHTTPの使用を検討します。
Oracle Web Cacheでは、サーバー側の証明書とクライアント側の証明書の両方がサポートされます。SSLサーバー証明書を使用するとサーバーの信頼性を検証でき、SSLクライアント証明書を使用すると、特定のクライアントへのアクセスを制限できます。ただし、SSLのみを使用してユーザー検証を行うことは一般にはありません。
この項では、次の項目について説明します。
認証局(CA)は、サード・パーティや、ユーザー、データベース、管理者、クライアント、サーバーなど、その他のエンティティの識別情報を証明する、信頼できる第三者機関です。認証局は、当事者の識別情報を検証し、秘密鍵で署名された証明書を付与します。Oracle Web Cacheで使用する証明書は、CAによって署名されている必要があります。
CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAによってはユーザーの運転免許証の提示を必要としたり、別のCAでは証明書リクエスト・フォームの公証や、証明書をリクエストしている当事者の指紋を必要とする可能性があります。
CAは、公開鍵が含まれている独自の証明書を発行します。各ネットワーク・エンティティは、信頼しているCAの証明書のリストを所有しています。あるエンティティが別のエンティティと通信を行う場合、通信を始める前に、このリストを使用して、相手のエンティティの証明書の署名が既知の信頼できるCAのものであるかを検証します。
ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。Oracle Wallet Managerは、デフォルトでVeriSign社、RSA社、Entrust社およびGTE CyberTrust社による信頼できる(トラステッド)証明書とともに自動的にインストールされます。
証明書は、サーバーまたはクライアントなどのネットワーク・エンティティを認証するために使用されるデジタル・データ・レコードです。ある当事者の公開鍵が信頼できるCAによって署名されると作成されます。証明書は、ある当事者の識別情報が正しく、公開鍵が実際にその当事者の所有するものであることを保証します。
証明書には、当事者の名前、公開鍵、有効期限、さらにシリアル番号および証明書チェーン情報が含まれています。また、証明書に関連付けられた権限に関する情報が含まれている場合もあります。
ネットワーク・エンティティが証明書を受信すると、それが信頼できる証明書、つまり信頼できる認証局によって発行および署名された証明書であるか検証します。証明書は、期限切れになるか無効にされるまで有効です。
Oracle Web Cacheは、次の証明書をサポートしています。
サーバー側の証明書: サーバー側の証明書は、通信先のサーバーの識別情報を検証するための手段です。証明書は、サーバーに関する情報をサーバーの公開鍵にバインドするもので、信頼できるCAによって署名される必要があります。
サーバー側の証明書が使用される場合、Oracle Web Cacheは、SSLハンドシェイク時にサーバー証明書をクライアントのブラウザに送信し、その後でオブジェクトに対するリクエストを処理します。リクエストされたオブジェクトがキャッシュに格納されていない場合、キャッシュはリクエストをWebアプリケーション・サーバー、(クラスタ内の)ピア・キャッシュまたは(階層内の)従属キャッシュに転送します。
一意のサイト定義ごとに1つのサーバー側の証明書が必要です。HTTPSでは、単一のポートに対して複数の仮想ホストはサポートされません。たとえば、20のサイトIPアドレスがある環境の場合、ポート番号構成には20の異なる証明書が必要です。
クライアント側の証明書: クライアント側の証明書は、クライアントの識別情報を検証する方法の1つです。証明書は、クライアント・ユーザーに関する情報をユーザーの公開鍵にバインドするもので、信頼できるCAによってデジタル署名される必要があります。証明書失効リスト(CRL)は、SSLハンドシェイクでピアの証明書を検証し、証明書がCAによって発行された失効している証明書のリストにないことを確認します。
クライアント側の証明書を使用する場合、クライアントのブラウザは、SSLハンドシェイク時に証明書をキャッシュに送信し、その後でキャッシュがオブジェクトに対するリクエストを処理します。リクエストされたオブジェクトがキャッシュに格納されていない場合、キャッシュはリクエストをWebアプリケーション・サーバー、(クラスタ内の)ピア・キャッシュまたは(階層内の)別のキャッシュに転送します。クライアント側の証明書に関する情報を別のキャッシュまたはWebアプリケーション・サーバーに転送するために、Oracle Web CacheはリクエストにHTTPヘッダーを追加します。これらのヘッダーは、文字列SSL-Client-Certで始まります。
また、配置に応じて、ピア・キャッシュまたは任意のエンティティ(プロバイダ・キャッシュやリモート・キャッシュなど)からHTTPヘッダーの証明書情報を受け入れるようにキャッシュを構成するか、またはヘッダーの証明書情報を受け入れないようにキャッシュを構成します。
クライアント側の証明書に関して、次の点に注意してください。
クライアント側の証明書は、HTTPSリクエストでは要求されません。クライアント側の証明書は通常、金融、政府または軍事用のアプリケーションなど、PKIに基づくユーザー認証が必要な場合に使用されます。
リスニング・ポートがクライアント証明書を要求すると、接続が拒否されます。サイトがクライアント証明書を要求し、SSLポートが要求しない場合、HTTPエラー「403 禁止」が返されます。
Oracle Web Cacheでは、Oracle HTTP Serverとともに使用する場合にのみクライアント側の証明書の使用がサポートされます。
分散キャッシュ階層では証明書の安全性が保証されないため、Oracle Web Cacheでは、クライアント側の証明書はサポートされていません。
Oracle HTTP ServerではOpenSSL証明書失効リストがサポートされますが、Oracle Web Cacheではサポートされません。クライアント側の証明書を使用する場合は、クライアント側の証明書が失効しているかどうかを確認するようにアプリケーションを変更する必要があります。これを行うには、CGIスクリプトまたはサーブレットを使用します。
Oracle Fusion Middlewareでは、Microsoft Server Gated Cryptography(SGC)証明書またはVeriSign Global Server IDはサポートされません。この暗号方式により、エクスポート・バージョンのブラウザは、アプリケーション・サーバーとの通信時に、弱い40ビットの暗号化から強力な128ビットの暗号化に透過的にアップグレードできます。この暗号方式がないと、弱い40ビットの暗号化を使用するブラウザは、Oracle Fusion Middlewareに対して保護された接続のネゴシエーションを行うことができません。
ウォレットは、SSLに必要な鍵、証明書、および信頼できる証明書などの認証データを管理するためのリポジトリです。ウォレットには、X.509バージョン3証明書、秘密鍵および信頼できる証明書のリストが含まれています。
セキュリティ管理者は、Oracle Web Cacheサーバーのセキュリティ資格証明の管理にOracle Wallet Managerを使用します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。具体的には、Oracle Wallet Managerは次のことを行うために使用されます。
公開鍵と秘密鍵のペアを生成し、認証局に提出する証明書リクエストを作成します。
識別情報用の証明書をインストールします。
識別情報用の信頼できる証明書を構成します。
Oracle Web CacheでHTTPSを構成するには、サポートしている各サイトのOracle Web Cacheサーバーでウォレットを作成します。Oracle Web Cache HTTPSリスニング・ポートおよび操作ポート(受信HTTPSリクエストのサポート用)とオリジン・サーバー(送信HTTPSリクエストのサポート用)のそれぞれに対してウォレットの場所を指定します。1つのウォレットを共有することも、異なるウォレットを作成することもできます。同じウォレットを使用する場合、このウォレットがサポートできるのは1つのサーバー側の証明書のみである点に注意する必要があります。
Oracle Web Cacheでは、デフォルトのウォレットがデフォルトの証明書とともにインストールされますが、これらはテスト目的のみに使用し、本番環境では使用しないでください。デフォルトのウォレットを使用した場合、SSL接続は安全であるとは考えられません。本番環境では、新しいウォレットを作成して新しい証明書を作成するか、または信頼できる証明書をウォレットにインポートしてください。
Oracle Wallet Managerの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
HTTPS接続でのSSLの仕組みの説明では、「クライアント」という用語はブラウザまたはOracle Web Cacheを指し、「サーバー」という用語はOracle Web Cacheまたはオリジン・サーバーを指します。たとえば、ブラウザがクライアントの場合、サーバーはOracle Web Cacheまたはオリジン・サーバーのいずれかになります。一方、Oracle Web Cacheがクライアントの場合は、サーバーはオリジン・サーバーになります。
クライアントとサーバー間の認証プロセスは、次のステップで構成されます。
クライアントとサーバーは、どの暗号(暗号化アルゴリズム)を使用するかを決定します。
SSLは、保護された接続を確立するために、クライアントとサーバー間のハンドシェイクを実行します。
SSLハンドシェイクには次のアクションが含まれます。
クライアントとサーバーは、どの暗号スイートを使用するかを設定します。
サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。
オプションで、サーバーがクライアント証明書をリクエストし、クライアントがサーバーにクライアント証明書を送信することによって応答します。サーバーは、クライアントの証明書が信頼できるCAによって署名されていることを検証します。
クライアントとサーバーが、公開鍵暗号化を使用してキー情報を交換します。この情報に基づいて、それぞれがセッション・キーを生成します。クライアントとサーバーとの間の以降のやりとりはすべて、このセッション・キーのセットと暗号を使用して暗号化/復号化されます。
Oracle Web Cacheでは、SSL処理をWeb層に移動することによってSSLアクセラレータを提供しています。
オフボードのSSLアクセラレータ・ソリューションに加えて、Oracle Fusion Middlewareでは、Oracle Web CacheおよびOracle HTTP Serverが稼働しているサーバーへのデプロイメントのために、ソフトウェアのみのSSL処理とnCipherのBHAPI準拠ハードウェアの両方がサポートされています。ソフトウェアで実行される場合、SSL処理によってサーバーのCPUリソースに重度の負荷がかかるため、スループットが低下し、全体的なパフォーマンスが低下します。nCipherのハードウェアを使用すると、SSLの鍵交換処理によってサーバーのCPUにかかる負荷がなくなるため、同時SSL接続数が増加し、SSL保護コンテンツのレスポンス時間が改善されます。
nCipherの詳細は、http://www.ncipher.comを参照してください。
デフォルトでは、インストールを実行したユーザーがOracle Web Cacheファイルの所有者となります。ほとんどのファイルは、Oracle Web Cache Managerの「Process Identity」ページ(「Properties」→「Process Identity」)で指定したユーザーIDおよびグループIDで読み取ることができます。
プロセス認証ユーザーを変更する場合は、chownコマンドを実行して、Oracle Web Cacheのファイルとディレクトリの所有権を新しいユーザーIDおよびグループIDに手動で変更する必要があります。
Oracle HTTP Serverのmod_accessモジュールによって、ホスト名やIPアドレスなどのリクエストの特性に基づいてURLへのアクセスが制御されます。Oracle Web Cacheでは、URLベースでIPアドレスが制限されることはありません。Oracle Web Cacheでmod_accessを使用している場合は、キャッシュ・ルールを指定しないか、またはコンテンツをキャッシュしないキャッシュ・ルールを明示的に設定して、保護リソースがキャッシュされないようにしてください。
クライアントのIPをOracle HTTP Serverに直接渡すには、httpd.confファイルでOrderディレクティブを構成します。詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。
Oracle Identity Managementインフラストラクチャにより、エンタープライズ全体にまたがるセキュリティの管理が集中化されます。
セキュリティ上の理由により、Oracle Single Sign-Onサーバーからコンテンツをキャッシュしないでください。
Single Sign-Onのパートナ・アプリケーションを実行しているOracle HTTP Serverに対するコンテンツをキャッシュするように、Oracle Web Cacheを構成できます。デフォルトでは、mod_osso保護ページは、Surrogate-Control: no-storeレスポンス・ヘッダーを使用してキャッシュ不可に構成されています。
mod_ossoのデフォルトの動作をオーバーライドするには、httpd.confファイルでOssoSendCacheHeadersをoffに設定します。次に例を示します。
<Location /foo/> OssoSendCacheHeaders off </Location>
この例は、/fooで始まるすべてのURLに対して、キャッシュ・ヘッダーのmod_ossoによる設定を無効にします。これらのURLについては、アプリケーション側で、適宜Surrogate-Controlを組み込んで、キャッシュ制御ヘッダーを設定する必要があります。
Oracle Web Cacheが同じSingle Sign-Onのパートナ・アプリケーションに対するリクエストのロード・バランシングを実行している場合は、Oracle HTTP Serverをクラスタとして構成して、複数のアプリケーションが単一のパートナ・アプリケーションとして機能するようにします。このように構成すると、サーバーに対するリクエストのステートレス・ロード・バランシングを実行するように、Oracle Web Cacheを構成できます。アプリケーションの中間層がクラスタ化されていない場合は、ステートフル・ロード・バランシングを実行する必要があります。
Oracle Single Sign-Onを介して認証を要求するように、Oracle Web Cacheを構成できます。受信リクエストがOracle Web Cacheによって処理されるには、リクエストに有効なOracle Single Sign-OnのCookieが必要です。構成の詳細は、第5.8項を参照してください。
無効化および統計監視用のリクエストを発行する前に、リクエストを送信するためのセキュアなパスワードを確立する必要があります。
invalidatorアカウントは、無効化リクエストの送信を許可された管理者です。キャッシュ内のオブジェクトを無効化するために、invalidatorアカウントはHTTP POSTリクエストを送信します。
administratorアカウントは、Oracle Web Cache Managerにログインし、そのインタフェースを介して構成を変更することを許可されたOracle Web Cache管理者です。この管理者は、Oracle Web Cacheの統計監視用ポートに対する統計監視リクエストの送信も許可されています。Fusion Middleware Controlでメトリックを監視した後に別のパフォーマンス・メトリックが必要となった場合は、administratorアカウントを使用して統計監視用ポートにアクセスして、詳細なパフォーマンス・メトリックを表示できます。第8.4項を参照してください。
これらのアカウントのデフォルトのパスワードは、Oracle Universal Installerの「Web Cache管理者」ページで指定したパスワードです。構成を開始する前に、これらのアカウントのパスワードをセキュアなパスワードに変更します。この構成はFusion Middleware Controlで行う必要があります。
invalidatorおよびmonitorアカウントに対してセキュアなパスワードを確立するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
「Webキャッシュ」メニューから、「管理」→「パスワード」を選択します。
「パスワード」ページが表示されます。
「新規パスワード」フィールドに、新しいパスワードを入力します。このとき、次の制限事項に注意してください。
パスワードは、5文字以上30文字以下にする必要があります。
最低でも1文字は数字にする必要があります。
パスワードに使用できる文字は、英数字とアンダースコア(_)のみです。
パスワードは、英字で始まる必要があります。パスワードを数字、アンダースコア(_)、ドル記号($)またはナンバー記号(#)で始めることはできません。
Oracleの予約語はパスワードにできません。予約語の一覧は『Oracle Database SQLリファレンス』に記載されています。
「パスワードの確認」フィールドに新しいパスワードを再入力して、パスワードの入力が正しいことを確認します。
「適用」をクリックします。
Oracle Web Cacheを再起動します。第2.13項を参照してください。
Oracle Web Cacheを再起動しないと、Fusion Middleware Controlの一部のページへのアクセス時にエラーが発生することがあります。
デフォルトでは、Oracle Web Cacheをインストールしたコンピュータが信頼できるホストです。管理リクエスト、無効化リクエストおよび統計監視リクエストの発信元となる信頼できるサブネットまたは信頼できるホストは変更できます。
アプリケーションへの通信の一部または全部がHTTPSを使用するように限定するかどうか指定するには、次の手順を実行します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。
「Security」ページが表示されます。
「Security」ページで、「Current Trusted Subnets」の下にある「Change Trusted Subnets」をクリックします。
「Change Trusted Subnets」ダイアログ・ボックスが表示されます。
オプションを選択します。
All subnets: ネットワークのすべてのサブネット上にあるすべてのコンピュータからのリクエストを許可します。
This machine only: このコンピュータからのみリクエストを許可します。
Enter list of IP addresses: カンマ区切りのリストで入力したすべてのIPアドレスからのリクエストを許可します。次の形式を使用してIPアドレスを入力できます。
ネットワーク番号、サブネット・アドレスおよび一意のホスト番号を含めた完全なIPアドレス(ドット表記法を使用)
例: 10.1.0.0
マスクによるサブネット制限を実行するネットワーク/ネットマスクのペア
例: 10.1.0.0/255.255.0.0の場合、サブネット10.1からアクセスするすべてのホストが許可されます。
ネットワーク/nnnの形式のClassless Inter-Domain Routing(CIDR)を指定することにより、ハイエンドからnnnビットの一致を要求
例: 10.1.0.0/16の場合、サブネット10.1からアクセスするすべてのホストが許可されます。この例はネットワーク/ネットマスクの例と似ていますが、ネットマスクがnnnという上位1ビットで構成される点が異なります。
「Submit」をクリックします。
opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。
Webサイトのセキュリティを強化するため、クライアントからHTTPプロトコル・リクエストを受信し、オリジン・サーバーにHTTPSリクエストを送信するようにOracle Web Cacheを構成することができます。HTTPSではSSLを使用して、ユーザー・ページのリクエストおよびOracle Web Cacheとオリジン・サーバーから返されるページを暗号化および復号化します。また、HTTPSのリスニング・ポートを通じてオリジン・サーバーに通信データを送信するようにOracle Web Cacheを構成することもできます。
Oracle Web CacheでHTTPSサポートを構成するには、次の作業を行います。
Oracle Web CacheでHTTPSをサポートするには、サポートしている各サイトのOracle Web Cacheサーバーでウォレットを作成します。次のHTTPSリクエストをサポートするにはウォレットが必要です。
Oracle Web Cacheによってホスティングされるサイトに対するクライアント・リクエスト
Oracle Web Cacheに対する管理、無効化および統計監視用のリクエスト
オリジン・サーバーに対するOracle Web Cacheのリクエスト、およびSSL対応の無効化用ポートおよび統計監視用ポートに対するadminサーバー・プロセスのリクエスト
Oracle Web Cacheがサポートする各サイトには、少なくとも1つのウォレットを構成します。Oracle Web Cache HTTPSリスニング・ポートおよび操作ポート(受信HTTPSリクエストのサポート用)とオリジン・サーバー(送信HTTPSリクエストのサポート用)のそれぞれに対してウォレットの場所を指定します。1つのウォレットを共有することも、異なるウォレットを作成することもできます。同じウォレットを使用する場合、このウォレットがサポートできるのは1つのサーバー側の証明書のみである点に注意する必要があります。
ウォレットを作成するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
「Webキャッシュ」メニューから、「セキュリティ」→「ウォレット」を選択します。
「ウォレット」ページが表示されます。
『Oracle Fusion Middleware管理者ガイド』のウォレットの作成に関する項の作業を実行します。
クライアントとOracle Web Cache間でHTTPSプロトコルをサポートするように構成するには、Oracle Web Cache用のHTTPSリスニング・ポートを構成する必要があります。
HTTPSリスニング・ポートを追加するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
リスニング・ポートを作成します。
「Webキャッシュ」メニューから、「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。
「作成」をクリックします。
「ポートの作成」ページが表示されます。
「ポート・タイプ」リストから「NORM」を選択します。
「IPアドレス」フィールドで、Oracle Web Cacheが稼働しているコンピュータを指定します。
- 32ビットのドット10進数表記法で記述されたIPバージョン4アドレス、または128ビット表記法で記述されたIPバージョン6アドレス。第2.5項を参照してください。
- Oracle Web Cacheが稼働しているコンピュータのIPアドレスに解決されるホスト名。ホスト名の解決にドメイン・ネーム・システム(DNS)を使用しない場合は、UNIXのetc/hostsファイルなどの別の名前解決メカニズムを使用してください。
- 任意のIPアドレスを表すANY
「ポート」フィールドに、Oracle Web CacheがWebサイトのクライアント・リクエストを受信するリスニング・ポートを入力します。
このポート番号が使用されていないことを確認してください。
1024未満のポート番号は、UNIXの特権プロセス用に確保されています。Oracle Web Cacheが1024未満のポート(ポート80など)でリスニングするように構成するには、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行します。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。
webcached実行可能ファイルをroot権限で実行できるように変更する方法は、第5.9項を参照してください。
「OK」をクリックします。
SSLのポートを有効にします。
「Webキャッシュ」メニューから、「セキュリティ」→「SSL構成」を選択します。
「SSL構成」ページが表示されます。
ステップ2で作成したエンドポイントの行を選択して、「編集」をクリックします。
「ポートの編集」ページが表示されます。
「SSL構成」セクションで、「SSLの有効化」をクリックします。
「サーバー・ウォレット名」フィールドで、第5.4.1項で作成したウォレットを選択します。
「拡張SSL設定」セクションで、「開く」(+)をクリックして構成設定を開きます。
「クライアント認証」リストから、クライアント認証のタイプを選択します。
- サーバー認証: サーバーがクライアントに対して自身を認証します。
- 相互認証: クライアントがサーバーに対して自身を認証するとともに、そのサーバーがそのクライアントに対して自身を認証します。
- 認証なし: サーバーもクライアントも認証を必要としません。
- オプションのクライアント認証: サーバーがクライアントに対して認証を実行しますが、クライアントはサーバーに対して認証を実行する場合としない場合があります。クライアント自身の認証を行わなくても、SSLセッションは機能します。
「SSLプロトコル・バージョン」リストから、使用するSSLのバージョンを選択します。
- すべて: 「v1」、「v3」および「v3-v2Hello」オプションを有効にします。
- v1: TLSバージョン1トラフィックをサポートします。
- v3: SSLバージョン3トラフィックを提供します。
- v3_v2Hello: SSLバージョン2のhelloメッセージ・フォーマットとSSLバージョン3の処理を組み合せて、ハンドシェイク操作中のSSLバージョンのアップグレードをサポートします。
「OK」をクリックします。
この作業では、オリジン・サーバーに対するOracle Web Cache接続で使用するSSLウォレットを指定します。このウォレットには、オリジン・サーバーが使用するウォレットに一致する証明書が含まれている必要があります。
オリジン・サーバーに対するWeb Cache接続で使用するSSLウォレットを指定するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
「Webキャッシュ」メニューから、「セキュリティ」→「SSL構成」を選択します。
「SSL構成」ページが表示されます。
「WebCacheとOracle HTTP Server(OHS)間のSSL通信」セクションの横にある「開く」アイコンをクリックします。
「ウォレットの変更」をクリックして、「クライアント・ウォレットの選択」ダイアログ・ボックスを表示します。
使用するウォレットを選択し、「OK」をクリックします。このウォレットには、オリジン・サーバーが使用するウォレットに一致する証明書が含まれている必要があります。
HTTPとHTTPSの通信が混在する環境の場合は、次の手順に従って特定のサイト(またはサイトのURL接頭辞サブセット)の通信を制限して、Oracle Web CacheがSSL接続経由のリクエストのみを受信するようにします。
サイトの設定を構成するには、Fusion Middleware ControlとOracle Web Cache Managerを組み合せて使用します。
Fusion Middleware Controlで、第2.11.3項および第2.11.4項の説明に従って、サイト定義およびサイトからサーバーへのマッピングを指定します。サイト定義を構成するときには、HTTPSリスニング・ポートを必ず指定します。このサイトでは、そのポート用に定義されたウォレットが使用されます。
「Webキャッシュ」メニューから、「可用性」→「再起動」を選択して、構成設定を保存し、Oracle Web Cacheを再起動します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Site Definition」を選択します。第2.7.2項を参照してください。
ステップ1で作成したサイトを選択し、「Show/Edit Site」をクリックします。
「Show/Edit」ダイアログ・ボックスで、「HTTPS Only Prefix」フィールドに、HTTPSリクエストのみを処理することを示すURLの接頭辞を入力します。すべての通信をHTTPSに限定する場合は、サイト全体を表す「/」を入力します。
「Submit」をクリックします。
Oracle HTTP Serverのデフォルトでは、Microsoft Internet Explorer 5.5以降のリリースからのHTTPSクライアント・リクエストに対するキープ・アライブ接続は維持されません。Internet Explorerには、タイムアウトしたSSL接続を再使用しようとする既知の問題があります。Oracle HTTP ServerがOracle Web Cacheからのキープ・アライブ接続を維持できるようにするには、UNIXでは$ORACLE_HOME/Apache/Apache/confディレクトリ、WindowsではORACLE_HOME\Apache\Apache\confディレクトリにあるssl.confファイルから次のエントリを削除する必要があります。
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
ssl.confファイルにより、Oracle HTTP ServerのSSL定義を指定します。このエントリを削除しないと、キープ・アライブ接続は無効です。Oracle Web Cacheでキープ・アライブのタイムアウトを構成する方法については、第2.11.5項を参照してください。
第2.13項を参照してください。
オリジン・サーバーがOracle WebLogic Serverである場合は、SSLリクエストを正しく処理できるように、Oracle Web Cacheに対して追加の属性を指定する必要があります。
オリジン・サーバーがOracle WebLogic Serverである構成でOracle Web Cacheを構成する手順は次のとおりです。
次の場所にあるwebcache.xmlをテキスト・エディタで開きます。
(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
SERVERTYPE属性をCACHE要素に追加します。次に例を示します。
<HOST ID="host_ID" NAME="WLS_server_name" PORT="WLS_server_port" LOADLIMIT="100" OSSTATE="ON" SERVERTYPE="WebLogic"/> ...
webcache.xmlを保存します。
次のコマンドを使用してOracle Web Cacheを再起動します。
opmnctl restartproc ias-component=component_name
この実行可能ファイルは、次のディレクトリにあります。
(UNIX) ORACLE_INSTANCE/bin (Windows) ORACLE_INSTANCE\bin
第5.4項の作業を実行した後に、オプションで次の構成を実行できます。
Fusion Middleware Controlで管理リクエスト、無効化リクエストまたは統計監視リクエストをリスニングするHTTPSポートを構成するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
リスニング・ポートを作成します。
「Webキャッシュ」メニューから、「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。
「作成」をクリックします。
「ポートの作成」ページが表示されます。
「ポート・タイプ」リストから、ポート・タイプとして「管理」、「無効化」または「統計」を選択します。
「IPアドレス」フィールドで、Oracle Web Cacheが稼働しているコンピュータを指定します。
- 32ビットのドット10進数表記法で記述されたIPバージョン4アドレス、または128ビット表記法で記述されたIPバージョン6アドレス。第2.5項を参照してください。
- Oracle Web Cacheが稼働しているコンピュータのIPアドレスに解決されるホスト名。ホスト名の解決にドメイン・ネーム・システム(DNS)を使用しない場合は、UNIXの/etc/hostsファイルなどの別の名前解決メカニズムを使用してください。
- 任意のIPアドレスを表すANY
「ポート」フィールドに、Oracle Web CacheがWebサイトのクライアント・リクエストを受信するリスニング・ポートを入力します。
このポート番号が使用されていないことを確認してください。
1024未満のポート番号は、UNIXの特権プロセス用に確保されています。Oracle Web Cacheが1024未満のポート(ポート80など)でリスニングするように構成するには、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行します。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。
webcached実行可能ファイルをroot権限で実行できるように変更する方法は、第5.9項を参照してください。
「OK」をクリックします。
SSLのポートを有効にします。
「Webキャッシュ」メニューから、「セキュリティ」→「SSL構成」を選択します。
「SSL構成」ページが表示されます。
ステップ2で作成したエンドポイントの行を選択して、「編集」をクリックします。
「ポートの編集」ページが表示されます。
「SSL構成」セクションで、「SSLの有効化」をクリックします。
「サーバー・ウォレット名」フィールドで、第5.4.1項で作成したウォレットを選択します。
「拡張SSL設定」セクションで、「開く」(+)をクリックして構成設定を開きます。
「SSL認証」リストから、クライアント認証のタイプを選択します。
- サーバー認証: サーバーがクライアントに対して自身を認証します。
- 相互認証: クライアントがサーバーに対して自身を認証するとともに、そのサーバーがそのクライアントに対して自身を認証します。
- 認証なし: サーバーもクライアントも認証を必要としません。
- オプションのクライアント認証: サーバーがクライアントに対して認証を実行しますが、クライアントはサーバーに対して認証を実行する場合としない場合があります。クライアント自身の認証を行わなくても、SSLセッションは機能します。
「SSLプロトコル・バージョン」リストから、使用するSSLのバージョンを選択します。
「OK」をクリックします。
クライアントの識別情報を検証するために、証明書(クライアント側の証明書)をキャッシュに送信することをクライアントに要求できます。
クライアント側の証明書を使用する場合、クライアントのブラウザはSSLハンドシェイク時に証明書をキャッシュに送信します。次に、サーバーがそのオブジェクトに対するリクエストを処理します。リクエストされたオブジェクトがキャッシュに格納されていない場合、キャッシュはリクエストをWebアプリケーション・サーバー、(クラスタ内の)ピア・キャッシュまたは(階層内の)従属キャッシュに転送します。クライアント側の証明書に関する情報を別のキャッシュまたはWebアプリケーション・サーバーに転送するために、Oracle Web CacheはリクエストにHTTPヘッダーを追加します。ヘッダーの先頭は、文字列SSL-Client-Certで始まります。
クライアント側の証明書の使用については、次の点に注意してください。
単純な構成(クライアントからキャッシュ、キャッシュからWebアプリケーション・サーバーへ)では、クライアントはSSLハンドシェイク時に証明書をキャッシュに送信します。リクエストされたオブジェクトがキャッシュに保存されない場合、キャッシュはそのリクエストをWebアプリケーション・サーバーに転送し、ヘッダー内のクライアント側の証明書情報もWebアプリケーション・サーバーに転送します。Webアプリケーション・サーバーは、ヘッダーを認識してリクエストに応答します。
クラスタ内で、クライアントはSSLハンドシェイク時に証明書をキャッシュ・クラスタ・メンバーに送信します。リクエストされたオブジェクトがキャッシュ内に保存されない場合、クラスタ・メンバーはピア(そのオブジェクトを所有するクラスタ・メンバー)にそのオブジェクトをリクエストします。クライアント側の証明書を使用する場合、Oracle Web Cacheはヘッダー内のクライアント側の証明書情報をピア・クラスタ・メンバーに渡すことができ、ピア・クラスタ・メンバーはそのヘッダーをWebアプリケーション・サーバーに渡すことができる必要があります。
サイトがクライアント証明書を必要としている場合、クライアント証明書が渡されないと「403 禁止」エラーが返されます。リスニング・ポートがクライアント証明書を要求したときにクライアント証明書が提供されない場合、SSLハンドシェイクは失敗します。
|
注意: Oracle Web Cacheでは、Oracle HTTP Serverとともに使用する場合にのみクライアント側の証明書の使用がサポートされます。分散キャッシュ階層では証明書の安全性が保証されないため、Oracle Web Cacheでは、クライアント側の証明書はサポートされていません。 |
次のトピックは、クライアント側の証明書を構成する方法を示します。
クライアント側の証明書を使用するには、第5.4.2項の説明に従ってHTTPSリスニング・ポートを有効にする必要があります。キャッシュ・クラスタを使用する場合は、すべてのクラスタ・メンバーに対してHTTPSリスニング・ポートを有効にする必要があります。また、クライアントのブラウザにSSL証明書を要求できるようOracle Web Cacheを構成する必要があります。
クライアント側の証明書を構成したら、Oracle Web Cacheが証明書情報をOracle HTTP Serverに転送できるようにAddCertHeaderディレクティブをhttpd.confに追加します。AddCertHeaderディレクティブの追加方法については、Oracle Fusion Middleware Oracle HTTP Server管理者ガイドを参照してください。
キャッシュ・クラスタを使用する場合は、キャッシュがピア・クラスタ・メンバー以外のソースからHTTPヘッダーの証明書情報を受け取らないようにする必要があります。さらに、各キャッシュはヘッダー内のクライアント側の証明書情報をピア・クラスタ・メンバーに渡すことができ、ピア・クラスタ・メンバーはそのヘッダーをWebアプリケーション・サーバーに渡すことができる必要があります。
Oracle Web Cache Managerでこの動作を構成するには、次の手順を実行します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。
「Security」ページの「Security Header Configuration」セクションで、「Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers」の値を「NO」(デフォルト)に設定して、Oracle Web CacheがHTTPヘッダー内の証明書情報を受け取らないようにします。この設定により、キャッシュ・クラスタ内のキャッシュが、HTTPヘッダーの証明書情報を受け取らなくなります。
「Cluster Security Configuration」セクションで、「Route requests that contain SSL client certificates to cache cluster peers」の値を「YES」に設定して、Oracle Web CacheがHTTPヘッダーのクライアント側証明書に関する情報をピア・キャッシュに渡すようにします。この設定を使用すると、キャッシュ・クラスタ内のキャッシュが、ピア・キャッシュに情報を渡すことができるようになります。
「Apply Changes」をクリックします。
Oracle Web Cacheを再起動します。第2.13項を参照してください。
サイト全体がクライアント側の証明書を要求するように指定することもできます。サイトがクライアント証明書を必要としている場合、クライアント証明書が渡されないと「403 禁止」エラーが返されます。
サイトがクライアント側の証明書を使用するよう構成するには、次の手順を実行します。
Fusion Middleware ControlまたはOracle Web Cache Managerでは、証明書失効リスト(CRL)によるクライアント証明書の検証はサポートされません。このサポートは、webcache.xmlファイルを手動で編集することで構成できます。
クライアント証明書失効ステータスは、ファイルシステム・ディレクトリに存在するCRLに基づいてチェックされます。通常、CRL定義の有効期限は数日間であり、定期的に更新される必要があります。CRL定義を変更した場合、常にOracle Web Cacheを再起動する必要があります。
CRL検証が有効化されており、使用可能な場合、Oracle Web Cacheはクライアント証明書に対して証明書失効ステータス・チェックを実行します。証明書が失効している場合、SSL接続は拒否されます。CRLが見つからない場合や、証明書がまだ失効していない場合、SSL接続は許可されます。
CRLによる証明書検証を構成するには、次の手順を実行します。
HTTPSリスニング・ポートに対してクライアント証明書を有効化します。第5.5.2項を参照してください。
次の場所にあるwebcache.xmlをテキスト・エディタで開きます。
(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
CRLチェックを有効化する必要のあるHTTPSリスニング・ポートの場所をwebcache.xmlで特定し、LISTENディレクティブにSSLCRLENABLE="YES"パラメータを追加します。次に例を示します。
... <LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H" CLIENT_CERT="YES" SSLCRLENABLE="YES" STRONG_CRYPTO_ONLY="NO"> ...
HTTPS LISTENディレクティブにSSLCRLPATHおよびSSLCRLFILEパラメータを追加して、CRLファイルの場所を構成します。
SSLCRLPATH: CRLが格納されているディレクトリのパスを入力します。パスが正しいことを確認します。間違っていると、CRLチェックは機能しません。このパラメータにデフォルト値はありません。
SSLCRLFILE: PEMエンコードされた包括的CRLファイル(BASE64 CRLが優先度の順に1つのファイルに連結されたもの)へのパスを入力します。このパラメータを設定する場合、ファイルは指定した場所に存在している必要があります。存在していないと、CRLチェックが機能しません。
次に例を示します。
... <LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H" CLIENT_CERT="YES" SSLCRLENABLE="YES" SSLCRLFILE="/ORACLE_HOME/webcache/crls/sample_crl" SSLCRLPATH="/ORACLE_HOME/webcache/crls/" STRONG_CRYPTO_ONLY="NO"> ...
orapkiコマンドライン・ユーティリティを使用して、ファイルシステムでCRLの名前を変更します。orapkiの使用方法の詳細は、Oracle Databaseドキュメント・ライブラリにあるOracle Database Advanced Security管理者ガイドの証明書失効リストの管理に関する項を参照してください。
webcache.xmlを保存します。
次のコマンドを使用してOracle Web Cacheを再起動します。
opmnctl restartproc ias-component=component_name
この実行可能ファイルは、次のディレクトリにあります。
(UNIX) ORACLE_INSTANCE/bin (Windows) ORACLE_INSTANCE\bin
クラスタ構成では、クラスタ・メンバーのwebcache.xmlファイルの構成を直接変更する場合、Fusion Middleware ControlまたはOracle Web Cache Managerを使用してその変更を他のクラスタ・メンバーに伝播してください。3.6項および3.7項を参照してください。
Oracle Web Cacheでは、デフォルトで、HTTPリクエスト・ヘッダー・フィールドに対して次の制限が設けられています。
リクエスト内のすべてのHTTPリクエスト・ヘッダー・フィールドの合計は819000バイト
セキュリティを確立し、クライアントからのDoS攻撃を回避するために、ヘッダー・サイズはこのデフォルト値以下に設定することをお薦めします。
リクエストの長さが制限サイズより長い場合、Oracle Web Cacheはエラーをクライアントに送信し、次のエラー11356をイベント・ログに記録します。
Total request header length exceeds configured maximum. A forbidden error response is returned to the client.
各HTTPリクエスト・ヘッダー・フィールドは8152バイト
各ヘッダー・サイズは、アプリケーションで設定するHTTPリクエスト・ヘッダー・フィールドの大きさに基づいて設定することをお薦めします。
リクエストの長さが制限サイズより長い場合、Oracle Web Cacheはエラーをクライアントに送信し、次のエラー11355をイベント・ログに記録します。
Single request header length exceeds configured maximum. A forbidden error response is returned to the client.
デフォルトのヘッダー制限を変更するには、次の手順を実行します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。
「Security」ページが表示されます。
「Security」ページの「HTTP Request Header Limits」セクションで、「Edit」をクリックします。
「HTTP Request Header Limits」ダイアログ・ボックスが表示されます。
「Maximum combined header size in bytes」フィールドで、リクエスト内のすべてのHTTPリクエスト・ヘッダー・フィールドの合計サイズを指定します。制限は4096バイト(4 KB)以上に指定してください。
「Maximum individual header size in bytes」フィールドで、各HTTPリクエスト・ヘッダー・フィールドの制限サイズを指定します。制限は256バイト以上に指定してください。
「Submit」をクリックし、「Apply Changes」をクリックします。
Oracle Web Cacheを再起動します。第2.13項を参照してください。
ブラウザなどのクライアントは、リクエストのヘッダーでそのIPアドレスに関する情報を送信できます。ただし、クライアントはヘッダーに偽のIPアドレスを使用することがあるため、キャッシュにその情報を別のキャッシュやオリジン・サーバーに転送することを許可すると、セキュリティに問題が発生する可能性があります。デフォルトでは、Oracle Web Cacheは、クライアントから転送されたIPヘッダー情報を削除し、クライアントの正しいIPアドレスを含むヘッダーで置換します。(この場合のクライアントは、ブラウザ、または階層内の別のキャッシュです。)
キャッシュ階層では、Oracle Web Cacheは、階層内のキャッシュ間で転送される情報、またはキャッシュからオリジン・サーバーに転送される情報を保持できる必要があります。
これらを構成するには、次の手順を実行します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。
「Security」ページの「Security Header Configuration」セクションで、「Accept client IP addresses encoded in ClientIP headers」フィールドの値をチェックします。
値が「NO」の場合、Oracle Web Cacheは、クライアントから転送されたClientIPリクエスト・ヘッダーを削除し、正しいIPアドレスが含まれているヘッダーに置き換えます。
値が「YES」の場合、Oracle Web Cacheはクライアントから受信したヘッダーを受け入れ、そのヘッダーを別のキャッシュまたはオリジン・サーバーに転送できます。
設定値が次の内容と一致しない場合は、「Edit」をクリックし、「Security Header Configuration」ダイアログ・ボックスで設定値を変更します。
単純な構成の場合、値は「NO」です。
キャッシュ・クラスタのすべてのクラスタ・メンバーについて、値は「NO」です。
分散キャッシュ階層内のリモート・キャッシュの場合、値は「NO」です。
分散キャッシュ階層内で他のキャッシュからのみリクエストを受信する集中キャッシュの場合、値は「YES」です。
集中キャッシュがブラウザと階層内の他のキャッシュの両方からリクエストを受信した場合、Oracle Web Cacheは、ブラウザから受信したリクエストと別のキャッシュから受信したリクエストを区別できません。このため、「YES」に指定すると、誤ったIPアドレスがブラウザから転送される可能性があります。ただし、別のキャッシュからは正しい情報が転送されます。「NO」を指定すると、誤ったIPアドレスがブラウザから転送される可能性がなくなります。ただし、別のキャッシュから転送される情報には、オリジナル・サーバーではなくキャッシュのIPアドレスが含まれます。
「Submit」をクリックし、「Apply Changes」をクリックします。
Oracle Web Cacheを再起動します。第2.13項を参照してください。
Oracle Web Cacheは、Oracle Single Sign-On認証によって保護され、ほかに認可要件がないコンテンツのキャッシュをサポートするように構成できます。
Oracle Web Cache Managerでこの設定を有効にするには、次の手順を実行します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Origin Servers, Sites, and Load Balancing」→「Site Definitions」を選択します。第2.7.2項を参照してください。
構成済のサイトを選択し、「Edit Show/Edit Site」をクリックします。
「For Site」ダイアログ・ボックスの「Attributes」セクションで、リクエストされたオブジェクトに必要な認証のタイプを選択します。
Oracle Single Sign-On: Oracle Single Sign-Onを介した認証を必要とする場合に選択します。Oracle Web Cacheがリクエストを処理するには、有効なOracle Single Sign-OnのCookieが必要です。
None: 認証を一切必要としない場合に選択します。
「Submit」をクリックします。
Oracle Web Cacheを再起動します。第2.13項を参照してください。
UNIXでは、次の場合、webcachedがroot権限で実行されるように構成する必要があります。
現在のopmnctlユーザーが、Oracle Web Cache Managerの「Process Identity」ページ(「Properties」→「Process Identity」)で構成されたプロセス認証ユーザーと一致しない場合
この項では、次の項目について説明します。
デフォルトでは、インストールを実行したユーザーがOracle Web Cacheプロセスの所有者となります。このユーザーはopmnctlコマンドを実行できます。インストールを実行したユーザーと同じグループIDに属するユーザーもopmnctlコマンドを実行できます。
現在のopmnctlのユーザーがOracle Web Cache Managerの「Process Identity」ページに構成されているユーザーと一致しない場合は、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行する必要があります。webcached実行可能ファイルをroot権限で実行できない場合は、エラー・イベントがイベント・ログ・ファイルに記録され、Oracle Web Cacheは起動に失敗します。
UNIXでOracle Web CacheプロセスのユーザーIDとグループIDを変更するには、次の手順を実行します。
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Process Identity」を選択します。第2.7.2項を参照してください。
「Process Identity」ページが表示されます。
設定を変更するキャッシュを選択し、「Change IDs」をクリックします。
「Change Process Identity」ダイアログ・ボックスが表示されます。
「User ID」フィールドに新しいユーザーを、「Group ID」フィールドにそのユーザーのグループIDを入力します。
「Submit」をクリックします。
次のwebcache_setuser.shスクリプトを使用して、ファイルとディレクトリの所有権を変更します。
webcache_setuser.sh setidentity <user_ID>
この<user_ID>は、「Process Identity」ページの「User ID」フィールドで指定したユーザーです。
setidentityコマンドによって、次のファイルとディレクトリの所有権が新しいユーザーIDに変更されます。
次のディレクトリにあるwebcache.xml構成ファイル
(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\webcache_name>
次のディレクトリにあるイベント・ログ・ファイルとアクセス・ログ・ファイル
(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>
opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。
特権ポートに関する構成を行う場合またはOracle Web Cacheのファイル・ディスクリプタ制限を引き上げるには、2つの方法があります。
Oracle Web Cacheを実行している特定のユーザーの制限を引き上げます。この方法を使用することをお薦めします。ユーザーの制限の引上げに関する詳細は、オペレーティング・システムのマニュアルを参照してください。
webcache_setuser.shのsetrootコマンドを使用して、プロセス認証の設定を変更することなくOracle Web Cacheにroot権限を設定します。
Oracle Web Cacheをアップグレードするかパッチを適用するたびに、Oracle Web Cacheのバイナリが暗黙的に再リンクされます。したがって、次の手順に示すようにsetrootコマンドを再実行する必要があります。
webcache_setuser.shのsetrootコマンドを使用するには、次の手順を実行します。
構成されたユーザーと現在のユーザーが一致しない構成では、Oracle Web Cacheプロセスのプロセス認証を変更し、webcache_setuser.shのsetidentityコマンドを使用してOracle Web Cacheにroot権限を設定します。
Oracle Web Cacheプロセスのプロセス認証を変更します。
制限付きユーザーを使用してOracle Web Cacheを実行することをお薦めします。グループIDとユーザーIDを設定してプロセス認証を確立する方法は、第5.9.1項を参照してください。
別のユーザーとしてOracle Web Cacheを実行するには、webcache_setuser.shスクリプトを次のように使用し、ユーザーIDに対するアクセス権をwebcached実行可能ファイルに追加します。
webcache_setuser.sh setidentity user_ID
このuser_IDは、ステップ2で指定したユーザーIDです。webcache_setuser.shスクリプトの詳細は、第5.10項を参照してください。
コンピュータからログアウトし、ステップ2で構成したユーザーで再度ログインします。
opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。
アクセス権をインストール時の状態に戻すには、webcache_setuser.shのrevertコマンドを使用します。setidentityコマンドの使用後にパッチ・リリースをインストールする場合は、アクセス権を元に戻す必要があります。アクセス権を元に戻さないと、$ORACLE_HOME/webcacheディレクトリ内のファイルに書き込めません。パッチのインストールの完了後に、setidentityコマンドを使用してプロセス認証を再度変更できます。
ファイルのアクセス権をリセットするには、次の手順を実行します。
UNIXオペレーティング・システムの場合は、webcache_setuser.shスクリプトを使用して、Oracle Web Cacheの実行に使用するモードに従ってファイル・アクセス権を設定できます。ファイルwebcache_setuser.shは、$ORACLE_HOME/webcache/binディレクトリにあります。
webcache_setuser.shスクリプトを実行する前に、OPMNユーティリティ・コマンドを使用して、cacheサーバー・プロセスとadminサーバー・プロセスを停止してください。
opmnctl stopproc ias-compononent=WebCache
次に、webcache_setuser.sh構文の書式を示します。
webcache_setuser.sh command user_ID
表5-1で各コマンドについて説明します。
表5-1 webcache_setuser.shスクリプトのコマンド
| コマンド | 説明 |
|---|---|
|
|
|
|
ランタイムOracle Web Cacheユーザーの所有権を変更します。このコマンドでは、ユーザーIDに対するアクセス権が |
|
|
ファイル・アクセス権をインストール時の状態に戻します。
|
パラメータuser_IDは、Oracle Web Cacheプロセスと関連付けられているユーザーIDです。(デフォルトでは、そのユーザーIDはインストールを実行したユーザーのIDです。)setrootおよびrevertモードについては、ユーザーIDはインストールを実行したユーザーのIDである必要があります。このユーザーIDは、Oracle Web Cache Managerの「Process Identity」ページ(「Properties」→「Process Identity」)で指定したユーザーIDと一致する必要があります。webcache_setuser.shスクリプトの実行が必要となる状況の詳細は、第5.9項を参照してください。
