Cloud Service Mesh 安全性總覽
Cloud Service Mesh 搭配 Istio API 安全性，可確保工作負載間的所有通訊都經過加密、雙向驗證與授權，有效減少內部威脅，並降低資料侵害風險。
傳統上，使用 IP 規則的微區隔可用於降低內部風險。不過，隨著容器、共用服務和分散式正式環境的採用率提高，這種做法的設定和維護難度也隨之增加。
透過 Cloud Service Mesh，您可以設定一層服務情境感知和要求情境感知網路安全，與基礎網路的安全性無關。因此，Cloud Service Mesh 可讓您採用符合零信任安全性原則的縱深防禦機制。您可以使用宣告式政策達成此目標，且無需修改任何應用程式程式碼。
相互傳輸層安全標準 (TLS)
Cloud Service Mesh 會使用相互傳輸層安全標準 (mTLS) 進行對等互連驗證。驗證是指身分：這項服務是誰？這位使用者是誰？我是否可以信任他們的身分？
工作負載可透過 mTLS 驗證彼此的身分，並相互驗證。您可能已透過 HTTPS 使用簡單的 TLS，讓瀏覽器信任網路伺服器，並加密交換的資料。使用簡易 TLS 時，用戶端會驗證伺服器的憑證，確認伺服器值得信任。mTLS 是 TLS 的一種實作方式，用戶端和伺服器會互相提供憑證並驗證彼此的身分。
Cloud Service Mesh 會透過 mTLS 實作服務之間的驗證和加密。
在 Cloud Service Mesh 中，系統預設會啟用自動 mTLS。使用自動 mTLS 時，用戶端 Sidecar Proxy 會自動偵測伺服器是否具有 Sidecar。用戶端 Sidecar 會將 mTLS 傳送至具有 Sidecar 的工作負載，並將純文字傳送至沒有 Sidecar 的工作負載。但請注意，服務接受純文字和 mTLS 流量。為保護服務網格，建議您將服務遷移至僅接受 mTLS 流量。
如要進一步瞭解如何強制執行 mTLS，請參閱「Cloud Service Mesh 範例：mTLS」。
安全優勢
Cloud Service Mesh 提供下列安全性優勢：
降低重播或模擬攻擊的風險，避免攻擊者使用竊取的憑證。Cloud Service Mesh 依賴 mTLS 憑證驗證對等互連，而非 JSON Web Token (JWT) 等不記名權杖。由於 mTLS 憑證繫結至 TLS 通道，因此在無法存取私密金鑰的情況下，正式環境中的實體無法透過重播驗證權杖來模擬其他實體。
確保傳輸中資料加密。使用 mTLS 進行驗證，也能確保所有 TCP 通訊在傳輸過程中都經過加密。
確保只有授權用戶端可以存取含有機密資料的服務。只有獲得授權的用戶端可以存取含有機密資料的服務，無論用戶端的網路位置和應用程式層級憑證為何。您可以指定只有具備授權服務身分，或位於授權 Kubernetes 命名空間中的用戶端，才能存取服務。您也可以使用以 IP 為基礎的存取權政策，將存取權授予部署在網格外的用戶端。
降低正式環境網路中的使用者資料侵害風險。您可以確保內部人員只能透過授權用戶端存取機密資料。此外，您也可以確保特定用戶端只有在能提供有效且短期的使用者權杖時，才能存取使用者資料。這樣一來，即使單一用戶端憑證遭盜用，攻擊者也無法存取所有使用者資料，可降低相關風險。
找出哪些用戶端存取了含有機密資料的服務。除了 IP 位址，Cloud Service Mesh 存取記錄也會擷取用戶端的 mTLS 身分。因此，即使工作負載是暫時性且動態部署，且位於不同的叢集或虛擬私有雲 (VPC) 網路，您也能瞭解是哪個工作負載存取服務。
功能與特色
本節說明 Cloud Service Mesh 提供的功能，可實現安全性優勢。
自動憑證和金鑰輪替
使用以服務身分為基礎的 mTLS，即可加密所有 TCP 通訊，並提供更安全的不可重播憑證，用於存取控管。大規模使用 mTLS 的主要挑戰之一，是管理所有目標工作負載的金鑰和憑證。Cloud Service Mesh 會負責輪替網格工作負載的 mTLS 金鑰和憑證，不會中斷通訊。您可以設定較短的憑證重新整理間隔，以降低風險。
Cloud Service Mesh 憑證授權單位
Cloud Service Mesh 包含代管的多區域私人憑證授權單位，即 Cloud Service Mesh 憑證授權單位，用於核發 mTLS 憑證。Cloud Service Mesh 憑證授權單位是高度可靠且可擴充的服務，已針對雲端平台上的動態擴充工作負載進行最佳化調整。使用 Cloud Service Mesh 憑證授權單位時，Google 會管理 CA 後端的安全性和可用性。Cloud Service Mesh 憑證授權單位可讓您在叢集間使用單一信任根。使用 Cloud Service Mesh 憑證授權單位時，您可以依賴工作負載身分集區提供粗略的隔離。根據預設，如果用戶端和伺服器不在同一個 workload identity pool，驗證就會失敗。
Cloud Service Mesh 憑證授權單位核發的憑證包含下列應用程式服務資料：
- Google Cloud 專案 ID
- GKE 命名空間
- GKE 服務帳戶名稱
憑證授權單位服務
除了 Cloud Service Mesh 憑證授權單位，您也可以將 Cloud Service Mesh 設為使用憑證授權單位服務，這適用於下列用途：
- 如需不同的憑證授權單位，在不同叢集簽署工作負載憑證。
- 您需要將簽署金鑰備份至代管 HSM。
- 如果您所處的產業受到嚴格監管，且必須遵守法規。
- 如要將 Cloud Service Mesh CA 鏈結至自訂企業根憑證，以便簽署工作負載憑證。
Cloud Service Mesh 憑證授權單位的費用已包含在 Cloud Service Mesh 定價中。CA 服務的費用不包含在 Cloud Service Mesh 基本價格中，會另外收取。此外，CA 服務有明確的服務水準協議，但 Cloud Service Mesh 憑證授權單位沒有。
整合時，Cloud Service Mesh 中的所有工作負載都會獲得兩個 IAM 角色：
身分感知存取控管 (防火牆) 政策
透過 Cloud Service Mesh，您可以設定以 mTLS 身分識別為依據的網路安全政策，而非對等互連的 IP 位址。這樣一來，您就能建立與工作負載網路位置無關的政策。僅支援同一 Google Cloud 專案中叢集之間的通訊。
要求宣告感知存取控管 (防火牆) 政策
除了 mTLS 身分之外，您也可以根據 HTTP 或 gRPC 要求 JWT 標頭中的要求聲明授予存取權。Cloud Service Mesh 可讓您聲明 JWT 是由受信任的實體簽署。也就是說，您可以設定政策，只允許特定用戶端存取，前提是要求聲明存在或符合指定值。
透過 Identity-Aware Proxy 驗證使用者身分
您可以使用 Identity-Aware Proxy (IAP)，驗證存取 Cloud Service Mesh 輸入閘道上公開服務的使用者。IAP 可驗證透過瀏覽器登入的使用者、整合自訂身分識別提供者，以及核發短期 JWT 權杖或 RCToken，然後透過 Ingress 閘道或下游服務 (使用 Sidecar) 授予存取權。詳情請參閱「將 IAP 與 Cloud Service Mesh 整合」。
使用現有的識別資訊提供者驗證使用者身分
您可以將現有的身分提供者與 Cloud Service Mesh 整合，為已部署的工作負載提供瀏覽器型使用者驗證和存取控管機制。詳情請參閱「設定 Cloud Service Mesh 使用者驗證」。
存取記錄和監控
Cloud Service Mesh 可確保存取記錄和指標在 Google Cloud Observability 中可用，並提供整合式資訊主頁，根據這些資料瞭解服務或工作負載的存取模式。
符合 FIPS 標準
資料層元件使用通過 FIPS 140-3 驗證的加密模組。
限制
Cloud Service Mesh 安全性有下列限制：
- 使用 IAP 進行使用者驗證時，必須將服務發布至網際網路。透過 IAP 和 Cloud Service Mesh，您可以設定政策，限制只有授權使用者和用戶端能存取允許的 IP 範圍。如果選擇只向同一網路中的用戶端公開服務，則必須設定自訂政策引擎，用於使用者驗證和權杖核發。