登录帐户
Oracle帐户

登出
- 帐户
- 帮助
Oracle帐户

管理您的帐户并访问个性化内容。
登录创建帐户

云帐户

访问您的云仪表盘，管理订单等。
登录
国家/地区
联系我们

为 OTN 撰稿

为 Oracle 技术网撰写技术文章，获得报酬的同时可提升技术技能。

密切关注

OTN 架构师社区

保护 SOA 环境

作者：Jürgen Kress、Berthold Maier、Hajo Normann、Danilo Schmeidel、Guido Schmutz、Bernd Trops、Clemens Utschig-Utschig、Torsten Winterberg

安全性要求在 SOA 分布式系统环境中变得日益复杂。

行业 SOA 文章系列的一部分

2013 年 7 月

简介

在传统的封闭系统中使用局部限制时，安全性要求通常比较容易管理。安全性要求在 SOA 分布式系统环境中变得日益复杂。安全性不再仅限于一个应用程序或应用程序域，而是必须跨一系列的应用程序和业务流程实现。

为了实现这些全面的安全性要求，制定了众多安全标准。其中包括 WS-SecurityPolicy、WS-Trust、XML Encryption、XKMS、XML Signature、WS-Federation、WS-SecureConversation、SAML1、SAML2 等。目前，还没有一种产品或开源框架能够完全支持所有这些标准。根据我们的经验，只要 SOA 产品或部署的 Web 服务框架需要在其小型生态系统以外进行通信，都会出现不兼容的情况。

因此，面对不断增加的费用，项目经理倾向于开始寻找可行的替代方案就一点儿也不奇怪了。他们通常选择在公司内部开发不够灵活的解决方案，能够快速实现有风险的反模式，例如在功能性负载中传输用户名和口令。各种不同的标准对设计一个得到妥善保护的系统提出了种种限制，使人们很难清楚地理解可用的安全标准和内部产品相关性。

我们的目标是，根据久经验证的最佳实践，就如何负责任地处理安全性为 IT 专家和 SOA 架构师提供一些技巧。

我需要何种程度的安全性？

由于 SOA 的广泛网络化性质，安全性起着至关重要的作用，但不同类型的应用程序和架构层对安全性有不同程度的要求。因此，通过从概念上制定实施计划，进而定义整个企业及其各个部门的内部和外部安全要求就非常重要。

在一个 SOA 项目刚开始时，开展一次企业范围的风险评估，衡量某种损害发生的可能性以及可能造成的负面影响。然后，可以根据无法避免的、可接受的安全风险权衡每种安全解决方案造成的必要工作量和绩效压力，因为安全性说到底是个财务问题。

除了风险评估，当前的法律环境也会影响安全架构。既然管理层可能因故障或风险拨备不足被追究个人责任，那么安全性对于每个员工来说就更加重要。因此，一个符合安全准则（例如 ISO 27001 [REF-1] 或面向德国公共部门的 BSI Standard 100 [REF-2]）要求的灵活、协调一致的安全架构是 SOA 的一个重要方面。

我需要何种安全性？

在信息安全方面，根据是否会危及可用性、保密性或完整性对潜在威胁进行分类。缺乏真实性也是传输数据和文档结构时需要考虑的因素，这在 SOA [REF-2] 中具有特殊意义。每个特性的简单定义如下：

可用性

按照协议规定的时间向服务使用者提供服务（流程、应用程序、系统），不会对业务造成任何负面影响。

保密性

定义为防止对保密信息进行未经授权的访问。保密性在传输未公开的信息时变得相当重要。

完整性

也称作可靠性，保证来自提供者的所有消息文本将原封不动地送达使用者，来自使用者的所有消息文本将原封不动地送达提供者。

真实性

用户是他或她所声明的那个人，不是一个匿名实体。

可用性

面向服务的业务流程通常会跨多个域分布和实现，在涉及可用性时会产生一定的依赖。

可用性与拒绝服务攻击

面向服务的架构中的服务通常在广泛保护的网络域中可用。通常针对企业内部或外部广大受众提供的业务服务往往容易遭受常见的互联网攻击，如拒绝服务攻击 (DoS)。TCP/IP 层的网络安全措施可降低此类威胁。这些措施包括 IP 检查、测量调用频率以及在超出阈值时进行阻塞。然而，这意味着无法完全阻止 SOAP 协议调用导致的应用程序服务及相关 HTTP servlet 泛滥。

作为一种通过互联网向有限制的用户范围提供服务的典型安全性变体，SSL 协议通常与 X.509 客户端证书结合使用。因此，用户范围缩小到了持有为此发行的证书的用户，以降低发生互联网威胁的可能性。

确保可用性

公共 SOA 接口通常需要全天候可用，不出现任何故障。为确保这种最高级别的可用性，需要为 Web 服务配备松耦合模式以支持基本的无状态实现。这样可以大大简化 SOA 基础架构，使可扩展性和集群功能更易于实现。

使用高度可用的 ESB 产品作为服务调用的“入口点”，有助于实现强大的分离操作，减少后台中异步的、基于队列的、延时处理的服务。通过这种方法更容易维持系统实现的持续可用性，同时简化 SOA 中所有已连接系统的维护工作。DevOps 交互 [REF-4] 就是一个不错的例子。

保密性

保密性是信息安全的一个重要特性，可以防止未经授权的信息泄露。加密和权限或访问管理是维护信息技术保密性的主要手段。

保密性与加密

保密性或防止对敏感数据进行未经授权的访问，可以通过加密实现。加密（编码）[REF-5] 被定义为在“密钥”（仅对拥有此密钥的用户解密）的帮助下将纯文本消息转换为秘密消息。由于在传输密钥的同时保密的难度较大，采用私钥和公钥的异构 RSA 过程 [REF-6] 成为了主流。

密钥管理的挑战

因为需要为加密（保密性）和签名（真实性）提供消息密钥，所以需要在 SOA 基础架构中提供高效的密钥管理。遗憾的是，大多数基础架构中的密钥都是随意存储的，分布于整个领域的各个角落。这种随意的传播会导致反复失败，因为发布的密钥证书有过期日期，而管理员会忘记密钥的存储位置和更新时间。通过使用 XML 密钥管理规范 (XKMS) [REF-7]，服务或安全代理可以促进在结构良好的 SOA 基础架构中实现集中密钥管理。

“用于 Web 服务消息加密的 SSL”反模式

使用 SSL 实现 SOAP 协议安全性与实现端到端安全性的目标不相符，因为只能保护调用者和 HTTP 服务器之间的路径。在其中一个中途停留点（通常是 ESB 或 BPEL 或 BPMN 引擎）中，消息内容未加密，因此未经授权的人员可以进行查看或修改。由于其易于使用的操作，故 SSL 依然是深受外部使用者和公共业务服务欢迎的选择。然而在内部，由于既定的准则有不足之处，通常不对技术消息进行加密。

端到端的安全性始终是高度敏感数据所必需的，不仅要求对连接协议进行加密，还要求对 SOAP 或 REST 消息本身进行加密，就像在 SSL 中那样。消息（负载）加密通常导致 SOA 基础架构出现问题，因为这些内容无法用于逻辑控制，如基于内容的路由。结果，证明对关键、敏感的内容（如仅包含配置数据的元素）进行部分加密是最佳实践。

WS-Security 标准可以为部分消息加密和签名提供必要的框架，以便证明发送方身份真实性，虽然 SOAP 的范围和复杂性也会显著增加。因此，通常使用代理模式和基础架构中集中实现的安全代理实现安全性。大多数情况下，使用 Corisecio、Layer 7 和 Vordel 提供的 XML 安全网关。

使用集成的角色和权限概念实现访问控制

对敏感和加密内容的访问必须由中央角色和权限系统在可互操作的 SOA 中实现，OASIS 的可扩展访问控制标记语言 (XACML) 为此定义了一项标准。采用标准化方式向授权用户描述对资源的访问控制，即谁有权执行哪些控制以及何时执行。

在典型的 SOA-XACML 部署场景中，授权通过中央权限服务（访问控制服务）访问服务操作或请求资源。理想情况下，代理互连到该服务作为安全代理，在安全术语中用策略执行点 (PEP) 来表示。

提供访问之前，通过集中配置的权限服务或策略决策点 (PDP) 用 XACML 格式标识 PEP，这将根据已定义的 XACML 规则确定是否使用访问属性。答案以 XACML 格式返回代理 (PEP)，该服务决定如何具体实现权限属性。

完整性

消息密封

密封最容易确保消息的完整性和不可变性。密封被破坏表示消息已更改，这就要求接收方记录日志并拒绝该消息。此类密封在技术上称为数字签名，通过两步操作即可生成。第一步是使用安全散列算法，这是一个根据消息计算得出的唯一值，用作输入参数或消息摘要。安全散列算法（SHA1，在 RFC3174 中已标准化）本身是为计算而制定的。

在第二步中，按照 W3C XML 签名语法、处理和加密规范中定义的过程，使用私钥加密摘要，并将摘要链接到证书和发送方的消息。幸运的是，使用 Web 服务堆栈时，例如 Metro、CXF、高价值的 ESB 或基于策略的安全解决方案（理想情况下），没有任何复杂的 API 编程。

真实性

术语“真实性”被定义为确保通信参与者是他或她所声明的那个人的属性。由于当前 SOA 环境往往在验证真实性时缺乏彻底性，我们将介绍缺乏真实性将以哪些方式对 SOA 产生影响，同时推荐一些解决方案。

“用户名/口令身份验证”反模式

当在有限的时间内面对适用的安全要求时，SOA 开发人员会匆忙地将安全特性编程到服务中，不会过多考虑技术影响。正如 Web 服务安全规范 (WSS) 所述，人们经常提到的编程错误是仅为身份验证机制提供用户名和口令安全。如果仅初始服务调用受影响，这通常不是问题。

然而，应针对流程（如 BPEL 或 BPMN 2）编排服务以提高灵活性，这将形成复杂的调用链。用户名和口令安全性将意味着，除了用户名外，口令也需要在业务流程的各个服务中以纯文本形式存在或以另一种方式确定。这些环境从管理和安全性角度是无法接受的，这将引发一个问题，那就是在不更新口令输入的情况下，如何在整个流程环境中不断维护上下文安全。

使用令牌和证书进行身份验证确认

作为稳定的身份验证的前提，所有需要得到保护的服务用户都应拥有一个唯一的 ID，无论这些用户是人员还是服务组件。这种“基于证书和令牌”的安全流程基本已确定可以在 SOA 领域中传输调用者身份，而且也渐渐应用于社交 Web 应用程序。在该流程中，用户使用 SSO 保护的门户或安全令牌服务 (STS) [REF-8] 登录中央身份验证服务，该服务通过连接的 Access Manager 检查用户凭证。这可以通过口令输入、证书、芯片卡或生物识别身份验证机制执行。

身份验证服务使用 STS 创建所需令牌，可以是 X.509 证书、Kerberos 票证、OAuth 令牌甚至 SAML 断言，然后用标准化的安全断言标记语言 (SAML) 安全交换格式 [REF-9] 打包。该程序包包括用户身份或“主题”，可以从入口点传输到终端系统，以便进行安全性查询和日志记录。

因此，SAML 可以对 XML 安全结构进行标准化，使其能够用于在 Web 服务安全规范以内和以外交换 WSS SOAP 头中的安全信息。关于安全性，SAML 提供的互操作性允许建立跨组织的安全通信，因此，从一开始就应当在架构规范中规定利用 SAML 和 STS 实现安全性。

身份验证和安全上下文传输

与 SAML 相结合，WS-Security 标准已经确定可以在 SOAP 消息中传输身份信息。该标准介绍了标准化 XML 结构如何与标识信息一起打包，以及如何在 SOAP 头中传输。

在功能代码中使用用户名

如果服务使用上述标准机制之一实施安全准则，而标准机制中立地用于功能性服务实现者并处理上游安全任务，则会引发一个问题。功能性服务实现或组件如何接收相关的用户信息？这在很多情况下都是必需的，例如，如果实现组件只能返回或更改由于功能原因（例如，访问数据库上的服务最终会要求“正确的”用户）指派给用户的数据。

如上所述，在与安全头平行的负载中传输用户名是最低效但最常见的方法。安全上下文必须传入功能性组件实现。理想情况下，服务本身应将服务生命周期接口作为 JAVA EE 组件 [REF-10]、.NET 组件、Spring 组件或代理实现。

安全上下文会根据配置自动传播。尽管该流程看起来符合逻辑，但经常会违反设计原则，而且用户名通常会（例如，作为服务或方法参数）并行传输到应用程序中。

SOA 安全基础架构

服务实现与安全特性相混合会带来许多麻烦。安全性相关的功能逻辑和技术逻辑应当严格按照相应的分离原则进行分离。这些逻辑特性所需的技能与服务编程所需的技能截然不同，它们彼此混合会导致服务难以维护。

因此，建立 SOA 安全基础架构时，必须在所有层面上将应用程序和安全逻辑相分离。这种横截面特性主要通过实现 facade、代理或包装器设计模式或通过使用策略来实现。这支持在实现服务时分离功能逻辑，如果要求允许，也可以使用不同的安全性实现封闭和配置功能逻辑。

由于我们认为这项原则对于实现安全性至关重要，以下部分将探讨如何通过基于策略的安全架构单独实现安全特性。

安全性与基于策略的管理

除了应用程序组件中的隐性安全性，例如 WS 体系中的安全性，基于策略的管理 (PBM)（如图 1 所示）逐渐占据横截面安全管理的主导地位。这是因为基于特性的安全准则在系统中难以维护，甚至在 SOA 环境中变得越发复杂。

一般情况下，PBM 表示整个横截面 IT 系统管理及其使用策略和代理的配置。策略定义行为准则，主要在中央库中创建，与应用程序或服务并行存储。因此，策略中包括的规则可以由代理和网关在安全性相关点上实现，例如 Web 服务、BPEL 等。如果有从策略决策点 (PDP) 动态传递给代理的加密策略，那么 Web 服务中的代理将利用获得的信息加密 SOAP 消息。

在这种情况下，Web 服务本身不必在 Java EE 部署描述文件中实现安全性或配置复杂的安全性构件。如果安全准则发生了变化，无需更改、重新部署或重新调整 Web 服务。典型的产品包括 IBM Tivoli Security Operations Manager、Oracle Web Service Manager (OWSM) 以及 Open Source Talend ESB Suite 中的集成策略管理。

基于策略管理的组件

在 PBM 中，策略执行点 (PEP) 负责在系统或服务中解释和实现授权决策。可扩展访问控制标记语言 (XACML) 已被视为面向访问控制请求的标准语言。因为 XACML 定义 SAML 配置文件，所以 XACML 也在 SAML 中用于交换授权信息，促进中央访问管理组件的连接。

通过安全网关或代理概念在调用者和执行者之间的运行时组件中实现 PEP（如图 2 所示）。它们通过中央策略库的策略决策点(PDP) 动态创建配置的和必需的安全特性，并在实际服务调用之前执行这些特性。

除了身份验证、授权和加密之外，代理和网关还可以向 SOAP 消息发送信号并执行日志记录操作。策略通常由 XML 标准 WS 策略 [REF-11] 描述，在应用程序管理员的中央治理库中以图形方式维护，而不是由 SOA 开发人员维护。此组件表示为策略管理点 (PAP)。

策略决策点 (PDP) 表示使用提供的安全策略做出授权决策的组件。决策点通常从代理或网关 (PEP) 接收消息，从信息库识别要使用的策略。PDP 还识别和解决不同策略中的运行时冲突。因此，策略决策点也可以在访问管理中表示为立法权。

在更改或扩展之后，根据要求由推或拉机制发布策略。推方法更受欢迎，因为更改可以通过这种方法从管理服务器传递到 PDP。由于没有通过 PBM 更改策略的物理服务部署，所以带有工作流机制（包含不受时间限制的、按发布和激活执行的分布与批准例程）的治理支持管理组件或策略管理点 (PAP) 是必需的。

图 1：基于策略的管理 (PBM)

使用代理概念会导致需求的不良副作用在部署过程中被植入各个服务的调用管道中。因此，除了代理概念，通常还需要使用简化的安全性网关概念。安全性通过作为代理组件的上游中央安全网关实现，该网关可以拦截所有调用、执行策略以及传递到原始服务。尽管此概念在安全方面不像代理概念那样稳健，但其安全管理非常简单：

安全网关和服务之间有一个有可能被操控的网络路由。然而，代理概念可以集成到服务中，因此更安全。
安全网关不能将安全上下文传递到服务或实现组件中，尽管代理可以建立符合 Java EE 或应用程序专用的安全上下文。
由于端口位于中心位置，安全网关通常可以生成一个更大的系统负载，这一点必须考虑在内。

图 2：网关和代理安全基础架构（资料来源：Oracle）

通过 XKMS 建立公钥基础架构

RSA 不对称加密系统通常用于验证和确保真实性，而公钥需要在公钥基础架构 (PKI) 中进行管理。相对于将密钥存储在文件系统或并行操作的应用服务器中，在 SOA 中使用相应的服务管理密钥看似比较合理。

正是出于这个原因，万维网联盟制定了 XML 密钥管理规范 (XKMS) [REF-7]，此规范可以定义一个为服务提供 PKI 功能的协议。XKMS 由两部分组成。XML 密钥信息服务规范 (X-KISS) 定义密钥的搜索、获取和验证方式，而 XML 密钥注册服务规范 (X-KRSS) 则指定按服务注册密钥的方式。如上所述，如果不运用 XKMS，密钥会随意地分散在文件系统的各个角落，令管理员很难进行适当管理。

REST 与安全性

本文介绍的 SOA 安全标准在 REST [REF-12] 架构样式中只能得到有限的利用。REST 服务样式主要应用于基于资源的 URL 服务，此类服务使用已知的 HTTP 协议动词，例如 GET、POST 和 DELETE，意味着用于 REST Web 服务的安全概念与用于标准 Web 应用程序的安全概念相同。

由于广泛的互联网支持特性，OAuth 2.0 [REF-13] 通常用作令牌服务，用于 Web 应用程序授权以及基于资源的 REST 服务。然而，提供的令牌必须能够交换以实现 Web 应用程序和后端 SOAP 或 REST 服务之间的互操作通信。在此架构中，利用安全令牌服务（STS [REF-8]，作为基础架构元素）可以轻松转换或验证令牌，因此可以跨域和技术边界实现联合安全性。