Encryption 计划进程-为加密配置提供密钥

我开发了一个在运行时加载到配置文件中的工具。某些值使用AES密钥加密

该工具将被安排在远程机器上定期运行。向程序提供解密密钥的可接受方式是什么。它有一个命令行界面，我可以通过它。我目前可以看到三种选择

通过CLI提供完整密钥，这意味着该密钥在操作系统配置级别（即CronJob）的clear中可用

通过源代码将密钥硬编码到二进制文件中。这不是一个好主意，原因有很多。（反编译和可移植性较差）

结合使用

1

和

2

，即在exe中有一个基本密钥，然后通过CLI接受部分密钥。这样，我可以对多台机器使用相同的构建，但它不能解决反编译exe的问题

值得注意的是，我并不太担心对exe进行反编译以获取密钥。如果我确定我可以通过模糊处理等方式解决问题

最终，如果我真的有意识，我就不会把密码存储在任何地方

我想听听什么是最佳实践。谢谢

我添加了Go标签，因为该工具是用Go编写的，以防有一个神奇的Go包可能会有所帮助，除此之外，这个问题实际上并不特定于某项技术

---

更新：：我正试图保护密钥免受外部攻击者的攻击。不是机器的常规物理用户。

此类系统的最佳实践是以下两个方面之一：

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

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

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

---

在我研究过的每一个案例中，HSM最终都是最好的解决方案。对于简单的用途（如启动应用程序），对于更多的“自己滚吧”（我不是特别回顾这些内容。我主要使用的是a，但基本思想是一样的。）

这里不清楚您是在保护信息不受谁的影响。如果来自外部攻击者，您的用户可以安全地提供解密密钥。如果您试图保护这些信息不受用户的影响（这听起来像是因为您讨论了将密钥硬编码为二进制），那么没有加密方案可以提供这一点。你能做的最好的是模糊处理，而且（几乎是根据定义）没有一个最佳的模糊处理实践。