網管人雜誌

本文刊載於網管人雜誌第 246 期 - 2026 年 7 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。

本文目錄

前言

VCF 9.1 Global Dedup 支援資料加密

遠端 vSAN Datastore 支援傳輸加密

實戰 – vSAN 資料加密機制

啟用資料傳輸加密機制

KMS 金鑰管理伺服器

啟用靜態資料加密機制

加密機制健康情況

結語

前言

在 vSphere 虛擬化和 vSAN 超融合基礎架構中，已經支援 NIST 美國國家標準與技術研究院，加密標準的「進階加密標準」（Advanced Encryption Standard，AES）演算法，並支援下列兩種不同的加密方式，企業和組織可以根據需求個別啟用，也可以同時啟用保護機敏資料不外洩（如圖 1 所示）。

傳輸資料加密（Data-in-Transit）：針對 vSAN 超融合叢集中，所有成員節點主機之間儲存流量進行加密，以 vSAN 叢集為單位進行啟用或關閉傳輸資料加密機制。
靜態資料加密（Data-at-Rest）：針對 vSAN 超融合叢集，在 vSAN Datastore 儲存資源中，所有持久性儲存裝置的資料進行加密，直到系統在執行讀取操作程序時，資料才會被解密。

圖 1、支援兩種主流加密機制的 vSAN 超融合叢集示意圖

圖片來源： vSAN Encryption Services using VMware Cloud Foundation 9.1

VCF 9.1 Global Dedup 支援資料加密

在 VCF 9.0 版本中，針對 vSAN ESA 超融合架構，推出資料最佳化「全域重複資料刪除」（Global Deduplication）機制，能夠有效跨越過去 vSAN OSA 的技術限制，提供更高效能和更多儲存空間節省的目標。

首先，最大的差異在舊有 vSAN OSA 架構中，重複資料刪除網域被限制在 vSAN 叢集內，單台 vSAN 節點主機的「磁碟群組」（Disk Group）當中，這會降低重複資料刪除的有效性，舉例來說，當相同的資料區塊位於不同的磁碟群組時，就無法刪除重複資料，這也是阻礙 vSAN OSA 重複資料刪除率的主要原因之一。

新式 vSAN ESA 運作架構，重複資料刪除網域則是以整個 vSAN 叢集為單位，因此在 vSAN 叢集中只要出現相同的資料區塊，便能夠執行重複資料刪除作業，同時採用 4KB 資料顆粒度更小的設計，更容易讓系統明顯提升出到重複資料區塊的數量，進而提升重複資料刪除的效率和節省的儲存空間。

此外，在重複資料刪除執行效能方面兩者也有很大的不同，在舊有 vSAN OSA 架構中，會將資料暫存至容量層級（Capacity Tier）當中，然後才觸發執行重複資料刪除作業程序，雖然這樣的行為是發生在資料寫入確認，傳送給客體作業系統之後，但此舉會造成資料移動至容量層級的速度變慢，同時讓緩衝區更容易被填滿，當採用的儲存裝置反應速度又較慢時，便會發生 vSAN 壅塞的情況，導致 VM 虛擬主機延遲反應的情況。

新式的 vSAN ESA 運作架構中，重複資料刪除不會發生在熱資料寫入路徑當中，確保重複資料刪除程序不會浪費資源在最新寫入的資料中，這些資料通常會在不久之後便被刪除或覆寫，同時搭配智慧化處理的方式來執行這些工作任務，動態確認當 CPU 週期空閒時，才會執行重複資料刪除的工作任務，針對運作中的 VM 虛擬主機干擾程度降至最低，並且透過中繼資料（Metadata）對應機制，讓系統能有效識別並優先刪除冷資料，然後才刪除較熱的資料，確保重複資料刪除處理效率。

事實上，在 VCF 9.0 版本中的 vSAN ESA，是採用「有限可用性」(Limited Availability）形式推出，僅提供部分企業端客戶體驗。在最新推出的 VCF 9.1 版本中，正式推出「全域重複資料刪除」（Global Deduplication），值得注意的是在 VCF 9.1 版本中的 vSAN 9.1，不僅針對資料最佳化進行重複資料刪除，更支援 vSAN 靜態資料加密（Data-at-Rest）機制，保護企業和組織的機敏資料（如圖 2 所示）。

圖 2、VCF 9.1 支援全域重複資料刪除和靜態資料加密機制運作示意圖

圖片來源： More Capacity with VMware vSAN Compression and Global Deduplication in VCF 9.1 - VMware Cloud Foundation（VCF）Blog

在最新 vSAN 9.1 版本運作架構中，全域重複資料刪除和靜態資料加密協同運作，當資料最初寫入儲存裝置時，系統便會立即進行靜態資料加密的動作，確保儲存裝置上的資料內容始終保持加密狀態，滿足企業和組織對於資安與合規的要求。

接著，全域重複資料刪除機制比對原有的資料區塊是否有重複的情況發生，過去在加密環境下這樣的比對行為通常會遇到挑戰，而新版 vSAN 9.1 的解決方式，則是記憶體中暫時解密比對的資料區塊，以便產生雜湊值並進行比對。值得注意的是，這個暫時解密的動作僅限於記憶體層級，並不會影響儲存裝置的加密狀態，完成比對程序後資料仍然以加密形式進行保存，簡單來說，vSAN 叢集透過這樣的方式，讓系統在安全性與執行效率之間達到動態平衡，能夠保持資料加密的安全性，又能進行資料最佳化達到重複資料刪除的目的。

透過資料比對產生雜湊值的方式，讓系統能夠更有效率的讀取資料，不僅縮短整體處理時間，同時大幅降低 CPU 工作負載與網路資源的消耗，讓重複資料刪除在大型規模的 vSAN 叢集環境中更具可行性。此外，在 vCenter 管理介面中也改善空間節省的呈現方式，將重複資料刪除與壓縮的資料減量比率統一顯示，讓管理人員能夠更直覺解讀整體效益，避免過去因為不同呈現方式而造成的混淆（如圖 3 所示）。

圖 3、重複資料刪除與壓縮的資料減量比率統一顯示

圖片來源： More Capacity with VMware vSAN Compression and Global Deduplication in VCF 9.1 - VMware Cloud Foundation（VCF）Blog

值得注意的是，當管理人員關閉全域重複資料刪除功能後，系統僅會暫停處理後續資料，已經完成重複資料刪除的資料區塊，仍然會保持原狀不會恢復成未重複資料刪除的狀態。此外，全域重複資料刪除機制，尚未支援 Stretched Cluster 與 2-Node Cluster 拓撲架構，所以企業和組織在規劃部署時，必須留意避免發生架構衝突而無法順利啟用。

遠端 vSAN Datastore 支援傳輸加密

在過去的 vSAN 版本中，當 vSphere 虛擬化叢集掛載遠端 vSAN Datastore 儲存資源時，由於在傳輸過程中的儲存流量並未加密，這表示 vSAN 儲存流量在客戶端叢集與伺服器叢集之間，仍然存著潛在的資安風險。

因此，在最新的 VCF 9.1 版本當中，正式支援跨 vSAN 叢集之間傳輸資料加密機制，當然包含 vSphere 虛擬化叢集掛載遠端 vSAN Datastore 儲存資源的情境，提供真正的端到端加密，確保所有 vSAN 儲存流量在傳輸過程中都能受到加密保護，對於資料安全極為嚴格的產業，例如，金融、醫療產業使用者的高度期待（如圖 4 所示）。

圖 4、遠端 vSAN Datastore 支援傳輸資料加密示意圖

圖片來源： Greater Flexibility and Security with VMware vSAN Storage Clusters in VCF 9.1 - VMware Cloud Foundation（VCF）Blog

在部署層面上，要針對遠端 vSAN Datastore 啟用傳輸加密也很簡單，只需要在掛載遠端 vSAN Datastore 時進行組態設定即可，除了與伺服器叢集上的其他資料服務完全獨立之外，加密金鑰的管理也由系統自動處理，降低管理複雜度。

針對不同企業和組織的需求，提供兩種不同的部署方式，第一種部署方式在 vSAN 儲存叢集中，同時啟用傳輸加密和資料加密機制，並在 vSAN 客戶端叢集啟用傳輸加密機制，確保儲存流量中的每個封包皆具備唯一雜湊值，提供最高等級的安全性，但是這種部署雖然具備極高的安全性，卻可能帶來效能降低的副作用。

第二種部署方式，則是在 vSAN 儲存叢集僅啟用資料加密機制，而 vSAN 客戶端叢集啟用傳輸加密機制，整體的加密機制仍然完整，但是不保證寫入的儲存流量具備唯一雜湊值，除非面臨最嚴苛的合規要求，否則此部署方式已經能滿足大部份的企業和組織需求，並且能有效避免效能損耗。

實戰 – vSAN 資料加密機制

在實戰演練小節中，將採用最新版本 vSAN 9 運作環境，實際操作啟用「資料傳輸」（Data-in-Transit）加密機制，以及「靜態資料」（Data-at-Rest）加密機制。

啟用資料傳輸加密機制

當企業和組織，主要針對 vSAN 超融合叢集中，叢集成員主機之間的資料傳輸進行加密時，便可以透過啟用「資料傳輸」（Data-in-Transit）加密機制達成，當資料傳輸加密機制啟用完成之後，叢集成員主機之間，所有的資料傳輸和「中繼資料」（Metadata）進行任何傳輸作業時，便會加密之後才進行傳輸，確保即便惡意攻擊有機會在途中攔截資料，也無法分析和解密出任何敏感資訊。

請在登入 vCenter 管理介面之後，依序點選「vCenter Server > Datacenter > Cluster > Configure > vSAN > Services」項目，在右邊 Data Services 區塊中，分別可以看到資料傳輸加密和靜態資料加密，兩個不同加密技術的啟用情況，請點選區塊下方的 EDIT，準備啟用資料傳輸加密機（如圖 5 所示）。

圖 5、準備啟用資料傳輸加密機制

在彈出的 vSAN Services 對話框中，請啟用「資料傳輸」（Data-in-Transit）加密機制（如圖 6 所示），預設情況下，重新產生加密金鑰的間隔時間為「1 day」，管理人員也可以選擇不同的間隔時間，例如，更短的 6 hours 或更長的 7 days，倘若預設的間隔時間無法滿足企業和組織的需求時，可以將 Rekey Interval 下拉選單的選項調整為 Custom，預設為 1440 分鐘，然而管理人員可以自行輸入以分鐘為單位的間隔時間，值得注意的是分鐘數值的支援區間，最少為 30 分鐘最多為 10080 分鐘，確認組態設定無誤後，按下 Apply 鈕以便套用生效。

圖 6、啟用資料傳輸加密機制並選擇加密金鑰重新產生的間隔時間

在系統啟用資料傳輸加密機制的過程中，管理人員可以透過 vCenter 操作介面中，展開下方的 Tasks 窗格內，看到系統會自動為 vSAN 叢集進行資料傳輸加密機制啟用作業，接著為 vSAN 叢集中所有的成員節點主機，也進行資料傳輸加密機制的啟用作業，所有工作任務完成後，管理人員可以切換回 Data Services 區塊，確認「資料傳輸」（Data-in-Transit）加密機制欄位，是否由原本的 Disabled 轉變為 Enabled 的啟用狀態，並且顯示剛才選擇加密金鑰重新產生的間隔時間（如圖 7 所示）。

圖 7、vSAN 叢集啟用資料傳輸加密機制成功和加密金鑰重新產生時間

現在，管理人員可以比較放心，在企業內部資料中心當中，即便 Layer 2 或 Layer 3 的 vSAN 儲存網路，遭到惡意人士攻入並收集網路封包進行分析時，由於 vSAN 叢集已經啟用資料傳輸加密機制，所以即便惡意人士收集到 vSAN 儲存網路封包，但是他們將會發現收集到的網路封包內容已經被加密過，無法順利分析或擷取出傳輸過程中任何的機敏資料，有效保障企業和組織的傳輸資料安全。

KMS 金鑰管理伺服器

事實上，從過去舊版的 vSAN 6.7 版本開始，便已經開始支援靜態資料加密機制，此加密機制採用 FIPS 140-2 驗證的軟體加密技術，並且由於 vSAN 靜態資料加密技術與硬體無關，所以能夠帶來簡化金鑰管理上的便利性。

由於啟用靜態資料加密技術時，系統會在 vSAN 上層進行資料加密作業，在過去的 vSAN 儲存架構中，容易影響到整體運作效能，但是在新式 vSAN ESA 儲存運作架構中，能夠盡可能減少 CPU 工作負載，以及 I/O 儲存效能額外耗損的情況，有效改善因為啟用加密機制而導致運作效能降低的情況。

在 vSAN 叢集環境中，要完成靜態資料加密作業，必須先確保運作環境中具備 KMS 外部金鑰管理伺服器，因為 vCenter 管理平台，將會針對 KMS 外部金鑰管理伺服器，送出加密金鑰的請求，然後 KMS 外部金鑰管理伺服器產生並儲存加密金鑰後，vCenter 管理平台會再從 KMS 外部金鑰管理伺服器取得加密金鑰的 ID，然後再派送給 vSAN 叢集中所有成員節點主機。因此，vCenter 管理平台並不會儲存敏感的 KMS 加密金鑰，但是會保留加密金鑰 ID 列表清單。

管理人員在啟用靜態加密技術之前，必須先確認 KMS 外部金鑰管理伺服器，是否支援「金鑰管理互通性通訊協定」（Key Management Interoperability Protocol，KMIP）v1.1 版本標準，並且管理人員必須組態設定 KMS 外部金鑰管理伺服器，然後新增至 vCenter 管理平台同時建立信任機制後，才能順利啟用靜態加密機制。

登入 vCenter 管理介面後，請依序點選「vCenter Server > Configure > Security > Key Providers > Add > Add Native Key Provider」項目，在彈出的新增 Key Provider 視窗中，請鍵入本文實作名稱「vSAN9-Native-Key-Provider」（如圖 8 所示），由於本文實作環境為巢狀式虛擬化環境，因此請取消勾選下方 TPM 選項，否則稍後要針對靜態加密機制進行 Key Provider 的套用時，將會無法套用成功並產生錯誤，然而實務上採用實體硬體伺服器時則強烈建議勾選採用，上述組態設定確認無誤後，即可按下 Add Key Provider 鈕產生靜態加密機制使用的 Key Provider。

圖 8、新增靜態加密機制使用的 Native Key Provider

順利新增 Native Key Provider 之後，管理人員便能在下方 KMS 資訊欄中，看到系統自動產生加密金鑰，然而目前 Native Key Provider 的運作狀態欄位顯示為「Not backed up」，必須先為 Native Key Provider 執行備份作業，避免後續執行資料還原動作之後，因為遺失加密金鑰導致無法恢復資料的情況發生。請點選「vSAN9-Native-Key-Provider」項目後，點選上方 BACK-UP，準備為 Native Key Provider 執行備份作業（如圖 9 所示）。

圖 9、順利新增 vSAN9-Native-Key-Provider，但尚未進行加密金鑰備份作業

在彈出的 Back up Native Key Provider 視窗中，管理人員必須先勾選 Protect Native Key Provider data with password 選項，為 Native Key Provider 加上密碼多一層保護，在連續鍵入兩次加密金鑰保護密碼之後，勾選 I have saved the password in a sceure place 後，按下 Back Up Key Provider 鈕（如圖 10 所示），系統將會自動下載「vSAN9-Native-Key-Provider.p12」檔案，請管理人員務必妥善保存，否則後續執行資料還原動作時，將會因為遺失加密金鑰導致無法恢復資料的情況。

圖 10、備份 vSAN9-Native-Key-Provider 並加上密碼保護

現在，在 vCenter 管理介面中，可以看到 vSAN9-Native-Key-Provider 項目，狀態欄位已經轉變為 Active，表示系統已經完成加密金鑰提供者的備份作業，接著請點選上方 Set as Default，在彈出的 Make Key Provider Default 視窗中，系統提醒一旦將此加密金鑰設定為預設值之後，系統將會使用此加密金鑰，針對後續所有新增的 VM 虛擬主機進行靜態資料加密的動作，確認無誤後按下 Set as Default 鈕以便套用生效，確認將 vSAN9-Native-Key-Provider 項目組態設定為預設的金鑰提供者（如圖 11 所示）。

圖 11、組態設定 vSAN9-Native-Key-Provider 為預設的加密金鑰提供者

啟用靜態資料加密機制

在 vSAN 超融合叢集運作架構中，「靜態資料」（Data-as-Rest）加密機制，屬於軟體層級的加密技術與硬體無關，因此企業和組織無須額外採購，費用更昂貴的「自我加密硬碟」（Self-Encrypting Drives，SEDs），也可以達成保護 vSAN 叢集中 VM 虛擬主機資料的目的。

目前，我們已經完成組態設定 KMS 金鑰提供者，並且執行加密金鑰的備份作業，由於 vSAN 叢集在啟用靜態資料加密機制後，將會針對 vSAN Datastore 儲存資源內，所有的儲存裝置進行重新格式化的動作，所以在啟用靜態資料加密機制之前，建議管理人員應該將所有 VM 虛擬主機，遷移出 vSAN Datastore 儲存資源，以便有效縮短啟用靜態資料加密時間，否則系統將會針對每一台受影響的 VM 虛擬主機，進行逐台 VM 虛擬主機線上遷移的自動化作業，先自動遷移 VM 虛擬主機出 vSAN Datastore 儲存資源，重新格式化儲存裝置後，再自動將 VM 虛擬主機遷移回 vSAN Datastore 儲存資源，將會造成整體啟用靜態資料加密時間過長。

在 vCenter 管理介面中，請依序點選「vSAN9-Cluster > Configure > vSAN > Services」項目後，點選右側 Data Services 中的 Edit，在彈出的 vSAN Services 視窗中，請啟用 Data-at-Rest 加密機制，並選擇剛才新增並備份完成的 vSAN9-Native-Key-Provider 項目後，按下 Apply 鈕套用生效。

待系統完成組態設定後，切換回 Data Services 頁面中，可以看到靜態資料加密機制已經啟用，並且採用先前建立的 vSAN9-Native-Key-Provider 金鑰提供者（如圖 12 所示）。

圖 12、vSAN 叢集靜態資料加密機制啟用成功

事實上，在本文實作環境中，為節省時間所以未勾選重新格式化儲存裝置選項，因此在 Data Services 區塊中，可以看到 Disk wiping 的選項值為 Disabled 。然而，實務上強烈建議管理人員必須要勾選，讓系統重新格式化 vSAN Datastore 儲存資源中的所有儲存裝置，以確保資料外洩的可能性能夠降到最低。

現在，vSAN 叢集已經順利啟用靜態資料加密機制，日後在管理維運上，建議管理人員應該定期產生新的加密金鑰，除了防止加密金鑰過期之外，也能有效避免加密金鑰外洩的風險，管理人員只需要點選，在 Data Services 區塊下方的 Generate New Encryption Keys，然後跟著互動對話視窗操作即可重新產生新的加密金鑰。

加密機制健康情況

順利為 vSAN 超融合叢集，啟用資料傳輸加密和靜態資料加密機制後，管理人員可以隨時透過 vCenter 管理介面，查詢並了解 vSAN 叢集加密機制的健康狀態。

在 vCenter 管理介面中，請依序點選「vSAN9-Cluster > Monitor > vSAN > Skyline Health > Health findings > ALL > Sort by Category」項目，接著點選過濾圖示，然後勾選 Data-in-transit encryption 選項之後，便可以看到資料傳輸加密機制，組態設定的檢查狀態欄位顯示為健康（如圖 13 所示）。

圖 13、過濾並檢查 vSAN 叢集資料傳輸加密機制健康狀態

點選 Configuration check 項目左側的三個點圖示，選擇 View Current Result 選項後，可以看到 vSAN 叢集中所有成員節點主機，啟用資料傳輸加密機制的健康狀態（如圖 14 所示），倘若成員節點主機健康狀態發生問題時，可以查看 Recommendation 欄位的建議內容，修復 vSAN 叢集成員節點主機的資料傳輸加密健康狀態。

圖 14、查看 vSAN 叢集資料傳輸加密機制健康狀態

同樣的查看方式，但是將過濾項目改為勾選 Data-at-rest encryption 後，這次可以看到有二個健康檢查項目，分別是 VMware vCenter and all hosts are connected to Key Management Servers 和 CPU AES-NI is enabled on hosts 項目（如圖 15 所示）。

圖 15、過濾並檢查 vSAN 叢集靜態資料加密機制健康狀態

請點選第一個健康檢查項目左側的三個點圖示，選擇 View Current Result 選項後，可以看到系統檢查並驗證 vSAN 叢集中金鑰提供者狀態，同時列出 vSAN 成員節點主機的連線狀態和加密金鑰狀態（如圖 16 所示）。

圖 16、檢查 vSAN 叢集靜態資料加密連線狀態和金鑰狀態

檢查完畢後，點選上方 Overview 項目回到上一頁，改為點選第二個健康檢查項目左側三個點圖示，選擇 View Current Result 後，可以看到系統檢查和驗證 vSAN 叢集中，所有成員節點主機是否啟用 CPU AES-NI 的 x86 指令集功能，在 CPU 處理器中的 AES-NI 指令集功用，在於能有效提高執行加密和解密的執行速度，同時減少 CPU 處理器的工作負載，讓 vSAN 節點主機不會因為啟用加密機制，而降低整體運算效能（如圖 17 所示）。