经过几次Google搜索并快速查看问题后，我似乎无法找到我认为是SQL Server权限的食谱答案。
正如我经常在小商店看到的那样，大多数开发人员在开发时都在使用SQL Server的管理员帐户。我想设置我可以分配给开发人员的角色和权限，以便我们可以完成工作，但也可以使用所需的最低权限。任何人都可以提供有关SQL Server权限分配的建议吗？
组件：
平台：
由于一些传统的应用和网络，我们正在运行“混合模式”安全性，但正在转向Windows身份验证。我不确定这是否真的会影响角色设置。
我计划将开发人员的访问权限设置为Prod和Staging / QA DB为只读。但是，我仍然希望开发人员保留运行性能分析的能力。
我们需要具有更高权限级别的部署帐户。我们目前正在尝试确切了解SSIS包部署所需的特权。
在开发服务器中，开发人员需要广泛的权限。但是，我不确定只是让他们所有的管理员都是最好的选择。
很难相信没有人发布过一个体面的示例脚本，可以为开发人员和部署人员设置一组适当的权限来设置这些角色。
我们可以通过锁定内容然后在发现需要时添加权限来解决这个问题，但这对于每个人来说都是太大了。
在这些平台上，有人能指出或提供这些角色权限的良好范例吗？
答案 0 :(得分：2)
这种情况因公司而异。关键因素是锁定生产，以便开发人员无法创建或更改对象。我们的开发人员只有prod的datareader权利，没有别的。除非登录到应用程序并使用应用程序的权限，否则它们甚至无法执行存储过程。
我们为dev上的许多开发人员提供了几乎完全的权限，但它可能会有所不同，具体取决于他们应该针对哪些数据库进行开发以及他们要为其支持的应用程序访问哪些服务器。因此，对一个开发服务器具有完全访问权限的开发人员甚至可能在另一个开发服
通过将devs锁定在prod之外我们已经获得了几个关键的东西。首先，没有牛仔数据库开发。他们知道他们必须为其他人创建脚本才能运行，因此他们不会随意进行随机更改。这也意味着它们不是将脚本放入源代码控制中的问题，因为拥有prod权限的人只有在源代码控制中才会运行脚本。
接下来，没有人会对即将发生的紧急情况进行未经测试的更改，这些变更永远不会降低到dev和qa，因此在下次加载新版本时会丢失。因此，对prod不起作用的改变也逐渐减少了，因为现在所有的东西都经过了测试，然后才有人试图将它投入生产。
人们也不会随时更改数据并意外更新整个用户表，因为他们忘记突出显示where子句（是的，这是在我们锁定prod之前发生的）。
答案 1 :(得分：1)
我一直在寻找类似的指导，但没有找到。经过一些实验，我认为一个简单的设置是将用户添加到“dbcreator”服务器角色，然后将它们添加到他们将要处理的每个数据库中的“db_owner”角色。这将允许用户创建新数据库，以及修改他们是“db_owner”成员的数据库。