在开发盒上为开发人员授予 SA 权限

Question

尽管我们强烈抗议，但我们的管理层决定必须授予开发团队对开发服务器的“sa”权限。问题是我们，DB 支持组仍然负责维护这个盒子。

我们现在被委托为具有这些增强权限的开发团队制定一份注意事项列表的任务。

请添加到此列表中：

DO——将活动限制在正在开发的数据库中

不要 -

• 更改任何 SQL 实例设置
• sp_configure（包括 cmdshell）
• 添加/更改/删除任何安全设置
• 添加/更改/删除数据库对象
• 添加/更改/删除服务器对象，如备份设备和链接服务器
• 添加/更改/删除复制
• 添加/更改/删除维护计划
• 接触任何不属于您团队的数据库

任何指向可用于跟踪这些用户活动的工具的指针将不胜感激。

Answer 1

如果现在还为时不晚，我已经看到一个很好的折衷选项，而不是升级权限或替换开发人员的现有帐户，而是创建一个单独的帐户，仅在他们需要提升的权限时使用。

所以通常它们在单独的“受限”帐户下工作（我松散地使用它，因为这些受限帐户仍然需要一些巨大的权限——即创建、删除、更改表）。但是在他们认为需要的极少数情况下sa，他们可以使用此帐户登录。然后，您可以在日志中标记该帐户并对其进行额外监控。您已经为开发人员提供了他们要求的访问权限，但以一种更加可控的方式。

最终，如果存在滥用行为，此帐户上的日志可以作为证据将其删除。

Answer 2

它在这里说(MSDN) 您需要 sysadmin (sa)才能在 SQL Server 2005 上进行调试。

但是，this SO question显示了另一种没有sa 的方式，这就是我最初的想法。只需让他们运行sp_sidedebug

我还建议给他们本地 SQL Express，这也解决了其他问题......

（编辑了更多信息）

编辑，在 W. Craig Trader 的回答之后

“sa”权限的其他问题，在最坏的情况下：

• 开发人员将创建不受信任的 CLR 程序集
• 他们将使用 xp_cmdshell
• 所有操作都在 sql server 服务帐户的上下文中
• 他们将承担客户端连接的 sa 权限
• 等等等等

例如 xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

Answer 3

我认为他们不需要开发盒上的 SA 权限。几乎在所有情况下，他们都可以不用。

我认为一个不错的选择是安装本地开发版本。

问题：

您不希望开发人员添加/更改/删除数据库对象？！！他们将如何发展？