Cloud Service Mesh 安全性最佳做法
本文說明如何建立及控管在 Google Kubernetes Engine (GKE) 上執行的安全 Cloud Service Mesh 設定，並提供相關最佳做法。本文件提供的指引不只說明如何設定及安裝 Cloud Service Mesh，也介紹如何搭配使用 Cloud Service Mesh 與其他產品和功能，防範網格中應用程式可能面臨的安全威脅。 Google Cloud
這份文件適用於管理 Cloud Service Mesh 政策的管理員，以及在 Cloud Service Mesh 中執行服務的使用者。對於需要提升服務網格安全性以符合法規遵循需求的機構，本文所述的安全措施也很有幫助。
本文的編排方式如下：
簡介
Cloud Service Mesh 提供各種功能和工具，協助您以統一方式觀察、管理及保護服務。這項服務以應用程式為中心，並使用受信任的應用程式身分，而非以網路 IP 為中心。您可以透明地部署服務網格，不必修改現有的應用程式程式碼。Cloud Service Mesh 可對網路行為進行宣告式控制，有助於將負責交付及發布應用程式功能的團隊工作，與負責安全性和網路的管理員職責分開。
Cloud Service Mesh 以開放原始碼的 Istio 服務網格為基礎，可進行精密的設定和拓撲。視貴機構的架構而定，可能由一或多個團隊或角色負責安裝及設定網格。系統會選擇預設的 Cloud Service Mesh 設定來保護應用程式，但在某些情況下，您可能需要自訂設定或授予例外狀況，方法是從網格中排除特定應用程式、連接埠或 IP 位址。因此，請務必採取控管措施，管理網格設定和安全性例外狀況。
攻擊媒介和安全風險
攻擊向量
Cloud Service Mesh 安全性遵循零信任安全模型，假設安全威脅來自機構安全邊界內外。可能威脅服務網格中應用程式的安全攻擊類型包括：
- 資料竊取攻擊。舉例來說，攻擊者可能會竊聽服務對服務流量中的機密資料或憑證。
- 中間人攻擊。舉例來說，惡意服務可能會偽裝成合法服務，藉此取得或修改服務之間的通訊內容。
- 權限提升攻擊。舉例來說，攻擊者可能會非法取得網路中的高權限，然後進行作業。
- 阻斷服務 (DoS) 攻擊。
- 殭屍網路攻擊，企圖入侵及操控服務，對其他服務發動攻擊。
您也可以根據攻擊目標將攻擊分類：
- 防範內部網路攻擊。攻擊目標是竄改、竊聽或偽造網格內部服務對服務或服務對控制層的通訊。
- 控制層攻擊。攻擊目的是要造成控制層故障 (例如 DoS 攻擊)，或是從控制層竊取機密資料。
- 網狀網路邊緣攻擊。攻擊目的是要竄改、竊聽或偽造網格輸入或輸出端的通訊內容。
- 網格作業攻擊。針對網格作業的攻擊。攻擊者可能會嘗試取得進階權限，在網格中執行惡意作業，例如修改安全政策和工作負載映像檔。
安全性風險
除了安全攻擊，網狀架構也面臨其他安全風險。以下列出幾種可能的安全性風險：
- 安全防護不完整。服務網格尚未設定驗證和授權政策，無法保護安全。舉例來說，網格中的服務未定義任何驗證或授權政策。
- 安全性政策例外狀況。為配合特定用途，使用者可以為特定流量 (內部或外部) 建立安全性政策例外狀況，將這些流量從 Cloud Service Mesh 安全性政策中排除。如要安全地處理這類情況，請參閱「安全地處理政策例外狀況」一節。
- 忽略圖片升級。網格中使用的映像檔可能會發現安全漏洞。您必須將網格元件和工作負載映像檔更新至最新版本，才能取得最新的安全漏洞修正程式。
- 缺乏維護 (沒有專業知識或資源)。網狀架構軟體和政策設定需要定期維護，才能運用最新的安全防護機制。
- 無法掌握情況。網格政策設定錯誤或不安全，以及網格流量/作業異常，都不會通知網格管理員。
- 設定漂移。 網格中的政策設定與可靠資料來源不一致。
保護服務網格的措施
本節將提供服務網格安全性的操作手冊。
安全架構
服務網格的安全性取決於網格系統和應用程式不同層級的元件安全性。建議的 Cloud Service Mesh 安全性態勢，其高階意圖是透過在不同層級整合多種安全機制，確保服務網格安全無虞，在零信任安全模型下共同實現整體系統安全。下圖顯示建議的 Cloud Service Mesh 安全性狀態。
Cloud Service Mesh 提供多層安全防護，包括：
- 網格邊緣安全性
- Cloud Service Mesh 入口安全防護功能可控管外部流量的存取權，並確保外部存取網格中服務公開的 API 時安全無虞。
- Cloud Service Mesh 輸出安全防護功能可控管內部工作負載的輸出流量。
- Cloud Service Mesh 使用者驗證 與 Google 基礎架構整合，可驗證從網頁瀏覽器到執行網頁應用程式的服務， 所發出的外部呼叫。
- Cloud Service Mesh 閘道憑證管理功能會使用憑證授權單位服務，保護及輪替 Cloud Service Mesh 輸入和輸出閘道使用的私密金鑰和 X.509 憑證。
- Cloud Armor 可防範外部分散式阻斷服務 (DDoS) 和第 7 層攻擊。這項服務可做為網頁應用程式防火牆 (WAF)，保護網格免於網路攻擊。例如，注入和遠端程式碼執行攻擊。
- VPC 和 VPC Service Controls 可透過私人網路存取控管機制，保護網格邊緣。
- 叢集安全性
- Cloud Service Mesh 雙向傳輸層安全標準 (mTLS) 會強制執行工作負載對工作負載的流量加密和驗證。
- 代管的憑證授權單位 (例如 Cloud Service Mesh 憑證授權單位和憑證授權單位服務) 會安全地佈建及管理工作負載使用的憑證。
- Cloud Service Mesh 授權會根據網格服務的身分和其他屬性，強制執行存取權控管。
- GKE Enterprise 安全性資訊主頁可監控工作負載的安全政策和 Kubernetes 網路政策設定。
- Kubernetes 網路政策會根據 IP 位址、Pod 標籤、命名空間等，強制執行 Pod 存取權控管。
- 控制層安全防護功能可防範控制層遭受攻擊。這項防護措施可防止攻擊者修改、利用或洩漏服務和網格設定資料。
- 工作負載安全防護
- 請隨時掌握 Cloud Service Mesh 安全性版本，確保網格中執行的 Cloud Service Mesh 二進位檔沒有公開已知的安全漏洞。
- Workload Identity Federation for GKE 可讓工作負載取得憑證，安全地呼叫 Google 服務。
- Kubernetes CNI (容器網路介面) 可避免權限提升攻擊，因為不需要使用具備權限的 Cloud Service Mesh 初始化容器。
- 操作人員安全
- Kubernetes 角色型存取權控管 (RBAC) 會限制 Kubernetes 資源的存取權，並限制運算子權限，以防範惡意運算子或運算子模擬行為發動攻擊。
- GKE Enterprise Policy Controller 會驗證及稽核網格中的政策設定，防止設定錯誤。
- Google Cloud 二進位授權可確保網格中的工作負載映像檔是管理員授權的映像檔。
- Google Cloud 稽核記錄會稽核網格作業。
下圖顯示 Cloud Service Mesh 中整合式安全解決方案的通訊和設定流程。
叢集安全性
啟用嚴格的雙向 TLS
中間人 (MitM) 攻擊會試圖在兩個通訊方之間插入惡意實體，藉此竊聽或操控通訊內容。Cloud Service Mesh 會對所有通訊方強制執行雙向傳輸層安全標準 (mTLS) 驗證和加密，防範中間人攻擊和資料竊取攻擊。寬鬆模式會在雙方都支援 mTLS 時使用 mTLS，但允許不使用 mTLS 的連線。相較之下，嚴格 mTLS 要求流量必須透過 mTLS 加密及驗證，且不允許純文字流量。
Cloud Service Mesh 可讓您設定 TLS 連線的最低 TLS 版本，確保工作負載之間的 TLS 連線符合安全性和法規遵循要求。
詳情請參閱「Anthos Service Mesh by example: mTLS | Enforcing mesh-wide mTLS」(Anthos 服務網格範例：mTLS | 強制執行網格範圍的 mTLS)。
啟用存取控管
除非有充分理由將服務或 Pod 排除在 Cloud Service Mesh 安全性政策之外，否則應對進出網格的所有流量強制執行 Cloud Service Mesh 安全性政策 (例如驗證和授權政策)。在某些情況下，使用者可能基於正當理由，需要略過部分連接埠和 IP 範圍的 Cloud Service Mesh 安全性政策。舉例來說，如要與 Cloud Service Mesh 未管理的服務建立原生連線，如要在這類用途下保護 Cloud Service Mesh，請參閱「安全地處理 Cloud Service Mesh 政策例外狀況」。
服務存取權控管對於防止未經授權存取服務至關重要。強制執行 mTLS 會加密及驗證要求，但網格仍需Cloud Service Mesh 授權政策，才能對服務強制執行存取權控管。舉例來說，拒絕來自已驗證用戶端的未授權要求。
Cloud Service Mesh 授權政策提供彈性的方式來設定存取控管，防範未經授權的存取行為。Cloud Service Mesh 授權政策應根據驗證結果 (mTLS 或 JSON Web Token (JWT) 驗證) 衍生的已驗證身分強制執行，並一併做為 Cloud Service Mesh 授權政策的一部分。
強制執行 Cloud Service Mesh 驗證政策
JSON Web Token (JWT)
除了 mTLS 驗證，網格管理員也可以要求服務根據 JWT 驗證及授權要求。 Cloud Service Mesh 不會做為 JWT 提供者，但會根據設定的 JSON Web Key Set (JWKS) 端點驗證 JWT。JWT 驗證可套用至外部流量的輸入閘道，或網格內流量的內部服務。當 JWT 用於代表最終呼叫端，且所要求的服務需要證明是代表最終呼叫端呼叫時，JWT 驗證可以與 mTLS 驗證合併使用。強制執行 JWT 驗證可防範這類攻擊，避免攻擊者在沒有有效憑證的情況下，代表真實使用者存取服務。
Cloud Service Mesh 使用者驗證
Cloud Service Mesh 使用者驗證是整合式解決方案，可為工作負載提供以瀏覽器為基礎的使用者驗證和存取權控管。這項服務會將服務網格與現有的身分識別提供者 (IdP) 整合，實作標準的網頁式 OpenID Connect (OIDC) 登入和同意流程，並使用 Cloud Service Mesh 授權政策進行存取權控管。
Cloud Service Mesh 授權政策可控管：
- 允許誰或哪些項目存取服務。
- 可存取的資源。
- 可對允許的資源執行哪些作業。
授權政策是一種多用途的存取權控管設定方式，可根據服務實際執行的身分、流量的應用程式層 (第 7 層) 屬性 (例如要求標頭)，以及網路層 (第 3 層和第 4 層) 屬性 (例如 IP 範圍和連接埠) 進行設定。
應根據驗證結果衍生的已驗證身分，強制執行 Cloud Service Mesh 授權政策，防範未經授權存取服務或資料。
根據預設，除非明確定義授權政策來允許存取服務，否則應拒絕存取服務。如要查看拒絕存取要求的授權政策範例，請參閱「授權政策最佳做法」。
授權政策應盡可能限制信任關係。舉例來說，您可以根據服務公開的個別網址路徑定義服務存取權，這樣只有服務 A 可以存取服務 B 的路徑 /admin。
授權政策可與 Kubernetes 網路政策搭配使用，後者只會在網路層 (第 3 層和第 4 層) 運作，並控管 Kubernetes Pod 和 Kubernetes 命名空間中 IP 位址和連接埠的網路存取權。
強制執行權杖交換，以存取網格服務
為防範權杖重送攻擊 (這類攻擊會竊取權杖，並重複使用竊取的權杖來存取網格服務)，來自網格外部的要求中的權杖應在網格邊緣交換為短期網格內部權杖。
如要從網格外部存取網格服務，要求必須包含權杖 (例如 JWT 或 Cookie)，才能通過網格服務的驗證和授權。網狀網路外部的權杖可能具有長期效力。為防範權杖重送攻擊，來自網格外部的權杖應在網格的輸入端，換成範圍有限的短期網格內部權杖。網格服務會驗證網格內部權杖，並根據網格內部權杖授權存取要求。