プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Traffic Directorの管理
12c (12.2.1.1.0)
E77306-01
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

10 セキュリティの管理

この章では、Oracle Traffic Director管理サーバーへのアクセスの保護、およびOracle Traffic Director仮想サーバーに対するSSL/TLSの有効化の方法について説明します。また、クライアント認証の構成方法、およびOracle Traffic Directorを使用したオリジン・サーバーへのアクセスの保護の方法についても説明します。

この章には次の項が含まれます:


注意:

環境内のOracle Traffic Directorを保護するための手順の詳細は、付録C「Oracle Traffic Directorデプロイメントの保護」を参照してください。

10.1 Oracle Traffic Directorとクライアント間のSSL/TLSの構成

この項では、SSL/TLSを使用して、クライアントとOracle Traffic Directorインスタンス間の通信を保護する方法について説明します。この項の情報は、SSL/TLS、証明書、暗号および鍵の概念を熟知している読者を対象としています。これらの概念の基本的な情報については、10.1.7項「SSL/TLSの概念」を参照してください。

この項には次のサブセクションが含まれます:

10.1.1 SSL/TLS構成プロセスの概要

Oracle Traffic DirectorインスタンスのSSL/TLSを有効化するには、RSAまたはECC証明書、あるいはその両方をインスタンスの1つ以上のリスナーに関連付ける必要があります。加えて、RSAまたはECC証明書、あるいはその両方を、仮想サーバーに直接関連付けることもできます。Oracle Traffic DirectorインスタンスのSSL/TLSを構成するプロセスには、次の手順が含まれます。

  1. 自己署名証明書、VeriSign社などのサードパーティ認証局(CA)が発行した証明書または自分で生成した証明書を取得します。

    詳細は、次の項を参照してください。

  2. 10.3.3項「証明書のインポート」の説明に従って証明書をインストールします。

  3. 10.1.2項「リスナーのSSL/TLSの構成」の説明に従い、証明書を必要なHTTPリスナーまたはTCPリスナーに関連付けます。

    10.1.3項「証明書と仮想サーバーの関連付け」の説明に従い、証明書を仮想サーバーに直接関連付けることもできます。Oracle Traffic Directorで、SSL/TLSハンドシェイク中にクライアントに送信される証明書の選択に使用されるロジックの詳細は、10.1.5項「証明書の選択ロジック」を参照してください。

  4. 10.1.4項「リスナーのSSL/TLS暗号の構成」の説明に従い、HTTPリスナーまたはTCPリスナーにサポートされている暗号を構成します。

10.1.2 リスナーのSSL/TLSの構成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、HTTPSまたはTCPリクエストを受信するリスナーを構成できます。開始する前に、必要な証明書を取得して、10.3.1項「鍵ペアの生成」10.3.2項「CA署名証明書の取得」および10.3.3項「証明書のインポート」の説明に従ってインストールします。


注意:

  • リスナーを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

  • 新しい証明書をリスナーに関連付ける、または以前に関連付けられていた証明書を削除する場合、変更を有効にするには、インスタンスを再起動する必要があります。更新された構成をデプロイするだけでは不十分です。

  • WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。


Fusion Middleware Controlを使用したリスナー用のSSL/TLSの構成

Fusion Middleware Controlを使用してHTTPまたはTCP用のSSL/TLSを構成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. SSL/TLSが有効化されたリスナーを構成する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「管理」→「仮想サーバー」を選択します。

    「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

    名前をクリックすると、仮想サーバーのプロパティを表示できます。

  7. 有効にし、SSL/TLSを構成するリスナーを選択します。

    「リスナー設定」ページが表示されます。

  8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。

    「SSL/TLS設定」ページが表示されます。

  9. 「SSL設定」セクションで、「SSL有効」チェック・ボックスを選択します。

  10. 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。

    リスナーをRSA証明書およびECC証明書に関連付ける場合、サーバーがクライアントに最終的に提示する証明書は、クライアントとサーバーがネゴシエートして使用する暗号スイートに基づき、SSL/TLSハンドシェイク中に決定されます。

    また、「リスナー設定」ページの「詳細設定」セクションで次の詳細なSSL/TLS設定も指定できます。

    • クライアント認証の設定の有効化および無効化詳細は、10.6項「クライアント認証の構成」を参照してください。

    • 厳密なSNIホスト一致の有効化および無効化。詳細は、10.1.6項「厳密なSNIホスト一致について」を参照してください。

    • 次のTLS固有の機能の有効化および無効化

      • バージョンのロールバック

        Oracle Traffic DirectorでTLSバージョンのロールバックを検出し、試行をブロックするには、このチェック・ボックスを選択します。たとえば、クライアントがTLS 1.0をリクエストしたものの、攻撃者がより低いバージョン(たとえば、SSL 3.0)に変更した場合、Oracle Traffic Directorは、低いバージョンをサポートしていたとしても、このロールバックを検出しブロックします。

      • セッション・チケット拡張

        有効化した場合、TLSセッションは、サーバー上に各クライアントのセッション状態を格納することなく再開できます。Oracle Traffic Directorは、各クライアントのセッション状態をチケットにカプセル化し、クライアントにチケットを転送します。続いて、クライアントは、前に取得済のセッション・チケットを使用してTLSセッションを再開します。

    • SSLおよびTLS暗号の有効化および無効化。詳細は、10.1.4項「リスナーのSSL/TLS暗号の構成」を参照してください。

    画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

    フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

    「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

  11. 必要な変更を行った後、「適用」をクリックします。

    更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

  12. 「共通のタスク」ペインの「インスタンスの起動/再起動」をクリックして、構成のインスタンスを再起動します。

WLSTを使用したリスナーのSSL/TLSの構成

  • HTTPまたはTCPリスナーのSSL/TLSのプロパティを表示するには、次の例に示すように、otd_getHttpListenerSslPropertiesまたはotd_getTcpListernerSslPropertiesコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['http-listener'] = 'http-listener-1'
    otd_getHttpListenerSslProperties(props)
    
    enabled=false
    client-auth=false
    client-auth-timeout=60
    max-client-auth-data=1048576
    ssl3=true
    tls10=true
    tls11=true
    tls12=true
    override-cipher-order=false
    ...
    
  • HTTPまたはTCPリスナー用のSSL/TLSを構成するには、次の例に示すように、otd_setHttpListenerSslPropertiesまたはotd_setTcpListenerSslPropertiesコマンドを実行します。

    props['configuration'] = 'foo'
    props['http-listener'] = 'http-listener-1'
    props['tls10'] = 'false'
    otd_setHttpListenerSslProperties(props)
    

10.1.3 仮想サーバーと証明書の関連付け

Fusion Middleware ControlまたはWLSTのいずれかを使用して、1つのRSAおよび1つのECC証明書を各仮想サーバーに関連付けることができます。Oracle Traffic Directorで、SSL/TLSハンドシェイク中にクライアントに送信される証明書の選択に使用されるロジックの詳細は、10.1.5項「証明書の選択ロジック」を参照してください。

開始する前に、必要な証明書を取得して、10.3.1項「鍵ペアの生成」10.3.2項「CA署名証明書の取得」および10.3.3項「証明書のインポート」の説明に従ってインストールします。


注意:

  • 仮想サーバーを変更すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、3.3項「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。

  • 新しい証明書を仮想サーバーに関連付ける、または以前に関連付けられていた証明書を削除する場合、変更を有効にするには、インスタンスを再起動する必要があります。更新された構成をデプロイするだけでは不十分です。

  • WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。


Fusion Middleware Controlを使用した証明書と仮想サーバーの関連付け

Fusion Middleware Controlを使用して証明書を仮想サーバーと関連付けるには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 仮想サーバーと証明書を関連付ける構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「管理」→「仮想サーバー」を選択します。

    「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

    名前をクリックすると、仮想サーバーのプロパティを表示できます。

  7. 有効にし、SSL/TLSを構成するリスナーを選択します。

    「リスナー設定」ページが表示されます。

  8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。

    「SSL/TLS設定」ページが表示されます。

  9. 「SSL設定」セクションで、「SSL有効」チェック・ボックスを選択します。

  10. 「RSA証明書」および「ECC証明書」フィールドで、サーバーの認証に使用する証明書を選択します。

    フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

    「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

  11. 必要な変更を行った後、「適用」をクリックします。

    更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

  12. OTDの「構成」ペインで「インスタンスの起動/インスタンスの再起動」をクリックして、構成のインスタンスを再起動します。

WLSTを使用した仮想サーバーと証明書の関連付け

  • 仮想サーバーに現在関連付けられている証明書を表示するには、次の例に示すように、otd_getVirtualServerPropertiesコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    otd_getVirtualServerProperties(props)
    
  • 仮想サーバーと証明書を関連付けるには、次の例に示すように、otd_setVirtualServerSslPropertiesコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    props['server-cert-alias'] = 'cert-1'
    props['http-listener'] = 'http-listener-1'
    otd_setVirtualServerProperties(props)
    

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。


注意:

仮想サーバーに関連付ける証明書と同じタイプの証明書(ECCまたはRSA)が、仮想サーバーがバインドされているリスナーにも関連付けられていることを確認してください。

10.1.4 リスナーのSSL/TLS暗号の構成

SSL/TLSハンドシェイクの実行中、クライアントとサーバーは、サポートしているSSLおよびTLSについて情報を交換し、SSL/TLSセッションに使用する暗号(通常、最も強力な暗号)をネゴシエートします。暗号についての基本的な概念の詳細は、暗号についてを参照してください。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Oracle Traffic Directorがサポートしているリスナーの暗号を構成できます。

Fusion Middleware Controlを使用したリスナーの暗号の構成

Fusion Middleware Controlを使用してHTTPまたはTCPリスナーでサポートされる暗号を構成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 暗号を構成する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「管理」→「リスナー」を選択します。

    「リスナー」ページが表示されます。構成に定義されたHTTP/TCPリスナー・リストが表示されます。

    名前をクリックすると、HTTP/TCPリスナーのプロパティを表示できます。

  7. 有効にし、SSL/TLSを構成するHTTP/TCPリスナーを選択します。

    「リスナー設定」ページが表示されます。

  8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。

    「SSL/TLS設定」ページが表示されます。

  9. 「SSL設定」セクションで証明書を管理できます。

  10. フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。

    「取消」ボタンをクリックすることで、いつでも変更を破棄できます。

  11. 必要な変更を行った後、「OK」をクリックします。

    更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したリスナーの暗号の構成

  • 現在HTTPまたはTCPリスナーで有効になっている暗号を表示するには、次の例に示すように、otd_getHttpListenerSslPropertiesまたはotd_getTcpListernerSslPropertiesコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['http-listener'] = 'http-listener-1'
    otd_getHttpListenerSslProperties(props)
    

    現在有効になっている暗号のカンマ区切りのリストがcipherプロパティに返されます。

  • リスナーに対して特定の暗号を有効または無効にするには、otd_setHttpListenerSslPropertiesまたはotd_setTcpListenerSslPropertiesコマンドを実行し、有効にする暗号をciphersプロパティに指定します。

  • otd_getHttpListenerSslPropertiesまたはotd_getTcpListenerSslPropertiesコマンドを実行するときに、サポートされている暗号のリストは別のプロパティ「supported-ciphers」で表示されます。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

Oracle Traffic Directorでサポートされている暗号スイート

SSL/TLSハンドシェイク中、Oracle Traffic Directorとクライアント間でどの暗号スイートを使用するかのネゴシエーションが行われます。表10-1に、Oracle Traffic Directorでサポートされている暗号スイートを示します。このリストは、この項で説明したWLSTコマンドotd_getVirtualServerSslPropertiesを実行すると表示されます。各暗号スイートの名前は、鍵交換アルゴリズム、ハッシュ・アルゴリズム、暗号化アルゴリズムを表しています。

  • サポートされるプロトコル

    • TLS: TLS 1.0, 1.1, 1.2

    • SSL: SSL 3

  • サポートされる鍵交換アルゴリズム

    • RSA

    • RSA_EXPORT

    • RSA_EXPORT1024

    • RSA_FIPS

    • ECDHE_RSA

    • ECDH_RSA

    • ECDH_ECDSA

    • ECDHE_ECDSA

  • サポートされる暗号化アルゴリズム

    • AES_256_CBC: 256ビット鍵

    • 3DES_EDE_CBC: 168ビット鍵

    • AES_128_CBC: 128ビット鍵

    • RC4_128: 128ビット鍵

    • DES_CBC: 56ビット鍵

    • RC4_56: 56ビット鍵

    • RC4_40およびRC2_CBC_40: 128ビット鍵。ただし、暗号化で意味を持つのは40ビットのみ

    • NULL: 暗号化なし

  • サポートされるメッセージ認証コード(MAC)アルゴリズム

    • SHA: 160ビット・ハッシュ

    • NULL: ハッシュなし

表10-1 Oracle Traffic Directorでサポートされる暗号スイート

暗号スイート FIPS 140準拠

SSL_RSA_WITH_RC4_128_SHA


SSL_RSA_WITH_3DES_EDE_CBC_SHA


TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

はい

TLS_ECDHE_RSA_WITH_RC4_128_SHA


TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

はい

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

はい

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

はい

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA


TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

はい

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

はい

TLS_RSA_WITH_AES_128_CBC_SHA

はい

TLS_RSA_WITH_AES_256_CBC_SHA

はい

TLS_RSA_WITH_AES_128_CBC_SHA256


TLS_RSA_WITH_AES_256_CBC_SHA256


TLS_RSA_WITH_AES_128_GCM_SHA256


TLS_RSA_WITH_AES_256_GCM_SHA384


TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256


TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384


TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256


TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384


TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256


TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384



FIPS 140準拠に関する情報の出典: http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html

10.1.5 証明書の選択ロジック

HTTPSリクエストの受信時、Oracle Traffic DirectorがSSL/TLSハンドシェイク中に送信する証明書は、次のいずれかになります。

  • 構成したHTTP/TCPリスナーにバインドされている仮想サーバーに関連付けられている証明書

  • リスナーのデフォルト仮想サーバーに関連付けられている証明書

  • リスナーに関連付けられている証明書

Oracle Traffic Directorは、次のロジックを使用して、SSL/TLSハンドシェイク中にクライアントに送信する証明書を決定します。

表10-2 証明書の選択ロジック

条件 ケースA ケースB ケースC ケースD

クライアントがSNIホスト拡張を送信しました

はい

はい

はい

いいえ

一致する脚注1仮想サーバーが見つかりました。

はい

いいえ

いいえ

--

一致する仮想サーバーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

はい

--

--

--

リスナーのデフォルト仮想サーバーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

--

はい

--

--

リスナーに、クライアントから送信された暗号に一致する証明書タイプ(RSAまたはECC)があります。

--

--

はい

はい

選択される証明書:

一致する仮想サーバーの証明書

デフォルト仮想サーバーの証明書

リスナーの証明書

リスナーの証明書


脚注1 一致する仮想サーバーとは、リスナーにバインドされている仮想サーバーで、クライアントから送信されたHost:ヘッダーと一致するホスト・パターンを持ちます。

10.1.6 厳密なSNIホスト一致について

SSL/TLSが有効化されたOracle Traffic DirectorインスタンスにクライアントがHTTPSリクエストを送信する際、サーバーは、SSL/TLSハンドシェイクを開始するために証明書をクライアントに送信する必要があります。リクエスト内のホスト名が、サーバーから提供される証明書内のサーバー名(通常、CN)と一致しない場合、警告メッセージが、クライアントによってユーザーに表示されます。SSL/TLSハンドシェイク・プロセスを続行するには、ユーザーは、証明書を信頼することを明示的に選択する必要があります。

Oracle Traffic Directorインスタンスに、単一のIPアドレスとポートの組合せで構成された名前ベースの仮想サーバーが複数含まれている場合、クライアントに送信する適切な証明書を特定するには、サーバーは、HTTPリクエスト内のHostヘッダーの値を認識している必要がありますが、この値は、SSL/TLS接続が確立されるまで読み取ることはできません。

Server Name Indication (SNI)と呼ばれる、SSLとTLSプロトコルの拡張により、リクエストされたホスト名をSNIホスト拡張でSSL/TLSハンドシェイク中に提供することをクライアントに許可することで、この問題に対応します。Oracle Traffic Directorは、SNIホスト拡張内のホスト名を使用して、クライアントに送信する仮想サーバー証明書を特定します。仮想サーバーと証明書の関連付けの詳細は、10.1.3項「仮想サーバーと証明書の関連付け」を参照してください。

SNIのサポートは、Oracle Traffic DirectorのSSL/TLSが有効化されたHTTPリスナーに対してデフォルトで有効化されています。より厳密に制御するために、非SNIクライアントが名前ベースの仮想サーバーにアクセスできないようにする場合は、「厳密なSNIホスト一致」パラメータを有効化する必要があります。

「厳密なSNIホスト一致」がHTTPリスナーに対して有効化されていて、そのリスナーに対し、仮想サーバーの少なくとも1つに証明書がある場合、次の条件のいずれかが真であれば、Oracle Traffic Directorにより403-Forbiddenエラーがクライアントに返されます。

  • SSL/TLSハンドシェイク中、クライアントからSNIホスト拡張が送信されませんでした。

  • リクエストに、Host:ヘッダーがありません。

  • SSL/TLSハンドシェイク中にSNIホスト拡張でクライアントから送信されたホスト名が、リクエスト内のHost:ヘッダーと一致しません。

10.1.7 SSL/TLSの概念

この項では、セキュリティ関連の概念についての基本情報を説明します。次の項目が含まれます。

SSLについて

Secure Socket Layer (SSL)は、インターネットの通信およびトランザクションを保護するプロトコルです。デジタル証明書を使用することで、サーバーとクライアント間のセキュアで機密性の高い通信が可能になります。Oracle Traffic Directorは、SSL v3およびトランスポート層セキュリティ(TLS) v1をサポートしています。

双方向HTTP over SSL (HTTPS)接続では、ブラウザ、Webサーバーなどのそれぞれの装置がまず、相手のアイデンティティを確認します。このフェーズをSSL/TLSハンドシェイクと呼びます。アイデンティティが確認された後、接続が確立され、データが暗号化された形式で交換されます。SSLが有効なブラウザとSSLが有効なサーバー間におけるSSL/TLSハンドシェイクの手順を次に示します。

  1. ブラウザは、http://ではなくhttps://で始まるURLを送信し、サーバーへの接続を試みます。

  2. サーバーがそのデジタル証明書(「証明書について」を参照)および公開鍵をクライアントに送信します。

  3. クライアントは、サーバーの証明書が現行のものであるかどうか(つまり、失効していないか)、およびクライアントが信頼している認証局(CA)によって発行されたものかどうかをチェックします。

  4. 証明書が有効な場合、クライアントは、1回限りの一意のセッション鍵を生成し、サーバーの公開鍵で暗号化して、その暗号化した鍵をサーバーに送信します。

  5. サーバーは、秘密鍵を使用してクライアントからのメッセージを復号化し、セッション鍵を取得します。

この時点で、クライアントは、サーバー・アイデンティティを確認済となり、クライアントとサーバーのみが、クライアントが生成した一意のセッション鍵のコピーを持ちます。セッションが終了するまで、クライアントとサーバーはこの鍵を使用して、互いの間のすべての通信を暗号化します。

暗号について

暗号は、データの暗号化および復号化に使用されるアルゴリズムであり、数学関数です。暗号によって、強度や堅牢性は異なります。通常、暗号で使用されるビット数が多いほど、その暗号を使用して暗号化されたデータの復号化を難しくなります。

SSL v3およびTLS v1は、様々な暗号をサポートしています。サポートしているプロトコル、暗号化強度についての組織のポリシー、および暗号化されたソフトウェアに対する政府による輸出規制などの要因に応じて、クライアントおよびサーバーでサポートできる暗号スイートは異なります。

双方向の暗号プロセスでは、クライアントとサーバーは、同じ暗号スイートを使用する必要があります。SSL/TLSハンドシェイク・プロセス中、サーバーとクライアントは、通信に使用する暗号スイート(通常、最も強い暗号スイート)についてネゴシエートします。

鍵について

暗号を使用した暗号化、それ自体では、データのセキュリティは確保されません。実際に暗号化された結果を作成する、暗号化済の情報を復号化するには、暗号化する暗号とともに鍵を使用する必要があります。暗号化プロセスでは、公開鍵と秘密鍵の2つの鍵が使用されます。それぞれの鍵は数学的に関連しています。したがって、公開鍵を使用して暗号化された情報は、関連付けられた秘密鍵でのみ復号化でき、その逆も同様です。公開鍵は、証明書の一部として所有者によって公開されます(「証明書について」を参照)。関連付けられている秘密鍵のみが保護されます。

証明書について

証明書は、インターネット上の個人、会社またはその他のエンティティを一意に識別するデータの集合です。証明書を使用することで、2つのエンティティ間のセキュアで機密性の高い通信が可能になります。個人の証明書は、個人が使用するもので、サーバーの証明書は、サーバーとクライアント間でSSLを利用したセキュアなセッションを確立するために使用されます。

証明書は、(サーバーによって)自己署名されるか、認証局(CA)と呼ばれる信頼できるサードパーティによって署名されたものであるか、自分で生成したもののいずれかです。証明書の保有者は、アイデンティティの証明として証明書を提示し、暗号化された機密性の高い通信を確立できます。CAは、サードパーティ・ベンダー、または組織のサーバーに対して証明書を発行する社内の担当部門である場合があります。

証明書は、公開鍵による暗号化に基づいており、この暗号化では、(非常に長い番号)のペアが使用され、目的の受信者のみが読み取れるように情報を暗号化します。受信者は、鍵の1つを使用して情報を復号化します。

証明書によって、所有者の公開鍵と所有者のアイデンティティがバインドされます。公開鍵に加えて、証明書には、通常次の情報が含まれます。

  • 保有者の名前およびその他の識別情報(証明書を使用するサーバーのURLなど)

  • 証明書を発行したCAの名前

  • 発行したCAのデジタル署名

  • 証明書の有効期間

10.2 Oracle Traffic Directorとオリジン・サーバー間のSSL/TLSの構成

この項では、SSL/TLSを使用して、Oracle Traffic Directorインスタンスと、Oracle WebLogic ServerおよびOracle HTTP Serverインスタンスであるオリジン・サーバー間の通信をどのように保護するかについて説明します。次の項目が含まれます。

10.2.1 一方向および双方向のSSL/TLSについて

Oracle Traffic Directorと、バック・エンドのオリジン・サーバー間の接続は、一方向または双方向のSSL/TLSを使用して保護できます。

  • 一方向SSL/TLS: SSL/TLSが有効化されたオリジン・サーバーでは、証明書がOracle Traffic Directorインスタンスに提示されます。SSL/TLSハンドシェイク中、Oracle Traffic Directorインスタンスは証明書をオリジン・サーバーに提示するように構成されていません。

  • 双方向SSL/TLS: SSL/TLSが有効化されたオリジン・サーバーでは、証明書がOracle Traffic Directorインスタンスに提示されます。Oracle Traffic Directorインスタンスも自身の証明書をオリジン・サーバーに提示します。オリジン・サーバーは、SSL/TLS接続を確立する前に、Oracle Traffic Directorインスタンスのアイデンティティを確認します。さらに、SSL/TLS接続の両端(Oracle Traffic Directorまたはオリジン・サーバー、あるいはその両方)が、証明書の交換中にホスト名を確認するように構成できます。

10.2.2 Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成

Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSを構成するには、オリジン・サーバーの証明書をPKCS#12形式でエクスポートし、Oracle Traffic Directorの証明書データベースにインストールして、オプションで、その証明書を信頼するようにOracle Traffic Directorを構成します。


注意:

  • この項で説明する手順は、オリジン・サーバー・プール内のすべてのサーバーが、同じCAが発行した証明書を使用しているというシナリオに沿っています。このようなシナリオでは、オリジン・サーバーの証明書に署名したCAのルート証明書を、Oracle Traffic Directorの証明書データベースにインポートするだけで、一方向のSSL/TLSを構成できます。

  • オリジン・サーバーが自己署名証明書、または異なるCAが発行した証明書を使用している場合、各サーバーの証明書、またはサーバー証明書に署名したCAの各ルート証明書を個別にエクスポートおよびインポートする必要があります。

  • Weblogic Server Fusion Middleware Controlからアクセス可能なWebLogic Server Plug-In Enabled属性がtrueに設定されていて、SSL接続がOracle Traffic Directorで終端する場合、Oracle Traffic Directorは、WebLogic Serverにデプロイされているアプリケーションに証明書情報を通知します。アプリケーションは、鍵サイズや暗号など証明書内の特定の情報を検証してから、クライアントにアプリケーションへのアクセスを許可します。


  1. 証明書をオリジン・サーバーに発行したCAのルート証明書を、PKCS#12形式でエクスポートします。

    • Oracle WebLogic Serverオリジン・サーバーの場合:

      Java SE 6で使用可能なkeytoolコマンドを使用します。

      構文:

      > $JAVA_HOME/bin/keytool -exportcert -alias alias -file file -keystore keystore -storepass storepass -rfc
      

      aliasはエクスポートされる証明書のニックネーム、fileはエクスポートされる証明書の名前、keystoreはカスタムのOracle WebLogic Serverアイデンティティ・ストア・ファイルの名前、storepassは指定したキーストアのパスワードです。

      :

      > $JAVA_HOME/bin/keytool -exportcert -alias wlsos1 -file wls_os_cert
       -keystore $DOMAIN_HOME/soa_domain/soa_keystore.jks -storepass stpass -rfc
      

      keytoolの詳細は、次の場所にあるドキュメントを参照してください。

      http://docs./javase/6/docs/technotes/tools/windows/keytool.html

    • Oracle HTTP Serverオリジン・サーバーの場合:

      exportWalletObject WebLogic Scripting Tool (WLST)コマンドを使用します。

      構文:

      exportWalletObject(instName, compName, compType, walletName, password, type, path, DN)
      

      :

      > exportWalletObject('inst1', 'ohs1', 'ohs','wallet1', 'password', 'Certificate', '/tmp','cn=soa.example.com')
      

      このコマンドでは、Oracle HTTP Serverインスタンスohs1について、DN cn=soa.example.comの証明書がウォレットwallet1からエクスポートされます。信頼できる証明書は、ディレクトリ/tmpにエクスポートされます。

      exportWalletObjectコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』exportWalletobjectを参照してください。

  2. importKeyStoreCertificate WLSTコマンドを使用して、エクスポートしたルート証明書をOracle Traffic Directorの証明書データベースにインストールします。


    注意:

    Fusion Middleware Controlを使用した証明書のインストールの詳細は、10.3.3項「証明書のインポート」を参照してください

    構文:

    -----BEGIN CERTIFICATE-----
    (Server SSL certificate)
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    (Intermediate certificate)
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    (Root certificate)
    -----END CERTIFICATE-----
    

    :

    svc = getOpssService("KeyStoreService")
     # generate a key pair with the proper DN
    svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')
    

    注意:

    オリジン・サーバーが自己署名証明書または異なるCAによって発行された証明書を使用している場合、手順1および2のかわりに次の操作を行います。
    1. 手順1で使用した同じコマンドを使用して、各サーバー証明書、またはサーバー証明書に署名したCAの各ルート証明書をエクスポートします。

    2. 手順2の説明に従い、importKeyStoreCertificate WLSTを使用して(ただし、--cert-type=serverを指定)、前の手順でエクスポートした各証明書をOracle Traffic Directorの証明書データベースにインストールします。


  3. 必要に応じて、otd_setRouteProperties WLSTを使用して、オリジン・サーバーの証明書のホスト名を確認するようにOracle Traffic Directorを構成します。

    構文:

    otd_setRouteProperties(props)
    

    :

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    props['route'] = 'route-1'
    props['websocket-idle-timeout'] = '1200'
    otd_setRouteProperties(props)
    

    構成内の仮想サーバーのリスト、および仮想サーバーに定義されているルートを表示するには、otd_listVirtualServersおよびotd_listRoutes WLSTコマンドをそれぞれ使用します。


    注意:

    SSL/TLSハンドシェイク中に、オリジン・サーバーの証明書のホスト名を検証するようにOracle Traffic Directorを構成することを選択した場合、次の操作を行う必要があります。

    そうでない場合、オリジン・サーバーがその証明書を提示した際、Oracle Traffic Directorは証明書のホスト名を検証できず、このためSSL/TLSハンドシェイクが失敗します。


10.2.3 Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSの構成

Oracle Traffic Directorとオリジン・サーバー間の双方向SSL/TLSを構成するには、次の操作を行います。


注意:

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

  1. 10.2.2項「Oracle Traffic Directorとオリジン・サーバー間の一方向SSL/TLSの構成」の説明に従い、一方向SSL/TLSを構成する手順を実行します。

  2. 10.3.2項「CA署名証明書の取得」の説明に従い、CAによって発行されたOracle Traffic Directorのサーバー証明書を取得します。

  3. 10.3.3項「証明書のインポート」の説明に従い、CAによって発行された証明書をOracle Traffic Director構成にインストールします。

  4. otd_enableRouteAuth WLSTを使用して、Oracle Traffic Directorがオリジン・サーバーに提示する必要がある証明書を指定し、必要なOracle Traffic Directorルートを構成します。

    構文:

    otd_enableRouteAuth(props)
    

    :

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    props['route'] = 'route-1'
    props['auth-user'] = 'baz'
    props['auth-password'] = 'qux'
    otd_enableRouteAuth(props)
    

    構成内の仮想サーバーのリスト、および仮想サーバーに定義されているルートを表示するには、otd_listVirtualServersおよびotd_listRoutes WLSTコマンドをそれぞれ使用します。

  5. activateコマンドを使用して、更新された構成をOracle Traffic Directorインスタンスにデプロイします。

    pullComponentChanges(<instance_name>)
    
  6. Oracle Traffic Directorインスタンスの証明書に署名したCAのルート証明書をキーストアからエクスポートします。

    構文:

    svc = getOpssService("KeyStoreService")
    svc.exportKeyStoreCertificate(appStripe='<stripe>', name='<keystore>', password='<password>', alias='<alias>', type='<entrytype>', filepath='<absolute_file_path>')
    

    svcはgetOpssService()の呼び出しを通じて取得されたサービス・コマンド・オブジェクト、appstripeはキーストアを含むストライプの名前、nameはキーストアの名前、passwordはキーストアのパスワード、aliasはエクスポートされるエントリの別名、typeはエクスポートされるキーストア・エントリのタイプです。有効な値は「証明書」、「信頼できる証明書」、または「証明書チェーン」であり、filepathは証明書、信頼できる証明書、または証明書チェーンがエクスポートされるファイルの絶対パスです。

    :

    svc = getOpssService("KeyStoreService")
    svc.exportKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='rootca', keypassword='', type='TrustedCertificate', filepath='/scratch/rootcert.txt')
    

    exportKeyStoreCertificateコマンドの詳細は、次のコマンドを実行してください。

    svc = getOpssService("KeyStoreService")
    svc.help('exportKeyStoreCertificate')
    
  7. 前の手順でエクスポートしたルート証明書を、Oracle WebLogic Serverオリジン・サーバー(およびOracle HTTP Serverオリジン・サーバーのOracleウォレット)の信頼キーストアにインポートします。

    • Oracle WebLogic Serverオリジン・サーバーの場合:

      Java SE 8で使用可能なkeytoolコマンドを使用します。

      構文:

      > $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias alias
      -file cert_file -keystore keystore_file -storepass keystore_password
      -noprompt
      

      aliasは前の手順でエクスポートされたCA発行のルートCAのニックネーム、fileはエクスポートされた証明書ファイルの名前、keystoreはカスタムのOracle WebLogic Serverアイデンティティ・ストア・ファイルの名前、storepassは指定したキーストアのパスワードです。

      :

      > $JAVA_HOME/bin/keytool -importcert -v -trustcacerts -alias rootca1
       -file /tmp/rootca1.pem -keystore $DOMAIN_HOME/soa_domain/soa_keystore.jks
       -storepass stpass -noprompt
      

      keytoolの詳細は、次の場所にあるドキュメントを参照してください。

      http://docs./javase/8/docs/technotes/tools/windows/keytool.html

    • Oracle HTTP Serverオリジン・サーバーの場合:

      importWalletObject WLSTコマンドを使用します。

      構文:

      importWalletObject(instName, compName, compType, walletName, password, type, filePath)
      

      :

      > importWalletObject('inst1', 'ohs1', 'ohs','wallet1', 'password', 'TrustedCertificate','/tmp/rootca1.pem')
      

      importWalletObjectコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』importwalletobjectを参照してください。

  8. SSL/TLSハンドシェイク中にOracle Traffic Directorにそのクライアント証明書の提示を要求するように、オリジン・サーバーを構成します。

    • Oracle WebLogic Serverオリジン・サーバーの場合:

      Oracle WebLogic Server Fusion Middleware Controlオンライン・ヘルプの双方向SSLの構成に関する項で説明されている手順を実行します。


      注意:

      Oracle WebLogic Serverでは、デフォルトでホスト名の確認が有効化されています。ホスト名検証の無効化の詳細は、Oracle WebLogic Server Fusion Middleware Controlオンライン・ヘルプのホスト名検証の無効化に関する項を参照してください。

    • Oracle HTTP Serverオリジン・サーバーの場合:

      httpd.confファイルに次のディレクティブを追加します。

      SSLVerifyClient require
      

10.2.4 非SSL Oracle Traffic DirectorインスタンスからSSL Oracle Traffic Directorインスタンスへの変換

非SSL Oracle Traffic DirectorインスタンスをSSL Oracle Traffic Directorインスタンスに変換するには、次を実行します。

  1. Oracle Fusion Middlewareの管理の「ウォレットの作成」の説明に従って、ウォレットを作成します。

  2. Oracle Fusion Middlewareの管理の「証明書または信頼できる証明書のインポート」の説明に従って、必要なルート証明書、中間証明書、サーバー証明書をウォレットにインポートします。

  3. 9.1項「リスナーの作成」の説明に従って、ポート4443の新しいHTTPSリスナーを作成します。

  4. 4.3項「Oracle Traffic Directorインスタンスの起動、停止および再起動」の説明に従って、サービスを再起動します。

10.3 証明書の管理

この項は、次の項目を含んでいます。


注意:


10.3.1 鍵ペアの生成

証明書にCAによる署名が必要ない場合、またはデモ用のCA証明書によるCA署名処理でSSL/TLSの実装をテストする場合は、鍵ペアを生成できます。

鍵ペアを使用してOracle Traffic Director仮想サーバーのSSL/TLSを有効にしている場合、クライアントが仮想サーバーのhttps://のURLにアクセスすると、署名しているCAが不明であり信頼できないことを示すエラー・メッセージが表示されます。接続を続行するために、クライアントは、自己署名証明書を信頼するように選択できます。

Fusion Middleware ControlまたはWLSTのいずれかを使用して、鍵ペアを生成できます。

始める前に

鍵ペアの生成を開始する前に、次のことを決定します。

  • 鍵ペアのニックネーム(鍵ペアの生成のみに必要)。

  • 鍵のタイプ(RSAまたはECC)。

    Oracle Traffic Directorは、従来のRSAタイプの鍵、およびより高度な楕円曲線暗号(ECC)鍵の生成をサポートしています。ECCは、演算処理の高速化、電力消費の低減およびメモリーと帯域幅の節約を図れる、小さいサイズの鍵と同等のセキュリティを提供します。

  • 鍵サイズ(RSA)または曲線(ECC)。

    RSA鍵では、512、1024、2048または4096ビットを指定できます。鍵の桁が多いほど、暗号化の強度は向上しますが、Oracle Traffic Directorは生成するのにより長い時間を必要とします。

    ECCでは、鍵のペアを生成するための曲線を指定する必要があります。Oracle Traffic Directorでは、次の曲線がサポートされています: 163(sect163r2)、192(secp192r1)、224(secp224r1)、233(sect233k1)、256(secp256r1)、283(sect283k1)、384(secp384r1)、409(sect409k1)、521(secp521r1)、571(sect571k1)。

Fusion Middleware Controlを使用した鍵ペアの生成

Fusion Middleware Controlを使用して自己署名証明書を作成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 自己署名証明書を作成する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書の管理」を選択します

    画面に新しいページが表示されます。

  7. 「共通タスク」バーにある「鍵ペアの生成」ボタンをクリックします。

    新規の鍵ペアの生成ウィザードが開きます。

    図10-1 新規鍵ペアの生成ウィザード

    図10-1の説明が続きます
    「図10-1 新規鍵ペアの生成ウィザード」の説明

  8. 「OK」をクリックします。証明書リスト内に新規証明書が表示されます。

  9. 証明書の別名をクリックして証明書の詳細を表示します

    鍵ペアは、デモ用のCA署名証明書でラップされ、トラスト・ストアに格納されています。アプリケーションでトラスト・ストアを使用していない場合は、デモ用のCA証明書をカスタム・キーストアにインポートする必要があります。

WLSTを使用した鍵ペアの生成

鍵ペアを生成するには、次の例に示すように、generateKeyPairコマンドを実行します。

svc = getOpssService("KeyStoreService")
svc.generateKeyPair(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='',dn='CN=test., OU=Webtier, O=\'Oracle Corporation\', ST=California, C=US', keysize='1024')

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

generateKeyPairの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3.2 CA署名証明書の取得

認証局(CA)によって署名された証明書を取得するには、「証明書署名リクエスト(CSR)」をCAに送信し、必要に応じて規定の料金を支払ったら、CAによってリクエストが承認され証明書が付与されるのを待ちます。

CSRは、サーバー名、組織名、国などの情報を含むデジタル・ファイル(Base-64でエンコーディングされたPEM形式の暗号化済テキスト・ブロック)です。また、証明書に含められる公開鍵も含まれます。

Oracle Traffic DirectorのFusion Middleware ControlまたはWLSTのいずれかを使用して、CSRを生成できます。

Fusion Middleware Controlを使用したCSRの生成

Fusion Middleware Controlを使用してCSRを生成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. CSRを作成する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書の管理」を選択します

    画面に新しいページが表示されます。

  7. 使用可能な証明書のリストが表示されます。
    CSRを生成する証明書を選択します。

  8. 「共通タスク」ペインにある「CSRの生成」ボタンをクリックします。

    「CSRの生成」をエクスポートできる新規ウィンドウが表示されます。

  9. 「CSRのエクスポート」画面上のプロンプトに従い、「CSRのエクスポート」をクリックしてそのコピーを保存し、「閉じる」をクリックします

これで、選択したCAに証明書の署名料金とともにCSRを送信できるようになりました。

WLSTを使用したCSRの生成

CSRを生成するには、次の例に示すように、exportKeyStoreCertificateRequestコマンドを実行します。

# generate the CSR and put it in to a text file
svc.exportKeyStoreCertificateRequest(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='', filepath='/scratch/certreq.crt')

このコマンドによりCSRが生成され、Fusion Middleware Controlを使用した鍵ペアの生成に示すようなCSRの暗号化されたテキストが表示されます。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

exportKeyStoreCertificateRequestの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

作成したCSRに対応するCA署名証明書を取得した後、10.3.3項「証明書のインポート」の説明に従い、適切な構成に証明書をインポートする必要があります。

10.3.3 証明書のインポート

Fusion Middleware ControlまたはWLSTのいずれかを使用して、生成した鍵ペアまたはCA署名証明書をインポートできます。

この項は、次の項目を含んでいます。

  • Fusion Middleware Controlを使用した証明書のインポート

  • WLSTを使用した証明書のインポート

Fusion Middleware Controlを使用した証明書のインポート

Fusion Middleware Controlを使用して証明書または信頼できる証明書をインポートするには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 証明書をインポートする構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書の管理」を選択します

    画面に新しいページが表示されます。

  7. 「インポート」ボタンをクリックします。

    図10-2に示す、証明書のインポート・ウィザードが開きます。

    図10-2 証明書のインポート

    図10-2の説明が続きます
    「図10-2 証明書のインポート」の説明

  8. 「証明書タイプ」ドロップダウンから、「証明書」「信頼できる証明書」、または「証明書チェーン」を選択します。


    注意:

    • 自己署名証明書をインポートしている場合は、「証明書タイプ」ドロップダウンから「信頼できる証明書」を選択します。

    • CA署名証明書をインポートしている場合は、「証明書タイプ」ドロップダウンから「証明書チェーン」を選択します。

    • 証明書チェーンをインポートしている場合、CAから取得した証明書チェーンがPKCS7形式で作成されていることを確認します。


  9. 証明書または証明書チェーンをインポートしている場合は、ドロップダウンから「別名」を選択します。信頼できる証明書をインポートしている場合は、「別名」の名前を指定します。

  10. 証明書ソースを指定します。貼付けオプションを使用する場合は、証明書をコピーして直接テキスト・フィールドに貼り付けます。ファイルの選択オプションを使用する場合は、「参照」をクリックしてオペレーティング・システムからファイルを選択します。

  11. 「OK」をクリックします。インポートされた証明書または信頼できる証明書が、証明書の一覧に表示されます。

WLSTを使用した証明書のインポート

証明書をインポートするには、次の例に示すように、importKeyStoreCertificateコマンドを実行します。

svc.importKeyStoreCertificate(appStripe='OTD', name='myconfig', password='', alias='ca-cert', keypassword='', type='Certificate', filepath='/scratch/cacert.crt')

証明書チェーンをインポートするには、次の例に示すように、importKeyStoreCertificateコマンドを実行します。

svc.importKeyStoreCertificate(appStripe='TEST_STRIPE',name='sample',password='welcome1', alias='test_cert', keypassword='welcome1',type='CertificateChain',filepath='/scratch/mwport/rpolavar/CERTS/testCertChain.crt')

このコマンドでは、構成soaにニックネームsoa-certでサーバー証明書がインストールされます。CA証明書をインストールするには、--cert-typeオプションでcaを指定します。


注意:

証明書チェーンをインポートしている場合、CAから取得した証明書チェーンがPKCS7形式で作成されていることを確認します。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

importKeyStoreCertificateの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3.4 証明書リストの表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成にインストールされている証明書のリストを表示できます。

Fusion Middleware Controlを使用した証明書のリストの表示

Fusion Middleware Controlを使用して構成にインストールされている証明書のリストを表示するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 証明書を表示する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書の管理」を選択します

    画面に新しいページが表示されます。

  7. 「共通タスク」バーの下に証明書のリストが表示されます。

WLSTを使用した証明書のリストの表示

  • 構成にインストールされている証明書のリストを表示するには、次の例に示すように、otd_listCertificatesコマンドを実行します。

    • 次のコマンドでは、構成のサーバー証明書のリストが表示されます。

      props = {}
      props['configuration'] = 'foo'
      otd_listCertificates(props)
      
  • 証明書のプロパティを表示するには、次の例に従い、getKeyStoreCertificatesコマンドを実行します。

    svc = getOpssService("KeyStoreService")
    svc.getKeyStoreCertificates(appStripe='OTD', name='myconfig', password='', alias='mycert')
    

注意:

指定した構成でPINがトークンに対して有効化されている場合、otd_listCertificatesおよびgetKeyStoreCertificatesコマンドを実行する際に、トークンPINを入力するプロンプトが表示されます。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.3.5 サーバー証明書の更新

証明書を更新するには、次の操作を行います。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「構成」ボタンをクリックします。

    使用可能な構成のリストが表示されます。

  3. 証明書を更新する構成を選択します。

  4. ナビゲーション・ペインで、「SSL」を展開し、「サーバー証明書」を選択します。

    結果のページに、インストールされているサーバー証明書が表示されます。


    注意:

    選択した構成でトークンに対してPINが有効化されている場合、インストールされている証明書は表示されません。かわりに、トークンのPINを入力するメッセージがページに表示されます。
    1. 「トークンPINのキャッシュ」をクリックします。

    2. 表示されたダイアログ・ボックスで、トークンのPINを入力し、「OK」をクリックします。


  5. 更新する証明書の「更新」ボタンをクリックします。

    「サーバー証明書の更新」ダイアログ・ボックスが表示されます。

  6. 新しい有効期間を指定し、「次」をクリックします。

  7. 「証明書の更新」をクリックします。

  8. 「閉じる」をクリックします。

    • 「コンソール・メッセージ」ペインに、指定した期間に対して証明書が更新されたことを確認するメッセージが表示されます。

    • 証明書の新しい有効期限が、「サーバー証明書」ページに表示されます。

10.3.6 証明書の削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成内の証明書を削除できます。

Fusion Middleware Controlを使用した証明書の削除

Fusion Middleware Controlを使用して構成内の証明書を削除するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 証明書を削除する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書の管理」を選択します

    画面に新しいページが表示されます。

  7. 「共通タスク」バーの下に証明書のリストが表示されます。

  8. 削除する証明書の「削除」ボタンをクリックします。

    • 1つ以上のリスナーが削除中の証明書と関連付けられている場合、その証明書を削除できないことを示すメッセージが表示されます。

    • 削除中の証明書が、いずれのリスナーにも関連付けられていない場合、証明書の削除を確認するプロンプトが表示されます。

      「OK」をクリックして進みます。

    「コンソール・メッセージ」ペインに、証明書が削除されたことを確認するメッセージが表示されます。

WLSTを使用した証明書の削除

証明書を削除するには、deleteKeyStoreEntryコマンドを実行します。

:

svc = getOpssService("KeyStoreService")
svc.deleteKeyStoreEntry(appStripe='OTD', name='myconfig', password='', alias='mycert', keypassword='')

削除しようとしている証明書が1つ以上のリスナーに関連付けられている場合、次のメッセージが表示されます。

OTD-64309 Certificate 'rsa-1' is being referred by listeners: listener1,listenerN

--forceオプションを指定することで、証明書を強制的に削除できます。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

deleteKeyStoreEntryの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.4 証明書失効リストの管理

証明書失効リスト(CRL)は、CAが証明書の期限が切れる前に失効させることを決定した証明書についてCAがユーザーに通知するために発行するリストです。CRLは定期的に更新され、更新されたCRLはCAのWebサイトからダウンロードできます。

Oracle Traffic Directorサーバーが、CAが失効させた証明書を信頼しないようにするために、最新のCRLをCAから定期的にダウンロードし、Oracle Traffic Director構成にインストールしておく必要があります。

CRLは手動でインストールできます。また、ダウンロード済のCRLを指定したディレクトリから指定の間隔で自動的に取得しインストールするようにOracle Traffic Directorを構成できます。

この項は、次の項目を含んでいます。


注意:


10.4.1 CRLの手動によるインストールおよび削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、CRLを手動でインストールおよび削除できます。

Fusion Middleware Controlを使用したCRLの手動インストール

Fusion Middleware Controlを使用してダウンロードされたCRLをインストールするには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. 証明書をインストールする構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書失効リスト」を選択します

    画面に新しいページが表示されます。

  7. 「CRLのインストール」ボタンをクリックします。

    「証明書失効リストのインストール」ダイアログ・ボックスが表示されます。

  8. ダウンロードしたCRLファイルの場所を指定し、「CRLのインストール」をクリックします。

    • CRLのインストールが成功したことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

    • インストールしたCRLは、「認証局」ページに表示されます。

WLSTを使用したCRLの手動によるインストールおよび削除

  • ダウンロードされたCRLをインストールするには、次の例に示すように、otd_installCrlコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['file-path'] = '/export/ServerSign.crl'
    otd_installCrl(props).
    
  • 構成にインストールされているCRLのリストを表示するには、次の例に示すように、otd_listCrlsコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    otd_listCrls(props)
    ---------------------------
    "Class 1 Public Primary Certification Authority" "Sat Apr 15 16:59:59 PDT 2000"
    "VeriSign Class 3 Code Signing 2010 CA" "Mon Aug 29 14:00:03 PDT 2011"
    "VeriSign Class 3 Organizational CA" "Sun May 18 13:48:16 PDT 2014"
    
  • CRLを削除するには、次の例に示すように、otd_deleteCrlコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['issuer'] = 'CN=GlobalSign ServerSign CA,OU=ServerSign CA,O=GlobalSign nv-sa,C=BE'
    otd_deleteCrl(props)
    

    CRLを削除すると、CRLはOracle Traffic Director構成、およびダウンロードされたCRLが格納されているディレクトリから削除されます。

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.4.2 CRLの自動更新

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ダウンロードされたCRLファイルが指定したディレクトリから定期的に取得され、自動的にインストールされるようにOracle Traffic Directorを構成できます。

Oracle Traffic Directorは、指定されたディレクトリ上の更新されたCRLファイルを、指定された間隔で検索します。

  • Oracle Traffic Directorは、新しいCRLファイルを検出した場合、そのファイルを構成にインストールし、サーバー・ログにメッセージを記録します。

  • 既存のCRLファイルが変更された場合、Oracle Traffic Directorは、更新されたCRLファイルを構成にインストールし、サーバー・ログにメッセージを記録します。

  • Oracle Traffic Directorが、前にインストール済のCRLファイルがディレクトリから削除されていることを検出すると、構成からCRLを削除し、サーバー・ログにメッセージを記録します。

  • CRLディレクトリで変更が検出されない場合、Oracle Traffic Directorは更新を実行しません。

Fusion Middleware Controlを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成

Fusion Middleware Controlを使用して、CRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. CRLを自動的にインストールするように設定する構成の名前をクリックします。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「セキュリティ」→「証明書失効リスト」を選択します

    画面に新しいページが表示されます。

  7. 「CRLのインストール」ボタンをクリックします。

    「証明書失効リストのインストール」ダイアログ・ボックスが表示されます。

  8. ダウンロードしたCRLファイルの場所を指定し、「CRLのインストール」をクリックします。

    • CRLのインストールが成功したことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

    • インストールしたCRLは、「認証局」ページに表示されます。

  9. ページの「詳細設定」セクションに移動します。

  10. 「CRL更新イベント」フィールドに、更新されたCRLファイルを含むディレクトリへの絶対パスを入力します。

  11. 「新規イベント」をクリックします。

    「新規CRL更新イベント」ダイアログ・ボックスが表示されます。

  12. CRLを更新する間隔または時刻を指定し、「OK」をクリックします。

    • イベントの作成を確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

    • 新規イベントが「CRL更新イベント」リストに表示されます。

      • 新しいイベントはデフォルトで有効になっています。ステータスを変更するには、「有効化/無効化」チェック・ボックスを選択します。

      • イベントを削除するには、「削除」ボタンをクリックします。

WLSTを使用したOracle Traffic DirectorにおけるCRLの自動インストールの構成

CRLを自動的にインストールするようにOracle Traffic Directorを構成するには、次の操作を行います。

  1. otd_createEventコマンドを使用して、Oracle Traffic Directorにより、ダウンロードされたCRLが指定されたディレクトリから取得され、自動的にインストールされるようにイベントをスケジュールします。

    たとえば、次のコマンドでは、構成fooのCRLは毎日12時に更新されます。

    props = {}
    props['configuration'] = 'foo'
    props['event'] = 'event-1'
    props['command'] = 'update CRL'
    props['time'] = '12:00'
    otd_createEvent(props)
    

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.5 Webアプリケーション・ファイアウォールの管理

Webアプリケーション・ファイアウォール(WAF)とは、HTTPリクエストにルール・セットと呼ばれる一連のルールを適用するフィルタまたはサーバー・プラグインのことです。Webアプリケーション・ファイアウォールは、攻撃を検知および阻止するためにセキュリティ・レイヤーを強化する手段として役立ちます。これはオリジン・サーバー内にホストされているアプリケーションのファイアウォールとして機能します。また、管理者がヘッダーや本文などHTTPリクエストの任意の部分を調査したり、条件を構成しHTTPリクエストがその条件に基づいて許可または拒否されるように設定することもできます。

Webアプリケーション・ファイアウォール・モジュールには無償のバージョンと商用バージョンがあります。Oracle Traffic DirectorのWebアプリケーション・ファイアウォール・モジュールはModSecurity 2.8をサポートしています。これはWebアプリケーション用の侵入検知およ防止エンジンです。ModSecurityのルール・セットはカスタマイズ可能で、クロスサイト・スクリプティング(XSS)やSQLインジェクションなどの一般的な攻撃からアプリケーションを保護できます。HTTPヘッダー、環境変数およびCGI変数などの様々な条件に基づき、ModSecurityは受信リクエストにフィルタを適用して拒否します。ModSecurityの詳細は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Introductionを参照してください。

様々な企業がModSecurity用のルール・セットを提供していますが、Oracle Traffic Directorはオープンソース・アプリケーション・セキュリティ・プロジェクトであるOpen Web Application Security Project (OWASP)によるテストを受けた製品であり、最も使用されているルール・セット・プロバイダの1つです。詳細は、https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Projectを参照してください。

この項では、次の項目について説明します。

10.5.1 Webアプリケーション・ファイアウォールの概要

Oracle Traffic Directorを使用すると、構成内の各仮想サーバーに対してWebアプリケーション・ファイアウォールを有効化(または無効化)できます。これはルール・セットを適用し、オリジン・サーバーにデプロイされているWebアプリケーションのファイアウォールとして機能します。オリジン・サーバーおよび仮想サーバーの詳細は、第6章「オリジン・サーバーの管理」および第7章「仮想サーバーの管理」をそれぞれ参照してください。

Oracle Traffic Directorはルール・セットを仮想サーバー・レベルと構成レベルの両レベルでサポートしています。仮想サーバー・レベルで定義されたルールは、構成レベルで定義されたルールよりも優先されます。デプロイすると、これらのルールと構成変更がインスタンスにプッシュされ、インスタンスが再構成されます。Webアプリケーション・ファイアウォールの動作の詳細は、付録B「Webアプリケーション・ファイアウォールの例とユースケース」を参照してください。

10.5.2 Webアプリケーション・ファイアウォールの構成

Webアプリケーション・ファイアウォールを構成するには、オープン・ソースのWebアプリケーション・ファイアウォールのルール・セットをダウンロードするか、独自のルール・セットを作成します。たとえば、OWASPリポジトリからModSecurity Core Rule Set (CRS)をダウンロードし、ルール・セットを任意のフォルダに解凍します。Oracle Traffic Directorは次のディレクトリ内にあるルールをサポートしています。

  • base_rules

  • optional_rules

  • slr_rules


注意:

Webアプリケーション・ファイアウォールでは、OWASP ModSecurityコア・ルール・セットのディレクトリbase_rulesoptional_rulesおよびslr_rulesにある構成で使用されるModSecurity 2.8ディレクティブをサポートしています。ただし、<IfDefine...><Location...>などのApacheコア構成ディレクティブや、RequestHeaderHeaderなど、その他のApacheモジュールでサポートされているディレクティブはサポートしていません。


注意:

Webアプリケーション・ファイアウォールのルール・ファイルをインストールする前に、すべての依存ファイルがインストールされていることを確認します。そうでない場合、Webアプリケーション・ファイアウォールのルール・ファイルのインストールは失敗します。

前述のディレクトリを解凍した後、これらのディレクトリ内のファイルを編集して、管理サーバーにアップロードできます。これらのルール・セット・ファイルをデプロイすると、Oracle Traffic Directorインスタンスにプッシュされます。詳細は、10.5.2.1項「Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストール」を参照してください。


注意:

  • configディレクトリの外部にあるディレクトリからルール・セット・ファイルを取得するようサーバーを構成することもできますが、この場合ルール・ファイルの管理がサポートされなくなります。Oracle Traffic Directorを高可用性構成にする場合は、Webアプリケーション・ファイアウォール・ルール・セットをconfigディレクトリに格納することをお薦めします。

  • サポートされていないディレクティブ、変数、演算子、アクション、フェーズ、関数およびストレージを使用すると、サーバーの起動エラーの原因になります。たとえば、ルール・セット・ファイルmodsecurity_crs_42_tight_security.confを、非サポートのアクションverを削除せずにインストールすると、サーバーの起動時にOracle Traffic Directorによって次のエラー・メッセージが表示されます。

    [ERROR:16] [OTD-20016] Syntax error on line 20 of /scratch/rgoutham/instance1/net-config1/config/ruleset/config1/modsecurity_crs_42_tight_security.conf:
    [ERROR:16] [OTD-20016] Error parsing actions: Unknown action: ver
    [ERROR:32] [OTD-20008] Failed to parse VS webapp-firewall-ruleset (ruleset/config1/*.conf)
    [ERROR:32] [OTD-10422] Failed to set configuration
    [ERROR:32] server initialization failed
    

    このエラーを回避するには、ルール・セット・ファイルを編集し、サポートされていないディレクティブ、変数、演算子、アクション、フェーズ、関数およびストレージを削除またはコメント・アウトしてからサーバーを起動します。


10.5.2.1 Webアプリケーション・ファイアウォール・ルール・セットの有効化とインストール

Fusion Middleware ControlまたはWLSTのいずれかを使用して、Webアプリケーション・ファイアウォールのルール・セットを有効化およびインストールできます。


注意:


Fusion Middleware Controlを使用したWebアプリケーション・ファイアウォールのルール・セットの有効化およびインストール

Fusion Middleware Controlを使用して仮想サーバーにWebアプリケーション・ファイアウォールを構成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. Webアプリケーション・ファイアウォールを構成する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「詳細構成」→「Webアプリケーション・ファイアウォール」を選択します

  7. 「Webアプリケーション・ファイアウォール」ページが表示されます。

    1. 「ルール・セット・ファイルのインストール」をクリックします。

      「ルール・セット・ファイルのインストール」ダイアログ・ボックスで、ルール・セット・ファイルを解凍したフォルダを参照しルール・セット・ファイルを選択するか、ルール・セット・ファイルがある場所までの完全パスを入力します。複数のルール・セット・ファイルをインストールする場合は、1度に1つずつインストールします。

      1つ以上のルール・セット・ファイルをインストールすると、「ルール・セット・パターン」フィールドに次のテキストが追加されます。

      ruleset/<virtual-server-id>/*.conf
      

      注意:

      • 構成レベルでルール・セット・ファイルをインストールすると、ルール・セット・パターンが次のように表示されます。

        ruleset/*.conf
        
      • 必要であれば、カスタム・ルール・セット・パターンを追加できます。しかし、ruleset/<virtual-server-id>ディレクトリ(仮想サーバー・レベルの場合)またはrulesetディレクトリ(構成レベルの場合)の外部にあるルール・セットは、Oracle Traffic DirectorのFusion Middleware ControlまたはWLSTを使用して表示や削除はできません。これらのルール・セットは手動で管理する必要があります。


WLSTを使用したWebアプリケーション・ファイアウォールの有効化

WLSTを使用してWebアプリケーション・ファイアウォールを有効にするには、otd_enableWebAppFirewallコマンドを実行します。

たとえば、次のコマンドを実行すると、構成fooにある仮想サーバーbarでWebアプリケーション・ファイアウォールが有効になります。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_enableWebappFirewall(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

otd_enableWebAppFirewallの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

WLSTを使用したWebアプリケーション・ファイアウォールのルール・セットのインストール

WLSTを使用してWebアプリケーション・ファイアウォールのルール・セットをインストールするには、otd_installVirtualServerWebappFirewallRulesetFileコマンドを実行します。

たとえば、次のコマンドを実行すると、構成fooにある仮想サーバーbarにWebアプリケーション・ファイアウォールのルール・セットmodsecurity_crs_20_protocol_violations.confがインストールされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['file-path'] = '/export/rulesets/baz.conf'
otd_installVirtualServerWebappFirewallRulesetFile(props)

構成レベルでWebアプリケーション・ファイアウォールのルール・セットをインストールするには、otd_installWebappFirewallRulesetFileコマンドを実行します。たとえば、次のコマンドを実行すると、構成fooにWebアプリケーション・ファイアウォールのルール・セットmodsecurity_crs_50_outbound.confがインストールされます。

props = {}
props['configuration'] = 'foo'
props['file-path'] = '/export/rulesets/baz.conf'
otd_installVirtualServerWebappFirewallRulesetFile(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

otd_installWebappFirewallRulesetFileおよびotd_installVirtualServerWebappFirewallRulesetFileの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。


注意:

otd_setConfigurationPropertiesおよびotd_setVirtualServerPropertiesコマンドを使用して、構成レベルおよび仮想サーバー・レベルのぞれぞれで、otd_deleteWebappFirewallRulesetFile/otd_deleteVirtualServerWebappFirewallRulesetFileプロパティの値を設定できます。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

10.5.3 ルール・セット・ファイルのリスト表示

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ルール・セット・ファイルのリストを表示できます。


注意:

WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したルール・セット・ファイルのリストの表示

Fusion Middleware Controlを使用してルール・セット・ファイルのリストを表示するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. ルール・セット・ファイルを表示する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「詳細構成」→「Webアプリケーション・ファイアウォール」を選択します

  7. 「Webアプリケーション・ファイアウォール」ページの「ルール・セット・ファイル」表に、インストール済のルール・セット・ファイルがリストされます。これらのファイルの内容を確認するには、クリックして個々のルール・ファイルを選択するか、「名前」チェック・ボックスを選択してすべてのルール・ファイルを選択します。

  8. 「表示」をクリックします。

    各ルール・ファイルの内容が「ルール・セット・ファイルの内容」ウィンドウに表示されます。

WLSTを使用したルール・セット・ファイルのリストの表示

CLIを使用して個々のルール・セット・ファイルの内容を表示することはできませんが、インストール済のルール・セット・ファイルのリストを表示することは可能です。ルール・セット・ファイルのリストを表示するには、otd_listVirtualServerWebappFirewallRulesetFilesコマンドを実行します。

たとえば、次のコマンドを実行すると、構成fooにある仮想サーバーbarにインストールされているWebアプリケーション・ファイアウォールのルール・セット・ファイルがリストされます。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listVirtualServerWebappFirewallRulesetFiles(props)

構成レベルでインストールされているWebアプリケーション・ファイアウォールのルール・セットのリストを表示するには、otd_listWebappFirewallRulesetFilesコマンドを実行します。たとえば、次のコマンドを実行すると、構成fooに構成レベルでインストールされているWebアプリケーション・ファイアウォールのルール・セットがリストされます。

props = {}
props['configuration'] = 'foo'
otd_listVirtualServerWebappFirewallRulesetFiles(props)

otd_getWebappFirewallPropertiesコマンドを実行すると、Webアプリケーション・ファイアウォールのプロパティを表示できます。

otd_listWebappFirewallRulesetFiles、otd_listVirtualServerWebappFirewallRulesetFilesおよびotd_getWebappFirewallPropertiesコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.5.4 ルール・セット・ファイルの削除

Fusion Middleware ControlまたはWLSTのいずれかを使用して、ルール・セット・ファイルを削除できます。


注意:

WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したルール・セット・ファイルの削除

特定の仮想サーバーのルール・セット・ファイルを削除するには、次の操作を行います。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. ルール・セット・ファイルを削除する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「詳細構成」→「Webアプリケーション・ファイアウォール」を選択します

  7. 「Webアプリケーション・ファイアウォール」ページで、個々のルール・ファイルをクリックして選択するか、「名前」チェック・ボックスを選択してすべてのルール・ファイルを選択します。

  8. 「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

    「コンソール・メッセージ」ペインに、ルール・セット・ファイルが削除されたことを確認するメッセージが表示されます。

WLSTを使用したルール・セット・ファイルの削除

特定の仮想サーバーのルール・セット・ファイルを削除するには、次の例に示すように、otd_deleteVirtualServerWebappFirewallRulesetFileコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['ruleset-file'] = 'baz.conf'
otd_deleteVirtualServerWebappFirewallRulesetFile(props)

ルール・セット・ファイルを削除するには、次の例に示すように、otd_deleteWebappFirewallRulesetFileコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['ruleset-file'] = 'baz.conf'
otd_deleteVirtualServerWebappFirewallRulesetFile(props)

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

otd_deleteWebappFirewallRulesetFileotd_deleteVirtualServerWebappFirewallRulesetFileの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。


注意:

otd_disableWebAppFirewallコマンドを使用してWebアプリケーション・ファイアウォールを無効にできます。詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

10.5.5 サポートされているWebアプリケーション・ファイアウォールのディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズ

Oracle Traffic Directorでは様々なModSecurity 2.8のディレクティブ、変数、演算子、アクション、関数、永続ストレージおよびフェーズがサポートされています。

サポートされているWebアプリケーション・ファイアウォール・ディレクティブ

Oracle Traffic Directorでは次のModSecurity 2.8ディレクティブがサポートされています。ModSecurityディレクティブの詳細およびディレクティブのリスト(サポートされていないディレクティブを含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configuration_Directivesを参照してください。

SecAction
SecArgumentSeparator
SecAuditEngine
SecAuditLog
SecAuditLog2
SecAuditLogDirMode
SecAuditLogFileMode
SecAuditLogParts
SecAuditLogRelevantStatus
SecAuditLogStorageDir
SecAuditLogType
SecComponentSignature
SecContentInjection
SecCookieFormat
SecDataDir (see note below)
SecDebugLog
SecDefaultAction
SecDebugLogLevel
SecGeoLookupDb
SecInterceptOnError
SecMarker
SecPcreMatchLimit (see note below)
SecPcreMatchLimitRecursion (see note below)
SecRequestBodyAccess
SecRequestBodyInMemoryLimit (see note below)
SecRequestBodyNoFilesLimit (see note below)
SecRequestBodyLimitAction
SecResponseBodyAccess
SecResponseBodyLimit
SecResponseBodyLimitAction (see note below)
SecResponseBodyMimeType
SecResponseBodyMimeTypesClear
SecRule
SecRuleEngine (see note below)
SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleRemoveByTag
SecRuleUpdateActionById
SecRuleUpdateTargetById
SecTmpDir
SecUnicodeMapFile (see note below)
SecUnicodeCodePage (see note below)
SecUploadDir
SecUploadFileLimit
SecUploadFileMode
SecUploadKeepFiles
SecWebAppId (see note below)
SecCollectionTimeout

注意:

  • SecWebAppIdは仮想サーバー固有のWebアプリケーション・ファイアウォール構成ファイル内で指定できます。アプリケーション・ネームスペースを特定の仮想サーバーに関連付けることができます。

  • SecRequestBodyLimitActionディレクティブを使用して、SecRequestBodyNoFilesLimitにヒットしたリクエストに対してアクションを設定できます。しかし、SecRequestBodyLimitディレクティブはOracle Traffic Directorではサポートされていないため、このディレクティブにアクションを設定することはできません。

  • Oracle Traffic DirectorではSecRequestBodyLimitディレクティブがサポートされていません。これは、ModSecurityでバッファする最大リクエスト本文サイズを構成するときに使用するディレクティブです。このディレクティブのかわりに、次のオプションを使用できます。

    オプション1: SecRequestBodyNoFilesLimitディレクティブおよびSecRequestBodyLimitActionディレクティブを使用します。例:

    SecRequestBodyNoFilesLimit 100
    SecRequestBodyLimitAction Reject
    

    オプション2: 拒否動作を設定するため、リクエストのContent-Lengthヘッダーをチェックするようにobj.confでOracle Traffic Directorを構成します。さらに、max-unchunk-size値をserver.xmlで設定できます。

    同様に、ProcessPartial動作を設定するため、server.xmlでbody-buffer-size要素に適切な制限値を設定できます。この場合、制限に収まる本文の最初の部分のみが処理され、残りの部分は通過します。

  • webapp-firewall-ruleset要素で指定された構成ファイル内でSecRuleEngineディレクティブが指定されている場合、これは無視されます。ただし、SecRuleEngineDetectionOnlyモードに設定されている場合、これは当てはまりません。

  • ヘッダーContent-Typex-www-form-urlencodedに設定されている場合、SecRequestBodyInMemoryLimitディレクティブは無視されます。

  • SecDataDirSecPcreMatchLimitSecPcreMatchLimitRecursionSecUnicodeCodePageおよびSecUnicodeMapFileディレクティブは、構成レベルでのみ使用できます。これらのディレクティブのスコープはMainであると見なされます。その他のすべてのディレクティブは仮想サーバー・レベルと構成レベルの両レベルで使用できます。これらのディレクティブのスコープはAnyであると見なされます。Mainスコープのディレクティブを仮想サーバー・レベルの構成ファイル内で指定すると、エラーがログに記録され、サーバーの起動は失敗します。


サポートされているWebアプリケーション・ファイアウォール変数

Oracle Traffic Directorでは次のModSecurity 2.8変数がサポートされています。ModSecurity変数の詳細および変数のリスト(サポートされていない変数を含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Variablesを参照してください。

ARGS
ARGS_COMBINED_SIZE
ARGS_GET
ARGS_GET_NAMES
ARGS_NAMES
ARGS_POST
ARGS_POST_NAMES
AUTH_TYPE
DURATION
ENV
FILES
FILES_COMBINED_SIZE
FILES_NAMES
FILES_SIZES
GEO
HIGHEST_SEVERITY
MATCHED_VAR
MATCHED_VARS
MATCHED_VAR_NAME
MATCHED_VARS_NAMES
MODSEC_BUILD 
MULTIPART_BOUNDARY_QUOTED
MULTIPART_BOUNDARY_WHITESPACE
MULTIPART_DATA_AFTER
MULTIPART_DATA_BEFORE
MULTIPART_FILE_LIMIT_EXCEEDED
MULTIPART_HEADER_FOLDING
MULTIPART_INVALID_QUOTING
MULTIPART_INVALID_HEADER_FOLDING
MULTIPART_LF_LINE 
MULTIPART_MISSING_SEMICOLON
MULTIPART_CRLF_LF_LINES
MULTIPART_STRICT_ERROR
MULTIPART_UNMATCHED_BOUNDARY
PERF_COMBINED
PERF_GC
PERF_LOGGING
PERF_PHASE1
PERF_PHASE2
PERF_PHASE3
PERF_PHASE4
PERF_PHASE5
PERF_SREAD
PERF_SWRITE
QUERY_STRING
REMOTE_ADDR
REMOTE_PORT
REMOTE_USER
REQBODY_ERROR
REQBODY_ERROR_MSG
REQBODY_PROCESSOR
REQBODY_PROCESSOR_ERROR
REQUEST_BASENAME
REQUEST_BODY (see note below)
REQUEST_BODY_LENGTH
REQUEST_COOKIES
REQUEST_COOKIES_NAMES
REQUEST_FILENAME
REQUEST_HEADERS (see note below)
REQUEST_HEADERS_NAMES
REQUEST_LINE
REQUEST_METHOD
REQUEST_PROTOCOL
REQUEST_URI
REQUEST_URI_RAW
RESPONSE_BODY
RESPONSE_CONTENT_LENGTH
RESPONSE_CONTENT_TYPE
RESPONSE_HEADERS
RESPONSE_HEADERS_NAMES
RESPONSE_PROTOCOL
RESPONSE_STATUS
RULE
SERVER_ADDR
SERVER_NAME
SERVER_PORT
SESSIONID
TIME
TIME_DAY
TIME_EPOCH
TIME_HOUR
TIME_MIN
TIME_MON
TIME_SEC
TIME_WDAY
TIME_YEAR
TX
UNIQUE_ID
URL_ENCODED_ERROR
USERID
WEBAPPID
WEBSERVER_ERROR_LOG (see note below)
XML

注意:

  • rawリクエストの本文を格納するREQUEST_BODY変数には、その他のフィルタを通過した使用可能本文コンテンツが格納されます。

  • オープン・ソースのModSecurityでは、各リクエスト/レスポンスのapacheエラー・ログを収集してWEBSERVER_ERROR_LOG変数に格納し、auditlogアクションで出力できます。しかし、Oracle Traffic Directorではこの機能はサポートされていません。

  • 同じ名前のリクエスト・ヘッダーは1つに連結されるため、ヘッダー数は常に1となります。そのため、同じリクエスト・ヘッダーが送信された場合、その数に関係なく&REQUEST_HEADERS:<any header name>で常に1が返されます。


サポートされているWebアプリケーション・ファイアウォール演算子

Oracle Traffic Directorでは次のModSecurity 2.8演算子がサポートされています。ModSecurity演算子の詳細および演算子のリスト(サポートされていない演算子を含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Operatorsを参照してください。

beginsWith
contains
containsWord
endsWith
eq
ge
geoLookup
gt
inspectFile
ipMatch
le
lt
pm
pmf
pmFromFile
rbl (see note below)
rx
streq
strmatch
validateByteRange
validateDTD
validateSchema
validateUrlEncoding
validateUtf8Encoding
verifyCC
verifyCPF
verifySSN
within

注意:

ModSecurity 2.8ではSecHttpBlKeyディレクティブがサポートされません。そのため、RBLとしてProject Honey Pot (dnsbl.httpbl.cong)を使用することはできません(SecHttpBlKeyが必要になるため)。

サポートされているWebアプリケーション・ファイアウォール・アクション

Oracle Traffic Directorでは次のModSecurity 2.8アクションがサポートされています。ModSecurityアクションの詳細およびアクションのリスト(サポートされていないアクションを含む)は、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Actionsを参照してください。

allow
append
auditlog (see note below)
block
capture
chain
ctl
deny (see note below)
deprecatevar
drop (see note below)
exec
expirevar
id
initcol
log
logdata
msg
multiMatch
noauditlog
nolog
pass
pause
phase
prepend
redirect
rev
sanitiseArg
sanitiseMatched
sanitiseMatchedBytes
sanitiseRequestHeader
sanitiseResponseHeader
severity
setuid
setsid
setenv
setvar
skip
skipAfter
status
t
tag
xmlns

注意:

  • オープン・ソースのModSecurityでは、各リクエスト/レスポンスのapacheエラー・ログを収集してWEBSERVER_ERROR_LOG変数に格納し、auditlogアクションで出力できます。しかし、Oracle Traffic Directorではこの機能はサポートされていません。

  • denyなど、HTTPレスポンスのステータスを変更するアクションは、フェーズ4で呼び出された場合にレスポンス・ステータスを正しく変更しません。このようなシナリオでは、次のエラー・メッセージがサーバー・ログに記録されます。

    " ModSecurity: Access denied with code 403 (phase 4)."
    
  • dropアクションがフェーズ4で呼び出された場合、Oracle Traffic DirectorがHTTPヘッダーをクライアントに送出し、接続を切断します。

  • denyアクションがフェーズ4で呼び出された場合、Oracle Traffic Directorは403レスポンス・ステータスを送信するかわりに、レスポンス本文を取り除きます。これにより、サーバー・ログに次の警告が表示される可能性があります。

    Response content length mismatch (0 bytes with a content length of <original content length>)
    

サポートされているWebアプリケーション・ファイアウォール変換関数

Oracle Traffic Directorでは次のModSecurity 2.8変換関数がサポートされています。ModSecurity変換関数の詳細およびすべての変換関数のリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Transformation_functionsを参照してください。

base64Decode
sqlHexDecode
base64DecodeExt
base64Encode
cmdLine
compressWhitespace
cssDecode
escapeSeqDecode
hexDecode
hexEncode
htmlEntityDecode
jsDecode
length
lowercase
none
normalisePath
normalisePathWin
parityEven7bit
parityOdd7bit
parityZero7bit
removeNulls
removeWhitespace
replaceComments
removeCommentsChar
removeComments
replaceNulls
urlDecode
urlDecodeUni
urlEncode
sha1
trimLeft
trimRight
trim

サポートされているWebアプリケーション・ファイアウォール永続ストレージ

Oracle Traffic Directorでは次のModSecurity 2.8永続ストレージがサポートされています。ModSecurity永続ストレージの詳細およびすべての永続ストレージのリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Persistant_Storageを参照してください。

GLOBAL
IP
RESOURCE
SESSION
USER

サポートされているWebアプリケーション・ファイアウォール・フェーズ

Oracle Traffic Directorでは次のModSecurity 2.8フェーズがサポートされています。ModSecurityフェーズの詳細およびすべてのフェーズのリストは、https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Processing_Phasesを参照してください。

Phase:1 - Request headers stage
Phase:2 - Request body stage
Phase:3 - Response headers stage
Phase:4 - Response body stage
Phase:5 - Logging

注意:

  • denyなど、HTTPレスポンスのステータスを変更するアクションは、フェーズ4で呼び出された場合にレスポンス・ステータスを正しく変更しません。

  • dropアクションがフェーズ4で呼び出された場合、Oracle Traffic DirectorがHTTPヘッダーをクライアントに送出し、接続を切断します。

  • denyアクションがフェーズ4で呼び出された場合、Oracle Traffic Directorは403レスポンス・ステータスを送信するかわりに、レスポンス本文を取り除きます。これにより、サーバー・ログに次の警告が表示される可能性があります。

    Response content length mismatch (0 bytes with a content length of <original content length>)
    

10.6 クライアント認証の構成

クライアント認証とは、クライアントによって提供される証明書に基づいて行われる、Oracle Traffic Director仮想サーバーまたはTCPプロキシによるクライアントの検証です。

クライアント認証は、デフォルトでは有効化されません。Fusion Middleware ControlまたはWLSTのいずれかを使用して、クライアントに証明書の提供を要求するようにOracle Traffic Directorリスナーを構成できます。


注意:

WLSTの起動の詳細は、1.7.1項「WebLogic Scripting Toolへのアクセス」を参照してください。

Fusion Middleware Controlを使用したクライアント認証の構成

Fusion Middleware Controlを使用してリスナーのクライアント認証を有効にするには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. リスナーのクライアント認証を有効にする構成を指定します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「管理」→「仮想サーバー」を選択します。

    「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

  7. 構成する仮想サーバーの名前を選択します。

  8. 「設定」→「詳細設定」→「SSL/TLS設定」を選択します。

  9. 必要な「SSL/TLSクライアント認証」モードを選択します。

    • 必須: サーバーがクライアントに証明書を要求し、クライアントが証明書を提供しない場合、接続はクローズされます。

    • オプション: サーバーはクライアントに証明書を要求しますが必須ではありません。クライアントが証明書を提供しなくても、接続は確立されます。

    • 無効 (デフォルト): クライアント認証は無効化されます。

  10. 「認証タイムアウト」および「最大認証データ」パラメータを指定します。

    画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

    フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。

    「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。

  11. 必要な変更を行った後、「適用」をクリックします。

    • 更新されたリスナーが保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

WLSTを使用したクライアント認証の構成

HTTPまたはTCPリスナー用のクライアント認証を有効にするには、仮想サーバーに対してotd_setVirtualServerSslPropertiesコマンドを実行します。

props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['client-auth'] = 'false'
otd_setVirtualServerSslProperties(props)

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

10.7 サービス拒否攻撃の防止

サービス拒否(DoS)攻撃とは、悪意のあるユーザーがリクエストをサーバーに連続して送信することで、正当なユーザーによるサービスへのアクセスを妨害することを指します。

DoS攻撃を回避するために、リクエストの頻度または同時接続数が指定された制限を超えた場合、リクエストを拒否するようにOracle Traffic Director仮想サーバーを構成できます。より細かくリクエストを制御するには、リクエスト制限を定義し、各制限を、指定したURLパターンや問合せ文字列パターンに一致するリクエスト、および指定した値に一致するリクエスト・ヘッダーなどに適用できます。

この項には次のサブセクションが含まれます:

10.7.1 リクエスト制限のパラメータ

仮想サーバーに複数のリクエスト制限を指定できます。各リクエスト制限について、いくつかのパラメータを構成できます。

  • 各リクエスト制限は、次のような式を使用して指定した特定の条件を満たすリクエストに適用するように設定できます。

    $path = "*.jsp"
    $url = "/images/*"
    $ip =~ "^130\.35\.46\..*"
    

    変数または変数の組合せを使用して、制限の条件を指定できます。リクエスト制限の条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』の変数、式および文字列の補間の使用に関する項を参照してください。

  • 各リクエスト制限に対して、同時リクエスト数(max-connections)および1秒当たりの平均リクエスト数(max-rps)を指定できます。

    たとえば、制限を指定すると(max-rps=20など)、Oracle Traffic Directorは、指定された計算間隔(デフォルト: 30秒)で受信したリクエスト数に基づき、その間隔でリクエスト・レートを繰返し計算することでリクエスト・レートを継続的に追跡します。指定したリクエスト制限に達した場合、Oracle Traffic Directorによって後続のリクエストはすべて拒否されます。

  • リクエスト制限を適用する場合、Oracle Traffic Directorが監視するオプション属性も指定できます。Oracle Traffic Directorは、個別のカウンタを使用して、各監視対象属性のリクエスト統計を追跡します。

    たとえば、Oracle Traffic DirectorでクライアントIPごとにリクエストを個別に追跡するには、変数$ipを監視属性として指定できます。リクエスト・レートがクライアントで指定された制限を超えると、そのクライアントからの後続のリクエストは拒否されますが、その他のクライアントからのリクエストは引き続き処理されます。

    また、監視する属性を指定する際は、変数を組み合せることもできます。たとえば、同じURIをリクエストする頻度が高すぎるクライアントからのリクエストを制限するには、$ip:$uriを監視対象の属性として指定できます。1つのURIに対するクライアントからのリクエスト・レートが制限を超えた場合、その後のそのクライアントからのそのURIへのリクエストは拒否されますが、そのクライアントから別のURIへのリクエスト、およびその他のクライアントから任意のURIへのリクエストは引き続き処理されます。

  • Oracle Traffic Directorによって拒否されたリクエストについては、指定したHTTPレスポンス・コードが返されます。デフォルトのステータス・コードは、503 (service unavailable)です。

  • 指定された制限(max-connectionsまたはmax-rps)に到達した後、Oracle Traffic Directorでは、指定された続行条件が満たされるまで、後続のリクエストはすべて拒否され続けます。次の続行条件のいずれかを指定できます。

    • しきい値(デフォルト): 指定された制限をリクエスト・レートが下回ったら、サービスは再開されます。

    • サイレンス: 受信するリクエスト数が間隔全体でゼロになると、サービスが再開されます。

10.7.2 仮想サーバーのリクエスト制限の構成

Fusion Middleware ControlまたはWLSTのいずれかを使用して、仮想サーバーのリクエスト制限を構成できます。


注意:


Fusion Middleware Controlを使用したリクエスト制限の構成

Fusion Middleware Controlを使用してリクエスト制限を構成するには、次を実行します。

  1. 1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。

  2. ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。

  3. 「管理」→「OTD構成」を選択します。

    使用可能な構成のリストが表示されます。

  4. リクエスト制限を構成する構成を選択します。

  5. 「共通タスク」ペインの「Traffic Director構成」をクリックします。

  6. 「管理」→「仮想サーバー」を選択します。

    「仮想サーバー」ページが表示されます。構成に定義された仮想サーバー・リストが表示されます。

  7. ナビゲーション・ペインで、「仮想サーバー」を展開し、リクエスト制限を構成する仮想サーバーの名前を展開して、「リクエスト制限」を選択します。

    「リクエスト制限」ページが表示されます。仮想サーバーに現在定義されているリクエスト制限がリストされます。

    リクエスト制限の作成

    1. 「新規リクエスト制限」をクリックします。

      「新規リクエスト制限」ダイアログ・ボックスが表示されます。

      「名前」フィールドで、新しいリクエスト制限の名前を入力します。

      「接続」フィールドに、仮想サーバーへの最大同時接続数を指定します。

      「リクエスト数/秒」フィールドに、仮想サーバーが1秒当たりで受入れ可能な最大リクエスト数を指定します。


      注意:

      少なくともいずれかの制限(最大接続数または1秒当たりの最大リクエスト数)を指定する必要があります。

      「監視属性」フィールドに、仮想サーバーがリクエスト制限を適用するために監視する必要があるリクエスト・ヘッダーの属性を指定します。このパラメータを指定しない場合、リクエスト制限はすべてのリクエストに適用されます。

      「適用先」フィールドでデフォルトの1つを選択すると、そのリクエスト制限がすべてのリクエストに適用されます。

    2. 「OK」をクリックすると、新しい「リクエスト制限の作成」が作成されます。

      作成したリクエスト制限が「リクエスト制限」ページに表示されます。

    リクエスト制限の編集

    リクエスト制限の設定を変更するには、次の操作を行います。

    1. リクエスト制限の「名前」をクリックします。

      「編集中のリクエスト制限」ページが表示されます。


      注意:

      条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。

    2. 変更するパラメータを指定します。

      リクエスト制限を編集する際、リクエスト制限の作成時に指定したパラメータの変更に加えて、requests-per-second計算間隔、および指定した制限に到達したときに拒否されるリクエストについて仮想サーバーが返すHTTPステータス・コードを設定および変更できます。「編集」をクリックすると設定済の条件を編集できるため、条件を手動でまたは条件ビルダーを使用して編集できます。古い式を削除したり、新しい式を作成できます。

      画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

      フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

      「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

    3. 必要な変更を行った後、「保存」をクリックします。

      更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

    リクエスト制限の削除

    リクエスト制限を削除するには、「削除」ボタンをクリックします。確認プロンプトで、「OK」です。

WLSTを使用したリクエスト制限の構成

  • リクエスト制限を作成するには、otd_createRequestLimitコマンドを実行します。

    :

    • 次のコマンドでは、構成fooの仮想サーバーbar内にrequest-limit-1という名前のリクエスト制限が作成されます。

      props = {}
      props['configuration'] = 'foo'
      props['virtual-server'] = 'bar'
      props['request-limit'] = 'request-limit-1'
      props['max-connections'] = '2048'
      otd_createRequestLimit(props)
      

    --conditionオプションの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、『Oracle Traffic Director構成ファイル・リファレンス』 の変数、式および文字列の補間の使用に関する項を参照してください。

  • 仮想サーバーに定義されているリクエスト制限のリストを表示するには、次の例に示すように、otd_listRequestLimitsコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    otd_listRequestLimits(props)
    
  • リクエスト制限のプロパティを表示するには、次の例に示すように、otd_getRequestLimitPropertiesコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    props['request-limit'] = 'request-limit-1'
    props['event-notification-interval'] = '60'
    otd_getRequestLimitProperties(props)
    
  • リクエスト制限のプロパティを変更するには、otd_setRequestLimitPropertiesコマンドを実行します。

    たとえば、次のコマンドでは、構成fooの仮想サーバーbar内のリクエスト制限request-limit-1における1秒当たりのリクエスト数の計算間隔が変更されます。

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    props['request-limit'] = 'request-limit-1'
    props['max-connections'] = '1024'
    otd_setRequestLimitProperties(props)
    
  • リクエスト制限を削除するには、次の例に示すように、otd_deleteRequestLimitコマンドを実行します。

    props = {}
    props['configuration'] = 'foo'
    props['virtual-server'] = 'bar'
    props['request-limit'] = 'request-limit-1'
    otd_deleteRequestLimit(props)
    

更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。

この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。

10.8 OTDのSSLパススルーの構成

Oracle Traffic Director (OTD)は、Oracleエンジニアド・システム用のソフトウェア・ベースのアプリケーション配信コントローラであり、SOA、ATG (E-Commerce)、PeopleSoft、E-Business SuiteなどのOracle Fusion MiddlewareおよびBusiness Applicationデプロイメントのフロントエンドとして、SSLの終端、ロード・バランシング、制限、受信リクエスト調整といった機能を備えています。

Oracle Traffic Director (OTD)の主要機能には次のものがあります。

  • 高度なロード・バランシング・アルゴリズム、およびHTTPヘッダーまたはHTTPエンティティ・データのいずれかに基づくトラフィック管理機能を備えた本格的なレイヤー7ソフトウェア・ロード・バランサ。

  • WebLogic RMI t3、LDAPプロトコルなどのTCPトラフィックのフロントエンドとなる、レイヤー5(単一接続-TCP)のロード・バランサ。

  • SQLインジェクション、コマンド・インジェクション脆弱性などの一般的なセキュリティ脆弱性からバックエンド・アプリケーションを保護するModSecurityのベースのWebアプリケーション・ファイアウォール(WAF)機能。

  • ロード・バランサ層内の高可用性(アクティブ-パッシブ/アクティブ-アクティブ)フェイルオーバー機能。

さらに、OTDでは、スループット向上のため、HTTP(S)/SSLリクエストを処理しながら、SSL暗号の処理を基礎となるIntelプロセッサへオフロードする機能が提供されています。とはいえ、本番システムでは、顧客は外部のハードウェア・ロード・バランサでSSLを終端します。このドキュメントでは、このユースケースを処理するために必要な構成手順のリストを見ていきます。

10.8.1 外部(ハードウェア)ロード・バランサからのパス・スルーSSL情報のためのOTDの構成

(次に示すような)標準的な本番デプロイメント・トポロジでは、顧客は、(外部の)ハードウェア・ロード・バランサ内でSSLを終端し、内部のロード・バランサ(リバース・プロキシ)およびアプリケーション層内ではHTTP通信のみを扱います。

screen1.jpgの説明が続きます
「screen1.jpg」の説明

このシナリオでは、顧客は、すべてのリクエストのリダイレクトが正しく行われるように、アプリケーション層のみでなく内部のロード・バランサ/リバース・プロキシ・ソリューションでも、いくつかの追加手順を実行する必要があります。この項では、内部のロード・バランサ(OTD)/リバース・プロキシ・ソリューション内で必要となる手順を中心に説明します。

  1. OTDに追加ヘッダーを送信するためのハードウェア・ロード・バランサの構成

    • OTD内でSSLを終端する場合、OTDに「WL-Proxy-SSL:true」ヘッダーを送信するように、ハードウェア・ロード・バランサを構成する必要があります。詳細は、「OTDに特定のヘッダーを送信するためのF5-BigIPの構成」を参照してください。

    • ハードウェア・ロード・バランサ内でSSLを終端し、Oracle Access Manager (OAM/IDM)のフロントエンドとしてOTD/OHSも使用する場合は、受信リクエストのヘッダーに「IS_SSL:ssl」ヘッダーを追加して挿入するようにハードウェア・ロード・バランサを構成する必要があります。この手順は、「OTDに特定のヘッダーを送信するためのF5-BigIPの構成」で説明するWL-Proxy-SSLヘッダーの挿入に似ています。

  2. WebLogic Serverの内のWLSプラグイン有効化の構成設定を有効にします。

    • オリジン・サーバーで、WebLogic Serverも、その基礎となるWebLogic Serverコンテナも使用していない場合は、この手順をスキップできます。

    • 詳細は、「Web層/Traffic DirectorからSSL情報を受信するためのWebLogicの構成」を参照してください。

  3. パス・スルーSSLのためのOTD 11gの構成(管理コンソールのUIを使用):

    • 適切な資格証明を使用してOTDの管理コンソールにログインします。

    • 「仮想サーバー」を展開して、対応するかまたは関連する「ルート」画面を選択します。

    • ルートを更新して(「仮想サーバー」→「ルート」→「デフォルト」→「詳細」)、OTDによる「Location」または「Content-Location」ヘッダーの書き換えを無効にします。これは、外部のロード・バランサでSSLが終端されている場合に重要です。

    • 「Rewrite-headers」を空に変更します。

    • ルートの「詳細設定」の下で、(次に示すように)オリジン・サーバーに送信されるすべてのSSL関連ヘッダーの選択を解除して保存し、この構成をデプロイします。

    • 変更を保存して、「変更のデプロイ」ボタンをクリックします。

前述の手順の最後で、Oracle Traffic Directorによりヘッダーが書き換えられることはなくなり(通常これは、アプリケーション層が別の場所にリクエストをリダイレクトするときに発生します)、受信リクエスト内の受信リクエスト・ヘッダーを介して、外部のハードウェア・ロード・バランサが提供するSSL情報のパス・スルーが可能になります。

10.8.2 Web層/Traffic DirectorからSSL情報を受信するためのWebLogicの構成

WebLogicアプリケーション・サーバーのフロントエンドとして、WebLogic Proxy Plug-In、Oracle HTTP ServerなどのOracleのWeb層ソリューションまたはOracle Traffic Directorを使用する場合は、WebLogicコンソールで明示的に「WebLogicプラグインの有効化」の設定をオンにする必要があります。このフラグは、特定のWebLogic管理対象サーバー内またはWebLogicクラスタ・レベルのいずれかでオンにできます。このフラグは、WebLogicクラスタ・レベルでオンにすることをお薦めします。

これにより、Traffic Director/Web層内でSSLが終端されている場合に、WebLogicで適切にヘッダーを書き込むことができます。

http://<wls-admin-hostname>:7001/consoleを開き、WebLogicのユーザー/パスワードでログインします。

(Weblogicクラスタを有効にしている場合は、クラスタ・レベルでこれを行うことをお薦めします)。

(Weblogicクラスタを有効にしていない場合は、WLS管理対象サーバー内でこの設定を有効にできます)。「構成」→「一般」の設定タブ内で、「詳細設定」を展開してスクロール・ダウンし、「WebLogicプラグインの有効化」で「はい」を選択し、「保存」をクリックします。

10.8.3 OTDに特定のヘッダーを送信するためのF5-BigIPの構成

Oracle Traffic Directorでは、基礎となるハードウェア・プロセッサを利用して暗号処理をオフロードでき、一般的なリバース・プロキシ・ソリューションと比較して全体的に優れたSSL性能を実現します。

F5-BigIpなどのハードウェア・ロード・バランサ内でのSSLの終端を選択する場合は、OTDおよびWLSに対して明示的に特定のヘッダー「WL-Proxy-SSL」を送信するように、このハードウェア・ロード・バランサを構成する必要があります。

次の手順では、このヘッダーを送信するようにF5-BigIpを構成する方法を説明します(情報源: F5 Big IP製品のドキュメント)。

SSL用の新規HTTPプロファイルを作成するには:

  1. 「Main」タブで「Local Traffic」を展開して、「Profiles」をクリックします。「HTTP Profiles」画面が開きます。

  2. 画面の右上部で、「Create」ボタンをクリックします。「New HTTP Profile」画面が開きます。

  3. 「Name」ボックスに、このプロファイルの名前を入力します。この例では、bea-sslと入力します。

  4. WebAcceleratorを使用している場合は、「Parent Profile」リストから「http-acceleration」を選択します。WebAcceleratorを使用していない場合は、「http-wan-optimized-compression-caching」を選択します。

  5. 「Request Header Insert」行で、「Custom」ボックスを選択します。このボックスに、WL-Proxy-SSL:trueと入力します。

  6. 「Redirect Rewrite」行で、「Custom」ボックスを選択します。「Redirect Rewrite」リストから「Match」を選択します。

  7. ご自身のネットワークに応じて、その他の設定を変更します。この例では、設定はデフォルトのままにします。

  8. 「終了」ボタンをクリックします。