应用错误收集

我不会直接暴露数据库。我会在用户和数据库之间使用一个层，以便您可以控制他们查询数据库的方式以及他们可以检索的内容。

不要在代码中定义数据库连接。而是使用JNDI资源（特别是如果您在应用服务器上运行，例如为您管理JNDI资源的Tomcat）。这将使您的代码与连接信息分离。此外，您可以使用连接池与JNDI之类的东西，这将增强您的应用程序的性能（并将处理连接关闭等事情）。并发将由连接池处理。请参阅此Oracle article on JNDI resources和this one specific to Tomcat。

使用服务帐户，即用于对数据库的应用进行身份验证的帐户。该帐户与访问您应用的用户的用户帐户无关。限制服务帐户可以执行的操作。如果你想要做的只是通过应用程序读取数据，那么将服务帐户限制为仅（至少在开始时）。

您可以使用ORM，例如Java中的Hibernate将为您提供数据库的抽象视图。如果你拥有的只是一张桌子，那对你来说可能太过分了。在这种情况下，请使用名为PreparedStatement的内容。

您想让用户定义自己的SQL语句时感到厌倦。这会让你面临很多SQL攻击（寻找SQL注入）。

永远不要将用户凭据以明文形式存储在数据库中。哈希值。

最后，请看一下这些awesome best practices。

我认为，这在很大程度上取决于您希望在安全性，易用性等方面实现的目标。每个都有其优点和缺点。通常它是一种权衡。

为所有用户连接一个数据库帐户

优点：

灵活性：您不受DBMS提供的访问限制方法的约束。

E.g。您可以在应用程序的权限管理中包含可能不适用于DBMS权限管理的业务规则。

如果您没有使用其权限管理的任何专业，那么更改DBMS也可能更容易。如果应用程序保持不变，则访问控制保持不变。

您可以根据需要在应用程序中设计用户管理，使您尽可能轻松便捷。如果您使用DBMS来管理用户，则只能使用它为该作业提供的工具。

如果DBMS存在关于权限管理的错误，并且相应的公司或社区未提供补丁，则您无法做很多事情。如果您的程序中出现这种情况，您可以自行修复。
使用您喜欢的工具：您可以更轻松地在应用程序中正确执行此工具，只因为您熟悉并熟悉相应的编程语言。也许你还不太了解DBMS。

这可能会对您的解决方案的质量产生影响。

缺点：

单点故障：从DBMS的角度来看，您的所有用户都是同一个用户。

也就是说，如果这个帐户由于某种原因落入坏人之手，那么一切都将丢失。当然，您可以（并且应该！）在DBMS上尽可能地限制这样一个DBMS帐户。侧。但是，任何有权访问此帐户的人都可以执行应用程序允许的最高权限。

同时记录谁在这种情况下做了可以规避的事情。由于入侵者拥有您的应用程序拥有的所有权限，并且DBMS无法区分可能的用户，因此他们可以模仿他们喜欢的所有用户。甚至可能操纵（在数据库中）日志。找到攻击的痕迹可能会更难。

应用程序必须知道单个数据库帐户的密码（或任何凭据），以便在登录时将其提供给DBMS。显然，尤其是你不能外包＆＃34;这个知识给用户＆＃39;大脑。如果他们知道，他们可以通过简单地使用通用客户端（例如MySQL Workbench）处理您的应用程序从未允许的事情来轻松绕过您的应用程序。来自内部的攻击并不罕见。例如。一些操纵别人工作的用户，在管理促销之前要更好看。或者是那些觉得被公司背叛并希望报复的人。你说它的名字。（如果它不是商业项目，则按社区替换公司。）

它必须物理存储在应用程序可以访问它的某个地方。虽然可能有一些措施可以很好地处理并且安全，但它仍然比仅仅在用户头脑中更容易暴露。

如果您必须更改该单个帐户的密码，则可能必须以某种方式将其部署到应用程序的所有安装中。这可能不是一个（大）问题，具体取决于您的应用程序的部署方式。
经过良好测试：如果您选择其中一个着名的DBMS，您可以确定很多其他人都使用它。很多人都测试了它。有些人甚至可能已明确审核过它。

这些DBMS中的一个有错误的概率，允许帐户摆脱其限制而不是0，可能远远低于您可能较差的传播和支持的应用程序中的一些隐藏缺陷。

（请不要认为这是一种侮辱。我不会怀疑你的技能或任何东西。但我只是假设你没有重量级的合作，例如甲骨文拥有数十亿美元的资源你可以投入或者（还）有很多志愿者背后有一个庞大的开源社区。）

对于每个用户，使用不同的数据库帐户

优点：

减少影响：您不会遇到单点故障的所有问题，即所有用户都会使用单个DBMS帐户。

当然，如果攻击者获得超级用户帐户，那么，无论如何，您都可以完成。但即使有人可以窃取您的一个普通用户的帐户数据，他们也无法做到这一点，因为这个用户可以做到。当然，您必须尽可能降低此处的权利，以减少此类事件可能产生的影响。

由于DBMS明确地知道它与谁打交道，因此可以安全地记录用户操作以防止可能的操作。您可以重建已完成的操作以及执行操作的人员。并确保日志不会骗你。

你可以＆＃34;外包＆＃34;用户大脑的登录凭据。没有必要，它必须在物理上存储在您的应用程序可访问的地方。它的暴露程度较低。（前提是用户不要在键盘旁边的某些帖子上写这些有趣的东西。但是，这是另一个故事......）如果密码需要为一个用户进行更改，那么它就不会＃ 39;根本不影响其他用户或程序的安装。
经过良好测试，得到很好的支持：正如我上面所说，如果你带着一个众所周知的DBMS，你可以肯定很多其他人都会使用它。它经过良好测试甚至可能已被明确审核过。

因此，DBMS中的漏洞概率可能比您的应用程序低很多。并且支持社区或公司可能很容易找到此类错误的修复程序。

对您的项目来说，这可能不是一件重要的事情。我无法判断规模。但我并不希望它被提及，某些DBMS提供了集成在组织的复杂IT环境中的手段。这也与用户管理有关。例如，在SQL Server Active Directory中可以使用用户。这可能有助于整体简化，集中和/或标准化组织内的用户管理，从而使其不易出错。对用户来说也可能很方便 - 可以提供单点登录。

缺点：

自由度较低：使用DBMS进行用户和权限管理，您必须遵守其规则。

DBMS可能无法提供您需要的某种方式或某种级别的访问限制。您可能会发现无法制作DBMS＆＃39;权利管理根据您的一些业务规则行事。在这种情况下，你无能为力。

如果你想改变你可能会发现的DBMS，你已经在旧的用户管理中使用了许多专业，这些专业无法在新的用户管理中实现。你可能必须从头开始。

您必须得到生成DBMS的公司或社区的支持。如果权利管理中存在错误，这对您构成了危险，并且公司或社区没有提供补丁，那么您无能为力。
可能需要学习：特别是当您刚接触DBMS世界时，您需要学习如何理解DBMS可以提供的访问控制方法一般而言，某个DBMS如何提供它们或者它必须提供什么。

当然，这并不是毫不费力的，一开始你可能会犯错误。

<强>结论

每种方法各有利弊。

以＃34;单个DBMS用户为所有＆＃34;如果安全要求不高，路由可能是正确的选择。更大的灵活性可能会超过它。

另一方面，多个DBMS帐户提供的安全级别要高得多。如果这是一个问题，特别是当我们谈论敏感数据时，这可能是更好的选择，甚至是唯一合理的选择。

甚至混合解决方案也许是正确的选择。始终在DBMS中倒退。访问限制，最重要的是，将您自己的限制放在应用程序中。

要确定哪种方法最适合项目，必须考虑其需求，并且必须相互加权。我猜没有单一的最佳方式。

我的用户应该直接连接到数据库吗？如何将用户连接到数据库;

2 个答案: