安全规则

本页面介绍了网关安全规则以及如何创建这些规则。

借助 Secure Web Proxy，您可以在网关安全政策中定义各种类型的安全规则，以保护出站 Web 流量。您可以使用这些规则，通过使用特定的请求详细信息（例如标头和网址模式）来精确控制流量的安全性，确保只有获批的 HTTP/S 流量离开您的网络。

网关安全规则具有以下功能：

  • 每条规则都是一条 if-then 语句，用于根据以下参数检查 Web 请求：

  • 网关安全规则提供精细的控制。借助这些规则，您可以使用清晰的结构化定义在整个组织内强制执行不同的安全标准。

主机匹配规则

Secure Web Proxy 使用主机名匹配来验证目标网域。验证过程因代理的部署方式而异，如下表所示。

部署模式 主机验证过程
显式代理模式 对于未加密的流量，代理会根据 HTTP 连接标头检查主机名 检查 。如果您将 [Application Matcher 属性](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) 用于 TLS 检查，则代理会先在连接级检查主机名，然后在 应用级检查主机名。
下一个跃点模式 对于加密流量，代理会根据出站请求中的服务器名称指示 (SNI) 字段检查目标 主机名。即使在安全连接上，此字段也是可见的。

为显式代理模式配置主机匹配规则

将 Secure Web Proxy 部署为显式代理时，请配置主机匹配规则，以验证客户端发送的主机信息是否已正确提取并根据您定义的安全规则进行检查。在显式代理模式下，客户端会主动配置为将其流量直接发送到 Secure Web Proxy 实例。

在显式代理模式下，主机匹配适用于不同类型的 Web 流量，方式如下：

流量类型 匹配机制 规则配置
未加密的 HTTP Secure Web Proxy 会根据 HTTP 请求的标准 CONNECT 标头中的 host 字段检查目标主机名。 在 sessionMatcher 字段中，使用 host() == "example.com"。
加密的 HTTPS（不进行传输层安全协议 (TLS) 检查） 无法在应用级 或会话级进行主机匹配。这是因为请求 详细信息已加密，并且不支持 destination.ip 属性。您必须使用更广泛的政策控制（例如 来源身份匹配），或者启用 TLS 检查 以进行基于主机的过滤。 如需使用 Application Matcher，请使用来源 身份匹配（例如服务账号） 或启用 TLS 检查。
加密的 HTTPS（进行 TLS 检查） 如需检查完整请求，您必须同时使用 Session Matcher 和 Application Matcher。 1. 设置一个通用的 Session Matcher 规则，该规则要么返回 true，要么匹配目标主机（例如 host() == "example.com"）。

2. 在 applicationMatcher 字段中，添加一个 特定的主机 规则，例如 request.host() == "example.com"。

为下一个跃点模式配置主机匹配规则

将 Secure Web Proxy 部署为下一个跃点时，您必须配置主机匹配规则。流量会通过 Virtual Private Cloud (VPC) 路由重定向到代理，该路由基于您定义的 IP 地址范围。主机匹配规则可确保代理通过检查流量的各个字段（例如服务器名称指示 (SNI) 标头）来正确识别目标主机。

在下一个跃点模式下，主机匹配适用于不同类型的 Web 流量，方式如下：

流量类型 匹配机制 规则配置
未加密的 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. 设置一个通用的 Session Matcher 规则，该规则要么返回 true，要么匹配目标主机（例如 host() == "example.com"）。

2. 在 applicationMatcher 字段中，添加一个特定的主机规则，例如 request.host() == "example.com"。

TCP 代理规则

借助传输控制协议 (TCP) 代理规则，您可以控制非标准 Web 流量（例如 HTTP [端口 80] 或 HTTPS [端口 443]）。通过配置 TCP 代理规则，您可以允许或阻止任何其他 TCP 端口上的流量。这些规则有助于您阻止恶意流量并管理使用 TCP 的非 Web 应用。

如果您的工作负载（例如应用和服务）将 Secure Web Proxy 用作下一个跃点， 则应用 TCP 代理规则会很有用。基于路由的重定向会将非 HTTP(S) 和非 Web 流量定向到您的 Secure Web Proxy 实例。这样，您就可以阻止出站流量到达恶意外部网站，并管理您的网络工作负载可以连接到的外部服务。

配置 TCP 代理规则

您可以为应用配置 TCP 代理规则，以保护非 Web 流量，并为不使用标准 HTTP/S（例如端口 80 和 443）的应用强制执行安全政策。

通过应用这些规则，您可以防止未经授权使用其他 TCP 端口进行数据传输或恶意活动。当您的 工作负载将 Secure Web Proxy 用作下一个跃点以处理 非 Web 协议时，此功能尤为有用。

如需实现 TCP 代理规则并为应用创建允许或阻止流量规则，您必须指定目标端口。您还可以选择添加以下任何 Session Matcher 属性，以细化允许或阻止规则的条件。

下表详细介绍了您可以在 TCP 代理规则中使用的各种属性：

属性 属性类型 说明
source.ip 字符串 发送请求的客户端的 IP 地址。
source.port 字符串 发送请求的客户端端口。
destination.port 字符串 您的 Secure Web Proxy 实例将流量发送到的上游端口。
source.matchTag(SECURE_TAG) 布尔值

如果来源与 相关联，则为True。SECURE_TAG

该实参是安全标记的永久 ID，例如 source.matchTag('tagValues/123456')。
source.matchServiceAccount(SERVICE_ACCOUNT) 布尔值 True，如果来源与 SERVICE_ACCOUNT 相关联（例如 source.matchServiceAccount('x@my-project.iam.gserviceaccount.com')）。
inIpRange(IP_ADDRESS,
IP_RANGE)		 布尔值 True，如果 IP_ADDRESS 包含在 IP_RANGE 中（例如 inIpRange(source.ip, '1.2.3.0/24')），则为 。IPv6 地址的子网掩码不能大于 `/64`。

TCP 代理规则示例

此示例展示了如何使用 CEL 表达式定义 Secure Web Proxy gatewaySecurityPolicyRule，以允许 所有 TCP 流量到达端口 22。在应用安全 Web 代理的 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 代理规则时，不支持 host Session Matcher 属性，因为主机信息在 TCP 层不可用。

  • TCP 代理规则仅根据目标端口过滤 Web 流量。为了提高网络的安全性，建议您使用逻辑运算符（逻辑 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 不支持为用户数据报协议 (UDP) 应用配置代理规则。因此，Secure Web Proxy 会阻止基于 UDP 的应用的流量。

创建安全规则

在创建网关安全规则之前，请确保执行以下操作：

  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. 点击添加规则 。

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 代理规则。

  2. 创建安全政策规则。

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

限制

后续步骤