我们正在公司 DMZ 中的独立 LAMP 平台上部署一个简单的新闻通讯 Web 应用程序。有人讨论是否应将 MySQL 服务器从 DMZ 中移除并放入内部网络。
服务器位于防火墙后面，仅开放 80 端口，MySql 将连接到非标准端口。数据库包含客户电子邮件地址。
这是一个安全的设置吗（或者足够安全）？将数据放在第二个防火墙后面会有多安全？（我更像是一名开发人员，所以我并不真正了解这里的所有安全方面 - 有人可以启发我吗！）
更新 只是为了澄清并吸引更多评论，以下是我们当前的设置：
互联网 - 防火墙 1 - http 服务器 - 防火墙 2 - 应用服务器 - 防火墙 3 - 企业资源
这个新的应用程序应该完全位于防火墙 1 和 2 之间的 DMZ 内。我们目前正在讨论将 MySQL 服务器拉到第二道防火墙后面。
答案1
允许从 DMZ 到内部 LAN 的连接会破坏 DMZ 的概念。
将 MySQL 绑定到本地主机的安全性不会低于将 MySQL 放置在其他地方的安全性。如果您担心数据被盗，您应该假设两台机器分开并且 Apache 部分受到损害，那么存储在受损害机器上的 MySQL 连接详细信息可能会被攻击者重新利用来读取数据。
编辑以添加：
即使像您所描述的那样使用双跳 DMZ，您也无法通过分离服务获得任何真正的安全优势，同时使设置更加复杂。您甚至可能通过拥有更多机器并通过网络发送原本会回送的数据来增加攻击面。
答案2
我会将数据库放在内部网络中（第二个防火墙后面）。
这大大减少了数据库的攻击面，因为您将第二个防火墙（DMZ 到内部）的防火墙规则设置为仅允许来自 Web 服务器的端口 XXXX（数据库端口）上的连接。
因此，即使您的 DMZ 受到威胁，您的 DB 仍然受到保护。
答案3
让我们评估一下这两种情况，看看哪种情况更好。我假设您已将 MySQL 帐户配置为仅对特定于应用程序的表具有读/写访问权限。
我将使用零日漏洞攻击 Web 服务器。我现在拥有 Web 服务器的管理员访问权限，并且可以完全访问本地文件系统。我还可以发送源自此 Web 服务器的网络通信。我已获得访问应用程序数据库所需的凭据。
如果数据库服务器在同一台机器上，我现在也可以直接完全访问数据库。我可以读取和写入数据库中的所有表、创建新表并监听与此数据库服务器的所有其他通信。评估：这是最糟糕的情况。应用程序数据库和所有其他数据库现在都受到影响。
如果数据库服务器位于同一 DMZ 内的另一台机器上，我就可以与数据库服务器进行完全通信。我现在可以利用 Windows 文件共享服务中的漏洞来获得该服务器的管理员访问权限。评估：我可以使用 Web 应用程序帐户访问数据库服务器，但这可能只授予我有限的权限。我需要不同的漏洞才能获得对数据库服务器的完全访问权限。我可以利用数据库服务器上可用的任何服务。
如果数据库服务器位于完全不同的网络中，我只能访问数据库端口。任何其他通信都将被防火墙过滤。这意味着我只能使用数据库程序中的漏洞来获得管理员访问权限。如果我获得管理员访问权限，整个内部网络就会受到威胁。评估：我可以使用 Web 应用程序帐户访问数据库服务器，但这可能只会给我有限的权限。我只能利用数据库端口来获得完全访问权限。如果我这样做，数据库服务器的网络就会受到威胁。
答案4
数据库服务器应与任何外部互联网连接隔离，以便只有应用服务器（以及管理所需的任何设备）可以连接到数据库。如果它与应用服务器分开 - 这样做有多种原因 - 然后适当地设置防火墙和安全性。
入侵应用服务器可能会让数据库攻击者获得应用程序的登录凭据，因此某种程度的数据库或应用程序级安全性可能会有所帮助。例如，您可以按照以下方式进行某种责任分离：
设置数据库对象所有权，这样应用程序就不能直接读取客户数据，而必须通过存储过程。完整的信用卡号只能写入 - 存储过程可以允许更新它们，但只能读取“更新详细信息”屏幕的最后 4 位数字。任何需要信用卡号的东西可能位于不同的服务器上，并通过不同的帐户连接。
如果财务信息在物理上不同的服务器上管理（可能与公共互联网隔离），那么您最多可以发出虚假订单或类似的东西，而不会真正危及服务器。获取信用卡信息需要危及两台机器（应用服务器和数据库服务器或财务服务器）。您还必须从受感染的 Web 服务器发起攻击。这为您提供了更长的检测活动窗口，因为攻击者无法同时危及两台机器。
DB 和财务服务器机器还与 Web 服务器有一组非常具体的交互。这允许您假设大多数（如果不是全部）与应用程序无关的活动都是可疑的，并在这些机器上设置具有极度偏执配置的 IDS。