我正在收听 podcast #19,Joel 和 Jeff 正在争论在与您的 IIS 安装相同的机器上运行 SQL Server。我不得不说,这听起来像是 Jeff 对 Joel 弃牌了,但话又说回来,我只是在猜测哪个是哪个。;)
各自的优缺点是什么?哪个更好?
我通常单独运行它们(Joel 的偏好),但我可以看到 Jeff 的观点,即两者之间的距离更近。
我正在收听 podcast #19,Joel 和 Jeff 正在争论在与您的 IIS 安装相同的机器上运行 SQL Server。我不得不说,这听起来像是 Jeff 对 Joel 弃牌了,但话又说回来,我只是在猜测哪个是哪个。;)
各自的优缺点是什么?哪个更好?
我通常单独运行它们(Joel 的偏好),但我可以看到 Jeff 的观点,即两者之间的距离更近。
出于安全目的,最好将 Web 和数据库机器分开,最好在两者之间设置防火墙。Web 服务器向整个世界公开。不幸的是,有些人乐于窃取或破坏这些服务器上包含的信息。
然后是性能方面。众所周知,SQL Server 喜欢内存。IIS 也是如此,尤其是当网站大量使用缓存和会话信息时。所以你在这里也有潜在的冲突。为 SQL Server 配备一台专用机器显然比让一台机器完成所有负载要好。
然后,分离可以更容易地识别调整的需要和调整单个硬件组件的能力。
总而言之,一台足够强大的机器可以同时满足实时环境中 IIS 和 SQL Server 的需求,不一定比为每个服务器的特定要求指定的两台机器便宜。(Jeff Atwood 在其中一个播客中提到,升级一台机器的成本与购买第二台机器的成本相同)。
@MarkR
通过将 SQL Server 移动到另一个盒子确实增强了安全性,这与暴露的攻击面有关。
Web 服务器暴露于来自 Internet 的恶意访问。人们希望它永远不会发生,但已经存在(并且将来可能存在)可以通过穿越防火墙的格式错误的请求来利用的漏洞。
利用其中一个漏洞可能导致任意代码能够执行。
如果 Web 服务器以这种方式受到威胁,那么在该机器上运行的任何其他东西现在都容易受到攻击,并且漏洞利用软件可能会在特权上下文中运行。受感染机器的攻击面要广泛得多。
如果 SQL Server 安装在同一台机器上,任何数据库都容易受到攻击。
现在,如果 SQL Server 安装在单独的机器上,它本身只能通过其公共接口访问。数据库的附加表面仅限于该接口。因此,要破坏数据库,您现在必须首先破坏 Web 服务,然后是 SQL Server。这比将它们放在同一台机器上要困难得多。
进一步扩展原理,它也是使用存储过程的一个论据。如果 Web 服务器只能使用存储过程访问数据库服务器,那么接口和攻击面就会受到很大限制。如果 Web 服务器能够对数据库服务器执行任意 SQL,那么攻击面就会再次变得更大,并且数据的风险也会大大增加。
在数据有价值的系统中,这些风险虽然相对较小,但却非常真实,确定此类风险的业务风险是解决方案设计的一个重要方面。
将它们放在同一台机器上:
如果应用程序不需要冗余并且不需要横向扩展,那么将它们放在同一个盒子上是绝对的胜利 - 它更容易维护。
我认为安全论点没有任何意义——我认为将它们分开没有任何安全好处。Web 服务器需要对数据库有足够的访问权限才能查看和修改全部或大部分数据,因此如果它完全受到攻击,SQL 框也会受到有效攻击。
对于非常敏感的站点,在它们之间使用防火墙的单独服务器的优势可能很有用,但它带来了许多问题。
拆分服务器建议: