您将加密密钥放在面向公众的服务器上的什么位置？答案

【问题标题】：Where do you put an encryption key on a public facing server?您将加密密钥放在面向公众的服务器上的什么位置？
【发布时间】：2011-02-01 16:59:54
【问题描述】：

我在我的 Web 应用程序和服务之间使用 NServiceBus 和 MSMQ，并且我需要能够加密消息有效负载，以便如果消息在 Web 服务器上本地排队（服务主机已关闭），敏感数据不能被查看。

因为网络服务器是面向公众的，所以我不仅需要加密可能无论如何都会序列化到磁盘的数据，而且我也不能将加密密钥存储在网络服务器上。

我考虑过使用 DPAPI 来存储密钥，但由于密钥将存储在主机上，我还不知道这是否违反要求。我考虑过的另一个选项是，当 Web 应用程序启动时，它可以从服务中请求密钥，并将其保存在内存中，直至应用程序池的生命周期。

我以前没有处理过这种级别的加密要求，我想了解其他人在做什么，并就上述想法获得一些反馈。

【问题讨论】：

无论您做什么，请聘请安全顾问来验证您的设计/实施的有效性。如果您不是该领域的专家，那么犯错误是微不足道的，与花钱请人帮助您纠正错误的成本相比，错误的成本可能是巨大的。参看。 Heartland 支付系统。
这并不是非对称密码学解决的问题。
非对称密钥至少会降低观察者从磁盘读取现有状态的可能性。尽管手头有非对称密钥，但观察者可以使用它来发起暴力攻击。

【解决方案1】：

您可以使用公钥/私钥加密吗？那么你只需要在服务器上公钥，在别处使用私钥解密数据。

【讨论】：

值得注意的是，公私加密可能需要大量的加密安全熵（对于消息密钥、IV 和填充）——这可能是高吞吐量的问题。
是的，我同意 - 非对称密钥会有很大帮助。在高吞吐量系统中，要实现足够强大的加密可能需要很大的马力。在我们的一个场景中，我们转向了加密硬件——昂贵、难以集成，但值得。
听起来不错，但我不确定我能否获得批准。就像你说的没有专用硬件，非对称加密会扼杀吞吐量。我考虑过仅对密钥使用非对称密钥，但解密密钥的密钥仍需要存储在 Web 应用程序可以访问的地方。

【解决方案2】：

“因为网络服务器是面向公众的，所以我不仅需要加密可能无论如何都会序列化到磁盘的数据，而且我也不能将加密密钥存储在网络服务器上。”

似乎这是唯一需要关注的约束 - 验证它对于初学者来说是正确的。它将排除 DPAPI + 本地密钥存储方法。

通过服务传递密钥是合理的，但该服务仍然需要对调用者进行身份验证。如果您的服务器被伪装成合法调用者，观察调用等都是可能的。此外，如果您仅将密钥存储在内存中，则该内存仍然可以在调试器或内存转储、提升的特权进程等中发现。

硬件加密卡是克服后一种情况的唯一方法。

【讨论】：

我认为您通过服务交付密钥是正确的。虽然我被告知我们不能将密钥存储在网络服务器上，但我怀疑我是否会获得硬件加密卡的批准。我一直在关注 DPAPI，如果我使用用户范围而不是机器范围，我可能会获得批准。我的经理整天都在开会，所以我必须等到那时才能获得批准。

【解决方案3】：

您可以覆盖 NServiceBus 从中提取其加密密钥的来源 - 此处的文档中对此进行了描述：http://docs.particular.net/nservicebus/security/encryption

这样，您可以避免将这些敏感信息留在 DMZ 中。

【讨论】：

【解决方案4】：

encrypt is at the queue level 的最佳去处。您通过sending private messages 执行此操作并创建只接受私人消息的队列。虽然您可以在创建队列时设置队列隐私级别，但我不确定您是否可以将 NServiceBus 配置为发送私人消息。

【讨论】：

是的，我看过这个，但根据您链接中的文档：“发送私人消息时，消息队列确保消息的正文从离开的那一刻起就保持加密状态源队列管理器到它们到达目标队列管理器的那一刻。”我还需要在队列中加密消息，而 MSMQ 似乎本身不支持此功能。