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

Question

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

但是，一些用户是拥有SQL查询工具的高级用户，并且可以直接访问数据库以生成报告。但是，对于集成的安全性，它们在表中不应具有的默认更新权限，因为应用程序将规则应用于更新。

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

Answer 1

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

使用共享ID的一个主要缺点是你失去了向服务器提交SQL的人的踪迹，尽管如果他们都是内部的你可以得到机器名。

虽然有其他的事情。这听起来好像您的用户可以连接到数据库并随意运行查询。由于直接连接的SQL会话中的用户行为，您在应用程序中运行宕机的主要风险。如果您可以将其关闭，则可能需要尝试创建一个报告数据库，并根据您的企业可以容忍的时间间隔（即每日更新）更新报告数据库。 HTH

Answer 2

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

Answer 3

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

可以对数据库管理员进行高级访问，以便在需要时直接操作数据。

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

Answer 4

sql认证是一种选择。存储过程是另一个过程。但是，为适当的用户类型分配适当的权限，构建更细化的角色就是您真正需要的地方。

此外，我真的会避免让这些用户直接访问数据库。除了安全原因外，对于不熟练使用SQL的用户而言，意外执行一个查询会使数据库服务器瘫痪并创建有效的拒绝服务，这并不会带来太大的影响。即使专业人员偶尔也会偶然做到这一点。

取而代之的是，让他们访问报告服务或分析服务类型解决方案，或者使用复制使他们能够访问数据的克隆。这样你的生产系统受到保护。