从 DMZ 中的 Web 服务器访问内部生产数据库中的数据答案

【问题标题】：Accessing data in internal production databases from a web server in DMZ从 DMZ 中的 Web 服务器访问内部生产数据库中的数据
【发布时间】：2011-05-07 11:51:00
【问题描述】：

我正在开发一个外部网站（在 DMZ 中），该网站需要从我们的内部生产数据库中获取数据。

我提出的所有设计都被拒绝了，因为网络部门不允许任何类型的连接（WCF、Oracle 等）从 DMZ 进入内部。

来自网络方面的建议通常分为两类-

1) 将所需数据导出到 DMZ 中的服务器，并最终以某种方式导出修改/插入的记录，或者

2) 从内部轮询，不断询问 DMZ 中的服务是否有任何需要服务的请求。

我反对建议 1，因为我不喜欢数据库位于 DMZ 中的想法。选项 2 似乎对正在做的事情的性质造成了可笑的额外复杂性。

这些是唯一合法的解决方案吗？我缺少一个明显的解决方案吗？ “禁止从 DMZ 进入”法令是否实用？

编辑：我经常听到的一句话是“没有大公司允许网站连接内部以获取实时生产数据。这就是他们发送确认电子邮件的原因”。真的是这样吗？

【问题讨论】：

这不是应该在 www.serverfault.com 上问的，因为这是一个管理员问题。但由于赏金，它不能被关闭......
“没有大公司允许网站内部连接以获取实时生产数据”完全是垃圾
我强烈建议，正如其他一些通过 mod-flags 所做的那样，Server Fault 社区会更好地服务。如果你愿意，我可以迁移它。
@Marc 我无法选择在哪个网站上提问。我选择 SO 而不是 SF 的原因是因为我觉得这个站点更有可能从具有这些系统经验的程序员那里获得实际的实现细节，而不是理论上谈论 DMZ 和连接点。但是，如果您觉得应该将其从 SO 中移走，我不会抱怨（很多；）。
嗯...既然已经获得了赏金，那就太尴尬了。也许在 SF 上重新提问，注意 SO 问题以供参考？

标签： security dmz

【解决方案1】：

很抱歉，您的网络部门正处于崩溃状态或类似情况 - 他们显然不明白 DMZ 的目的是什么。总而言之 - 存在三个“区域” - 大而糟糕的外部世界，纯洁和处女的内心世界，以及众所周知、值得信赖、安全的 DMZ。

规则是：

来自外部的连接只能到达 DMZ 中的主机和特定端口（80、443 等）；
从外部到内部的连接被完全阻断；
从内部到 DMZ 或外部的连接都非常好；
只有 DMZ 中的主机可以建立到内部的连接，并且同样只能在已知和允许的端口上建立连接。

第四点是他们没有掌握的——“与非军事区没有联系”政策是错误的。

问他们“那我们的电子邮件系统是如何工作的？”我假设您有一个公司邮件服务器，也许是交换，并且个人有连接到它的客户端。请他们解释您的公司电子邮件（可以访问互联网电子邮件）如何运作并符合他们的政策。

对不起，它并没有真正给你答案。

【讨论】：

是的，我昨天试图说服顶级人物。它不好的原因是，如果有人入侵了数据库前面的三台服务器和两个防火墙，那么没有什么能阻止他们进入产品数据库。
@aehiilrs：不幸的是，这也是开始时没有网站的原因。我的意思是，他们可以入侵网站和 dmz 并进入您的本地局域网......
显然@sysadmin1138（在之前的“服务器故障”讨论中，发生在 2010 年 3 月）对“第四点”的 Ken Ray 有相反的理解。请参阅serverfault.com/questions/125881/…，其中 sysadmin1138 表示以下内容：“适当的网络安全规定 DMZ 服务器不应访问‘受信任’网络。受信任网络可以访问 DMZ，但反之则不行。对于像您这样的数据库支持的网络服务器来说，这可能是一个问题，这就是为什么数据库服务器最终会出现在 DMZ 中。"。

【解决方案2】：

我是一家财富 50 强金融公司的安全架构师。我们进行了同样的对话。我不同意你的网络组。我理解他们的焦虑，并且我理解他们想要一个更好的解决方案，但大多数地方并没有选择更好的选择（由于他们的无知 [即网络人而不是你]）。

两个选项如果他们很难设置：您可以使用像 greensql 这样的 SQL 代理解决方案（我不为他们工作，只知道他们）他们只是 greensql dot com。

他们提到的大多数“大型组织”使用的方法是分层网络模型。您有一个前端 Web 服务器（由广大公众访问）、一个中间层（实际流程发生的应用程序或服务层）和一个数据库层。中间层是唯一可以与数据库层对话的东西。在我看来，这个模型对于大多数大型组织来说是最佳的。但是话虽如此，大多数大型组织将遇到供应商提供的不支持中间层的产品，他们在没有中间层的情况下开发，并且过渡需要他们不必为开发中间层 Web 服务而腾出的开发资源，或者说，某些公司完全没有优先选择这条路线。

这是一个灰色地带，在这方面没有绝对的对与错，所以如果他们说的是确定性的话，那么他们显然是错误的。我为他们的热情喝彩，作为一名安全专业人士，我了解他们来自哪里。但是，我们必须使业务能够安全运行。这就是我一直试图扔给自己的挑战和挑战。我如何才能提供我的客户（我的开发人员、我的管理员、我的 dbas、业务用户）他们想要的东西（在合理的范围内，如果我告诉某人不，我总是试图提供满足他们大部分需求的替代方案）。

老实说，这应该是一次公开的对话。我认为您可以在这里获得一些空间，让他们对他们希望减轻的风险进行威胁建模。要求他们提供使您的 Web 应用程序正常运行的替代解决方案。如果他们说他们不能说话，那么让他们有责任提供解决方案。如果他们不能，那么你默认它工作。您仅为已批准的端口打开从 dmz 到 db 的连接的站点。让他们知道 DMZ 是为了提供外部服务。除了潜在的文件传输解决方案之外，如果没有内部数据，外部服务就不好。

只是我的两分钱，希望这个评论有帮助。并尽量对我的安全兄弟轻松。在我们的羊群中，我们有一些经验较少的被误导的人，他们坚持一些旧的做事方式。随着世界的演变，威胁也在演变，我们的缓解方法也在演变。

【讨论】：

【解决方案3】：

为什么不复制数据库服务器？您可以确保连接是从内部服务器到外部服务器，而不是其他方式。

一种方法是使用 ms 同步框架 - 您可以构建一个简单的 Windows 服务，该服务可以将更改从内部数据库同步到外部数据库（可以驻留在单独的数据库服务器上），然后在面向公众的网站中使用它.优点是，您的同步逻辑可以过滤掉敏感数据，只保留真正需要的东西。而且由于数据的全部控制权将在您的内部服务器中（推送数据而不是拉取数据），我认为 IT 不会对此有任何问题。

形成的连接永远不会进入 - 它已经退出 - 这意味着不需要打开任何端口。

【讨论】：

不允许复制，因为（他们的话）如果有人入侵 Web 服务器并插入垃圾/删除数据，它将立即复制到内部数据库。也就是说，我将研究您建议的 MS Sync 框架，看看是否可以解决我们的问题。谢谢！
另一个缺点是有些数据可能被认为是 a) 敏感和 b) 必要的。
@aehiilrs Roopesh 正在谈论 PUSH 复制，其中 Web 服务器上的数据永远不会更新回原始数据库，数据只会被推送到它。但是您对敏感数据问题的看法是正确的
如果你使用sync框架来同步数据库，那么既可以过滤出去的数据，又可以保证数据只流向一种方式。那应该可以解决您的问题。如果您需要任何帮助，请发送邮件至 roopesh.shenoy@vagsons.com。

【解决方案4】：

在这方面我主要支持肯·雷；但是，似乎缺少一些信息。让我们看看我是否正确：

您有一个 Web 应用程序。
该 Web 应用程序的一部分需要显示来自不同生产服务器（不是通常支持您的站点的服务器）的数据。
您想要/需要的数据由内部完全不同的应用程序处理。
这些数据对您的正常业务流程至关重要，只需要向外界提供有限的一组数据。

如果我走上正轨，那么我不得不说我同意你的 IT 部门的意见，我也不会让你直接访问该服务器。

只需选择选项 1。让生产服务器将您需要的数据导出到通常可访问的放置位置。让另一台数据库服务器（DMZ 中的一个）获取数据并定期导入。最后，让您的网络应用只与 dmz 中的数据库服务器通信。

考虑到现在有很多人建立网站，我也不愿意只打开一个从 dmz 到相关 Web 服务器的 sql 端口。坦率地说，如果我确信 1. 你只使用存储过程来访问你需要的数据，我可以说服我打开连接； 2. 用于访问数据库的帐户信息被加密，完全限制只能运行那些procs； 3. 那些 procs 的动态 sql 为零并且仅限于选择； 4. 你的代码是正确的。

普通的 IT 人员可能没有资格回答所有这些问题。如果这个数据库来自第三方，我敢打赌，如果你从它的正常应用程序之外开始访问它，你可能会失去支持。

【讨论】：

好的，再次尝试回复。 1) 是的。 2) 不，此 Web 应用程序是内部应用程序的面向公众的部分。相同的数据。 3) 见 2。 4) 是的，但在某些情况下，内部和外部机器会竞争先到先得的位置。
至于 SQL 连接 - 可悲的是，当我们试图改变不这样做时，整个事情就出现了（据说应用程序几年前就以这种方式实现了）。我们想改为使用内部 Web 服务，这将允许我们在比 Web 服务器更受信任的服务器上进行更多验证，同时允许我们完全摆脱直接的数据库连接。当反应是“不，完全改变一切并推出你自己的数据传输代码”时，我们相当惊讶。不断地从内部轮询外部的服务请求真的合理吗？
@aehiilrs：在这种情况下，您的 IT 人员就处于崩溃状态。如果有帮助的话，几年前我曾与这样的 IT 人员打过交道。我花了 2 个月的时间反复去找我们的共同老板，“我很想实施这个，但由于 bozo 的限制我不能”但无济于事。最后，boss+bozo 被解雇了，突然间我们就可以完成工作了。不是我知道的答案，只是说我感觉到你的痛苦。
@aehiilrs：哦，还有一个痛苦的故事：几年前，我在一家有其他严厉政策的大公司工作。有一天，IT 人员决定开发人员无法拥有对其本地计算机的管理员访问权限。副作用是我们无法调试或应用程序，因为在 Visual Studio 中需要管理员访问权限。这花了 4 个月的时间，100 多个开发人员的抱怨和几乎没有工作完成，直到违规的人被解雇。美好时光。

【解决方案5】：

在谈论您的特定问题之前，我想先处理一下您提供的更新。

我没有为“大”公司工作过——虽然没有上下文很难判断大公司，但我已经为我曾经工作过的非营利组织和大学部门建立了自己的网络应用程序份额。在这两种情况下，我总是从 DMZ 上的 Web 服务器连接到内部网络上的生产数据库。我很确定许多大公司也这样做。例如，想想 Sharepoint 的架构是如何设置的 - 后端索引、数据库等服务器，这些服务器由位于 DMZ 中的前端 Web 服务器连接。

还有发送确认电子邮件的做法，我相信您在注册网站时指的是确认，通常不会处理安全问题。它们更像是一种验证用户是否输入了有效电子邮件地址的方法。

现在，让我们看看您的问题。不幸的是，除了您提出的两种解决方案之外，我想不出任何其他方法来做到这一点。尽管您可能想考虑一些事情：

解决方案 1：

根据您需要处理的数据的敏感性，将其提取到 DMZ 上的服务器上（无论是使用服务还是某种自动同步软件）都违反了基本的安全常识。您所做的是将数据从防火墙后面的服务器移动到防火墙前面的服务器。他们还不如让你从 DMZ 访问内部数据库服务器。

解决方案 2：

我不是网络专家，所以如果我错了，请纠正我，但是轮询机制仍然需要从 Web 服务器返回某种通信，以通知数据库服务器它需要返回一些数据，这意味着需要一个端口要打开，您不妨再次告诉他们让您轻松访问内部数据库，因为您并没有真正使用此方法添加任何额外的安全性。

所以，我希望这至少有助于为您提供一些参数，以允许您直接访问数据。在我看来，您的网络部门似乎对安全的数据库支持的 Web 应用程序架构应该是什么样子存在许多误解。

【讨论】：

问题不在于有沟通，而在于沟通渠道是从哪里打开的。

【解决方案6】：

这是你可以做的......这有点牵强，但它应该可以工作......

编写一个位于 DMZ 中的服务器上的服务。它将侦听三个端口 A、B 和 C（选择任何有意义的端口号）。我将其称为 DMZ 隧道应用程序。

编写另一个驻留在内部网络任何地方的服务。它将连接到端口 B 上的 DMZ 隧道应用程序。一旦建立此连接，DMZ 隧道应用程序不再需要侦听端口 B。这就是“控制连接”。

当有东西连接到 DMZ 隧道应用程序的端口 A 时，它会通过控制连接发送请求以获取新的 DB/任何连接。内部隧道应用程序将通过连接到内部资源来响应。建立此连接后，它将连接回端口 C 上的 DMZ 隧道应用程序。

在可能验证一些令牌之后（这部分由您决定），DMZ 隧道应用程序将在它在端口 A 和 C 上接收到的连接之间来回转发数据。您将有效地从两个服务创建一个透明 TCP 代理在 DMZ 和内部网络中运行。

而且，最重要的是，完成此操作后，您可以向 IT 部门解释您所做的事情并观察他们的表情，因为他们意识到您没有违反他们的安全政策，但您仍然保持高效。我告诉你，他们会讨厌这样的。

【讨论】：

是的，但是他们说我们不能这样做，它又回到了绘图板上，预算被破坏了。当某人拥有完全的否决权时，你不会狡猾。
那你可能想去找高层说“看，这个应用程序需要访问这个数据源......没有办法解决这个问题。我们可以整天和 IT 玩安全游戏，但是您是否希望这个项目完成？”
然后你去找你的主管并解释你所处的第 22 个问题。你被要求做一份工作，而 IT 阻止了你。把它留在别人的盘子里，弄清楚如何实现它……哎呀，你只是开发人员……你开发软件。
如果不是令人沮丧，那么 IT 就不会正确地完成他们的工作。 ;)
@cdhowie [尖刻评论已编辑]

【解决方案7】：

如果由于 DMZ 中的系统工程限制而无法应用所有开发解决方案，那么就交给他们吧。

将您的网站放在 Intranet 中，并告诉他们'现在我需要到该应用程序的入站 HTTP:80 或 HTTPS:443 连接。设置你想要的：反向代理、ISA Server、协议中断、SSL...如果需要，我会调整我的应用程序。'

关于 ISA，如果您与外部连接进行交换，我想他们得到了一个。

当需要在 Intranet 和公共之间共享资源时，许多公司都会选择此解决方案。

设置具有高度安全规则的特定 Intranet 网络是简化管理、集成和部署的最佳方式。更容易的事情是众所周知的，众所周知的是掌握：更少的安全漏洞。

越来越多的系统工程师（如矿工）更愿意维护一个像 HTTP 这样具有较小“安全漏洞”的 Intranet 网络，而不是开放其他协议和端口。

顺便说一句，如果他们知道 WCF 服务，他们就会接受这个解决方案。如果设计得当，这是最安全的解决方案。

个人而言，我使用这两种方法：TCP(HTTP or not) Services 和 ISA Server。

【讨论】：