作为负责任的管理员，我们知道常见的弱点，例如
- CWE-260：配置文件中的密码http://cwe.mitre.org/data/definitions/260.html
- CWE-522：凭证保护不足http://cwe.mitre.org/data/definitions/522.html
- CWE-257：以可恢复的格式存储密码http://cwe.mitre.org/data/definitions/557.html
但在实践中我们该如何处理这个问题呢？
当然，借助通过 SSH 进行无密码身份验证等技术和 sudo 之类的工具，可以摆脱在重要位置存储的登录凭据，这对 Linux 服务器的自动部署非常有帮助。
但是，一旦您离开操作系统并安装应用程序，很有可能会面临如何安全地存储密码的问题。
例如，如果您安装了数据库服务器，很可能需要将明文密码保存到 Web 应用程序的配置文件中。
然后，您应该保护配置文件，以便只有管理员能够查看凭据，并且您应该限制数据库用户的访问权限，以限制可能的安全影响。
但是如何处理主管理数据库帐户？至少你的数据库管理员应该知道它（所以你需要某个地方的明文），作为操作系统管理员，你应该不是知道凭证。或者部署是由 DevOps 完成的，他们不应该知道任何生产服务器上的凭证。
可能的解决方案
经过较长时间的思考，我提出了三种可能的解决方案，但它们都有各自的弱点：
在部署期间生成随机凭据，并以一次写入的方式将其存储在数据库中。例如，dbas 有另一个用户可能只读取数据库凭据。但如何处理配置文件中的明文密码（例如 webapps）？root 用户可以读取它们。密码数据库的 root 用户也可能读取全部密码凭证。
在部署期间接受明文密码和默认凭据，并添加更改的后记任何和所有密码。甚至可能是交互式的，授权人员必须在脚本运行时输入凭据。
使用受信任的第三方的密钥对密码进行非对称加密。当密码被请求时，它必须是后来发生了改变。
您觉得如何？您认为这里有任何最佳实践吗？
答案1
- 您应该拥有一个包含所有凭据的安全加密数据库
- 在部署期间，服务器应完全无法通过防火墙从外部访问
- 可以使用脚本生成随机通行证并通过电子邮件发送给你
- 在服务器配置完成后，在允许公众访问之前，也可以更改密码
- 通过电子邮件向自己发送密码是可以的，只要使用内部邮件服务器并且不通过 SMTP 上的公共邮件路由即可（SMTPS 是另一回事）
您可以使用任何协议来替代电子邮件。您可以将密码通过 sftp 传输到某处，使用 onetimesecret api 创建一次性消息，使用 https 将其上传到私人 gist，或者您能想到的任何其他方式。
我想这就涵盖了。