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

Question

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

在最近的会议中，在我的组织中工作的DBA越来越担心应用程序逻辑控制哪些数据可供查看和更新​​。到目前为止，我一直在开发应用程序的方法是使用单个数据库登录来访问数据库。此数据库登录是唯一允许访问数据库的用户，并且所有其他数据库用户（DBA类型除外）都受到限制。

此项目的DBA坚持要求应用程序的每个用户将其帐户仅映射到他们应该访问的数据库中的那些对象。我当然可以看到他的担忧，这就是我希望提出两个问题的原因......

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

2. 是否有人了解一些资源（文章/书籍），这些资源（文章/书籍）介绍了如何设计一个应用程序，在该应用程序中，从SQL Server内部而不是通过应用程序控制数据库访问？

Answer 1

1. 这是不好的做法，但正如您所看到的那样 - 大多数应用程序“进化”的方式开始时会对少数用户开放，并随着更多人（IT / DBA）的参与而变得紧张。

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

很多设置将取决于环境和应用程序。例如 - 如果所有用户都在基于Windows（基于）的连接上，则您将需要使用Windows身份验证而不是SQL身份验证。如果您有许多不同的角色，则需要使用SQL Server角色。您可能希望合并AD组以及角色（或代替）。当您向他们解释有关您的申请的更多信息时，您的DBA可以帮助您做出这些决定，甚至为您做出决定。

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

Answer 2

在我看来

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

如果您沿着活动目录路由走，您可以使用LDAP查询来查看用户所属的组，并且您可以决定他们是否应该具有访问权限。

阅读其他回复将会很有趣。

Answer 3

您没有说出数据库的大小或业务环境，所以答案是 - 这取决于，但推测是您的DBA是正确的。

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

对于“部门”级别的应用程序，访问权限仅限于六个左右的用户，数据不是关键业务，并且永远不需要使用原始应用程序之外的数据，然后应用程序 - 级别安全性往往更方便，风险通常是可以接受的。我有客户使用这种方法向小型企业销售定制的垂直应用软件，因为没有内部IT，很难想象如何在不产生高支持费用的情况下方便地做到这一点。

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