搭配 Secure Web Proxy 使用前端 mTLS

您可以在 Secure Web Proxy 上設定前端相互傳輸層安全標準 (mTLS)，提升工作負載 (例如 AI 代理程式) 的安全性。Secure Web Proxy 會使用前端 mTLS，透過憑證驗證用戶端身分。

這項整合功能可讓您在 Secure Web Proxy 授權政策中使用經過驗證的用戶端身分，對輸出流量強制執行精細的存取控管。

運作方式

下列步驟說明 Secure Web Proxy 如何使用前端 mTLS 保護輸出流量：

• 明確的 Proxy 連線：您可以將用戶端設定為使用 Secure Web Proxy 做為明確的 Proxy。用戶端會向 Secure Web Proxy 前端發出 HTTPS CONNECT 要求，而不是直接連線至網際網路。

• 雙向 TLS 握手：在連線設定期間，Secure Web Proxy 和用戶端會在 Proxy 前端執行 mTLS 握手。Proxy 會使用設定的 TrustConfig 資源驗證用戶端憑證，而用戶端會驗證 Proxy 的伺服器憑證。

• 身分識別資訊擷取：握手成功後，Secure Web Proxy 會直接從經過驗證的用戶端憑證擷取專屬身分識別屬性，例如 URI_SAN。

• 以身分為依據的授權：Secure Web Proxy 會根據您設定的授權政策，評估輸出要求。為判斷要求是否獲得授權，Proxy 會使用用戶端的身分，該身分已在 mTLS 握手期間經過加密驗證。

• 確保輸出流量安全：獲得授權後，如果外部目的地有相符的規則，Secure Web Proxy 就會將要求傳送至目的地。

主要優點

在 Secure Web Proxy 上設定前端 mTLS 可提供下列安全性和作業優點：

• 提升安全性：要求所有外送流量都必須通過前端 mTLS 驗證，實現零信任存取。這樣就能確保只有身分經過驗證的工作負載，才能與 Proxy 建立連線，存取外部服務。

• 簡化工作負載設定：使用 Secure Web Proxy 的明確 Proxy 轉送模式，運用 Proxy 攔截及驗證要求的功能。

• 精細控管：強制執行詳細的身分感知政策，判斷每個特定工作負載可存取哪些外部服務。

用途範例：驗證工作負載的身分

在銀行業等法規遵循要求嚴格的受監管產業中，驗證要求的網路位置不足以防止未經授權的資料存取。在 Secure Web Proxy 上設定前端 mTLS 後，機構就能改用經過密碼編譯驗證的身分模型。這可確保每個工作負載 (無論是虛擬機器 (VM) 執行個體或 AI 代理程式)，都必須使用可信任的憑證證明其特定身分。

管理員可透過這種方法強制執行以身分為依據的防護措施，保護敏感的出站路徑。舉例來說，銀行可以確保只有經過驗證的特定付款處理工作負載，才能連線至外部金融閘道。

為 Secure Web Proxy 設定前端 mTLS 驗證

本節說明如何設定 Secure Web Proxy 執行個體的前端 mTLS 驗證。

事前準備

• 查看「管理信任設定」頁面。

• 安裝 Google Cloud CLI

• 啟用必要的 API

• 請身分與存取權管理員授予下列角色：

  • Certificate Manager 擁有者角色 (roles/certificatemanager.owner)
  • Compute 網路管理員角色 (roles/compute.networkAdmin)
  • Compute 安全管理員角色 (roles/compute.securityAdmin)
  • Networksecurity Admin 角色 (roles/networksecurity.admin)

• 您必須在明確的 Proxy 路由模式中部署 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) 記錄為用戶端 ID。建立 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 僅支援在明確 Proxy 路由模式中設定前端 mTLS。

• 如要建立前端 mTLS 型安全性規則，請使用 Secure Web Proxy 的授權政策。系統不支援閘道安全性政策規則。

詳情請參閱前端 mTLS 限制。

後續步驟

• 將 Secure Web Proxy 部署為 Private Service Connect 服務