团队应该考虑此 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 部分)。