将前端 mTLS 与 Secure Web Proxy 搭配使用

您可以在 Secure Web Proxy 上配置前端双向 TLS (mTLS)，以增强工作负载（例如 AI 代理）的安全性。Secure Web Proxy 使用前端 mTLS 通过证书验证客户端身份。

通过此集成，您可以在安全 Web 代理授权政策中使用经过验证的客户端身份，以针对出站流量强制执行精细的访问权限控制。

工作原理

以下步骤介绍了 Secure Web Proxy 如何使用前端 mTLS 来保护出站流量：

• 显式代理连接：您可以将客户端配置为使用 Secure Web Proxy 作为其显式代理。客户端向 Secure Web Proxy 前端发起 HTTPS CONNECT 请求，而不是直接连接到互联网。

• 双向 TLS 握手：在连接设置期间，Secure Web Proxy 和客户端在代理前端执行 mTLS 握手。代理使用配置的 TrustConfig 资源来验证客户端的证书，而客户端则验证代理的服务器证书。

• 身份提取：成功完成握手后，Secure Web Proxy 会直接从经过验证的客户端证书中提取唯一身份属性（例如 URI_SAN）。

• 基于身份的授权：Secure Web Proxy 会根据您配置的授权政策评估出站请求。为了确定请求是否获得授权，代理会使用在 mTLS 握手期间经过加密验证的客户端身份。

• 安全地处理出站流量：获得授权后，如果外部目的地有匹配的规则，Secure Web Proxy 会满足对该目的地的请求。

主要优势

在 Secure Web Proxy 上配置前端 mTLS 具有以下安全和运营优势：

• 增强安全性：通过要求所有出站流量都进行前端 mTLS 身份验证，实现零信任访问。这可确保只有经过验证的身份的工作负载才能与代理建立连接，以访问外部服务。

• 简化的工作负载配置：使用 Secure Web Proxy 的显式代理路由模式，以利用代理拦截和验证请求的能力。

• 精细控制：强制执行详细的、可识别身份的政策，以确定每个特定工作负载可以访问哪些外部服务。

使用场景示例：验证工作负载的身份

在银行等合规性要求高且受监管的行业中，仅验证请求的网络位置不足以防止未经授权的数据访问。通过在 Secure Web Proxy 上配置前端 mTLS，组织可以改用经过加密验证的身份模型。这样一来，无论是虚拟机 (VM) 实例还是 AI 代理，每个工作负载都必须使用可信证书来证明其特定身份。

此方法可让管理员强制执行基于身份的护栏，以保护敏感的出站路径。例如，银行可以确保只有特定的经过身份验证的付款处理工作负载才能访问外部金融网关。

为 Secure Web Proxy 配置前端 mTLS 身份验证

本部分介绍了为 Secure Web Proxy 实例配置前端 mTLS 身份验证的步骤。

准备工作

• 查看管理信任配置页面。

• 安装 Google Cloud CLI

• 启用必需的 API

• 请让您的 Identity and Access Management 管理员为您授予以下角色：

  • Certificate Manager Owner 角色 (roles/certificatemanager.owner)
  • Compute Network Admin 角色 (roles/compute.networkAdmin)
  • Compute Security Admin 角色(roles/compute.securityAdmin)
  • Networksecurity Admin 角色 (roles/networksecurity.admin)

• 您必须拥有以显式代理路由模式部署的 Secure Web Proxy 实例。

创建根证书和中间证书

本部分介绍如何使用 OpenSSL 生成根证书授权机构 (CA) 证书（信任锚）和可选的中间 CA 证书。Secure Web Proxy 使用这些证书来验证工作负载在前端 mTLS 握手过程中提供的客户端证书。此手动流程适用于测试和开发环境，旨在提供 Secure Web Proxy 验证客户端证书所需的信任锚。

根证书位于证书链的顶部，而中间证书在可回溯到根证书的信任链中充当桥梁。中间证书由根证书进行加密签名。当 Secure Web Proxy 收到客户端证书时，它会通过建立一条从客户端证书回溯到配置的信任锚点的信任链来验证身份。

使用以下命令创建根证书和中间证书。虽然中间证书是可选的，但此配置使用它来对客户端证书进行签名，以显示多层证书层次结构。

1. 创建 OpenSSL 配置文件。

   cat > example.cnf << EOF
   [req]
   distinguished_name = empty_distinguished_name
   
   [empty_distinguished_name]
   # Kept empty to allow setting via -subj command-line argument.
   
   [ca_exts]
   basicConstraints=critical,CA:TRUE
   keyUsage=keyCertSign
   extendedKeyUsage=clientAuth
   EOF
   

2. 创建自签名 X.509 根证书 (root.cert) 和私钥 (root.key)。

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=root' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout root.key -out root.cert
   

3. 为中间证书创建证书签名请求 (int.req)。

   openssl req -new \
       -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=int' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout int.key -out int.req
   

4. 对证书签名请求 (CSR) 进行签名，以创建 X.509 中间证书 (int.cert)。

   openssl x509 -req \
       -CAkey root.key -CA root.cert \
       -set_serial 1 \
       -days 3650 \
       -extfile example.cnf \
       -extensions ca_exts \
       -in int.req -out int.cert
   

创建用于测试的客户端证书

为测试客户端工作负载创建叶证书和私钥。在与 Secure Web Proxy 实例进行 mTLS 握手期间，客户端会提供此叶证书来证明自己的身份。

以下示例使用 OpenSSL 生成客户端密钥和 CSR，然后使用您在创建根证书和中间证书部分中创建的中间 CA 密钥对 CSR 进行签名。

1. 运行以下 OpenSSL 命令，以生成名为 client.key 的 RSA 私钥：

   openssl genpkey -algorithm RSA -out client.key
   

2. 创建一个名为 client.cnf 的配置文件，用于指定正文备用名称 (SAN) 的 DNS 名称。这有助于确保证书符合现代安全要求。

   cat > client.cnf << EOF
   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   prompt = no
   
   [req_distinguished_name]
   CN = my-client.example.com
   
   [v3_req]
   keyUsage = critical, digitalSignature, keyEncipherment
   extendedKeyUsage = clientAuth
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = my-client.example.com
   
   EOF
   

   您可以根据测试需要修改 CN 和 DNS.1 值。

3. 使用您创建的私钥和配置文件运行 OpenSSL 请求命令，以生成 client.req 文件。

   openssl req -new -key client.key -out client.req -config client.cnf
   

4. 使用 OpenSSL x509 命令，通过您的中间证书 (int.cert) 和密钥 (int.key) 对请求进行签名。设置有效期（例如 365 天），并确保配置文件中的扩展程序应用于生成的 client.cert 文件。

   openssl x509 -req -in client.req -CA int.cert -CAkey int.key \
     -set_serial 02 -days 365 -out client.cert \
     -extfile client.cnf -extensions v3_req
   

   此过程会创建 client.cert 文件。将 DNS SAN（例如 my-client.example.com）中使用的值记录为您的客户端身份。您可以在创建 Secure Web Proxy 授权政策时使用此值来标识工作负载。

设置证书格式

将根证书和中间证书格式化为可在 trust_config.yaml 文件中使用的环境变量。

  export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
  export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

创建信任配置资源

信任配置表示 Certificate Manager 中的公钥基础架构 (PKI)。信任配置会向您的 Secure Web Proxy 实例指明在前端 mTLS 握手期间验证客户端证书时要信任哪些证书授权机构 (CA) 证书。

此示例信任配置资源包含一个受信任证书存储区，该存储区具有一个信任锚（根 CA）和一个中间 CA。它使用您在上一个设置证书格式部分中创建的环境变量中的证书内容。

1. 创建 trust_config.yaml 文件。

   cat << EOF > trust_config.yaml
   trustStores:
     TRUST_CONFIG_NAME:
       trustAnchors:
         - pemCertificate: |
           -----BEGIN CERTIFICATE-----
           <certificate content>
           -----END CERTIFICATE-----
       intermediateCAs:
         - pemCertificate: |
           -----BEGIN CERTIFICATE-----
           <certificate content>
           -----END CERTIFICATE-----
   
   EOF
   

   将 TRUST_CONFIG_NAME 替换为您的信任配置资源的名称。

2. 使用 gcloud certificate-manager trust-configs import 命令导入 trust config.yaml 文件。

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\
     --source=trust_config.yaml \
     --location=LOCATION
   

   替换以下内容：

   • TRUST_CONFIG_NAME：信任配置资源的名称

   • LOCATION：存储信任配置资源的区域

创建 ServerTlsPolicy 资源

ServerTlsPolicy 资源（也称为客户端身份验证资源）用于定义 Secure Web Proxy 验证客户端证书的方式。借助该资源，您可以指定证书验证的服务器端 TLS 模式和信任配置资源。

clientValidationMode 属性用于确定当客户端提供无效证书或根本不提供证书时，连接的处理方式。如需了解详情，请参阅前端 mTLS 客户端验证模式。

clientValidationMode 属性的值如下所示：

• REJECT_INVALID：Secure Web Proxy 仅允许来自以下客户端的连接：这些客户端提供由您信任配置中的 CA 签名的有效证书。系统会拒绝证书无效或缺失的连接。

• ALLOW_INVALID_OR_MISSING_CLIENT_CERT：即使客户端证书无效、无法根据您的信任配置进行验证或完全缺失，Secure Web Proxy 也会允许连接请求。

如需创建 ServerTlsPolicy 资源，请按以下步骤操作：

1. 创建 server_tls_policy.yaml 文件，为 clientValidationMode 选择以下选项之一：

   • 选项 1：ALLOW_INVALID_OR_MISSING_CLIENT_CERT

   name: SERVER_TLS_POLICY_NAME
   mtlsPolicy:
     clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
     clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
   

   • 选项 2：REJECT_INVALID

   name: SERVER_TLS_POLICY_NAME
   mtlsPolicy:
     clientValidationMode: REJECT_INVALID
     clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
   

   替换以下内容：

   • SERVER_TLS_POLICY_NAME：ServerTlsPolicy 资源的名称

   • PROJECT_ID：您的 Google Cloud 项目的 ID

   • TRUST_CONFIG_NAME：信任配置资源的名称

   • LOCATION：配置 Secure Web Proxy 实例的区域

2. 使用 gcloud network-security server-tls-policies import 命令导入 ServerTlsPolicy 资源。

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\
     --source=server_tls_policy.yaml \
     --location=LOCATION
   

   替换以下内容：

   • SERVER_TLS_POLICY_NAME：ServerTlsPolicy 资源的名称

   • LOCATION：配置 Secure Web Proxy 实例的区域

3. 可选：如需列出所有 ServerTlsPolicies 资源，请使用 gcloud network-security server-tls-policies list 命令。

   gcloud network-security server-tls-policies list \
     --location=LOCATION
   

   将 LOCATION 替换为配置 Secure Web Proxy 实例的区域。

将 ServerTlsPolicy 资源与 Secure Web Proxy 实例相关联

1. 将 ServerTlsPolicy 资源附加到 Secure Web Proxy 实例的 gateway.yaml 文件中。

   echo "serverTlsPolicy:
   //networksecurity.googleapis.com/projects/PROJECT_ID/locations/
   LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME"
   >> gateway.yaml
   

   替换以下内容：

   • PROJECT_ID：您的 Google Cloud 项目的 ID

   • LOCATION：配置 Secure Web Proxy 实例的区域

2. 使用 gcloud network-services gateways import 命令从 gateway.yaml 文件导入 Secure Web Proxy 实例的配置。

   gcloud network-services gateways import GATEWAY_NAME\
       --source=gateway.yaml \
       --location=LOCATION
   

   替换以下内容：

   • GATEWAY_NAME：Secure Web Proxy 实例的名称

   • LOCATION：配置 Secure Web Proxy 实例的区域

配置授权政策

如需了解详情，请参阅为 Secure Web Proxy 设置授权政策。

日志记录

如需了解详情，请参阅前端 mTLS 错误处理和日志记录。

限制

• Secure Web Proxy 仅在显式代理路由模式下支持配置前端 mTLS。

• 如需创建基于前端 mTLS 的安全规则，请使用 Secure Web Proxy 的授权政策。网关安全政策规则不受支持。

如需了解详情，请参阅前端 mTLS 限制。

后续步骤

• 将 Secure Web Proxy 部署为 Private Service Connect 服务