SQL Server身份验证还是集成安全性？

Question

我们有一些企业内部网用户使用WinForms应用程序来处理后面有SQL服务器的系统。集成安全性已设置，允许所有用户更新和删除权限，其中应用程序安全性限制表更新的方式和位置。

但是，某些用户可以使用SQL查询工具，并直接访问数据库以构建报告。但是，通过集成安全性，它们具有应该没有的表的默认更新权限，因为应用程序将规则应用于更新。

这是一个更合适的例子，为应用程序提供中央SQL身份验证登录，而用户获得集成安全性的只读权限吗？

Answer 1

正如Jon所说，存储过程可以为您提供直接表修改的保护。还有其他选择。您可以使用SQL Server的“应用程序角色”（通过sp_setapprole proc）。这使您可以继续为每个人使用单独的ID，但仅在应用程序连接时（通过前端）提升用户权限。

使用共享ID的一个主要缺点是你忘记了谁将SQL提交到服务器，尽管如果它们都是内部的，你可以获得机器名。

但其他一些事情仍然存在。听起来好像您的用户可以连接到数据库并随意运行查询。由于直接连接的SQL会话中的用户行为，您在应用程序中存在严重的停机风险。如果您可以将其关闭，您可能希望尝试创建一个报告数据库，该数据库会按照您的业务可以容忍的时间间隔（即每天）进行更新。 HTH

Answer 2

我从你的问题的方式推测，你的应用程序直接执行sql语句。如果您可以重构它以便它执行存储过程，您可以授予exec对过程的权限并拒绝直接更新表。但这可能无法实现，具体取决于您的应用程序的功能。

Answer 3

sql身份验证是一种选择。存储过程是另一个。但是，构建更细粒度的角色只是为适当的用户类型分配适当的权限，这是您应该真正关注的地方。

另外，我真的会避免让这些用户直接访问数据库。除了安全性原因之外，对于不熟练使用SQL的用户来说，如果意外地执行会破坏数据库服务器并创建有效拒绝服务的查询，则不需要花费太多时间。专业人士甚至可以偶尔不小心做到这一点。

相反，让他们访问报告服务或分析服务类型解决方案，或使用复制来授予他们访问数据克隆的权限。这样就可以保护您的生产系统。

Answer 4

我个人会通过存储过程进行所有应用程序数据访问。我将集成安全性设置为仅允许用户运行SP而不直接操作数据。

可以向DB管理员提供高级访问权限，以便在需要时直接操作数据。

基于组的权限将为您提供更大的访问权限灵活性，并在使用集成安全性控制这些权限时减少管理负担。