VMware Engine 安全性的最佳做法

本文說明管理及設定 Google Cloud VMware Engine 時，建議採用的安全性最佳做法，適合已熟悉 VMware Engine 的使用者。如果您是新手，建議先瞭解必要條件和 VMware Engine 安全性。

VMware Engine 採用共責式安全性模型。如要確保雲端安全無虞，客戶和 Google (服務供應商) 必須共同承擔責任。遵循這些最佳做法可協助您節省時間、避免錯誤，並減輕故障點的影響。

VMware Engine 網路

下列各節將介紹 VMware Engine 環境中的網路最佳做法。

找出並瞭解環境中的所有流量

VMware Engine 會運用 VMware Engine 網路和虛擬私有雲對等互連，將 VMware Engine 私有雲網路的私有網路連線，連至您的虛擬私有雲網路。來自Google Cloud 環境中虛擬私有雲或地端部署網路的連入流量，會經過 Google 管理的獨立租用環境網路。

使用 VMware Engine 的公開 IP 服務進行網際網路資料移轉

網際網路流量可透過 VMware Engine 的公開 IP 服務直接進入私有雲。或者，網際網路流量也可以透過 Google Cloud的公用負載平衡器進入。在這種情況下，流量會像其他任何傳入流量一樣進行路由。請注意，這些選項互斥。如果需要對網際網路流量進行自訂控制，例如網址篩選、IPS/IDS 或流量檢查 (由 Google Cloud 環境中的中央執行個體或服務提供)，您應透過虛擬私有雲網路傳送網際網路流量。

如果這不適用於您，或您已在私有雲中實作控制項，建議您在 VMware Engine 中加入外部 IP 位址服務。此外，建議您使用外部存取規則，拒絕來自網際網路且不適用於您應用程式的流量模式。

在 VMware Engine NSX 的閘道和分散式防火牆上，分別設定南北向和東西向防火牆規則

在第 1 層邏輯路由器上，設定 NSX 中的分散式防火牆 (DFW)，區隔虛擬第 2 層網域之間的內部流量。NSX DFW 的設計目的是處理區隔之間的 (內部) 東西向網路流量，並允許防火牆規則，允許和拒絕區隔內個別執行個體之間的流量。

如要進行精細的網路存取控管，請務必在 DFW 上套用受限的預設政策，根據預設拒絕執行個體之間的網路流量。使用 DFW 具體允許應用程式之間，以及應用程式內服務之間的流量。

設定 NSX 閘道防火牆，控管進出私有雲的南北向流量。

NSX 閘道防火牆用於控管南北向流量，建議用於控管周邊流量，以進入其他安全區域等用途。如要為整個私有雲持續設定南北向流量，請在第 0 層路由器上設定閘道防火牆。如要為每個 NSX 區隔設定南北向流量，請在第 1 層路由器上設定閘道防火牆。

除了 NSX 防火牆，我們建議您使用 VPC 防火牆，允許及封鎖 VMware Engine 私有雲中的工作負載與 VPC 中的工作負載之間的東向/西向流量。從 VMware Engine 工作負載傳輸至 Compute Engine 執行個體的輸入資料，應預設受到限制，僅允許主動開啟的流量。

使用虛擬私有雲防火牆，從虛擬私有雲封鎖傳輸至管理裝置和 vSphere/vSAN CIDR 範圍的出站資料。只允許網路中信任的主機和 IP 位址，將輸出資料傳輸至管理裝置。請注意，管理裝置不在 NSX 區隔內，因此 DFW 規則不適用於限制存取權。

在 NSX 中套用零信任安全原則和微區隔機制

使用 NSX DFW 為安全區隔實作流量控管，精細程度可達個別虛擬機器。預設拒絕保護個別 VM 之間流量的這項原則，通常也稱為「微區隔」，與在第 3 層網域之間實作傳統防火牆相比，這種做法的防火牆更精細。

DFW 會在私有雲中所有 VMware Engine vSphere 主機的 Hypervisor 核心中啟用，並控管相同或不同 NSX 區隔中工作負載之間的流量。如要定義允許 VM 往來流量的防火牆規則，可以將 VM 分組到政策群組，這些群組可採用彈性的成員資格條件，例如 VM 標記或名稱比對。

微區隔可讓您實作精細的流量控制網路，明確允許流量模式。所有網路流量都由身分和裝置驗證程序控管，而非隱含信任，這種安全概念通常也稱為「零信任安全」。

從 Cloud Marketplace 入口網站部署第三方防火牆設備，取得 IPS/IDS 功能

如需進階第 7 層安全防護，包括從網路其餘部分或 NSX 網路區隔之間傳入私有雲的流量入侵偵測系統/入侵防禦系統功能，請考慮部署第三方防火牆設備。您可以將第三方設備部署為 Google Cloud 網路中兩個 VPC 之間的多 NIC 設備，也可以部署在私有雲中，並與 NSX 整合。

如要深入瞭解 VMware Engine 架構 (採用集中式裝置，可用於各種進階安全用途，例如 IPS/IDS、DDoS、SSL 卸載等)，請參閱 Cloud Architecture Center 的「使用集中式裝置的網路安全」文件。

使用 Google Cloud Armor 保護 VMware Engine 上的網路服務，防範 DDoS 攻擊

如果透過客戶 VPC 將連入流量路由至 VMware Engine 上的工作負載，建議您將 VMware Engine 工作負載放在 Cloud Service Mesh 後方的混合式網路端點群組中，並善用外部 HTTP(S) 負載平衡器。無論採用哪種設定，您都可以為面向公眾的應用程式加入 Google Cloud Armor，防範 DDoS 攻擊和 SQL 注入或跨網站指令碼攻擊等常見安全漏洞。

如果您需要使用 Envoy Proxy 進行進階流量管理，或是整合憑證授權單位服務等 Cloud Service Mesh 功能，建議使用 Cloud Service Mesh。在其他情況下，我們建議使用外部 HTTP(S) 負載平衡器。

請參閱說明文件，瞭解如何在下列任一設定中，將 VMware Engine 工作負載新增至混合式 NEG：

在沒有網際網路存取權的情況下，以私密方式連線至 Google Cloud 服務

VMware Engine 私有雲工作負載可使用 Private Google Access 存取 API，例如 Cloud Storage API。 Google Cloud建議您使用 Private Google Access 存取 Google 服務，不必透過網際網路傳送流量，因為這樣可降低輸出資料移轉費用和延遲時間。此外，如果工作負載只需要 Google API 存取權，就不需要網際網路的網路路徑。如要瞭解更多技術細節和設定步驟，請深入瞭解 Private Google Access。

同樣地，如果 VMware Engine 工作負載需要存取服務供應商網路的Google Cloud 資源 (例如 Cloud SQL 或 Memorystore 執行個體)，則應使用 PSA 透過私有連線連線。詳情請參閱 VMware Engine 的 PSA 一節。

加密地端部署環境與 Google Cloud之間的通訊

VMware Engine 上的工作負載如需與地端部署系統通訊，應透過加密管道連線。建議您採用多層式方法，加密地端部署資料中心和Google Cloud之間傳輸的資料。地端部署系統與 Google Cloud之間的連結可以透過設定 Cloud VPN 和 IPsec 通道加密，也可以使用互連網路 VLAN 連結的內建 IPsec 加密。此外，應用程式元件之間應使用 TLS 啟用應用程式層加密。

使用 VPC Service Controls 防範資料遭竊

建議使用 VPC Service Controls 降低資料竊取的風險，方法是將 Cloud Storage 值區和 BigQuery 資料集等機密資源放入 VPC Service Controls 範圍。需要存取安全範圍內資料的工作負載也必須置於安全範圍內。具體來說，託管私有雲的 Google Cloud 專案必須屬於 VPC Service Controls 範圍，才能存取受 VPC Service Controls 保護的資源。

您需要在 VPC Service Controls 設定中設定輸入和輸出資料移轉政策，允許 VMware Engine 生產者服務 API 進入 perimeter。如需詳細設定指南，請參閱 VMware Engine 適用的 VPC Service Controls 說明文件頁面。

VMware Engine IAM 和權限

以下各節將介紹 VMware Engine 環境中使用者權限的最佳做法。請務必留意 VMware Engine 環境和 Google Cloud 部署私有雲的專案中的權限。

使用預先定義的角色或自訂角色授予存取權

您可以使用與其他 VMware Engine 環境相同的方式，運用 VMware Engine 方法來管理 vSphere 角色和權限。不過，部署叢集等活動需要 Identity and Access Management (IAM) 權限。下表列出相關存取權管理員、他們授予權限的身分來源，以及他們啟用的範例活動。

平台 元件 識別資訊來源如何設定權限 活動範例
Google Cloud VMware Engine 入口網站 Cloud Identity Identity and Access Management 例如私有雲部署和取消、叢集部署和取消。
VMware Engine vCenter LDAP vCenter 使用者介面中的主機和叢集、VM 和資料夾、資料儲存庫 例如建立 VM、建立 VM 資料夾、建立及刪除資料存放區物件
NSX LDAP NSX Manager 使用者介面中的「使用者和角色」 例如建立 NSX 區隔、設定防火牆和負載平衡器。
vCenter VM 訪客作業系統 例如 Active Directory、LDAP、本機使用者 訪客作業系統 SSH 或 RDP 登入、檔案作業 (例如)

在 Google Cloud IAM 中，有兩個預先定義的角色具有 VMware Engine 入口網站的權限：

  • VMware Engine 服務管理員：具備 Google Cloud上 VMware Engine 服務的完整存取權。
  • VMware Engine 服務檢視者：提供 Google Cloud上 VMware Engine 服務的唯讀存取權。

這些權限與 VMware Engine 入口網站中的動作相關，與 API 或 CLI 中的動作無關。請注意，基本角色也包含管理 VMware Engine 服務 (擁有者、編輯者) 或查看服務詳細資料 (檢視者) 的權限。一般而言，建議您使用預先定義角色，而非基本角色，因為預先定義角色提供更精細的權限。

使用 API 或 CLI 透過服務帳戶以程式輔助方式存取 VMware Engine 時，應使用預先定義的角色或自訂角色加以限制，因為這些角色包含更精細的權限，僅適用於 VMware Engine。如果程式輔助存取權僅用於需要預先定義角色特定權限子集的工作，建議您建立自訂角色。

在機構的資源階層中，為 IAM 角色指派作業選擇適當位置。如果您只在一個專案中執行所有 VMware Engine 私有雲，則只能在專案層級指派角色。如果技術或機構需求導致私有雲位於不同專案，請在私有雲所用專案的共用資料夾中，定義必要角色。

如果活動只需要在 vCenter、NSX 或 HCX 內完成，則不需要 Cloud IAM 權限。如果員工只需要操作這些環境，就不需要先前列出的 IAM 角色。他們應改用 LDAP 身分，並在 vCenter 和 NSX 中設定權限。建議您只為極少數使用者提供 VMware Engine 服務管理員或 VMware Engine 服務檢視者角色，因為這些角色會授予 vCenter 的 CloudOwner 使用者帳戶和 NSX 的管理員使用者帳戶存取權。這些使用者帳戶僅適用於初始設定或緊急程序。

限制並主動稽核管理員存取權

VMware Engine 服務管理員角色權限極高，因此只能指派給需要管理 VMware Engine 私有雲和叢集生命週期的使用者。一般來說，手動新增或刪除叢集和節點並非經常執行的動作，但可能會對帳單或叢集可用性造成重大影響。請只將這個角色指派給貴機構中的少數使用者。

請務必定期稽核已指派 VMware Engine 服務管理員角色的人員，無論是直接在用於 VMware Engine 的專案中，或是在資源階層的其中一個父項層級。這項稽核應包含其他角色，例如基本編輯者和擁有者角色，這些角色包含與 VMware Engine 相關的重要權限。您可以使用 IAM 角色建議工具等服務，找出權限過高的角色。

設定 LDAP 或 Active Directory 識別資訊來源

您應設定支援 LDAP 驗證的識別資訊提供者 (例如 Active Directory)，以便為 vCenter 和 NSX Manager 啟用使用者驗證。建議您採用這種做法，集中管理身分生命週期、群組和密碼等。請注意，系統不支援直接將 vCenter 和 NSX 加入 Active Directory，以進行整合式 Windows 驗證。

輪替內建服務帳戶的密碼

VMware Engine 會產生憑證，用於存取私有雲中的管理設備 (例如 vCenter、NSX 和 HCX)。建議您建立程序，輪替預設 vCenter 服務帳戶 CloudOwner@gve.local 和預設 NSX 服務帳戶管理員的密碼。這兩個使用者帳戶都只能用於初始設定和緊急程序，且密碼應定期輪替 (例如每 60 或 90 天)。同樣地，請定期輪替解決方案使用者帳戶的密碼，這些帳戶通常用於整合第三方工具。服務帳戶密碼輪替頻率越高，惡意行為人找到密碼時，密碼就越不可能仍然有效。

VMware Engine 記錄與監控

以下各節將介紹 VM 工作負載和 VMware Engine 基礎架構的記錄與監控最佳做法，後者提供工作負載使用的資源。

擷取 VMware Engine 記錄和指標

許多機構都想在集中式「單一玻璃窗」中收集及分析記錄。在 Google Cloud，Cloud Logging 和 Cloud Monitoring 產品提供可用於集中管理記錄和指標的服務。VMware Engine 可透過獨立代理程式與 Cloud Monitoring 整合。在此設定中，vCenter 會將 ESXi CPU 和記憶體使用率等指標轉送至 Cloud Monitoring。建議您根據 vCenter 轉送的指標建立資訊主頁，或使用 GitHub 上發布的範例資訊主頁。

如要收集平台記錄，VMware Engine 私有雲可將系統記錄檔轉送至集中式記錄彙整器。這項作業適用於 vCenter 和 NSX Syslog 訊息。收集、保留及分析 vCenter 的 Syslog 訊息，可用於重要的安全性用途，例如根據管理員使用者 (或緊急使用者) 登入活動發出即時快訊，但這類活動僅應在特殊情況下執行。如要分析系統記錄檔訊息，必須設定系統記錄檔匯總工具 (例如 Fluentd 或獨立代理程式)，將訊息轉送至 Cloud Logging。

建議您在單一專案的中央資訊主頁中，分析 VMware Engine 的記錄。如果 VMware Engine 環境涵蓋多個專案，您還需要設定記錄接收器和監控範圍，彙整專案。

使用 Cloud Logging 代理程式記錄工作負載 VM

VMware Engine 工作負載 VM 可以使用 Logging 代理程式，直接將記錄傳送至 Cloud Logging API。Logging 代理程式以 fluentd 為基礎，會將常見的第三方應用程式和系統軟體的記錄檔串流至 Cloud Logging。最佳做法是，針對 VMware Engine 上的工作負載 VM 收集及分析記錄檔時，採用與 Compute Engine 執行個體和地端部署資產 (如適用) 相同的做法。在 VMware Engine 上使用 Logging 代理程式的方式，與在 Compute Engine VM 上使用的方式相同，因此這兩個平台上的工作負載都會將記錄傳送至 Cloud Logging。

套用資料存取透明化控管機制和 Access Approval 政策的同等功能

雖然 VMware Engine 不支援 Google Cloud中的資料存取透明化控管機制 (AxT) 和存取核准 (AxA)，但我們已實作具備同等功能的程序，可應要求啟用。

如要達到資料存取透明化控管機制同等程度的保護，您需要考量多個記錄來源，包括：

  • vCenter 記錄檔 - 可使用遠端系統記錄檔伺服器設定匯出。
  • ESXi 記錄：可使用遠端系統記錄設定收集，但您需要向 Google Cloud 提出支援要求，才能設定 ESXi 系統記錄轉送。

如果您有嚴格的法規要求，我們會實施一項政策，提供同等的存取核准功能。根據這項政策，標準服務作業必須產生支援單，並說明存取服務營運商需要存取權的原因。

Google Cloud 存取權核准 排除條件 適用。

VMware Engine 加密

以下各節將介紹私有雲儲存空間加密的最佳做法，以及選擇私有雲金鑰供應商時應考量的驅動因素。

使用 Google-owned and managed key 已啟用 vSAN 靜態資料加密的供應商

靜態資料加密是透過 vSAN 軟體加密實作。根據預設，VMware Engine 會在每個 ESXi 叢集上啟用 vSAN 加密，並在 vCenter 中設定預設金鑰供應商。Google 要求客戶在 ESXi 叢集上啟用 vSAN 加密，停用 vSAN 加密會違反 VMware Engine 的服務條款。許多機構都要求靜態資料加密，這是公司政策的一部分，或受到法規約束，必須加密資料 (例如 NIST、FIPS)。

每個 ESXi 主機都會使用標準 AES-256 XTS 模式，以及隨機產生的不同資料加密金鑰 (DEK) 加密資料。DEK 會使用金鑰加密金鑰 (KEK) 加密，且只會以加密形式儲存在磁碟上。vCenter 伺服器只會儲存 KEK 的 ID，不會儲存 KEK 本身，KEK 會儲存在 Cloud Key Management Service (KMS) 中。您可以選擇 Cloud KMS 的位置，用來存放 KEK。

建議您使用 Google 管理的預設金鑰供應商。不過，如果您必須自行管理 Cloud KMS，可以使用支援廠商提供的第三方 KMIP 1.1 相容 Cloud KMS。在這兩種情況下，金鑰供應商都可以用來加密靜態資料和 vMotion 傳輸中的流量。

下表列出預設金鑰供應商與第三方 Cloud KMS 整合的主要差異：

主要供應商 優點 缺點
預設 Google-owned and managed key 供應商
  • 簡單：開箱即用，無需管理供應商，也不會增加作業負擔
  • Google 提供的端對端支援
  • 最簡單的 DEK/KEK 輪替方法是主要需求
  • 完全不須另外付費
  • 內建可用區備援機制，確保高可用性
  • 無法自備金鑰內容 (BYOK)
  • KEK 會儲存在 Google 基礎架構中並由 Google 管理。系統不支援外部金鑰管理員 (EKM)。
第三方 Cloud KMS 金鑰供應商
  • 完全掌控加密資料和加密金鑰
  • 硬體支援的金鑰可儲存在 HSM 設備中
  • 增加複雜度和營運負擔
  • 額外費用
  • 可能會增加額外延遲，尤其是 SaaS KMS
  • 可能降低供應量

Google 不建議同時啟用 VM 層級加密和 vSAN 資料儲存庫加密，因為加密 VM 的重複資料刪除效率會降至零。

根據貴機構的標準，自動輪替加密金鑰

您必須負責在 VMware Engine vSphere 中輪替 KEK。無論您使用預設金鑰提供者或外部 Cloud KMS，都適用這項規定。您可以從 vCenter 或使用 vCenter API 啟動 KEK 輪替。建議自動輪替 KEK，以符合貴機構的安全性規定。您可以在 GitHub 找到 PowerCLI 指令碼範例。

加密虛擬機器的需求條件

您可以透過預設Google-owned and managed key 供應商或 Cloud Key Management Service，管理 VM 的加密金鑰。

如果您為私有雲中的任何 VM 啟用 VM 加密 (或 vTPM)，並使用 KMS 管理加密金鑰，則在輪替 KMS 金鑰後，必須重新加密 (淺層重新產生金鑰) 每個 VM。

淺層換鎖只會替換金鑰加密金鑰 (KEK)，不會變更 VM 的資料加密金鑰 (DEK)。您通常會在 vSphere Client 中使用「重新加密」動作，觸發淺層換鎖。

在這項作業期間，系統會使用新的 KEK 重新包裝 (重新加密) 現有 DEK。這個程序速度很快，因為不會重寫磁碟上的實際資料，只會更新包含加密 DEK 的小型金鑰組合。詳情請參閱下列 VMware 說明文件：

無法重新設定加密 VM 金鑰的風險

如果您在刪除輪替 (舊) KMS 金鑰版本前，未重新設定加密 VM 的金鑰，可能會導致下列問題：

  • vMotion 失敗：如果您在 KMS 金鑰輪替後，但在執行 VM 換鎖前，重新啟動目的地主機或將目的地主機新增至叢集，ESXi 主機就無法在 vMotion 期間解密 VM DEK。
  • 無法啟動：如果主機重新啟動或清除本機金鑰快取，就無法從 KMS 重新取得金鑰。如果您從 KMS 刪除必要金鑰，主機就無法解密 DEK，導致加密 VM 無法啟動。

對工作負載 VM 執行換鎖作業的步驟

  1. 在 vSphere Client 中，以滑鼠右鍵按一下 VM。
  2. 依序選取「VM Policies」>「Re-encrypt」。
  3. 在隨即顯示的對話方塊中，確認重新加密要求。
  4. 等待工作完成。
  5. 將 VM 遷移至您重新啟動或新增至叢集的主機，確認換鎖是否成功。

VMware Engine 備份和災難復原

保護資料免受勒索軟體、損毀和人為錯誤等威脅至關重要。此外，重要業務應用程式幾乎隨時都需要資料，因此您幾乎沒有時間從突然中斷的服務中復原資料。本節並未完整涵蓋所有備份和災難復原層面，但會提供重要考量，協助您為 VMware Engine 環境選擇合適的策略，有效設計備份和災難復原策略，確保資料安全無虞且隨時可用。

使用備份和災難復原服務備份工作負載

備份和災難復原服務 Google Cloud 提供集中管理的內建備份解決方案，可用於各種用途，包括備份 Compute Engine 和 Google Cloud VMware Engine 上的工作負載。備份和災難復原服務是 Google 建議的單一工作負載備份解決方案，因為這項服務提供多項優勢，例如支援各種工作負載、空間效率高、可永久執行增量備份，以及提供彈性的儲存空間選項。

Google Cloud VMware Engine 也支援使用第三方代理程式型備份解決方案。如果您已擁有第三方備份產品的授權，或許會偏好使用這些解決方案。使用這類工具的前提條件包括：

  • 提供應用程式層級備份
  • 並通過應用程式供應商認證
  • 通過 VMware Engine 的 vSAN 認證
  • 支援 VMware Engine vStorage API for Data Protection (VADP) 通訊協定標準，或採取應用程式層級備份

無論選擇哪種備份解決方案，我們都建議使用 Cloud Storage，因為這是符合成本效益的儲存空間選項，可長期保留備份資料。Cloud Storage 是具備高耐用性及成本效益的物件儲存空間。Cloud Storage bucket 可設定為自動跨多個區域複製儲存空間物件，非常適合多區域雲端拓撲。

Cloud Storage 也非常適合長期封存，因為它提供生命週期政策，可自動將儲存空間物件移至其他儲存層，前提是物件的生命週期超過預先定義的值。如果成本是主要考量因素，建議使用這個選項，以經濟實惠的備份儲存空間位置和中高 RPO 進行備份。

或者，您也可以選擇 vSAN 儲存空間，盡可能縮短 RPO。如果可接受較高的備份儲存空間費用，且 Cloud Storage 無法滿足 RPO 需求，請使用這個儲存空間選項。請避免使用這個選項進行長期封存，因為 VMware Engine 叢集大小可能會受到儲存空間限制。

使用備份和災難復原服務實作災難復原

建議使用備份和災難復原服務，還原 VMware Engine 上的應用程式。如要保護實際工作環境工作負載，避免因區域內單一可用區發生中斷而受到影響，建議您在區域內的次要可用區部署及運作私有雲 (如果 VMware Engine 在該區域內有多個可用區)。如果不是，建議您在次要區域還原應用程式。

除了 Google Cloud 備份和災難復原服務，VMware Engine 也支援其他災難復原選項，例如 VMware Engine SRM 和 Zerto。VMware Engine SRM 和 Zerto 都依賴 vSphere 複製功能進行災難復原，通常支援較低的 RPO 目標。如果您的復原點目標是以分鐘為單位，而非小時，請考慮採用以 vSphere 複寫為基礎的 DR 解決方案。

檢查清單摘要

以下檢查清單彙整了使用 VMware Engine 的安全性最佳做法。

工作 主題
VMware Engine 網路
VMware Engine IAM 和權限
VMware Engine 記錄與監控
VMware Engine 加密
VMware Engine 備份和災難復原

後續步驟