我们正在 DMZ 公司的独立 LAMP 平台上部署一个简单的时事通讯 webapp。关于 MySQL 服务器是否应该从 DMZ 中移除并放入内部网络的问题存在一些讨论。
服务器位于防火墙后面，仅开放了 80 端口，MySql 将连接到非标准端口。该数据库包含客户电子邮件地址。
这是一个安全的设置（或足够安全）吗？将数据放在第二个防火墙后面会更安全吗？（我更像是一名开发人员，所以我并不真正了解这里的所有安全方面 - 有人可以启发我！）
更新 只是为了澄清并在此处添加更多评论是我们当前的设置：
互联网 - 防火墙 1 - http 服务器 - 防火墙 2 - 应用服务器 - 防火墙 3 - 企业资源
这个新应用程序应该完全进入防火墙 1 和 2 之间的 DMZ。我们目前正在讨论将 MySQL 服务器拉到第二个防火墙后面。
允许从 DMZ 到内部 LAN 的连接打破了 DMZ 的概念。
将 MySQL 绑定到 localhost 将不会比将 MySQL 放置在其他地方更安全。如果您担心数据盗窃，您应该假设两台机器分开并且 Apache 部分被破坏，那么存储在受感染机器上的 MySQL 连接详细信息可能会被攻击者简单地重新利用来读取数据。
编辑添加：
即使使用您所描述的双跳 DMZ，您也不会从分离服务中获得任何真正的安全优势，同时使设置更加复杂。您甚至可能通过拥有更多机器并通过线路发送数据来增加攻击面，否则这些数据将处于环回状态。
我会将数据库放在内部网络中（在第二个防火墙后面）。
这大大减少了数据库的攻击面，因为您将第二个防火墙（DMZ 到内部）的防火墙规则设置为仅允许来自网络服务器的端口 XXXX（数据库端口）上的连接。
因此，即使您的 DMZ 遭到破坏，您的数据库仍然受到保护。
让我们评估这两种情况，看看哪一种更好。我想您已将 MySQL 帐户配置为仅对特定于应用程序的表具有 READ/WRITE 访问权限。
我将使用零日漏洞攻击网络服务器。我现在拥有对 Web 服务器的管理员访问权限，并且可以完全访问本地文件系统。我还可以发送源自该网络服务器的网络通信。我已获得访问应用程序数据库所需的凭据的访问权限。
如果数据库服务器在同一台机器上，我现在也可以直接和完全访问数据库。我可以读取和写入数据库中的所有表，创建新表并监听与该数据库服务器的所有其他通信。评价：这是最坏的情况。应用程序数据库和所有其他数据库现在都受到影响。
如果数据库服务器在同一个 DMZ 中的不同机器上，我可以与数据库服务器完全通信。我现在可以使用 Windows 文件共享服务中的漏洞来获得对该服务器的管理员访问权限。评估：我可以使用 Web 应用程序帐户访问数据库服务器，但这可能只给我有限的权限。我需要一个不同的漏洞来获得对数据库服务器的完全访问权限。我可以利用数据库服务器上的任何可用服务。
如果数据库服务器在完全不同的网络中，我只能访问数据库端口。任何其他通信都会被防火墙过滤。这意味着我只能使用数据库程序中的漏洞来获得管理员访问权限。如果我获得管理员访问权限，则整个内部网络都会受到威胁。评估：我可以使用 Web 应用程序帐户访问数据库服务器，但这可能只给我有限的权限。我只能利用数据库端口来获得完全访问权限。如果我这样做，数据库服务器的网络就会受到威胁。
我认为 MySQL 部分已经被充分覆盖，我当然同意已经说过的话。我只想指出，作为第一步，您应该了解您所在地区的法律要求是什么，因为它们差异很大。很可能这将决定您的配置。
数据库服务器应与任何外部 Internet 连接隔离，因此只有应用程序服务器（加上管理所需的任何内容）可以连接到数据库。如果它与应用服务器分开 - 这样做有多种原因 - 然后适当地设置防火墙和安全性。
破坏应用程序服务器很可能使数据库攻击者可以使用应用程序的登录凭据，因此某种级别的数据库或应用程序级别的安全性可能会有所帮助。例如，您可以按照以下方式进行某种职责分离：
设置数据库对象所有权，以便应用程序不能直接读取客户数据，而必须通过存储过程。完整的信用卡号只能写入 - 存储过程可以允许更新它们，但只能读取“更新详细信息”屏幕的最后 4 位数字。任何需要 CC 号码的东西都可能存在于不同的服务器上并通过不同的帐户连接。
如果财务是在物理上不同的服务器上管理的（可能与公共互联网隔离），那么您最多可以发出虚假订单或类似的订单，而不会实际损害服务器。获取信用卡信息需要破坏两台机器（应用服务器和数据库服务器或财务服务器）。您还必须从受感染的 Web 服务器发起攻击。这为您提供了更长的窗口来检测活动，因为攻击者无法同时破坏两台机器。
DB 和金融服务器机器也有一组非常具体的与 Web 服务器的交互。这使您可以假设大多数（如果不是全部）与应用程序相关的活动都是可疑的，并在这些机器上设置一个具有超偏执配置的 IDS。
如果机器受到攻击，那么 MySQL 服务器是否在 DMZ 中都没有关系。访问 MySQL 数据库的凭据将在某处的 Web 应用程序代码中，并且 DMZ 中的机器必须有权访问它，因此防火墙不会在这种情况下保证您的数据安全。
更好的设计可能是让 Web 应用程序编写一个队列，然后将其拉入受保护网络内的 MySQL 数据库中。这将限制客户数据暴露于队列中的内容。只是在这里大声思考。这对于您的特定应用程序可能不起作用或不实用。
您不得允许任何来自 DMZ 的流量进入内部网络。这真是个坏主意！如果有人可以控制您的网络应用程序 dmz，那么就有可能打开与您内部网络中的服务器的连接，并完全控制您的整个网络。如果您想将 Web 应用程序从您的网络中分离出来，我建议您创建另一个 DMZ 并将您的数据库放在那里。允许从您的 Web 服务器到其他 DMZ i 的唯一流量。我见过一些糟糕的防火墙设计，这就是其中之一。
Håkan Winther 高级 DBA 和一家安全公司的前任所有者。