• 最好的放置是将数据库服务器放在它们自己的受信任区域中。
• 它们应该只允许来自 Web 服务器的入站连接，并且应该在防火墙和机器上强制执行。现实通常要求更多的机器（数据库管理员等）。当然，根据需要服从现实。
• 只有在您更新它们的软件时，它们才应该建立出站连接。

同意 Jeff Ferland 的观点，数据库服务器应该是独立的：你应该有一个干净的网络来进行复制和备份。

请原谅我的 ASCII 艺术，一个合理的理想的快速概述：

      [internet]
          |
    outer-firewall--- [proxy-zone]
          |      
          +---- [app-zone]
          |
    inner-firewall 
       |        |
[lan]--+        +-- [database-zone]

1. 在代理区域中运行反向代理 Apache+mod_security/varnish/nginx/WAF/whatever。如果需要，也可以在此处添加负载平衡/故障转移。如果需要，还可以为出站连接（DNS、SMTP、HTTP 代理）添加代理/中继服务器。
2. 当应用程序逻辑在 Web 服务器 (Java/PHP/ASP) 上运行时，我更喜欢将其称为应用程序服务器。
3. 当您需要扩展时，您可以水平扩展，负载均衡器使这更容易。您还可以考虑将静态和/或未经身份验证的内容复制到前端代理（提前考虑 URL 路径、主机名和 cookie 在这里得到回报）
4. 您可能想要添加一个或多个区域类型：IDS、管理、备份、远程访问、出站代理

您正在尝试减轻，因此：

• 区域间通信必须限制在服务、管理和监控所需的最低限度内。
• 反向代理接受来自 Internet 的不受信任的连接，并且只能启动到应用程序服务器上的服务的连接，没有出站 Internet 连接。如果您想按性质/流量对您的区域进行分类（颜色），您需要仔细考虑终止 HTTPs，并且如果您想创建与应用服务器的新 HTTPs 连接（更新：您可能会这样做，但您可以配置一小部分快速密码，并省略 CA 包以保持低开销）。
• application zone 接受来自代理的半信任连接，并且只能启动到数据库的连接。当您知道应用程序服务器不直接与 Internet 对话时，您可以更加信任它们。
• 数据库服务器只接受来自应用服务器的连接，数据库区域应该是你的“最干净”的网络
• 考虑为外部和内部防火墙使用不同的防火墙（供应商/产品）
• 对于所需的出站服务（DNS、SMTP 或修补/更新），这些应该通过不同的服务器（例如在代理区域或单独的出站代理区域）。
• 任何出站 CC 验证 HTTPS 连接也是如此。（如果你不幸有一些供应商或服务黑匣子进行验证，这些也应该放在一个专用区域，恕我直言。）
• 仅在代理区域中使用公共 IP 地址，在其他地方使用私有地址。代理区域之外的任何服务器都不需要公共 IP、NAT 甚至是到 Internet 的默认路由。

单独的区域使您的 IDS 的工作更容易，并且记录更有效。区域应在第 2 层（交换）和第 3 层 (IP) 隔离。如果您有资源，请为每个服务器添加一个管理区域、单独的管理 NIC（如果可以，请保护端口）。服务监控最好通过运营网络进行。

实际上，您最终可能会将“理想”网络压缩为单个防火墙和 VLAN。任何 dev/preprod 环境都应该尽可能地复制操作网络（特别是如果您不想追踪引入的尾部调试问题，例如丢弃的空闲连接）。如果您现在考虑上述选项，那么将来迁移应该会更容易，即在您友好的邻居 PCI-DSS 审核员下次访问后不久；-)

以下是 DMZ 架构的常见设置：

互联网

^

防火墙1

^

DMZ（在此处托管您的 dmz 服务器，仅允许特定端口通过防火墙）

^

防火墙2

^

数据库网络（仅允许从防火墙 2 到该网络的特定端口和协议）

正如您提到的数据库包含信用卡（敏感）数据，那么即使在防火墙2 的内部，数据库网络也应该与公司和用户网络隔离。很多时候，我看到公司的皇冠上的宝石在内部网络上敞开着供所有用户探测和访问。更进一步，您可以让数据库管理 VLAN 仅允许此 VLAN 权限内的系统访问数据库（当然，需要从 DMZ 访问它的应用程序除外）。

希望这可以帮助。

三层架构是最安全和可扩展的解决方案。随着客户端流量的增加，我们可以添加尽可能多的中间层来确保性能。三层架构也更安全，因为中间层正在保护数据库层。我们需要保护数据库层不被直接访问，并且需要将其放置在受信任的区域中，并且它应该只接受来自应用程序服务器的连接。