SQL Server 应该与 IIS 安装在同一台计算机上吗?

发布于 2024-07-08 18:35:19 字数 1477 浏览 8 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

满意归宿 2024-07-15 18:35:19

出于安全目的,最好将网络计算机和数据库计算机分开,最好在两者之间设置防火墙。 Web 服务器向全世界公开。 不幸的是,有些人以窃取或损坏这些服务器上包含的信息为乐。

然后是性能方面。 SQL Server 喜爱内存是众所周知的事情。 IIS 也是如此,特别是当网站大量使用缓存和会话信息时。 所以这里也存在潜在的冲突。 拥有一台专用于 SQL Server 的机器显然比使用一台机器来完成所有负载要好。

然后,分离可以更容易地识别调整的需要以及调整各个硬件组件的能力。

总而言之,一台功能强大到足以在实时环境中满足 IIS 和 SQL Server 需求的机器不一定比为每台服务器的特定要求指定的两台机器便宜。 (杰夫·阿特伍德在一个播客中提到,升级一台机器的成本与购买第二台机器相同)

For security purposes it is good to separate web and database machines, preferably having a firewall between the two. A web server is exposed to the world at large. Unfortunately there are people who take pleasure in stealing or damaging the information contained on those servers.

Then there is the performance aspect. It's common knowledge that SQL Server loves memory. So does IIS, particularly if the web-site makes extensive use of caching and session information. So you have a potential conflict here as well. Having a dedicated machine for SQL Server is clearly better than having a single machine doing all the load.

Then, separation allows easier identification of the need to tune and the ability to tune individual hardware components.

To sum up, a machine powerful enough to cope with the demands of both IIS and SQL Server in a live environment won't necessarily be cheaper than two machines specced for the specific requirements of each server. (Jeff Atwood mentioned in one of the podcasts, that upgrading the one machine would have cost the same as getting a second machine).

梦里°也失望 2024-07-15 18:35:19

@MarkR

通过将 SQL Server 移动到另一个盒子确实增强了安全性,这与暴露的攻击面有关。

Web 服务器容易受到来自 Internet 的恶意访问。 人们希望这种情况永远不会发生,但已经存在(并且将来可能存在)可通过穿越防火墙的格式错误的请求来利用的漏洞。

利用这些漏洞之一可能会导致任意代码能够执行。

如果 Web 服务器以这种方式受到损害,则该计算机上运行的任何其他内容现在都容易受到攻击,并且漏洞利用软件可能会在特权上下文中运行。 受感染机器的攻击面要广泛得多。

如果 SQL Server 安装在同一台计算机上,则任何数据库都容易受到攻击。

现在,如果 SQL Server 安装在单独的计算机上,则它本身只能通过其公共接口进行访问。 数据库的附加表面仅限于该接口。 因此,要危害数据库,您现在必须首先危害 Web 服务,然后是 SQL Server。 这比将它们放在同一台机器上要困难得多。

进一步扩展该原则,它也是使用存储过程的一个论点。 如果 Web 服务器只能使用存储过程访问数据库服务器,则接口以及攻击面都会受到极大限制。 如果 Web 服务器能够针对数据库服务器执行任意 SQL,则攻击面会再次比实际需要的大得多,并且数据的风险也会大大增加。

在数据有价值的系统中,这些风险虽然相对较小,但却非常真实,确定此类风险的业务风险是解决方案设计的一个重要方面。

@MarkR

Security is indeed enhanced by moving SQL Server to another box and it's to do with the Attack Surface exposed.

The web server is exposed to malicious access from the Internet. One hopes it would never happen, but there have been (and could in future, be) vulnerabilities that can be exploited via malformed requests that traverse firewalls.

Exploiting one of these vulnerabilities could lead to arbitrary code being able to execute.

In the event that the web server is compromised in this way, anything else that runs on that machine is now vulnerable and exploit software could potentially run in a privileged context. The attack surface of the compromised machine is much wider.

If SQL Server is installed on the same machine, any database is vulnerable.

Now, if SQL Server is installed on a separate machine, it can itself only be accessed via its public interface. The attach surface of the database is limited to that interface. So, to compromise the database, you now have to compromise the web service first, THEN the SQL Server. This is MUCH more difficult than having them on the same machine.

Extending the principle further, it's also an argument for the use of stored procs. If the web server is only able to access the database server using stored procs, the interface, and hence the attack surface, is massively constrained. If the web server is able to execute arbitrary SQL against the database server, the attack surface is again much bigger then it needs to be and the risk to the data is greatly increased.

In systems where data is valuable, these risks, while relatively small, are very real and determining the business exposure of such risks is an essential aspect of solution design.

叫思念不要吵 2024-07-15 18:35:19

将它们放在同一台机器上:

  • 减少它们之间的延迟 - 因此,如果您有大量简单的查询,这可以提高性能
  • 让您的开发和性能测试更容易,因为您可以使用单个机器(或虚拟机)来完成

如果应用程序没有需要冗余并且不需要横向扩展,将它们放在同一个盒子上绝对是胜利 - 它更容易维护。

我不认为安全论据有任何分量——我不认为将它们分开有任何安全好处。 无论如何,Web 服务器需要对数据库有足够的访问权限才能查看和修改所有或大部分数据,因此如果它完全受到攻击,SQL 框也会有效地受到攻击。

Putting them on the same machine:

  • Reduces latency between them - so if you have lots of easy queries, this can improve performance
  • Make your development and performance testing easier because you can do it with a single box (or VM)

If the application does not need redundancy and doesn't need to scale out, putting them on the same box is definite win - it's far easier to maintain.

I don't think the security argument carries any weight - I don't see any security benefit of separating them. The web server would need to have enough access to the database to view and modify all or most of the data anyway, so if it were fully compromised, the SQL box would effectively be compromised too.

阳光下慵懒的猫 2024-07-15 18:35:19

对于非常敏感的站点,在它们之间设置防火墙的单独服务器的优势可能很有用,但它带来了许多问题。

  1. 拆分 IIS 上的查询性能 - 由于需要通过网络传递数据,SQL 服务器可能运行非常慢,即使服务器相距 2 英尺,DNS 也可能仍然是一个因素,因此可能需要做一些工作才能使应用程序能够访问工作也分开。
  2. 管理。 这可能是显而易见的,但它有 2 台服务器、2 个 Windows 许可证以及所涉及的管理以及穿越防火墙的复杂性。

拆分服务器建议:

  1. 在服务器之间安装千兆位 LAN。
  2. 优化查询以存储过程的形式运行
  3. 优化查询以仅返回最少量的数据。
  4. 确保服务器间寻址使用 IP 地址或有效的 DNS 查找。
  5. 为 SQL 负载提供足够的内存来存储临时结果。

For very sensitive sites, the advantage of separate servers with firewalls between them can be useful but it brings a number of issues.

  1. Performance of queries on split IIS - SQL servers can run very slow due to the need to pass data across the network, also DNS may still be a factor even with servers 2 feet apart, so there maybe some work to do to get an applications to work as well split.
  2. Management. It maybe obvious but its 2 servers, 2 windows licenses and the management that's involved and the complexity of traversing firewalls.

Split server recommendations:

  1. Install a gigabit LAN between servers.
  2. Optimised queries to run as stored procedures instead
  3. Optimise queries to only return the minimum amount of data.
  4. Make sure interserver addressing uses the IP address or effective DNS lookup.
  5. Give the SQL loads of memory sufficient for temporary results.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文