目前，我有许多脚本需要以超级用户身份登录才能自动执行许多任务。（例如，在数据库中创建表，创建其他用户等）
我没有将凭据（尤其是密码）直接存储在脚本中，而是从一个文件（称为 pwds.txt）中读取它们，该文件只能由 root 用户访问。
我的一些同事说，更安全的方法是在 pswds.txt 中加密密码，将密钥隐藏在某处，并在我使用之前解密脚本中的加密数据。
我声称它只是将问题减少到查找密钥所在的位置，这对于可以阅读脚本的对手来说似乎并不难。我认为这个过程只会使编程复杂化，而实际上并没有提供任何真正的保护层。
两个问题：
1) 你是 100% 正确的，为什么？如果机器受到攻击，攻击者仍然能够检索解密密钥，因为应用程序必须进行对称加密才能解密，并且密钥文件必须具有与应用程序相同的读取权限，以便应用程序可以读取它。
我的意思是应用程序仍然需要在其中包含硬编码的秘密解密密钥目录，因此攻击者只需查找它：D，即使应用程序是二进制可执行文件，攻击者也可以轻松地从中转储文件目录和文件的字符串。
我知道是因为我是从需要调试的 Go 语言程序中完成的，而且我没有源代码（服务器上托管的客户端应用程序之一）:)
如果存在漏洞，则缓冲区溢出等攻击将起作用，因为应用程序以太方式将数据存储在内存中以重用，例如用于数据库身份验证。
2）最好的解决方案是有一个中央保险库，每个应用程序都在其中请求其秘密并出租它们。此类解决方案之一是https://www.vaultproject.io/以及有关它的更多详细信息https://www.vaultproject.io/docs/internals/architecture.html
最佳常规做法是最小化每个角色对每个应用程序资源的访问和控制权限。示例：如果应用只使用一个数据库，则不授予该用户查看其他数据库或在其他数据库上执行 DML 的权限，如果应用不执行迁移，则删除删除表权限，依此类推。
如果脚本由示例 root 用户执行，则不使用保管库，则不要存储具有较低特权用户所有权的机密。让所有者是同一个用户，只使用你真正需要的读、写、执行权限。
尽可能为您的资源使用 TLS，因为如果攻击者设法获得身份验证阶段但您存储秘密数据，则一个 tcp 转储会泄漏数据。