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

【问题标题】：Database access control: Application or Database level control?数据库访问控制：应用程序或数据库级别控制？
【发布时间】：2011-03-15 10:08:26
【问题描述】：

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

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

该项目的 DBA 坚持应用程序的每个用户都将他们的帐户映射到数据库中他们应该有权访问的那些对象。我当然可以看到他的担忧，这就是为什么我希望提出两个问题......

使用单个应用程序级别登录数据库是一种不好的做法吗？我曾计划实施一个基于角色的安全模型，其中授予的“访问”用户取决于他们的应用程序角色。但是，应用程序逻辑决定是否允许某些查询/更新继续进行。
有谁知道一些资源（文章/书籍），这些资源（文章/书籍）介绍了如何设计一个应用程序，其中数据库访问是从 SQL Server 内部而不是通过应用程序控制的？

【问题讨论】：

在我看来，错误在于使用 SQL Server 身份验证而不是 Windows。如果您执行后者，则无需将登录凭据存储在 Access 前端。忽略那些说 Access 是一个糟糕的前端的顽固分子——它是一个很棒的前端，但你必须构建它才能正常工作，而且在我看来，Windows 身份验证是要求之一。
我们确实在使用 Windows 身份验证。我个人认为 .NET（ASP.NET 或 WinForms）会是更好的解决方案，但是，这不是我的决定。

标签： sql-server ms-access permissions

【解决方案1】：

在我看来

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

如果您使用 Active Directory 路由，您可以使用 LDAP 查询来查看用户所属的组，然后您可以决定他们是否应该有权访问。

阅读其他关于此的回复会很有趣。

【讨论】：

但是，用户永远不能访问登录凭据。
我确信有办法从 Access 文件中提取连接字符串，但网络/数据包嗅探器失败了。
在我的情况下我别无选择。想要的权力 Access 2003。我推动了一个 ASP.NET Web 应用程序，但没有被接受。
@webworm 哎哟......听起来像是一个非技术总监，认为他们了解软件。访问是糟糕的选择。我也会逃跑的。
@webworm，嗯，Access 通常，通常甚至是一个糟糕的技术选择，但它确实具有可兑换的功能，并且可能是一个很好的商业选择。我有一个客户，我仍然支持我在 12 年前为他们开发的业务关键型 Access97 应用程序（在“我们应该使用其他东西但被否决”的情况下），随着他们的业务在过去十年中蓬勃发展，该应用程序已经满足他们的需求和增长，而且成本可能比任何其他路线都便宜，很难反对它是他们的正确选择。它们绝不是独一无二的。

【解决方案2】：

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

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

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

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

【讨论】：

【解决方案3】：

这是一种不好的做法，但正如您所见 - 这就是大多数应用程序“发展”的方式，一开始对少数用户开放，然后随着更多人 (IT/DBA) 的参与而收紧。
您的 DBA 应该能够提供帮助 - 几乎所有通用 SQL Server 书籍都有一两章介绍用户、角色和安全性。他们还将能够解释不同安全选项的细微差别以及在您的环境中最有效的方法。

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

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

【讨论】：

+1 用于 SQL Server 中的 Windows 身份验证。这比任何其他方法都更容易管理，因为 Access 前端根本不需要了解有关用户登录凭据的任何信息——它们在后台透明地处理。
我同意一个警告。数据库层并不总是控制返回什么结果的最佳位置。让应用程序管理自己的角色可以提供很大的灵活性，并且无需 DBA 干预。
我的原则是数据相关的安全属于数据库引擎，用户访问控制属于应用层。但后者可以通过存储在数据库用于管理安全性的任何内容中的组成员信息来控制，这些信息可以是数据库中定义的角色，也可以是普通的旧 NTFS 用户组。我倾向于将角色用于与数据完整性相关的安全性，并将 NTFS 组用于用户访问控制（尽管这并不是所有情况下的明确区别）。