Man*_*uel 36 sql sql-server security
我在网上搜索了一下,找不到任何真正指向该地点或覆盖基础如何在数据库上设置用户/角色.
基本上,将有一个用户将用于从应用程序(在本例中为Web应用程序)访问数据库,该用户将需要访问数据库以进行常规数据库操作(选择,插入,更新,删除)和执行存储过程(使用exec在其他存储过程/ UDF中运行存储过程).
然后,我们还有一个主要管理员用户(这很简单).
我目前有一个开发环境,在我看来我们并没有真正管理安全性(应用程序使用具有db_owner角色的用户,尽管它是一个Intranet应用程序).尽管它是一个Intranet应用程序,但我们仍然考虑到安全性,并希望了解开发人员为此类环境设置用户/角色的方式.
编辑:Web应用程序和SQL Server驻留在不同的计算机上.
编辑:忘了提到使用需要直接读/写访问的ORM.
问题: 设置用户进行应用程序访问的"最佳实践"是什么？将适用哪些角色以及哪些角色？
Wya*_*ett 41
首先,我倾向于将权限封装在数据库角色中,而不是将它们附加到单个用户主体.这里的最大胜利是角色是数据库的一部分,因此您可以完全编写脚本安全性,然后告诉部署类型"添加用户并将他添加到此角色"并且他们不会与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术语集成身份验证中).只需在两个框上使用相同的凭据(用户/通过组合).设置应用程序域以在Web框上以该用户身份运行,并在sql框上设置由该主体支持的Sql Server用户并获利.也就是说,使用数据库角色几乎可以使您与此决定脱节,因为部署类型应该能够处理创建SQL用户并根据需要修改连接字符串.
Rem*_*anu 14
很长一段时间,SQL Server对数据库的应用程序访问指南是将对数据的访问隔离到存储过程中,将过程分组到模式中,并将模式上的执行授予应用程序使用的主体.所有权链接将保证对过程调用者的数据访问.可以通过检查存储过程来检查访问.这是一个简单的模型,易于理解,设计,部署和管理.使用存储过程可以利用代码签名,最细粒度和最强大的访问控制方法,以及唯一一个防篡改(如果程序被更改,则签名丢失).
问题是Visual Studio设计人员提出的每一项技术都面临着这一建议.开发人员面临的模型很难仅与存储过程一起使用.开发人员喜欢首先设计他们的类模型,并从逻辑模型生成表结构.在编写应用程序的第一行之前,基于过程的指南首先要求程序存在,并且由于现代开发的迭代方式,这在开发中实际上存在问题.这是不可解决的,只要团队领导层意识到问题并解决它(即准备好程序,即使是嘲笑,当开发周期开始时).
创建Web应用程序使用的用户"webuser".
仅授予存储过程执行权限给该用户.不允许直接表读/写.如果你需要从表中读取内容,请编写一个proc.如果需要写入数据,请编写另一个proc.
这样一切都保持简洁.一个应用用户,仅具有相关权限.如果安全性受到损害,那么入侵者所能做的就是运行procs.