在开发箱上为开发人员授予SA特权

8

尽管有强烈的抗议，我们的管理层还是决定必须在开发服务器上授予开发团队“ sa”权利。问题是我们DB支持小组仍然负责维护此框。

现在，我们已经被委托为具有这些增强的特权的开发团队提供了一个“要注意事项”清单。

请添加到此列表：

做-将活动限制在正在开发的数据库中

不要 -

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

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

sql-server  sql-server-2005  permissions 
— 拉吉
source
1
他们需要执行哪些任务，从而需要更高级别的SA特权？
我认为db_owner就是他们所需要的...
5
好的，如果不建议他们“添加/更改/删除数据库对象”，他们应该怎么做？拥有开发工具箱的全部意义不是因为他们可以打破它吗？
— Stuart Ainsworth
这些是应用程序开发人员。他们需要具有“ sa”特权，才能在Dev Studio中调试存储过程。管理层已经做出了决定，他们不愿意让步。我们正在努力减少潜在的头痛
2
这个问题+1，因为我已经几次打过这个问题了。另一个解决方案：给开发人员一个带有SQL的沙盒虚拟机，使其成为100％的老板。他们还100％负责保持其生命力：）->令人惊讶的是，开发人员学会不破坏其自身系统的速度有多快：)
— Martin S. Stoller 2012年

Answers:

8

如果还不算太晚，我见过的一个折衷方案就是行之有效，而不是升级权限或替换开发人员的现有帐户，而是创建一个单独的帐户，该帐户仅在他们需要提升的权限时才使用。

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

最终，如果存在滥用，该帐户上的日志可以用作取走该帐户的证据。

— 乔尔·科洪
source
6

它说（MSDN），您需要sysadmin（sa）才能在SQL Server 2005上进行调试。

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

我还建议给他们本地SQL Express，它也可以解决其他问题。

（使用更多信息编辑）

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

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

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

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

— gbn
source
1
对于超出界限进行编码的开发人员，答案是在锁定的情况下进行持续集成，因为这将由用户权限运行，并相应地使构建失败。让构建服务器从头开始重新创建数据库，并用测试数据填充数据库（当然，这些数据全部来自SCM）。（就我而言，我使用与应用程序安装程序用于创建新数据库的代码完全相同的代码，从而测试了安装程序以及应用程序。）
1
@克雷格商人：行不通。改写我的旧答案，开发人员将不会受到信任，并且集成不会检测所有情况。我是开发人员dba：客户代码猴子是我的敌人。在我的企业中，我赢了...。这是我的火车，我处理的是最低的公分母...
— gbn 2010年
显然，您的里程可能会有所不同。根据我的经验，我通常必须进行一些培训/指导以说明如何以及为什么要完成工作，但是在那之后事情通常会运行得很好。当然，我一直坚持认为，超出开发范围的唯一构建就是来自受严格控制的构建服务器的构建-如果代码未在其中构建，那是代码（或测试）的问题，而不是代码的问题。组态。我已经在许多公司的小型团队和大型项目中做到了这一点，并且始终成功。
3

如果是开发服务器，那么开发者具有完全访问权限又有什么问题？告诉开发人员您不能添加/删除/更改数据库对象（例如：表，列，索引），就像告诉他们“您可以拥有一个编译器，但不允许其运行”。在我看来，开发人员希望/需要访问他们自己的数据库实例的目的是专门允许他们测试解决问题的不同方法，而不必使用PRODUCTION或TEST数据库。您应该鼓励这种行为，而不是阻止它。

有人可能建议开发人员使用SQL Express的本地实例，但是尽管每个开发人员的SQL Express都可以解决某些问题，但与单独服务器上的完整SQL Server相比，它具有不同的限制和性能特征。

您应该做的是制定一个定期的备份计划（至少每晚一次），并与开发人员合作，以确保他们知道如何启动计划外的备份以及如何从备份中还原，从而在出现问题时将停机时间降到最低。

— 克雷格商人
source
您的类比完全错误。发生的事情是它们四处乱窜，然后在无法将其四处迁移到锁定服务器时发牢骚。我当然是开发人员DBA :-)
— gbn
然后需要一点教育。我是一个经常成为DBA的开发人员。在这两个世界都站稳脚跟，教我双方共存通常是我的工作。毕竟，是用户是敌人，而不是DBA或开发人员……
还有一些诸如维护计划之类的东西，他们是不应该访问的。
— Joel Coehoorn
1
问题是，我们有多个开发组，并且该服务器托管了所有数据库。拥有“ sa”权利的组仅拥有33％的Db。令人担心的是，它们可能使服务器瘫痪并使服务器瘫痪，从而也影响其他小组。该公司不希望为他们购买单独的硬件，除非我们能够证明他们搞砸了。
2
这是荒谬的。每个开发小组都应该拥有自己的服务器，因此任何人都不能踩到任何东西。如今，硬件几乎是免费的，软件几乎和硬件一样便宜。并且，如果您的组织足够大，可以有多个开发组，则应该使用服务器虚拟化，这将使所有这些工作变得更加容易。
3

它是开发服务器，而不是数据库支持组服务器或生产服务器。保留良好的备份/映像，并让开发人员破解。让DBA控制devbox就像让尾巴摇狗一样。开发人员可以在那里进行开发工作。这涉及到有时破坏事物并删除表，然后使用不同的设置将它们放回去。一段时间之后，开发箱总是处于失修状态，这就是我们要做的。如果我们不知道问题出在哪里，我们会尝试不同的方法。其中有些很容易撤消，有些则不那么容易。

这里的问题是，开发人员很容易忘记他们所构建的应用程序不会一直具有相同的权限。是的，给他们sa，但是做到这一点，使它们默认情况下不是sa，以便他们知道什么时候做的事情需要一些额外的工作才能正确部署。
— Joel Coehoorn
1

我认为他们不需要在“开发”框中具有SA特权。在几乎所有情况下，他们都可以做到。

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

题：

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

— 拉吉·莫尔（Raj More）
source
对不起，我很困惑。我的意思是开发人员不得更改数据库设置或删除数据库。
1

我们要求所有数据库结构更改都必须使用脚本（即使在开发环境中）进行，并保存在Subversion中。然后，按照既定的时间表，我们从产品中刷新开发人员，他们必须重新运行脚本才能返回到开发周期中的位置。这有助于确保通过脚本完成所有操作，并确保在部署时已准备好脚本。

我知道您可以在2008年设置DDL触发器来跟踪数据库结构更改，您可以在2005年做到这一点吗？这样，至少您可以找出某人何时更改设置，并找出原因。

— 赫尔格姆
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.