SOA安全噩梦何时休？.docxVIP

PAGE 1 PAGE 1 SOA安全噩梦何时休？  SOA为那些要实施跨部门、跨系统和跨企业集成的公司创造了巨大的机会。集成能够帮助简化商业流程、提高产品上市的时间、使企业对业务、共享的数据和服务中的变化更快地做出反应。  SOA为那些要实施跨部门、跨系统和跨企业集成的公司创造了巨大的机会。  集成能够帮助简化商业流程、提高产品上市的时间、使企业对业务、共享的数据和服务中的变化更快地做出反应。例如，正确建立的SOA架构能够让一个电子商务网站与自己的供应商、分销商、信用卡公司和消费者无缝地集成在一起。在一个客户下订单之后，系统将自动编排大量的信息，不必要在每一次登录时都询问用户或者系统。  SOA还允许企业在不放弃和不更换老式系统的状况下通过抽象化某些商业流程、服务或者数据来重新焕发这些老系统的青春。企业能够利用它们对现有的老式系统的投资，同时建立无缝地与老系统集成在一起的新系统。  对于最终用户来说，这是涅槃。对于安全部门的人来说，这是他们最糟糕的噩梦。  集成的负面影响  上面提到的SOA的好处伴随着在安全、隐私和遵守法规方面的很大风险。对于那些轻松地把防火墙后面和防火墙外面的其它服务集成在一起的服务来说，它们必需是可发觉的和简单转变的。很多SOA实施使用Web服务。Web服务使用WSDL(Web服务说明语言)说明如何启用这个服务。UDDI(统一描述、发觉和集成)是一种标准，通常与Web服务一起使用，允许发觉和提取服务。SOA中常用的另外两个标准是XML(可扩展标记语言)和SOAP(简洁对象访问协议)。XML是一种自我说明格式，包含明文形式的信息，而SOAP是交换基于XML的信息的协议并且以明文供应重要的信息。虽然这些标准让企业更简单地集成服务，但是，假如没有适当的安全措施，它也会把这个王国的钥匙交给黑客。  很多老式的系统的构造从来都不是要暴露给外部的，特殊是不能暴露给防火墙外部的系统。现在，采用SOA之后，由于SOA的可发觉的和自我说明的性质，黑客能够访问他们以前无法接触的系统和数据。  企业中的挑战  业内人士向很多架构师、厂商、培训师和安全专家提出了一个简洁的问题：你认为在实施SOA的时候架构师需要解决的最大的安全风险是什么？这个问题的答案有如下几类：  机构中缺乏对这种风险的严重的熟悉和学问。  在服务、系统和企业之间传播证书。  监视、审计和强制执行政策的能力。  缺乏熟悉和学问  重要的是企业架构师要得到适当的培训，这样他们就能够很好地理解SOA以识别这种风险。很多SOA计划都是企业架构师小组从技术的观点推动的。假如架构师不熟识风险和其它问题，他们不仅不知道需要建立什么来这个服务的安全，而且他们还不知道在什么时候引进安全和审计专家。安全需要提前建立，不应当在事后建立。把安全建在每一个服务中对于每一项服务的性能和可维护性可能是一个负担。安全应当作为一套核心的服务实施，允许集中管理和维护安全。此外，管理层必需理解这个风险并且供应适当的支持和资金以便有效地保证企业的安全。  传播证书  很多服务是“无头的”，也就是说这些服务没有相关的用户接口。这些服务是通过启动其它服务并且由其它服务启动的，而且必需要把证书根据顺序从头到尾不间断传遍整个系统。更有挑战性的是一个信息可能包含为多个服务用户供应的XML数据。  以一个电子商务网站为例，一个订单能够引发一个包含供应给一个供应商、分销商和信用卡公司的XNL数据，每一方都有不同的安全要求。只有信用卡公司有权访问这个信用卡信息(信用卡信息应当根据PCI的要求加密)。供应商需要知道什么产品和在目录的什么地方。分销商需要知道有关产品和发货地址的信息。因此，你从这个例子可以看出，过去简洁地使用SSL的日子是不够的。在这个例子中，同样的信息要同时发给三个不同的公司并且不需要任何一家公司登录。很多公司采用WS-*标准(如Ws-Security、WS-Trust、WS-Federation、Ws-Policy等)来解决这些风险。  最佳做法包括XML加密，使用公共密钥和/或者令牌，政策驱动的安全方法，而不是采用硬编码。但是，在建立这些最佳做法的时候，事情会变得更加复杂。XML加密可以造成性能下降，从而产生XML设备/加速器的需求。政策驱动的安全需要用于更新、维护和审计安全政策的工具。这将把我们带到下一类问题...  审计、监视和强制执行政策  很多回答这个问题的人强调了对于全部的服务的端对端的监视和审计重要性。说把适当的安全措施建在这个架构中是一回事。证明这个事情是另一回事。  把安全建成一种服务的架构