我们有一些企业 Intranet 用户使用 WinForms 应用程序在带有 SQL Server 的系统上工作。设置了集成安全性，允许所有用户更新和删除权限，其中应用程序安全性限制了表更新的方式和位置。
但是，一些用户是拥有 SQL 查询工具的高级用户，可以直接访问数据库以构建报告。但是，通过集成安全性，它们在不应具有的表上具有默认更新权限，因为应用程序将规则应用于更新。
这是一个更适合为应用程序提供中央 SQL 身份验证登录的示例，而用户获得集成安全性的只读权限？
Hendrick
问问题
3848 次
4 回答
6
正如 Jon 提到的，存储过程将为您提供对直接表修改的保护。还有其他选择。您可以使用 SQL Server 的“应用程序角色”（通过 sp_setapprole proc）。这使您可以继续为每个人使用单独的 ID，但仅在应用程序连接时（通过前端）提升用户的权限。
使用共享 ID 的一个主要缺点是您无法跟踪谁在向服务器提交 SQL，但如果它们都是内部的，您可以获取机器名称。
不过，还有其他事情值得关注。听起来好像您的用户可以连接到数据库并随意运行查询。由于直接连接的 SQL 会话中的用户行为，您将面临应用程序停机的重大风险。如果您可以成功，您可能希望尝试创建一个报告数据库，该数据库在您的业务可以容忍的时间间隔（即每天）进行更新。高温高压
于 2008-12-29T15:33:28.590 回答
4
我从您提出问题的方式推测您的应用程序直接执行 sql 语句。如果您可以重构它以使其执行存储过程，您可以授予该过程的 exec 权限并拒绝直接更新表。不过，这可能是不可能的，具体取决于您的应用程序的功能。
于 2008-12-29T15:23:42.180 回答
4
sql 身份验证是一种选择。存储过程是另一个。但是，构建更精细的角色以仅将适当的权限分配给适当的用户类型是您真正应该关注的地方。
此外，我真的会完全避免让这些用户直接访问数据库。撇开安全原因不谈，对于不精通 SQL 的用户来说，意外执行一个查询会占用您的数据库服务器并创建有效的拒绝服务并不需要太多。即使是专业人士有时也会不小心做到这一点。
相反，让他们访问报告服务或分析服务类型的解决方案，或使用复制让他们访问数据的克隆。这样，您的生产系统就会受到保护。
于 2008-12-29T15:27:46.620 回答
1
我个人会通过存储过程进行所有应用程序数据访问。我会将集成安全设置为仅允许用户运行 SP 而不能直接操作数据。
可以向数据库管理员授予高级访问权限，以便在需要时直接操作数据。
基于组的权限将为您提供更大的访问权限灵活性，并在使用集成安全性控制这些权限时减少管理负担。
于 2008-12-29T15:24:54.270 回答