vSAN加密雙重到位　兼顧傳輸中與靜態資料

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

‧傳輸資料加密（Data-in-Transit）：針對vSAN超融合叢集中，所有成員節點主機之間儲存流量進行加密，以vSAN叢集為單位進行啟用或關閉傳輸資料加密機制。

‧靜態資料加密（Data-at-Rest）：針對vSAN超融合叢集，在vSAN Datastore儲存資源中，所有持久性儲存裝置的資料進行加密，直到系統在執行讀取操作程序時，資料才會被解密。

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所示。

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

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

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

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

遠端vSAN Datastore支援傳輸加密

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

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

在部署層面上，要針對遠端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所示。

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

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

現在，管理人員可以比較放心，在企業內部資料中心，即便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外部金鑰管理伺服器是否支援「金鑰管理互通性通訊協定」（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。

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

在彈出的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」檔案，管理人員務必妥善保存，否則後續執行資料還原動作時，將會因為遺失加密金鑰導致無法恢復資料的情況。

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

啟用靜態資料加密機制

在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所示。

事實上，在本文實作環境中，為節省時間所以未勾選重新格式化儲存裝置選項，因此在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所示。

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

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

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

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

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞