Oracle Cloud Infrastructureドキュメント

ルール・セットの管理

このトピックでは、HTTPリスナーでトラフィックに適用するアクションで構成されるルール・セットの作成方法について説明します。

ロード・バランサ・リスナーの管理の詳細は、「ロード・バランサ・リスナーの管理」を参照してください。

警告

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用してクラウド・リソースに説明、タグまたはわかりやすい名前を割り当てるときは、機密情報を入力しないでください。

必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者が作成するポリシーで、コンソールまたはSDK、CLIまたはその他のツールを使用したREST APIのどちらを使用しているかにかかわらず、必要なタイプのアクセスを付与する必要があります。 アクションを実行しようとしたときに、権限のないメッセージや権限のないメッセージを取得する場合は、管理者に付与されているアクセスのタイプと作業するコンパートメントを確認してください。

管理者向け: ロード・バランサとそのコンポーネントにアクセスできる典型的なポリシーについては、「ネットワーク管理者がロード・バランサを管理できるようにします」を参照してください。

また、inspect load-balancersを含むポリシー・ステートメントは、指定されたグループに、ロード・バランサに関するすべての情報を表示する機能を提供することに注意してください。 詳細は、「ロード・バランシングの詳細」を参照してください。

新しいポリシーの場合は、「ポリシーの開始」「共通ポリシー」を参照してください。

ルール・セットの操作

ルール・セットは、ロード・バランサに関連付けられ、そのロード・バランサの1つ以上のリスナーに適用された名前付きのルール・セットです。 ルールは、ロード・バランサ・リスナーでトラフィックに適用されるアクションを表すオブジェクトです。

次のタイプのルールをルール・セットに含めることができます:

ルール・セットはHTTPリスナーにのみ適用されます。

リスナーの編集時には、既存のルール・セットを適用できます。 同じルール・セットを同じロード・バランサの複数のリスナーに適用できます。

ルール・セットはロード・バランサ間で共有されません。 別のロード・バランサで同じルール・セットを使用するには、そのロード・バランサの下に新しい同じルール・セットを作成する必要があります。

ルール・セットには最大20個のルールを含めることができます。 最大50ルールをロード・バランサに関連付けることができます。

アクセス制御ルール

アクセス制御ルールは、ユーザー指定のIPアドレスまたはアドレス範囲の一致条件に基づいて、アプリケーション・リソースへのアクセスを許可します。 アクセス制御ルールを指定しない場合は、デフォルト・ルールによってすべてのトラフィックが許可されます。 アクセス制御ルールを追加すると、ロード・バランサはルールに一致しないトラフィックを拒否します。

サービスは、一致条件に対してクラス間ルーティング(CIDR)形式(x.x.x.x/y or x:x::x/y)文字列のみを受け入れます。

すべての着信トラフィックに一致する0.0.0.0/0または::/0を指定します。

ノート

現在IPv6の値を許可するのは、US Government Cloudリージョンのみです。

アクセス方法ルール

アクセス・メソッド・ルールは、関連するリスナーで許可されるHTTPメソッドを指定します。 ロード・バランサは、許可されていないリクエストをバックエンド・サーバーに転送せず、使用可能なメソッドのリストとともに405 Method Not Allowedレスポンスを返します。 許可されたメソッドのリストは、指定のリスナーに1つのみ関連付けることができます。

デフォルトでは、「HTTPメソッド・レジストリ」で定義されている標準HTTPメソッドのみを指定できます。 HTTPメソッドのリストは拡張可能です。 カスタムHTTPメソッドを構成する必要がある場合は、My Oracle Supportに連絡して、テナンシから制限を削除してください。 バックエンド・アプリケーションは、指定されたメソッドを処理できる必要があります。

デフォルトHTTPメソッド

URLリダイレクト・ルール

URLリダイレクト・ルールにより、受信HTTPリクエストを別の宛先URLにルーティングする方法を指定します。 URLリダイレクト・ルールはHTTPリスナーにのみ適用されます。 特定のリスナーおよび指定したパスに対して各リダイレクト・ルールを構成します。 リスナーには、特定の着信URLパスについて1つのリダイレクト・ルールのみを指定できます。

URLリダイレクト・ルールを作成する際、サービスがリダイレクト用の着信URLの評価に使用するパス文字列と一致条件を指定します。 リダイレクトURLおよびレスポンス・コードも定義します。

着信パス文字列の評価

着信URLで評価するパス文字列またはパターンを指定します。 例えば:

/video

また、リダイレクト用の着信URLを評価するときに適用する一致条件も指定します。 使用可能な一致タイプは次のとおりです:

  • FORCE_LONGEST_PREFIX_MATCH

    システムは、着信URLパスの最初の部分に最も一致するリダイレクト・ルール・パス文字列を検索します。

  • EXACT_MATCH

    着信URLパスは、指定されたパス文字列と完全に一致する必要があります。

  • PREFIX_MATCH

    着信URLパスの最初の部分が、指定したパス文字列と完全に一致している必要があります。

  • SUFFIX_MATCH

    着信URLパスの終了部分は、指定したパス文字列と完全に一致する必要があります。

リダイレクトURLの構成

リダイレクトURLは、元のリクエストに適用されるように定義します。 URLリダイレクト・ルールは、次のURLコンポーネントを認識します:

<protocol>://<host>:<port>/<path>?<query>

リテラル文字列を指定することも、任意のコンポーネントにトークンを指定することもできます。 トークンは、着信HTTPリクエストURLから値を抽出します。 トークンは大文字と小文字を区別します。 たとえば、{host}は有効なトークンですが、{HOST}は無効です。

  • プロトコル

    リダイレクトURLで使用するHTTPプロトコル。 有効な値はHTTPおよびHTTPSです。

    {protocol}トークンは、着信したHTTPリクエストURLからプロトコルを抽出します。 このプロパティで唯一有効なトークンです。

  • ホスト

    リダイレクトURLで使用する有効なドメイン名またはIPアドレス。

    {host}トークンは、着信HTTPリクエストURLからホストを抽出します。 すべてのURLリダイレクト・トークンはこのプロパティに対して有効です。 トークンは、複数回使用できます。

    {}の中カッコで囲まれた{}は、トークンを囲む場合にのみこのプロパティで有効です。

  • Port

    リダイレクトURLで使用する通信ポート。 有効な値には、1から65535までの整数が含まれます。

    {port}トークンは、着信したHTTPリクエストURLからポートを抽出します。 このプロパティで唯一有効なトークンです。

  • パス

    リダイレクトURLで使用するHTTP URLパス。 リダイレクトURLからのパスを省略する場合は、この値を空の文字列に設定します。

    {path}トークンは、着信されたHTTPリクエストURLからパス文字列を抽出します。 すべてのURLリダイレクト・トークンはこのプロパティに対して有効です。 トークンは、複数回使用できます。

    パス文字列の先頭が{path}トークンでない場合、スラッシュ/で始まる必要があります。

  • 問合せ

    リダイレクトURLで使用する問合せ文字列。 リダイレクトURLから着信する問合せパラメータをすべて省略するには、この値を空の文字列に設定します。

    {query}トークンは、着信されたHTTPリクエストURLから問合せ文字列を抽出します。 すべてのURLリダイレクト・トークンはこのプロパティに対して有効です。 トークンは、複数回使用できます。

    問合せ文字列が{query}トークンで始まらない場合、それは疑問符?で始まります。

    複数の問合せパラメータを単一の文字列として指定できます。 各問合せパラメータはアンパサンド&で区切ります。

    指定した問合せ文字列の結果が?または&で終わるリダイレクトURLの場合は、最後の文字が切り捨てられます。 たとえば、着信URLがhttp://host.com:8080/documentsで問合せプロパティの値が?lang=en&{query}の場合、リダイレクトURLはhttp://host.com:8080/documents?lang=enです。 {query}トークンを置換する値が含まれていない着信URLのため、最後のアンパサンド&が切り捨てられます。

警告

少なくとも1つのURLコンポーネント・フィールドに値を指定しないと、リダイレクト・ループが発生する可能性があります。

手動リダイレクトURLの構成

コンソールには、各URLコンポーネントのテキスト入力フィールドが用意されています。 または、リダイレクトURLを完全に手動で指定することもできます。

リダイレクトURLのパスおよび問合せプロパティに値を指定する場合は、トークンのリテラル文字を保持できます。 \{および}文字のエスケープ文字として、バックスラッシュ\を使用します。 たとえば、着信HTTPリクエストURLが/videoの場合、パス・プロパティの値/example{path}123\{path\}が、/example/video123{path}として作成されたリダイレクトURLに表示されます。

パスおよび問合せ文字列の例を次に示します:

  • /example/video/123は、リダイレクトURLの/example/video/123として表示されます。
  • /example{path}は、/video/123が着信HTTPリクエストURLのパスである場合、リダイレクトURLの/example/video/123として表示されます。
  • {path}/123は、/example/videoが着信HTTPリクエストURLのパスである場合、リダイレクトURLの/example/video/123として表示されます。
  • {path}123は、/example/videoが着信HTTPリクエストURLのパスである場合、リダイレクトURLの/example/video123として表示されます。
  • /{host}/123は、example.comが着信HTTPリクエストURLのホスト名である場合、リダイレクトURLの/example.com/123として表示されます。
  • example.comがホスト名で、123が着信HTTPリクエストURLのポートである場合、/{host}/{port}はリダイレクトURLの/example.com/123として表示されます。
  • /{query}は、着信されるHTTPリクエストURLで問合せがlang=enの場合、リダイレクトURLに/lang=enとして表示されます。
  • lang=en&time_zone=PSTは、リダイレクトURLのlang=en&time_zone=PSTとして表示されます。
  • lang=en&time_zone=PSTが着信HTTPリクエストの問合せ文字列である場合、{query}はリダイレクトURLのlang=en&time_zone=PSTとして表示されます。 着信HTTPリクエストに問合せパラメータがない場合、{query}トークンは空の文字列としてレンダリングされます。
  • country=usが着信HTTPリクエストの問合せ文字列である場合、lang=en &{query}& time_zone=PSTはリダイレクトURLのlang=en&country=us&time_zone=PSTとして表示されます。 着信HTTPリクエストに問合せパラメータがない場合、この値はlang=en&time_zone=PSTとしてレンダリングされます。
  • protocol={protocol}& hostname={host}は、プロトコルがhttpで、着信HTTPリクエストでホスト名がexample.comの場合、リダイレクトURLでprotocol=http&hostname=example.comとして表示されます。
  • port={port}& hostname={host}は、ポートが8080で、着信HTTPリクエストURLでホスト名がexample.comの場合、リダイレクトURLにport=8080&hostname=example.comとして表示されます。

レスポンス・コード

着信したリクエストがリダイレクトされたときに返すHTTPステータス・コードを指定できます。 標準HTTP仕様からのリダイレクションに有効なレスポンス・コードは次のとおりです:

  • 301 永久的に移動
  • 302 見つかりました
  • 303 他を参照してください。
  • 307 Temporary Redirect
  • 308 Permanent Redirect

デフォルト値は302 Foundです。

リクエストおよびレスポンス・ヘッダー・ルール

リクエストおよびレスポンスのヘッダー・ルールによって、HTTPリクエストまたはレスポンスのヘッダーが追加、変更または削除されます。 これらのルールは、メタデータをバックエンド・サーバーに渡して次のような操作を行うのに役立ちます:

  • どのリスナーがリクエストを送信したかを識別します。
  • SSLの終了についてバックエンド・サーバーに通知します。

ルール・セットがサイト・セキュリティの向上に役立つ例を次に示します:

  • 外部ドメインがサイトをダイアグラムできないようにするためのヘッダーの追加。
  • "Server"などのデバッグ・ヘッダーを削除すると、バックエンド・サーバーから送信されます。 このアクションは、バックエンドの実装詳細を非表示にするのに役立ちます。
  • "strict-transport-security"ヘッダーを適切な値でレスポンスに追加します。 このヘッダーは、サイトへのアクセスがHTTPSのみであることを保証するのに役立ちます。
  • 適切な値を使用したX-xss-protectionヘッダーの追加。 このヘッダーにより、最新のブラウザに組み込まれたクロスサイト・スクリプティング(XSS)保護を強制的に適用できます。
  • 適切な値を使用したx-content-typeヘッダーの追加。 このヘッダーは、コンテンツ・タイプのシフトに基づく攻撃を防止するのに役立ちます。

例: ロード・バランサがSSLを終了したことをWebLogicに通知

SSL終了を実行するようにロード・バランサを構成できます。 多くの場合、バックエンド・アプリケーションにはこのアクションの通知が必要です。 たとえば、HTTPS WebLogic e-commerceのオンライン・トランザクション処理では、リクエストがSSLに由来することを確認するために、WL-Proxy-SSLヘッダーが検索されます。 ルール・セットを使用して、ロード・バランサ・リスナーでこのヘッダーを追加できます。

ヒント

セキュリティ上の理由から、WebLogicは、WebLogic管理コンソールで「WebLogicプラグインの有効化」チェック・ボックスを選択(チェック)しないかぎり、このヘッダーを無視します。

  1. 「ルール・セットの作成」の手順に従い、次の手順を実行します:

    1. 「アクション」ドロップダウン・リストから「リクエスト・ヘッダーの追加」オプションを選択します。
    2. 「ヘッダー」名としてWL-Proxy-SSLと入力します。
    3. ヘッダーを設定します:

      • ロード・バランサがSSL終了を実行するよう構成されている場合、この値を"true"に設定します。
      • SSL終了ポイントがプラグインが動作するWebサーバー内にある場合は、この値を"false"に設定します。
  2. 「リスナーの作成」「既存のリスナーを編集」、および新しいルール・セットを追加します。

コンソールの使用

ルール・セットをリスナーに適用するには、最初にそのルールを含むルール・セットを作成します。 ルール・セットはロード・バランサ構成の一部になります。 ロード・バランサのリスナーを作成または更新するときに使用するルール・セットを指定できます。

ルール・セットを作成するには