ルールの設定

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

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

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

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

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

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

明示的なプロキシモード

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

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

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

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

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

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

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

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

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

TCP プロキシルールの例

この例では、 gatewaySecurityPolicyRuleを使用して CEL 式により ポート 22 へのすべての TCP トラフィックを許可する Secure Web Proxy を定義する方法を示します。この構成は、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/HTTPS ルールよりも優先度が高く（数値が小さい）なるようにして、最初に評価されて処理されるようにする必要があります。詳細については、 ルールの評価順序をご覧ください。

• 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. コンソールで、[SWP ポリシー] ページに移動します。 Google Cloud

   [SWP ポリシー] に移動

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

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

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 インスペクションを有効にするには、 HTTPS トラフィックの一致に applicationMatcher を使用する各ルールで 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 インスタンスを作成する
• Secure Web Proxy を Private Service Connect サービスとしてデプロイする
• Secure Web Proxy をネクストホップとしてデプロイする