规则评估顺序

规则评估会使用您在政策中设置的规则来确定是否应允许或拒绝 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）。 因此，在评估规则 1 之前，会应用规则 2， 允许来自 bankofamerica.com 的流量未经 TLS 检查。

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

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

限制

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

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

  由于目前无法进行后端验证， 使用专用证书或自签名证书的服务器 被拦截。

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

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

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

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

• 客户端必须配置为信任您的专用根证书。

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