ルールの設定

Secure Web Proxy では、アウトバウンド ウェブ トラフィックを保護するために、ポリシー内でさまざまなタイプのルールを定義できます。これらのルールを使用すると、ヘッダーや URL パターンなどの特定のリクエストの詳細を使用してトラフィックのセキュリティを正確に制御し、承認された HTTP/S トラフィックのみがネットワークから送信されるようにできます。

このページでは、さまざまな種類のルールと、それらを作成してセキュリティ ポリシーに追加する手順について説明します。

ホスト一致ルールを構成する

ホスト一致ルールは、ウェブ リクエストの宛先ホスト名を許可または拒否されたURL リストと照合します。これらのルールは、www.example.com などの宛先ドメインを確認することで、トラフィックが承認済みのウェブサイトとサービスにのみ到達するようにします。

このセクションでは、次の Secure Web Proxy デプロイモードのホスト一致ルールを構成する方法について説明します。

• 明示的プロキシモード
• ネクストホップ モード

明示的プロキシモード

Secure Web Proxy を明示的なプロキシとしてデプロイする場合は、クライアントから送信されたホスト情報が正しく抽出され、定義されたセキュリティ ルールと照合されることを確認するようにホスト照合ルールを構成します。明示的なプロキシ モードでは、クライアントはトラフィックを Secure Web Proxy インスタンスに直接送信するように積極的に構成されます。

明示的プロキシ モードでのホスト照合は、次のようにさまざまな種類のウェブ トラフィックに対して機能します。

トラフィックの種類	マッチング メカニズム	ルールの設定
暗号化されていない HTTP	Secure Web Proxy は、HTTP リクエストの標準 CONNECT ヘッダーの host フィールドと宛先ホスト名を照合します。	sessionMatcher フィールドで、host() == "example.com" を使用します。
暗号化された HTTPS（Transport Layer Security（TLS）インスペクションなし）	ホスト マッチングは、アプリケーション レベルでもセッション レベルでもできません。これは、リクエストの詳細が暗号化され、destination.ip 属性がサポートされていないためです。ソース ID の照合などの広範なポリシー制御を使用するか、ホストベースのフィルタリングで TLS インスペクションを有効にする必要があります。	アプリケーション マッチャーを使用するには、サービス アカウントなどのソース ID の照合を使用するか、TLS インスペクションを有効にします。
暗号化された HTTPS（TLS インスペクションあり）	リクエスト全体を検査するには、セッション マッチャーとアプリケーション マッチャーの両方を使用する必要があります。	1. true を返すか、host() == "example.com" などの宛先ホストと一致する一般的なセッション マッチャー ルールを設定します。 2. applicationMatcher フィールドに、request.host() == "example.com" などの特定のホストルールを追加します。

ネクストホップ モード

Secure Web Proxy をネクストホップとしてデプロイする場合は、ホスト一致ルールを構成する必要があります。トラフィックは、定義した IP アドレス範囲に基づいて Virtual Private Cloud（VPC）ルートを介してプロキシにリダイレクトされます。ホスト照合ルールにより、プロキシは、Server Name Indication（SNI）ヘッダーなどのトラフィックのさまざまなフィールドをチェックして、宛先ホストを正しく識別します。

ネクストホップ モードでのホスト照合は、次の方法でさまざまなタイプのウェブ トラフィックに対して機能します。

トラフィックの種類	マッチング メカニズム	ルールの設定
暗号化されていない HTTP	Secure Web Proxy は、宛先ホスト名を標準の HTTP リクエスト ヘッダーの host フィールドと照合します。	sessionMatcher フィールドで、host() == "example.com" を使用します。
暗号化された HTTPS（TLS 検査なし）	Secure Web Proxy は、アウトバウンド リクエストの SNI ヘッダーに対してホスト名をチェックします。このヘッダーは、トラフィックの残りの部分が暗号化されていても確認できます。	sessionMatcher フィールドで、host() == "example.com" を使用します。
暗号化された HTTPS（TLS インスペクションあり）	リクエスト全体を検査するには、セッション マッチャーとアプリケーション マッチャーの両方を使用する必要があります。	1. true を返すか、host() == "example.com" などの宛先ホストと一致する一般的なセッション マッチャー ルールを設定します。 2. applicationMatcher フィールドに、request.host() == "example.com" などの特定のホストルールを追加します。

TCP プロキシルールを構成する

アプリケーションの Transmission Control Protocol（TCP）プロキシルールを構成して、非ウェブ トラフィックを保護し、標準の HTTP/S を使用しないアプリケーション（ポート 80 や 443 など）にセキュリティ ポリシーを適用できます。

これらのルールを適用すると、データ転送や悪意のあるアクティビティに他の TCP ポートが不正使用されるのを防ぐことができます。これは、ワークロードがウェブ以外のプロトコルで Secure Web Proxy をネクストホップとして使用する場合に特に便利です。

TCP プロキシルールを実装し、アプリケーションのトラフィックを許可またはブロックするルールを作成するには、宛先ポートを指定する必要があります。必要に応じて、次のセッション マッチャー属性を含めて、許可ルールまたはブロックルールの条件を絞り込むことができます。

次の表に、TCP プロキシルールで使用できるさまざまな属性の詳細を示します。

属性	属性タイプ	説明
source.ip	文字列	リクエストを送信したクライアントの IP アドレス。
source.port	文字列	リクエストを送信したクライアント ポート。
destination.port	文字列	Secure Web Proxy インスタンスがトラフィックを送信するアップストリーム ポート。
source.matchTag(SECURE_TAG)	ブール値	ソースが SECURE_TAG に関連付けられている場合は、True。 引数は、セキュアタグの永続的な ID です（source.matchTag('tagValues/123456') など）。
source.matchServiceAccount(SERVICE_ACCOUNT)	ブール値	ソースが SERVICE_ACCOUNT（source.matchServiceAccount('[e-mail]') など）に関連付けられている場合は、True。
inIpRange(IP_ADDRESS, IP_RANGE)	ブール値	IP_ADDRESS が IP_RANGE に含まれている場合（inIpRange(source.ip, '1.2.3.0/24') など）は True。IPv6 アドレスのサブネット マスクは `/64` 以下にする必要があります。

TCP プロキシルールの例

この例では、CEL 式を使用して Secure Web Proxy gatewaySecurityPolicyRule を定義し、ポート 22 へのすべての TCP トラフィックを許可する方法を示します。この構成は、Secure Web Proxy の TCP プロキシ機能を適用するときに使用できます。

次のコードサンプルは、TCP プロキシルールを定義する方法を示しています。

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

次のように置き換えます。

• PROJECT_ID: プロジェクトの ID
• REGION: ポリシーのリージョン
• POLICY_NAME: ポリシーの名前
• RULE_NAME: TCP プロキシルールの名前。この例では、その値を allow-ssh-tcp-proxy と見なすことができます。

重要な考慮事項

• 構成する TCP プロキシルールは、HTTP/S ルールよりも優先度を高く（数値を小さく）する必要があります。これにより、TCP プロキシルールが最初に評価され、処理されます。詳細については、ルールの評価順序をご覧ください。

• TCP プロキシルールを構成する場合、TCP レイヤでホスト情報を使用できないため、host セッション マッチャー属性はサポートされていません。

• TCP プロキシルールは、宛先ポートのみに基づいてウェブ トラフィックをフィルタします。ネットワークのセキュリティを強化するには、論理演算子（論理 AND 演算子（&&）と論理 OR 演算子（||））と、source.ip などのサポートされている属性を使用して、他の条件を追加することをおすすめします。より具体的な TCP プロキシルールを定義する例を次に示します。

    // Allow port 22 from only a specific source IP range
    sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
  

• Secure Web Proxy は、User Datagram Protocol（UDP）アプリケーションのプロキシルールを構成する機能をサポートしていません。その結果、Secure Web Proxy は UDP ベースのアプリケーションのトラフィックをブロックします。

Secure Web Proxy ルールを作成する

このセクションでは、Secure Web Proxy ルールを作成する方法について説明します。

ルールを作成する前に、次の操作を行ってください。

1. 初期設定の手順をすべて完了します。

2. ポリシーを作成する

ルールを作成してポリシーに関連付けたら、Secure Web Proxy のデプロイ時にルールを使用できます。

コンソール

1. Google Cloud コンソールで、[SWP ポリシー] ページに移動します。

   SWP ポリシーに移動

2. ポリシーの名前（policy1 など）をクリックします。

3. [ルールを追加] をクリックします。

4. ルールごとに、次の操作を行います。

   1. [優先度] に、ルールの数値評価順序を入力します。ルールは、最も高い優先度から順番に評価されます（最も高い優先度は 0）。

   2. [名前] フィールドに、ルールの名前を入力します。

   3. [説明] フィールドに、ルールの説明を入力します。

   4. [アクション] で、次のいずれかのオプションを選択します。

      • 許可: ルールに一致する接続リクエストを許可します。
      • 拒否: ルールに一致する接続リクエストを拒否します。

   5. [ステータス] フィールドで、ルールの適用について次のいずれかのオプションを選択します。

      • 有効: Secure Web Proxy インスタンスにルールを適用します。
      • 無効: Secure Web Proxy インスタンスにルールを適用しない場合。

   6. [セッションの一致] セクションで、host() == "www.wikipedia.org" などのセッションの一致条件を指定します。

      SessionMatcher の構文の詳細については、CEL マッチャーの言語リファレンスをご覧ください。

   7. [アプリケーションの一致] セクションで、リクエストの一致条件を指定します。

      TCP トラフィックのマッチングの詳細については、TCP プロキシルールを構成するをご覧ください。

   8. [ルールを追加] をクリックします。

重要: TLS インスペクションを含むルールを作成するには、TLS インスペクションを有効にするをご覧ください。

Cloud Shell

1. ここに示すように、rule.yaml ファイルを作成します。sessionMatcher の構文の詳細については、CEL マッチャーの言語リファレンスをご覧ください。

   name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
   description: Allow wikipedia.org
   enabled: true
   priority: 1
   basicProfile: ALLOW
   sessionMatcher: host() == 'www.wikipedia.org'
   

   次のように置き換えます。

   • PROJECT_ID: プロジェクトの ID
   • REGION: ポリシーのリージョン
   • RULE_NAME: ルールの名前。この例では、その値を allow-wikipedia-org と見なすことができます。

2. 省略可: TLS インスペクションが有効になっているルールを作成する場合は、次のように rule.yaml ファイルを作成します。詳細については、TLS インスペクションの概要と TLS インスペクションを有効にするをご覧ください。

     name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
     description: Allow wikipedia.org
     enabled: true
     priority: 1
     basicProfile: ALLOW
     sessionMatcher: host() == 'www.wikipedia.org'
     applicationMatcher: request.path.contains('index.html')
     tlsInspectionEnabled: true
   

   TCP トラフィックのマッチングの詳細については、TCP プロキシルールを構成するをご覧ください。

   重要: 作成するすべてのルールで TLS インスペクションを有効にするには、applicationMatcher を使用して HTTPS トラフィックを照合する各ルールで tlsInspectionEnabled 属性を true に設定します。ルールの TLS インスペクションは、ルールの sessionMatcher 属性に一致するトラフィックに限定されます。詳細については、TLS インスペクション ルールの評価をご覧ください。

3. セキュリティ ポリシー ルールを作成します。

   gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
       --source=rule.yaml \
       --location=REGION \
       --gateway-security-policy=policy1
   

次のステップ

• Secure Web Proxy インスタンスを作成する
• Private Service Connect サービスとして Secure Web Proxy をデプロイする
• ネクストホップとして Secure Web Proxy をデプロイする