在 winforms 应用程序中连接数据库的服务帐户

Question

这看起来是一个非常常见的问题，但找不到任何正确的答案。

我们有许多 WinForms 应用程序目前正在使用 sql 服务器帐户连接 sql。 现在我们计划使用服务帐户（活动目录）连接到数据库。 有一种选择，我们可以为每个用户提供对数据库的访问权限并使用我们当然不想要的集成安全性。 考虑到应用程序不需要/最少的更改，最好的解决方案是什么？

提前非常感谢。

Answer 1

我想我明白你想要做什么。

Sql 帐户在这种情况下不太理想，因为您必须与您的应用程序一起分发帐户凭据。 您可以使用加密的配置文件部分或其他技巧来做事，但最终用户名/密码会暴露出来并且不容易维护。

通过使用内置于 Active Directory 中的身份验证基础结构，集成安全性对此进行了改进。 您不再需要随应用分发密码。

但是，集成安全仍然存在两个弱点。

首先是账户管理。 为每个 Active Directory 用户设置 Sql 服务器登录可能很乏味，而且随着时间的推移用户流失，管理它们也很尴尬和笨拙。

值得庆幸的是，这并不像你想象的那么糟糕。 您可以通过为 Active Directory 组而不是单个用户创建 Sql 服务器登录来解决此问题。 将 Active Directory 用户设置为此类组的成员足以授予他们组访问权限。 您甚至可以使用少量组来代替原始提案中的每个“服务帐户”，以支持分层访问。 使用此方案，实际登录的用户也可用于 Sql 服务器（因此也可用于应用程序），以便在需要时在应用程序中分配更具体的权限。

另一个弱点是您直接向用户授予原始数据库权限，而不仅仅是授予使用应用程序的权限。 这是一个真正的问题，如果乔用户可以下载 Sql Server Management Studio（或任何可能甚至不需要安装的类似应用程序）并针对授权使用该应用程序的数据库部分运行他们想要的任何查询。

不幸的是，您提出的解决方案（Active Directory 中的服务帐户）不起作用。 这些服务帐户仍然需要使用集成安全性，并且集成安全性仅在相关帐户实际运行应用程序进程时才起作用。 这永远不会按照你想要的方式工作。

所以，我们能做些什么？

一种“最佳实践”是将应用程序角色与基于组的集成安全性结合使用。 不幸的是，这需要对您的应用程序进行更改，以便每个数据库连接都可以调用sp_setapprole 。

这也让您回到与您的应用程序一起分发凭证。 它更安全一些，因为这种分布式凭证需要集成安全登录才能使用； 如果这样的凭证泄露给全世界，您的数据库仍然只会在您自己的用户群中受到损害。

但是请记住，当您的凭据被公开时，您的任何有动机和访问 Google 的用户仍然可以找到一个应用程序，该应用程序可以让他们复制您的应用程序正在执行的操作，以使用与应用程序相同的权限运行他们想要的任何查询，就像单独使用基于组的集成安全一样。 您仍然需要保护凭证，以及随之而来的所有挑战。

换句话说，这最终仍然具有向用户授予原始数据库权限的集成安全弱点和需要保护凭证的 sql 身份验证弱点。 我不是粉丝。

我知道还有另外两个选项，但都需要对应用程序进行重大修改。

第一个选项涉及重写应用程序以使用服务层（通常是 JSON，通过 web API）而不是直接访问数据库。 这是有效的，因为您控制服务层机器，但它是对应用程序的巨大重写，并且需要额外的服务器资源。

第二个选项涉及将所有数据库访问转移到存储过程中。 然后将 Active Directory 组帐户设置为仅对相应存储过程具有执行权限。 这样，存储过程就构成了事实上的 API。 这里的弱点是它可以限制报告选项。

那么我会在你的鞋子里做什么？ 可能 go 用于基于组的集成安全选项，而不使用特殊的应用程序角色（没有sp_setapprole ...使用 Sql 服务器角色为您的组分配权限仍然是一个好主意）。 但是，我会尽量限制对这些组的权限。 这样，您的应用程序最初需要的唯一更改就是连接字符串。 然后我们可以随着时间的推移转向存储过程选项。 这可以在应用程序中在多个发布周期内完成，因此您无需等待对集成安全性进行更改。

Answer 2

除了 Joel 对分配给 SQL 权限的 AD 组的回答之外，为数据读取创建 sql 视图并为更新存储过程可能符合您的最佳利益，只需将 ZAC5C74B64B4B8352EF2F181AFFB5AC2 的整个映射组权限分配给这些项目沙邦。 如果最终用户在技术上如此倾向于 go 探索，这将在最终用户和原始数据库之间添加一层抽象。

但是根据您的业务案例，这可能是过度架构的事情。