通过第三个数据库使用同一登录名连接两个数据库是否更安全？

我们有以下设置：

• 包含私有数据的多生产数据库，桌面软件使用该数据库
• 公共网站的Web数据库，需要来自私有数据库的一些数据
• 一个中间数据库，其中包含一些视图和存储过程，这些视图和存储过程从私有数据库中提取数据

当前，网站登录到Web数据库，并且Web数据库连接到中间数据库以提取数据或在生产数据库上执行存储过程。所有数据库都在同一SQL实例上，并且整个过程使用相同的用户帐户。

该用户帐户具有对Web数据库和中间数据库的完全访问权限，但只能访问和私有数据库的特定视图和存储过程

这真的比仅使公共数据库直接连接到私有数据库更安全吗？

似乎中间数据库只是使事情复杂化，因为使用同一登录名来访问所有数据库中的数据，并且它已经仅限于专用数据库中所需的视图/ SP。我希望将其删除。

一件事跳到这里：

整个过程使用相同的登录凭据集

问题

因此，假设的userX（无论是使用Excel的肉食还是IIS AppPool Identity）都可以看到一些视图和代码。这些视图和代码位于哪个数据库中都没有关系，因为无论如何在3个数据库中都设置了userX。

但是，您将失去像这样的所有权链。

比方说WebDB.dbo.SomeProc电话PrivateDB.dbo.SomeTable。UserX需要对两个对象都有权限。如果正在OneDB.WebGUI.SomeProc使用，OneDB.dbo.SomeTable则仅OneDB.WebGUI.SomeProc需要权限。不会检查对具有相同所有者的引用对象的权限。

注意：我对跨数据库所有权链接没有太深入的了解。我只知道普通的老“所有权链”以及

现在，根据注释，您确实有2个可以组合的数据库。最初暗示不是3。但是，中间体和纤网可以结合使用。

其他“私有”数据库也许可以合并，但这将是一个单独的问题。有关“一个或多个数据库”的完整讨论，请参见底部链接。

解？

如果额外的数据库仅是代码容器，那么架构是一个更好的主意。

听起来您使用了“数据库”，而您应该使用“架构”（在SQL Server的意义上，不是MySQL的意义）。我要有一个WebGUI架构，一个Helper或Common架构（以替换中间数据库）和Desktop架构。这样，您可以根据客户端分离权限，并且只有一个数据库

使用一个数据库（除了“所有权链接”之外），您还可以开始考虑索引视图，SCHEMABINDING（我一直使用它），而这在单独的数据库中是无法做到的

有关模式的更多信息，请参见以下问题：

• 模式设计-最佳做法？
• 过度使用/正确使用模式？

最后，似乎没有理由基于“不需要交易完整性”拥有单独的数据库。请参阅以下问题对此进行解释： 关于何时使用非dbo模式与新数据库的决策标准

答案是：这取决于。如果不能从外部内部LAN（或仅通过VPN）访问私有数据库，则此方案会增加安全性，因为使用WebSite凭据的人对私有DB Server的访问将受到限制（并且还有很多工作要做）进入您的内部网络-在发现入侵和关闭漏洞方面可能很方便）。

如果没有，我认为除了复杂性外，它不会增加任何其他内容。

编辑：

似乎我误解了您的问题，所以让我们看看我现在是否正确理解：IntermDb是一个仅用于连接到PrivateDB的空数据库，或者它是具有自己视图/过程的数据库，该数据库连接到PrivateDB以检索数据？

在第一种情况下，WTF？撕掉它。除非有人想要对其进行审核以更懒惰地描述对PrivateDB的访问（并使WebApp开发人员更加努力地工作），否则这毫无价值。SQL Profiler可以使用DB_ID进行过滤...

在第二种情况下，我维持先前的答案。

编辑：“我仍然不知道这比直接将私有数据库直接连接到公共数据库更安全，因为在同一SQL实例上的所有3个数据库和用于所有3个数据库的登录名都是相同的，并且只能访问无论如何，私有数据库中的特定视图和存储过程”。

拥有中介意味着入侵者将必须在您的代码中进行挖掘以了解 IntermDB的存在-并且必须在其上挖掘您的代码以了解是否存在PrivateDB。

如果将PrivateDB放置在组织LAN / WAN内部的另一台服务器上（如果可能），它可以给管理员足够的时间来检测和阻止入侵的企图。如果您使用同义词，那么此举很顺利，因为您所拥有的只是将它们重建为现有代码的正确位置。

您还将获得其他好处：由于所有代码都必须通过IntermDB来访问PrivateDB中的数据，因此没有开发人员会试图绕过它-并且这种尝试可以很容易地在SQL Server Profiler上发现为PrivateDb数据请求的DB_ID将是WebAppDb。