第 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 支持安全决策表

　　安全性(高)安全性(中)安全性(低)

　　红色361211

　　橙色1253

　　黄色606

　　在表中可以看到 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)的标准步骤：

　　确定安全需求和约束

　　得出和收集安全需求

　　创建安全体系结构设计

　　形成详细的安全 SOA 设计文档

　　实现 SOA(包括 SOA 治理)

　　测试

　　部署

　　维护

　　乍看之下，这些步骤可能非常明显，但安全团队很少采用 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 标准。

　　随着更为详细的模型的出现，必须熟悉组成 WS-Security 的各种 SOA 安全标准，并了解它们如何彼此相关以及其与 SOA 安全模型需求的关系。这些安全标准将用于构造整个 SOA 实现中的安全消息。

　　第 10 步 为第三方供应商制定标准

　　最后，在第 10 步中，SOA 安全团队将负责为第三方供应商创建一组标准和应用程序编程接口(Application Program Interface，API)。SOA 的一个主要卖点是，系统将利用其开放性访问第三方供应商提供的服务。每个供应商必须熟悉 SOA 实现安全标准，并清楚地知道服务将如何与 SOA 实现的安全服务进行交互。

　　在整个过程中，必须维护详细的安全术语表，以确保所形成的所有文档采用相同的术语和定义。我建议从 Oasis Security Services TC Glossary 着手。应该与所有供应商共享此术语表，以确保所有人都采用相同的术语。