自带密钥（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？确保拥有设计良好的安全架构，并经常重新评估、测试和监测这个架构，才是重中之重。