第 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 实现经常需要投入相当大的精力提供系统文档，以准确地反映组织的安全策略。