SQL Server上用户/角色对于Web应用程序的最佳实践

Question

我在网上搜索了一下，找不到任何真正确定位置或覆盖基础如何关于在数据库上设置用户/角色的基础知识。

基本上，将会有一个用户将被用来从应用程序（在这种情况下是web应用程序）访问数据库，这将需要访问常规数据库操作（选择，插入，更新，删除）的数据库和执行存储过程（使用exec在其他存储过程/ UDF中运行存储过程）。

然后，我们也将有一个用户，这将是主要管理员（这很简单）。

我目前有一个开发环境，在我看来，应用程序使用具有db_owner角色的用户，尽管它是Intranet应用程序，但我们并没有真正管理安全性。尽管它是一个Intranet应用程序，但我们仍然有安全考虑，并希望看到开发人员为这种类型的环境设置用户/角色的方式。

编辑：Web应用程序和SQL Server驻留在单独的机器上。

编辑：忘了提及一个ORM被用来需要直接读/写访问。

问： 什么是关于建立应用程序访问用户的“最佳做法”？什么样的角色将适用于什么样的渔获物？

Answer 1

首先，我倾向于将权限封装在数据库角色中，而不是将它们附加到单个用户主体。这里的大赢家是角色是你数据库的一部分，所以你可以完全脚本安全，然后告诉部署类型“添加一个用户并将他添加到这个角色”，他们并不反对SQL的权限boogeymen。此外，这可以让事情保持足够的清洁，以至于可以避免在db_owner模式下进行开发，并且对自己感觉更好 - 以及像玩游戏一样的练习，并且通常可以避免任何问题。

就应用该角色的权限而言，我倾向于最近将网络投入更广泛，尤其是在使用ORM并通过应用程序处理安全性的情况下。在T-SQL术语，它看起来像这样：

GRANT SELECT, UPDATE, INSERT, DELETE, EXECUTE on SCHEMA::DBO to [My DB Role] 

这初看起来似乎有点吓人，但它确实是不 - 这种作用不能做得比操纵数据的任何其他。无法访问扩展的特效或系统特效或授予用户访问权限等。另一大优势是更改模式（如添加表或过程）只要保留在该模式中就不需要进一步的安全性工作。

SQL 2005+要考虑的另一件事是使用数据库模式来保护对象组。现在，这里最大的窍门是许多ORM和迁移工具不喜欢它们，但是如果您将默认架构[dbo]呈现给应用程序，则可以使用替代架构来实现特殊的安全措施。例如 - 为应由管理员手动运行的特殊的，残酷的数据库清理过程创建一个ADMIN模式。甚至还有一个独立的模式，用于需要更多粒度数据库权限的特殊高度安全的应用程序部分。

就用户而言，即使没有域，您可以使用Windows身份验证（使用Sql Server术语集成身份验证）进行配线。只需在两个盒子上使用相同的凭据（用户/传递组合）。设置一个应用程序域以在网络框中以该用户的身份运行，并在sql框中设置由该主体支持的Sql Server用户并获利。也就是说，使用数据库角色几乎可以将你从这个决定中分离出来，因为部署类型应该能够根据需要处理创建sql用户和修改连接字符串。

Answer 2

创建Web应用程序使用的用户'webuser'。

只授予存储过程执行权限给这个用户。不允许直接表读/写。如果您需要从表中读取某些内容，请编写一个proc。如果你需要写数据，写另一个过程。

这样一切都保持良好和简单。一个应用用户，只有相关的权限。如果安全性受到影响，那么所有入侵者都可以运行procs。

Answer 3

很长一段时间，SQL Server应用程序访问数据库的指导原则是将数据访问隔离为存储过程，将过程分组为模式并将模式上的执行授予应用程序使用的主体。所有权链接将保证数据访问程序调用者。访问可以通过检查存储过程来检查。这是一个简单的模型，易于理解，设计，部署和管理。存储过程的使用可以利用代码签名，最细粒度和功能强大的访问控制方法，也是唯一一个明显篡改的方法（签名在程序改变时会丢失）。

问题是，来自Visual Studio设计人员的每一点技术都会在这个建议面前飞来飞去。开发人员将看到只使用存储过程难以使用的模型。开发人员喜欢先设计他们的类模型，并从逻辑模型中生成表结构。基于程序的指导方针使程序首先在应用程序的第一行写入之前存在，并且由于现代开发的迭代方式，这在开发中实际上是有问题的。这不是无法解决的，只要团队领导层意识到问题并解决问题（即，准备好的程序，即使是在开发周期开始时为嘲笑）。