数据库访问控制：应用程序或数据库级别控制？

Question

我一直在使用SQL Server作为后端数据存储的Access 2003中开发应用程序。 Access仅用作GUI，不存储任何数据。应用程序中的所有代码都使用ADO编写在VBA中进行数据访问。

在最近的会议上，在我组织的工作DBA已经成为了应用程序逻辑控制哪些数据可用于查看和更新​​的事实越来越关注。直到现在，我一直在开发应用程序的方式是使用单个数据库登录来访问数据库。此数据库登录是唯一允许访问数据库的用户，并且所有其他数据库用户（DBA类型除外）都受到限制。

此项目的DBA坚持要在应用程序的每个用户都有自己的帐户只能映射到数据库中的这些对象，他们应该有机会。当然，我可以看到他的关注，这就是为什么我希望问两个问题...

1. 是具有单一的应用程序级别的登录到数据库的不好的做法？我曾计划实施一个基于角色的安全模型，其中“访问”用户依赖于他们的应用角色。但是，应用程序逻辑确定是否允许某些查询/更新进行。

2. 有谁知道一些资源（文章/书籍），其过去如何设计，其中数据库访问是从SQL Server中，而不是通过应用控制的应用程序？

Answer 1

在我看来

1. 是的，这是不好的做法，因为用户可以使用的凭证来访问数据库以另一种方式，绕过应用程序的访问控制和执行的操作，他们不应该能够。如果您位于Windows域中，则可以在AD中为每个角色创建一个组，然后将用户分配给该组，然后根据该组应用权限，以便不必将新用户添加到SQL。

如果沿着活动目录路由走下去，可以使用LDAP查询来查看用户属于哪些组，并且可以决定它们是否应该有权访问。

阅读关于此的其他答案会很有趣。

Answer 2

你不说什么数据库的大小或业务环境，所以答案是 - 这取决于，但推定是你的DBA是正确的。

在公司环境中，主要关心的通常是数据，而不是用于访问它的应用程序。实际上，数据通常比应用程序具有更长的使用寿命，而且不断变化的业务考虑因素可能会决定数据被不同来源使用并可能被修改，而不仅仅是“您的”应用程序。在这种情况下，建立数据库级别的安全性是有道理的，因为无论合法还是非法地访问数据库，无论现在还是将来，无论数据库如何被访问，都可以确保数据库的完整性。

对于“部门级”应用程序，即访问限于六位左右的用户，数据不是关键业务，并且永远不需要在原始应用程序之外使用数据，然后应用程序级别的安全性往往更加方便，风险往往是可以接受的。我有客户将定制的垂直应用软件出售给使用这种方法的小型企业，并且由于没有内部IT，很难想象如何在不引起高支持开销的情况下方便地实施。

然而，与部门级情况相反，企业的一个定义特征是前者会有专门的DBA，而后者可能甚至没有专门的IT支持，因此您几乎可以肯定必须将数据库视为企业资产，因此您应该遵循DBA的建议。定义数据库对象和安全性的工作量更大，但最终的结果是您可以对数据库的完整性充满信心，并且当不可避免的升级/扩展出现时您就可以安心工作。

Answer 3

1. 这是不好的做法，但正如你所看到的 - 那是多么大多数应用“进化”开始作为大开，只有少数用户和越来越紧下来，更多的人（IT /数据库管理员）参与进来。

2. 您的DBA应该能够提供帮助 - 几乎所有常规SQL Server书籍都有一两章关于用户，角色和安全性。他们还将能够解释不同安全选项的细微差别以及在您的环境中最有效的方法。

设置区域会取决于环境和应用程序。例如 - 如果您的所有用户都是基于Windows（基于）的连接，则您将希望使用Windows身份验证而不是SQL身份验证。如果你有很多不同的角色，你会希望使用SQL Server角色。您可能希望纳入AD组以及角色（或替代）。你的数据库管理员可以帮助你做出这些决定，甚至为你做出决定，因为你更多地向他们解释你的申请。

如果您发布有关环境和应用程序以及使用情况的更多信息，SO上的人员当然也可以提供我们的意见。