VMware Engine 安全性的最佳做法

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

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

VMware Engine 網路

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

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

VMware Engine 會運用 VMware Engine 網路和 VPC 對等互連，將 VMware Engine 私有雲網路的私有網路連線連至您的 VPC 網路。從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 執行個體的輸入資料，應預設受到限制，僅允許主動開啟的流量。

使用 VPC 防火牆，從 VPC 封鎖傳輸至管理裝置和 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 網路區隔之間，傳入私有雲的流量 IDS/IPS 功能，請考慮部署第三方防火牆設備。您可以將第三方設備部署為 Google Cloud 網路中兩個虛擬私有雲之間的多 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。在其他情況下，我們建議使用外部 HTTP(S) 負載平衡器。

請按照說明文件操作，在下列任一設定中，將 VMware Engine 工作負載新增至混合式 NEG：

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

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

同樣地，如果 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 Producer Service API 進入範圍。如需詳細設定指南，請參閱 VMware Engine 的 VPC Service Controls 說明文件頁面。

VMware Engine IAM 和權限

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

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

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

平台 元件 身分來源 設定權限的位置 活動範例
Google Cloud VMware Engine 入口網站 Cloud Identity Identity and Access Management 例如私有雲部署和取消、叢集部署和取消。
VMware Engine vCenter LDAP vCenter UI 中的主機和叢集、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 收集、保留及分析系統記錄訊息，可提供重要的安全用途，例如根據管理員使用者 (或緊急使用者) 登入活動發出即時快訊，但這類活動應僅在特殊情況下執行。如要分析系統記錄檔訊息，必須設定系統記錄檔匯總工具 (例如 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 本身，後者會儲存在 Cloud Key Management Service (KMS) 中。您可以選擇 Cloud KMS 的位置，用來存放金鑰加密金鑰。

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

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

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

請注意，我們不建議同時啟用 VM 層級加密和 vSAN 資料儲存庫加密，因為加密 VM 的重複資料刪除效率會趨近於零。

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

您必須使用 VMware Engine vSphere 輪替 KEK。無論是預設金鑰供應商還是外部 Cloud KMS，都是如此。您可以從 vCenter 或使用其 API 啟動 KEK 輪替。請考慮根據貴機構的需求，自動輪替 KEK。您可以在 GitHub 找到 PowerCLI 指令碼範例。

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 值區，自動將儲存空間物件複製到多個區域，非常適合多區域雲端拓撲。

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 備份和災難復原

後續步驟