我开发了一个工具，可以在运行时加载到配置文件中。有些值是用AES密钥加密的。
该工具将安排在远程机器上定期运行。向程序提供解密密钥的可接受方式是什么。它有一个命令行接口，我可以通过它。我目前可以看到三个选项
- 通过CLI提供完整密钥，这意味着该密钥在操作系统配置级别的clear中可用（即CronJob）
- 通过源代码将密钥硬编码为二进制。出于多种原因，这不是一个好主意。（可分解，便携性较差）
- 使用
1和2的组合，即在exe中有一个基密钥，然后通过CLI接受部分密钥。这样，我可以对多台机器使用相同的构建，但它不能解决反编译exe的问题
值得注意的是，我并不太担心反编译exe来获取密钥。如果我确信有一些方法可以通过混淆等来解决
最终，如果我真的有意识的话，我不会把密码存储在任何地方。
我想听听什么是最佳实践。谢谢
我之所以添加Go标签，是因为该工具是用Go编写的，只是为了以防万一有一个神奇的Go包可能会有所帮助，除此之外，这个问题实际上并不是特定于某项技术。
更新：：我正在努力保护密钥不受外部攻击者的攻击。不是机器的常规物理用户。
这类系统的最佳实践是两件事之一：
-
系统管理员在启动期间进行身份验证，并在控制台上提供密码。这通常非常不方便，但很容易实现。
-
硬件设备用于保存凭据。最常见和最有效的被称为HSM（硬件安全模块）。它们有各种格式，从USB钥匙到插件板，再到外部机架安装设备。HSM带有它们自己的API，您需要与之接口。HSM的主要特点是它从不泄露密钥，而且它有物理保护措施来防止密钥被提取。你的应用程序会向它发送一些数据，它会对数据进行签名并返回。这证明硬件模块已连接到此计算机。
对于特定的操作系统，您可以使用本地安全凭据存储，这可以提供一些合理的保护。Windows和OS X尤其具有这些，通常键入管理员在启动时需要键入的某些凭据。我不知道Linux有什么特别有效的，而且一般来说，这在服务器设置中非常不方便（因为系统管理员手动干预）。
在我处理过的每一个案例中，HSM最终都是最好的解决方案。对于简单的用途（比如启动应用程序），你只需几百美元就可以获得它们。再加上一点"滚你自己的"，我见过它们便宜到50美元。（我没有特别回顾这些。我主要使用过价格稍贵的产品，但基本想法是一样的。）