链接服务器风险

aep*_*eus 12 performance sql-server-2008 security sql-server linked-server

我正在实施一项新功能,该功能需要来自多台服务器上的数据库的数据。我只需要合并来自所有这些服务器的数据并对其进行排序。想到的两个选项是:

  1. 使用链接服务器并编写一个简单的查询来合并和排序将从一台服务器运行并从其他服务器收集数据的数据。

  2. 使用应用程序从所有服务器收集数据,并将其发送回 SQL Server 进行排序(不想在应用程序中实现排序)。

我们在 SQL Server 2008 r2 的主动/主动集群中运行我们的服务器。所有数据库都具有相同的权限,如果您有权访问一个数据库/服务器,则您对它们都有权限。这是一个面向公众的应用程序(需要用户登录)。

使用链接服务器有哪些风险?是否有任何我应该关注的安全漏洞?在主动/主动集群中运行链接服务器是否有任何问题?与替代方案相比,是否存在任何重大的性能问题?

关于链接服务器似乎有普遍的负面“嗡嗡声”,但我找不到任何具体的东西让我相信那里有任何真正的担忧。

Dav*_*ett 14

只要您考虑到其中的含义,链接服务器就可以很好地工作:

  1. 安全性:一个关键的考虑因素是,如果你有链接的服务器,如果一个服务器受到威胁,它们都会面临很大的风险。即使您为每个用户在不同的服务器上拥有不同的凭据(如果唯一的攻击向量被泄露/发现/猜测的凭据,这将阻止攻击者获取其他资源),该链接也可以有效地绕过所有这些。该链接还将绕过对公共网络隐藏其他数据库的保护,例如在一个或多个服务器未向公共接口提供数据的情况下,因此通常无法通过防火墙看到。您可能会想“好吧,复制的问题不是同样的风险吗?” 答案是肯定的,但是复制是在单个应用程序数据库之间进行的,链接服务器路由可能会危及同一服务器上的其他数据库,因为链接是在服务器级别而不是数据库级别(当然,您可以通过仔细控制用户访问来降低这种风险权利,但您至少需要在您的计划中意识到这一点)。关于安全性的附带说明:如果服务器不在同一站点上,请确保使用某种形式的 VPN 将它们链接起来,而不是让 SQL Server 在公共接口上可用。

  2. 带宽:如果所有服务器都在同一个 DC 中,它们之间具有良好、快速、不限流量的连接,那么您可能不需要担心这一点,但是对于更远的连接要更加小心,特别是如果您的用户能够运行广告-各种临时查询。对于大多数数据集而言,VPN 链路级别的压缩将有很大帮助,但请注意,这将以更大的延迟为代价,这可能会加剧效率问题(见下文)。

  3. 效率:如果您只是简单地将大块数据拉下线,那么这不是一个大问题(但请考虑锁定:请参阅我的下一点),但是一旦您通过连接等方式执行任何操作,就会有限制查询规划器可以优化您的请求。如果它需要进行许多索引查找,如果服务器由于网络延迟而不是彼此本地,则会创建运行非常缓慢的查询(本地服务器肯定也存在同样的问题,但当然程度较小),并且它可能会改为使用索引扫描(牺牲带宽使用以获得延迟收益)消耗带宽,并且如果它持有锁(以避免脏读问题等),这也会影响应用程序的其他部分。

  4. 锁定/并发:脱离服务器会增加查询的运行时间,这将加剧您可能还不知道的锁定问题,从而严重降低应用程序的并发性和可扩展性。如果使用常规和/或长时间运行的跨服务器查询,您需要非常小心,您要密切关注锁定问题并酌情提供计划程序提示。

只要您有足够的规定来管理安全和性能问题,我就不会认为使用链接服务器有问题,尽管可能有更好/更安全/更可靠/更容易安全的方法来实现相同的目标结果。


Mat*_*att 1

我也经历过同样的负面“嗡嗡声”,但我在链接服务器上遇到的唯一问题是您可以轻松地通过网络提取大量数据。从 DBA 的角度来看,如果您有非 DBA 可以做到这一点,即使他们承诺不会滥用它,这也是可怕的。

在您的情况下,编写自己的应用程序似乎没有任何好处,因为这仍然需要移动数据。听起来您有一个非常简单的权限模型,因此根据环境,可能值得设置一些特殊权限,以便链接不会在不需要的地方使用。