存储数据库密码的最佳实践
我正在开发一个将访问数据库的自定义服务器应用程序。 我需要决定将凭据（和地址）存储到该服务器的位置。
常见的解决方案是将凭证放在配置文件中。 但是，我不希望受感染的服务器意味着黑客可以访问数据库（托管在单独的服务器上）。
我可以将凭据存储在环境中，但这只是通过默默无闻的安全性。 Evil先生可以在环境中寻找它。
有人建议加密。 但是，如果我将密钥存储在可执行文件中，快速解编译（我们使用的是Java），我仍然注定失败。
我还想避免每次启动服务器时都输入一个释义。
有什么建议么？ 我觉得我错过了一些简单的事情。
谢谢
我不认为你错过了一些简单的东西。 有问题的服务器可以在没有您帮助的情况下连接到数据库，在这种情况下，它必须具有凭据; 或者在没有供应的情况下无法连接。 您可以采取各种步骤，例如您列出的步骤，使受感染的服务器更难以向数据库显示凭据，但最终，如果必须拥有这些凭据并将其提供给数据库服务器要连接，它们必须存储在某个地方 – 或者至少，它必须有一些获取它们的方法，因此在这个意义上是可以破解的。
您最好的选择是尽可能快地找出入侵（受损服务器），为最坏情况保留良好的异地，离线备份，首先为入侵设置许多障碍，等等。
我正在分享，我解决这个问题的方式。
- 构建API，以从外部域查询身份validation详细信息。
- 使用公钥和私钥来读取详细信息。
但是，说实话，唯一能做的就是复杂的简单事情。 之后，我使用不同的权限为数据库创建了多个用户。
喜欢
-
guest只能SELECT -
mod只能CREATE，INSERT，UPDATE，DELETE
每当出现身份validation的用户时，都会切换用户。
通过用户和会话的组合，到目前为止我已经能够逃脱威胁。 但是，当然代码漏洞必须彻底测试。
锁定它。 防止Evil先生获得成功。 我知道，对吗？
编写安全的应用程序并锁定应用程序服务器。 遵循那里的最佳实践，这是大部分工作。
当我在安全环境中设置数据库时，与数据库服务器位于同一物理网络上的唯一服务器是应用程序服务器。 有两种方法可以访问数据库服务器：
- 应用服务器
- 安慰
因此，为了破坏数据库服务器，他们必须妥协应用程序服务器。
因此，锁定应用程序服务器。 当然，唯一比受到损害的更糟糕的事情就是妥协并且不了解它。 如果您确实发现了泄密，则需要修复漏洞（如果存在漏洞）。 取证在这里很重要（启用日志并监控它们）。 您还需要制定恢复计划。
预防，检测，纠正和恢复至关重要。