我在网上搜索了一下，找不到任何真正指向该地点的内容或覆盖了如何在数据库上设置用户/角色的基础。
基本上，将会有一个用户从应用程序（本例中是Web应用程序）访问数据库，该用户需要访问数据库以进行常规数据库操作（选择，插入，更新，删除）和执行存储过程（使用exec在其他存储过程/ UDF中运行存储过程）。
然后，我们还有一个主要管理员用户（这很简单）。
我目前有一个开发环境，在我看来我们并没有真正管理安全性（应用程序使用具有db_owner角色的用户，尽管它是一个Intranet应用程序）。尽管它是一个Intranet应用程序，但我们仍然考虑到安全性，并希望了解开发人员为此类环境设置用户/角色的方式。
编辑：Web应用程序和SQL Server驻留在不同的计算机上。
编辑：忘记提到使用需要直接读/写访问的ORM。
问题： 设置用户进行应用程序访问的“最佳实践”是什么？将适用哪些角色以及哪些角色？
答案 0 :(得分：38)
首先，我倾向于将权限封装在数据库角色中，而不是将它们附加到单个用户主体。这里的最大胜利是角色是数据库的一部分，因此您可以完全编写脚本安全性，然后告诉部署类型“添加用户并将其添加到此角色”并且他们不会与SQL权限boogeymen作斗争。此外，这可以保持足够的清洁，你可以避免在db_owner模式下开发并且对自己感觉更好 - 以及像你一样练习并且通常避免任何问题。
在为该角色申请权限的情况下，我倾向于将这些天网扩大，特别是如果一个人正在使用ORM并通过应用程序处理安全性。在T-SQL术语中，它看起来像这样：
GRANT SELECT, UPDATE, INSERT, DELETE, EXECUTE on SCHEMA::DBO to [My DB Role]
一开始看起来有点可怕，但实际上并非如此 - 除了操纵数据之外，该角色不能做任何其他事情。无法访问扩展的进程或系统进程或授予用户访问权限等。另一个重要的优点是更改模式 - 如添加表或过程 - 只要您保留在该模式中就不需要进一步的安全工作。 / p>
SQL 2005+需要考虑的另一件事是使用数据库模式来保护对象组。现在，这里的一个大窍门是许多ORM和迁移工具不喜欢它们，但是如果你将默认模式[dbo]渲染到应用程序，你可以使用替代模式来处理特殊的安全内容。例如 - 为特殊的，残酷的数据库清理过程创建一个ADMIN模式，该过程应由管理员手动运行。甚至是应用程序的特殊，高度安全的部分的单独模式，需要更细粒度的数据库权限。
如果您在具有单独框的用户中进行布线，即使没有域，您也可以使用Windows身份验证（在Sql Server术语集成身份验证中）。只需在两个框上使用相同的凭据（用户/通过组合）。设置应用程序域以在Web框上以该用户身份运行，并在sql框上设置由该主体支持的Sql Server用户并获利。也就是说，使用数据库角色几乎可以使您与此决定脱节，因为部署类型应该能够处理创建SQL用户并根据需要修改连接字符串。
答案 1 :(得分：14)
很长一段时间，SQL Server对数据库的应用程序访问指南是将数据访问隔离到存储过程中，将过程分组到模式中，并将模式执行授予应用程序使用的主体。所有权链接将保证对过程调用者的数据访问。可以通过检查存储过程来检查访问。这是一个简单的模型，易于理解，设计，部署和管理。使用存储过程可以利用代码签名，这是最精细和最强大的访问控制方法，也是唯一可以防篡改的方法（如果程序被更改，签名就会丢失）。
问题在于，从Visual Studio设计人员那里传出的每一项技术都面临着这一建议。开发人员面临的模型很难仅与存储过程一起使用。开发人员喜欢首先设计他们的类模型，并从逻辑模型生成表结构。在编写应用程序的第一行之前，基于过程的指南首先要求程序存在，并且由于现代开发的迭代方式，这在开发中实际上存在问题。这是不可解决的，只要团队领导层知道问题并解决问题（即，当开发周期开始时，即使作为模拟，程序准备好）。
答案 2 :(得分：6)
创建Web应用程序使用的用户“webuser”。
仅向此用户授予存储过程执行权限。不允许直接表读/写。如果你需要从表中读取内容，请编写一个proc。如果需要写入数据，请编写另一个proc。
这样一切都保持简洁。一个应用用户，仅具有相关权限。如果安全性受到损害，那么入侵者所能做的就是运行过程。