vSAN新功能再升級　加密保護叢集資料安全

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

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

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

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

vSAN 8 U3加密機制

接著，詳細介紹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所示。

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

資料傳輸加密

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

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

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

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

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

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

靜態資料加密

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

不同於傳輸資料加密採用動態產生金鑰，靜態資料加密機制使用「金鑰管理伺服器」（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所示。

由於靜態資料加密機制必須依賴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所示。

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

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

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

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

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

現在，企業可以放心地在內部資料中心內，即便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所示。

順利新增Native Key Provider後，可以在下方KMS資訊欄中看到系統自動產生金鑰ID，然而目前的狀態是「Not backed up」，如圖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」檔案，管理人員務必妥善保存。

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

啟用靜態資料加密機制

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

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

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

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

檢查完畢，點選上方Overview項目，回到上一頁，改為點選第二個健康檢查項目左側的三個點圖示，選擇View Current Result後，可以看到系統檢查和驗證vSAN叢集中，所有成員節點主機是否啟用CPU AES-NI的x86指令集功能。

如圖21所示，這個AES-NI指令集的功用在於，能有效提高執行加密和解密的執行速度，並減少CPU工作負載。

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