SOA项目中十步搞定大型SOA应用程序的安全
SOA项目中十步搞定大型SOA应用程序的安全十步搞定大型SOA应用程序的安全
第 1 步 选择正确的团队
将大型关键基础设施应用程序迁移到 SOA 的工作令人望而生畏。对其进行保护甚至更为困难，经常需要采用全新的视角对其加以认识--甚至可能需要一组全新的安全人员进行相关工作。大部分安全团队在 SOA 方面甚至编程方面的培训极少。安全权威机构常用的方法是，只管发出要求并希望组织能够加以遵循。因此，第 1 步（这经常是最难的部分）是确保拥有正确的团队。
团队应该有个负责人，该负责人应该具有安全性和软件体系结构方面的知识，最好也能了解 SOA 的相关知识。与企业架构师类似，安全企业架构师（Security Enterprise Architect，SEA）将负责创建总体 SOA 安全模型，以便在每个粒度级别集成所有不同的安全性需求。SEA 将进入 SOA 治理委员会，与企业架构师（Enterprise Architect，EA）一起确保所有 SOA 实现都符合安全性需求的相关要求，并对负责创建整个流程中所需的构件的安全业务分析人员（Security Business Analyst，SBA）和安全系统工程师（Security Systems Engineers，SSE）团队进行指导。SEA 还将负责与编写安全性服务代码的程序员及在部署系统前对其进行测试的安全性系统测试人员合作。
第 2 步 创建详细项目计划
对于大型 SOA 系统，第 2 步要求高层管理了解，将无法通过改进新的 SOA 将其纳入旧安全模型中：这样做根本行不通。如果从最开始的重点就是传统安全机制（如防火墙、入侵检测系统和安全监视），这将完全与 SOA 安全实现不沾边。您将负责通过制定详细的项目计划和预算，清楚地说明和反映 SOA 安全实现所必需的东西，确保每个人都对此心里有底。
您必需让大家认识到，到 SOA 模型的任何转换都会涉及到固有的安全矛盾：系统的 SOA 特征越明显，其安全性越差。通过面向服务的建模和分析技术将当前系统转换为 SOA 的过程要求形成业务设计的相关文档。通过使用可将业务设计与信息系统相关的正式语言，通常仅能说明矛盾、低效而复杂的非 SOA 系统的情况。不过，这个复杂性会掩盖住大部分问题所在，从而使寻找机会破坏企业系统的人难于找到这些脆弱的环节。对这些系统进行分解并启用 SOA 后，恶意用户所面对的体系结构就会简单一些，从而更便于进行破坏。
SOA 支持者可能对此会加以否认，但负责保护系统安全的人知道，具有集中控制点且启用了 Web 的开放系统本身安全性就较差，而需要更为反应灵敏而灵活便利的方法。没有办法绕开这个问题，项目规划人员（经常会向 SOA 安全性方面分配一组适当的任务）必须记住，SOA 安全性需要详细的项目规划和预算，为安全性团队分配必要的时间，以便分析和了解 SOA 实现所带来的新挑战。
第 3 步 维护 SOA 支持安全决策表
通过创建 SOA 支持安全决策表正式记录抽象 SOA 安全性动态因素。在此表中，业务参与者将应用程序分为三类，包括：
"将启用 SOA 支持的应用程序
"必须与启用 SOA 支持的应用程序交互的应用程序
"将不启用 SOA 支持，也不必与启用 SOA 支持的应用程序交互的应用程序
也可以对这些不同的类别进行颜色编码。例如，我将第一个类别中的项目设置为红色，第二个类别中的项目设置为橙色，而将第三个类别的项目设置为黄色。
安全团队然后将进一步把应用程序划分到各个安全性类别，如高、中和低。例如，处理市场和分类信息的应用程序或服务将属于高安全性类别，而仅仅访问公开数据的应用程序或服务可以归入最低安全性类别。
表 1 显示了 SOA 支持安全决策表的示例。
表 1. SOA 支持安全决策表
安全性（高） 安全性（中） 安全性（低）
红色 36 12 11
橙色 12 5 3
黄色 6 0 6
在表中可以看到 12 个应用程序将不启用 SOA 支持（标为黄色的应用程序）；因此，此工作将需要异类安全模型，即一个为以 SOA 为中心的系统部分提供安全性，另一个为非 SOA 区域提供安全性。通常，非 SOA 模型依赖于基于边界的安全性，其中的信息资产通过防火墙层进行保护。
对于以 SOA 为中心的安全性，要首先按照第 4 步中所述创建风险管理框架。
第 4 步 使用风险评估框架方法创建初步草案
第 4 步将使用"内部安全性"(security from within) 方法。内部安全性 指安全性考虑与 SOA 实现中的所有活动对应。必须检查设计文档，了解必须在哪些地方作出安全决策并确定执行这些决策的安全控制点，从而了解 SOA 实现将如何工作。
需根据需要将这些策略的职责分配到应用程序、SOA 安全性服务和 SOA 组件，从而利用相应的机制来应用这些安全策略并加以执行。必须将安全需求封装或分解为将在 SOA 实现中以渗透方式工作的一组安全服务。例如，可以将用户身份验证的任务分配给 Authentication Security Service（所有应用程序都能够访问此服务并与之进行交互）。与此相对，可以配置企业服务总线（Enterprise Service Bus，ESB）来按应用程序限制对特定消息的访问。（第 2 部分将提供更多的相关细节。）
SOA 安全服务必须遵循相同的常规 SOA 原则、即松散偶合、模块化、封装、重用和可组合性，以获得必要的灵活性，帮助确保信息系统能够跟上业务设计中变化的速度，并成为实现更为完善的组织总体安 全性的变更驱动因素。这就要求从传统的静态安全模型转向动态模型，以跟上 SOA 体系结构中更快的变更速度。
除了内部安全性方法外，还必须同时保留基于风险管理的方法：从第 3 步中，可以看到有些数据的安全要求比其他数据高，有些应用程序比其他应用程序更为开放，如此等等。因此，不要均按照同样的标准处理所有消息和应用程序，否 则就可能对整个系统造成不必要的安全负担，从而影响系统的性能和可用性。总体风险管理战略中必须包含将安全需求与系统的总体可用性进行权衡的内容。
Gary McGraw 撰写的非常实用的书籍（请参见参考资料）详细说明了用于帮助创建风险管理框架（Risk-Management Framework，RMF）的包含五个部分的流程。从本质上说，您必须做到以下几点：
"了解业务上下文。
"确定业务和技术风险。
"对风险进行综合与分级。
"定义风险缓和战略。
"进行补救并验证结果。
例如，通过了解供应商竞标系统的业务上下文，可以发现尽管每个供应商都应该能够访问自己的信息，但查看其他供应商的信息却并不合适。此数据仅能在业务上下文中进行分类，而不能使用简单的层次结构模型（如第 3 步中的模型）进行分类。
第 5 步 定义内部和外部参与者
了 解了这些方法后，就该进行第 5 步了。在第 5 步中，SOA 安全团队将确定 SOA 安全参与者并进行相应的划分工作。参与者分为两类：外部和内部。外部政策制定者和治理机构（如 North American Electric Reliability Corporation (NERC)）可能提供了具有广泛安全影响的特定网络完全性标准，如关键基础设施保护（Critical Infrastructure Protection，CIP）需求等。
CIP 涵盖的领域非常广泛，如安全管理控制 (Security Management Controls) (CIP-003-1)、电子安全范围 (Electronic Security Perimeter) (CIP-005-1)、关键网络资产的物理安全 (Physical Security of Critical Cyber Assets) (CIP-006-1)、系统安全管理 (Systems Security Management) (CIP-007-1)、事故报告与响应计划 (Incident Reporting and Response Planning) (CIP-008-1) 及关键网络资产的恢复计划 (Recovery Plans for Critical Cyber Assets) (CIP-009-1)。所有这些标准都有自己的一组特定需求，会对总体 SOA 安全实现造成影响。
而且，内部安全需求（经常采用安全标准操作流程（Security Standard Operating Procedure，SOP）的形式编写）可回答谁、什么、何地、何时 及如何 这样的安全问题。谁能够何时何地访问什么，以及如何进行、持续时间多长？对于很多组织而言，此信息随着时间不断地发展，缺乏组织性和一致性；SOA 实现经常需要投入相当大的精力提供系统文档，以准确地反映组织的安全策略。
第 6 步 确定和使用正确的工具进行需求收集
在 第 6 步中，开始收集需求前，务必选择正确的工具，以便团队进行协作和方便地记录 SOA 安全需求和创建 SOA 安全模型。正确的需求与分析工具将帮助团队了解问题领域、捕获和管理不断发展的需求、建模用户交互、在整个项目生命周期中包含参与者反馈，而最为重要的是 进行协作。
良好的安全需求与分析实践将极大地减少系统安全风险。IBM? Rational? 需求与分析工具非常适合用于了解和表示参与者需求、指导和协调客户和业务需求的收集和验证工作、记录和组织系统的需求及向整个团队说明相关需求。我自己在 使用 IBM Rational RequisitePro?、WebSphere? Business Modeler 和 Rational Software Architect，建议大家也使用这些工具。
第 7 步 遵循 SOA 安全实现的 SDLC 流程
考虑到所必须收集的海量信息、必须编写的体系结构构件的数量以及将构造的特定 SOA 安全服务，SOA 安全团队应该遵循软件开发生命周期（Software Development Life Cycle，SDLC）的标准步骤：
1.确定安全需求和约束
2.得出和收集安全需求
3.创建安全体系结构设计
4.形成详细的安全 SOA 设计文档
5.实现 SOA（包括 SOA 治理）
6.测试
7.部署
8.维护
乍看之下，这些步骤可能非常明显，但安全团队很少采用 SDLC 流程。他们不习惯坐在房间里讨论相关工作和编写详细需求、设计安全抽象设计，以及创建详尽测试用例来验证系统是否具有可靠的安全性。（抽象设计和测试用例将在本系列的第 2 部分和第 3 部分进行讨论。）
团 队开始设计解决方案前，必须对需求进行收集。对于安全实现，既有显式需求，也有隐式需求。对于显式需求，一个很好的着手点就是按照第 5 步中所示收集每个参与者的需求。而对于隐式需求，最好使用安全框架，如保密性、完整性和可靠性（Confidentiality, Integrity, and Accountability，CIA）三部曲，以便在其中列出所有安全系统的具体需求。CIA 三部曲是广泛使用的信息保证（Information Assurance，IA）模型，此模型将保密性、完整性和可用性定义为所有信息系统的基础安全特征。
团队应该考虑此 SOA 实现将如何确保系统保密性（即数据保密），并构建清楚的流程图，以详细说明如何保证仅由目标授权接收方、个人、流程或设备访问传输中的消息。将消息泄漏给 非授权实体（如使用非授权网络探查的恶意用户）就违反了保密性，SOA 实现必须指定将在何种情况下在整个系统中使用加密技术（存储和传输保密信息的方法）。
与此类似，SOA 安全模型要求提供完整性（确保消息不会被更改）。SOA 安全负责确保信息在从原始位置传输到接收方的过程中不会被更改（数据完整性），并负责保证该信息的发送方是预期的发送方（来源完整性）且接收方是预期的接 收方（接收方完整性）。在预期接收方收到信息前，如果数据被有意或意外地更改或破坏，数据完整性就遭到了破坏。如果代理冒充发送方身份并向接收方提供不正 确的信息，则来源完整性就遭到了破坏。数据签名和哈希算法是用于提供数据完整性的机制。
另外，授权用户对数据服务 器的及时可靠访问（可用性）也是一项 SOA 安全需求：SOA 实现必须确保信息和资源在需要时可用，这意味着资源的提供速度应该足够满足较大的系统执行其预期任务所需的速度。当然可能在保密性和完整性得到保护的情况 下，入侵者仍然可能导致资源在需要时可用性降低，或根本不可用。具体来说，当 ESB 之类的 SOA 系统组件负责"代理消息"时，必须在 SOA 安全需求文档中详细说明高可用性协议、完全冗余网络体系结构和系统硬件，不要存在任何单点故障，从而保证系统的可靠性和稳健性。SOA 安全团队负责全面地表示这些区域，并确保记录了相应的用例（且能充分说明特定的需求）。
第 8 步 找出现有模型并从中吸取经验教训
SOA 安全需求团队花时间确定了所有需求后，团队成员会发现没有任何第三方工具能满足其全部需求。他们必须自己编写 SOA 安全服务来满足特定需求。比完全闭门造车好得多的做法是，对现有的模型进行分析，在团队开始抽象设计阶段前了解已经开发的内容。在此步骤（第 8 步）中，我们建议参考 Intelligrid 的以下模型（请参见参考资料）。可以在其中看到常用安全实用工具服务的列表，可能需要在 SOA 安全实现中提供这些服务。我将在下一篇文章中对这些服务进行更为详细的说明，但为了方便起见，我在此将其列出供参考：
"Audit Common Service
"Authorization Service for Access Control
"Confidentiality Service
"Credential Conversion Service
"Credential Renewal Service
"Delegation Service
"Firewall Traversal Service
"Identity Establishment Service
"Identity Mapping Service
"Information Integrity Service
"Inter-Domain Security Service
"Non-repudiation Service
"Path Routing and QoS Service
"Security Policy Service
"Policy Exchange Service
"Privacy Service
"Profile Service (User Profile Service)
"Quality of Identity Service
"Security Against Denial of Service (DoS)
"Security Assurance Management Service
"Security Protocol Mapping Service
"Security Service Availability Discovery Service
"Single Sign-on Service
"Trust Establishment Service
您可能并不需要其中的全部服务。SOA security 团队必须将需求映射到每个服务，然后为需要的所有服务创建 SOA 安全模型，以满足第 7 步中确定的所有需求。
第 9 步 熟悉 WS-Security 标准
完成此流程后，就收集了足够的信息可进行第 9 步了，即分析 WS-Security 标准，确定哪个标准适用于您的特定 SOA 安全实现。图 1 列出了需要参考的所有 WS-Security 标准。
图 1. WS-Security 标准
随着更为详细的模型的出现，必须熟悉组成 WS-Security 的各种 SOA 安全标准，并了解它们如何彼此相关以及其与 SOA 安全模型需求的关系。这些安全标准将用于构造整个 SOA 实现中的安全消息。
第 10 步 为第三方供应商制定标准
最 后，在第 10 步中，SOA 安全团队将负责为第三方供应商创建一组标准和应用程序编程接口（Application Program Interface，API）。SOA 的一个主要卖点是，系统将利用其开放性访问第三方供应商提供的服务。每个供应商必须熟悉 SOA 实现安全标准，并清楚地知道服务将如何与 SOA 实现的安全服务进行交互。
在整个过程中，必须维护详细的安全术语表，以确保所形成的所有文档采用相同的术语和定义。我建议从 Oasis Security Services TC Glossary 着手。应该与所有供应商共享此术语表，以确保所有人都采用相同的术语。
总结
在本文中，我们了解了常见 SOA 安全路线图的 10 个步骤：
"选择正确的团队。
"制定详细的项目计划。
"维护 SOA 支持安全决策表
"使用"内部安全性"和风险管理框架方法创建初步草案。
"定义内部和外部参与者。
"确定和使用正确的工具进行需求收集。
"遵循 SOA 安全实现的 SDLC 流程。
"找出现有模型并从中吸取经验教训。
"熟悉 WS-Security 标准。
"为第三方供应商制定标准。
如果遵循所有这些步骤，就在 SOA 安全性方面有了一个好的开头。
关注这个包括三部分的系列文章的后续部分，了解 SOA 安全团队进行成功 SOA 安全性实现所需的主要项目：路线图（第 1 部分）、抽象设计（第 2 部分）以及测试用例（第 3 部分）。
1 SOA安全性特点
1.1 跨技术、身份和管理边界的身份转换和传播
一套完整的业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维 护，这要求必须在SOA架构范围内建立统一的信任体系，使得请求者（人或程序）能够在服务间自由流动，系统能够自动地将请求者身份随着边界的不同而转换。
1.2 与合作伙伴建立信任
借助Web服务的强大能力，企业往往需要与合作伙伴建立紧密地服务和数据交换，发挥各自的优势来共同组成一个完整的一站式服务。比如一个旅行服务系统，机 票订购由专门的机票代理公司提供，旅游线路设计和行程服务则由旅行社负责，而食宿则由当地旅店提供。为了保证客户信息能够在多个系统安全完整地流动，并及 时地反映客户实时的旅行状态，必须在企业与合作伙伴之间建立可靠、安全的信任关系。
1.3 跨多个应用程序统一、重用和共享公共安全性
SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。每个应用系统可以使用共享安全组件，比如CA认证中心、信道加密方式和SOA安全网关等。此外，统一的安全标准遵从对于SOA整体安全性而言至关重要。
1.4 政府和行业规范要求的可追究性和可跟踪性
在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护，同时可能还需要用安全的方式在一定时期内保存敏感信息。在启用验证、审核和许可之前，必须保证 消息源的完整性（如通过公证服务）。消息的完整性和保密性可以通过对敏感信息进行加密和数字签名来实现。完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保存保护的内容以遵守政府规章制度和业界最佳实践的需要。企业需要对其提供的服务进行担保，确保服务 仅执行其公开申明的操作，同时有义务为用户提供足够的安全保障。因此，企业必须保存系统操作记录，以此来跟踪其用户或消息，也就是说企业必须具有很强的服 务审计能力。
1.5SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互
身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问 Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器 的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁（大多数情况下，这些请求被人恶意利用和操纵）将是SOA安全防御的一项 重要课题。
2 SOA面临的安全挑战
2.1 XML通信协议消耗大量带宽，引发安全问题
与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。
由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很 容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所"淹没"，结果可能导致拒绝式攻击从而损害系统的正常功 能。
为了解决这类问题，市场上已出现了专门的XML 。利用基于64位平台架构的语法分析器，该设备可以用来加速XML/SOAP的解析、XML模式的确 认、XPath的处理以及 XSLT的功能转换。据公开的产品测试报告称，这种XML 能够达到每秒处理1万多条XML消息的能力。
2.2 基于XML的服务间通信易受到监听和窃取
由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进 行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和Web服务策略（WS-Policy）是专门用来解决这个问题的两个标准；通过消息安全，可以保证Web服务环境中交换 的XML消息的完整性和保密性，Web服务安全（Web Service Security，WSS）和安全声明标记语言（Security Assertion Markup Language，SAML）则用来解决这方面的问题。
目前主要的XML安全标准包括：XML加密、XML签名语法和处理、数字签名和XML密钥管理规范（XML Key Management Specification，XKMS）等。值得一提的是，现有的XML安全标准已经可以实现对XML文档进行有选择的签名处理，而这在以前是不可能做到的，要么整个文档被签名，要么根本不签名。
下面我将重点介绍XML加密和XML签名。它们已经由W3C发布为标准，可以用来把安全加入到基于XML的数据中去。
XML加密是用来把原始的XML数据通过密码依次加密，从而让数据能够在请求者和服务端之间以一种模糊的方式传输。密码仅由请求者和服务端掌握，这就能保证即使是在传输的过程中有数据被截取，窃取者也只能看到一堆毫无意义的字符串，从而防止敏感信息泄露。
另一方面，XML签名则用来防止XML文档的被非法篡改。通过使用XML签名，一个服务供应商可以提供给任何的服务消费者--以一种确定的方式来检测XML的有效负载是否相对于它原来的方式或者原来的状态发生了改变。
需要特别指出的是，XML加密和XML签名适用于任何的XML类型的文档。意识到这一点是很重要的，因为它们不仅仅可以用来保护服务交互的有效负载的交 换，同样的它们也可以用来保护类似WSDL这种契约，这些文档也是基于XML的，并且也是SOA中的一个重要组成部分。
同样，市场上也出现了专门解决这类问题的产品，称为XML安全网关。类似传统的防火墙， 企业可以把它部署在网络边界上，从而对所有进出的XML数据进行保护。XML安全网关遵循包括XML和WS-Security在内的行业标准，对XML数 据进行验证、加密、签名以及认证，来提供安全的基于XML的Web服务通信。此外，它还可提供防火墙功能和访问控制功能。有些产品还可以与网络管理软件集 成，帮助企业降低IT管理成本，并解决依从性需求。
2.3 缺乏良好的编程模型严重威胁企业安全
对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则而构造实现的服务、应用程序以及跨组织操作所具有的松耦合特性，这种环境往往更加容易 现有安全实现的弱点或局限性，因此缺乏良好的编程模型将严重威胁Web服务的安全。
仅采用边界防御（如防火墙和路由器） 来保护企业信息安全是不够的，因为企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态的信任关系。因此，企业需要灵活的、可自定义的 基础设施，以适应新要求和规章制度。要提供这种灵活性，不应简单的指望将策略生搬硬套到基础设施中，应该在服务的开发过程中建立和遵循由策略驱动的编程模 型。SOA 编程模型可以确保每个服务调用都符合对请求者和服务端点均有效的安全策略。
从安全的角度来看，编程模型负责对于谁负责实现安全策略（如基础设施或应用程序）以及需要让请求者得到此信息的哪一部分等做出决策。另一方面要考虑的是调 用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性。最后，在实现安全解决方案时，还应该考虑安全工程--用于构建安全应用程序的工 程方法。
3 其它SOA安全保护方法
3.1 应用程序代理
一种非常有效的保护核心系统的方法是避免让任何人直接访问提供服务的平台，可以通过为SOA中的Web服务部署一个代理做到这一点。一个受保护的代理可以 代表实际的Web服务接收所有Web服务请求，并对其做出响应，从而保护Web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础 架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对Web服务请求的身份验证和授权，而不是每次用户想调用Web服务时，就在网络上使用大量 消息对该用户进行身份验证和授权。代理还可以在消息中插入了身份验证和授权SAML断言，从而消除了Web服务请求者直接查询核心安全性系统的风险。
3.2 契约管理
作为主要的SOA 管理问题之一，契约管理在SOA安全性中起着举足轻重的作用。所谓契约就是用于管理Web服务使用情况的一组规则。例如，某个契约可能会规定某个特定用户 有权每天调用某个特定的Web服务五百次，而且在调用过程中，服务水平必须满足特定的参数，比如所有请求都必须在2秒钟内响应。
在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而被误用。例如，SOA拦截器把Web服务请求和响应数据发送给SOA安全管理 中心，然后该SOA安全管理中心确定该请求是否满足契约。如果某个安全性行为（比如拒绝式服务攻击）使Web服务的响应速度降低到契约规定的服务水平以 下，SOA安全管理中心就会警告系统管理人员有问题存在，甚至可以根据预设的策略自动采取必要的措施，比如对某些攻击请求进行阻断或限制次重要服务的使用 频率等。尽管一次足够严重的攻击可以导致整个网络崩溃，但是合理的契约管理至少可以使我们得到及时的安全问题通知，从而有效地采取行动。
总之，为了应对SOA的安全挑战，需要在企业范围内（还应包括其合作伙伴）建立一套统一的安全基础设施，通过对请求者进行身份验证和对其授予服务访问权、 基于基本信任模型跨Web服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容，安全基础设施帮助企业形成一套完整的保护基于组件和服务的 SOA环境的结构。
所有SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。而基于 Web 服务安全规范的Web服务安全模型和方法有助于解决保护面向服务的应用程序的难题。
SOA安全标准面临新挑战
面向服务的体系结构（SOA）使安全决策变得复杂，原因在于，作为最终应用的许多移动部件，必须在模块程序中集成。因此，IT和安全人员在SOA计划实施之初就需要密切协调，才能保证其实现机密性、完整性和可用性。
对于一些组织机构和IT管理者而言，利用分布式计算，如SOA和集成式Web服务，意味着对设计的复杂性和安全性要求更高。
随着计算进一步趋向分布式，以及新型威胁和有组织的互联网犯罪的增多，开放式标准在制定和更好地利用有效的安全措施等方面起着重大的作用。除此之 外，如何在管理层次以及安全对策、程序和相关工作中利用这些标准，来提高内部员工的安全意识、促进业务伙伴访问企业服务、监测网络所面临的威胁也是至关重 要的。
本文探讨了SOA面临的安全挑战，安全标准制定取得的进展，以及安全标准在扩展时可能遇到的问题。
SOA使安全决策难度大
面向服务的体系结构从本质上说是一种由元数据和XML（可扩展的标记语言）一类的标准数据结构协议生成的应用程序。SOA所面临的安全问题与应用其他任何分布式系统时所遇到的安全问题是相同的，即如何确保机密性、完整性和可用性。
SOA虽然在某些方面使安全简化，但是在其他方面却使安全问题变得复杂。业界人士认为，由于在基础设施中使用了XML一类的数据结构通用协议、IP通信协 议和通用操作系统，因此SOA有助于简化某些安全决策；但在模块程序中，由于许多移动部件作为最终应用要集成在一起，因此使安全决策变得复杂。
启动开放性安全标准
分布式系统安全业务的开放性标准，如SAML（安全断言标记语言）、XACML（可扩展访问控制标记语言）和Web服务安全标准，已被OASIS（结构化信息标准促进组织）所采用。业界认为，新的SOA和分布式系统标准能够有效提升安全性。
可用性和可复用性要求采用更新、更灵活的标准，即用于联合等同的SAML、精确访问控制的XACML、性能先进的SOA应用的WS安全标准。据 称，SAML现在包括若干基于实时应用环境的新文档，并将融进更多的新文档。目前，推广应用SAML的成功者为数不少。某些政府也正在推广应用，其用户多 达数千万。
Web服务安全标准的制定工作已经基本完成。可以预计的是，如果用户进行相对简单的通用数据存取，他们将可以顺利完成这一过程。如果Web服务安全标准复 杂或者实施起来比较困难，那么用户可能就会遇到某些互操作性的问题。不过，等同联合的交替模块（包括Web服务联合和开放ID）能够解决这些问题。
改编新标准引争议
OASIS技术委员会正在编写一套扩展式Web服务安全对策样本。这套对策比较复杂，并且还没有在实际中应用过。
OASIS数字签名业务扩展（DSS-X）技术委员会正在制定标准的XML框架，用来管理机构之间的身份信息和系统资源及其分配。业界人士认为，XML标 准框架有利于管理身份信息和系统资源。不过现在的问题是必须推出和测试能互操作的产品，并部署和测试实时应用环境。
尽管为SOA指定的各种安全标准的制定还存在着种种障碍，但是把这些标准融入SOA以及将其大量应用于工业进程的工作正在进行中。
互操作性问题
Web服务常常作为应用互操作性的理想解决方案， 而且对于与平台、销售商和编程语言无关的综合应用也是非常有效的，它们不受互操作性问题的影响。因此，大多数互操作性问题并非来自于成熟稳定的Web服务 规范，而是来自各种Web服务规范的扩展和Web服务安全标准的一系列扩展。随着这些标准的扩展，销售商必须选择所要支持的规范草案，开发商有时需要协商 解决不同规范之间的不兼容问题。
SOA倾向于模块化设计
业界认为，SOA即使只作为实现模块设计的手段，其优点也非常突出。用SOA设计的模块就是将应用程序的不同功能单元（称为服务）通过这些服务之间定义良 好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样系统中的服务可以采用一种统一和通用的方式进行交互。这是一种松散藕合的 接口方式，其易损性比内部数据结构之间基于代码的交互作用低得多。其优点与面向对象的设计非常相似，甚至更胜一筹。
SOA内部模块化并不会引发安全问题，因为它不会将新的功能 给其他系统或外部机构。但是，代码库的重复使用和开放可存取性却存在着危险性，即通过与用 户和供应链上的合作伙伴所建立的业务接口，可能 新的服务功能。当这种情况发生时，预定的服务供给可能中断，给企图扩展权限和进行服务攻击不怀好意者留 下路径。
任何一种安全标准或所支持的标准总数，都不足以评估SOA或Web服务平台的效能。因此，对安全标准的支持并不就意味着安全。在许多情况下，安全标准只是定义了让各种服务模式能彼此互操作的框架，实际上它并不等于任何一种特殊服务模式都能良好运行。
即使完全按照Web服务安全实施办法，服务仍可能因为使用弱密码、受简单的密约管理，或者数据库未加密而出现不安全的情况。应当说安全是一种实际应用状态，而不仅仅是一系列所支持的标准。
SOA通过分布式系统的开放性标准以及模块化设计来提供安全的Web服务。
MSN视频对话存在堆溢出漏洞
受影响系统：MicrosoftMSNMessenger7.5、Microsoft MSN Messenger 7.0、Microsoft MSN Messenger 6.2和Microsoft Windows Messenger 8.0。
描述：MSNMessenger是微软发布的非常流行的即时通信聊天工具。MSNVIDEO处理用户请求时存在缓冲区溢出漏洞，远程攻击者可能利用此漏洞控制用户系统。
厂商补丁：Microsoft已经为此发布了一个安全公告（MS07-054）以及相应补丁:
MS07-054：VulnerabilityinMSNMessenger and Windows Live Messenger Could Allow Remote Code Execution (942099) 。
链接：technet/security/Bulletin/MS07-054.mspx?pf=true
动态
●Juniper推UAC2.1方案Juniper网络公司近日推出统一访问控制UAC 2.1安全解决方案。这项解决方案提供了先进的网络保护、应用可见性和监控、简化网络访问控制安装，有效遵循相关规定，同时降低风险，满足不断发展的访问 控制及高性能业务的安全要求。
●金山捕获新病毒金山公司近日发现新病毒，该病毒的作者借病毒来发布寻人启示，自行修改文件夹选项，同时会关闭任务管理器，如果不隐藏运行，则不断弹出恶意代码。为此，金山毒霸反病毒应急中心建议用户及时更新病毒库。
●CheckPoint推网关新功能Check Point软件技术有限公司近日宣布,其企业安全网关将Check Point的SmartDefense?与入侵防御技术相整合，可以阻止企业员工使用个人VoIP应用程序Skype v3.5，协助企业更好地管理，降低因其员工使用自行下载及自用程序所带来的安全风险。
垃圾邮件利用PDF漏洞攻击反病毒厂商F-secure近日发现一种利用最近一个AcrobatReader处理PDF的漏洞进行攻击的垃圾邮件。 这种垃圾邮件通常以"你的信用记录"、"个人财务信息"之类的标题作为主题，内容空白，并携带一个文件名为Report.pdf的文档，这个文档如果不小 心被用户开启后，会从一个位于马来西亚的服务器上下载并安装恶意软件。
●趋势科技将收购Provilla趋势科技近日宣布将收购内容安全厂商Provilla。Provilla是领先的数据泄漏防护产品厂商，主要生产基于指 纹识别的数据泄漏防护智能终端方案。收购完成后，Provilla将作为趋势科技美国分公司下属的子公司存在，并为趋势科技的多层内容安全方案提供支持。
●RSA推SecurIDSoftwareToken 安全厂商RSA近日推出了支持Symbian OS平台的SecurID Software Token产品，Symbian OS是当前流行的移动电话操作系统，而SecurID Software Token属于双因素身份验证产品，这表明了RSA的软件Token产品再次扩展到更大范围的移动平台上，同时为企业使用RSA软件Token降低了成本和门槛。
本文来自： 国际信息安全学习联盟
SOA项目中十步搞定大型SOA应用程序的安全
十步搞定大型SOA应用程序的安全
第 1 步 选择正确的团队
将大型关键基础设施应用程序迁移到 SOA 的工作令人望而生畏。对其进行保护甚至更为困难，经常需要采用全新的视角对其加以认识--甚至可能需要一组全新的安全人员进行相关工作。大部分安全团队在 SOA 方面甚至编程方面的培训极少。安全权威机构常用的方法是，只管发出要求并希望组织能够加以遵循。因此，第 1 步（这经常是最难的部分）是确保拥有正确的团队。
团队应该有个负责人，该负责人应该具有安全性和软件体系结构方面的知识，最好也能了解 SOA 的相关知识。与企业架构师类似，安全企业架构师（Security Enterprise Architect，SEA）将负责创建总体 SOA 安全模型，以便在每个粒度级别集成所有不同的安全性需求。SEA 将进入 SOA 治理委员会，与企业架构师（Enterprise Architect，EA）一起确保所有 SOA 实现都符合安全性需求的相关要求，并对负责创建整个流程中所需的构件的安全业务分析人员（Security Business Analyst，SBA）和安全系统工程师（Security Systems Engineers，SSE）团队进行指导。SEA 还将负责与编写安全性服务代码的程序员及在部署系统前对其进行测试的安全性系统测试人员合作。
第 2 步 创建详细项目计划
对于大型 SOA 系统，第 2 步要求高层管理了解，将无法通过改进新的 SOA 将其纳入旧安全模型中：这样做根本行不通。如果从最开始的重点就是传统安全机制（如防火墙、入侵检测系统和安全监视），这将完全与 SOA 安全实现不沾边。您将负责通过制定详细的项目计划和预算，清楚地说明和反映 SOA 安全实现所必需的东西，确保每个人都对此心里有底。
您必需让大家认识到，到 SOA 模型的任何转换都会涉及到固有的安全矛盾：系统的 SOA 特征越明显，其安全性越差。通过面向服务的建模和分析技术将当前系统转换为 SOA 的过程要求形成业务设计的相关文档。通过使用可将业务设计与信息系统相关的正式语言，通常仅能说明矛盾、低效而复杂的非 SOA 系统的情况。不过，这个复杂性会掩盖住大部分问题所在，从而使寻找机会破坏企业系统的人难于找到这些脆弱的环节。对这些系统进行分解并启用 SOA 后，恶意用户所面对的体系结构就会简单一些，从而更便于进行破坏。
SOA 支持者可能对此会加以否认，但负责保护系统安全的人知道，具有集中控制点且启用了 Web 的开放系统本身安全性就较差，而需要更为反应灵敏而灵活便利的方法。没有办法绕开这个问题，项目规划人员（经常会向 SOA 安全性方面分配一组适当的任务）必须记住，SOA 安全性需要详细的项目规划和预算，为安全性团队分配必要的时间，以便分析和了解 SOA 实现所带来的新挑战。
第 3 步 维护 SOA 支持安全决策表
通过创建 SOA 支持安全决策表正式记录抽象 SOA 安全性动态因素。在此表中，业务参与者将应用程序分为三类，包括：
"将启用 SOA 支持的应用程序
"必须与启用 SOA 支持的应用程序交互的应用程序
"将不启用 SOA 支持，也不必与启用 SOA 支持的应用程序交互的应用程序
也可以对这些不同的类别进行颜色编码。例如，我将第一个类别中的项目设置为红色，第二个类别中的项目设置为橙色，而将第三个类别的项目设置为黄色。
安全团队然后将进一步把应用程序划分到各个安全性类别，如高、中和低。例如，处理市场和分类信息的应用程序或服务将属于高安全性类别，而仅仅访问公开数据的应用程序或服务可以归入最低安全性类别。
表 1 显示了 SOA 支持安全决策表的示例。
表 1. SOA 支持安全决策表
安全性（高） 安全性（中） 安全性（低）
红色 36 12 11
橙色 12 5 3
黄色 6 0 6
在表中可以看到 12 个应用程序将不启用 SOA 支持（标为黄色的应用程序）；因此，此工作将需要异类安全模型，即一个为以 SOA 为中心的系统部分提供安全性，另一个为非 SOA 区域提供安全性。通常，非 SOA 模型依赖于基于边界的安全性，其中的信息资产通过防火墙层进行保护。
对于以 SOA 为中心的安全性，要首先按照第 4 步中所述创建风险管理框架。
第 4 步 使用风险评估框架方法创建初步草案
第 4 步将使用"内部安全性"(security from within) 方法。内部安全性 指安全性考虑与 SOA 实现中的所有活动对应。必须检查设计文档，了解必须在哪些地方作出安全决策并确定执行这些决策的安全控制点，从而了解 SOA 实现将如何工作。
需根据需要将这些策略的职责分配到应用程序、SOA 安全性服务和 SOA 组件，从而利用相应的机制来应用这些安全策略并加以执行。必须将安全需求封装或分解为将在 SOA 实现中以渗透方式工作的一组安全服务。例如，可以将用户身份验证的任务分配给 Authentication Security Service（所有应用程序都能够访问此服务并与之进行交互）。与此相对，可以配置企业服务总线（Enterprise Service Bus，ESB）来按应用程序限制对特定消息的访问。（第 2 部分将提供更多的相关细节。）
SOA 安全服务必须遵循相同的常规 SOA 原则、即松散偶合、模块化、封装、重用和可组合性，以获得必要的灵活性，帮助确保信息系统能够跟上业务设计中变化的速度，并成为实现更为完善的组织总体安 全性的变更驱动因素。这就要求从传统的静态安全模型转向动态模型，以跟上 SOA 体系结构中更快的变更速度。
除了内部安全性方法外，还必须同时保留基于风险管理的方法：从第 3 步中，可以看到有些数据的安全要求比其他数据高，有些应用程序比其他应用程序更为开放，如此等等。因此，不要均按照同样的标准处理所有消息和应用程序，否 则就可能对整个系统造成不必要的安全负担，从而影响系统的性能和可用性。总体风险管理战略中必须包含将安全需求与系统的总体可用性进行权衡的内容。
Gary McGraw 撰写的非常实用的书籍（请参见参考资料）详细说明了用于帮助创建风险管理框架（Risk-Management Framework，RMF）的包含五个部分的流程。从本质上说，您必须做到以下几点：
"了解业务上下文。
"确定业务和技术风险。
"对风险进行综合与分级。
"定义风险缓和战略。
"进行补救并验证结果。
例如，通过了解供应商竞标系统的业务上下文，可以发现尽管每个供应商都应该能够访问自己的信息，但查看其他供应商的信息却并不合适。此数据仅能在业务上下文中进行分类，而不能使用简单的层次结构模型（如第 3 步中的模型）进行分类。
第 5 步 定义内部和外部参与者
了 解了这些方法后，就该进行第 5 步了。在第 5 步中，SOA 安全团队将确定 SOA 安全参与者并进行相应的划分工作。参与者分为两类：外部和内部。外部政策制定者和治理机构（如 North American Electric Reliability Corporation (NERC)）可能提供了具有广泛安全影响的特定网络完全性标准，如关键基础设施保护（Critical Infrastructure Protection，CIP）需求等。
CIP 涵盖的领域非常广泛，如安全管理控制 (Security Management Controls) (CIP-003-1)、电子安全范围 (Electronic Security Perimeter) (CIP-005-1)、关键网络资产的物理安全 (Physical Security of Critical Cyber Assets) (CIP-006-1)、系统安全管理 (Systems Security Management) (CIP-007-1)、事故报告与响应计划 (Incident Reporting and Response Planning) (CIP-008-1) 及关键网络资产的恢复计划 (Recovery Plans for Critical Cyber Assets) (CIP-009-1)。所有这些标准都有自己的一组特定需求，会对总体 SOA 安全实现造成影响。
而且，内部安全需求（经常采用安全标准操作流程（Security Standard Operating Procedure，SOP）的形式编写）可回答谁、什么、何地、何时 及如何 这样的安全问题。谁能够何时何地访问什么，以及如何进行、持续时间多长？对于很多组织而言，此信息随着时间不断地发展，缺乏组织性和一致性；SOA 实现经常需要投入相当大的精力提供系统文档，以准确地反映组织的安全策略。
第 6 步 确定和使用正确的工具进行需求收集
在 第 6 步中，开始收集需求前，务必选择正确的工具，以便团队进行协作和方便地记录 SOA 安全需求和创建 SOA 安全模型。正确的需求与分析工具将帮助团队了解问题领域、捕获和管理不断发展的需求、建模用户交互、在整个项目生命周期中包含参与者反馈，而最为重要的是 进行协作。
良好的安全需求与分析实践将极大地减少系统安全风险。IBM? Rational? 需求与分析工具非常适合用于了解和表示参与者需求、指导和协调客户和业务需求的收集和验证工作、记录和组织系统的需求及向整个团队说明相关需求。我自己在 使用 IBM Rational RequisitePro?、WebSphere? Business Modeler 和 Rational Software Architect，建议大家也使用这些工具。
第 7 步 遵循 SOA 安全实现的 SDLC 流程
考虑到所必须收集的海量信息、必须编写的体系结构构件的数量以及将构造的特定 SOA 安全服务，SOA 安全团队应该遵循软件开发生命周期（Software Development Life Cycle，SDLC）的标准步骤：
1.确定安全需求和约束
2.得出和收集安全需求
3.创建安全体系结构设计
4.形成详细的安全 SOA 设计文档
5.实现 SOA（包括 SOA 治理）
6.测试
7.部署
8.维护
乍看之下，这些步骤可能非常明显，但安全团队很少采用 SDLC 流程。他们不习惯坐在房间里讨论相关工作和编写详细需求、设计安全抽象设计，以及创建详尽测试用例来验证系统是否具有可靠的安全性。（抽象设计和测试用例将在本系列的第 2 部分和第 3 部分进行讨论。）
团 队开始设计解决方案前，必须对需求进行收集。对于安全实现，既有显式需求，也有隐式需求。对于显式需求，一个很好的着手点就是按照第 5 步中所示收集每个参与者的需求。而对于隐式需求，最好使用安全框架，如保密性、完整性和可靠性（Confidentiality, Integrity, and Accountability，CIA）三部曲，以便在其中列出所有安全系统的具体需求。CIA 三部曲是广泛使用的信息保证（Information Assurance，IA）模型，此模型将保密性、完整性和可用性定义为所有信息系统的基础安全特征。
团队应该考虑此 SOA 实现将如何确保系统保密性（即数据保密），并构建清楚的流程图，以详细说明如何保证仅由目标授权接收方、个人、流程或设备访问传输中的消息。将消息泄漏给 非授权实体（如使用非授权网络探查的恶意用户）就违反了保密性，SOA 实现必须指定将在何种情况下在整个系统中使用加密技术（存储和传输保密信息的方法）。
与此类似，SOA 安全模型要求提供完整性（确保消息不会被更改）。SOA 安全负责确保信息在从原始位置传输到接收方的过程中不会被更改（数据完整性），并负责保证该信息的发送方是预期的发送方（来源完整性）且接收方是预期的接 收方（接收方完整性）。在预期接收方收到信息前，如果数据被有意或意外地更改或破坏，数据完整性就遭到了破坏。如果代理冒充发送方身份并向接收方提供不正 确的信息，则来源完整性就遭到了破坏。数据签名和哈希算法是用于提供数据完整性的机制。
另外，授权用户对数据服务 器的及时可靠访问（可用性）也是一项 SOA 安全需求：SOA 实现必须确保信息和资源在需要时可用，这意味着资源的提供速度应该足够满足较大的系统执行其预期任务所需的速度。当然可能在保密性和完整性得到保护的情况 下，入侵者仍然可能导致资源在需要时可用性降低，或根本不可用。具体来说，当 ESB 之类的 SOA 系统组件负责"代理消息"时，必须在 SOA 安全需求文档中详细说明高可用性协议、完全冗余网络体系结构和系统硬件，不要存在任何单点故障，从而保证系统的可靠性和稳健性。SOA 安全团队负责全面地表示这些区域，并确保记录了相应的用例（且能充分说明特定的需求）。
第 8 步 找出现有模型并从中吸取经验教训
SOA 安全需求团队花时间确定了所有需求后，团队成员会发现没有任何第三方工具能满足其全部需求。他们必须自己编写 SOA 安全服务来满足特定需求。比完全闭门造车好得多的做法是，对现有的模型进行分析，在团队开始抽象设计阶段前了解已经开发的内容。在此步骤（第 8 步）中，我们建议参考 Intelligrid 的以下模型（请参见参考资料）。可以在其中看到常用安全实用工具服务的列表，可能需要在 SOA 安全实现中提供这些服务。我将在下一篇文章中对这些服务进行更为详细的说明，但为了方便起见，我在此将其列出供参考：
"Audit Common Service
"Authorization Service for Access Control
"Confidentiality Service
"Credential Conversion Service
"Credential Renewal Service
"Delegation Service
"Firewall Traversal Service
"Identity Establishment Service
"Identity Mapping Service
"Information Integrity Service
"Inter-Domain Security Service
"Non-repudiation Service
"Path Routing and QoS Service
"Security Policy Service
"Policy Exchange Service
"Privacy Service
"Profile Service (User Profile Service)
"Quality of Identity Service
"Security Against Denial of Service (DoS)
"Security Assurance Management Service
"Security Protocol Mapping Service
"Security Service Availability Discovery Service
"Single Sign-on Service
"Trust Establishment Service
您可能并不需要其中的全部服务。SOA security 团队必须将需求映射到每个服务，然后为需要的所有服务创建 SOA 安全模型，以满足第 7 步中确定的所有需求。
第 9 步 熟悉 WS-Security 标准
完成此流程后，就收集了足够的信息可进行第 9 步了，即分析 WS-Security 标准，确定哪个标准适用于您的特定 SOA 安全实现。图 1 列出了需要参考的所有 WS-Security 标准。
图 1. WS-Security 标准
随着更为详细的模型的出现，必须熟悉组成 WS-Security 的各种 SOA 安全标准，并了解它们如何彼此相关以及其与 SOA 安全模型需求的关系。这些安全标准将用于构造整个 SOA 实现中的安全消息。
第 10 步 为第三方供应商制定标准
最 后，在第 10 步中，SOA 安全团队将负责为第三方供应商创建一组标准和应用程序编程接口（Application Program Interface，API）。SOA 的一个主要卖点是，系统将利用其开放性访问第三方供应商提供的服务。每个供应商必须熟悉 SOA 实现安全标准，并清楚地知道服务将如何与 SOA 实现的安全服务进行交互。
在整个过程中，必须维护详细的安全术语表，以确保所形成的所有文档采用相同的术语和定义。我建议从 Oasis Security Services TC Glossary 着手。应该与所有供应商共享此术语表，以确保所有人都采用相同的术语。
总结
在本文中，我们了解了常见 SOA 安全路线图的 10 个步骤：
"选择正确的团队。
"制定详细的项目计划。
"维护 SOA 支持安全决策表
"使用"内部安全性"和风险管理框架方法创建初步草案。
"定义内部和外部参与者。
"确定和使用正确的工具进行需求收集。
"遵循 SOA 安全实现的 SDLC 流程。
"找出现有模型并从中吸取经验教训。
"熟悉 WS-Security 标准。
"为第三方供应商制定标准。
如果遵循所有这些步骤，就在 SOA 安全性方面有了一个好的开头。
关注这个包括三部分的系列文章的后续部分，了解 SOA 安全团队进行成功 SOA 安全性实现所需的主要项目：路线图（第 1 部分）、抽象设计（第 2 部分）以及测试用例（第 3 部分）。
1 SOA安全性特点
1.1 跨技术、身份和管理边界的身份转换和传播
一套完整的业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维 护，这要求必须在SOA架构范围内建立统一的信任体系，使得请求者（人或程序）能够在服务间自由流动，系统能够自动地将请求者身份随着边界的不同而转换。
1.2 与合作伙伴建立信任
借助Web服务的强大能力，企业往往需要与合作伙伴建立紧密地服务和数据交换，发挥各自的优势来共同组成一个完整的一站式服务。比如一个旅行服务系统，机 票订购由专门的机票代理公司提供，旅游线路设计和行程服务则由旅行社负责，而食宿则由当地旅店提供。为了保证客户信息能够在多个系统安全完整地流动，并及 时地反映客户实时的旅行状态，必须在企业与合作伙伴之间建立可靠、安全的信任关系。
1.3 跨多个应用程序统一、重用和共享公共安全性
SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。每个应用系统可以使用共享安全组件，比如CA认证中心、信道加密方式和SOA安全网关等。此外，统一的安全标准遵从对于SOA整体安全性而言至关重要。
1.4 政府和行业规范要求的可追究性和可跟踪性
在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护，同时可能还需要用安全的方式在一定时期内保存敏感信息。在启用验证、审核和许可之前，必须保证 消息源的完整性（如通过公证服务）。消息的完整性和保密性可以通过对敏感信息进行加密和数字签名来实现。完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保存保护的内容以遵守政府规章制度和业界最佳实践的需要。企业需要对其提供的服务进行担保，确保服务 仅执行其公开申明的操作，同时有义务为用户提供足够的安全保障。因此，企业必须保存系统操作记录，以此来跟踪其用户或消息，也就是说企业必须具有很强的服 务审计能力。
1.5SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互
身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问 Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器 的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁（大多数情况下，这些请求被人恶意利用和操纵）将是SOA安全防御的一项 重要课题。
2 SOA面临的安全挑战
2.1 XML通信协议消耗大量带宽，引发安全问题
与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。
由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很 容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所"淹没"，结果可能导致拒绝式攻击从而损害系统的正常功 能。
为了解决这类问题，市场上已出现了专门的XML 。利用基于64位平台架构的语法分析器，该设备可以用来加速XML/SOAP的解析、XML模式的确 认、XPath的处理以及 XSLT的功能转换。据公开的产品测试报告称，这种XML 能够达到每秒处理1万多条XML消息的能力。
2.2 基于XML的服务间通信易受到监听和窃取
由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进 行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和Web服务策略（WS-Policy）是专门用来解决这个问题的两个标准；通过消息安全，可以保证Web服务环境中交换 的XML消息的完整性和保密性，Web服务安全（Web Service Security，WSS）和安全声明标记语言（Security Assertion Markup Language，SAML）则用来解决这方面的问题。
目前主要的XML安全标准包括：XML加密、XML签名语法和处理、数字签名和XML密钥管理规范（XML Key Management Specification，XKMS）等。值得一提的是，现有的XML安全标准已经可以实现对XML文档进行有选择的签名处理，而这在以前是不可能做到的，要么整个文档被签名，要么根本不签名。
下面我将重点介绍XML加密和XML签名。它们已经由W3C发布为标准，可以用来把安全加入到基于XML的数据中去。
XML加密是用来把原始的XML数据通过密码依次加密，从而让数据能够在请求者和服务端之间以一种模糊的方式传输。密码仅由请求者和服务端掌握，这就能保证即使是在传输的过程中有数据被截取，窃取者也只能看到一堆毫无意义的字符串，从而防止敏感信息泄露。
另一方面，XML签名则用来防止XML文档的被非法篡改。通过使用XML签名，一个服务供应商可以提供给任何的服务消费者--以一种确定的方式来检测XML的有效负载是否相对于它原来的方式或者原来的状态发生了改变。
需要特别指出的是，XML加密和XML签名适用于任何的XML类型的文档。意识到这一点是很重要的，因为它们不仅仅可以用来保护服务交互的有效负载的交 换，同样的它们也可以用来保护类似WSDL这种契约，这些文档也是基于XML的，并且也是SOA中的一个重要组成部分。
同样，市场上也出现了专门解决这类问题的产品，称为XML安全网关。类似传统的防火墙， 企业可以把它部署在网络边界上，从而对所有进出的XML数据进行保护。XML安全网关遵循包括XML和WS-Security在内的行业标准，对XML数 据进行验证、加密、签名以及认证，来提供安全的基于XML的Web服务通信。此外，它还可提供防火墙功能和访问控制功能。有些产品还可以与网络管理软件集 成，帮助企业降低IT管理成本，并解决依从性需求。
2.3 缺乏良好的编程模型严重威胁企业安全
对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则而构造实现的服务、应用程序以及跨组织操作所具有的松耦合特性，这种环境往往更加容易 现有安全实现的弱点或局限性，因此缺乏良好的编程模型将严重威胁Web服务的安全。
仅采用边界防御（如防火墙和路由器） 来保护企业信息安全是不够的，因为企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态的信任关系。因此，企业需要灵活的、可自定义的 基础设施，以适应新要求和规章制度。要提供这种灵活性，不应简单的指望将策略生搬硬套到基础设施中，应该在服务的开发过程中建立和遵循由策略驱动的编程模 型。SOA 编程模型可以确保每个服务调用都符合对请求者和服务端点均有效的安全策略。
从安全的角度来看，编程模型负责对于谁负责实现安全策略（如基础设施或应用程序）以及需要让请求者得到此信息的哪一部分等做出决策。另一方面要考虑的是调 用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性。最后，在实现安全解决方案时，还应该考虑安全工程--用于构建安全应用程序的工 程方法。
3 其它SOA安全保护方法
3.1 应用程序代理
一种非常有效的保护核心系统的方法是避免让任何人直接访问提供服务的平台，可以通过为SOA中的Web服务部署一个代理做到这一点。一个受保护的代理可以 代表实际的Web服务接收所有Web服务请求，并对其做出响应，从而保护Web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础 架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对Web服务请求的身份验证和授权，而不是每次用户想调用Web服务时，就在网络上使用大量 消息对该用户进行身份验证和授权。代理还可以在消息中插入了身份验证和授权SAML断言，从而消除了Web服务请求者直接查询核心安全性系统的风险。
3.2 契约管理
作为主要的SOA 管理问题之一，契约管理在SOA安全性中起着举足轻重的作用。所谓契约就是用于管理Web服务使用情况的一组规则。例如，某个契约可能会规定某个特定用户 有权每天调用某个特定的Web服务五百次，而且在调用过程中，服务水平必须满足特定的参数，比如所有请求都必须在2秒钟内响应。
在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而被误用。例如，SOA拦截器把Web服务请求和响应数据发送给SOA安全管理 中心，然后该SOA安全管理中心确定该请求是否满足契约。如果某个安全性行为（比如拒绝式服务攻击）使Web服务的响应速度降低到契约规定的服务水平以 下，SOA安全管理中心就会警告系统管理人员有问题存在，甚至可以根据预设的策略自动采取必要的措施，比如对某些攻击请求进行阻断或限制次重要服务的使用 频率等。尽管一次足够严重的攻击可以导致整个网络崩溃，但是合理的契约管理至少可以使我们得到及时的安全问题通知，从而有效地采取行动。
总之，为了应对SOA的安全挑战，需要在企业范围内（还应包括其合作伙伴）建立一套统一的安全基础设施，通过对请求者进行身份验证和对其授予服务访问权、 基于基本信任模型跨Web服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容，安全基础设施帮助企业形成一套完整的保护基于组件和服务的 SOA环境的结构。
所有SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。而基于 Web 服务安全规范的Web服务安全模型和方法有助于解决保护面向服务的应用程序的难题。
SOA安全标准面临新挑战
面向服务的体系结构（SOA）使安全决策变得复杂，原因在于，作为最终应用的许多移动部件，必须在模块程序中集成。因此，IT和安全人员在SOA计划实施之初就需要密切协调，才能保证其实现机密性、完整性和可用性。
对于一些组织机构和IT管理者而言，利用分布式计算，如SOA和集成式Web服务，意味着对设计的复杂性和安全性要求更高。
随着计算进一步趋向分布式，以及新型威胁和有组织的互联网犯罪的增多，开放式标准在制定和更好地利用有效的安全措施等方面起着重大的作用。除此之 外，如何在管理层次以及安全对策、程序和相关工作中利用这些标准，来提高内部员工的安全意识、促进业务伙伴访问企业服务、监测网络所面临的威胁也是至关重 要的。
本文探讨了SOA面临的安全挑战，安全标准制定取得的进展，以及安全标准在扩展时可能遇到的问题。
SOA使安全决策难度大
面向服务的体系结构从本质上说是一种由元数据和XML（可扩展的标记语言）一类的标准数据结构协议生成的应用程序。SOA所面临的安全问题与应用其他任何分布式系统时所遇到的安全问题是相同的，即如何确保机密性、完整性和可用性。
SOA虽然在某些方面使安全简化，但是在其他方面却使安全问题变得复杂。业界人士认为，由于在基础设施中使用了XML一类的数据结构通用协议、IP通信协 议和通用操作系统，因此SOA有助于简化某些安全决策；但在模块程序中，由于许多移动部件作为最终应用要集成在一起，因此使安全决策变得复杂。
启动开放性安全标准
分布式系统安全业务的开放性标准，如SAML（安全断言标记语言）、XACML（可扩展访问控制标记语言）和Web服务安全标准，已被OASIS（结构化信息标准促进组织）所采用。业界认为，新的SOA和分布式系统标准能够有效提升安全性。
可用性和可复用性要求采用更新、更灵活的标准，即用于联合等同的SAML、精确访问控制的XACML、性能先进的SOA应用的WS安全标准。据 称，SAML现在包括若干基于实时应用环境的新文档，并将融进更多的新文档。目前，推广应用SAML的成功者为数不少。某些政府也正在推广应用，其用户多 达数千万。
Web服务安全标准的制定工作已经基本完成。可以预计的是，如果用户进行相对简单的通用数据存取，他们将可以顺利完成这一过程。如果Web服务安全标准复 杂或者实施起来比较困难，那么用户可能就会遇到某些互操作性的问题。不过，等同联合的交替模块（包括Web服务联合和开放ID）能够解决这些问题。
改编新标准引争议
OASIS技术委员会正在编写一套扩展式Web服务安全对策样本。这套对策比较复杂，并且还没有在实际中应用过。
OASIS数字签名业务扩展（DSS-X）技术委员会正在制定标准的XML框架，用来管理机构之间的身份信息和系统资源及其分配。业界人士认为，XML标 准框架有利于管理身份信息和系统资源。不过现在的问题是必须推出和测试能互操作的产品，并部署和测试实时应用环境。
尽管为SOA指定的各种安全标准的制定还存在着种种障碍，但是把这些标准融入SOA以及将其大量应用于工业进程的工作正在进行中。
互操作性问题
Web服务常常作为应用互操作性的理想解决方案， 而且对于与平台、销售商和编程语言无关的综合应用也是非常有效的，它们不受互操作性问题的影响。因此，大多数互操作性问题并非来自于成熟稳定的Web服务 规范，而是来自各种Web服务规范的扩展和Web服务安全标准的一系列扩展。随着这些标准的扩展，销售商必须选择所要支持的规范草案，开发商有时需要协商 解决不同规范之间的不兼容问题。
SOA倾向于模块化设计
业界认为，SOA即使只作为实现模块设计的手段，其优点也非常突出。用SOA设计的模块就是将应用程序的不同功能单元（称为服务）通过这些服务之间定义良 好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样系统中的服务可以采用一种统一和通用的方式进行交互。这是一种松散藕合的 接口方式，其易损性比内部数据结构之间基于代码的交互作用低得多。其优点与面向对象的设计非常相似，甚至更胜一筹。
SOA内部模块化并不会引发安全问题，因为它不会将新的功能 给其他系统或外部机构。但是，代码库的重复使用和开放可存取性却存在着危险性，即通过与用 户和供应链上的合作伙伴所建立的业务接口，可能 新的服务功能。当这种情况发生时，预定的服务供给可能中断，给企图扩展权限和进行服务攻击不怀好意者留 下路径。
任何一种安全标准或所支持的标准总数，都不足以评估SOA或Web服务平台的效能。因此，对安全标准的支持并不就意味着安全。在许多情况下，安全标准只是定义了让各种服务模式能彼此互操作的框架，实际上它并不等于任何一种特殊服务模式都能良好运行。
即使完全按照Web服务安全实施办法，服务仍可能因为使用弱密码、受简单的密约管理，或者数据库未加密而出现不安全的情况。应当说安全是一种实际应用状态，而不仅仅是一系列所支持的标准。
SOA通过分布式系统的开放性标准以及模块化设计来提供安全的Web服务。
MSN视频对话存在堆溢出漏洞
受影响系统：MicrosoftMSNMessenger7.5、Microsoft MSN Messenger 7.0、Microsoft MSN Messenger 6.2和Microsoft Windows Messenger 8.0。
描述：MSNMessenger是微软发布的非常流行的即时通信聊天工具。MSNVIDEO处理用户请求时存在缓冲区溢出漏洞，远程攻击者可能利用此漏洞控制用户系统。
厂商补丁：Microsoft已经为此发布了一个安全公告（MS07-054）以及相应补丁:
MS07-054：VulnerabilityinMSNMessenger and Windows Live Messenger Could Allow Remote Code Execution (942099) 。
链接：technet/security/Bulletin/MS07-054.mspx?pf=true
动态
●Juniper推UAC2.1方案Juniper网络公司近日推出统一访问控制UAC 2.1安全解决方案。这项解决方案提供了先进的网络保护、应用可见性和监控、简化网络访问控制安装，有效遵循相关规定，同时降低风险，满足不断发展的访问 控制及高性能业务的安全要求。
●金山捕获新病毒金山公司近日发现新病毒，该病毒的作者借病毒来发布寻人启示，自行修改文件夹选项，同时会关闭任务管理器，如果不隐藏运行，则不断弹出恶意代码。为此，金山毒霸反病毒应急中心建议用户及时更新病毒库。
●CheckPoint推网关新功能Check Point软件技术有限公司近日宣布,其企业安全网关将Check Point的SmartDefense?与入侵防御技术相整合，可以阻止企业员工使用个人VoIP应用程序Skype v3.5，协助企业更好地管理，降低因其员工使用自行下载及自用程序所带来的安全风险。
垃圾邮件利用PDF漏洞攻击反病毒厂商F-secure近日发现一种利用最近一个AcrobatReader处理PDF的漏洞进行攻击的垃圾邮件。 这种垃圾邮件通常以"你的信用记录"、"个人财务信息"之类的标题作为主题，内容空白，并携带一个文件名为Report.pdf的文档，这个文档如果不小 心被用户开启后，会从一个位于马来西亚的服务器上下载并安装恶意软件。
●趋势科技将收购Provilla趋势科技近日宣布将收购内容安全厂商Provilla。Provilla是领先的数据泄漏防护产品厂商，主要生产基于指 纹识别的数据泄漏防护智能终端方案。收购完成后，Provilla将作为趋势科技美国分公司下属的子公司存在，并为趋势科技的多层内容安全方案提供支持。
●RSA推SecurIDSoftwareToken 安全厂商RSA近日推出了支持Symbian OS平台的SecurID Software Token产品，Symbian OS是当前流行的移动电话操作系统，而SecurID Software Token属于双因素身份验证产品，这表明了RSA的软件Token产品再次扩展到更大范围的移动平台上，同时为企业使用RSA软件Token降低了成本和门槛。
本文来自： 国际信息安全学习联盟
SOA项目中十步搞定大型SOA应用程序的安全
十步搞定大型SOA应用程序的安全
第 1 步 选择正确的团队
将大型关键基础设施应用程序迁移到 SOA 的工作令人望而生畏。对其进行保护甚至更为困难，经常需要采用全新的视角对其加以认识--甚至可能需要一组全新的安全人员进行相关工作。大部分安全团队在 SOA 方面甚至编程方面的培训极少。安全权威机构常用的方法是，只管发出要求并希望组织能够加以遵循。因此，第 1 步（这经常是最难的部分）是确保拥有正确的团队。
团队应该有个负责人，该负责人应该具有安全性和软件体系结构方面的知识，最好也能了解 SOA 的相关知识。与企业架构师类似，安全企业架构师（Security Enterprise Architect，SEA）将负责创建总体 SOA 安全模型，以便在每个粒度级别集成所有不同的安全性需求。SEA 将进入 SOA 治理委员会，与企业架构师（Enterprise Architect，EA）一起确保所有 SOA 实现都符合安全性需求的相关要求，并对负责创建整个流程中所需的构件的安全业务分析人员（Security Business Analyst，SBA）和安全系统工程师（Security Systems Engineers，SSE）团队进行指导。SEA 还将负责与编写安全性服务代码的程序员及在部署系统前对其进行测试的安全性系统测试人员合作。
第 2 步 创建详细项目计划
对于大型 SOA 系统，第 2 步要求高层管理了解，将无法通过改进新的 SOA 将其纳入旧安全模型中：这样做根本行不通。如果从最开始的重点就是传统安全机制（如防火墙、入侵检测系统和安全监视），这将完全与 SOA 安全实现不沾边。您将负责通过制定详细的项目计划和预算，清楚地说明和反映 SOA 安全实现所必需的东西，确保每个人都对此心里有底。
您必需让大家认识到，到 SOA 模型的任何转换都会涉及到固有的安全矛盾：系统的 SOA 特征越明显，其安全性越差。通过面向服务的建模和分析技术将当前系统转换为 SOA 的过程要求形成业务设计的相关文档。通过使用可将业务设计与信息系统相关的正式语言，通常仅能说明矛盾、低效而复杂的非 SOA 系统的情况。不过，这个复杂性会掩盖住大部分问题所在，从而使寻找机会破坏企业系统的人难于找到这些脆弱的环节。对这些系统进行分解并启用 SOA 后，恶意用户所面对的体系结构就会简单一些，从而更便于进行破坏。
SOA 支持者可能对此会加以否认，但负责保护系统安全的人知道，具有集中控制点且启用了 Web 的开放系统本身安全性就较差，而需要更为反应灵敏而灵活便利的方法。没有办法绕开这个问题，项目规划人员（经常会向 SOA 安全性方面分配一组适当的任务）必须记住，SOA 安全性需要详细的项目规划和预算，为安全性团队分配必要的时间，以便分析和了解 SOA 实现所带来的新挑战。
第 3 步 维护 SOA 支持安全决策表
通过创建 SOA 支持安全决策表正式记录抽象 SOA 安全性动态因素。在此表中，业务参与者将应用程序分为三类，包括：
"将启用 SOA 支持的应用程序
"必须与启用 SOA 支持的应用程序交互的应用程序
"将不启用 SOA 支持，也不必与启用 SOA 支持的应用程序交互的应用程序
也可以对这些不同的类别进行颜色编码。例如，我将第一个类别中的项目设置为红色，第二个类别中的项目设置为橙色，而将第三个类别的项目设置为黄色。
安全团队然后将进一步把应用程序划分到各个安全性类别，如高、中和低。例如，处理市场和分类信息的应用程序或服务将属于高安全性类别，而仅仅访问公开数据的应用程序或服务可以归入最低安全性类别。
表 1 显示了 SOA 支持安全决策表的示例。
表 1. SOA 支持安全决策表
安全性（高） 安全性（中） 安全性（低）
红色 36 12 11
橙色 12 5 3
黄色 6 0 6
在表中可以看到 12 个应用程序将不启用 SOA 支持（标为黄色的应用程序）；因此，此工作将需要异类安全模型，即一个为以 SOA 为中心的系统部分提供安全性，另一个为非 SOA 区域提供安全性。通常，非 SOA 模型依赖于基于边界的安全性，其中的信息资产通过防火墙层进行保护。
对于以 SOA 为中心的安全性，要首先按照第 4 步中所述创建风险管理框架。
第 4 步 使用风险评估框架方法创建初步草案
第 4 步将使用"内部安全性"(security from within) 方法。内部安全性 指安全性考虑与 SOA 实现中的所有活动对应。必须检查设计文档，了解必须在哪些地方作出安全决策并确定执行这些决策的安全控制点，从而了解 SOA 实现将如何工作。
需根据需要将这些策略的职责分配到应用程序、SOA 安全性服务和 SOA 组件，从而利用相应的机制来应用这些安全策略并加以执行。必须将安全需求封装或分解为将在 SOA 实现中以渗透方式工作的一组安全服务。例如，可以将用户身份验证的任务分配给 Authentication Security Service（所有应用程序都能够访问此服务并与之进行交互）。与此相对，可以配置企业服务总线（Enterprise Service Bus，ESB）来按应用程序限制对特定消息的访问。（第 2 部分将提供更多的相关细节。）
SOA 安全服务必须遵循相同的常规 SOA 原则、即松散偶合、模块化、封装、重用和可组合性，以获得必要的灵活性，帮助确保信息系统能够跟上业务设计中变化的速度，并成为实现更为完善的组织总体安 全性的变更驱动因素。这就要求从传统的静态安全模型转向动态模型，以跟上 SOA 体系结构中更快的变更速度。
除了内部安全性方法外，还必须同时保留基于风险管理的方法：从第 3 步中，可以看到有些数据的安全要求比其他数据高，有些应用程序比其他应用程序更为开放，如此等等。因此，不要均按照同样的标准处理所有消息和应用程序，否 则就可能对整个系统造成不必要的安全负担，从而影响系统的性能和可用性。总体风险管理战略中必须包含将安全需求与系统的总体可用性进行权衡的内容。
Gary McGraw 撰写的非常实用的书籍（请参见参考资料）详细说明了用于帮助创建风险管理框架（Risk-Management Framework，RMF）的包含五个部分的流程。从本质上说，您必须做到以下几点：
"了解业务上下文。
"确定业务和技术风险。
"对风险进行综合与分级。
"定义风险缓和战略。
"进行补救并验证结果。
例如，通过了解供应商竞标系统的业务上下文，可以发现尽管每个供应商都应该能够访问自己的信息，但查看其他供应商的信息却并不合适。此数据仅能在业务上下文中进行分类，而不能使用简单的层次结构模型（如第 3 步中的模型）进行分类。
第 5 步 定义内部和外部参与者
了 解了这些方法后，就该进行第 5 步了。在第 5 步中，SOA 安全团队将确定 SOA 安全参与者并进行相应的划分工作。参与者分为两类：外部和内部。外部政策制定者和治理机构（如 North American Electric Reliability Corporation (NERC)）可能提供了具有广泛安全影响的特定网络完全性标准，如关键基础设施保护（Critical Infrastructure Protection，CIP）需求等。
CIP 涵盖的领域非常广泛，如安全管理控制 (Security Management Controls) (CIP-003-1)、电子安全范围 (Electronic Security Perimeter) (CIP-005-1)、关键网络资产的物理安全 (Physical Security of Critical Cyber Assets) (CIP-006-1)、系统安全管理 (Systems Security Management) (CIP-007-1)、事故报告与响应计划 (Incident Reporting and Response Planning) (CIP-008-1) 及关键网络资产的恢复计划 (Recovery Plans for Critical Cyber Assets) (CIP-009-1)。所有这些标准都有自己的一组特定需求，会对总体 SOA 安全实现造成影响。
而且，内部安全需求（经常采用安全标准操作流程（Security Standard Operating Procedure，SOP）的形式编写）可回答谁、什么、何地、何时 及如何 这样的安全问题。谁能够何时何地访问什么，以及如何进行、持续时间多长？对于很多组织而言，此信息随着时间不断地发展，缺乏组织性和一致性；SOA 实现经常需要投入相当大的精力提供系统文档，以准确地反映组织的安全策略。
第 6 步 确定和使用正确的工具进行需求收集
在 第 6 步中，开始收集需求前，务必选择正确的工具，以便团队进行协作和方便地记录 SOA 安全需求和创建 SOA 安全模型。正确的需求与分析工具将帮助团队了解问题领域、捕获和管理不断发展的需求、建模用户交互、在整个项目生命周期中包含参与者反馈，而最为重要的是 进行协作。
良好的安全需求与分析实践将极大地减少系统安全风险。IBM? Rational? 需求与分析工具非常适合用于了解和表示参与者需求、指导和协调客户和业务需求的收集和验证工作、记录和组织系统的需求及向整个团队说明相关需求。我自己在 使用 IBM Rational RequisitePro?、WebSphere? Business Modeler 和 Rational Software Architect，建议大家也使用这些工具。
第 7 步 遵循 SOA 安全实现的 SDLC 流程
考虑到所必须收集的海量信息、必须编写的体系结构构件的数量以及将构造的特定 SOA 安全服务，SOA 安全团队应该遵循软件开发生命周期（Software Development Life Cycle，SDLC）的标准步骤：
1.确定安全需求和约束
2.得出和收集安全需求
3.创建安全体系结构设计
4.形成详细的安全 SOA 设计文档
5.实现 SOA（包括 SOA 治理）
6.测试
7.部署
8.维护
乍看之下，这些步骤可能非常明显，但安全团队很少采用 SDLC 流程。他们不习惯坐在房间里讨论相关工作和编写详细需求、设计安全抽象设计，以及创建详尽测试用例来验证系统是否具有可靠的安全性。（抽象设计和测试用例将在本系列的第 2 部分和第 3 部分进行讨论。）
团 队开始设计解决方案前，必须对需求进行收集。对于安全实现，既有显式需求，也有隐式需求。对于显式需求，一个很好的着手点就是按照第 5 步中所示收集每个参与者的需求。而对于隐式需求，最好使用安全框架，如保密性、完整性和可靠性（Confidentiality, Integrity, and Accountability，CIA）三部曲，以便在其中列出所有安全系统的具体需求。CIA 三部曲是广泛使用的信息保证（Information Assurance，IA）模型，此模型将保密性、完整性和可用性定义为所有信息系统的基础安全特征。
团队应该考虑此 SOA 实现将如何确保系统保密性（即数据保密），并构建清楚的流程图，以详细说明如何保证仅由目标授权接收方、个人、流程或设备访问传输中的消息。将消息泄漏给 非授权实体（如使用非授权网络探查的恶意用户）就违反了保密性，SOA 实现必须指定将在何种情况下在整个系统中使用加密技术（存储和传输保密信息的方法）。
与此类似，SOA 安全模型要求提供完整性（确保消息不会被更改）。SOA 安全负责确保信息在从原始位置传输到接收方的过程中不会被更改（数据完整性），并负责保证该信息的发送方是预期的发送方（来源完整性）且接收方是预期的接 收方（接收方完整性）。在预期接收方收到信息前，如果数据被有意或意外地更改或破坏，数据完整性就遭到了破坏。如果代理冒充发送方身份并向接收方提供不正 确的信息，则来源完整性就遭到了破坏。数据签名和哈希算法是用于提供数据完整性的机制。
另外，授权用户对数据服务 器的及时可靠访问（可用性）也是一项 SOA 安全需求：SOA 实现必须确保信息和资源在需要时可用，这意味着资源的提供速度应该足够满足较大的系统执行其预期任务所需的速度。当然可能在保密性和完整性得到保护的情况 下，入侵者仍然可能导致资源在需要时可用性降低，或根本不可用。具体来说，当 ESB 之类的 SOA 系统组件负责"代理消息"时，必须在 SOA 安全需求文档中详细说明高可用性协议、完全冗余网络体系结构和系统硬件，不要存在任何单点故障，从而保证系统的可靠性和稳健性。SOA 安全团队负责全面地表示这些区域，并确保记录了相应的用例（且能充分说明特定的需求）。
第 8 步 找出现有模型并从中吸取经验教训
SOA 安全需求团队花时间确定了所有需求后，团队成员会发现没有任何第三方工具能满足其全部需求。他们必须自己编写 SOA 安全服务来满足特定需求。比完全闭门造车好得多的做法是，对现有的模型进行分析，在团队开始抽象设计阶段前了解已经开发的内容。在此步骤（第 8 步）中，我们建议参考 Intelligrid 的以下模型（请参见参考资料）。可以在其中看到常用安全实用工具服务的列表，可能需要在 SOA 安全实现中提供这些服务。我将在下一篇文章中对这些服务进行更为详细的说明，但为了方便起见，我在此将其列出供参考：
"Audit Common Service
"Authorization Service for Access Control
"Confidentiality Service
"Credential Conversion Service
"Credential Renewal Service
"Delegation Service
"Firewall Traversal Service
"Identity Establishment Service
"Identity Mapping Service
"Information Integrity Service
"Inter-Domain Security Service
"Non-repudiation Service
"Path Routing and QoS Service
"Security Policy Service
"Policy Exchange Service
"Privacy Service
"Profile Service (User Profile Service)
"Quality of Identity Service
"Security Against Denial of Service (DoS)
"Security Assurance Management Service
"Security Protocol Mapping Service
"Security Service Availability Discovery Service
"Single Sign-on Service
"Trust Establishment Service
您可能并不需要其中的全部服务。SOA security 团队必须将需求映射到每个服务，然后为需要的所有服务创建 SOA 安全模型，以满足第 7 步中确定的所有需求。
第 9 步 熟悉 WS-Security 标准
完成此流程后，就收集了足够的信息可进行第 9 步了，即分析 WS-Security 标准，确定哪个标准适用于您的特定 SOA 安全实现。图 1 列出了需要参考的所有 WS-Security 标准。
图 1. WS-Security 标准
随着更为详细的模型的出现，必须熟悉组成 WS-Security 的各种 SOA 安全标准，并了解它们如何彼此相关以及其与 SOA 安全模型需求的关系。这些安全标准将用于构造整个 SOA 实现中的安全消息。
第 10 步 为第三方供应商制定标准
最 后，在第 10 步中，SOA 安全团队将负责为第三方供应商创建一组标准和应用程序编程接口（Application Program Interface，API）。SOA 的一个主要卖点是，系统将利用其开放性访问第三方供应商提供的服务。每个供应商必须熟悉 SOA 实现安全标准，并清楚地知道服务将如何与 SOA 实现的安全服务进行交互。
在整个过程中，必须维护详细的安全术语表，以确保所形成的所有文档采用相同的术语和定义。我建议从 Oasis Security Services TC Glossary 着手。应该与所有供应商共享此术语表，以确保所有人都采用相同的术语。
总结
在本文中，我们了解了常见 SOA 安全路线图的 10 个步骤：
"选择正确的团队。
"制定详细的项目计划。
"维护 SOA 支持安全决策表
"使用"内部安全性"和风险管理框架方法创建初步草案。
"定义内部和外部参与者。
"确定和使用正确的工具进行需求收集。
"遵循 SOA 安全实现的 SDLC 流程。
"找出现有模型并从中吸取经验教训。
"熟悉 WS-Security 标准。
"为第三方供应商制定标准。
如果遵循所有这些步骤，就在 SOA 安全性方面有了一个好的开头。
关注这个包括三部分的系列文章的后续部分，了解 SOA 安全团队进行成功 SOA 安全性实现所需的主要项目：路线图（第 1 部分）、抽象设计（第 2 部分）以及测试用例（第 3 部分）。
1 SOA安全性特点
1.1 跨技术、身份和管理边界的身份转换和传播
一套完整的业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维 护，这要求必须在SOA架构范围内建立统一的信任体系，使得请求者（人或程序）能够在服务间自由流动，系统能够自动地将请求者身份随着边界的不同而转换。
1.2 与合作伙伴建立信任
借助Web服务的强大能力，企业往往需要与合作伙伴建立紧密地服务和数据交换，发挥各自的优势来共同组成一个完整的一站式服务。比如一个旅行服务系统，机 票订购由专门的机票代理公司提供，旅游线路设计和行程服务则由旅行社负责，而食宿则由当地旅店提供。为了保证客户信息能够在多个系统安全完整地流动，并及 时地反映客户实时的旅行状态，必须在企业与合作伙伴之间建立可靠、安全的信任关系。
1.3 跨多个应用程序统一、重用和共享公共安全性
SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。每个应用系统可以使用共享安全组件，比如CA认证中心、信道加密方式和SOA安全网关等。此外，统一的安全标准遵从对于SOA整体安全性而言至关重要。
1.4 政府和行业规范要求的可追究性和可跟踪性
在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护，同时可能还需要用安全的方式在一定时期内保存敏感信息。在启用验证、审核和许可之前，必须保证 消息源的完整性（如通过公证服务）。消息的完整性和保密性可以通过对敏感信息进行加密和数字签名来实现。完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保存保护的内容以遵守政府规章制度和业界最佳实践的需要。企业需要对其提供的服务进行担保，确保服务 仅执行其公开申明的操作，同时有义务为用户提供足够的安全保障。因此，企业必须保存系统操作记录，以此来跟踪其用户或消息，也就是说企业必须具有很强的服 务审计能力。
1.5SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互
身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问 Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器 的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁（大多数情况下，这些请求被人恶意利用和操纵）将是SOA安全防御的一项 重要课题。
2 SOA面临的安全挑战
2.1 XML通信协议消耗大量带宽，引发安全问题
与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。
由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很 容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所"淹没"，结果可能导致拒绝式攻击从而损害系统的正常功 能。
为了解决这类问题，市场上已出现了专门的XML 。利用基于64位平台架构的语法分析器，该设备可以用来加速XML/SOAP的解析、XML模式的确 认、XPath的处理以及 XSLT的功能转换。据公开的产品测试报告称，这种XML 能够达到每秒处理1万多条XML消息的能力。
2.2 基于XML的服务间通信易受到监听和窃取
由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进 行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和Web服务策略（WS-Policy）是专门用来解决这个问题的两个标准；通过消息安全，可以保证Web服务环境中交换 的XML消息的完整性和保密性，Web服务安全（Web Service Security，WSS）和安全声明标记语言（Security Assertion Markup Language，SAML）则用来解决这方面的问题。
目前主要的XML安全标准包括：XML加密、XML签名语法和处理、数字签名和XML密钥管理规范（XML Key Management Specification，XKMS）等。值得一提的是，现有的XML安全标准已经可以实现对XML文档进行有选择的签名处理，而这在以前是不可能做到的，要么整个文档被签名，要么根本不签名。
下面我将重点介绍XML加密和XML签名。它们已经由W3C发布为标准，可以用来把安全加入到基于XML的数据中去。
XML加密是用来把原始的XML数据通过密码依次加密，从而让数据能够在请求者和服务端之间以一种模糊的方式传输。密码仅由请求者和服务端掌握，这就能保证即使是在传输的过程中有数据被截取，窃取者也只能看到一堆毫无意义的字符串，从而防止敏感信息泄露。
另一方面，XML签名则用来防止XML文档的被非法篡改。通过使用XML签名，一个服务供应商可以提供给任何的服务消费者--以一种确定的方式来检测XML的有效负载是否相对于它原来的方式或者原来的状态发生了改变。
需要特别指出的是，XML加密和XML签名适用于任何的XML类型的文档。意识到这一点是很重要的，因为它们不仅仅可以用来保护服务交互的有效负载的交 换，同样的它们也可以用来保护类似WSDL这种契约，这些文档也是基于XML的，并且也是SOA中的一个重要组成部分。
同样，市场上也出现了专门解决这类问题的产品，称为XML安全网关。类似传统的防火墙， 企业可以把它部署在网络边界上，从而对所有进出的XML数据进行保护。XML安全网关遵循包括XML和WS-Security在内的行业标准，对XML数 据进行验证、加密、签名以及认证，来提供安全的基于XML的Web服务通信。此外，它还可提供防火墙功能和访问控制功能。有些产品还可以与网络管理软件集 成，帮助企业降低IT管理成本，并解决依从性需求。
2.3 缺乏良好的编程模型严重威胁企业安全
对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则而构造实现的服务、应用程序以及跨组织操作所具有的松耦合特性，这种环境往往更加容易 现有安全实现的弱点或局限性，因此缺乏良好的编程模型将严重威胁Web服务的安全。
仅采用边界防御（如防火墙和路由器） 来保护企业信息安全是不够的，因为企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态的信任关系。因此，企业需要灵活的、可自定义的 基础设施，以适应新要求和规章制度。要提供这种灵活性，不应简单的指望将策略生搬硬套到基础设施中，应该在服务的开发过程中建立和遵循由策略驱动的编程模 型。SOA 编程模型可以确保每个服务调用都符合对请求者和服务端点均有效的安全策略。
从安全的角度来看，编程模型负责对于谁负责实现安全策略（如基础设施或应用程序）以及需要让请求者得到此信息的哪一部分等做出决策。另一方面要考虑的是调 用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性。最后，在实现安全解决方案时，还应该考虑安全工程--用于构建安全应用程序的工 程方法。
3 其它SOA安全保护方法
3.1 应用程序代理
一种非常有效的保护核心系统的方法是避免让任何人直接访问提供服务的平台，可以通过为SOA中的Web服务部署一个代理做到这一点。一个受保护的代理可以 代表实际的Web服务接收所有Web服务请求，并对其做出响应，从而保护Web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础 架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对Web服务请求的身份验证和授权，而不是每次用户想调用Web服务时，就在网络上使用大量 消息对该用户进行身份验证和授权。代理还可以在消息中插入了身份验证和授权SAML断言，从而消除了Web服务请求者直接查询核心安全性系统的风险。
3.2 契约管理
作为主要的SOA 管理问题之一，契约管理在SOA安全性中起着举足轻重的作用。所谓契约就是用于管理Web服务使用情况的一组规则。例如，某个契约可能会规定某个特定用户 有权每天调用某个特定的Web服务五百次，而且在调用过程中，服务水平必须满足特定的参数，比如所有请求都必须在2秒钟内响应。
在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而被误用。例如，SOA拦截器把Web服务请求和响应数据发送给SOA安全管理 中心，然后该SOA安全管理中心确定该请求是否满足契约。如果某个安全性行为（比如拒绝式服务攻击）使Web服务的响应速度降低到契约规定的服务水平以 下，SOA安全管理中心就会警告系统管理人员有问题存在，甚至可以根据预设的策略自动采取必要的措施，比如对某些攻击请求进行阻断或限制次重要服务的使用 频率等。尽管一次足够严重的攻击可以导致整个网络崩溃，但是合理的契约管理至少可以使我们得到及时的安全问题通知，从而有效地采取行动。
总之，为了应对SOA的安全挑战，需要在企业范围内（还应包括其合作伙伴）建立一套统一的安全基础设施，通过对请求者进行身份验证和对其授予服务访问权、 基于基本信任模型跨Web服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容，安全基础设施帮助企业形成一套完整的保护基于组件和服务的 SOA环境的结构。
所有SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。而基于 Web 服务安全规范的Web服务安全模型和方法有助于解决保护面向服务的应用程序的难题。
SOA安全标准面临新挑战
面向服务的体系结构（SOA）使安全决策变得复杂，原因在于，作为最终应用的许多移动部件，必须在模块程序中集成。因此，IT和安全人员在SOA计划实施之初就需要密切协调，才能保证其实现机密性、完整性和可用性。
对于一些组织机构和IT管理者而言，利用分布式计算，如SOA和集成式Web服务，意味着对设计的复杂性和安全性要求更高。
随着计算进一步趋向分布式，以及新型威胁和有组织的互联网犯罪的增多，开放式标准在制定和更好地利用有效的安全措施等方面起着重大的作用。除此之 外，如何在管理层次以及安全对策、程序和相关工作中利用这些标准，来提高内部员工的安全意识、促进业务伙伴访问企业服务、监测网络所面临的威胁也是至关重 要的。
本文探讨了SOA面临的安全挑战，安全标准制定取得的进展，以及安全标准在扩展时可能遇到的问题。
SOA使安全决策难度大
面向服务的体系结构从本质上说是一种由元数据和XML（可扩展的标记语言）一类的标准数据结构协议生成的应用程序。SOA所面临的安全问题与应用其他任何分布式系统时所遇到的安全问题是相同的，即如何确保机密性、完整性和可用性。
SOA虽然在某些方面使安全简化，但是在其他方面却使安全问题变得复杂。业界人士认为，由于在基础设施中使用了XML一类的数据结构通用协议、IP通信协 议和通用操作系统，因此SOA有助于简化某些安全决策；但在模块程序中，由于许多移动部件作为最终应用要集成在一起，因此使安全决策变得复杂。
启动开放性安全标准
分布式系统安全业务的开放性标准，如SAML（安全断言标记语言）、XACML（可扩展访问控制标记语言）和Web服务安全标准，已被OASIS（结构化信息标准促进组织）所采用。业界认为，新的SOA和分布式系统标准能够有效提升安全性。
可用性和可复用性要求采用更新、更灵活的标准，即用于联合等同的SAML、精确访问控制的XACML、性能先进的SOA应用的WS安全标准。据 称，SAML现在包括若干基于实时应用环境的新文档，并将融进更多的新文档。目前，推广应用SAML的成功者为数不少。某些政府也正在推广应用，其用户多 达数千万。
Web服务安全标准的制定工作已经基本完成。可以预计的是，如果用户进行相对简单的通用数据存取，他们将可以顺利完成这一过程。如果Web服务安全标准复 杂或者实施起来比较困难，那么用户可能就会遇到某些互操作性的问题。不过，等同联合的交替模块（包括Web服务联合和开放ID）能够解决这些问题。
改编新标准引争议
OASIS技术委员会正在编写一套扩展式Web服务安全对策样本。这套对策比较复杂，并且还没有在实际中应用过。
OASIS数字签名业务扩展（DSS-X）技术委员会正在制定标准的XML框架，用来管理机构之间的身份信息和系统资源及其分配。业界人士认为，XML标 准框架有利于管理身份信息和系统资源。不过现在的问题是必须推出和测试能互操作的产品，并部署和测试实时应用环境。
尽管为SOA指定的各种安全标准的制定还存在着种种障碍，但是把这些标准融入SOA以及将其大量应用于工业进程的工作正在进行中。
互操作性问题
Web服务常常作为应用互操作性的理想解决方案， 而且对于与平台、销售商和编程语言无关的综合应用也是非常有效的，它们不受互操作性问题的影响。因此，大多数互操作性问题并非来自于成熟稳定的Web服务 规范，而是来自各种Web服务规范的扩展和Web服务安全标准的一系列扩展。随着这些标准的扩展，销售商必须选择所要支持的规范草案，开发商有时需要协商 解决不同规范之间的不兼容问题。
SOA倾向于模块化设计
业界认为，SOA即使只作为实现模块设计的手段，其优点也非常突出。用SOA设计的模块就是将应用程序的不同功能单元（称为服务）通过这些服务之间定义良 好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样系统中的服务可以采用一种统一和通用的方式进行交互。这是一种松散藕合的 接口方式，其易损性比内部数据结构之间基于代码的交互作用低得多。其优点与面向对象的设计非常相似，甚至更胜一筹。
SOA内部模块化并不会引发安全问题，因为它不会将新的功能 给其他系统或外部机构。但是，代码库的重复使用和开放可存取性却存在着危险性，即通过与用 户和供应链上的合作伙伴所建立的业务接口，可能 新的服务功能。当这种情况发生时，预定的服务供给可能中断，给企图扩展权限和进行服务攻击不怀好意者留 下路径。
任何一种安全标准或所支持的标准总数，都不足以评估SOA或Web服务平台的效能。因此，对安全标准的支持并不就意味着安全。在许多情况下，安全标准只是定义了让各种服务模式能彼此互操作的框架，实际上它并不等于任何一种特殊服务模式都能良好运行。
即使完全按照Web服务安全实施办法，服务仍可能因为使用弱密码、受简单的密约管理，或者数据库未加密而出现不安全的情况。应当说安全是一种实际应用状态，而不仅仅是一系列所支持的标准。
SOA通过分布式系统的开放性标准以及模块化设计来提供安全的Web服务。
MSN视频对话存在堆溢出漏洞
受影响系统：MicrosoftMSNMessenger7.5、Microsoft MSN Messenger 7.0、Microsoft MSN Messenger 6.2和Microsoft Windows Messenger 8.0。
描述：MSNMessenger是微软发布的非常流行的即时通信聊天工具。MSNVIDEO处理用户请求时存在缓冲区溢出漏洞，远程攻击者可能利用此漏洞控制用户系统。
厂商补丁：Microsoft已经为此发布了一个安全公告（MS07-054）以及相应补丁:
MS07-054：VulnerabilityinMSNMessenger and Windows Live Messenger Could Allow Remote Code Execution (942099) 。
链接：technet/security/Bulletin/MS07-054.mspx?pf=true
动态
●Juniper推UAC2.1方案Juniper网络公司近日推出统一访问控制UAC 2.1安全解决方案。这项解决方案提供了先进的网络保护、应用可见性和监控、简化网络访问控制安装，有效遵循相关规定，同时降低风险，满足不断发展的访问 控制及高性能业务的安全要求。
●金山捕获新病毒金山公司近日发现新病毒，该病毒的作者借病毒来发布寻人启示，自行修改文件夹选项，同时会关闭任务管理器，如果不隐藏运行，则不断弹出恶意代码。为此，金山毒霸反病毒应急中心建议用户及时更新病毒库。
●CheckPoint推网关新功能Check Point软件技术有限公司近日宣布,其企业安全网关将Check Point的SmartDefense?与入侵防御技术相整合，可以阻止企业员工使用个人VoIP应用程序Skype v3.5，协助企业更好地管理，降低因其员工使用自行下载及自用程序所带来的安全风险。
垃圾邮件利用PDF漏洞攻击反病毒厂商F-secure近日发现一种利用最近一个AcrobatReader处理PDF的漏洞进行攻击的垃圾邮件。 这种垃圾邮件通常以"你的信用记录"、"个人财务信息"之类的标题作为主题，内容空白，并携带一个文件名为Report.pdf的文档，这个文档如果不小 心被用户开启后，会从一个位于马来西亚的服务器上下载并安装恶意软件。
●趋势科技将收购Provilla趋势科技近日宣布将收购内容安全厂商Provilla。Provilla是领先的数据泄漏防护产品厂商，主要生产基于指 纹识别的数据泄漏防护智能终端方案。收购完成后，Provilla将作为趋势科技美国分公司下属的子公司存在，并为趋势科技的多层内容安全方案提供支持。
●RSA推SecurIDSoftwareToken 安全厂商RSA近日推出了支持Symbian OS平台的SecurID Software Token产品，Symbian OS是当前流行的移动电话操作系统，而SecurID Software Token属于双因素身份验证产品，这表明了RSA的软件Token产品再次扩展到更大范围的移动平台上，同时为企业使用RSA软件Token降低了成本和门槛。
本文来自： 国际信息安全学习联盟
SOA项目中十步搞定大型SOA应用程序的安全
十步搞定大型SOA应用程序的安全
第 1 步 选择正确的团队
将大型关键基础设施应用程序迁移到 SOA 的工作令人望而生畏。对其进行保护甚至更为困难，经常需要采用全新的视角对其加以认识--甚至可能需要一组全新的安全人员进行相关工作。大部分安全团队在 SOA 方面甚至编程方面的培训极少。安全权威机构常用的方法是，只管发出要求并希望组织能够加以遵循。因此，第 1 步（这经常是最难的部分）是确保拥有正确的团队。
团队应该有个负责人，该负责人应该具有安全性和软件体系结构方面的知识，最好也能了解 SOA 的相关知识。与企业架构师类似，安全企业架构师（Security Enterprise Architect，SEA）将负责创建总体 SOA 安全模型，以便在每个粒度级别集成所有不同的安全性需求。SEA 将进入 SOA 治理委员会，与企业架构师（Enterprise Architect，EA）一起确保所有 SOA 实现都符合安全性需求的相关要求，并对负责创建整个流程中所需的构件的安全业务分析人员（Security Business Analyst，SBA）和安全系统工程师（Security Systems Engineers，SSE）团队进行指导。SEA 还将负责与编写安全性服务代码的程序员及在部署系统前对其进行测试的安全性系统测试人员合作。
第 2 步 创建详细项目计划
对于大型 SOA 系统，第 2 步要求高层管理了解，将无法通过改进新的 SOA 将其纳入旧安全模型中：这样做根本行不通。如果从最开始的重点就是传统安全机制（如防火墙、入侵检测系统和安全监视），这将完全与 SOA 安全实现不沾边。您将负责通过制定详细的项目计划和预算，清楚地说明和反映 SOA 安全实现所必需的东西，确保每个人都对此心里有底。
您必需让大家认识到，到 SOA 模型的任何转换都会涉及到固有的安全矛盾：系统的 SOA 特征越明显，其安全性越差。通过面向服务的建模和分析技术将当前系统转换为 SOA 的过程要求形成业务设计的相关文档。通过使用可将业务设计与信息系统相关的正式语言，通常仅能说明矛盾、低效而复杂的非 SOA 系统的情况。不过，这个复杂性会掩盖住大部分问题所在，从而使寻找机会破坏企业系统的人难于找到这些脆弱的环节。对这些系统进行分解并启用 SOA 后，恶意用户所面对的体系结构就会简单一些，从而更便于进行破坏。
SOA 支持者可能对此会加以否认，但负责保护系统安全的人知道，具有集中控制点且启用了 Web 的开放系统本身安全性就较差，而需要更为反应灵敏而灵活便利的方法。没有办法绕开这个问题，项目规划人员（经常会向 SOA 安全性方面分配一组适当的任务）必须记住，SOA 安全性需要详细的项目规划和预算，为安全性团队分配必要的时间，以便分析和了解 SOA 实现所带来的新挑战。
第 3 步 维护 SOA 支持安全决策表
通过创建 SOA 支持安全决策表正式记录抽象 SOA 安全性动态因素。在此表中，业务参与者将应用程序分为三类，包括：
"将启用 SOA 支持的应用程序
"必须与启用 SOA 支持的应用程序交互的应用程序
"将不启用 SOA 支持，也不必与启用 SOA 支持的应用程序交互的应用程序
也可以对这些不同的类别进行颜色编码。例如，我将第一个类别中的项目设置为红色，第二个类别中的项目设置为橙色，而将第三个类别的项目设置为黄色。
安全团队然后将进一步把应用程序划分到各个安全性类别，如高、中和低。例如，处理市场和分类信息的应用程序或服务将属于高安全性类别，而仅仅访问公开数据的应用程序或服务可以归入最低安全性类别。
表 1 显示了 SOA 支持安全决策表的示例。
表 1. SOA 支持安全决策表
安全性（高） 安全性（中） 安全性（低）
红色 36 12 11
橙色 12 5 3
黄色 6 0 6
在表中可以看到 12 个应用程序将不启用 SOA 支持（标为黄色的应用程序）；因此，此工作将需要异类安全模型，即一个为以 SOA 为中心的系统部分提供安全性，另一个为非 SOA 区域提供安全性。通常，非 SOA 模型依赖于基于边界的安全性，其中的信息资产通过防火墙层进行保护。
对于以 SOA 为中心的安全性，要首先按照第 4 步中所述创建风险管理框架。
第 4 步 使用风险评估框架方法创建初步草案
第 4 步将使用"内部安全性"(security from within) 方法。内部安全性 指安全性考虑与 SOA 实现中的所有活动对应。必须检查设计文档，了解必须在哪些地方作出安全决策并确定执行这些决策的安全控制点，从而了解 SOA 实现将如何工作。
需根据需要将这些策略的职责分配到应用程序、SOA 安全性服务和 SOA 组件，从而利用相应的机制来应用这些安全策略并加以执行。必须将安全需求封装或分解为将在 SOA 实现中以渗透方式工作的一组安全服务。例如，可以将用户身份验证的任务分配给 Authentication Security Service（所有应用程序都能够访问此服务并与之进行交互）。与此相对，可以配置企业服务总线（Enterprise Service Bus，ESB）来按应用程序限制对特定消息的访问。（第 2 部分将提供更多的相关细节。）
SOA 安全服务必须遵循相同的常规 SOA 原则、即松散偶合、模块化、封装、重用和可组合性，以获得必要的灵活性，帮助确保信息系统能够跟上业务设计中变化的速度，并成为实现更为完善的组织总体安 全性的变更驱动因素。这就要求从传统的静态安全模型转向动态模型，以跟上 SOA 体系结构中更快的变更速度。
除了内部安全性方法外，还必须同时保留基于风险管理的方法：从第 3 步中，可以看到有些数据的安全要求比其他数据高，有些应用程序比其他应用程序更为开放，如此等等。因此，不要均按照同样的标准处理所有消息和应用程序，否 则就可能对整个系统造成不必要的安全负担，从而影响系统的性能和可用性。总体风险管理战略中必须包含将安全需求与系统的总体可用性进行权衡的内容。
Gary McGraw 撰写的非常实用的书籍（请参见参考资料）详细说明了用于帮助创建风险管理框架（Risk-Management Framework，RMF）的包含五个部分的流程。从本质上说，您必须做到以下几点：
"了解业务上下文。
"确定业务和技术风险。
"对风险进行综合与分级。
"定义风险缓和战略。
"进行补救并验证结果。
例如，通过了解供应商竞标系统的业务上下文，可以发现尽管每个供应商都应该能够访问自己的信息，但查看其他供应商的信息却并不合适。此数据仅能在业务上下文中进行分类，而不能使用简单的层次结构模型（如第 3 步中的模型）进行分类。
第 5 步 定义内部和外部参与者
了 解了这些方法后，就该进行第 5 步了。在第 5 步中，SOA 安全团队将确定 SOA 安全参与者并进行相应的划分工作。参与者分为两类：外部和内部。外部政策制定者和治理机构（如 North American Electric Reliability Corporation (NERC)）可能提供了具有广泛安全影响的特定网络完全性标准，如关键基础设施保护（Critical Infrastructure Protection，CIP）需求等。
CIP 涵盖的领域非常广泛，如安全管理控制 (Security Management Controls) (CIP-003-1)、电子安全范围 (Electronic Security Perimeter) (CIP-005-1)、关键网络资产的物理安全 (Physical Security of Critical Cyber Assets) (CIP-006-1)、系统安全管理 (Systems Security Management) (CIP-007-1)、事故报告与响应计划 (Incident Reporting and Response Planning) (CIP-008-1) 及关键网络资产的恢复计划 (Recovery Plans for Critical Cyber Assets) (CIP-009-1)。所有这些标准都有自己的一组特定需求，会对总体 SOA 安全实现造成影响。
而且，内部安全需求（经常采用安全标准操作流程（Security Standard Operating Procedure，SOP）的形式编写）可回答谁、什么、何地、何时 及如何 这样的安全问题。谁能够何时何地访问什么，以及如何进行、持续时间多长？对于很多组织而言，此信息随着时间不断地发展，缺乏组织性和一致性；SOA 实现经常需要投入相当大的精力提供系统文档，以准确地反映组织的安全策略。
第 6 步 确定和使用正确的工具进行需求收集
在 第 6 步中，开始收集需求前，务必选择正确的工具，以便团队进行协作和方便地记录 SOA 安全需求和创建 SOA 安全模型。正确的需求与分析工具将帮助团队了解问题领域、捕获和管理不断发展的需求、建模用户交互、在整个项目生命周期中包含参与者反馈，而最为重要的是 进行协作。
良好的安全需求与分析实践将极大地减少系统安全风险。IBM? Rational? 需求与分析工具非常适合用于了解和表示参与者需求、指导和协调客户和业务需求的收集和验证工作、记录和组织系统的需求及向整个团队说明相关需求。我自己在 使用 IBM Rational RequisitePro?、WebSphere? Business Modeler 和 Rational Software Architect，建议大家也使用这些工具。
第 7 步 遵循 SOA 安全实现的 SDLC 流程
考虑到所必须收集的海量信息、必须编写的体系结构构件的数量以及将构造的特定 SOA 安全服务，SOA 安全团队应该遵循软件开发生命周期（Software Development Life Cycle，SDLC）的标准步骤：
1.确定安全需求和约束
2.得出和收集安全需求
3.创建安全体系结构设计
4.形成详细的安全 SOA 设计文档
5.实现 SOA（包括 SOA 治理）
6.测试
7.部署
8.维护
乍看之下，这些步骤可能非常明显，但安全团队很少采用 SDLC 流程。他们不习惯坐在房间里讨论相关工作和编写详细需求、设计安全抽象设计，以及创建详尽测试用例来验证系统是否具有可靠的安全性。（抽象设计和测试用例将在本系列的第 2 部分和第 3 部分进行讨论。）
团 队开始设计解决方案前，必须对需求进行收集。对于安全实现，既有显式需求，也有隐式需求。对于显式需求，一个很好的着手点就是按照第 5 步中所示收集每个参与者的需求。而对于隐式需求，最好使用安全框架，如保密性、完整性和可靠性（Confidentiality, Integrity, and Accountability，CIA）三部曲，以便在其中列出所有安全系统的具体需求。CIA 三部曲是广泛使用的信息保证（Information Assurance，IA）模型，此模型将保密性、完整性和可用性定义为所有信息系统的基础安全特征。
团队应该考虑此 SOA 实现将如何确保系统保密性（即数据保密），并构建清楚的流程图，以详细说明如何保证仅由目标授权接收方、个人、流程或设备访问传输中的消息。将消息泄漏给 非授权实体（如使用非授权网络探查的恶意用户）就违反了保密性，SOA 实现必须指定将在何种情况下在整个系统中使用加密技术（存储和传输保密信息的方法）。
与此类似，SOA 安全模型要求提供完整性（确保消息不会被更改）。SOA 安全负责确保信息在从原始位置传输到接收方的过程中不会被更改（数据完整性），并负责保证该信息的发送方是预期的发送方（来源完整性）且接收方是预期的接 收方（接收方完整性）。在预期接收方收到信息前，如果数据被有意或意外地更改或破坏，数据完整性就遭到了破坏。如果代理冒充发送方身份并向接收方提供不正 确的信息，则来源完整性就遭到了破坏。数据签名和哈希算法是用于提供数据完整性的机制。
另外，授权用户对数据服务 器的及时可靠访问（可用性）也是一项 SOA 安全需求：SOA 实现必须确保信息和资源在需要时可用，这意味着资源的提供速度应该足够满足较大的系统执行其预期任务所需的速度。当然可能在保密性和完整性得到保护的情况 下，入侵者仍然可能导致资源在需要时可用性降低，或根本不可用。具体来说，当 ESB 之类的 SOA 系统组件负责"代理消息"时，必须在 SOA 安全需求文档中详细说明高可用性协议、完全冗余网络体系结构和系统硬件，不要存在任何单点故障，从而保证系统的可靠性和稳健性。SOA 安全团队负责全面地表示这些区域，并确保记录了相应的用例（且能充分说明特定的需求）。
第 8 步 找出现有模型并从中吸取经验教训
SOA 安全需求团队花时间确定了所有需求后，团队成员会发现没有任何第三方工具能满足其全部需求。他们必须自己编写 SOA 安全服务来满足特定需求。比完全闭门造车好得多的做法是，对现有的模型进行分析，在团队开始抽象设计阶段前了解已经开发的内容。在此步骤（第 8 步）中，我们建议参考 Intelligrid 的以下模型（请参见参考资料）。可以在其中看到常用安全实用工具服务的列表，可能需要在 SOA 安全实现中提供这些服务。我将在下一篇文章中对这些服务进行更为详细的说明，但为了方便起见，我在此将其列出供参考：
"Audit Common Service
"Authorization Service for Access Control
"Confidentiality Service
"Credential Conversion Service
"Credential Renewal Service
"Delegation Service
"Firewall Traversal Service
"Identity Establishment Service
"Identity Mapping Service
"Information Integrity Service
"Inter-Domain Security Service
"Non-repudiation Service
"Path Routing and QoS Service
"Security Policy Service
"Policy Exchange Service
"Privacy Service
"Profile Service (User Profile Service)
"Quality of Identity Service
"Security Against Denial of Service (DoS)
"Security Assurance Management Service
"Security Protocol Mapping Service
"Security Service Availability Discovery Service
"Single Sign-on Service
"Trust Establishment Service
您可能并不需要其中的全部服务。SOA security 团队必须将需求映射到每个服务，然后为需要的所有服务创建 SOA 安全模型，以满足第 7 步中确定的所有需求。
第 9 步 熟悉 WS-Security 标准
完成此流程后，就收集了足够的信息可进行第 9 步了，即分析 WS-Security 标准，确定哪个标准适用于您的特定 SOA 安全实现。图 1 列出了需要参考的所有 WS-Security 标准。
图 1. WS-Security 标准
随着更为详细的模型的出现，必须熟悉组成 WS-Security 的各种 SOA 安全标准，并了解它们如何彼此相关以及其与 SOA 安全模型需求的关系。这些安全标准将用于构造整个 SOA 实现中的安全消息。
第 10 步 为第三方供应商制定标准
最 后，在第 10 步中，SOA 安全团队将负责为第三方供应商创建一组标准和应用程序编程接口（Application Program Interface，API）。SOA 的一个主要卖点是，系统将利用其开放性访问第三方供应商提供的服务。每个供应商必须熟悉 SOA 实现安全标准，并清楚地知道服务将如何与 SOA 实现的安全服务进行交互。
在整个过程中，必须维护详细的安全术语表，以确保所形成的所有文档采用相同的术语和定义。我建议从 Oasis Security Services TC Glossary 着手。应该与所有供应商共享此术语表，以确保所有人都采用相同的术语。
总结
在本文中，我们了解了常见 SOA 安全路线图的 10 个步骤：
"选择正确的团队。
"制定详细的项目计划。
"维护 SOA 支持安全决策表
"使用"内部安全性"和风险管理框架方法创建初步草案。
"定义内部和外部参与者。
"确定和使用正确的工具进行需求收集。
"遵循 SOA 安全实现的 SDLC 流程。
"找出现有模型并从中吸取经验教训。
"熟悉 WS-Security 标准。
"为第三方供应商制定标准。
如果遵循所有这些步骤，就在 SOA 安全性方面有了一个好的开头。
关注这个包括三部分的系列文章的后续部分，了解 SOA 安全团队进行成功 SOA 安全性实现所需的主要项目：路线图（第 1 部分）、抽象设计（第 2 部分）以及测试用例（第 3 部分）。
1 SOA安全性特点
1.1 跨技术、身份和管理边界的身份转换和传播
一套完整的业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维 护，这要求必须在SOA架构范围内建立统一的信任体系，使得请求者（人或程序）能够在服务间自由流动，系统能够自动地将请求者身份随着边界的不同而转换。
1.2 与合作伙伴建立信任
借助Web服务的强大能力，企业往往需要与合作伙伴建立紧密地服务和数据交换，发挥各自的优势来共同组成一个完整的一站式服务。比如一个旅行服务系统，机 票订购由专门的机票代理公司提供，旅游线路设计和行程服务则由旅行社负责，而食宿则由当地旅店提供。为了保证客户信息能够在多个系统安全完整地流动，并及 时地反映客户实时的旅行状态，必须在企业与合作伙伴之间建立可靠、安全的信任关系。
1.3 跨多个应用程序统一、重用和共享公共安全性
SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。每个应用系统可以使用共享安全组件，比如CA认证中心、信道加密方式和SOA安全网关等。此外，统一的安全标准遵从对于SOA整体安全性而言至关重要。
1.4 政府和行业规范要求的可追究性和可跟踪性
在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护，同时可能还需要用安全的方式在一定时期内保存敏感信息。在启用验证、审核和许可之前，必须保证 消息源的完整性（如通过公证服务）。消息的完整性和保密性可以通过对敏感信息进行加密和数字签名来实现。完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保存保护的内容以遵守政府规章制度和业界最佳实践的需要。企业需要对其提供的服务进行担保，确保服务 仅执行其公开申明的操作，同时有义务为用户提供足够的安全保障。因此，企业必须保存系统操作记录，以此来跟踪其用户或消息，也就是说企业必须具有很强的服 务审计能力。
1.5SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互
身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问 Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器 的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁（大多数情况下，这些请求被人恶意利用和操纵）将是SOA安全防御的一项 重要课题。
2 SOA面临的安全挑战
2.1 XML通信协议消耗大量带宽，引发安全问题
与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。
由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很 容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所"淹没"，结果可能导致拒绝式攻击从而损害系统的正常功 能。
为了解决这类问题，市场上已出现了专门的XML 。利用基于64位平台架构的语法分析器，该设备可以用来加速XML/SOAP的解析、XML模式的确 认、XPath的处理以及 XSLT的功能转换。据公开的产品测试报告称，这种XML 能够达到每秒处理1万多条XML消息的能力。
2.2 基于XML的服务间通信易受到监听和窃取
由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进 行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和Web服务策略（WS-Policy）是专门用来解决这个问题的两个标准；通过消息安全，可以保证Web服务环境中交换 的XML消息的完整性和保密性，Web服务安全（Web Service Security，WSS）和安全声明标记语言（Security Assertion Markup Language，SAML）则用来解决这方面的问题。
目前主要的XML安全标准包括：XML加密、XML签名语法和处理、数字签名和XML密钥管理规范（XML Key Management Specification，XKMS）等。值得一提的是，现有的XML安全标准已经可以实现对XML文档进行有选择的签名处理，而这在以前是不可能做到的，要么整个文档被签名，要么根本不签名。
下面我将重点介绍XML加密和XML签名。它们已经由W3C发布为标准，可以用来把安全加入到基于XML的数据中去。
XML加密是用来把原始的XML数据通过密码依次加密，从而让数据能够在请求者和服务端之间以一种模糊的方式传输。密码仅由请求者和服务端掌握，这就能保证即使是在传输的过程中有数据被截取，窃取者也只能看到一堆毫无意义的字符串，从而防止敏感信息泄露。
另一方面，XML签名则用来防止XML文档的被非法篡改。通过使用XML签名，一个服务供应商可以提供给任何的服务消费者--以一种确定的方式来检测XML的有效负载是否相对于它原来的方式或者原来的状态发生了改变。
需要特别指出的是，XML加密和XML签名适用于任何的XML类型的文档。意识到这一点是很重要的，因为它们不仅仅可以用来保护服务交互的有效负载的交 换，同样的它们也可以用来保护类似WSDL这种契约，这些文档也是基于XML的，并且也是SOA中的一个重要组成部分。
同样，市场上也出现了专门解决这类问题的产品，称为XML安全网关。类似传统的防火墙， 企业可以把它部署在网络边界上，从而对所有进出的XML数据进行保护。XML安全网关遵循包括XML和WS-Security在内的行业标准，对XML数 据进行验证、加密、签名以及认证，来提供安全的基于XML的Web服务通信。此外，它还可提供防火墙功能和访问控制功能。有些产品还可以与网络管理软件集 成，帮助企业降低IT管理成本，并解决依从性需求。
2.3 缺乏良好的编程模型严重威胁企业安全
对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则而构造实现的服务、应用程序以及跨组织操作所具有的松耦合特性，这种环境往往更加容易 现有安全实现的弱点或局限性，因此缺乏良好的编程模型将严重威胁Web服务的安全。
仅采用边界防御（如防火墙和路由器） 来保护企业信息安全是不够的，因为企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态的信任关系。因此，企业需要灵活的、可自定义的 基础设施，以适应新要求和规章制度。要提供这种灵活性，不应简单的指望将策略生搬硬套到基础设施中，应该在服务的开发过程中建立和遵循由策略驱动的编程模 型。SOA 编程模型可以确保每个服务调用都符合对请求者和服务端点均有效的安全策略。
从安全的角度来看，编程模型负责对于谁负责实现安全策略（如基础设施或应用程序）以及需要让请求者得到此信息的哪一部分等做出决策。另一方面要考虑的是调 用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性。最后，在实现安全解决方案时，还应该考虑安全工程--用于构建安全应用程序的工 程方法。
3 其它SOA安全保护方法
3.1 应用程序代理
一种非常有效的保护核心系统的方法是避免让任何人直接访问提供服务的平台，可以通过为SOA中的Web服务部署一个代理做到这一点。一个受保护的代理可以 代表实际的Web服务接收所有Web服务请求，并对其做出响应，从而保护Web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础 架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对Web服务请求的身份验证和授权，而不是每次用户想调用Web服务时，就在网络上使用大量 消息对该用户进行身份验证和授权。代理还可以在消息中插入了身份验证和授权SAML断言，从而消除了Web服务请求者直接查询核心安全性系统的风险。
3.2 契约管理
作为主要的SOA 管理问题之一，契约管理在SOA安全性中起着举足轻重的作用。所谓契约就是用于管理Web服务使用情况的一组规则。例如，某个契约可能会规定某个特定用户 有权每天调用某个特定的Web服务五百次，而且在调用过程中，服务水平必须满足特定的参数，比如所有请求都必须在2秒钟内响应。
在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而被误用。例如，SOA拦截器把Web服务请求和响应数据发送给SOA安全管理 中心，然后该SOA安全管理中心确定该请求是否满足契约。如果某个安全性行为（比如拒绝式服务攻击）使Web服务的响应速度降低到契约规定的服务水平以 下，SOA安全管理中心就会警告系统管理人员有问题存在，甚至可以根据预设的策略自动采取必要的措施，比如对某些攻击请求进行阻断或限制次重要服务的使用 频率等。尽管一次足够严重的攻击可以导致整个网络崩溃，但是合理的契约管理至少可以使我们得到及时的安全问题通知，从而有效地采取行动。
总之，为了应对SOA的安全挑战，需要在企业范围内（还应包括其合作伙伴）建立一套统一的安全基础设施，通过对请求者进行身份验证和对其授予服务访问权、 基于基本信任模型跨Web服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容，安全基础设施帮助企业形成一套完整的保护基于组件和服务的 SOA环境的结构。
所有SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。而基于 Web 服务安全规范的Web服务安全模型和方法有助于解决保护面向服务的应用程序的难题。
SOA安全标准面临新挑战
面向服务的体系结构（SOA）使安全决策变得复杂，原因在于，作为最终应用的许多移动部件，必须在模块程序中集成。因此，IT和安全人员在SOA计划实施之初就需要密切协调，才能保证其实现机密性、完整性和可用性。
对于一些组织机构和IT管理者而言，利用分布式计算，如SOA和集成式Web服务，意味着对设计的复杂性和安全性要求更高。
随着计算进一步趋向分布式，以及新型威胁和有组织的互联网犯罪的增多，开放式标准在制定和更好地利用有效的安全措施等方面起着重大的作用。除此之 外，如何在管理层次以及安全对策、程序和相关工作中利用这些标准，来提高内部员工的安全意识、促进业务伙伴访问企业服务、监测网络所面临的威胁也是至关重 要的。
本文探讨了SOA面临的安全挑战，安全标准制定取得的进展，以及安全标准在扩展时可能遇到的问题。
SOA使安全决策难度大
面向服务的体系结构从本质上说是一种由元数据和XML（可扩展的标记语言）一类的标准数据结构协议生成的应用程序。SOA所面临的安全问题与应用其他任何分布式系统时所遇到的安全问题是相同的，即如何确保机密性、完整性和可用性。
SOA虽然在某些方面使安全简化，但是在其他方面却使安全问题变得复杂。业界人士认为，由于在基础设施中使用了XML一类的数据结构通用协议、IP通信协 议和通用操作系统，因此SOA有助于简化某些安全决策；但在模块程序中，由于许多移动部件作为最终应用要集成在一起，因此使安全决策变得复杂。
启动开放性安全标准
分布式系统安全业务的开放性标准，如SAML（安全断言标记语言）、XACML（可扩展访问控制标记语言）和Web服务安全标准，已被OASIS（结构化信息标准促进组织）所采用。业界认为，新的SOA和分布式系统标准能够有效提升安全性。
可用性和可复用性要求采用更新、更灵活的标准，即用于联合等同的SAML、精确访问控制的XACML、性能先进的SOA应用的WS安全标准。据 称，SAML现在包括若干基于实时应用环境的新文档，并将融进更多的新文档。目前，推广应用SAML的成功者为数不少。某些政府也正在推广应用，其用户多 达数千万。
Web服务安全标准的制定工作已经基本完成。可以预计的是，如果用户进行相对简单的通用数据存取，他们将可以顺利完成这一过程。如果Web服务安全标准复 杂或者实施起来比较困难，那么用户可能就会遇到某些互操作性的问题。不过，等同联合的交替模块（包括Web服务联合和开放ID）能够解决这些问题。
改编新标准引争议
OASIS技术委员会正在编写一套扩展式Web服务安全对策样本。这套对策比较复杂，并且还没有在实际中应用过。
OASIS数字签名业务扩展（DSS-X）技术委员会正在制定标准的XML框架，用来管理机构之间的身份信息和系统资源及其分配。业界人士认为，XML标 准框架有利于管理身份信息和系统资源。不过现在的问题是必须推出和测试能互操作的产品，并部署和测试实时应用环境。
尽管为SOA指定的各种安全标准的制定还存在着种种障碍，但是把这些标准融入SOA以及将其大量应用于工业进程的工作正在进行中。
互操作性问题
Web服务常常作为应用互操作性的理想解决方案， 而且对于与平台、销售商和编程语言无关的综合应用也是非常有效的，它们不受互操作性问题的影响。因此，大多数互操作性问题并非来自于成熟稳定的Web服务 规范，而是来自各种Web服务规范的扩展和Web服务安全标准的一系列扩展。随着这些标准的扩展，销售商必须选择所要支持的规范草案，开发商有时需要协商 解决不同规范之间的不兼容问题。
SOA倾向于模块化设计
业界认为，SOA即使只作为实现模块设计的手段，其优点也非常突出。用SOA设计的模块就是将应用程序的不同功能单元（称为服务）通过这些服务之间定义良 好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样系统中的服务可以采用一种统一和通用的方式进行交互。这是一种松散藕合的 接口方式，其易损性比内部数据结构之间基于代码的交互作用低得多。其优点与面向对象的设计非常相似，甚至更胜一筹。
SOA内部模块化并不会引发安全问题，因为它不会将新的功能 给其他系统或外部机构。但是，代码库的重复使用和开放可存取性却存在着危险性，即通过与用 户和供应链上的合作伙伴所建立的业务接口，可能 新的服务功能。当这种情况发生时，预定的服务供给可能中断，给企图扩展权限和进行服务攻击不怀好意者留 下路径。
任何一种安全标准或所支持的标准总数，都不足以评估SOA或Web服务平台的效能。因此，对安全标准的支持并不就意味着安全。在许多情况下，安全标准只是定义了让各种服务模式能彼此互操作的框架，实际上它并不等于任何一种特殊服务模式都能良好运行。
即使完全按照Web服务安全实施办法，服务仍可能因为使用弱密码、受简单的密约管理，或者数据库未加密而出现不安全的情况。应当说安全是一种实际应用状态，而不仅仅是一系列所支持的标准。
SOA通过分布式系统的开放性标准以及模块化设计来提供安全的Web服务。
MSN视频对话存在堆溢出漏洞
受影响系统：MicrosoftMSNMessenger7.5、Microsoft MSN Messenger 7.0、Microsoft MSN Messenger 6.2和Microsoft Windows Messenger 8.0。
描述：MSNMessenger是微软发布的非常流行的即时通信聊天工具。MSNVIDEO处理用户请求时存在缓冲区溢出漏洞，远程攻击者可能利用此漏洞控制用户系统。
厂商补丁：Microsoft已经为此发布了一个安全公告（MS07-054）以及相应补丁:
MS07-054：VulnerabilityinMSNMessenger and Windows Live Messenger Could Allow Remote Code Execution (942099) 。
链接：technet/security/Bulletin/MS07-054.mspx?pf=true
动态
●Juniper推UAC2.1方案Juniper网络公司近日推出统一访问控制UAC 2.1安全解决方案。这项解决方案提供了先进的网络保护、应用可见性和监控、简化网络访问控制安装，有效遵循相关规定，同时降低风险，满足不断发展的访问 控制及高性能业务的安全要求。
●金山捕获新病毒金山公司近日发现新病毒，该病毒的作者借病毒来发布寻人启示，自行修改文件夹选项，同时会关闭任务管理器，如果不隐藏运行，则不断弹出恶意代码。为此，金山毒霸反病毒应急中心建议用户及时更新病毒库。
●CheckPoint推网关新功能Check Point软件技术有限公司近日宣布,其企业安全网关将Check Point的SmartDefense?与入侵防御技术相整合，可以阻止企业员工使用个人VoIP应用程序Skype v3.5，协助企业更好地管理，降低因其员工使用自行下载及自用程序所带来的安全风险。
垃圾邮件利用PDF漏洞攻击反病毒厂商F-secure近日发现一种利用最近一个AcrobatReader处理PDF的漏洞进行攻击的垃圾邮件。 这种垃圾邮件通常以"你的信用记录"、"个人财务信息"之类的标题作为主题，内容空白，并携带一个文件名为Report.pdf的文档，这个文档如果不小 心被用户开启后，会从一个位于马来西亚的服务器上下载并安装恶意软件。
●趋势科技将收购Provilla趋势科技近日宣布将收购内容安全厂商Provilla。Provilla是领先的数据泄漏防护产品厂商，主要生产基于指 纹识别的数据泄漏防护智能终端方案。收购完成后，Provilla将作为趋势科技美国分公司下属的子公司存在，并为趋势科技的多层内容安全方案提供支持。
●RSA推SecurIDSoftwareToken 安全厂商RSA近日推出了支持Symbian OS平台的SecurID Software Token产品，Symbian OS是当前流行的移动电话操作系统，而SecurID Software Token属于双因素身份验证产品，这表明了RSA的软件Token产品再次扩展到更大范围的移动平台上，同时为企业使用RSA软件Token降低了成本和门槛。
本文来自： 国际信息安全学习联盟
SOA项目中十步搞定大型SOA应用程序的安全
十步搞定大型SOA应用程序的安全
第 1 步 选择正确的团队
将大型关键基础设施应用程序迁移到 SOA 的工作令人望而生畏。对其进行保护甚至更为困难，经常需要采用全新的视角对其加以认识--甚至可能需要一组全新的安全人员进行相关工作。大部分安全团队在 SOA 方面甚至编程方面的培训极少。安全权威机构常用的方法是，只管发出要求并希望组织能够加以遵循。因此，第 1 步（这经常是最难的部分）是确保拥有正确的团队。
团队应该有个负责人，该负责人应该具有安全性和软件体系结构方面的知识，最好也能了解 SOA 的相关知识。与企业架构师类似，安全企业架构师（Security Enterprise Architect，SEA）将负责创建总体 SOA 安全模型，以便在每个粒度级别集成所有不同的安全性需求。SEA 将进入 SOA 治理委员会，与企业架构师（Enterprise Architect，EA）一起确保所有 SOA 实现都符合安全性需求的相关要求，并对负责创建整个流程中所需的构件的安全业务分析人员（Security Business Analyst，SBA）和安全系统工程师（Security Systems Engineers，SSE）团队进行指导。SEA 还将负责与编写安全性服务代码的程序员及在部署系统前对其进行测试的安全性系统测试人员合作。
第 2 步 创建详细项目计划
对于大型 SOA 系统，第 2 步要求高层管理了解，将无法通过改进新的 SOA 将其纳入旧安全模型中：这样做根本行不通。如果从最开始的重点就是传统安全机制（如防火墙、入侵检测系统和安全监视），这将完全与 SOA 安全实现不沾边。您将负责通过制定详细的项目计划和预算，清楚地说明和反映 SOA 安全实现所必需的东西，确保每个人都对此心里有底。
您必需让大家认识到，到 SOA 模型的任何转换都会涉及到固有的安全矛盾：系统的 SOA 特征越明显，其安全性越差。通过面向服务的建模和分析技术将当前系统转换为 SOA 的过程要求形成业务设计的相关文档。通过使用可将业务设计与信息系统相关的正式语言，通常仅能说明矛盾、低效而复杂的非 SOA 系统的情况。不过，这个复杂性会掩盖住大部分问题所在，从而使寻找机会破坏企业系统的人难于找到这些脆弱的环节。对这些系统进行分解并启用 SOA 后，恶意用户所面对的体系结构就会简单一些，从而更便于进行破坏。
SOA 支持者可能对此会加以否认，但负责保护系统安全的人知道，具有集中控制点且启用了 Web 的开放系统本身安全性就较差，而需要更为反应灵敏而灵活便利的方法。没有办法绕开这个问题，项目规划人员（经常会向 SOA 安全性方面分配一组适当的任务）必须记住，SOA 安全性需要详细的项目规划和预算，为安全性团队分配必要的时间，以便分析和了解 SOA 实现所带来的新挑战。
第 3 步 维护 SOA 支持安全决策表
通过创建 SOA 支持安全决策表正式记录抽象 SOA 安全性动态因素。在此表中，业务参与者将应用程序分为三类，包括：
"将启用 SOA 支持的应用程序
"必须与启用 SOA 支持的应用程序交互的应用程序
"将不启用 SOA 支持，也不必与启用 SOA 支持的应用程序交互的应用程序
也可以对这些不同的类别进行颜色编码。例如，我将第一个类别中的项目设置为红色，第二个类别中的项目设置为橙色，而将第三个类别的项目设置为黄色。
安全团队然后将进一步把应用程序划分到各个安全性类别，如高、中和低。例如，处理市场和分类信息的应用程序或服务将属于高安全性类别，而仅仅访问公开数据的应用程序或服务可以归入最低安全性类别。
表 1 显示了 SOA 支持安全决策表的示例。
表 1. SOA 支持安全决策表
安全性（高） 安全性（中） 安全性（低）
红色 36 12 11
橙色 12 5 3
黄色 6 0 6
在表中可以看到 12 个应用程序将不启用 SOA 支持（标为黄色的应用程序）；因此，此工作将需要异类安全模型，即一个为以 SOA 为中心的系统部分提供安全性，另一个为非 SOA 区域提供安全性。通常，非 SOA 模型依赖于基于边界的安全性，其中的信息资产通过防火墙层进行保护。
对于以 SOA 为中心的安全性，要首先按照第 4 步中所述创建风险管理框架。
第 4 步 使用风险评估框架方法创建初步草案
第 4 步将使用"内部安全性"(security from within) 方法。内部安全性 指安全性考虑与 SOA 实现中的所有活动对应。必须检查设计文档，了解必须在哪些地方作出安全决策并确定执行这些决策的安全控制点，从而了解 SOA 实现将如何工作。
需根据需要将这些策略的职责分配到应用程序、SOA 安全性服务和 SOA 组件，从而利用相应的机制来应用这些安全策略并加以执行。必须将安全需求封装或分解为将在 SOA 实现中以渗透方式工作的一组安全服务。例如，可以将用户身份验证的任务分配给 Authentication Security Service（所有应用程序都能够访问此服务并与之进行交互）。与此相对，可以配置企业服务总线（Enterprise Service Bus，ESB）来按应用程序限制对特定消息的访问。（第 2 部分将提供更多的相关细节。）
SOA 安全服务必须遵循相同的常规 SOA 原则、即松散偶合、模块化、封装、重用和可组合性，以获得必要的灵活性，帮助确保信息系统能够跟上业务设计中变化的速度，并成为实现更为完善的组织总体安 全性的变更驱动因素。这就要求从传统的静态安全模型转向动态模型，以跟上 SOA 体系结构中更快的变更速度。
除了内部安全性方法外，还必须同时保留基于风险管理的方法：从第 3 步中，可以看到有些数据的安全要求比其他数据高，有些应用程序比其他应用程序更为开放，如此等等。因此，不要均按照同样的标准处理所有消息和应用程序，否 则就可能对整个系统造成不必要的安全负担，从而影响系统的性能和可用性。总体风险管理战略中必须包含将安全需求与系统的总体可用性进行权衡的内容。
Gary McGraw 撰写的非常实用的书籍（请参见参考资料）详细说明了用于帮助创建风险管理框架（Risk-Management Framework，RMF）的包含五个部分的流程。从本质上说，您必须做到以下几点：
"了解业务上下文。
"确定业务和技术风险。
"对风险进行综合与分级。
"定义风险缓和战略。
"进行补救并验证结果。
例如，通过了解供应商竞标系统的业务上下文，可以发现尽管每个供应商都应该能够访问自己的信息，但查看其他供应商的信息却并不合适。此数据仅能在业务上下文中进行分类，而不能使用简单的层次结构模型（如第 3 步中的模型）进行分类。
第 5 步 定义内部和外部参与者
了 解了这些方法后，就该进行第 5 步了。在第 5 步中，SOA 安全团队将确定 SOA 安全参与者并进行相应的划分工作。参与者分为两类：外部和内部。外部政策制定者和治理机构（如 North American Electric Reliability Corporation (NERC)）可能提供了具有广泛安全影响的特定网络完全性标准，如关键基础设施保护（Critical Infrastructure Protection，CIP）需求等。
CIP 涵盖的领域非常广泛，如安全管理控制 (Security Management Controls) (CIP-003-1)、电子安全范围 (Electronic Security Perimeter) (CIP-005-1)、关键网络资产的物理安全 (Physical Security of Critical Cyber Assets) (CIP-006-1)、系统安全管理 (Systems Security Management) (CIP-007-1)、事故报告与响应计划 (Incident Reporting and Response Planning) (CIP-008-1) 及关键网络资产的恢复计划 (Recovery Plans for Critical Cyber Assets) (CIP-009-1)。所有这些标准都有自己的一组特定需求，会对总体 SOA 安全实现造成影响。
而且，内部安全需求（经常采用安全标准操作流程（Security Standard Operating Procedure，SOP）的形式编写）可回答谁、什么、何地、何时 及如何 这样的安全问题。谁能够何时何地访问什么，以及如何进行、持续时间多长？对于很多组织而言，此信息随着时间不断地发展，缺乏组织性和一致性；SOA 实现经常需要投入相当大的精力提供系统文档，以准确地反映组织的安全策略。
第 6 步 确定和使用正确的工具进行需求收集
在 第 6 步中，开始收集需求前，务必选择正确的工具，以便团队进行协作和方便地记录 SOA 安全需求和创建 SOA 安全模型。正确的需求与分析工具将帮助团队了解问题领域、捕获和管理不断发展的需求、建模用户交互、在整个项目生命周期中包含参与者反馈，而最为重要的是 进行协作。
良好的安全需求与分析实践将极大地减少系统安全风险。IBM? Rational? 需求与分析工具非常适合用于了解和表示参与者需求、指导和协调客户和业务需求的收集和验证工作、记录和组织系统的需求及向整个团队说明相关需求。我自己在 使用 IBM Rational RequisitePro?、WebSphere? Business Modeler 和 Rational Software Architect，建议大家也使用这些工具。
第 7 步 遵循 SOA 安全实现的 SDLC 流程
考虑到所必须收集的海量信息、必须编写的体系结构构件的数量以及将构造的特定 SOA 安全服务，SOA 安全团队应该遵循软件开发生命周期（Software Development Life Cycle，SDLC）的标准步骤：
1.确定安全需求和约束
2.得出和收集安全需求
3.创建安全体系结构设计
4.形成详细的安全 SOA 设计文档
5.实现 SOA（包括 SOA 治理）
6.测试
7.部署
8.维护
乍看之下，这些步骤可能非常明显，但安全团队很少采用 SDLC 流程。他们不习惯坐在房间里讨论相关工作和编写详细需求、设计安全抽象设计，以及创建详尽测试用例来验证系统是否具有可靠的安全性。（抽象设计和测试用例将在本系列的第 2 部分和第 3 部分进行讨论。）
团 队开始设计解决方案前，必须对需求进行收集。对于安全实现，既有显式需求，也有隐式需求。对于显式需求，一个很好的着手点就是按照第 5 步中所示收集每个参与者的需求。而对于隐式需求，最好使用安全框架，如保密性、完整性和可靠性（Confidentiality, Integrity, and Accountability，CIA）三部曲，以便在其中列出所有安全系统的具体需求。CIA 三部曲是广泛使用的信息保证（Information Assurance，IA）模型，此模型将保密性、完整性和可用性定义为所有信息系统的基础安全特征。
团队应该考虑此 SOA 实现将如何确保系统保密性（即数据保密），并构建清楚的流程图，以详细说明如何保证仅由目标授权接收方、个人、流程或设备访问传输中的消息。将消息泄漏给 非授权实体（如使用非授权网络探查的恶意用户）就违反了保密性，SOA 实现必须指定将在何种情况下在整个系统中使用加密技术（存储和传输保密信息的方法）。
与此类似，SOA 安全模型要求提供完整性（确保消息不会被更改）。SOA 安全负责确保信息在从原始位置传输到接收方的过程中不会被更改（数据完整性），并负责保证该信息的发送方是预期的发送方（来源完整性）且接收方是预期的接 收方（接收方完整性）。在预期接收方收到信息前，如果数据被有意或意外地更改或破坏，数据完整性就遭到了破坏。如果代理冒充发送方身份并向接收方提供不正 确的信息，则来源完整性就遭到了破坏。数据签名和哈希算法是用于提供数据完整性的机制。
另外，授权用户对数据服务 器的及时可靠访问（可用性）也是一项 SOA 安全需求：SOA 实现必须确保信息和资源在需要时可用，这意味着资源的提供速度应该足够满足较大的系统执行其预期任务所需的速度。当然可能在保密性和完整性得到保护的情况 下，入侵者仍然可能导致资源在需要时可用性降低，或根本不可用。具体来说，当 ESB 之类的 SOA 系统组件负责"代理消息"时，必须在 SOA 安全需求文档中详细说明高可用性协议、完全冗余网络体系结构和系统硬件，不要存在任何单点故障，从而保证系统的可靠性和稳健性。SOA 安全团队负责全面地表示这些区域，并确保记录了相应的用例（且能充分说明特定的需求）。
第 8 步 找出现有模型并从中吸取经验教训
SOA 安全需求团队花时间确定了所有需求后，团队成员会发现没有任何第三方工具能满足其全部需求。他们必须自己编写 SOA 安全服务来满足特定需求。比完全闭门造车好得多的做法是，对现有的模型进行分析，在团队开始抽象设计阶段前了解已经开发的内容。在此步骤（第 8 步）中，我们建议参考 Intelligrid 的以下模型（请参见参考资料）。可以在其中看到常用安全实用工具服务的列表，可能需要在 SOA 安全实现中提供这些服务。我将在下一篇文章中对这些服务进行更为详细的说明，但为了方便起见，我在此将其列出供参考：
"Audit Common Service
"Authorization Service for Access Control
"Confidentiality Service
"Credential Conversion Service
"Credential Renewal Service
"Delegation Service
"Firewall Traversal Service
"Identity Establishment Service
"Identity Mapping Service
"Information Integrity Service
"Inter-Domain Security Service
"Non-repudiation Service
"Path Routing and QoS Service
"Security Policy Service
"Policy Exchange Service
"Privacy Service
"Profile Service (User Profile Service)
"Quality of Identity Service
"Security Against Denial of Service (DoS)
"Security Assurance Management Service
"Security Protocol Mapping Service
"Security Service Availability Discovery Service
"Single Sign-on Service
"Trust Establishment Service
您可能并不需要其中的全部服务。SOA security 团队必须将需求映射到每个服务，然后为需要的所有服务创建 SOA 安全模型，以满足第 7 步中确定的所有需求。
第 9 步 熟悉 WS-Security 标准
完成此流程后，就收集了足够的信息可进行第 9 步了，即分析 WS-Security 标准，确定哪个标准适用于您的特定 SOA 安全实现。图 1 列出了需要参考的所有 WS-Security 标准。
图 1. WS-Security 标准
随着更为详细的模型的出现，必须熟悉组成 WS-Security 的各种 SOA 安全标准，并了解它们如何彼此相关以及其与 SOA 安全模型需求的关系。这些安全标准将用于构造整个 SOA 实现中的安全消息。
第 10 步 为第三方供应商制定标准
最 后，在第 10 步中，SOA 安全团队将负责为第三方供应商创建一组标准和应用程序编程接口（Application Program Interface，API）。SOA 的一个主要卖点是，系统将利用其开放性访问第三方供应商提供的服务。每个供应商必须熟悉 SOA 实现安全标准，并清楚地知道服务将如何与 SOA 实现的安全服务进行交互。
在整个过程中，必须维护详细的安全术语表，以确保所形成的所有文档采用相同的术语和定义。我建议从 Oasis Security Services TC Glossary 着手。应该与所有供应商共享此术语表，以确保所有人都采用相同的术语。
总结
在本文中，我们了解了常见 SOA 安全路线图的 10 个步骤：
"选择正确的团队。
"制定详细的项目计划。
"维护 SOA 支持安全决策表
"使用"内部安全性"和风险管理框架方法创建初步草案。
"定义内部和外部参与者。
"确定和使用正确的工具进行需求收集。
"遵循 SOA 安全实现的 SDLC 流程。
"找出现有模型并从中吸取经验教训。
"熟悉 WS-Security 标准。
"为第三方供应商制定标准。
如果遵循所有这些步骤，就在 SOA 安全性方面有了一个好的开头。
关注这个包括三部分的系列文章的后续部分，了解 SOA 安全团队进行成功 SOA 安全性实现所需的主要项目：路线图（第 1 部分）、抽象设计（第 2 部分）以及测试用例（第 3 部分）。
1 SOA安全性特点
1.1 跨技术、身份和管理边界的身份转换和传播
一套完整的业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维 护，这要求必须在SOA架构范围内建立统一的信任体系，使得请求者（人或程序）能够在服务间自由流动，系统能够自动地将请求者身份随着边界的不同而转换。
1.2 与合作伙伴建立信任
借助Web服务的强大能力，企业往往需要与合作伙伴建立紧密地服务和数据交换，发挥各自的优势来共同组成一个完整的一站式服务。比如一个旅行服务系统，机 票订购由专门的机票代理公司提供，旅游线路设计和行程服务则由旅行社负责，而食宿则由当地旅店提供。为了保证客户信息能够在多个系统安全完整地流动，并及 时地反映客户实时的旅行状态，必须在企业与合作伙伴之间建立可靠、安全的信任关系。
1.3 跨多个应用程序统一、重用和共享公共安全性
SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。每个应用系统可以使用共享安全组件，比如CA认证中心、信道加密方式和SOA安全网关等。此外，统一的安全标准遵从对于SOA整体安全性而言至关重要。
1.4 政府和行业规范要求的可追究性和可跟踪性
在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护，同时可能还需要用安全的方式在一定时期内保存敏感信息。在启用验证、审核和许可之前，必须保证 消息源的完整性（如通过公证服务）。消息的完整性和保密性可以通过对敏感信息进行加密和数字签名来实现。完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保存保护的内容以遵守政府规章制度和业界最佳实践的需要。企业需要对其提供的服务进行担保，确保服务 仅执行其公开申明的操作，同时有义务为用户提供足够的安全保障。因此，企业必须保存系统操作记录，以此来跟踪其用户或消息，也就是说企业必须具有很强的服 务审计能力。
1.5SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互
身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问 Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器 的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁（大多数情况下，这些请求被人恶意利用和操纵）将是SOA安全防御的一项 重要课题。
2 SOA面临的安全挑战
2.1 XML通信协议消耗大量带宽，引发安全问题
与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。
由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很 容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所"淹没"，结果可能导致拒绝式攻击从而损害系统的正常功 能。
为了解决这类问题，市场上已出现了专门的XML 。利用基于64位平台架构的语法分析器，该设备可以用来加速XML/SOAP的解析、XML模式的确 认、XPath的处理以及 XSLT的功能转换。据公开的产品测试报告称，这种XML 能够达到每秒处理1万多条XML消息的能力。
2.2 基于XML的服务间通信易受到监听和窃取
由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进 行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和Web服务策略（WS-Policy）是专门用来解决这个问题的两个标准；通过消息安全，可以保证Web服务环境中交换 的XML消息的完整性和保密性，Web服务安全（Web Service Security，WSS）和安全声明标记语言（Security Assertion Markup Language，SAML）则用来解决这方面的问题。
目前主要的XML安全标准包括：XML加密、XML签名语法和处理、数字签名和XML密钥管理规范（XML Key Management Specification，XKMS）等。值得一提的是，现有的XML安全标准已经可以实现对XML文档进行有选择的签名处理，而这在以前是不可能做到的，要么整个文档被签名，要么根本不签名。
下面我将重点介绍XML加密和XML签名。它们已经由W3C发布为标准，可以用来把安全加入到基于XML的数据中去。
XML加密是用来把原始的XML数据通过密码依次加密，从而让数据能够在请求者和服务端之间以一种模糊的方式传输。密码仅由请求者和服务端掌握，这就能保证即使是在传输的过程中有数据被截取，窃取者也只能看到一堆毫无意义的字符串，从而防止敏感信息泄露。
另一方面，XML签名则用来防止XML文档的被非法篡改。通过使用XML签名，一个服务供应商可以提供给任何的服务消费者--以一种确定的方式来检测XML的有效负载是否相对于它原来的方式或者原来的状态发生了改变。
需要特别指出的是，XML加密和XML签名适用于任何的XML类型的文档。意识到这一点是很重要的，因为它们不仅仅可以用来保护服务交互的有效负载的交 换，同样的它们也可以用来保护类似WSDL这种契约，这些文档也是基于XML的，并且也是SOA中的一个重要组成部分。
同样，市场上也出现了专门解决这类问题的产品，称为XML安全网关。类似传统的防火墙， 企业可以把它部署在网络边界上，从而对所有进出的XML数据进行保护。XML安全网关遵循包括XML和WS-Security在内的行业标准，对XML数 据进行验证、加密、签名以及认证，来提供安全的基于XML的Web服务通信。此外，它还可提供防火墙功能和访问控制功能。有些产品还可以与网络管理软件集 成，帮助企业降低IT管理成本，并解决依从性需求。
2.3 缺乏良好的编程模型严重威胁企业安全
对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则而构造实现的服务、应用程序以及跨组织操作所具有的松耦合特性，这种环境往往更加容易 现有安全实现的弱点或局限性，因此缺乏良好的编程模型将严重威胁Web服务的安全。
仅采用边界防御（如防火墙和路由器） 来保护企业信息安全是不够的，因为企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态的信任关系。因此，企业需要灵活的、可自定义的 基础设施，以适应新要求和规章制度。要提供这种灵活性，不应简单的指望将策略生搬硬套到基础设施中，应该在服务的开发过程中建立和遵循由策略驱动的编程模 型。SOA 编程模型可以确保每个服务调用都符合对请求者和服务端点均有效的安全策略。
从安全的角度来看，编程模型负责对于谁负责实现安全策略（如基础设施或应用程序）以及需要让请求者得到此信息的哪一部分等做出决策。另一方面要考虑的是调 用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性。最后，在实现安全解决方案时，还应该考虑安全工程--用于构建安全应用程序的工 程方法。
3 其它SOA安全保护方法
3.1 应用程序代理
一种非常有效的保护核心系统的方法是避免让任何人直接访问提供服务的平台，可以通过为SOA中的Web服务部署一个代理做到这一点。一个受保护的代理可以 代表实际的Web服务接收所有Web服务请求，并对其做出响应，从而保护Web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础 架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对Web服务请求的身份验证和授权，而不是每次用户想调用Web服务时，就在网络上使用大量 消息对该用户进行身份验证和授权。代理还可以在消息中插入了身份验证和授权SAML断言，从而消除了Web服务请求者直接查询核心安全性系统的风险。
3.2 契约管理
作为主要的SOA 管理问题之一，契约管理在SOA安全性中起着举足轻重的作用。所谓契约就是用于管理Web服务使用情况的一组规则。例如，某个契约可能会规定某个特定用户 有权每天调用某个特定的Web服务五百次，而且在调用过程中，服务水平必须满足特定的参数，比如所有请求都必须在2秒钟内响应。
在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而被误用。例如，SOA拦截器把Web服务请求和响应数据发送给SOA安全管理 中心，然后该SOA安全管理中心确定该请求是否满足契约。如果某个安全性行为（比如拒绝式服务攻击）使Web服务的响应速度降低到契约规定的服务水平以 下，SOA安全管理中心就会警告系统管理人员有问题存在，甚至可以根据预设的策略自动采取必要的措施，比如对某些攻击请求进行阻断或限制次重要服务的使用 频率等。尽管一次足够严重的攻击可以导致整个网络崩溃，但是合理的契约管理至少可以使我们得到及时的安全问题通知，从而有效地采取行动。
总之，为了应对SOA的安全挑战，需要在企业范围内（还应包括其合作伙伴）建立一套统一的安全基础设施，通过对请求者进行身份验证和对其授予服务访问权、 基于基本信任模型跨Web服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容，安全基础设施帮助企业形成一套完整的保护基于组件和服务的 SOA环境的结构。
所有SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。而基于 Web 服务安全规范的Web服务安全模型和方法有助于解决保护面向服务的应用程序的难题。
SOA安全标准面临新挑战
面向服务的体系结构（SOA）使安全决策变得复杂，原因在于，作为最终应用的许多移动部件，必须在模块程序中集成。因此，IT和安全人员在SOA计划实施之初就需要密切协调，才能保证其实现机密性、完整性和可用性。
对于一些组织机构和IT管理者而言，利用分布式计算，如SOA和集成式Web服务，意味着对设计的复杂性和安全性要求更高。
随着计算进一步趋向分布式，以及新型威胁和有组织的互联网犯罪的增多，开放式标准在制定和更好地利用有效的安全措施等方面起着重大的作用。除此之 外，如何在管理层次以及安全对策、程序和相关工作中利用这些标准，来提高内部员工的安全意识、促进业务伙伴访问企业服务、监测网络所面临的威胁也是至关重 要的。
本文探讨了SOA面临的安全挑战，安全标准制定取得的进展，以及安全标准在扩展时可能遇到的问题。
SOA使安全决策难度大
面向服务的体系结构从本质上说是一种由元数据和XML（可扩展的标记语言）一类的标准数据结构协议生成的应用程序。SOA所面临的安全问题与应用其他任何分布式系统时所遇到的安全问题是相同的，即如何确保机密性、完整性和可用性。
SOA虽然在某些方面使安全简化，但是在其他方面却使安全问题变得复杂。业界人士认为，由于在基础设施中使用了XML一类的数据结构通用协议、IP通信协 议和通用操作系统，因此SOA有助于简化某些安全决策；但在模块程序中，由于许多移动部件作为最终应用要集成在一起，因此使安全决策变得复杂。
启动开放性安全标准
分布式系统安全业务的开放性标准，如SAML（安全断言标记语言）、XACML（可扩展访问控制标记语言）和Web服务安全标准，已被OASIS（结构化信息标准促进组织）所采用。业界认为，新的SOA和分布式系统标准能够有效提升安全性。
可用性和可复用性要求采用更新、更灵活的标准，即用于联合等同的SAML、精确访问控制的XACML、性能先进的SOA应用的WS安全标准。据 称，SAML现在包括若干基于实时应用环境的新文档，并将融进更多的新文档。目前，推广应用SAML的成功者为数不少。某些政府也正在推广应用，其用户多 达数千万。
Web服务安全标准的制定工作已经基本完成。可以预计的是，如果用户进行相对简单的通用数据存取，他们将可以顺利完成这一过程。如果Web服务安全标准复 杂或者实施起来比较困难，那么用户可能就会遇到某些互操作性的问题。不过，等同联合的交替模块（包括Web服务联合和开放ID）能够解决这些问题。
改编新标准引争议
OASIS技术委员会正在编写一套扩展式Web服务安全对策样本。这套对策比较复杂，并且还没有在实际中应用过。
OASIS数字签名业务扩展（DSS-X）技术委员会正在制定标准的XML框架，用来管理机构之间的身份信息和系统资源及其分配。业界人士认为，XML标 准框架有利于管理身份信息和系统资源。不过现在的问题是必须推出和测试能互操作的产品，并部署和测试实时应用环境。
尽管为SOA指定的各种安全标准的制定还存在着种种障碍，但是把这些标准融入SOA以及将其大量应用于工业进程的工作正在进行中。
互操作性问题
Web服务常常作为应用互操作性的理想解决方案， 而且对于与平台、销售商和编程语言无关的综合应用也是非常有效的，它们不受互操作性问题的影响。因此，大多数互操作性问题并非来自于成熟稳定的Web服务 规范，而是来自各种Web服务规范的扩展和Web服务安全标准的一系列扩展。随着这些标准的扩展，销售商必须选择所要支持的规范草案，开发商有时需要协商 解决不同规范之间的不兼容问题。
SOA倾向于模块化设计
业界认为，SOA即使只作为实现模块设计的手段，其优点也非常突出。用SOA设计的模块就是将应用程序的不同功能单元（称为服务）通过这些服务之间定义良 好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样系统中的服务可以采用一种统一和通用的方式进行交互。这是一种松散藕合的 接口方式，其易损性比内部数据结构之间基于代码的交互作用低得多。其优点与面向对象的设计非常相似，甚至更胜一筹。
SOA内部模块化并不会引发安全问题，因为它不会将新的功能 给其他系统或外部机构。但是，代码库的重复使用和开放可存取性却存在着危险性，即通过与用 户和供应链上的合作伙伴所建立的业务接口，可能 新的服务功能。当这种情况发生时，预定的服务供给可能中断，给企图扩展权限和进行服务攻击不怀好意者留 下路径。
任何一种安全标准或所支持的标准总数，都不足以评估SOA或Web服务平台的效能。因此，对安全标准的支持并不就意味着安全。在许多情况下，安全标准只是定义了让各种服务模式能彼此互操作的框架，实际上它并不等于任何一种特殊服务模式都能良好运行。
即使完全按照Web服务安全实施办法，服务仍可能因为使用弱密码、受简单的密约管理，或者数据库未加密而出现不安全的情况。应当说安全是一种实际应用状态，而不仅仅是一系列所支持的标准。
SOA通过分布式系统的开放性标准以及模块化设计来提供安全的Web服务。
MSN视频对话存在堆溢出漏洞
受影响系统：MicrosoftMSNMessenger7.5、Microsoft MSN Messenger 7.0、Microsoft MSN Messenger 6.2和Microsoft Windows Messenger 8.0。
描述：MSNMessenger是微软发布的非常流行的即时通信聊天工具。MSNVIDEO处理用户请求时存在缓冲区溢出漏洞，远程攻击者可能利用此漏洞控制用户系统。
厂商补丁：Microsoft已经为此发布了一个安全公告（MS07-054）以及相应补丁:
MS07-054：VulnerabilityinMSNMessenger and Windows Live Messenger Could Allow Remote Code Execution (942099) 。
链接：technet/security/Bulletin/MS07-054.mspx?pf=true
动态
●Juniper推UAC2.1方案Juniper网络公司近日推出统一访问控制UAC 2.1安全解决方案。这项解决方案提供了先进的网络保护、应用可见性和监控、简化网络访问控制安装，有效遵循相关规定，同时降低风险，满足不断发展的访问 控制及高性能业务的安全要求。
●金山捕获新病毒金山公司近日发现新病毒，该病毒的作者借病毒来发布寻人启示，自行修改文件夹选项，同时会关闭任务管理器，如果不隐藏运行，则不断弹出恶意代码。为此，金山毒霸反病毒应急中心建议用户及时更新病毒库。
●CheckPoint推网关新功能Check Point软件技术有限公司近日宣布,其企业安全网关将Check Point的SmartDefense?与入侵防御技术相整合，可以阻止企业员工使用个人VoIP应用程序Skype v3.5，协助企业更好地管理，降低因其员工使用自行下载及自用程序所带来的安全风险。
垃圾邮件利用PDF漏洞攻击反病毒厂商F-secure近日发现一种利用最近一个AcrobatReader处理PDF的漏洞进行攻击的垃圾邮件。 这种垃圾邮件通常以"你的信用记录"、"个人财务信息"之类的标题作为主题，内容空白，并携带一个文件名为Report.pdf的文档，这个文档如果不小 心被用户开启后，会从一个位于马来西亚的服务器上下载并安装恶意软件。
●趋势科技将收购Provilla趋势科技近日宣布将收购内容安全厂商Provilla。Provilla是领先的数据泄漏防护产品厂商，主要生产基于指 纹识别的数据泄漏防护智能终端方案。收购完成后，Provilla将作为趋势科技美国分公司下属的子公司存在，并为趋势科技的多层内容安全方案提供支持。
●RSA推SecurIDSoftwareToken 安全厂商RSA近日推出了支持Symbian OS平台的SecurID Software Token产品，Symbian OS是当前流行的移动电话操作系统，而SecurID Software Token属于双因素身份验证产品，这表明了RSA的软件Token产品再次扩展到更大范围的移动平台上，同时为企业使用RSA软件Token降低了成本和门槛。
本文来自： 国际信息安全学习联盟
页:
[1]