【IT专家网独家】面向服务架构(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工具/加速器的需要。政策驱动安全增加了公司对更新、维护和审计安全政策工具的需要，这就将我们引入了下一部分的内容。
审计、监控和执行政策
那些回答了我问题的人都强调了对所有服务实行端到端监控和审计的重要性，这是我们在讨论向架构中部署适当的安全措施时需要考虑的一个重要问题，我们可以通过另外一件事来证明这一点。
架构师在将安全措施作为一项服务来部署时，需要从审计和监管的角度来考虑需求问题。我们有SOX,HIPAA,PCI和很多其他规章制度，有时候这些规章会直接与另外的规章相冲突。
举例来说，SOX需要我们存储所有有关金融交易的信息，而PCI则指出我们不能存储信用卡号码，然而同时我们需要将信用卡信息通过金融指示。要想做到这一点，我们可以使用各种的加密法和其他安全措施来帮助公司实行审计，为了通过这些审计，我们必须根据每项服务的请求来记录信息的正确级别，以此来提供一种方法向不同的审计师和监管机构证明我们是在遵守他们的准则，仅仅一次坏的交易就可能使一次审计失败。
还存在的一个巨大挑战是，外部服务客户使用某些服务的方式是被认为不合适的。服务性消费必须加以主动监控来查明那些破坏安全政策的不恰当的服务使用事件，这样就能在发生灾难性后果之前快速的部署解决方案。在解决方案产生之前，我们必须确保我们在正确的时间向正确的客户发送了正确的数据。
我们能做什么?
我想到有两种方法可以帮助减轻这些安全风险。首先是提高认识。公司应该加大培训的力度来培训每一个人，而不只是对开发人员培训。管理层需要一个高层次的培训，而架构师、安全专家、审计师、开发人员、测试师、业务分析师、系统管理员、网络工程师和其他人则应该根据他们各自的需求进行培训。
第二点就是，安全是每一个人的责任，而不仅仅是软件架构师或者安全架构师的责任，整个公司应该承担起保护公司安全的责任。我强烈推荐公司可以雇佣一名有经验的SOA安全专家或者聘用一名安全顾问，在公司内部的安全部门传播安全知识。
此外，我强烈推荐Ramarao Kanneganti 和Prasad Chodavarapu合著的《Enterprise SOA》以及《SOA Security》这两本书。来自Progress Software的Dan Foody给我们带来了很多有关从安全角度SOA带来的挑战的生动有趣的例子，他采用造访白宫的比喻来解释SOA需要解决的不同级别的安全问题。
造访白宫的第一个安全级别是进入白宫，在这个安全级别中，会有一名警卫来检查你的身份，让你通过一个金属探测器并且使用X光来检查你的物品。进入白宫里面后，你会发现第二个安全级别：白宫里面每个门前面的保安人员。在你进入那些门时你需要提供其他必要信息，但是这里就不再会使用金属探测器和X光机器了，因为你已经经过检查了。在第三个安全级别中，你的向导会将你领入白宫内某个特定区域，在这个区域你不能随意的散步，并且你正在被你所看不见的眼睛所监视着。
这是一个很好的例子，让我们认识到保护SOA必要的安全级别，不幸的是，很多公司只是在大门口配备了几个保安人员。
IT专家网原创文章，未经许可，严禁转载！
