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

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

我们有许多WinForms应用程序当前正在使用sql server帐户连接sql。现在我们计划使用服务帐户（active directory）连接到DB。有一个选项，我们可以为每个用户提供对数据库的访问，并使用我们当然不希望的集成安全性。考虑到应用程序中不需要/最少的更改，什么是最佳解决方案

---

事先非常感谢。

我想我理解你的意图

Sql帐户在这种情况下不太可取，因为您必须随应用程序分发帐户凭据。您可以使用加密的配置文件部分或其他技巧进行操作，但最终用户名/密码是公开的，不容易维护

通过使用内置于Active Directory中的身份验证基础结构，集成安全性在这方面有所改进。您不再需要在应用程序中分发密码

然而，在综合安全方面仍然存在两个弱点

首先是账户管理。为每个Active Directory用户设置Sql Server登录可能会非常繁琐，而且随着时间的推移，用户数量会不断增加，因此管理这些用户会非常困难和笨拙

谢天谢地，这并不像你想象的那么糟糕。您可以通过为Active Directory组而不是单个用户创建Sql Server登录来解决此问题。将Active Directory用户设置为此类组的成员足以授予他们组访问权限。为了支持分层访问，您甚至可以使用少量的组，一个组代替原始方案中的每个“服务帐户”。使用此方案，Sql Server（以及应用程序）仍然可以使用实际登录的用户在需要时在应用程序中分配更多特定权限

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

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

那么我们能做什么呢

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

sp_setapprole

这也让您重新开始在应用程序中分发凭据。它更安全一些，因为这种分布式凭证在使用之前需要集成的安全登录；如果这样的凭证泄露给世界，那么您的数据库仍然只会在您自己的用户群中受损

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

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

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

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

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

---

那么，站在你的立场上，我该怎么办？可能选择基于组的集成安全选项，而不使用特殊的应用程序角色（no

sp_setapprole

…使用Sql Server角色为组分配权限仍然是一个好主意）。但是，我会尽量限制这些组的权限。这样，最初在应用程序中所需的唯一更改就是连接字符串。随着时间的推移，我们可以转向存储过程选项。这可以通过几个发布周期在应用程序中完成，因此您无需等待对集成安全性进行更改。

随着Joel关于分配给SQL权限的AD组的回答，为数据读取和存储更新过程创建SQL视图可能对您最有利，只需将映射到广告组perms的sql登录名分配给这些项目，而不是整个shabang。这将在最终用户和原始数据库之间添加一层抽象，如果最终用户在技术上倾向于进行探索的话

---

但这取决于你的商业案例，可能是在架构上的问题

集成安全性可能没有您想象的那么糟糕。您在Active Directory中设置了一个组，授予该组对您的数据库的访问权限，并使您的用户成为该组的成员。比如说，你也可以使用四个组中的三个作为访问层