16

我正在开发一个将访问数据库的自定义服务器应用程序。我需要决定将凭据（和地址）存储到该服务器的位置。

一个常见的解决方案是将凭证放在配置文件中。但是，我不希望受感染的服务器意味着黑客可以访问数据库（托管在单独的服务器上）。

我可以将凭据存储在环境中，但这只是通过默默无闻的安全性。邪恶先生可以在环境中寻找它。

有人建议加密。但是，如果我将密钥存储在可执行文件中，快速反编译（我们使用的是 Java），我仍然注定要失败。

我还想避免每次启动服务器时都必须输入释义。

有什么建议么？我觉得我错过了一些简单的东西。

谢谢

4

3 回答 3

8

我不认为你错过了一些简单的东西。有问题的服务器可以在没有您帮助的情况下连接到数据库，在这种情况下，它必须具有凭据；或者如果没有您提供它们，它就无法连接。您可以采取各种步骤，例如您列出的步骤，以使受感染的服务器更难向数据库透露凭据，但归根结底，如果它必须拥有这些凭据并将其提供给数据库服务器要连接，它们必须存储在某个地方——或者至少，它必须有一些获取它们的方法，因此在这个意义上是可以破解的。

你最好的选择是专注于尽快发现入侵（受损的服务器），在最坏的情况下保持良好的异地、离线备份，首先设置大量的入侵障碍，等等。

于 2012-04-17T12:37:40.677 回答
4

我正在分享，我解决这个问题的方式。

  • 构建 API，从外部域查询认证细节。
  • 使用公钥和私钥阅读详细信息。

但是，老实说，这样做的唯一一件事就是把简单的事情复杂化了。之后，我为数据库创建了几个具有不同权限的用户。

像

  • guest只能到SELECT
  • mod只能CREATE,,,, INSERT_ UPDATE_DELETE

等并在经过身份验证的用户出现时切换用户。

通过用户和会话的结合，到目前为止我已经能够逃脱威胁。当然，代码漏洞必须经过彻底的测试。

于 2012-04-17T12:40:48.977 回答
2

把它锁起来。防止邪恶先生扎根。我知道，容易吧？

编写一个安全的应用程序并保持您的应用程序服务器处于锁定状态。遵循那里的最佳实践，这就是大部分工作。

当我在安全环境中设置数据库时，与数据库服务器位于同一物理网络上的唯一服务器是应用程序服务器。访问数据库服务器有两种方式：

  1. 应用服务器
  2. 安慰

因此，为了破坏数据库服务器，他们必须破坏应用程序服务器。

因此，锁定应用程序服务器。当然，唯一比被妥协更糟糕的是被妥协而不知道它。如果您确实发现了妥协，您需要修复漏洞（如果有的话）。取证在这里很重要（启用日志并监控它们）。您还需要制定恢复计划。

预防、检测、纠正和恢复至关重要。

于 2012-04-17T13:05:15.507 回答