从 DMZ 中的 Web 服务器访问内部生产数据库中的数据
我正在开发一个外部网站（在 DMZ 中），该网站需要从我们的内部生产数据库获取数据。
我提出的所有设计都被拒绝，因为网络部门不允许任何类型的连接（WCF、Oracle 等）从 DMZ 进入内部。
来自网络方面的建议通常分为两类 -
1) 将所需数据导出到 DMZ 中的服务器，并最终以某种方式导出修改/插入的记录，或
2) 从内部轮询，不断询问 DMZ 中的服务是否有任何需要服务的请求。
我反对建议 1，因为我不喜欢数据库位于 DMZ 中的想法。对于正在做的事情的性质来说，选项 2 似乎是一个荒谬的额外复杂性。
这些是唯一合法的解决方案吗？我缺少明显的解决方案吗？ “禁止来自 DMZ 的连接”法令是否实用？
编辑：我经常听到的一句话是“没有一家大公司允许网站连接内部以获取实时生产数据。这就是他们发送确认电子邮件的原因”。真的是这样吗？
I'm working on an external web site (in DMZ) that needs to get data from our internal production database.
All of the designs that I have come up with are rejected because the network department will not allow a connection of any sort (WCF, Oracle, etc.) to come inside from the DMZ.
The suggestions that have come from the networking side generally fall under two categories -
1) Export the required data to a server in the DMZ and export modified/inserted records eventually somehow, or
2) Poll from inside, continually asking a service in the DMZ whether it has any requests that need serviced.
I'm averse to suggestion 1 because I don't like the idea of a database sitting in the DMZ. Option 2 seems like a ridiculous amount of extra complication for the nature of what's being done.
Are these the only legitimate solutions? Is there an obvious solution I'm missing? Is the "No connections in from DMZ" decree practical?
Edit: One line I'm constantly hearing is that "no large company allows a web site to connect inside to get live production data. That's why they send confirmation emails". Is that really how it works?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
抱歉，您的网络部门遇到了问题或类似的问题 - 他们显然不明白 DMZ 的目的是什么。总而言之，共有三个“区域”：广阔而恶劣的外部世界，纯净处女的内心世界，以及众所周知的、值得信赖的、安全的DMZ。
规则是：
第四点是他们没有掌握的一点——“不与非军事区建立联系”的政策是错误的。
问他们“那么我们的电子邮件系统是如何工作的？”我假设您有一个公司邮件服务器（也许是交换服务器），并且个人有连接到它的客户端。请他们解释您的公司电子邮件（可以访问互联网电子邮件）的工作方式以及如何遵守他们的政策。
抱歉，它并没有真正给你答案。
I'm sorry, but your networking department are on crack or something like that - they clearly do not understand what the purpose of a DMZ is. To summarize - there are three "areas" - the big, bad outside world, your pure and virginal inside world, and the well known, trusted, safe DMZ.
The rules are:
Point four is the one they haven't grasped - the "no connections from the DMZ" policy is misguided.
Ask them "How does our email system work then?" I assume you have a corporate mail server, maybe exchange, and individuals have clients that connect to it. Ask them to explain how your corporate email, with access to internet email, works and is compliant with their policy.
Sorry, it doesn't really give you an answer.
我是一家财富 50 强金融公司的安全架构师。我们进行了同样的对话。我不同意你的网络小组的观点。我理解他们的焦虑，我理解他们想要更好的解决方案，但大多数地方不会选择更好的选择（由于他们的无知[即网络人员而不是你]）。
如果他们对此有困难的话，有两个选择：
您可以使用像 greensql 这样的 SQL 代理解决方案（我不为他们工作，只是了解他们），它们只是 greensql dot com。
他们提到的大多数“大型组织”使用的方法是分层网络模型。其中有一个前端 Web 服务器（可供公众访问）、一个中间层（发生实际流程的应用程序或服务层）和一个数据库层。中间层是唯一可以与数据库层通信的层。在我看来，这种模式对于大多数大型组织来说都是最佳的。但话虽这么说，大多数大型组织都会遇到供应商提供的产品不支持中间层的情况，他们在没有中间层的情况下进行开发，并且过渡需要他们不必腾出的开发资源来开发中间层 Web 服务，或者直接说，有些公司没有优先考虑走这条路。
这是一个灰色地带，在这方面没有明确的正确或错误，所以如果他们用最终的术语说话，那么他们显然是错误的。我对他们的热情表示赞赏，作为一名安全专业人士，我理解他们的出发点。但是，我们必须确保业务能够安全运行。这就是我总是试图向自己提出的挑战和挑战。我如何才能交付我的客户（我的开发人员、我的管理员、我的数据库管理员、业务用户）他们想要的东西（在合理的范围内，如果我告诉某人不，我总是尝试提供满足他们大部分需求的替代方案）。
老实说，这应该是一次公开的对话。我认为你可以在这里获得一些空间，要求他们对他们希望减轻的风险进行威胁建模。要求他们提供替代解决方案，使您的网络应用程序能够正常运行。如果他们说他们不能说话，那么就让他们有责任提供解决方案。如果他们不能，那么你默认它可以工作。您仅针对批准的端口打开从 dmz 到数据库的连接的站点。让他们知道DMZ是对外提供服务的。除了潜在的文件传输解决方案之外，如果没有内部数据，外部服务就不好。
只是我的两分钱，希望这个评论有所帮助。并尽量对我的安全兄弟们宽容一些。我们的羊群中有一些经验不足的人被误导，他们坚持一些旧的做事方式。随着世界的发展，威胁也在不断变化，我们的缓解方法也在不断变化。
I am a security architect at a fortune 50 financial firm. We had these same conversations. I don't agree with your network group. I understand their angst, and I understand that they would like a better solution but most places don't opt with the better choices (due to ignorance on their part [ie the network guys not you]).
Two options if they are hard set on this:
You can use a SQL proxy solution like greensql (I don't work for them, just know of them) they are just greensql dot com.
The approach they refer to that most "Large orgs" use is a tiered web model. Where you have a front end web server (accessed by the public at large), a mid-tier (application or services layer where the actual processes occurs), and a database tier. The mid-tier is the only thing that can talk to the database tier. In my opinion this model is optimal for most large orgs. BUT that being said, most large orgs will run into either a vendor provided product that does not support a middle tier, they developed without a middle tier and the transition requires development resources they dont have to spare to develop the mid-tier web services, or plain outright there is no priorty at some companies to go that route.
Its a gray area, no solid right or wrong in that regard, so if they are speaking in finality terms then they are clearly wrong. I applaud their zeal, as a security professional I understand where they are coming from. BUT, we have to enable to business to function securely. Thats the challange and the gauntlet I always try and throw down to myself. how can I deliver what my customer (my developers, my admins, my dbas, business users) what they want (within reason, and if I tell someone no I always try to offer an alternative that meets most of their needs).
Honestly it should be an open conversation. Here's where I think you can get some room, ask them to threat model the risk they are looking to mitigate. Ask them to offer alternative solutions that enable your web apps to function. If they are saying they cant talk, then put the onus on them to provide a solution. If they can't then you default to it working. Site that you open connections from the dmz to the db ONLY for the approved ports. Let them know that DMZ is for offering external services. External services are not good without internal data for anything more than potentially file transfer solutions.
Just my two cents, hope this comment helps. And try to be easy on my security brethren. We have some less experienced misguided in our flock that cling to some old ways of doing things. As the world evolves the threat evolves and so does our approach to mitigation.
为什么不复制数据库服务器？您可以确保连接是从内部服务器到外部服务器，而不是相反。
一种方法是使用 ms 同步框架 - 您可以构建一个简单的 Windows 服务，该服务可以将内部数据库的更改同步到外部数据库（可以驻留在单独的数据库服务器上），然后在面向公众的网站中使用它。优点是，您的同步逻辑可以过滤掉敏感数据并仅保留真正必要的数据。由于数据的全部控制将在您的内部服务器中（将数据推出而不是拉取），我认为 IT 不会对此有问题。
形成的连接永远不会进入 - 它会退出 - 这意味着不需要打开任何端口。
Why don't you replicate your database servers? You can ensure that the connection is from the internal servers to the external servers and not the other way.
One way is to use the ms sync framework - you can build a simple windows service that can synchronize changes from internal database to your external database (which can reside on a separate db server) and then use that in your public facing website. Advantage is, your sync logic can filter out sensitive data and keep only things that are really necessary. And since the entire control of data will be in your internal servers (PUSH data out instead of pull) I dont think IT will have an issue with that.
The connection formed is never in - it is out - which means no ports need to be opened.
在这一点上我主要支持肯·雷（Ken Ray）；然而，似乎缺少一些信息。让我们看看我是否理解正确：
如果我步入正轨，那么我不得不说我同意您的 IT 部门的意见，并且我也不会让您直接访问该服务器。
只需采用选项 1。让生产服务器将您需要的数据导出到通常可访问的放置位置。让另一台数据库服务器（DMZ 中的一个）获取数据并定期导入。最后，让您的 Web 应用程序仅与 dmz 中的数据库服务器通信。
考虑到现在很多人构建网站的方式，我也不愿意只打开从 dmz 到相关 Web 服务器的 sql 端口。坦率地说，如果我确信 1. 您只使用存储过程来访问您需要的数据； 2. 用于访问数据库的帐户信息已加密，并且完全仅限于运行这些进程； 3. 这些过程的动态 sql 为零，并且仅限于选择； 4.你的代码构建正确。
普通 IT 人员可能没有资格回答所有这些问题。如果这个数据库来自第三方，我敢打赌，如果您开始从正常应用程序的外部访问它，您可能会失去支持。
I'm mostly with Ken Ray on this; however, there appears to be some missing information. Let's see if I get this right:
If I'm on track, then I would have to say that I agree with your IT department and I wouldn't let you directly access that server either.
Just take option 1. Have the production server export the data you need to a commonly accessible drop location. Have the other db server (one in the DMZ) pick up the data and import it on a regular basis. Finally, have your web app ONLY talk to the db server in the dmz.
Given how a lot of people build sites these days I would also be loath to just open a sql port from the dmz to the web server in question. Quite frankly I could be convinced to open the connection if I was assured that 1. you only used stored procs to access the data you need; 2. the account information used to access the database was encrypted and completely restricted to only running those procs; 3. those procs had zero dynamic sql and were limited to selects; 4. your code was built right.
A regular IT person would probably not be qualified to answer all of those questions. And if this database was from a third party, I would bet you might loose support if you were to start accessing it from outside it's normal application.
在谈论您的特定问题之前，我想处理您提供的更新。
我没有在“大”公司工作过 - 虽然在没有上下文的情况下很难判断大公司，但我已经为我曾经工作过的非营利组织和大学部门构建了自己的 Web 应用程序。在这两种情况下，我始终从 DMZ 上的 Web 服务器连接到内部网络上的生产数据库。我确信许多大公司也这样做；例如，想一下 Sharepoint 的架构是如何设置的 - 后端索引、数据库等服务器，这些服务器通过位于 DMZ 中的前端 Web 服务器连接。
另外，发送确认电子邮件的做法（我相信您指的是注册网站时的确认）通常不会涉及安全性。它们更多的是一种验证用户是否输入了有效电子邮件地址的方法。
现在，让我们看看您的问题。不幸的是，除了您提出的两种解决方案之外，我想不出任何其他方法来做到这一点。尽管您可能需要考虑一些事情：
解决方案 1：
根据您需要使用的数据的敏感性，将其提取到 DMZ 上的服务器上 - 无论是使用服务还是某种自动同步软件 - 都可以违反基本安全常识。您所做的是将数据从防火墙后面的服务器移动到防火墙前面的服务器。他们也可能只是让您从 DMZ 访问内部数据库服务器。
解决方案 2：
我不是网络专家，所以如果我错了，请纠正我，但是轮询机制仍然需要从 Web 服务器返回某种通信，以通知数据库服务器它需要返回一些数据，这意味着端口需要开放，您也可以再次告诉他们让您轻松访问内部数据库，因为您尚未使用此方法真正添加任何额外的安全性。
因此，我希望这至少有助于为您提供一些参数，以便您可以直接访问数据。在我看来，您的网络部门对于安全数据库支持的 Web 应用程序架构应该是什么样子存在许多误解。
Before talking about your particular problem I want to deal with the Update that you provided.
I haven't worked for a "large" company - though large is hard to judge without a context, but I have built my share of web applications for the non profit and university department that I used to work for. In both situations I have always connected to the production DB that is on the internal Network from the Web server on the DMZ. I am pretty sure many large companies do this too; think for example of how Sharepoint's architecture is setup - back-end indexing, database, etc. servers, which are connected to by front facing web servers located in the DMZ.
Also the practice of sending confirmation e-mails, which I believe you are referring to confirmations when you register for a site don't usually deal with security. They are more a method to verify that a user has entered a valid e-mail address.
Now with that out of the way, let us look at your problem. Unfortunately, other than the two solutions you presented, I can't think of any other way to do this. Though some things that you might want to think about:
Solutions 1:
Depending on the sensitivity of the data that you need to work with, extracting it onto a server on the DMZ - whether using a service or some sort of automatic synchronization software - goes against basic security common sense. What you have done is move the data from a server behind a firewall to one that is in front of it. They might as well just let you get to the internal db server from the DMZ.
Solution 2:
I am no networking expert, so please correct me if I am wrong, but a polling mechanism still requires some sort of communication back from the web server to inform the database server that it needs some data back, which means a port needs to be open, and again you might as well tell them to let you get to the internal database without the hassle, because you haven't really added any additional security with this method.
So, I hope that this helps in at least providing you with some arguments to allow you to access the data directly. To me it seems like there are many misconceptions in your network department over how a secure database backed web application architecture should look like.
这是您可以做的...这有点牵强，但它应该可以工作...
编写一个位于 DMZ 中服务器上的服务。它将监听三个端口：A、B 和 C（选择任何有意义的端口号）。我将其称为 DMZ 隧道应用程序。
编写另一个位于内部网络上任何位置的服务。它将连接到端口 B 上的 DMZ 隧道应用程序。建立此连接后，DMZ 隧道应用程序不再需要侦听端口 B。这是“控制连接”。
当某些东西连接到 DMZ 隧道应用程序的端口 A 时，它将通过控制连接发送请求以获取新的数据库/任何连接。内部隧道应用程序将通过连接到内部资源进行响应。建立此连接后，它将连接回端口 C 上的 DMZ 隧道应用程序。
在可能验证一些令牌（这部分由您决定）后，DMZ 隧道应用程序将在端口 C 上收到的连接之间来回转发数据A 和 C。您将有效地拥有一个由在 DMZ 和内部网络上运行的两个服务创建的透明 TCP 代理。
而且，最重要的是，完成此操作后，您可以向 IT 部门解释您做了什么，并观察他们的表情，因为他们意识到您没有违反他们的安全策略，但您仍然高效。我告诉你，他们会讨厌这样的。
Here's what you could do... it's a bit of a stretch, but it should work...
Write a service that sits on the server in the DMZ. It will listen on three ports, A, B, and C (pick whatever port numbers make sense). I'll call this the DMZ tunnel app.
Write another service that lives anywhere on the internal network. It will connect to the DMZ tunnel app on port B. Once this connection is established, the DMZ tunnel app no longer needs to listen on port B. This is the "control connection".
When something connects to port A of the DMZ tunnel app, it will send a request over the control connection for a new DB/whatever connection. The internal tunnel app will respond by connecting to the internal resource. Once this connection is established, it will connect back to the DMZ tunnel app on port C.
After possibly verifying some tokens (this part is up to you) the DMZ tunnel app will then forward data back and forth between the connections it received on port A and C. You will effectively have a transparent TCP proxy created from two services running in the DMZ and on the internal network.
And, for the best part, once this is done you can explain what you did to your IT department and watch their faces as they realize that you did not violate the letter of their security policy, but you are still being productive. I tell you, they will hate that.
如果由于 DMZ 中的系统工程限制而无法应用所有开发解决方案，那么就交给他们吧。
将您的网站放入 Intranet，并告诉他们“现在我需要到该应用程序的入站 HTTP:80 或 HTTPS:443 连接”。设置你想要的：反向代理、ISA 服务器、协议中断、SSL...我会的如有必要，请调整我的应用程序。'
关于 ISA，我想如果您与外部连接进行交换，他们就会得到一个。
当需要在内网和公共之间共享资源时，许多公司都会选择此解决方案。
设置具有高安全规则的特定内联网是使管理、集成和部署变得更容易的最佳方法。众所周知，更容易的事情是众所周知的，已知的事情是掌握的：更少的安全漏洞。
越来越多的系统工程师（如矿井工程师）更喜欢维护一个具有小型“安全漏洞”（如 HTTP）的内联网，而不是开放其他协议和端口。
顺便说一句，如果他们了解 WCF 服务，他们就会接受这个解决方案。如果设计良好，这是最安全的解决方案。
就我个人而言，我使用这两种方法：TCP（或非HTTP）服务和ISA服务器。
If all development solutions cannot be applied because of system engineering restriction in DMZ then give them the ball.
Put your website in intranet, and tell them 'Now I need inbound HTTP:80 or HTTPS:443 connections to that applications. Set up what you want : reverse proxies, ISA Server, protocols break, SSL... I will adapt my application if necessary.'
About ISA, I guess they got one if you have exchange with external connections.
Lot of companies are choosing this solution when a resource need to be shared between intranet and public.
Setting up a specific and intranet network with high security rules is the best way to make the administration, integration and deployment easier. What is easier is well known, what is known is masterized : less security breach.
More and more system enginers (like mines) prefer to maintain an intranet network with small 'security breach' like HTTP than to open other protocols and ports.
By the way, if they knew WCF services, they would have accepted this solution. This is the most secure solution if well designed.
Personnaly, I use this two methods : TCP(HTTP or not) Services and ISA Server.