SOA安全噩梦何时休？
时间：2009-04-21 05:38:34
手机看文章
扫描二维码
随时随地手机看文章
[导读]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设备/加速器的需求。政策驱动的安全需要用于更新、维护和审计安全政策的工具。这将把我们带到下一类问题...
审计、监视和强制执行政策
许多回答这个问题的人强调了对于所有的服务的端对端的监视和审计重要性。说把适当的安全措施建在这个架构中是一回事。证明这个事情是另一回事。
把安全建成一种服务的架构师需要从审计和管理规定的角度考虑这种需求。我们有SOX、HIPAA、PCI和许多其它的法规。有时候，这些法规是相互冲突的。例如，SOX要求我们存储有所有关金融交易的一切记录，而PCI法规要求我们不能用明文存储信用卡号码。而且我们同时还必须把信用卡号码信息传送给金融机构。要实现这个目的，企业的所有种类的加密和其它加密措施都要进行审计。要通过这些审计，我们必须记录每一个服务电话的正确的信息级别，向各种审计人员和管理部门提供一种方法，证明我们是遵守它们的规定的。一次糟糕的交易就会让审计失败。
一个大的挑战是外部服务用户以意想不到方式适应了某些服务。必须要有预见性地监视服务的消费以便识别出出人意料的不符合安全政策的用户，在灾难性结果出现之前迅速达成一个解决方案。最后，我们必须保证正确的数据在正确的时间交给正确的人。
我们能做什么？
有两件事情能够缓解这种风险。第一是提高认识。投资进行培训和培训每一个人，不仅仅使培训开发人员。管理层需要高水平的培训课程，而架构师、安全专家、审计师、开发人员、测试人员、商业分析师和其他人需要针对他们需求的培训。
第二，安全是每一个人的责任，不仅仅是企业架构师和安全架构师的责任。机构要全力保证企业的安全。业内人士建议企业雇用有经验的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设备/加速器的需求。政策驱动的安全需要用于更新、维护和审计安全政策的工具。这将把我们带到下一类问题...
审计、监视和强制执行政策
许多回答这个问题的人强调了对于所有的服务的端对端的监视和审计重要性。说把适当的安全措施建在这个架构中是一回事。证明这个事情是另一回事。
把安全建成一种服务的架构师需要从审计和管理规定的角度考虑这种需求。我们有SOX、HIPAA、PCI和许多其它的法规。有时候，这些法规是相互冲突的。例如，SOX要求我们存储有所有关金融交易的一切记录，而PCI法规要求我们不能用明文存储信用卡号码。而且我们同时还必须把信用卡号码信息传送给金融机构。要实现这个目的，企业的所有种类的加密和其它加密措施都要进行审计。要通过这些审计，我们必须记录每一个服务电话的正确的信息级别，向各种审计人员和管理部门提供一种方法，证明我们是遵守它们的规定的。一次糟糕的交易就会让审计失败。
一个大的挑战是外部服务用户以意想不到方式适应了某些服务。必须要有预见性地监视服务的消费以便识别出出人意料的不符合安全政策的用户，在灾难性结果出现之前迅速达成一个解决方案。最后，我们必须保证正确的数据在正确的时间交给正确的人。
我们能做什么？
有两件事情能够缓解这种风险。第一是提高认识。投资进行培训和培训每一个人，不仅仅使培训开发人员。管理层需要高水平的培训课程，而架构师、安全专家、审计师、开发人员、测试人员、商业分析师和其他人需要针对他们需求的培训。
第二，安全是每一个人的责任，不仅仅是企业架构师和安全架构师的责任。机构要全力保证企业的安全。业内人士建议企业雇用有经验的SOA安全人员或者雇用一个顾问把这个知识传授给机构内部的安全部门。
下载文档
