为什么不允许组拥有数据库？哪个用户应该拥有数据库？

Question

根据微软“SQL Server 数据库的 ALTER AUTHORIZATION”：

对新主人的要求：

新的所有者委托人必须是以下之一：

• SQL Server 身份验证登录。
• 代表 Windows 用户（不是组）的 Windows 身份验证登录。
• 通过代表 Windows 组的 Windows 身份验证登录进行身份验证的 Windows 用户。

显然一个组不能拥有一个数据库。确实调用

alter authorization on database::MyDatabase to [domainname\SQLServerAdminGroup]

结果在消息中

数据库类型的实体不能由角色、组、approle 或映射到证书或非对称密钥的主体拥有。

例如，让 SQL 管理员的 Windows 安全组的单个成员成为数据库所有者似乎很容易受到该帐户被废弃的影响。在这个问题中，这似乎是所有者员工离开公司时发生的事情。 此答案将数据库所有权作为 NT 主要主体的问题总结如下：

将数据库所有权默认为 NT 主要主体会产生一个包含问题（所有者是由 AD 管理的 NT SID，并且不会随数据库文件一起移动，NT 帐户可能会被指纹等）。

我是 SQL Server 管理的新手，与例如文件的所有权相比，只有主要主体才能成为所有者的限制很突出。根据微软“如何分配和更改所有者”：

默认情况下，新对象的所有者是在附加到创建过程的访问令牌中标识为默认所有者的安全主体。...当用户是管理员组或域管理员组的成员时，会发生唯一的例外。在这两种情况下，用户访问令牌中的所有者字段包含组的 SID，而不是单个用户帐户的 SID。假设管理帐户仅用于管理系统，而不用于任何个人目的。因此，由一个管理员创建的对象可以由同一组中的其他管理员管理。

换句话说，

• 对于管理员创建的文件，文件的默认所有者是组，而
• 对于数据库，所有者不能是组。

这给我留下了以下问题：

1. 数据库不能由次要主体拥有是否存在根本原因？
2. 哪个主体应该拥有一个数据库？有最佳实践吗？如果是这样，该最佳实践背后的原因是什么？

Answer 1

老实说，sa或者禁用具有绝对最低权限的 SQL Server 帐户是最佳选择。至于为什么？好吧，我可以写出三到四段，或者我可以分享我最喜欢的文章，关于哪个帐户应该拥有数据库以及为什么。涵盖所有基础的非常详尽的解释。强烈推荐。

这是核心摘录：（编辑添加此 1/9/2020）

好吧，那么sa呢？它已经可以做任何它想做的事情，所以它不像我们授予额外的权限，它不能退出或被解雇，无论如何都不应该使用它。哎呀，你可能有残疾，对吧？你知道吗？这其实是完全合理的！事实上， sa 是一个非常常见的用作数据库所有者的 ID。

唯一的风险是数据库是否变得可信。然后，您可以创建可以充当 sa 的存储过程。老实说，即使那样，这也不是一个巨大的风险，因为您必须具有模拟权限才能使用 EXECUTE AS 子句创建过程。这意味着为了创建该存储过程，您已被明确授予模拟 db_owner 角色成员的能力（请不要这样做）或自己成为 db_owner 的成员。这确实意味着拥有 db_owner 的人可以成为系统管理员，但同样，风险很小。TRUSTWORTHY 并不常见，希望您在使用它时了解风险并避免危险的权限。

但是，风险就是风险。因此，如果我们感到特别偏执和/或有一个非常敏感的系统，最简单的解决方案是创建一个 SQL 登录（使用一个非常复杂的密码，因为没有人会用它登录），禁用它，然后使用它作为业主。

Answer 2

1. 数据库不能由次要主体拥有是否存在根本原因？

我不是 100% 确定此限制的原因，尽管我怀疑它与模拟（即成为）该 SID 的能力有关。某些操作可以到达实例之外（例如操作系统、文件系统等），其逻辑通常是模拟 Windows 登录，或使用 SQL Server 服务帐户进行 SQL 登录。进程不能模拟组。但是，我猜如果 SID 是 Windows 组，逻辑也可以使用 SQL Server 服务帐户，不是吗？我不知道，除了简单的武断之外，想不出任何半途而废的合理解释。

不过，我可以说，我不同意人们不应该使用 Windows 登录作为数据库所有者的概念/建议，至少出于上述原因。在将数据库备份和还原到不同服务器上、在 SQL Server 中创建的 SID 或来自 Windows 或 AD 的 SID 之间没有太大区别。在任何一种情况下，您都可以很容易地恢复到不知道数据库所有者 SID 的实例。编写脚本并传输登录名以在新实例上重新创建可能会稍微容易一些，这样它就可以dbo在恢复时匹配数据库中用户的 SID 。但是，所有者 SID 最初将是执行的 SID，RESTORE并且无论如何都需要更新某些内容（除非您使用sa因为这保证会出现在新实例上，但这并不是一个好的选择；稍后会详细介绍）。最后，更改数据库本身的所有者sys.databases和dbo用户都相当容易，或者dbo在执行还原后简单地将数据库中用户的 SID 更新为新实例上的现有SID 。有几种选择，没有一个是那么困难。

并且关于 SID 不是“与数据库文件一起移动”的担忧不应适用于物理 MDF、NDF、LDF 文件，因为这些文件应该由 SQL Server 服务帐户拥有，而不是数据库所有者。

2. 哪个主体应该拥有一个数据库？有最佳实践吗？如果是这样，该最佳实践背后的原因是什么？

这里的答案归结为重点：方便XOR安全？选一个。

一个问题是数据库所有者用于确定某些操作的权限。就sa其本质而言，该帐户不受任何限制（除了可能对其自身施加限制，但现在我们只是愚蠢）。我不确定该操作列表是什么，但是使用低特权 SQL Server 登录作为所有者绝对是人们发现这些操作是什么的一种方式;-)（因此为什么这么多人更喜欢使用sa，即使这是一个糟糕的选择；稍后会详细介绍）。

该问题与执行其中包含的代码时可能发生的权限提升问题不同EXECUTE AS...。如果对象有效地由（直接或存在于-owned 模式中）拥有，则它是否作为执行owner或dbo没有区别。从技术上讲，这也与使用if是固定服务器角色成员的登录名创建的 proc 实际上相同。在这些情况下，如果启用了 的数据库属性，则执行模块（存储过程、触发器、标量 UDF、表值函数等）的任何人都将承担这些实例级权限。Laughing Vergil 链接的帖子提到需要获得许可dbodboEXECUTE AS [bob][bob]sysadminTRUSTWORTHYIMPERSONATEEXECUTE AS，但那是误导。该IMPERSONATE只需要权限创建与模块EXECUTE AS ...。但是，IMPERSONATE是不是当需要执行与创建的模块EXECUTE AS...。因此，这不是一扇完全敞开的门，但是如果 DB 所有者登录名是固定服务器角色的成员，并且在该 DB 中启用，则任何对创建的 proc 具有 EXEC 权限的人都EXECUTE AS 'dbo' 将以系统管理员身份执行该模块中的代码.sysadmin TRUSTWORTHY

苏：

• 如果您想要永远不必考虑任何事情的便利，或者可能需要几分钟来设置适当的安全性，那么sa它会尽可能方便。
• 如果您想要适当的安全性并且可以接受偶尔遇到权限错误，这会导致一些额外的小工作（尽管不多）来设置模块签名（并且在初始设置之后，甚至可以更快/更容易地根据需要添加其他权限，如果需要）然后使用低权限的 SQL Server 登录。

就我个人而言，我使用第二个选项（低特权 SQL Server 登录）进行生产，并且为了方便我使用的测试/演示sa或其他一些sysadmin登录。