在面向服务的体系架构（SOA）中，服务的安全对于保护企业的核心资产具有重要的作用。本系列文章将通过对策略驱动服务安全治理的介绍，展示如何在
SOA 治理的框架中实现服务安全问题与业务问题的解耦，如何处理 SOA 安全中的加解密、数字签名、身份认证和服务访问授权等问题，以及如何把
SOA 安全的灵活性与高性能统一在一个解决方案中。本文是系列文章的第 1 部分，将针对 SOA 的安全策略作一个概述。
企业 IT 应用的典型环境已经是一个由网络、服务器、路由设备以及中介处理设施（比如 ESB）构建成的复杂的应用环境。由于这样的复杂网络环境面临着外部和内部的各种攻击和欺诈，因此如何在不安全的网络环境中保护敏感信息得到了广泛的重视。法律规定方面，企业有义务保护其客户的隐私信息；自身信息安全的方面，一个企业要保证其敏感信息的保密性、完整性和可溯源性等等。
由于企业发展和管理的一些原因，不同职能部门往往拥有各自独立的应用系统。最终用户是通过访问企业的统一门户（Portal）来获得其提供的服务。门户会统一进行初步的身份认证和访问控制管理，然后应用诸如单点登录（Single-Sign
On，SSO）连接后台不同部门的各种应用系统来提供服务，而这些应用系统都有自己独立的应用安全解决方案，如图
1 所示。
图 1. 企业应用程序的典型安全架构
各个部门独立的应用安全解决方案一般来说都属于传统的 IT 安全解决方案，大都涉及以下一个或多个方面：
- 身份识别（Identification）：保证访问资源的请求者能够声明他自己的身份；
- 认证（Authentication）：能够验证访问资源的请求者声明的身份是否真实；
- 授权（Authentication）：保证该请求者只能够访问经过授予访问权限的资源；
- 完整性（Integrity）：保证消息在传输过程中不被篡改；
- 保密性（Confidentiality）：保证消息在传输过程中不被别人偷窥；
- 可审计性（Audit）：所有的事务必须记录在案以备日后的分析和审计；
- 不可否认性（Non-repudiation）：消息传输的双方都能够向第三方提供合法证明，证实消息的发送者的确是发送了该消息而且消息的接受者的确是接受到了该消息。
各个部门独立的应用安全解决方案对于企业来说重复了相当多的工作，并且使安全管理工作处于一种分散的状态，种分散往往会带来难以同步、难以改变、难以整合等问题，常见的问题主要有下面几个方面：
- 难以监控和验证当前所有应用安全是否同时满足某一规程；
- 难以满足不断修订或增加的规程（如 ITAR 规程）需要细粒度访问控制的需求，如除了基于角色的访问控制，还需要基于规则和基于属性的访问控制；
- 难以满足不断增长的安全多样化需求，包括个性化、目录、端口以及数据级别的访问控制；
- 在各个系统中分别开发应用安全会重复增加费用。
企业对应用安全的整合是企业 IT 应用整合的重要组成部分，用 SOA 安全来整合企业应用安全可以给企业带来一致、松耦合和易重用的安全。SOA
安全通过集中的、基于标准的安全服务来实现认证、授权和审计（AAA，Authentication, Authorization
and Audit），可以实现一致地管理企业范围内的基于角色的授权、基于内容和基于规则的访问控制和服务访问风险的控制等策略。
SOA 作为构建 IT 系统的一种新方式，它能够通过重用现有 IT 资产来构建新的业务应用，并且具有灵活改变的能力以支持未来业务的发展。然而在
SOA 中，服务之间跨域操作的松耦合性给安全带来了不少挑战。SOA 架构的目标是实现业务的敏捷性，如何构建易管易控、高度重用而又灵活应变的应用安全来是实现这个目标的一个难点。在
SOA 环境中，主要的安全需求有以下几项：
- 把身份认证从服务中解耦出来；
- 以事务形式实时地无缝地连接安全和应用系统；
- 当服务被编排成应用时，每个服务都应当执行与应用安全相对应的恰当的安全控制；
- 把使用不同技术实现的服务和异构的系统中的身份安全信息进行统一管理；
- 保护事务中的敏感数据信息而不影响其他的服务；
- 能够和不断增长的企业、行业以及法律法规的各种约束保持一致性。
为此 IBM 提出了 SOA 安全参考模型，如图 2 所示。
图 2.SOA 安全参考模型
这个参考模型是针对企业域而非单一应用系统，其中：
- 业务安全服务（
Business Security Services）：管理对约束满足性、报表、身份认证、访问管理、数据保护、隐私、可靠性管理、不可否认性，以及系统安全和网络安全的要求；
- IT 安全服务（
IT Security Services）：作为
SOA 基础架构的组成部分，把安全本身作为服务提供给应用服务（即 Security
as a Service），使之能够实现身份认证、访问授权、保密性、完整性和审计，它支撑着业务安全服务；
- 安全使能器（
Security Enablers）：主要是加解密算法、目录技术和密匙机制等支持
IT 安全服务完成业务功能的各种技术；
- 安全策略管理（
Security Policy Management）：作为策略管理（Policy
Management）的一部分执行撰写、转换、实施和监控安全策略，如：撰写对服务访问者的认证和授权的策略、依据可靠模型在不同服务访问之间传递安全信息、审计重要事件和保护敏感信息等等。从功能上来说，安全策略管理是
SOA 安全的核心部分之一；
- 策略管理（
Policy Management）：提供基于策略的管理平台，以达到
IT 架构和业务的一致性要求；
- 治理和风险管理（
Governance and Risk Management）：提供了一套机制在比较大的
SOA 环境中来实施策略。其中治理（Governance）帮助客户在整个企业范围内更好地管理
SOA，风险管理（Risk Management）评估 SOA
环境中的各种风险并制定管理这些风险的战略。
SOA 安全参考模型实际上是 IBM 的 SOA 的参考架构中 IT 服务管理的一部分。
前面已经提到安全策略管理是 SOA 安全的核心部分之一。在 SOA 治理的支撑下，策略驱动的服务安全解决方案，使业务需求产生出来的目标在操作层面上能够得到很好的贯彻和执行。总的说来，策略驱动的服务安全能够提供：
- 控制的可见性：策略是控制逻辑的具体表现，而不会像硬编码那样分散在系统的各个角落难以可视化；
- 高度的灵活性：能够快速响应市场竞争或者企业自身、行业内部规程和法规的变化；
- 能够做到一致性管理，利用策略配置的工具能够做到策略的一致性管理，并很少发生配置错误；
- 能够充分保证服务和应用都是满足控制要求的，特别是对于外部的访问者；
- 能够降低花销和节省时间，不需要设计、编写、测试、部署和维护硬编码。
策略驱动的服务安全解决方案是策略驱动的服务治理的一部分。用策略驱动的方式来进行服务安全管理时，应该参考策略管理生命周期（Policy
Management Life Cycle），如下图所示。
图 3. 策略管理生命周期
策略管理生命周期是一个闭环的四段方法论。
- 策略撰写（Author），依据业务和技术需求识别、设计、编写和巩固策略，并识别出有可能被策略影响到的利益相关者；
- 策略转换（Transform），把撰写的策略（有可能还是业务需求的形式）转化成可以执行的形式，并把它部署到策略实施点（Policy
Enforcement Point, PEP）；
- 策略实施（Enforce），在运行的环境中实施已经部署的策略；
- 策略监控（Monitor），测量、分析和报告策略的运行数据，检查策略的满足性要求，并把监控的结果作为输入进入下一个回环的撰写阶段的输入，以便进一步完善策略满足新的业务需求。
在策略驱动的服务治理中，策略被分为三个层面：
- 业务层面，把策略描述为业务某种形式的说明；
- 架构层面，把策略明确为架构风格和开发模式；
- 实施层面，把策略细化为各种配置条目。
在实际应用中，策略应用有不同的方面。除了本系列文章要讨论的涉及服务安全方面的策略，实际的应用环境中往往还有服务质量、业务规程等方面的策略。无论对哪方面的策略，从业务、架构和实施三个层面看到的策略形式是一个逐步细化的过程，如下表所示。
表 1. 策略的层面
| 层面 |
服务安全 |
服务质量 |
业务规程 |
| 业务层面 |
安全与隐私策略
所有个人信息必须被保护 |
业务服务策略
白金卡客户优先访问服务 |
业务策略
保证所有的财务事务满足法律法规 |
| 架构层面 |
应用安全策略
所有的经理只能访问他们自己的直接客户的信用记录 |
服务生命周期策略
所有部署的服务被分类 |
部署生命周期策略
所有的服务必须是原创的 |
| 实施层面 |
访问控制策略
消息应当被数字签名，访问通过授权 |
服务级策略
白金卡服务的响应时间必须小于 X 秒 |
原创认证策略
每部分代码都要有相应的所有者 |
事实上，IBM 提出了多种 SOA 策略，下面是一些具体的例子。
图 4. 多种不同策略示例
- 消息安全策略（Message Security Policy），消息内容的加密和签名，使得消息内容不能被偷窥和篡改；
- 访问控制策略（Access Control Policy），细粒度的访问控制，使得能够灵活控制敏感信息不会泄露；
- 可靠消息递送策略（Reliable Messaging Policy），消息不会由于传递路径中某些节点的故障而丢失，能够保证消息传递到目的地；
- 服务生命周期策略（Service Lifecycle Policy），为服务在生命周期转换的时候指定一个或多个验证器，以保证服务满足某些规程；
- WS-I 符合策略（WS-I Compliance Policy），WSDL 都满足 WS-I
规范，使得 J2EE 平台的 WEB 服务能够和 .NET 平台的 WEB 服务互操作；
- 原创认证策略（Certificate of Originality Policy），应用的代码都要原创，不能抄袭任何拥有知识产权的系统的代码，以免带来法律上的风险。
在这 6 种策略格式里，应在构建时（Buildtime）实施的策略是服务生命周期策略、WS-I 符合策略和原创认证策略，应在运行时（Runtime）实施的是消息安全策略、访问控制策略和可靠消息递送策略。在服务安全方面，主要是消息安全策略和访问控制策略，在本系列后续文章中我们将进行更详细的介绍。
表 2. 传统 IT 安全与策略驱动的服务安全的比较
| 层面 |
与业务的耦合性 |
管理方式 |
资源的调配 |
互联协议支持 |
| 传统 IT 安全解决方案 |
强，安全逻辑和业务逻辑不能很好的分离，安全逻辑的更改会影响业务逻辑 |
分散式管理，每个系统需要各自维护一套安全方案 |
安全处理占用业务处理的 IT 资源，影响业务处理能力 |
和底层互联协议安全相绑定 |
| 策略驱动的服务安全解决方案 |
弱，安全代码和业务代码很容易分离，安全逻辑的更改不会影响业务逻辑 |
集中式管理，跨越系统，实现统一创建、分发、实施策略。 |
安全作为服务 (SasS) 不占用业务处理的 IT 资源，提高业务处理能力 |
依靠 ESB 的能力实现和协议无关的数据安全处理能力 |
这里需要指出的是，基于策略的服务安全方案的出现并不会取代以往的企业应用安全方案，而是随着企业 SOA
战略实施的不断改进和对旧有系统的改造与重用，在原有的安全方案上的补充和提高，借助于 SOA 的松散灵活的服务架构来实现更高级别的对于服务安全的需求。
IBM 拥有一整套完整的策略驱动的服务安全解决方案。它集成了 SOA 基础产品系列，能够对安全策略的撰写、转换、实施和监控四个生命周期进行完整的管理。
IBM 策略驱动服务安全解决方案的主要 SOA 产品有下面三种。
- Tivoli Security Policy Manager (TSPM)，可以管理安全策略的整个生命周期。
图 5.Tivoli Security Policy Manager（TSPM）
TSPM 7.0 是 IBM 在 SOA 安全领域的一个新产品。它提供了集中的、元数据驱动的策略管理和变更管理；它的服务注册系统基于基于标准协议的集成，可以通过
WS-Policy，WS-SecurityPolicy, WS-Trust 等标准协议与 WSRR，CCMDB
集成；拥有细粒度的授权、安全服务；基于 XACML 标准把在原来单独存在于各个应用或服务的认证、授权解耦出来作为一个集成的服务以便增强安全，降低系统的复杂度和成本；通过端到端的策略集中化管理能降低策略管理的费用和风险。
它可以作为一个独立的产品对策略提供整个生命周期的管理，针对相关服务开发策略，附着策略，部署策略到各个执行环境，监控策略的运行情况。具体的说，它的主要功能有：
- 策略管理（Policy Administration Point，PAP），TSPM 作为策略集中化管理的节点，它具有资源识别、资源分类、策略撰写、策略转换、安全的策略部署、委托管理，日志和审计，变更管理和版本控制等等功能；
- 策略决策（Policy Decision Point，PDP），TSPM 中的 Runtime
Security Service（RTSS）组件是安全即服务（Security as a Service）理念的具体实现，能够以
Web 服务的方式提供身份、认证、授权和审计的功能；
- 策略实施（Policy Enforcement Point，PEP），TSPM 提供的策略实施的模式分为基于容器的（如针对
WAS 的插件）、基于仲裁者的（如 DataPower）和基于应用的（如 Java API
上的 JACC）三种模式。
另外，TSPM 能够集成策略信息（Policy Information Point，PIP），它支持基于标准的身份属性服务（Identity
Attribute Service，IdAS）来集成身份信息和服务信息。TSPM 还提供了策略设计工具帮助客户建模、分析和创建策略模板。
它可以同其他 SOA、策略相关产品集成，满足灵活与性能并重的应用需求：集成 WSRR 作为策略库方便重用和动态切换；集成
DataPower 分别单独作为外部的 PDP 和 PEP 提高运行时策略的实施效率。
- WebSphere Service Registry and Repository (WSRR)，提供了策略库、策略撰写和实施。
图 6.WebSphere Service Registry and
Repository (WSRR)
WSRR 6.2 能够方便地在 SOA 中发布、查找、丰富、管理和治理服务与策略。WSRR
本身自带 服务生命周期治理的策略库，但服务安全的策略需要架构人员自己撰写，它提供了以下策略方面的功能：
- 策略库（Policy Libraries），WSRR 为 SOA 应用提供了集中可靠的策略编目，策略作为头等对象能够像服务一样被存储、分类、变更和治理，提供了一系列可操作的策略模板，策略也作为
SOA 治理的最佳实践看待；
- 策略撰写（Policy Authoring），WSRR 提供的策略编辑器能够很容易的创建新的策略，并能够对
WS-Policy 提供可视化来保证策略的一致性和鲁棒性；
- 策略实施（Policy Enforcement），WSRR 能使 ESB 和其他 SOA
产品能够在运行时动态的发现和实施策略。
WSRR 能够管理业务需求、应用架构和 IT 操作三个层面的策略，与此同时它也可以作为服务注册和管理的中心。
- WebSphere DataPower SOA Appliance (DataPower)，提供了策略运行时的实施环境。
图 7.WebSphere DataPower SOA Appliance
(DataPower)
DataPower XI50 3.7.3 作为一个 SOA 硬件产品，是策略运行时实施的一个主要部件，它在策略方面的主要功能有：
- 运行时实施（Runtime Enforcement），通过提前上传策略或者从服务注册库中检索到服务已加载的策略，DataPower
作为 PEP 实施策略；
- 自行或第三方决策（On/Off-box Decision），DataPower 可以自身作为
PDP 依据策略和运行状时信息做出决策，DataPower 也可把第三方如 TSPM 的 RTSS
作为 PDP 来做决策；
- 配置策略，能够基于 WSDL、Service Endpoint、Operation 各种参数，基于某一时间段内服务的访问数量（如每秒钟的事务数，TPS）和基于服务请求、服务响应和异常的内容来进行各种不同策略配置；
- 支持多个设备对一个策略进行联合实施，提供通知（Notify）、减慢（Shape）和拒绝（Throttle）的策略响应模式。
DataPower 提供了丰富的策略实施功能，最重要的是它拥有 XML 加速器的功能，作为安全网关处理服务安全要比普通软件产品更为理想。在高性能的安全方案中，DataPower
有明显的优势。
在后续的文章中，我们将陆续介绍在应用场景中如何集成上述的这些产品、运用消息安全策略和访问授权策略实现
SOA 安全。
在 SOA 整合的过程中 SOA 安全得到越来越多的关注，策略驱动的服务安全是 SOA 安全的最佳实践，策略驱动的
SOA 服务安全能够安全与业务的解耦、细粒度的访问控制和高性能的实施。IBM 提供了丰富而强大的 SOA
产品来支持策略驱动的服务安全，最终实现正规化、标准化、自动化、可追踪和高重用的 SOA 安全。
本文概述了在 SOA 的架构下使用策略来帮助实现服务的基本概念，接下来的下一篇我们结合一个具体的场景介绍如何使用
TSPM (Tivoli Security Policy Manager) 和 DataPower 以及
WSRR（WebSphere Service Repository and Registry）实现消息内容的保护。
| 
