自帶密鑰（BYOK）只是安慰劑嗎？

先來看條基礎知識：靜態數據和動態數據都可以，也應該加密。

數據能在客戶端加密，也能在服務器端加密。在安全領域，我們深諳一些耳熟能詳的最佳實踐，比如深度防御（即不依賴單一安全防護措施），以及隱匿式安全——這真的不算安全。

那么，云行業的安全操作都有哪些，又存在何種潛在漏洞呢？大多數云服務提供商（CSP）都會以某種形式提供自帶密鑰（BYOK）服務。例如，AWS就支持如下幾種密鑰管理服務（KMS）選項：

● 僅KMS：KMS存儲客戶管理的密鑰（CMK）。

● 具有客戶密鑰存儲和CMK的KMS：同樣由客戶管理并存儲在云硬件安全模塊（HSM）中。

● 具有第三方HSM的KMS：客戶提供的KMS直連該KMS。

密鑰保存在易失性KMS內存中，也就是說，數據加密密鑰（DEK）解密后可在CSP環境中直接訪問，每次加密解密不再需要密鑰加密密鑰（KEK）。

在列出的所有實現選項中，數據加密密鑰都由CSP的KMS生成，可以導出，也可能無法導出。DEK用于加密界定范圍的數據（例如，按存儲桶、日期、文件等），而這些DEK用KEK加密。

BYOK的好處和風險

BYOK旨在為云客戶提供更多控制，方便云客戶更好地管控自己托管的數據。事實上，使用BYOK更像是共享自己的密鑰（SYOK），因為一旦將密鑰提交給CSP，客戶就無法控制其使用了。SYOK的唯一好處，大概是能在你不信任他們的隨機數生成器時還能確保密鑰隨機性。否則，你就也讓CSP生成密鑰了。

有些CSP也會以另外的模式提供BYOK，這種形式的BYOK連接客戶存儲并控制KEK的硬件。這種模式存在幾個突出的問題。

除了能夠通過技術手段或社會工程突破CSP保護措施的惡意黑客，服務提供商也能有意無意地訪問DEK，無論是在內存、緩存、日志文件或惡意代碼庫中。KEK駐留內存就是把雙刃劍，因為這么做根本就是為了更好的性能而踐行SYOK了。但既然都那樣了，為什么不直接上SYOK呢？

另一個問題是服務提供商可能不會用客戶KEK來保護DEK。CSP架構、代碼和各種產品還可能存在安全漏洞，會導致遭遇攔截或竊聽。即使動態解密DEK（通常不支持或不推薦），通信問題也可能會令業務陷入停頓，妨礙解密現有數據和加密新的DEK。

信任也是與CSP合作中的一個關鍵問題。信任應該源自認證和第三方審計。采用CSP管理自身敏感數據或生產的參考客戶可能也是加強這一信任的重要因素。你得確定是否信任CSP的身份驗證和授權安全。即使采用聯合安全，也并不意味著沒有額外的身份驗證和提權手段。

簡而言之：BYOK既解決不了問題，也不能減小風險！

我們還能做些什么呢？

大多數CSP都會為客戶提供自助撤銷、輪換和控制KEK的功能。在變動或授予CSP對數據的訪問權之前保護好數據可能會增強安全。但這么做其實沒什么好處，而且大多建議用于保護PII/PHI或其他受嚴格監管的數據。

最重要的因素是考慮所有入站和出站渠道，包括API和文件傳輸，以及各種特權訪問需求。在這方面，還可以擴展到采用基于角色或基于屬性的訪問控制進行身份驗證和授權，從而確保不可否認性、數據衛生和零信任等行業最佳實踐。

總結

本文的目的是要提起重視而非詆毀CSP。但BYOK基本上就是蒙人用的所謂萬靈藥。這東西常被誤認為是云端無需CSP信任即可起效的神藥。

SYOK毫無價值。既然假設CSP不能為KEK生成足夠隨機的密鑰，為什么還要依賴它來實現DEK？確保擁有設計良好的安全架構，并經常重新評估、測試和監測這個架構，才是重中之重。