传输层安全协议 (TLS) 加密流量占 Web 流量的绝大部分。由于威胁行为者经常使用这些加密通道来隐藏恶意活动，因此在这些流量到达目的地之前对其进行检查至关重要。
Secure Web Proxy 提供集成的 TLS 检查服务，可让您拦截和解密 HTTPS 流量。通过了解加密请求，Secure Web Proxy 可以应用高级安全政策（例如对完整请求路径进行网址过滤和 HTTP 标头检查），以保护您的环境免受隐藏在加密隧道中的威胁。
工作原理
TLS 检查的工作原理是建立两个单独的加密连接，其中 Secure Web Proxy 充当安全中介。
客户端握手：当客户端尝试连接到外部网站（例如
www.example.com）时，Secure Web Proxy 会拦截该请求。证书生成：Secure Web Proxy 会实时为
www.example.com生成临时证书。根据配置的证书颁发模式，代理会直接从 CA Service 为每个网域请求叶证书，或使用 CA 池中缓存的中间 CA 证书在本地对叶证书进行签名。信任验证：客户端随后会收到该临时证书。
检查点：流量在 Secure Web Proxy 实例中解密。在此阶段，安全政策会应用于纯文本 HTTP 数据。
服务器握手：Secure Web Proxy 随后会启动与实际目标服务器的第二个 TLS 连接。流量会被重新加密并发送到目标地址。
主要特性
Secure Web Proxy TLS 检查服务提供了一个灵活、可伸缩的框架，可通过以下功能管理加密流量：
集成式私有信任：与 CA Service 的内置集成可为您的私有 CA 提供由 Google 管理的高可用性代码库。
灵活的信任根：使用现有的本地根证书授权机构 (CA) 为 CA Service 中托管的从属 CA 签名。然后，您可以直接在 CA Service 中生成和管理全新的根证书。
特定解密：使用
SessionMatcher精确定义要解密的流量。您可以根据以下参数触发 TLS 检查：- 网站域名：使用正则表达式和域名列表匹配特定网站。
- 网络条件：定位到特定来源 IP 地址范围或无类别域间路由 (CIDR) 块（例如
10.0.0.0/24），以定义网络边界。 - 布尔逻辑：组合多个条件（例如来源 IP 和目标网址），以创建高度具体的安全规则。
可扩缩的政策架构：
专用政策：为每个 Secure Web Proxy 政策分配唯一的 TLS 检查政策和 CA 池，以实现严格隔离。
共享政策：通过在多个代理政策之间共享单个 TLS 检查配置，简化政策管理。
完整的统一资源标识符 (URI) 可见性：检查整个 URI（包括网域、路径和查询字符串，例如
www.example.com/downloads/malware.exe），而不仅仅是域名。精确访问权限控制：使用 TLS 检查对网站的特定路径强制执行政策。例如，您可以允许访问
www.example.com/documentation，但禁止访问www.example.com/uploads。中间 CA 支持：通过在本地缓存单个中间 CA 来对叶证书进行签名，而不是直接向 CA Service 发出每个网域的请求，从而降低 CA Service 使用费。如需了解详情，请参阅证书颁发模式。
证书授权机构在 TLS 检查中的角色
为了检查加密流量，Secure Web Proxy 会充当可信中介。这涉及代理、CA Service 和客户端设备之间的协调过程。
客户端信任要求
TLS 检查专为组织对客户端设备（例如受管笔记本电脑、服务器或虚拟机 [VM]）拥有管理控制权的环境而设计。
智能体容器信任：在路由来自容器化 AI 智能体（例如在 Cloud Run 或 Google Kubernetes Engine [GKE] 中）的出站 Web 流量时，您必须从 CA 池或私有公钥基础架构 (PKI) 导出根 CA 证书，并将其注入容器的证书信任存储区。例如，您可以配置容器运行时，也可以设置
AGENT_GATEWAY_ROOT_CERTIFICATES或SSL_CERT_FILE环境变量。如需详细了解如何配置根 CA，请参阅“将 Secure Web Proxy 部署为 Agent Gateway”中的设置 TLS 检查。私有信任锚：由于 Secure Web Proxy 提供的证书由内部 CA 而非公共 CA 签名，因此只有在预安装了私有根 CA 的情况下，客户端才会信任连接。
管理范围：来自非受管硬件的连接通常会触发
Insecure connection警告，因为这些设备缺少贵组织的特定信任锚。
处理拦截失败
即使在受管设备上，由于证书固定，某些连接也无法被拦截。当应用被硬编码为仅接受特定公钥或特定公共 CA 链时，就会发生证书固定。
- 证书固定示例：使用固定的常见服务包括 Windows 和 macOS 系统更新、Google Chrome 更新以及某些高安全性移动应用。
- 证书固定的结果：当 Secure Web Proxy 提供其签名证书时，应用会检测到该证书与其硬编码的预期不符，并终止连接。
缓解和精确控制
为防止固定应用的服务中断或维护敏感网站的隐私，您可以使用 SessionMatcher 属性绕过检查。您可以根据以下参数限制或跳过检查：
证书颁发模式
Secure Web Proxy 支持两种模式来预配其在 TLS 检查过程中用于解密流量的证书。具体选择取决于您的费用、性能和审核日志记录要求。
如需了解详情，请参阅配置本地中间 CA 签名。
本地中间 CA 签名
如果您将 certificateIssuanceMode 设置为 LOCAL_INTERMEDIATE_CA_SIGNING，Secure Web Proxy 会从 CA 池请求单个中间 CA 证书。代理会缓存此中间 CA，并在本地为所需网域对各个叶证书进行签名。
本地中间 CA 签名证书颁发模式的功能如下：
降低 CA Service 费用：对 CA Service 的请求仅限于中间 CA 的刷新周期（通常每天一次），而不是针对每个网域发生，从而降低了交易费用。
可观测性降低：代理在本地签名的各个叶证书不会记录在 CA Service 审计日志中。
直接叶节点预配
如果您将 certificateIssuanceMode 设置为 DIRECT_LEAF_PROVISIONING，Secure Web Proxy 会直接与每个唯一网域的 CA Service 池通信，以请求叶证书。
直接叶证书预配证书颁发模式的功能如下：
更高的可观测性：每个生成的证书请求都会记录在 CA Service 审计日志中，以便您跟踪和审计所有证书生成活动。
CA Service 费用较高：由于请求会发送到每个网域的 CA Service，因此在具有多个唯一网域或代理任务的环境中，此过程可能会导致较高的交易费用。
证书授权机构配置方法
如需启用 TLS 检查，请使用以下任一方法设置证书授权机构 (CA)：
CA Service 中的从属 CA：使用现有外部根 CA 为存储在 Google Cloud中的从属 CA 签名。
外部根 CA：使用外部根 CA 对在运行时通过从属 CA 生成的证书进行签名。
Google 管理的根 CA：直接在 CA Service 中生成新的根证书，用于为从属 CA 签名。
如需详细了解这些方法，请参阅创建从属 CA 池。