本红皮书是面向服务的体系结构(SOA)系列之一，主要通过名为JKHL Enterprises(JKHLE)的虚构公司阐述一个案例研究。本红皮书中的案例研究重点说明与SOA安全性和管理相关的挑战和解决方案。本红皮书描述如何使用“SOA安全性和管理场景”的实现和解决方案模式来解决与该案例研究相关的业务和IT挑战。

　　我们在本文中介绍的案例研究包括以下人员和角色：

　　·Sandy Osbourne-Archer，首席技术架构师
　　·Edmund Smythe-Barrett，企业架构师
　　·Steve Optman，IT 运营经理
　　·Axel Setrust，安全架构师
　　·Budi Manmon，管理架构师

　　帐户开立项目的挑战

　　JKHLE已经部署了一个成熟的管理环境来管理现有的应用程序。帐户开立项目中新引入的共享服务、流程和组合应用程序带来了新的管理挑战。本文讨论与保护和管理应用程序服务以及与用于帐户开立项目案例研究的支持基础设施相关的挑战和解决方案。

　　IT运营经理Steve Optman与首席技术架构师Sandy Osbourne-Archer进行会谈，讨论帐户开立项目的安全性和管理挑战及目标。Steve提出了对运营团队当前无法及时了解帐户开立项目设计情况的担忧。Steve重点强调了从一开始就参与到流程中的重要性，这样可以避免他的运营团队因延迟参与投入运行之前的一些部署而遇到的问题。Sandy赞同并承诺在开发周期中尽早让运营团队参与进来。

　　Sandy概述了运营团队在部署本项目时需要满足的三个关键安全性和管理目标：

　　·发现资源和服务

　　需要提供一种自动化方法来发现服务注册中心中定义的应用程序组件、中间件和服务。需要将从发现过程中捕获的数据提供给现有的更改控制流程。

　　·在通用管理控制台中监视服务

　　需要以一种与现有管理环境和通用管理控制台一致的方式监视帐户开立流程应用程序服务和支持基础设施。

　　·安全性和遵从性审核功能

　　需要端到端的安全性以及能够提供审核记录，以确保满足遵从性要求。

　　Sandy建议Steve及其运营团队直接与企业架构师Edmund Smythe-Barrett合作。

　　Edmund负责帐户开立项目应用程序和支持基础设施的体系结构和设计。

　　帐户开立项目的要求

　　Steve安排与Edmund、安全分析人员Axel Setrust和管理架构师Budi Manmon会面，检查帐户开立项目体系结构并概述关键安全性和管理设计点（请参见图1）。

　　图1 SOA安全性和管理部署体系结构的注意事项
 
　　简而言之，反向代理部署在隔离区(DMZ)中。

　　此处的门户用于提供表示层和使用ESB或直接与流程服务器及后端应用程序进行交互。客户端可以是企业内部和外部的用户或服务使用者。

　　类似地，应用程序和服务既可以属于企业内部也可以属于企业外部。

　　在部署体系结构中的各个点上强制执行安全性。

　　在从帐户开立流程门户中使用时，Edmund引用了客户概要服务（请参见图2）。Edmund解释说，此事务在应用程序体系结构和支持基础设施中具有代表意义。简而言之，在客户从门户中输入概要信息之后，客户概要服务（中介）就会与由CICS后端系统承载的帐户记录应用程序进行交互，用于存储客户概要信息供进一步处理。

　　图2帐户开立流程门户——客户概要服务
 
　　Steve介绍了帐户开立项目SOA的采用将如何创造竞争优势。Steve强调说，为降低成本和确保遵从性，高效的安全性和管理解决方案非常重要。

　　他解释说，成本降低包括更高效地管理JKHLE环境的大量资源，从而使运营团队能够以同样的资源提供更多管理支持。

　　Steve看到JKHLE面临着无法准确掌控业务和技术资产的挑战。需要实施足够的管理才能有效地管理所有资产。缺乏足够的管理会导致不必要的风险，以及无法有效地满足遵从性和审核要求。此外，往往还会出现重大操作中断。

　　Steve解释说，IBM Service Management跨业务和技术资产提供了集成的可见性、控制和自动化，可帮助您克服业务和技术集成方面的障碍，以及妨碍创新的因素。IBM Service Management产品组合包括与ITIL保持一致的工作流、基于标准的配置管理数据库、与基础设施保持一致的自动化任务、最佳实践以及实现支持。

　　注意：您可以在以下位置找到有关IBM Service Management的更多信息：

　　http://www.ibm.com/itsm

　　运营团队计划利用IBM Service Management解决方案和产品来支持帐户开立项目和其他活动。帐户开立项目的安全性和管理解决方案将重点关注图3中所示的IBM Service Management Operational Management和Service Management。

　　图3 IBM Service Management上下文中帐户开立项目重点关注的内容
 
　　SOA Management的要求

　　运营团队了解到JKHLE业务流程将越来越多地依赖于构成跨越多个体系结构层（包括服务使用者、业务流程、服务、服务组件和操作系统）的多层组合应用程序的共享服务。Steve和Budi知道，此管理解决方案需要包括用于管理和监视SOA组合应用程序和用于支持跨多个体系结构层的基础设施的软件和解决方案。

　　Steve概述了在整个管理生命周期中需要执行的关键任务。图4重点介绍了这些任务的关键输入、用户角色和这些任务的构件输出。虽然这些任务是采用自顶向下的方法显示的，但是这些任务中许多都具有迭代性。

　　Budi重点介绍了部署体系结构的关键SOA管理要求（请参见图1）。

　　REQ-01：标识要管理的服务和资源

　　标识需要通过帐户开立流程门户管理的服务和资源。JKHLE已经部署了许多现有的系统和资源。一项关键管理要求是了解如何标识或发现应管理哪些服务和支持资源。

　　REQ-02：自动发现资源

　　提供了一种自动化方法可以发现服务注册中心中定义的应用程序组件、中间件和服务。从发现过程中捕获的数据将提供给现有的更改控制流程。

　　REQ-03：将服务作为资源对其进行管理和监视

　　为达到业务定义的服务质量，每个服务终端都需要作为一项资源来管理，包括调用服务（使用者）和将应用程序功能公开为服务（提供者）。解决方案必须能够提供实时可用性和性能指标，以及定义的服务水平协议。

　　管理基础设施需要提供一种监视和故障排除方法，若能在故障发生之前发出警报则更好。监视包括实际用户通信量，以确保SLA一致性和监视综合事务。综合事务用于确保环境以一致的方式处理一组受控交互，这一点作为根本原因分析的基准是非常有用的。

　　Budi重点介绍了几个有代表性的监视示例：

　　·监视客户概要服务事务以确保其响应时间不超过5秒。
　　·监视客户概要服务（服务使用者和提供者，应用服务器和后端系统）所用的基础设施的可用性。

　　REQ-04：在集成控制台中监视端到端视图

　　在孤立的应用程序体系结构中，资源通常是由不同的操作人员或专家在多个不同的管理控制台中管理的。帐户开立流程门户代表了需要转变管理方法的SOA组合应用程序。需要通过以下方式监视和管理基础设施：既涵盖组合应用程序的端到端视图，又提供有关各资源的性能和可用性标准的详细信息。

　　SOA安全性的要求

　　Axel负责安全基础设施。Axel得出了两项与安全性相关的观测结果：

　　·因为部署体系结构中的每个组件都强制实施了安全性的某一方面，所以可能存在多种标识、身份验证、授权和审核机制。集成安全机制将成为一项挑战。
　　·特定的产品有多个管理岛，这往往会导致错误、不一致和缺乏协作。管理可能会以资源为中心，策略管理可能会独立于业务单元、应用程序或产品。

　　安全性管理在需要跨多个组件实施一致策略的SOA环境中会是一项挑战。

　　Axel重点介绍了SOA部署体系结构的关键安全性要求（请参见图1）。

　　REQ-05：标识提供

　　在JKHLE环境中，开立了一个新帐户之后，标识将提供给多个中间件和后端系统。解决方案需要提供和管理标识，从中央系统到外部系统。

　　REQ-06：标识传播

　　当用户与门户进行交互时，用户标识需要在整个事务中进行传播，无需多次登录即可传播到后端系统。在某些情况下，现有的系统将拥有并不完全相同的用户ID，或者外部用户将使用不同的协议绑定与门户进行交互。在这些情况下，保护业务数据和为标识、数据等建立业务信任关系是非常重要的。请求可能来自外部实体，因此安全域可能是交叉的。

　　需要在整个事务中传播标识，无论体系结构中有多少个跃点。

　　REQ-07：身份验证

　　当用户或系统与门户进行交互时，需要对标识进行身份验证。在对用户进行身份验证之前，需要设置一个代理来首先对用户标识进行质询。在代理上派生的标识需要到处传播，以便可以强制执行更多安全检查（如授权和审核）。此解决方案需要提供身份验证服务，能够通过单点登录功能从门户登录到多个后端系统。

　　REQ-08：授权

　　安全解决方案需要确保用户能够访问基于用户或系统标识确定的许可信息。许多组件可能都需要授权，其中包括粗粒度的基于服务的授权到细粒度的数据级访问控制。

　　REQ-09：审核

　　JKHLE必须确保采用了适当的控制来满足法规遵从性要求。需要沿着事务路径将审核信息从每个组件中收集起来。审核信息将被记录，并可用于实时、法律审查和报告，从而能够满足法规遵从性要求。

　　REQ-10：传输和消息级安全性

　　需要保证信息和业务数据在传输以及存储过程中的安全。需要提供机密性保护来确保消息数据不可访问且无法被其他人修改，从而确保消息的完整性。数据保护策略往往会指明需要在传输和消息级别采用哪种类型的保护。

　　注意：有关解决方案的详细信息，请参阅“传输和消息级别安全性”。

　　将SOA场景模式应用于案例研究

　　本部分描述了如何使用“SOA安全性和管理场景”实现模式来解决与帐户开立项目案例研究的安全性和管理相关的业务和IT挑战。

　　Steve安排与Sandy和运营团队的主要成员会面，介绍用于支持帐户开立流程门户应用程序部署的安全性和管理解决方案。

　　SOA管理

　　Steve有一个目标，希望通过此次与Sandy的会面实现以下两个目的：

　　·确保Sandy对支持定义的目标和要求的高级别管理解决方案有个大体了解。
　　·深入了解有关帐户开立流程应用程序服务和支持基础设施的发现和监视的更多详细信息。

　　为深入分析目的，Steve建议使用客户概要服务（请参见图2），因为该服务是部署体系结构和管理解决方案的代表。

　　建议的解决方案

　　Steve让Budi向Sandy详细介绍管理解决方案，并从说明如何标识要管理的资源开始。Budi解释说，可以采用两种基础方法来确定要管理的资源，即在分析和设计过程中确定资源和在运行时通过发现确定资源。这两种方法常常一起使用，但是也可以独立使用。

　　在分析和设计过程中确定资源

　　在分析和设计时基于非功能性需求和SLA确定要管理的资源。此方法需要了解应用程序体系结构和支持基础设施。

　　此方法包括以下几项高级任务：

　　·标识服务和端到端事务

　　包括标识关键服务、事务和流程。分析非功能性需求和SLA在确定应管理哪些服务过程中起到关键作用。在帐户开立流程门户中，客户概要服务与CICS后端系统进行交互。IBM Tivoli Service Level Advisor将记录并报告服务水平协议。例如，SLA规定事务的响应时间不应超过5秒，IBM Tivoli Composite Application Manager for SOA将对服务的响应时间进行监视，以确保达到SLA要求。

　　·确定SOA基础参考体系结构中的资源

　　在多个体系结构层中，帐户开立应用程序的服务、流程和支持基础设施将作为资源被管理。

　　Budi解释了如何分解多个体系结构层中的客户概要事务（请参见图5）。这些信息用于对适当的管理软件建立映射以管理资源。

　　·确定监视确定的资源所需的标准

　　在确定了服务事务和管理产品的资源类型之后，企业架构师和管理架构师能够与IT管理人员和SME一起根据已定义的特定标准来监视资源。SLA通常包括监视资源所需的关键标准。

　　图5在SOA基础体系结构层中确定要管理的资源
 
　　发现资源

　　在定义了标准之后，运营团队计划执行资源的自动发现来获取管理资源所需的附加信息。资源的发现包括应用程序组件和服务、基础设施资源，以及在服务注册中心中定义的服务。

　　现有的IBM Tivoli Monitoring Server提供了一个用于与其他监视产品集成的基本管理框架，以及一个被称为Tivoli Enterprise Portal的通用监视接口。Tivoli Composite Application Manager系列产品用于发现和监视特定类型的应用程序组件、服务和支持基础设施的资源。Tivoli Composite Application Manager产品配置了Tivoli Monitoring Server，可以在通用Tivoli Enterprise Portal(TEP)控制台中发现此类资源并在其中对这些资源进行管理。

　　Tivoli Composite Application Manager for SOA将用于发现和监视Web服务和ESB。Tivoli Composite Application Manager for SOA会安装到Tivoli Monitoring Server环境中。当Tivoli Composite Application Manager for SOA Agent在目标应用服务器上运行后，可以运行此应用程序。在使用Web服务或ESB中介的情况下，Tivoli Composite Application Manager for SOA的发现组件将检测服务的名称和操作，并在Tivoli Enterprise Portal中显示这些信息。在配置用于监视响应时间和使用率这样的度量服务的Tivoli Enterprise Portal境况时需要这些信息。还可以通过与IBM WebSphere? Service Registry and Repository集成发现服务。

　　监视

　　图6描述了将用于监视运行时环境的管理逻辑体系结构。环境中有许多其他后端系统；但是，应用程序体系结构代表了部署环境。

　　图6用于帐户开立流程门户的SOA管理解决方案
 
　　现有的环境包括图6中显示的许多管理组件。主要添加了以下组件：

　　·添加了Tivoli Composite Application Manager for SOA，用于管理和监视服务使用者和提供者，包括监视ESB中介和Web服务。
　　·需要添加Tivoli Composite Application Manager for Response Time Tracking来管理端到端的事务性能，从客户端一直到后端CICS。
　　·Tivoli Composite Application Manager for Response Time用于进行用户监视（用户响应时间、记录和回放综合事务）。

　　表1列出了将用于监视帐户开立部署环境的资源的自定义Tivoli Enterprise Portal工作区。

　　表1 Tivoli Enterprise Portal工作区摘要

　　工作区可以链接在一起，这对于进行根源分析来说可能非常有用。

　　考虑服务响应时间超过监视的境况的事件。根源是承载服务的应用服务器停止。可以将工作区链接在一起以深入研究从Situations Event Console中的服务响应时间事件到WebSphere Application Server—Log Analysis视图middleware工作区。

　　在分析、设计和发现过程中从资源的标识中收集到的信息和标准用于创建Tivoli Enterprise Portal境况。Tivoli Enterprise Portal境况是根据阈值对一组属性进行测试的条件。该境况按照预先定义的间隔对条件进行评估，并调用Tivoli Enterprise Portal中相应的自动响应和通知方法，如事件消息或采取措施。随多种IBM监视产品提供了许多预先定义的境况，可以按“原样”使用这些境况也可以对其进行自定义。

　　Budi列出了将用作触发事件的一些主要境况（请参见表2）。

　　表2用于触发事件的主要境况

　　图7显示了Main Tivoli Enterprise Portal工作区，该工作区提供了管理的资源的集成视图。当触发了一种境况后，Situation Event Console视图中将显示事件。

　　图7 Main Tivoli Enterprise Portal工作区——资源的集成监视视图
 
　　SOA安全性

　　Sandy已请求与Steve和Axel会面来检查支持定义的要求的安全性解决方案设计。

　　建议的解决方案

　　Axel说明了团队如何应用IBM SOA安全参考模型（请参见图8）来满足帐户开立应用程序和支持基础设施的安全要求。IBM SOA安全参考模型更广泛的上下文是用于保证服务、应用程序和资源安全的IBM Service Management的子组件。

　　图8 IBM SOA安全参考模型
 
　　高度概括地讲，此模型定义如下：

　　·业务安全服务（Business Security Services）包括管理业务的需求，如信任、标识和访问管理，数据保护，遵从性和报告，不可否认性，安全系统以及网络。
　　·IT安全服务（IT Security Services）描述用于保证服务安全的SOA基础结构的基础构造块。安全服务包括标识、身份验证和授权、机密性、完整性，以及审核服务。
　　·安全支持（Security Enablers）包括IT安全服务使用的加密、目录和密钥存储库等技术。安全策略管理包括管理、强制执行和监视安全策略。
　　·治理和风险管理（Governance and Risk Management）提供实现和强制执行安全策略的机制。治理可帮助客户在整个组织中管理SOA。风险管理用于处理评估风险并制定管理这些风险的策略的流程。
　　·安全策略管理（Security Policy Management）是总体策略管理的一部分，用于清楚表述、管理、强制执行和监视安全策略。

　　标识提供

　　帐户开立流程门户包括许多后端系统。出于参考目的，可以考虑调用客户概要服务与CICS后端系统进行交互的帐户开立流程门户应用程序。

　　简而言之，由帐户开立流程门户使用的WebSphere Portal、WebSphere Application Server和WebSphere Process Server共享一个由IBM Tivoli Directory Server实现的通用LDAP用户存储库。CICS将RACF用于安全服务。在帐户开立流程门户中创建了一个新帐户之后，LDAP用户存储库中会创建一个新标识，并且会在RACF中通过IBM Tivoli Identity Manager创建一个新标识。在有些情况下，IBM Tivoli Directory Integrator用于创建标识。在企业环境中，不同的系统强制执行不同的标识命名约定和策略是很普遍的。例如，用户标识jsmith是在LDAP目录中创建的，而joesmith是在RACF中创建的。

　　标识传播

　　作为从门户到后端系统的请求流的一部分，服务使用者可以通过ESB与提供者进行交互。用户的可信标识需要在整个应用程序中流动。应考虑标识的格式可能需要进行转换。此外，表示用户的标识在多个系统中可能不同，可能需要在多个系统间进行映射。

　　能够使用几种解决方案模式来传播标识。该团队决定使用通过IBM Tivoli Federated Identity Manager实现的安全令牌服务来执行格式转换和标识映射。需要WebSphere（Application Server、Portal Server 和 Process Server）来携带RACF用户ID和传递票证。在将请求发送到CICS（或其他后端系统）之前，需要使用安全令牌服务对WebSphere中的身份验证标识进行映射和转换，安全令牌服务可以将传入用户名jsmith(WebSphere/LDAP)映射为CICS所用的RACF用户ID joesmith。安全令牌服务还会为该用户生成RACF传递凭证。

　　根据WS-Trust规范，到安全令牌服务的接口也是一项服务。从LDAP ID到RACF ID的标识映射是通过在LDAP中查找此ID完成的。

　　身份验证服务

　　需要使用身份验证服务来与不同的域、不同的平台和不同的服务进行集成。运营团队确定用户标识符和密码身份验证。参照由IBM Tivoli Directory Server和IBM Tivoli Access Manager实现的基于LDAP的用户存储库对用户标识进行检查。

　　在JKHLE环境中，第一个身份验证质询在用户访问门户时发生。IBM Tivoli Access Manager—WebSEAL组件用于实现反向代理，反向代理充当门户和其他Web应用程序的联系人的联合单一登录点。使用上述反向代理，由于身份验证逻辑存在于Tivoli Access Manager WebSEAL层中，因此可以在将来支持更复杂的身份验证机制，而无需修改Web应用程序。

　　注意：运营团队正在评估使用IBM WebSphere DataPower来实现增强的处理能力。WebSphere DataPower可用作处理XML通信、提供消息保护和中介标识的安全代理。

　　ESB在将服务请求传递给服务提供者之前，使用身份验证服务对服务使用者提供的凭据进行身份验证。服务提供者包括中间件应用程序、后端系统和数据服务。

　　授权服务

　　在对用户的标识进行了身份验证之后，可以使用授权服务来确定对资源的适当访问权。

　　授权决策取决于授权策略和身份验证标识。在JKHLE环境中，在针对服务使用者和提供者、应用程序和数据的整个解决方案中使用了多种授权服务。

　　帐户开立流程门户是服务使用者。IBM WebSphere Portal为门户页面和Portlet提供了其自己的授权模式。对于门户和J2EE.应用程序，授权可以是基于角色的。此外，WebSphere Portal能够使门户的授权服务外部化以供IBM Tivoli Access Manager管理。

　　JKHLE环境中有大量需要授权服务的服务提供者类型。J2EE应用程序利用Tivoli Access Manager的授权服务。许多后端系统和应用程序都有其自己的授权服务或使用RACF，如基于CICS的应用程序。数据和数据库也需要授权服务。对于z/OS中的数据服务，使用RACF进行授权。

　　审核服务

　　部署审核服务是为了通过收集审核信息并报告这些信息来理解安全环境运行情况的。大多数IBM安全性和基础设施产品都包括可处理用于报告用途的审核日志功能。运营团队使用IBM Tivoli Compliance Insight Manager来整理、处理和报告审核数据。
　
　　传输和消息级安全性

　　运营团队使用行业标准的传输和消息级安全性。为保证HTTP的安全，可以应用传输级安全性。传输级安全性基于在HTTP下运行的安全套接字层(SSL)或传输层安全性(TLS)。与消息级安全性不同，HTTPS将对整个HTTP数据包进行加密。不存在选择性地对消息的特定部分应用安全性的选项。SSL和TLS提供身份验证安全性、数据保护和对安全HTTP连接的加密令牌支持。

　　WS-Security提供了消息级安全性，可在构建安全Web服务以实现消息内容完整性、机密性和身份验证时使用。来自服务使用者和提供者的数据都通过需要保护的ESB来中转。此操作可通过将WS-Security和传输级安全性与SSL/TLS结合使用，利用机密性服务并选择消息级安全性来实现。

　　总结

　　建议的安全性和管理解决方案体系结构可满足所确定的需求，同时能够重用现有基础设施中的许多组件。此方法提供了一个满足连续遵从性和审核要求的环境，同时促进了采用SOA为帐户开立应用程序带来的业务灵活性。安全性和管理解决方案体系结构为JKHLE继续采用其他SOA项目奠定了坚实的基础，而无需额外的管理开销。