规则评估顺序

规则评估会使用您在政策中设置的规则来确定应允许还是拒绝 Web 请求。它会考虑以下属性来做出决策：

  • 规则的优先级：数字越小，优先级越高。
  • SessionMatcher：与以下会话级属性匹配：
    • 来源计算机的 IP 地址
    • 来源计算机的服务账号
    • 来源机器的安全标记
    • 目标计算机的主机名
  • ApplicationMatcher：与以下 HTTP 请求属性匹配：
    • 网址
    • 路径
    • 请求标头

如需查看所有 SessionMatcher 和 ApplicationMatcher 属性的列表，请参阅 SessionMatcher 和 ApplicationMatcher 中的可用属性。

规则评估的工作原理

系统会按以下顺序评估规则：

  1. 系统会先评估高优先级规则。
  2. 与 SessionMatcher 和 ApplicationMatcher 属性匹配的最高优先级规则决定了对流量要采取的操作。
  3. 如果请求与该规则的 SessionMatcher 和 ApplicationMatcher 属性不匹配，系统会评估优先级最高的下一条规则。
  4. 此过程会持续进行，直到找到与请求匹配的规则或评估完所有规则为止。如果未找到匹配项，则拒绝该请求。

配置 TLS 检查之前

在配置 TLS 检查之前，您必须先了解以下规则评估场景：

  • 客户端可以向代理服务器发送 HTTP 请求。然后，系统会使用所有可用数据（包括主机名、来源标识、HTTP 标头和路径）来评估请求。

    如果允许请求，则会将 HTTP 流量发送到目的地。但是，如果请求被拒绝，则不允许通过 HTTP 流量。

  • 客户端可以向代理发送 HTTP CONNECT 请求，以建立到目的地的 TCP 隧道。当客户端想要发送任意 TCP 流量或通过代理与目的地建立端到端 TLS 连接（如同 HTTPS 一样）时，就会执行此操作。

  • 如果规则具有匹配的 SessionMatcher 属性且不包含 ApplicationMatcher 属性，并且规则评估结果为允许流量，则系统会建立到目的地的隧道，并通过 TCP 代理转发流量。这适用于 HTTPS 和 TCP 流量。

  • 如果优先级较高的规则无法确定对请求要采取的操作，则系统会继续评估规则。如果评估继续到具有 ApplicationMatcher 属性的规则，则隧道流量会被解读为 HTTP 或 HTTPS。

    如果底层数据不是 HTTP 或 HTTPS，则连接会失败。

    如果底层数据是 HTTP，系统会评估请求，包括主机名、来源身份、HTTP 标头和路径。系统会根据评估结果允许或拒绝流量。

  • 对于 HTTPS 流量，只有启用了 TLS 检查标志的规则才会被评估；否则，系统会跳过该规则。

  • 对于 HTTPS 流量，只有在满足以下条件时，系统才会检查规则：

    • TLS 检查标志已启用。
    • 流量与 SessionMatcher 属性匹配。

有关配置 TLS 检查规则的建议

  • 如果您想允许 TCP 流量，则允许 TCP 流量的规则的优先级必须高于允许 HTTP 流量的规则。
  • 具有 ApplicationMatcher 属性的规则应使用 SessionMatcher 属性来严格限定范围，以最大限度地减少将不相关流量解读为 HTTP 的情况。
  • 允许 TLS（包括 HTTPS）流量但不执行 TLS 检查的规则可解读为 TCP 代理规则。
  • 为避免对流量进行不必要的 TLS 检查，TLS 检查规则的优先级应低于非 TLS 检查规则。或者，为了针对不匹配的流量快速失败，应使用 SessionMatcher 属性来严格限定 TLS 检查规则的范围。

TLS 检查规则配置示例

请考虑以下示例中的两条规则。

示例 1

在此示例中，我们假设存在其他优先级较低的规则。请考虑以下两个规则：

  • 规则 1

    description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

  • 规则 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

在此示例中，安全 Web 代理会将这两条规则解读如下：

  • 允许 TCP 流量但禁止特定类型的 HTTP 请求是互斥的，因为 TCP 流量可以包含 POST 请求。
  • 规则 2 中的流量绝不允许。系统会拒绝该请求，因为系统会拦截从代码 12345 到 example.com 的流量，并将其解读为 HTTP 流量，以便评估 HTTP 方法。

  • 如需让规则 2 生效，您可以使用以下任一解决方案：

    • 建议：将规则 2 的优先级提高到更高级别（优先级：5）。

    • 缩小规则 1 的范围，以免允许的流量与其 SessionMatcher 属性重叠：

      sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

      我们不建议采用此解决方案，因为许多重叠的规则会难以维护。

示例 2

请考虑以下两个规则：

  • 规则 1

    description: allow to specific GitHub repository (TLS inspect to match specific path)
priority: 10
basicProfile: ALLOW
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.url().startsWith('github.com/grpc/grpc')

  • 规则 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: host() == 'bankofamerica.com'

在此示例中，安全 Web 代理会将这两条规则解读如下：

  • 系统会检查所有流量（包括目的地为 bankofamerica.com 的流量），确保 TLS 与高优先级规则 1 的 request.url() 匹配。

  • 如需避免规则 2 中的 TLS 检查，您可以使用以下任一解决方案：

    • 将规则 2 的优先级提高到更高级别（优先级：5）。 因此，系统会先应用规则 2，然后再评估规则 1，并且允许来自 bankofamerica.com 的流量，而无需进行 TLS 检查。

    • 建议：缩小规则 1 的范围，仅允许对 github.com 网域进行 TLS 检查。如需缩小范围，请添加定位到的 sessionMatcher 属性：

      sessionMatcher: host() == 'github.com'

限制

在配置 TLS 检查之前，您必须考虑以下限制：

  • 服务器仅通过使用公共根证书进行验证。根证书授权机构 (CA) 集基于 Mozilla 根计划。证书验证行为可能会发生变化，并且与网络浏览器验证证书的方式相对应。

    由于目前无法进行后端验证，因此无法拦截使用私钥或自签名证书的服务器的流量。

  • 安全 Web 代理不会运行证书吊销列表 (CRL) 检查。

  • 为了使 TLS 检查正常运行，客户端目前必须发送服务器名称指示 (SNI)。SNI 是可选的 TLS 规范扩展，但大多数客户端默认启用它。

  • 如果客户端需要使用经过加密的 ClientHello (ECH)（以前称为经过加密的 SNI），TLS 检查将无法正常运行。

    ECH 是一项 IETF 标准草案，允许客户端使用预先建立的服务器密钥对 TLS 握手的开头进行加密。由于 TLS 检查充当拦截代理，因此无法访问该预先建立的服务器密钥。因此，ECH 无法正常运行。

  • 必须将客户端配置为信任您的私有根证书。

  • 如果您从私有 CA 池中移除 CA，系统最多会在 28 小时内为您提供由该 CA 签名的缓存证书。如需防止使用缓存的证书，您可以更新 TLS 检查政策，使其指向新的 CA 池。因此，安全 Web 代理会被迫生成新的证书。