中间件工具会引起巨大的漏洞，足以抵消所带来的好处。然而，通过一些简单的步骤你就可以保护自己和数据。
在过去，开发者利用操作性用工具和特性去开发应用，但大多数操作系统工具都聚焦在一个平台和本地资源上。随着应用开发成为网络化的组件集，从客户/服务器到分布式多组件工作流，逐步形成了新的一组工具用以帮助开发者形成一致的实践并促进开发本身，这些工具被称为中间件，提供了很好的价值，但因为他们充当网络服务和应用之间的协调，因此，这些中间件本身也会产生重大的安全问题。
为了处理好这一问题，开发者需要了解应用的三个主要的安全属性：建立应用生命周期管理(ALM)实践来实施中间件安全，优化网络安全作为第一道防御，逐步给特定中间件工具和界面增加安全。
用户同意，“安全”的应用有三个属性。首先，它通过用户鉴权和权限控制提供了访问控制。其次，它保护工作流中的信息免受拦截或浏览，最后，它确保事务的完整性及不可抵赖性。你可以通过宽泛或特定的安全举措支持每一项属性，所以确保中间件安全的最重要一步是探索可能的安全举措并让这些举措与风险协调。
在受到中间件支持的应用是敏感的地方，或者中间件位于敏感信息被处理或存放的平台上时，中间件的风险最大。在这些情况下，中间件可形成恶意软件的第二路径，通过它应用和数据也会受到连累。不要把敏感应用和更加开放的(Web)应用混杂在同一个平台上，这样就可以减少中间件的安全风险，也可以更容易成本更低地保证重要的东西的安全。
中间件安全始于ALM流程
一切中间件安全都必须从ALM流程内开始，其目标是确保中间件组件和应用组件在集成到中间件朋友或应用之前已得到完全验证。如果用于支持它的元素有可能受到恶意软件感染或通过非授权变更攻溃的话，任何安全机制都没有效。避免受恶意软件影响的第一步是建立部署实践，把中间件工具和安全举措吸收进共同的“安全中间件”元素中，然后只要这一元素有任何变化都要求ALM流程测试功能性和安全性。
网络安全是防御恶意软件的第一道防线。网络越开放，内容就越不安全，增加特殊安全机制来保护不受恶意软件攻击就越重要。显然，应用和平台的互联网访问制造了最开放和最具风险的网络框架。只要应用和平台运行在VPN之内并予以特殊的访问控制，网络本身的安全性就足以满足某些应用需求，从而可以简化其他的安全举措。
你可以建设针对应用的叠加网络，通过对数据和访问进行分区处理来增强网络安全。这些网络，通常基于加密隧道建设，可提供访问保护和侦听安全，甚至降低信息在组件之间“飞行时”被盗用的风险，从而确保不可抵赖性。然而，多应用网络也会导致员工访问信息的复杂化，因此有可能的话最实用的做法是将应用按照员工类型分组，提供“应用级访问”而不是协调按照应用的访问。
一旦网络安全已被开放至实用的地步，就到审视恶意软件自身的时候了。经验表明，大多数有漏洞的中间件工具都是那些与工作流/消息总线管理相关的。工作流/消息管理中间件安全的目标是防止非授权的消息引入或侦听。
利用Web服务框架提高安全
保证中间件安全的一个明显方式是实现更多的Web服务(WS)框架，尤其是在组件间的WS-Security，并特别保证与服务/消息总线的连接安全。这是在供应商中间件架构(比方说Microsoft的 .NET、IBM的 WebSphere, Oracle Fusion)内提高安全的最容易的方式，因为安全工具是集成在里面，且通过标准开发工具和实践就能获得的。
一般情况，基本的WS流程都存在限制，因为它们并不涉及工作如何在合法组件间进行分配的，这会导致工作导航(通常通过BPEL)可发送某个东西给不安全的目的地的风险。尽管这一机制很难被外界利用，但内部人士可用它来拦截接收者无权看到的事务或数据。为避免这一点，你需要保证BPEL的安全，可能也要增加策略管理工具来限制中间件对特别关键数据的路由。再次地，这个也是某个往往由上述架构化的中间件工具提供的东西。
大多数工作流中间件都是基于消息总线的，但是有些应用则可受益于更加动态的结构。我们往往会采用发布/订阅模式，但如果没有正确实现的话，这些工具尤其容易受到攻击。当使用此类 “发布”能力或接口的功能时，把它限制给那些策略上有权访问的人至关重要。通常而言，需要进行消息过滤以确保发布/订阅中间件的安全，除非是在安全网络的“内部”实现的。这通常在用户和资源连接的那层上应用于发布/订阅中间件的外部。
对于所有的中间件安全问题来说，一个好的起点是检查主流供应商结构化中间件包的安全特性。通过审视所有这些安全特性以及应用方式，，你可以确定安全问题是否需要特定的中间件解决方案，也能看出不同的中间件元素一般是如何获得安全保证的。甚至哪怕你并未采用某个供应商的方案，理解那个方案能提供什么也能引导你改进自己的中间件安全。
中间件会给企业带来巨大的漏洞，足以抵消自身所带来的好处。不要让这一情况发生，通过有组织的方式采取一些简单步骤就能保护你和你的数据。
