我正在开发一个外部网站（在 DMZ 中），该网站需要从我们的内部生产数据库中获取数据。
我提出的所有设计都被拒绝了，因为网络部门不允许任何类型的连接（WCF、Oracle 等）从 DMZ 进入内部。
来自网络方面的建议通常分为两类 -
1) 将所需数据导出到 DMZ 中的服务器，并最终以某种方式导出修改/插入的记录，或
2) 从内部轮询，不断询问 DMZ 中的服务是否有任何需要服务的请求。
我反对建议 1，因为我不喜欢数据库位于 DMZ 中的想法。对于正在做的事情的性质，选项 2 似乎是一个荒谬的额外复杂性。
这些是唯一合法的解决方案吗？我缺少一个明显的解决方案吗？“禁止从 DMZ 进入”法令是否实用？
编辑：我经常听到的一句话是“没有大公司允许网站连接内部以获取实时生产数据。这就是他们发送确认电子邮件的原因”。真的是这样吗？
很抱歉，您的网络部门正在破解或类似的事情 - 他们显然不明白 DMZ 的目的是什么。总而言之 - 有三个“区域” - 大而糟糕的外部世界，你纯洁和原始的内部世界，以及众所周知的、值得信赖的、安全的 DMZ。
规则是：
第四点是他们没有掌握的——“与非军事区没有联系”的政策是错误的。
问他们“那我们的电子邮件系统是如何工作的？” 我假设您有一个公司邮件服务器，也许是交换，并且个人有连接到它的客户端。请他们解释您的公司电子邮件（可以访问互联网电子邮件）如何运作并符合他们的政策。
对不起，它并没有真正给你答案。
我是一家财富 50 强金融公司的安全架构师。我们进行了同样的对话。我不同意你的网络组。我理解他们的焦虑，并且我理解他们想要一个更好的解决方案，但大多数地方并没有选择更好的选择（由于他们的无知 [即网络人而不是你]）。
如果他们对此很难设置，则有两个选择：您可以使用像 greensql 这样的 SQL 代理解决方案（我不为他们工作，只知道他们）它们只是 greensql dot com。
他们提到的大多数“大型组织”使用的方法是分层网络模型。您有一个前端 Web 服务器（由广大公众访问）、一个中间层（实际流程发生的应用程序或服务层）和一个数据库层。中间层是唯一可以与数据库层对话的东西。在我看来，这个模型对于大多数大型组织来说是最佳的。但是话虽如此，大多数大型组织将遇到供应商提供的不支持中间层的产品，他们在没有中间层的情况下开发，并且过渡需要他们不必为开发中间层 Web 服务而腾出的开发资源，或者说，某些公司完全没有优先选择这条路线。
它是一个灰色地带，在这方面没有绝对的对与错，所以如果他们说的是确定性的话，那么他们显然是错误的。我为他们的热情喝彩，作为一名安全专业人士，我了解他们来自哪里。但是，我们必须使业务能够安全运行。这就是我一直试图扔给自己的挑战和挑战。我如何才能提供我的客户（我的开发人员、我的管理员、我的 dbas、业务用户）他们想要的东西（在合理的范围内，如果我告诉某人不，我总是试图提供满足他们大部分需求的替代方案）。
老实说，这应该是一个开放的对话。我认为您可以在这里获得一些空间，让他们对他们希望减轻的风险进行威胁建模。要求他们提供使您的 Web 应用程序正常运行的替代解决方案。如果他们说他们不能说话，那么让他们有责任提供解决方案。如果他们不能，那么你默认它工作。您仅为已批准的端口打开从 dmz 到 db 的连接的站点。让他们知道 DMZ 是为了提供外部服务。除了潜在的文件传输解决方案之外，如果没有内部数据，外部服务就不好。
只是我的两分钱，希望这个评论有帮助。并尽量对我的安全兄弟轻松。在我们的羊群中，我们有一些经验较少的被误导的人，他们坚持一些旧的做事方式。随着世界的演变，威胁也在演变，我们的缓解方法也在演变。
在这方面，我主要与肯·雷（Ken Ray）在一起；但是，似乎缺少一些信息。让我们看看我是否做对了：
如果我走上正轨，那么我不得不说我同意你的 IT 部门，我也不会让你直接访问该服务器。
只需选择选项 1。让生产服务器将您需要的数据导出到通常可访问的放置位置。让另一台数据库服务器（DMZ 中的一个）获取数据并定期导入。最后，让您的 Web 应用程序仅与 dmz 中的数据库服务器通信。
考虑到现在有很多人建立网站，我也不愿意只打开一个从 dmz 到相关 Web 服务器的 sql 端口。坦率地说，如果我确信 1. 你只使用存储过程来访问你需要的数据，我可以说服我打开连接；2. 用于访问数据库的帐户信息被加密，完全限制只能运行那些procs；3. 那些 procs 的动态 sql 为零并且仅限于选择；4. 你的代码是正确的。
一个普通的 IT 人员可能没有资格回答所有这些问题。如果这个数据库来自第三方，我敢打赌，如果你从它的正常应用程序之外开始访问它，你可能会失去支持。
为什么不复制数据库服务器？您可以确保连接是从内部服务器到外部服务器，而不是其他方式。
一种方法是使用 ms 同步框架 - 您可以构建一个简单的 Windows 服务，该服务可以将更改从内部数据库同步到外部数据库（可以驻留在单独的数据库服务器上），然后在面向公众的网站中使用它。优点是，您的同步逻辑可以过滤掉敏感数据，只保留真正需要的东西。而且由于数据的全部控制权将在您的内部服务器中（推送数据而不是拉取数据），我认为 IT 不会对此有任何问题。
形成的连接永远不会进入 - 它已经退出 - 这意味着不需要打开任何端口。
在谈论您的特定问题之前，我想处理您提供的更新。
我没有为“大”公司工作过——尽管没有上下文很难判断大公司，但我已经为我曾经工作过的非营利组织和大学部门建立了自己的网络应用程序份额。在这两种情况下，我总是从 DMZ 上的 Web 服务器连接到内部网络上的生产数据库。我很确定许多大公司也这样做。例如，想想 Sharepoint 的架构是如何设置的 - 后端索引、数据库等服务器，这些服务器由位于 DMZ 中的前端 Web 服务器连接。
此外，发送确认电子邮件的做法（我相信您在注册网站时指的是确认）通常不涉及安全性。它们更像是一种验证用户是否输入了有效电子邮件地址的方法。
现在，让我们看看你的问题。不幸的是，除了您提出的两种解决方案之外，我想不出任何其他方法来做到这一点。尽管您可能需要考虑一些事情：
解决方案1：
根据您需要处理的数据的敏感性，将其提取到 DMZ 上的服务器上——无论是使用服务还是某种自动同步软件——都违反了基本的安全常识。您所做的是将数据从防火墙后面的服务器移动到防火墙前面的服务器。他们还不如让您从 DMZ 访问内部数据库服务器。
解决方案2：
我不是网络专家，所以如果我错了，请纠正我，但是轮询机制仍然需要从 Web 服务器返回某种通信，以通知数据库服务器它需要返回一些数据，这意味着需要打开一个端口，您不妨再次告诉他们让您轻松访问内部数据库，因为您并没有真正使用此方法添加任何额外的安全性。
因此，我希望这至少有助于为您提供一些参数，以允许您直接访问数据。在我看来，您的网络部门似乎对安全的数据库支持的 Web 应用程序架构应该是什么样子存在许多误解。
这是你可以做的......这有点牵强，但它应该工作......
编写一个位于 DMZ 中的服务器上的服务。它将侦听三个端口 A、B 和 C（选择任何有意义的端口号）。我将其称为 DMZ 隧道应用程序。
编写位于内部网络任何位置的另一个服务。它将连接到端口 B 上的 DMZ 隧道应用程序。一旦建立此连接，DMZ 隧道应用程序不再需要侦听端口 B。这就是“控制连接”。
当有东西连接到 DMZ 隧道应用程序的端口 A 时，它将通过控制连接发送请求以获取新的 DB/任何连接。内部隧道应用程序将通过连接到内部资源来响应。建立此连接后，它将连接回端口 C 上的 DMZ 隧道应用程序。
在可能验证了一些令牌（这部分由您决定）之后，DMZ 隧道应用程序将在它在端口 A 和 C 上接收的连接之间来回转发数据。您将有效地拥有一个透明的 TCP 代理，该代理由运行在DMZ 和内部网络。
而且，最好的情况是，一旦完成，您可以向 IT 部门解释您所做的事情，并观察他们的表情，因为他们意识到您没有违反他们的安全政策，但您仍然保持高效。我告诉你，他们会讨厌那个。
如果由于 DMZ 中的系统工程限制而无法应用所有开发解决方案，那么就交给他们吧。
将您的网站放在 Intranet 中，并告诉他们“现在我需要到该应用程序的入站 HTTP:80 或 HTTPS:443 连接。设置您想要的：反向代理、ISA 服务器、协议中断、SSL ......如有必要，我将调整我的应用程序。'
关于 ISA，我想如果您与外部连接进行交换，他们会得到一个。
当需要在 Intranet 和公共之间共享资源时，许多公司都选择此解决方案。
建立具有高安全规则的特定 Intranet 网络是简化管理、集成和部署的最佳方式。更容易的是众所周知的，众所周知的是掌握：更少的安全漏洞。
越来越多的系统工程师（如矿工）更喜欢维护一个像 HTTP 这样具有较小“安全漏洞”的 Intranet 网络，而不是开放其他协议和端口。
顺便说一句，如果他们知道 WCF 服务，他们就会接受这个解决方案。如果设计得当，这是最安全的解决方案。
个人而言，我使用这两种方法：TCP（HTTP 或非）服务和 ISA 服务器。