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) 攻擊。
  • 嘗試入侵及操控服務，以便對其他服務發動攻擊的殭屍網路攻擊。

攻擊也可以根據攻擊目標分類：

  • 內部網路攻擊。攻擊目標是竄改、竊聽或偽造網格內部服務對服務或服務對控制層的通訊。
  • 控制層攻擊。攻擊目標是讓控制層發生故障 (例如拒絕服務攻擊)，或從控制層竊取機密資料。
  • 網格邊緣攻擊。攻擊目標是竄改、竊聽或偽造網格輸入或輸出時的通訊。
  • 網格運算攻擊。針對網格運算的攻擊。攻擊者可能會嘗試取得提升權限，以便在網格中執行惡意操作，例如修改安全性政策和工作負載映像檔。

安全性風險

除了安全攻擊之外，網狀架構也可能面臨其他安全風險。以下列出幾個可能的安全性風險：

  • 安全防護措施不完整。服務網格未設定驗證和授權政策來保護安全性。舉例來說，您未為網格中的服務定義任何驗證或授權政策。
  • 安全性政策例外狀況。為因應特定用途，使用者可以為特定流量 (內部或外部) 建立安全性政策例外狀況，將其排除在 Cloud Service Mesh 安全性政策之外。如要安全地處理這類情況，請參閱「安全地處理政策例外狀況」一節。
  • 未升級圖片。系統可能會發現網格中使用的圖片有安全漏洞。您必須將網格元件和工作負載映像檔更新至最新的安全漏洞修正版本。
  • 缺乏維護 (缺乏專業知識或資源)。網格軟體和政策設定需要定期維護，才能充分發揮最新安全防護機制的效用。
  • 無法掌握情況。網狀政策設定錯誤或不安全，以及網狀流量/作業異常，不會通知網狀管理員。
  • 設定偏移。網格中的政策設定與可靠資料來源不符。

保護服務網格的措施

本節將提供服務網格安全性的操作手冊。

安全架構

服務網格的安全性取決於網格系統及其應用程式不同層級的元件安全性。建議的 Cloud Service Mesh 安全性態勢，其高層意圖是透過在不同層級整合多個安全機制，保護服務網格，共同在零信任安全性模型下達成整體系統安全性。下圖顯示建議的 Cloud Service Mesh 安全性態勢。

Cloud Service Mesh 的安全防護機制

Cloud Service Mesh 提供多層安全防護，包括：

  • 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) 會強制執行工作負載對工作負載的流量加密和驗證。
    • 代管 CA (例如 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 加密及驗證，且不允許純文字流量。

您可以使用 Cloud Service Mesh 設定工作負載之間 TLS 連線的最低 TLS 版本，以符合安全性和法規遵循要求。

詳情請參閱「Cloud Service Mesh 範例：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 金鑰集 (JWKS) 端點驗證 JWT。JWT 驗證機制可套用至輸入閘道 (針對外部流量) 或內部服務 (針對網格內流量)。如果 JWT 用於代表終端呼叫端的憑證，且要求的服務需要證明是代表終端呼叫端進行呼叫，則可以將 JWT 驗證與 mTLS 驗證結合。強制執行 JWT 驗證，可防範攻擊者在沒有有效憑證的情況下，代表實際使用者存取服務。

Cloud Service Mesh 使用者驗證

Cloud Service Mesh 使用者驗證是一項整合式解決方案，可為工作負載提供以瀏覽器為基礎的使用者驗證和存取權控管功能。這項服務會將服務網狀結構與現有的身分識別提供者 (IdP) 整合，以便實作標準的網路版 OpenID Connect (OIDC) 登入和同意流程，並使用 Cloud Service Mesh 授權政策進行存取權控管。

強制執行授權政策

Cloud Service Mesh 授權政策可控管下列項目：

  • 允許存取服務的使用者或物件。
  • 可存取哪些資源。
  • 可對允許的資源執行哪些作業。

授權政策是一種多用途的方式，可根據服務執行的實際身分、流量的應用程式層 (第 7 層) 屬性 (例如要求標頭)，以及 IP 範圍和連接埠等網路層 (第 3 層和第 4 層) 屬性，設定存取權控管。

應根據驗證結果產生的已驗證身分，強制執行 Cloud Service Mesh 授權政策，以防範服務或資料遭到未經授權的存取。

根據預設，系統應拒絕服務存取權，除非明確定義授權政策，允許存取服務。如需拒絕存取要求的授權政策範例，請參閱「授權政策最佳做法」。

授權政策應盡可能限制信任。舉例來說，您可以根據服務公開的個別網址路徑定義服務存取權，例如只允許服務 A 存取服務 B 的路徑 /admin。

授權政策可與 Kubernetes 網路政策搭配使用，後者只會在網路層 (第 3 層和第 4 層) 運作，並控管 Kubernetes Pod 和 Kubernetes 命名空間上 IP 位址和連接埠的網路存取權。

強制執行存取網格服務的權杖交換程序

為了防範權杖重播攻擊，竊取權杖並重複使用竊取的權杖存取網狀網路服務，網狀網路邊緣應將網狀網路外部要求中的權杖，換成短效的網狀網路內部權杖。

網格服務必須驗證並授權網格外部存取網格服務的要求，因此要求中必須包含 JWT 或 Cookie 等權杖。來自網格的符記可能會保留很長一段時間。為防範權杖重送攻擊，您應將來自網格外部的權杖，換成網格內部短期權杖，並在網格輸入端限制其範圍。網格服務會驗證網格內部權杖，並根據網格內部權杖授權存取要求。

後續步驟