目前，在云中使用用户自己的加密产品已变得更为普遍。专家Ed Moyle在本文中讨论了BYOE的优缺点，以及用户在正式实施前所需了解的内容。

花几分钟时间与大多数技术人员讨论下公共云服务，你很快就会得到一个肯定的结论：从安全性的角度来看，云应用具有较大的挑战性。在一定程度上，这是云本身的固有特性决定的。让云变得有价值和强大的原因之一就是先进技术基础的商品化，这就意味着技术堆栈一定层面以下的一切（具体层面高低因云模式不同而不同）在客户眼中就是一个黑盒。这是非常强大的，因为它意味着客户可以重定向资源，否则它将在技术管理上花费更多而使用其他更直接可用的方法。

从安全性的角度来看，这是有一些含义的。首先，它意味着潜在地放弃了对服务供应商技术安全控制操作的责任部分，这可能是更厌恶风险的大型用户或对严格监管企业所最不愿意出现的情况。它还可能影响某些控件的操作和安全性。例如在加密的情况下，密钥所有权的问题成为了一个重要点。当企业用户放弃对密钥管理的控制与控制而交给服务供应商时，服务供应商的必要性就变为访问密钥，以及扩展至密钥所保护的数据。

这意味着服务供应商在实际应用有需要时拥有访问加密数据的能力。例如，当服务供应商收到来自于执法部门访问数据请求的情况下，尽管数据是被加密的，但也不存在任何访问数据的技术障碍。同样，服务供应商的技术或管理安全体系中的漏洞（例如密钥管理、过期或密钥访问）都可能将存储数据置于风险之中。

实施BYOE的好处

正因如此，目前更常见的是服务供应商在这种应用中推崇BYOE（自己带加密工具）的概念——有时被称为BYOK（使用你自己的密钥）。在此模式下，客户而不是CSP成为了密钥的所有者和管理者。从而让客户拥有使用现有密钥管理、加密、存储或软硬件组合的能力，与服务供应商一起实现加密功能但限制服务供应商对密钥的访问。

根据具体实施情况不同，BYOE可以允许用户使用硬件安全模块、第三方密钥管理工具、访问管理与日志记录工具以及其他的密钥代理功能。这种方法为客户提供了许多潜在的好处。首先也是最明显的是，这意味着要求云客户处于数据共享循环之中，其中也包括了接收方是执法部门的情况。也就是说，这种方式创造了一个技术壁垒，必须有客户首肯才能访问数据。

确保云客户身处循环之中是非常有价值的，但是BYOE有其他方法可以让客户受益。例如，它可以在企业用户寻求变更服务供应商时有所裨益。如果一家服务供应商需要退出云业务，客户是唯一可以访问密钥的人这一事实可以提供一定水平的保证，即当合作关系终止时，服务供应商将不再能够访问数据。同样，对于那些希望确保数据存储地理限制的企业用户来说，BYOE将可以有助于实现这一点——即使数据被存储在非客户所期望的其他区域，客户也可以通过保留密钥所有权来控制数据的访问程度。

实施中的注意事项

考虑到BYOE的优势，云客户的下一个合乎逻辑的问题就是实施的相对复杂性——即，在任何BYOE方法可用的情况下，具体实施的难易程度。

需要重点指出的是，并不是每一家云供应商都为他们所提供的每一个服务提供了BYOE选项。亚马逊在它的AWS密钥管理服务中提供了BYOE选项，而微软在Azure Key Vault中提供了这一选项，此外Salesforce则在最近推出的Shield产品中提供了这个功能。在存储领域，诸如Box和Tresorit这样的供应商也为客户提供了使用他们自己密钥的功能。但是，并不是所有的CSP（尤其是规模较小的供应商）都已经实现了这个功能。所以，对于认为这个功能非常重要的企业用户，他们需要认识到，能够提供这项功能的服务供应商选择范围可能是比较有限的。

此外，企业用户在他们试图实施BYOE之前对自身准备情况具有一定程度的自我认知也是非常重要的。很多企业加密实施方面并不是非常严格或认真的，如密钥管理程序、密钥到期以及其他具体实施细节等。如果用户企业已经在企业内部实施中遇到了密钥管理方面的挑战，那么他们所要做的并不仅限于将其扩展至BYOE——他们可能需要考虑它与其边界外的混乱情况。此外，企业还需了解其环境中的影子IT使用情况，这一点也很重要，因为如果他们不了解云应用情况就有可能不会使用BYOE功能，直到用户有意识地使用。

最后重要的一点是企业用户已经做好了处理与支持BYOE功能相关的可用性和物流支撑事项的准备。如果云供应商请求密钥来完成一个特定操作，那么环境需要做好支持它的准备。企业用户是否安排了工作人员来服务密钥创建？企业用户是否已经适当地设置了其内部访问权限以便只有那些获授权的工作人员才能创建和访问密钥？这些BYOE应用与在内部部署密钥管理应用是同等重要的。

BYOE能够为用户带来巨大的价值和灵活性，但是能否最大限度发挥其作用将取决于实施者在前期的准备工作和思考是否周密完备。