规则评估顺序

规则评估通过使用您在政策中设置的规则来确定是应该允许还是拒绝 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 流量的规则。
  • 您应使用 SessionMatcher 属性来限定具有 ApplicationMatcher 属性的规则的范围，以尽量减少将不相关的数据流解释为 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 Root Program。证书验证的行为随时可能发生变化，并且与网络浏览器验证证书的方式相对应。

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

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

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

  • 如果客户端需要加密客户端 Hello (ECH)（以前称为加密 SNI），TLS 检查将不起作用。

    ECH 是 IETF 草案标准，允许客户端使用预先建立的服务器密钥对 TLS 握手的开始进行加密。由于 TLS 检查充当拦截代理，因此它无权访问预先建立的服务器密钥。因此，ECH 不起作用。

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

  • 如果从专用 CA 池中移除 CA，您将获得由该 CA 签名的缓存证书（最多 28 小时）。为防止使用缓存的证书，您可以将 TLS 检查政策更新为指向新的 CA 池。因此，安全 Web 代理必须生成新证书。