预定过程 - 为加密配置提供密钥

Question

我开发了一个在运行时加载到配置文件中的工具。某些值使用 AES 密钥加密。该工具将被安排在远程机器上定期运行。向程序提供解密密钥的可接受方式是什么。它有一个命令行界面，我可以通过它。我目前可以看到三个选项通过 CLI 提供完整的密钥，这意味着密钥在操作系统配置级别（即 CronJob）清晰可用通过源代码将密钥硬编码到二进制文件中。由于多种原因，这不是一个好主意。（反编译和便携性较差）使用的组合1，并2即有在EXE基地键，然后接受通过CLI部分关键。这样我可以在多台机器上使用相同的build，但是并没有解决反编译exe的问题。值得注意的是，我并不太担心反编译exe获取key。如果我确定有办法通过混淆等解决问题。最终，如果我真的有意识，我不会将密码存储在任何地方。我想听听什么是最佳实践。谢谢。我添加了 Go 标签，因为该工具是用 Go 编写的，以防万一有一个神奇的 Go 包可能会有所帮助，除此之外，这个问题并不是特定于技术的。更新:: 我试图保护密钥免受外部攻击者的侵害。不是机器的常规物理用户。

Answer 1

这种系统的最佳实践是以下两件事之一：

• 系统管理员在启动期间进行身份验证，并在控制台提供密码。这通常非常不方便，但很容易实现。

• 硬件设备用于保存凭证。最常见和最有效的称为 HSM（硬件安全模块）。它们有各种格式，从 USB 密钥到插件板，再到外部机架安装设备。HSM 带有自己的 API，您需要与之交互。HSM 的主要特征是它从不泄露其密钥，并且具有物理保护措施以防止其被提取。您的应用程序向它发送一些数据，然后对数据进行签名并返回。那证明硬件模块连接到了这台机器上。

对于特定的操作系统，可以利用本地安全凭证存储，提供一些合理的保护。Windows 和 OS X 尤其有这些，通常与管理员在启动时需要输入的某些凭据有关。我不知道对 Linux 有什么特别有效的方法，通常这在服务器设置中非常不方便（因为手动系统管理员干预）。

在我处理过的每种情况下，最终 HSM 都是最好的解决方案。对于简单的用途（例如启动应用程序），您可以花几百美元购买它们。对于更多的“自己动手”，我已经看到它们便宜到 50 美元。（我不是专门审查这些。我主要使用更昂贵的那些，但基本思想是相同的。）