中继WCF服务
这更多的是一个架构和安全问题。我正在尝试确定是否需要建议的架构。让我解释一下我的配置。
我们建立了一个标准的 DMZ，它本质上有两个防火墙。一个面向外部，另一个连接到内部 LAN。下面描述了每个应用程序层当前运行的位置。
防火墙之外：
Silverlight 应用程序
在 DMZ 中：
WCF 服务（业务逻辑和数据访问层）
在 LAN 内：
数据库
我收到的输入表明架构不正确。具体来说，有人建议，由于“Web 服务器很容易被黑客攻击”，因此我们应该在 DMZ 内放置一个中继服务器，该服务器与 LAN 内的另一个 WCF 服务进行通信，然后该服务将与数据库进行通信。外部防火墙当前配置为仅允许端口 443 (https) 访问 WCF 服务。内部防火墙配置为允许来自 DMZ 中的 WCF 服务的 SQL 连接。
忽略明显的性能影响，我也看不到安全方面的好处。我将保留对此建议的判断，以避免我的偏见污染答案。任何意见都会受到赞赏。
谢谢，
马特
This is more of an architectural and security question than anything else. I'm trying to determine if a suggested architecture is necessary. Let me explain my configuration.
We have a standard DMZ established that essentially has two firewalls. One that's external facing and the other that connects to the internal LAN. The following describes where each application tier is currently running.
Outside the firewall:
Silverlight Application
In the DMZ:
WCF Service (Business Logic & Data Access Layer)
Inside the LAN:
Database
I'm receiving input that the architecture is not correct. Specifically, it has been suggested that because "a web server is easily hacked" that we should place a relay server inside the DMZ that communicates with another WCF service inside the LAN which will then communicate with the database. The external firewall is currently configured to only allow port 443 (https) to the WCF service. The internal firewall is configured to allow SQL connections from the WCF service in the DMZ.
Ignoring the obvious performance implications, I don't see the security benefit either. I'm going to reserve my judgement of this suggestion to avoid polluting the answers with my bias. Any input is appreciated.
Thanks,
Matt
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我确实认为这些言论是有效的，在这种情况下，我可能也会尝试使用尽可能多的“纵深防御”层。
另外，如果您使用 .NET 4（或可以迁移到它），实现这一目标的工作量可能比您担心的要少。
您可以使用新的 .NET 4 / WCF 4 路由服务来轻松完成此操作。另一个好处是：您可以向外界公开 HTTPS 端点，但在内部，您可以使用 netTcpBinding（速度要快得多）来处理内部通信。
了解设置 .NET 4 路由服务有多么容易：
I do think the remarks made are valid, and in such a case I would probably also try and use as many "defense-in-depth" layers I could possibly come up with.
Plus, the amount of work to achieve this might be less than you're afraid of - if you're on .NET 4 (or can move to it).
You could use the new .NET 4 / WCF 4 routing service to do this quite easily. As an added benefit: you could expose a HTTPS endpoint to the outside world, but on the inside, you could use netTcpBinding (which is a lot faster) to handle internal communications.
Check out how easy it is to set up a .NET 4 routing service: