セキュリティ ルール

このページでは、ゲートウェイ セキュリティ ルールとその作成方法について説明します。

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

**注:** Secure Web Proxy インスタンスで認可ポリシーを作成すると、プロキシは既存のゲートウェイ セキュリティ ポリシーと関連するゲートウェイ セキュリティ ルールをすべて無視します。

ゲートウェイ セキュリティ ルールには、次の機能があります。

• 各ルールは if-then ステートメントで、ウェブ リクエストを次のパラメータと照合します。

  • 送信元 ID: リクエストを行っているユーザー（特定の仮想マシン（VM）やサービス アカウントなど）。送信元 ID: リクエストを行っているユーザー（特定の仮想 マシン（VM）や サービス アカウントなど）。

  • 宛先: リクエストの送信先（trusted-partner.com などのリンク先 URL またはドメイン）。

  • アクション: トラフィックを許可するか拒否するかの決定。

• ゲートウェイ セキュリティ ルールは、きめ細かい制御を提供します。これらのルールを使用すると、明確で構造化された定義を使用して、組織全体でさまざまなセキュリティ標準を適用できます。

ホスト一致ルール

Secure Web Proxy は、ホスト名の一致を使用して宛先ドメインを確認します。確認プロセスは、次の表に示すように、プロキシのデプロイ方法によって異なります。

デプロイモード	ホスト確認プロセス
明示的なプロキシモード	暗号化されていないトラフィックの場合、プロキシはホスト名 と HTTP 接続ヘッダーを照合します。TLS インスペクションに [Application Matcher 属性](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) を使用する場合、プロキシは最初に接続レベルでホスト名を確認し、次に アプリケーション レベルで確認します。
ネクストホップ モード	暗号化されたトラフィックの場合、プロキシは宛先 ホスト名を送信リクエストの Server Name Indication（SNI）フィールドと照合します。このフィールドは、安全な接続でも表示されます。

明示的なプロキシモードのホスト一致ルールを構成する

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 インスペクションを有効にする必要があります。	Application Matcher を使用するには、サービス アカウントなどの送信元 ID の一致を使用するか、TLS インスペクションを有効にします。
暗号化された HTTPS（TLS インスペクションあり）	リクエスト全体を検査するには、 Session Matcher と Application Matcher の両方を使用する必要があります。	1. `true` を返すか、true host() == "example.com" などの宛先ホストと一致する一般的な Session Matcher ルールを設定します。 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 インスペクションあり）	リクエスト全体を検査するには、 Session Matcher と Application Matcher の両方を使用する必要があります。	1. `true` を返すか、true host() == "example.com" などの宛先ホストと一致する一般的な Session Matcher ルールを設定します。 2. applicationMatcher フィールドに、request.host() == "example.com" などの特定のホストルールを追加します。

TCP プロキシ ルール

伝送制御プロトコル（TCP）プロキシ ルールを使用すると、HTTP（ポート 80）や HTTPS（ポート 443）などの標準のウェブ トラフィック以外のトラフィックを制御できます。TCP プロキシ ルールを構成すると、他の TCP ポートのトラフィックを許可またはブロックできます。これらのルールは、悪意のあるトラフィックをブロックし、TCP を使用するウェブ以外のアプリケーションを管理するのに役立ちます。

ワークロード（アプリケーションやサービスなど）が Secure Web Proxy をネクストホップとして使用している場合は、 TCP プロキシルールを適用すると便利です。ルートベースのリダイレクトにより、HTTP(S) 以外のトラフィックとウェブ以外のトラフィックが Secure Web Proxy インスタンスに転送されます。これにより、悪意のある外部サイトに到達する下り（外向き）トラフィックをブロックし、ネットワーク ワークロードが接続できる外部サービスを管理できます。

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

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

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

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

次の表に、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]') に関連付けられている場合は 。
inIpRange(IP_ADDRESS, IP_RANGE)	ブール値	True、IP_ADDRESS が IP_RANGE などの inIpRange(source.ip, '1.2.3.0/24') に含まれている場合は True。IPv6 アドレスのサブネット マスクは `/64` 以下にしてください。

TCP プロキシ ルールの例

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

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

• 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 ベースのアプリケーションのトラフィックをブロックします。

セキュリティ ルールを作成する

ゲートウェイ セキュリティ ルールを作成する前に、次の操作を行います。

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

2. ポリシーを作成する

重要: HTTPS トラフィックのリクエスト属性を分析するには、 TLS インスペクションを有効にします。

ルールを作成してポリシーに関連付けたら、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 と見なすことができます。

   省略可: または、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 インスペクション ルールの評価をご覧ください。

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

   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 では、 User Datagram Protocol（UDP） アプリケーションのルールを構成することはできません。Secure Web Proxy は UDP ベースのアプリケーションのトラフィックをブロックします。

次のステップ

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