涉及加密的"经典"数据安全错误之一是对数据进行加密而未能保护加密密钥。更糟糕的是，一个很常见的问题是让密钥"靠近"数据，例如与加密文件在同一数据库或同一系统中。据报道，这种做法是造成一些突出数据泄露的一个因素。有时，一项调查显示，加密是为了合规而实施的，并且没有明确的威胁模型，认为密钥管理是事后考虑的，甚至没有考虑到。

有人可能会说，密钥必须比加密的数据得到更好的保护（或者，更一般地说，密钥必须比它保护的数据具有更强的控制能力）。如果密钥存储在数据附近，大数据主要学什么，这意味着保护密钥的控制实际上并不是更好的。

法规确实提供了密钥管理方面的指导，但很少有人就如何保存与加密数据相关的加密密钥给出准确的建议。显然，让密钥远离数据是一种很好的安全实践，但遗憾的是，有足够多的组织误解了这种做法。你怎么测量"远"呢？

现在，让我们将云计算添加到等式中。最近几年出现的一个特别的想法是："就像你不能把钥匙放在同一个数据库里一样，你也不能把它放在同一个云中。"

这里的预期反应是，一半的读者会说"显然！"而另一半可能会说"什么？太疯狂了！"这就是为什么这是一个伟大的分析主题！

现在，首先，让我们指出显而易见的一点：没有"云"。而且，不，何为大数据，这不是一个流行的说法，它是"别人的电脑"。在这里，我们谈论的是缺乏任何单片称为"云"。例如，当我们加密数据的休息，有一系列的密钥管理选项。事实上，我们总是使用我们的默认加密和存储密钥安全（相对于特定的威胁模型和要求）和透明。你可以在本文中详细阅读。但是，您会注意到，密钥总是与加密数据分离，有许多不同类型的边界。例如，在应用程序开发中，一个常见的最佳实践是将密钥保存在独立于工作负载的项目中。因此，这些将引入额外的边界，如网络、身份、配置、服务以及其他可能的边界。关键是，将密钥"放在同一个云中"并不一定意味着你犯了与将密钥放在同一个数据库中相同的错误。。。。除少数特殊情况外（这些情况将在下面讨论）。

此外，人工智能技术发展，云计算还引入了一个新的维度，即保持密钥"接近"数据的风险：密钥的物理存储位置与密钥的控制者。例如，如果密钥位于与数据位于同一网络（或：同一云数据中心）上的安全硬件设备（即HSM）内，则密钥是否靠近数据？或者，如果密钥位于另一个国家/地区的系统中，但具有访问数据的凭据的人也可以访问密钥，则密钥是否与数据接近？这也提出了一个问题：如果钥匙被泄露，最终由谁来负责，这使问题更加复杂。所有这些都提出了值得探讨的有趣的方面。

最后，请记住，这里的大多数讨论都集中在静态数据上（也许有一点是在传输中的数据，但不是在使用中的数据）。

风险

既然我们理解了"在同一个云中"的概念是微妙的，那么让我们看看驱动行为的风险和需求关于加密密钥存储。

在我们开始之前，请注意，如果您有一个架构不完善的内部应用程序，它确实将密钥存储在与加密数据相同的数据库或磁盘上，并且该应用程序迁移到云端，那么问题当然也会迁移到云端。这个挑战的解决方案可以是使用云本机密钥管理机制（是的，这确实涉及到更改应用程序）。

也就是说，这里有一些相关的风险和问题：

人为错误：首先，一个非常明显的风险当然是非恶意的人为错误，导致密钥泄露、丢失、盗窃，等等。想想开发人员的错误，使用了一个糟糕的熵源，错误的配置或者松散的权限等等。它们没有云的特定性，但是它们的影响在公共云中往往更具破坏性。理论上，云提供商的错误导致潜在的密钥泄露也在这个桶里。

外部攻击者：第二，外部攻击者窃取密钥也是一个挑战，可以追溯到前云时代。众所周知，顶级参与者攻击密钥管理系统（KMS）以获得更广泛的数据访问。他们还知道如何访问和读取应用程序日志以及观察应用程序网络流量，所有这些都可以提供有关密钥位置的提示。出于本能，许多在云计算之前积累了大量经验的安全专业人员对位于防火墙后面的KMS感觉更好。外部攻击者往往会发现上述人为错误，并将这些弱点转化为妥协。

内部威胁：第三，这就是事情变得有趣的地方：内部人呢？云计算模型意味着两种不同的内部人模型：来自云用户组织的内部人和来自云提供商的内部人。虽然一些公众的注意力集中在CSP内部人员身上，但客户内部人员通常拥有访问数据的有效凭证。虽然一些CSP提供商的员工可以（理论上并受许多需要大量合谋级别的安全控制）访问数据，但实际上是云客户的内部人员通过有效凭据直接访问他们在云中的数据。从威胁建模的角度来看，大多数不好的参与者会发现最薄弱的环节——可能是在云用户组织——在付出更多努力之前先加以利用。