任何减少我在生产中的特权但不会使我的工作过分困难的指示

在Windows 2008 R2上运行SQL Server 2005和2008。

我们将减少对开发人员的生产特权- 我想自己做为DBA一样，限制生产权并在需要时提升权限。

我的主要目标将是消除愚蠢的错误- 由数据库管理员做，devopers将有最多的生产读访问。我们喜欢表现得像我们是超级英雄，不会犯错，但是一直没有生产权是有道理的，这是一些人推荐的最佳做法。

最好的方法是什么？在日常使用和安装过程中，最痛苦的是什么？

当前，我们有一个DBA Windows组，该组对我们所有的服务器和数据库都有权限。

我也会对降低OS /远程登录权限感兴趣-但我最关心数据库权限。

我猜想我们需要提升特权才能以sa身份运行跟踪，并且可能需要进行一些所有权清除，才能删除旧登录名的SA权利。我们可能还会遇到什么其他问题？

感谢您的建议并分享您的经验！

理想情况下，对于可运行的生产数据库，您根本不希望开发人员完全有权访问服务器或服务器上的任何数据库。此类事情是您必须首先实现SOX合规性之一。

对于运行userID的权利类型，它们真正应具有的唯一权利是db_datareader，db_datawriter并且是显式的GRANT EXECUTE ON x TO y（对于每个存储的proc和xuserID的用户定义函数y）。

如果您需要在生产中运行跟踪，则会遇到一些问题，这将需要一堵长城文本™来解释。我的第一个建议是要像生产一样锁定QA环境，如果需要运行跟踪，请将prod db的备份还原到QA并在其中运行跟踪。同样，如果您有SOX，HIPAA或PCI-DSS要求，那么最好在将产品数据恢复为QA之前对其进行清理。

当前，我们有一个DBA Windows组，该组对我们所有的服务器和数据库都有权限。

给他们登录并查看数据权限；但是，要执行DBAly职责，请使用具有更高特权的单独登录。我知道一位这样做的财务客户-常规的基于Windows身份验证的登录名受到他们可能无意造成的损害的限制。恢复并运行需要使用单独的SQL身份验证登录名运行的DML。

与我合作的一个政府机构为每个服务器/数据库管理员使用2个单独的登录名。因此，如果Tangurena是我的域登录名（此登录名将具有常规User特权），TangurenaAdmin则将是我的单独Administrator登录名。如果您一直都在使用管理员帐户，则会遇到麻烦，但是该帐户缺少其他权限（例如没有电子邮件。哦，您说这是一件坏事...）。

我正在与之合作的当前政府机构让每个服务器/数据库管理员的权限都高于标准用户，但管理员权限不高（将其视为PowerUser组）。域管理员功能是通过共享的域管理员帐户执行的。

常见的错误是还原错误的数据库（例如通过生产服务器还原的质量检查），而这不能通过权限限制或多次登录来解决。成对地进行可能具有破坏性的事情是使风险最小化的一种方法。

我猜我们需要提升特权才能以sa身份运行跟踪

不需要。您只需要ALTER TRACE权限：http :
//msdn.microsoft.com/zh-cn/library/ms187611.aspx

首先，我建议您在开发或QA环境中进行所有特权操作，如果删除访问一段时间后不会出现问题。您将需要查看应用程序是否在安全性方面没有任何问题。

我将告诉您我们的内部方法：

• 所有应用程序都使用一个域用户，该用户被授予对数据库的必要权限（通常是db_owner数据库角色）。

• 对于偶尔读取的数据，我们使用SQL登录。我们为该用户分配数据库角色-db_datareader。这是结束对主数据库集群上的开发人员的访问的地方。对于其他任何想法，他们将使用报表服务器数据库，该数据库是在午夜完成的主服务器数据库的副本（使用日志传送完成）。为了不使用杀手级即席查询杀死报告服务器，我们使用内存和cpu的资源组分配。

• 对于DBA团队，我们有一个域组，该域组具有计算机和服务器上的所有特权（Windows计算机上的admin和sql服务器上的sysadmin）

• 对于安装，我们在运行更新时使用的数据库上具有一个db_owner的SQL用户-我们使用DDL触发器来监视架构更改，并且我们应该查看哪些更改是在安装期间完成的或作为单独的更改进行的

• 有经验的开发人员有时会有一些例外，但是在满足他们的需求后，我们将删除他们的访问权限-他们将根据其域登录名获得权限，因此我们可以在trace / ddl视图中监视连接，并使用ddl触发器监视任何可能的更改。

至于使用登录名和用户进行所有工作的方式-在服务器安全文件夹中的Management Studio中，创建所有需要的登录名，然后将它们与数据库关联并赋予它们所需的角色。如果对操作进行脚本编写，您将看到最初将创建一个服务器登录名，然后创建一个连接到该登录名的数据库用户，然后为该用户分配数据库角色。您可以将该脚本保留在脚本集中，这样您就可以每次验证哪些用户应该处于活动状态，哪些应该不存在。

在SQL Server中，您可以创建一个数据库用户并为它分配一个database role具有读/写/所有权的权限。将用户迁移到生产环境后，您可以转到已迁移的数据库用户，然后取消选中您不希望拥有的角色。例如，假设用户stan是测试中db_owner（数据库的所有权）的成员。将用户stan迁移到生产环境后，您可以将其从db_owner中取出，并仅为其分配db_datareader角色（只读）。

在SQL 2005+中，可以使用进行更精细的控制schema。查看架构上的此链接以获取更多详细信息。