在 Windows 2008 R2 上运行 SQL Server 2005 和 2008。
我们将减少开发人员在生产中的特权——作为 DBA，我想为自己做同样的事情，限制生产权限并在需要时提升权限。
我的主要目标是消除愚蠢的错误 -由 DBA犯下，开发人员最多在生产中具有读取权限。我们喜欢表现得像我们是不会犯错的超级英雄，但并非一直拥有生产权是有道理的，这是一些人推荐的最佳做法。
最好的方法是什么？日常使用和安装过程中什么最不痛苦？
我们目前有一个 DBA 的 Windows 组，它有权访问我们所有的服务器和数据库。
我也有兴趣降低操作系统/远程登录权限——但我最关心的是数据库权限。
我猜我们需要提升权限才能以 sa 身份运行跟踪，并且可能需要在我们取消旧登录名的 SA 权限之前进行一些所有权清理。我们还可能遇到什么其他问题？
感谢您的建议和分享您的经验！
首先，我建议您在开发或 QA 环境中进行所有特权游戏，如果访问权限被删除一段时间也没有问题。您将需要查看应用程序是否有任何安全问题。
我会告诉你我们的内部方法：
所有应用程序都使用一个域用户，该用户被授予对数据库的必要权限（通常是 db_owner 数据库角色）。
对于偶尔的数据读取，我们使用 SQL 登录。我们为该用户分配数据库角色 - db_datareader。这是它结束开发人员对主数据库集群的访问的地方。对于他们可能有的任何其他想法，他们将使用报告服务器数据库，这些数据库是在午夜完成的主服务器数据库的副本（使用日志传送完成）。为了不使用杀手级临时查询杀死报告服务器，我们使用内存和 CPU 的资源组分配。
对于 DBA 团队，我们有一个域组，它拥有机器和服务器的所有权限（windows 机器上的管理员和 sql server 上的系统管理员）
对于安装，我们有一个 SQL 用户，它是我们在运行更新时使用的数据库的 db_owner - 我们使用 DDL 触发器来监视模式更改，我们应该看到哪些更改是在安装期间完成的或作为单独的更改
有经验的开发人员偶尔会有一些例外，但在满足他们的需求后，我们会删除他们的访问权限 - 他们会根据他们的域登录获得权限，因此我们可以监控跟踪/ddl 视图中的连接以及 ddl 触发器的任何可能更改。
至于使用登录名和用户完成所有工作的方式 - 在 Management Studio 的服务器安全文件夹中，您创建所有需要的登录名，然后将它们与您的数据库相关联并为它们提供所需的角色。如果编写操作脚本，您将看到最初将创建一个服务器登录名，然后是一个连接到该登录名的数据库用户，然后为该用户分配一个数据库角色。您可以将脚本保留在脚本集中，这样您就可以每次验证哪些用户应该处于活动状态和踢球状态，哪些用户不应该处于活动状态。
理想情况下，对于可操作的生产数据库，您根本不希望开发人员有权访问服务器或服务器上的任何数据库。这类事情是您必须为SOX合规性做的首要事情之一。
对于 userIDs 运行的那种权利，他们真正应该拥有的唯一权利是
db_datareader,db_datawriter和 explicit （对于userIDGRANT EXECUTE ON x TO y的每个存储过程和用户定义函数）。xy如果您需要在生产中运行跟踪，就会遇到一些问题，需要 Great Wall of Text™ 来解释这一切。我的第一个建议是拥有一个像生产一样锁定的 QA 环境，如果需要运行跟踪，将 prod 数据库的备份恢复到 QA 并在那里运行跟踪。同样，如果您有 SOX、HIPAA或PCI-DSS要求，那么您最好在将产品数据恢复到 QA 之前对其进行清理。
授予他们登录和查看数据的权利；但是，要执行 DBAly 职责，请使用具有提升权限的单独登录。我认识一位这样做的金融客户 - 基于常规 Windows 身份验证的登录在他们可能无意中造成的损害方面受到限制。恢复和运行 DML 需要使用单独的 SQL 身份验证登录运行。
与我合作的一个政府机构为每个服务器/数据库管理员使用了 2 个单独的登录名。因此，如果
Tangurena是我的域登录（此登录将具有常规User权限），那么TangurenaAdmin将是我的单独Administrator登录。如果你一直使用你的管理员帐户，你会遇到麻烦，但它缺乏对其他事情的权限（比如没有电子邮件。哦，你说喜欢它是一件坏事......）。我正在使用的当前政府机构让每个服务器/数据库管理员都拥有高于标准用户的权限，但不是管理员（将其视为
PowerUser组）。域管理员功能是使用共享域管理员帐户执行的。一个常见的错误是恢复了错误的数据库（比如在生产服务器上恢复了 QA），这不会通过限制权限或多次登录来解决。两人一组做具有潜在破坏性的事情是将风险降至最低的一种方法。
不需要。您只需要 ALTER TRACE 权限：http:
//msdn.microsoft.com/en-us/library/ms187611.aspx
在 SQL Server 中，您可以创建一个数据库用户并为其分配
database role读/写/所有权权限。将用户迁移到生产环境后，您可以转到已迁移的数据库用户并取消选中您不希望其拥有的角色。例如，假设用户 stan 是 test 中 db_owner（数据库的所有权）的成员。将用户 stan 迁移到生产环境后，您可以将其从 db_owner 中取出并为其分配一个 db_datareader（只读）角色。在 SQL 2005+ 中，可以使用
schema. 检查架构上的此链接以获取更多详细信息。