SOA 安全性基础知识，第 1 部分: 制定保护大型 SOA 应用程序的路线图本系列提供面向服务的体系结构(Service-Oriented Architecture，SOA)安全实现路线图。本系列共三部分，本文是其中的第 1 部分，将介绍一个包括十个步骤的流程，以帮助您进行从构建 SOA 安全团队到创建有效的需求收集流程等各个方面的工作。在第 2 部分，我们将了解如何创建抽象设计，第 3 部分将讨论测试用例。

　　最近我有机会参与了一个 SOA 项目——具体来说，是一个大型自动控制系统的安全实现。我尽可能地阅读了很多关于此主题的书籍;我在网上对此进行研究，甚至向以前的同事和朋友发送电子邮件询问相关事项。让我意外的是，没有提供我所需的逐步流程的路线图，不能帮助我完成保护大型 SOA 应用程序的目标。

　　最后，我不得不自己创建了一个这样的流程。我开发了本文中所述的包含 10 个步骤的简单流程。

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

　　在表中可以看到 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)模型，此模型将保密性、完整性和可用性定义为所有信息系统的基础安全特征。