从DMZ到内部中间件的MSMQ通信 [英] MSMQ communications from DMZ into internal middleware

问题描述

我是一名IT人员，与一群需要将基于DMZ的n层应用程序与内部中间件系统(自制)集成的开发人员一起工作.

 

我的问题是，我们如何正确，安全地允许基于DMZ的MSMQ客户端向内部中间件系统发送消息?在理想情况下，内部中间件将打开到DMZ中的连接，就像从DMZ中打开连接一样.内部网通常被认为与最佳做法背道而驰.就是说，如果没有MSMQ客户端启动到内部中间件系统的连接，我们将看不到如何做到这一点，因此我们希望以最少暴露我们的方式来做到这一点.

 

我已经阅读了一些有关MSMQ强化模式的信息，并将其限制为端口80/443，甚至在两者之间使用代理.有人可以针对这种情况下的当前标准做法发表评论吗?我希望有一些提示/建议！

 

谢谢

解决方案

标准MSMQ仅需要端口1801进行通信，因此您无需打开大量端口(这是假设您使用的是私有队列，公共队列通常需要访问AD).

或者，您可以使用MSMQ/HTTPS并使用443，并且所有数据都将使用HTTPS加密，但是与使用超过1801的标准MSMQ相比，开销会更大.

I'm an IT guy working with a group of developers who need to integrate a DMZ-based n-tier app with an internal middleware system (home-brew). 

 

The question I have is how do we correctly and securely allow the DMZ-based MSMQ client send messages to the internal middleware system?  In a perfect world, the internal middleware would open the connection into the DMZ, as opening connections from DMZ -> internal net is generally considered contrary to best-practice.  That said, we don't see how we can do this without the MSMQ client initiating the connection into the internal middleware system, so we'd like to do this in the way that least exposes us.

 

I've read a bit about MSMQ hardened mode, and limiting it to port 80/443, and even using a proxy between the two.  Can someone please comment regarding what the current standard practice is in this type of scenario?  I'd love some tips/advice!

 

Thanks

解决方案

Standard MSMQ only required port 1801 for communications, so you don't need to open a large number of ports (this is assuming you're using private queues, public queues usually require access to AD).

Alternatively, you could use MSMQ/HTTPS and use 443 and all data will be encrypted with HTTPS but there will be more overhead than when using standard MSMQ over 1801.

这篇关于从DMZ到内部中间件的MSMQ通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！