那么第一个明显的优势是，如果有人打破了容纳您的应用程序服务器的盒子，则不能保证他们可以访问容纳数据库的同一台服务器。此外，通过分离此功能，您可以让 IT（软件开发人员、管理员等）更轻松地最大限度地减少对环境不同方面的代码更改影响/策略更新。这绝不会修复糟糕的编码或弱安全性（SQL 注入、默认用户名/密码）。但它确实有助于整体上更好的安全态势。

• 面向 Internet 的 Web 服务器完全没有理由访问 LAN/域，因此应该完全禁止这样做。理想情况下，它应该在 DMZ 上。

  • 这为“拥有”面向 Internet 的 Web 服务器攻击您网络的其余部分的攻击者提供了重要的保护。
  • 当然，出于 HA（高可用性）、DR（灾难恢复）和性能原因，您可以根据需要拥有任意数量的这些。
  • 中：对 WAN/DMZ 边界有严格规定，完全禁止“到 LAN”DMZ/LAN 流量，对“到 DMZ”DMZ/LAN 流量有严格规定，或类似的。
  • 高级：“外部”DMZ，对 WAN/OuterDMZ 和 OuterDMZ/InnerDMZ 边界或类似边界都有严格的规则。

• 面向内部的 Web 服务主机可能需要对 LAN/域（主要是您的数据库）的有限访问

  • 如果它没有对数据库使用域类型身份验证，它仍然不需要在域上
  • 当然，出于 HA（高可用性）、DR（灾难恢复）和性能原因，您可以根据需要拥有任意数量的这些。如果您使用具有高迭代次数的非常好的密码哈希（PBKDF2、bcrypt、scrypt），您将需要更多的处理和/或 RAM。
  • 虽然这是一个比面向 Internet 的 Web 服务器更好的攻击 LAN 的平台（除非它们是同一个机器，或者更糟糕的是，同一个站点），但它仍然应该具有非常有限的访问权限 - 通过数据库端口访问数据库机器仅，能够提取防病毒更新和推送防病毒警告等。
  • 基本：这是托管面向 Internet 的 Web 服务器或类似服务器的同一操作系统实例。
  • 中：这也在 DMZ 上，完全保护来自 WAM 的入站流量，以及对出站到 WAN WAN/DMZ 边界的严格规则，以及对 DMZ/LAN 边界或类似的严格规则。
  • 高级：这是在“内部”DMZ 上，对 OuterDMZ/InnerDMZ 和 InnerDMZ/LAN 边界或类似边界都有严格的规则。

• 数据库服务器很可能在您的 LAN 上，这使其成为攻击者更有价值的目标；它可能需要备份，需要被除网络之外的各种程序访问，等等。

  • 与往常一样，SQL 注入直接从 Internet 注入您的数据库。参数化你的 SQL！
  • 在此服务器与 LAN 和 Internet 上的其他服务器之间拥有多个明确定义的最小权限层，并具有良好的设计和实施，有助于增加攻击数据库服务器所需的工作量，更不用说攻击成功了。

本质上：

• Internet -> 网站 + 服务 + DB 意味着只要操作系统的一个妥协，攻击者就可以控制一切，包括直接泄露或破坏数据库（或备份）中的所有数据 - 无需通过 Web 界面来执行此操作.

• Internet ->Web site + services ->DB 意味着攻击者需要通过您的 Web 服务的钥匙孔来破坏您的数据库，或者需要破坏一台以上只有一些共享安全漏洞的机器。

• Internet -> 网站 -> Web 服务 -> DB 更好 - 攻击者需要通过 Web 服务的锁孔破坏您的数据库，正如通过您的网站的锁孔所看到的那样，或者需要破坏多个（或两个） ！）具有一些但不是全部共享安全漏洞的机器。

不用说，在每个级别上，您都应该尽可能安全 - 最新的补丁和防病毒软件、用于防止 SQL 注入的参数化 SQL、白名单条目、长密码随机密码、加密数据、加密连接、强散列密码（PBKDF2、bcrypt、scrypt）、加密和散列的良好算法选择、每层之间只打开最小端口、检查日志以查找攻击痕迹、IDS/IPS 软件/应用程序等等。

它确实需要一些计划或一些游戏（或两者）设置。

好吧，通过将 Web 服务器与数据库服务器分开，如果用户可以利用 Web 应用程序并提升他们自己的权限，他们可能会弄乱您的数据，但仅限于数据库服务器上的安全模型允许的程度。例如，虽然他们可以读取和写入客户数据（如果他们可以对 Web 应用程序的操作方式进行逆向工程），但他们无法批量下载整个数据库，或者完全删除它，或者通过重写它来破坏/破坏/以其他方式降级它架构。此外，旨在保护您的数据库服务器的新一代特定于应用程序的防火墙和 IDS 系统可以根据已知的攻击特征和启发式检测和阻止异常访问，从而保护您的数据免受客户端访问的损害。

如果数据库服务器为多个 Web 服务器提供数据，这将派上用场。