带有 SQL Server 后端的 MS Access 应用程序的安全模型（部署）答案

【问题标题】：Security model (deployment) for MS Access application with SQL Server Backend带有 SQL Server 后端的 MS Access 应用程序的安全模型（部署）
【发布时间】：2010-01-18 16:58:18
【问题描述】：

我们有一个应用程序，由一个 MS Access 前端（2007，mdb 格式）、一些 .net 库和一个 SQL Server (2008) 后端组成。我正在开发一个安装程序，它会自动安装 MS Access 运行时、我们的应用程序、我们的库、SQL Server Express 并配置所有内容。

显然，MS Access 应用程序和库（在正常的非管理员用户上下文中运行）需要访问 SQL Server 数据库。 授予应用程序访问权限的最佳方式是什么？

这就是我想出的。不幸的是，所有这些似乎都有缺点：

SQL Server Compact Edition：不支持视图。
Application Roles：这似乎是最佳实践。但是，它需要在访问数据库之前执行存储过程（我无法在连接字符串中传递应用程序凭据）。因此，我不能将其用于attach the SQL Server tables as a linked tables in the Access MDB，这是我们的 Access 应用程序的要求。
SQL Server User Instance：引用 MSDN：“此功能将在 Microsoft SQL Server 的未来版本中删除。避免在新的开发工作中使用此功能.. ."
SQL Authentication：微软说：“如果可能，请使用 Windows 身份验证。”
使用 Windows 身份验证并授予 BUILTIN\USERS 完全访问权限：这是迄今为止最简单的解决方案，但不知何故这样做“似乎是错误的”...

该应用程序面向非技术受众，因此要求用户配置权限不是一种选择。

编辑：一些澄清：这是一个“本地”应用程序，即 SQL Server 与应用程序位于同一台机器上；从网络访问 SQL Server 既没有必要也不需要。该软件（用于管理库存、发票等的常规业务应用程序）将可以免费下载，因此它应该在各种环境（域/非域、不同操作系统等）和 IT 环境中运行安装它不需要知识-除了通常的“单击setup.exe，确认UAC提示，确认安装目录等”。我预计最常见的场景是“Windows XP，本地管理员用户”和“Windows Vista/7，启用 UAC 的本地管理员用户”。由于我们希望遵循良好的做法，运行应用程序在后一种情况下不应要求“以管理员身份运行”。

【问题讨论】：

客户端和数据库服务器在同一台机器上吗？我们是在谈论“一对一”的情况，每个用户在他的机器上都有自己的服务器吗？机器是否在域中？用户是否有密码来启动/解锁他的机器？如果他不是管理员，用户如何在他的机器上安装软件包？
@Philippe：我已经更新了这个问题。用户将通过双击 setup.exe 并确认 UAC 提示来安装应用程序。 ;-) 但是，运行应用程序（并因此访问 SQL Server DB）不需要提升。

标签： sql-server security ms-access deployment sql-server-express

【解决方案1】：

@Heinzi 写：

使用 Windows 身份验证和授予 BUILTIN\USERS 完全访问权限：这是迄今为止最简单的解决方案，但不知何故，这样做“似乎是错误的” 那……

这里通常的方法是添加自定义用户组（例如“db-users”）并将用户放入该组。这样您就可以准确控制谁可以访问。

【讨论】：

感谢您的意见。事实上，这就是我作为系统管理员选择的解决方案。问题是该软件应该是可下载的最终用户产品，即目标群体包括不知道“用户群体”是什么的人......
在这种情况下，SQL Server 身份验证和 SQL Server 角色在我看来是可行的方法，不是吗？
是的，可能就是这样。我只是想知道这种方法是否有任何问题，因为我觉得现在 SQL 身份验证被认为有点“过时”。
我觉得Windows身份验证要容易很多，但是在你的分发场景中，你有不同的考虑，所以我认为这并不合适。

【解决方案2】：

怎么样：

使用预先配置的 Access ADP 项目连接到本地安装的 SQL Server 实例。
使用 BuiltIn\Users 组（或 SQL 身份验证）进行连接，但仅授予最低限度的凭据。足以登录和...
调用 sp_setappprole 以将客户端连接“提升”到您定义的应用程序角色的身份。

【讨论】：

是的，如果我们使用 ADP 而不是 MDB，那肯定是要走的路。不幸的是，ADP 项目不是一个选项，因为我们的代码需要一些 mdb 功能，例如本地查询定义。正如 Microsoft 建议不使用 ADP 而是使用带有链接表的 MDB 或 ACCDB（引用：“连接到 SQL Server 的首选方法是 MDB 文件格式或 ACCDB 文件格式。”，technet.microsoft.com/en-us/library/cc178973.aspx），我不'不要认为我们会将我们的应用程序迁移到 ADP 项目中。
ADP 无法支持的本地 Querydefs 是什么？哇，微软似乎在淡化 ADP，这是一个巨大的耻辱。 IMO，它是大多数工作组规模应用程序的理想开发技术......
好吧，我想应用程序可以重写为 ADP（querydefs 主要用作自适应报告源），但 querydef 只是问题之一。几年前我们尝试过 ADP，我不记得所有细节，但结论是需要重写大量遗留代码。因此，目前它不是一个选项。
是的，我正要提出各种方法来解决缺少 querydefs 的问题。但现在我发现存在对遗留代码的依赖，这需要大量返工才能在 ADP 中使用。哦，好吧...
即使没有遗留代码，ADP 也始终是移动目标。每个版本都有自己的一套陷阱，并且它们从一个版本到另一个版本（A2002 修复了 A2000 ADP 中的错误，但引入了自己的错误，然后 A2003 在引入自己的同时恢复了一些已修复的错误）。 ADP 只是一个失败的想法，可能从一开始就是浪费时间。从概念上讲，它可能有效，但从未达到 MS 著名的“版本 3”完整性。

【解决方案3】：

如果听起来你只是冰山一角。在销售和部署访问 SQL 应用程序时。

我采取了不同的路线。我有虚拟计算机作为独立的工作站和域服务器和工作站都是虚拟的。

我编写了一个脚本，它们是 VBA 和 VBScript 的组合。问 DB 和 App 是在单台计算机上运行还是在不同计算机上运行。如果不同的计算机，数据库所在的计算机的名称是什么。数据库和应用程序是否位于工作组、家庭组或域环境中数据库计算机是否已经有 SQL Express 或更高版本应用计算机是否已经安装了 Access 或 Access Runtime。
如果是，是哪个版本。是所有用户还是只有有限用户拥有访问权限。
如果受限，用户的用户组名称是什么可以访问数据。这个组是否已经存在如果没有列出应该添加到组中的用户的名称还有关于管理员用户和组的问题

脚本启动虚拟机并执行一系列步骤来代表 MDB 和 SQL DB 进行部署。然后为服务器安装创建一个 MSI，其中包含设置环境的自定义脚本。最后将 MDB 打包到一个不错的 MSI 中。

我已经改进了这个过程，允许在服务器安装开始时回答一些问题。这意味着可以根据之前提出的问题从工作站或域中的列表中选择用户组和用户。

如果用户，则应用用户是工作站或域的管理员组的成员。他们得到额外的菜单选项。这允许他们在工作站或域的数据库用户组中添加或删除成员。我觉得这很有帮助。

我现在正在进入下一阶段，正在考虑将我的评估应用程序托管为 SasS（软件即服务）（租赁）。因此，该应用程序可以在任何 HTML5 浏览器、Windows 或 Mac 中用作虚拟桌面或 Android 和 Apple 设备。话虽如此，Access 在移动设备上有点难看。

当我启动并运行时，我会将平台提供给其他人。

【讨论】：