網管人雜誌

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

本文目錄

前言

vSAN 8 U3 加密機制

vSAN ESA 和 OSA 加密機制的差異

資料傳輸加密

靜態資料加密

實戰 – vSAN 資料加密機制

啟用資料傳輸加密機制

組態設定 KMS 金鑰管理伺服器

啟用靜態資料加密機制

vSAN 加密機制健康狀態

結語

前言

對於企業和組織管理人員來說，當 vSAN 超融合基礎架構搭建完畢，效能調校和日常維運穩定後，下一步便應該思考如何保護企業和組織的機敏資料。

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

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

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

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

vSAN 8 U3 加密機制

vSAN ESA 和 OSA 加密機制的差異

在過去的 vSAN 超融合叢集版本中，主流採用「原始儲存架構」（Original Storage Architecture，OSA），但是從最新 vSAN 8 版本開始，為了將 NVMe 儲存裝置效能最大化，重新設計出「Express 儲存架構」（Express Storage Architecture，ESA）。

雖然，vSAN OSA 和 ESA 儲存架構都支援加密機制，但實際上 vSAN ESA 加密服務的實作方式有所不同，確保 vSAN 能更有效率並最大程度減少資源耗損。簡單來說，在 vSAN ESA 儲存架構中，資料加密和其它儲存服務，例如，壓縮……等，已經移至儲存堆疊架構中的上層。

因此，當 Guest VM 虛擬主機發出資料寫入操作時，系統會在儲存堆疊架構上層直接加密資料，這與傳統 vSAN OSA 相比之外，這樣的加密資料操作只會執行一次，無須針對存放於其它成員節點主機的物件進行加密，也無須像 vSAN OSA 架構必須解密後再重新加密的過程，有效減少 vSAN ESA 超融合叢集中，CPU 運算資源以及網路傳輸資源（如圖 2 所示）。

圖 2、vSAN ESA 和 OSA 加密流程示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

事實上，在 vSAN ESA 儲存架構中，雖然已經將加密流程移至儲存堆疊的上層，然而在實際執行過程中，vSAN 叢集加密過程位於資料服務中，介於壓縮和 Checksum 層級之間進行處理（如圖 3 所示），同時因為位於儲存堆疊最上層，一旦完成加密動作之後，在 vSAN 叢集中跨不同成員節點主機傳送的 vSAN 儲存流量，也已經是加密過後的物件流量傳輸，這也是為什麼 vSAN ESA 儲存架構，相較於傳統 vSAN OSA 儲存架構，所需要的資源和開銷要減少許多的主要原因之一。

圖 3、vSAN ESA 儲存架構加密流程示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

資料傳輸加密

在傳統三層式虛擬化基礎架構中，通常會使用實體網路隔離的方式，例如，採用獨立且不進行路由的 Layer 2 網路環境，來承載儲存流量達到網路隔離的效果。

但是，在 vSAN 超融合基礎架構中，則無須進行實體網路隔離，可以直接針對 vSAN 儲存網路進行資料傳輸加密的動作，達成「線上加密」（Over-the-Wire Encryption）的目的，並且能夠與其它資料服務協同運作，例如，重複資料刪除、壓縮……等，值得注意的是尚未支援 HCI Mesh 架構。

在 vSAN 叢集的「資料傳輸加密」（Data-in-Transit Encryption）機制，採用 FIPS 140-2 驗證加密模組，並以自動化的方式執行，無須搭配 KMS 金鑰伺服器及 vSphere NKP 進行管理維運的動作（如圖 4 所示）。

圖 4、vSAN 叢集啟用資料傳輸加密示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

簡單來說，當 vSAN 叢集啟用資料傳輸加密機制後，vSAN 叢集中成員節點主機之間，vSAN 儲存流量進行傳送時將進行加密的動作，即便這些網路封包被惡意攻擊後擷取了，也無法解密出 vSAN 儲存流量中的機敏資料。

此外，當 vSAN ESA 叢集啟用資料傳輸加密機制，並搭配稍後提到的靜態資料加密機制時，系統將會針對每個傳送的網路封包，進行唯一性的加密作業，如此一來後續有相同的網路封包時，便無須再透過網路進行傳輸，有效提升整體效能和網路封包傳輸流量。

至於啟用資料傳輸加密機制的 vSAN 叢集，在金鑰管理工作任務方面，原則上，在 vSAN 叢集中的所有成員節點主機，將會以動態的方式產生對稱式金鑰，針對傳輸的 vSAN 儲存流量進行加密和驗證作業。

靜態資料加密

「靜態資料加密」（Data-at-Rest Encryption），為針對 vSAN 叢集中 Datastore 儲存資源進行加密，無論採用傳統 vSAN OSA 或新式 vSAN ESA 儲存架構都支援（如圖 5 所示）。

圖 5、vSAN 叢集啟用靜態資料加密示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

不同於傳輸資料加密採用動態產生金鑰，靜態資料加密機制使用「金鑰管理伺服器」（Key Management Server，KMS）進行管理，以便提供符合加密金鑰生命週期管理，包含，金鑰建立、啟用、停用和刪除……等管理作業。

至於 KMS 用戶端，則是透過「金鑰管理互通性通訊協定」（Key Management Interoperability Protocol，KMIP），與 KMS 伺服器進行通訊，以便使用由 KMS 伺服器所管理的加密金鑰。

在組態設定信任網域時，管理人員必須遵循 PKI 數位憑證管理流程，也就是 vCenter 管理平台，必須向 KMS 金鑰管理伺服器提供數位憑證，接著 KMS 再搭配使用不同類型的憑證來建立信任網域機制，如下列所示：

根 CA 憑證（Root CA）：信任網域將針對根憑證簽署的所有憑證建立信任關係。
證書（Certificate）： vCenter 管理平台將會使用證書建立信任關係。
CSR 憑證簽署請求： vCenter 管理平台產生 CSR 請求檔後，提交給 KMS 金鑰管理伺服器進行簽署，接著採用產生的憑證建立信任關係。
上傳公鑰和私鑰：當 vCenter 管理平台取得憑證，並與金鑰提供者建立信任關係之後，vSAN 叢集便能啟用加密服務。

當 vSAN 叢集啟用靜態資料加密服務機制後，金鑰提供者的連線資訊，便會被推送到所有成員節點主機中，而 vSAN 成員節點主機將會向金鑰提供者，提供 Reference Key 或 Key ID 資訊，接著金鑰提供者再提供 KEK（Key Encryption Key）給 vSAN 成員節點主機，以便透過 KEK 將「磁碟金鑰」（Disk Keys）進行加密（如圖 6 所示）。

圖 6、vSAN 叢集啟用靜態加密技術流程示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

由於靜態資料加密機制，必須依賴 KMS 金鑰管理伺服器，所以企業及組織必須考慮 KMS 高可用性機制，例如，建立 KMS 叢集，部署多台 KMS 金鑰管理伺服器，以便提升金鑰管理的可用性。

在 VMware 最佳建議作法中，管理人員可以考慮為每台 vSAN 主機配置 TPM 受信任平台模組，讓加密金鑰能夠安全的儲存在 TPM 當中，以便 KMS 金鑰管理伺服器發生故障時，仍然能夠正常運作。

在 KMS 金鑰管理伺服器相容性與金鑰管理協定方面，目前市面上有許多版本的 KMIP 金鑰管理互通通訊協定，而在 vSAN 運作架構中支援採用 KMIP 1.1 版本，因此只要是符合 KMIP 1.1 標準的 KMS 金鑰管理伺服器，便能擔任 vSAN 叢集外部 KMS 金鑰管理伺服器的角色。

在加密金鑰生命週期管理方面，也已經和內建的 Skyline Health 機制整合。雖然，有部分 KMS 解決方案，能夠提供金鑰到期（Key Expiration）機制，讓 KMS 伺服器管理人員，能夠設定加密金鑰的到期時間。

然而，在 vSAN 8 U2 版本之前，vSAN 叢集並無法識別外部 KMS 金鑰管理伺服器，所提供的加密金鑰到期時間屬性，可能會因為加密金鑰過期失效，從而導致 vSAN 叢集加密機制停擺的風險。

因此，從 vSAN 8 U2 版本開始，無論是傳統的 vSAN OSA 或新式 vSAN ESA 儲存架構，都已經與 Skyline Health 機制整合，能夠檢查和監測加密金鑰的到期狀態，一旦 KMS 金鑰管理伺服器啟用加密金鑰到期機制後，系統將會自動產生健康狀態警示，顯示加密金鑰剩餘有效天數，同時提供重新加密（Shallow Rekey）的選項，確保 vSAN 叢集環境的穩定性（如圖 7 所示）。

圖 7、vSAN 8 U2 版本後支援 KMS 加密金鑰生命週期管理機制流程示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

事實上，除了採用外部 KMS 金鑰管理伺服器之外，從 vSphere 7 U2 版本開始，便開始支援 vSphere Native Key Provider（NKP）機制，這是包括 vTPM、VM 加密、vSAN 加密的內建機制，提供和外部 KMS 金鑰管理相同的功能，對於中小型企業和組織來說，能夠更簡單達成資料加密的目的（如圖 8 所示）。

圖 8、vSphere Native Key Provider（NKP）加密機制流程示意圖

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

事實上，無論採用內建的 vSphere KNP 加密機制，或是搭配外部 KMS 金鑰管理伺服器，在 VMware 最佳建議作法中，都建議為 vSAN 叢集中所有的成員節點主機配置 TPM 2.0 晶片，當系統儲存加密金鑰快取之後，便會立即同步至 TPM 晶片，後續即便 vSAN 主機重新啟動，加密金鑰仍可從 TPM 晶片中，恢復至加密金鑰快取內，確保加密運作不中斷（如圖 9 所示）。

圖 9、為 vSAN 主機配置 TPM 2.0 晶片確保加密作業不中斷

圖片來源： Understanding Encryption Offerings with vSAN 8 U3 and VCF 5.2

實戰 – vSAN 資料加密機制

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

啟用資料傳輸加密機制

當企業和組織，希望針對 vSAN 叢集中，叢集成員主機之間的資料傳輸進行加密時，便可以透過啟用「資料傳輸」（Data-in-Transit）加密機制達成目的。一旦資料傳輸加密機制啟用完成後，叢集成員主機之間，所有的資料傳輸和「中繼資料」（Metadata）傳輸時，便會進行加密作業。

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

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

請點選 Data Services 區塊中下方的 EDIT，在彈出的 vSAN Services 中，針對「資料傳輸」（Data-in-Transit）加密機制進行啟用的動作。預設情況下，重新產生加密金鑰的間隔時間為「1 天」（如圖 11 所示），管理人員也可以在 6 小時至 7 天的間隔時間進行選擇，倘若預設的間隔時間無法滿足企業和組織的需求時，可以將 Default 選項調整為 Custom，便可以自行輸入以分鐘為單位的間隔時間，值得注意的是分鐘數值支援區間為 30 分鐘至 10080 分鐘。

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

在系統啟用資料傳輸加密機制過程中，管理人員可以透過 vCenter 操作介面中，下方的 Tasks 窗格中，看到系統先為 vSAN 叢集進行啟用作業，接著為 vSAN 叢集中所有的成員節點主機，進行資料傳輸加密機制的啟用作業，完成後回到 Data Services 區塊中，確認「資料傳輸」（Data-in-Transit）加密機制欄位，是否由原本的 Disabled 轉變為 Enabled 的啟用狀態（如圖 12 所示）。

圖 12、順利為 vSAN 叢集啟用資料傳輸加密機制

現在，企業和組織可以放心，在內部資料中心內，即便 Layer 2 或 Layer 3 的 vSAN 儲存網路，遭到惡意人士攻入並收集網路封包後分析時，由於已經為 vSAN 叢集啟用資料傳輸加密機制，所以惡意人士將會發現收集到的網路封包已經加密過，將無法順利分析或擷取出傳輸過程中的機敏資料。

組態設定 KMS 金鑰管理伺服器

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

在 vSAN ESA 運作架構上，由於啟用靜態資料加密技術時，系統將會在 vSAN 上層進行資料加密作業，以降低 CPU 工作負載或 I/O 儲存效能額外耗損的情況，一旦啟用後便能有效保護儲存裝置內的靜態資料。

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

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

登入 vCenter 管理介面後，依序點選「vCenter Server > Configure > Security > Key Providers > Add > Add Native Key Provider」項目，在彈出的新增 Key Provider 視窗中，請鍵入本文實作名稱「vSAN-Native-KP」，由於實作環境為巢狀虛擬化環境，因此請取消勾選下方 TPM 選項，但實務上建議勾選採用，確認無誤後按下 Add Key Provider 鈕（如圖 13 所示）。

圖 13、新增 Native Key Provider

順利新增 Native Key Provider 後，可以在下方 KMS 資訊欄中，看到系統自動產生金鑰 ID，然而目前的狀態則是「Not backed up」（如圖 14 所示），請為 Native Key Provider 執行備份作業，以避免屆時執行還原作業時，因為遺失金鑰導致無法恢復資料的情況發生。

圖 14、順利新增 Native Key Provider，但尚未進行備份作業

請點選「vSAN-Native-KP」項目後，點選上方 BACK-UP，在彈出備份 Native Key Provider 視窗中，管理人員可以視需求，勾選 Protect Native Key Provider data with password 選項，為 Native Key Provider 加上密碼多一層保護，確認後按下 Back Up Key Provider 鈕（如圖 15 所示），系統將會自動下載「vSAN-Native-KP.p12」檔案，請管理人員務必妥善保存。

圖 15、備份 Native Key Provider 並加上密碼保護

可以看到 vSAN-Native-KP 項目中，狀態欄位已經轉變為 Active，表示系統已經完成金鑰提供者的備份作業，請點選上方 Set as Default，將 vSAN-Native-KP 項目組態設定為預設的金鑰提供者（如圖 16 所示）。

圖 16、vSAN-Native-KP 備份作業完成並設為預設

啟用靜態資料加密機制

由於 vSAN 叢集的「靜態資料」（Data-as-Rest）加密機制，屬於軟體層級的加密技術與硬體無關，因此企業和組織無須特意採購，較為昂貴的「自我加密硬碟」（Self-Encrypting Drives，SEDs），也可以達到保護 vSAN 叢集中靜態資料的目的。

組態設定 KMS 金鑰提供者並執行備份作業後，由於 vSAN 叢集啟用靜態資料加密後，將會針對 vSAN Datastore 儲存資源內，所有的儲存裝置進行重新格式化的動作，所以在啟用靜態資料加密前，建議將所有 VM 虛擬主機，遷移出 vSAN Datastore 儲存資源，以縮短啟用靜態資料加密時間，否則系統將依序執行遷移 VM 虛擬主機，重新格式化儲存裝置後再遷移，造成啟用靜態資料加密時間過長。

請在 vCenter 管理介面中，依序點選「Encrypt-Cluster > Configure > vSAN > Services」項目後，點選右側 Data Services 中的 Edit，在彈出的 vSAN Services 視窗中，請啟用 Data-at-Rest 加密機制，並選擇金鑰提供者為 vSAN-Native-KP 項目後，按下 Apply 鈕套用生效。

在本文實作中，為節省時間所以並未勾選重新格式化儲存裝置選項，在實務上建議管理人員應該要勾選，讓系統重新格式化 vSAN Datastore 中所有儲存裝置，確保資料外洩的可能性降到最低。回到 vSAN Data Servies 頁面中，可以看到靜態資料加密機制已經啟用，並且採用先前建立的 vSAN-Native-KP 金鑰提供者（如圖 17 所示）。

圖 17、為 vSAN 叢集啟用靜態加密機制

現在，vSAN 叢集已經順利啟用靜態加密機制，日後在管理維運上，建議管理人員應該定期產生新的加密金鑰，以防止金鑰過期，或避免金鑰外洩的風險，則只要點選下方 Generate New Encryption Keys 後，跟著互動對話視窗操作即可。

vSAN 加密機制健康狀態

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

請在 vCenter 管理介面中，依序點選「Encrypt-Cluster > Monitor > vSAN > Skyline Health > Health findings > ALL > Category」後，點選過濾圖示後，勾選 Data-in-transit encryption 選項後，可以看到資料傳輸加密的檢查狀態為健康（如圖 18 所示）。

圖 18、確認 vSAN 叢集資料傳輸加密機制健康狀態

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

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

同樣的查看方式，這次的過濾項目改為勾選 Data-at-rest encryption 後，這次可以看到有二個健康檢查項目，點選第一個健康檢查項目左側三個點圖示，選擇 View Current Result 後，可以看到系統檢查並驗證，vSAN 叢集中的金鑰提供者狀態，並列出 vSAN 成員節點主機的連線狀態和金鑰狀態（如圖 20 所示）。

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

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