您企业的SOA架构是否安全

申请免费试用、咨询电话：400-8352-114

您企业的SOA架构是否安全1

面向服务架构(SOA,service-oriented architecture)为公司进行跨部门、跨系统以及跨企业整合创造了巨大的机遇，整合可以帮助公司简化业务流程、提高上市速度，共享数据和服务，并且能够让公司对商业变化更快地做出反应。

举例来说，正确的SOA架构可以将电子商务网站毫无痕迹地与该网站的供应商、分销商、信用卡公司以及消费者整合在一起，这样的话，当消费者发出订单时，系统就能够在无需请求用户或者系统的情况下将信息即时向各相关方面发布。

SOA同样还可以通过抽取某些业务流程、服务或者数据点来帮助公司重新恢复他们的遗留系统，而不需要丢弃或者取代那些系统。公司在建设新的系统时可以将新系统与旧系统进行无缝整合，那样就可以降低公司的投资成本。

对于终端用户来说，这的确是好消息。但是对于安全部门的工作人员来说，却是他们最大的噩梦。

公司整合的负面影响

虽然正如上文所述，一体化整合存在很多好处，但同时也会给安全、隐私以及合规带来巨大的安全风险，对于能够轻易与其他服务整合的服务(两者都在防火墙后面或者防火墙外部)，这两种服务必须是可以被发现的以及易于转换的。

为此，很多SOA部署都使用了Web服务，web服务使用的是WSDL(Web服务描述语言)，这种语言能够描述如何行使该服务。 UDDI(统一描述、发现和集成)是web服务中常用的一个标准，它能够允许服务被发现以及检索。

SOA中经常使用的另外两个重要标准就是XML和SOAP(简单对象访问协议)，XML是一种自我描述格式，它包含了信息的清晰的文本描述，而SOAP是用于交换基于XML信息的协议并且也能提供重要信息的清晰的描述。

然而，尽管这些标准能够帮助公司更加方便地进行服务整合，但是如果适当的安全措施没有到位，就必然让黑客有机可乘。

很多旧系统并没有设计为能够接触到其他系统，尤其是防火墙外的系统。现在有了SOA，就使黑客能够进入他们以前不能访问的系统和数据，这还得归功于SOA的发现以及自我描述特性。

公司内部面临的挑战

我采访过很多架构师、供应商、培训人员和安全专家，问过他们这样一个简单的问题: 在部署SOA的时候你认为存在的最大安全风险是什么?我将收到的答案归类为以下几部分:

· 对于公司内部巨大的安全风险缺乏意识或认识

· 在各服务间、各系统间以及企业间普及使用授权证书

· 监控、审计和执行政策的能力

缺乏安全风险意识或认识

软件构架师(EA)必须接受适当的培训来更好地理解SOA部署，从而鉴定安全风险级别。很多SOA部署是由软件构架师团队从技术的角度来驱动的。如果架构师们对于安全风险问题没有足够的意识，那么他们就不知道该如何部署安全措施来保护服务，同样他们也不会知道什么时候需要调动安全和审计专家。

安全部署应该建立在前期，而不是事后才考虑的问题。向每个服务部署安全措施会对每个服务的性能和可维护性造成一定的负担，安全措施应该作为核心服务来部署，这样安全措施就能进行集中管理和维护。此外，管理层必须明白存在的安全风险，并提供适当的支持和资金来有效地保障企业的安全。

普及使用授权证书

很多服务都是“无头的”，这就是说这些服务与用户界面没有关系。这些服务被其他服务启用并且启用其他服务，启用服务必须通过授权认证以便正给系统的流动从开始到技术都不被中断。使问题更具挑战性的是，一条简单的信息可能包含多个服务客户的XML数据。例如，我们继续使用电子商务网站的例子，客户的一条请求可以触发包含XML数据的信息，XML数据是有关供应商、分销商和信用卡公司的数据，而且每部分有不同的安全要求。只有信用卡公司能够访问信用卡信息 (应该加密为PCI兼容)，供应商需要知道那些产品被运出存活区，而分销商需要知道产品和送货地址等信息。

从这个例子中你会发现过去单纯使用SSL是远远不够的。在这个例子中，同样的讯息被发送给不同的三个公司而不需要他们各自登录。很多公司都采用的是WS-*标准(WS-安全, WS-信任, WS- 联合, WS-政策, 等等.)来解决存在的安全风险。

最佳解决方法包括XML加密，使用公钥和/或者令牌以及一个政策驱动办法来解决相对于硬编码的安全问题。

但是当我们执行这些最佳解决方法的时候事情会变得更加复杂，XML加密可能导致系统性能退化，这就带来对XML工具/加速器的需要。政策驱动安全增加了公司对更新、维护和审计安全政策工具的需要，这就将我们引入了下一部分的内容。