最近，我们有一个存储过程请求，需要跨多个数据库进行访问。当然，这种情况并不少见，但在我们的例子中，之前我们使用了服务帐户，并且该服务帐户对所有数据库都有读/写权限。
但是现在我们将所有权限更改为 Windows 登录 AD 组，并且 AD 组中的用户没有对所有数据库的所有权限。
例子：
- AD 组 UG1 有 10 个用户，它们是数据库 A 上的用户。
- 存储过程 PROCA 驻留在数据库 A 中，但对属于数据库 B 和数据库 C 的表进行了选择。
- 已将执行权限授予存储过程 PROCA 和 AD 组 UG1，因为已在数据库 B 和数据库 C 上创建用户（没有其他权限）。
- DatabaseA、DatabaseB 和 DatabaseC 的数据库所有者在登录 XXX 下。
众所周知，这种跨数据库的权限可以通过
- 选项 1：在所有数据库上打开数据库跨链，或
- 选项 2：授予 AD 组 UG1 所需的数据库（B 和 C）的单个对象权限或
- 选项 3：在 DatabaseA 上使用 Trustworthy db 选项并更改存储的 proc PROCA 以包括以“dbo”用户身份执行，以便可以模拟权限。
- 选项 4：使用证书
我的问题是关于安全性并保持简单和安全的最佳解决方案是什么？
请注意，没有一个开发人员是任何数据库的数据库所有者，并且提升的权限只分配给 DBA，因此有人黑客攻击或 SQL 注入或冒充系统管理员的可能性是“无”的。
但同样，我想知道您在这种情况下会怎么做？我更喜欢选项3。
选项1是最糟糕的..不会使用那个..
选项 2 大量的管理工作..
选项3（见最后一句话:)）
选项 4最近我不得不考虑如何保护数据库。我的解决方案就是这个。这里有一篇关于安全性的好文章。甚至认为一开始使用证书有点复杂（以前从未对它们做过任何事情）我对这个选择感到非常高兴。我授予证书登录/用户权限。我用该证书签署程序，一切正常。我使用相同的系统来授予动态 SQL 的权限（因此，如果存在 sp_executesql，我将必要表的最低权限授予证书用户，因此 proc 的调用者看不到表，我不必以所有者身份执行或 smthng）。授予使用非对称密钥的权利也是如此。而且我一直都知道谁是程序的调用者（没有执行为），即使在我的情况下它不是很重要..
在开发期间签署程序有点麻烦（试图找到解决这个问题的好方法）。目前我正在搜索过程文本（DDL 触发器）以使用其他数据库，如果找到它，我会打印出警告，该过程可能必须签名..
我想念的另一件事是无法签署函数或视图（必须有充分的理由），因此您不能使用它们来访问其他数据库。
我想说的最后一件事 - 我更愿意用最少的模式解决尽可能多的问题。所以如果你广泛使用“执行为”和代理用户，那么可信选项可能是更好的选择。