隐藏长寿命加密密钥的最佳位置是什么答案

【问题标题】：What's the best place to hide long lived encryption keys隐藏长寿命加密密钥的最佳位置是什么
【发布时间】：2016-05-23 22:15:26
【问题描述】：

我正在考虑新 Sybase 项目的加密选项。我认为 Sybase 加密是错误的策略，因为 a) dba 可以进入，b) 如果我们迁移到 SQL Server 或 Oracle，我不想处理不同的加密策略。

因此，我正在考虑在我的 Java 代码中加密敏感数据（对称加密），然后再将其存储到数据库中。

现在，加密字段最好永远不要更改其加密密钥，除非在非常受控的环境中，这对我来说实际上意味着永远不会。所以这将是一个永久密码。

问题是，我应该将这个密码保存在哪里，以便程序可以访问但其他人无法访问。如果它在属性文件中，任何有权访问我们的 Git 存储库的开发人员都可以看到它。

我们可以在源代码中对其进行硬编码，但是好的法律，这是一种不好的做法。

我们可以在源代码中生成它，例如 10th Fibonacci 或 3!+8!这将很难找到，但它仍然相当暴露。

我们可以让 sa 在环境中维护它，但是他们在哪里归档以供将来参考？

这么多糟糕的选择。有没有好的？

【问题讨论】：

Put it in a properties file, but list this file in .gitignore.
我投票结束这个问题，因为它不是直接的编程问题。这更像是一个安全设计问题，我相信在Information Security Stack Exchange 网站上会更合适。
@TobySpeight 这确实是一个编程问题。我会改写它，但我的主要问题是“您将这些密码安全地存储在哪里，以便程序可以访问它们但没有人可以访问它们”
你不讨厌人们不发表评论就投票给你

【解决方案1】：

简单地使用一些密码来动态创建密钥既是一种不安全的方法，也会产生一个糟糕的密钥。数据库保持需要是一个随机字节数组。请记住，密钥在使用时需要在内存中，这将是数据库的大部分时间。

WRT 使用 DB 加密，仔细检查算法是否完全指定以及与另一个 DB 的兼容性。也有可能整个数据库需要被淘汰，然后添加到一个新的数据库中，在这种情况下，使用内部数据库加密将是透明的。

您确实需要考虑将来需要能够更改加密密钥，如果它被泄露，您会怎么做？有解决这个困境的办法。在 DB 之外执行加密可能会造成很大的性能损失，每个新的加密操作都有相当长的设置时间。此外，由于并非所有列都会被加密（一个很好的猜测），数据库和外部加密代码不共享信息，这种耦合不利于设计和维护。

不要将 DB 服务器连接到 Internet，将其分开并通过非网络连接（例如直接以太网）连接。这也限制了包含加密密钥的唯一系统的管理员用户数量。

解决方案的另一个重要部分是限制管理员对服务器的访问。这包括要求双重身份验证以及严格限制管理员的数量。您需要控制组织拥有的物理序列号设备的第二个因素，以便可以在人员变动时积极检索它们而不是复制它们。我个人更喜欢 RSA SecureID（或类似的）硬件设备，有正向控制。

最后回答这个问题，将密钥保存在数据库服务器上的文件中，如上所述，即无法访问 Internet 且管理员访问受限。

【讨论】：

一些笔记和问题。这是一个内部应用程序，数据库位于我们的 Intranet 后面。并非所有列都需要加密。实际上所有敏感的东西都在一个表的一列中，除了生产服务之外，没有人可以访问产品数据库。但该公司要求敏感数据必须加密，因此如果密钥保存在数据库中，则 DBA 可以使用它，因此它基本上没有加密
如果您试图向系统管理员隐藏加密密钥，则希望渺茫。如果数据相对较小，则可以选择购买包含密钥并执行加密/解密的外部设备（HSM 或类似设备），因此密钥永远不可用，然后必须安全地管理该设备。也可以进行双重监管，这样任何人都无法访问该设备。价格从 500 美元左右到 10 万美元不等，很大程度上取决于所需的直通式：条目大小 * 条目/分钟。