我开发了一个在运行时加载配置文件的工具。一些值使用 AES key 加密。
该工具将被安排在远程机器上定期运行。向程序提供解密 key 的可接受方式是什么。它有一个命令行界面，我可以通过它。我目前可以看到三个选项
- 通过 CLI 提供完整的 key ，这意味着 key 在操作系统配置级别(即 CronJob)以明文形式提供
- 通过源代码将 key 硬编码到二进制文件中。出于多种原因，这不是一个好主意。 (反编译和不太便携)
- 使用
1和2的组合，即在 exe 中有一个基本 key ，然后通过 CLI 接受部分 key 。这样我可以在多台机器上使用相同的构建，但它并没有解决反编译exe的问题。
值得注意的是，我不太担心反编译exe来获取 key 。如果我确定我可以通过混淆等方式解决问题。
最终，如果我真的有意识，我就不会在任何地方存储密码。
我想听听什么是最佳实践。谢谢。
我添加了 Go 标签，因为该工具是用 Go 编写的，以防万一有一个神奇的 Go 包可能会有所帮助，除此之外，这个问题并不特定于技术。
更新::我正在尝试保护 key 免受外部攻击者的攻击。不是机器的普通物理用户。
最佳答案
这种系统的最佳实践是两件事之一:
系统管理员在启动期间进行身份验证，在控制台提供密码。这通常非常不方便，但很容易实现。
硬件设备用于保存凭据。最常见和有效的称为 HSM(硬件安全模块)。它们有各种形式，从 USB key 到插件板再到外部机架安装设备。 HSM 带有自己的 API，您需要与之交互。 HSM 的主要特点是它从不泄露其 key ，并且它具有防止 key 被提取的物理保护措施。您的应用程序向它发送一些数据，它对数据进行签名并返回。这证明硬件模块已经连接到 native 。
对于特定的操作系统，您可以使用本地安全凭证存储，这可以提供一些合理的保护。 Windows 和 OS X 尤其具有这些功能，通常与管理员在启动时需要输入的某些凭据有关。我不知道对 Linux 有什么特别有效的方法，而且通常这在服务器设置中非常不方便(因为系统管理员手动干预)。
在我处理过的每个案例中，最终 HSM 都是最佳解决方案。对于简单用途(如启动应用程序)，you can get them for a few hundred bucks.多一点“自己动手”，I've seen them as cheap as $50. (我没有特别回顾这些。我主要使用 bit more expensive ones ，但基本思想是相同的。)
关于encryption - 预定过程 - 为加密配置提供 key ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33600982/