我们有一个 EXE 和一个读取/写入 SQL Server 数据库的 DLL。EXE 和 DLL 在用户的计算机上运行。
我们想使用 Integrated Security 连接到 SQL Server 数据库，但不是使用用户的 windows id，而是使用 windows 服务帐户。这样，我们就不需要授予用户对数据库的写权限。
由于用户在用户计算机上运行 EXE 和 DLL，是否可以将 SQL Server 连接字符串设置为集成安全，但使用 Windows 服务帐户（不是用户帐户）？
谢谢你。
从技术上讲，您可以，尽管这不是一个好主意。您没有描述的是您对此要求的推理。
这感觉就像一个 XY 问题，通过在另一个安全帐户的上下文中运行用户应用程序，您正在创建一个其他进程可能能够劫持的安全窗口。您失去了审核和控制每个用户对您想要保护的资源的访问的能力，而不是让事情变得更安全，在大多数情况下，您实际上实现了相反的效果。
大胆声明正确...如果用户正在运行应用程序，那么他们必须为提升的安全帐户保存或存储凭据，或者该用户必须知道提升的凭据。
在不同帐户的上下文中运行后台服务是完全可以接受的，但是当您将模拟脚本写入用户应用程序的执行方式时，这会产生漏洞，无论是您编写脚本的方式和凭证的存储方式，还是一旦用户在您的应用程序，任何文件访问对话框，如导出、文件打开、文件保存对话框，都可以让您的用户在您模拟的帐户的上下文中访问文件系统和网络。根据您的应用程序，这可能是好事，也可能是坏事，但在 UX 中经常被忽视。
进一步被忽视的是，您的应用程序所做的一切、每个审计跟踪、每个日志，所有内容都将显示为服务帐户，而不是用户帐户。当出现安全漏洞需要追踪时，不能单独的用户账户分开，每个人都会看起来像一个服务账户，在这种情况下，它扩展到 SQL Server 审计和安全配置文件，整个环境看起来像一个使用数据库的用户，并且该用户可能在 SQL Server 中拥有最高权限，这意味着只需要一个控制台就可以被破坏，并且一个控制台可能有权运行 DDL 语句，并且可能会严重导致一些问题。
我不能过分强调这一点，每个人都通过单一凭据访问数据库，这是一种非常糟糕的安全做法，并且在面对 SQL Server 中内置的非常强大的安全机制时会笑。
相反，请使用域安全性来发挥您的优势。不要担心对数据库文件有写访问权，如果您希望您的用户插入一条记录，那么他们需要 Windows 安全权限来修改文件是有道理的。我会更担心我知道谁在访问我的文件以及何时访问，只有当他们有个人帐户时才会发生这种情况。
如果您关心的是管理开销，那么创建一个安全组并将必要的用户放入该安全组。然后，您管理文件级访问权限，将组分配给所需的文件。在 SQL Server 内部，您可以进一步限制该用户对 SQL 操作的访问级别
请记住，替代方法可能是使服务帐户成为数据库的数据库管理员角色或所有者，因此您的应用程序的任何用户都可以删除数据库。
如果要使用集成安全，那么用户必须已经被信任才能访问域资源，数据库只是另一个域资源，所以安全管理应该同样对待。我们希望为用户提供唯一帐户的最大原因是，我们可以轻松地限制或撤销对个人的访问，而不必影响域上的所有用户。
将用户与对数据库的直接访问分离的最佳方法是设置分层 DAL 层，其中 DAL 部署为应用程序与之通信的独立服务，该服务可以在特定用户帐户的上下文中运行以进行数据库操作. 这通常涉及对您的应用程序设计的重大更改，但它仍然引入了上面列出的所有 SQL 安全实施问题，是的，它可能解决网络安全问题，但是没有简单的方法在数据库级别应用基于单个用户或角色的安全性如果每个人都使用同一个帐户，这意味着您有责任在应用程序级别进行管理。