技术开发 频道

SOA案例研究,第9部分:安全性和管理

  本部分描述了如何使用“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 工作区摘要

TEP 工作区工作区描述
Main用于监视跨 SOA 体系结构层的资源的视图。
Services用于管理服务的视图。
Transactional用于管理端到端事务性能的视图。
Middleware用于管理中间件资源的视图。
Operational用于管理操作资源的视图。

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

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

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

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

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

监视层/产品用于监视事件的境况
使用 ITCAM for SOA 监视服务
 
  • 服务(中介)平均响应时间超过 5 秒
  • 消息大小超出范围
  • 中介不能连接到 CICS Gateway (CTG)
监视事务性能 ITCAM RTT
 
  • 通过将事务的每个段与 CICS 后端关联起来监视端到端事务性能。

  图 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 项目奠定了坚实的基础,而无需额外的管理开销。

  总的来说,以下 IBM 产品将用于保护和管理部署环境:

  • 管理:
    • IBM Tivoli Monitoring Server
    • IBM Tivoli Composite Application Manager for:
      • SOA
      • WebSphere
      • Response Time
      • Response Time Tracking
      • CICS Transactions
    • IBM Tivoli OMEGAMON® XE
    • IBM Tivoli Service Level Advisor
    • IBM Tivoli Provisioning Manager
  • 安全性:
    • IBM Tivoli Access Manager
    • IBM Tivoli Identity Manager
    • IBM Tivoli Federated Identity Manager
    • IBM Tivoli Directory Server
      • IBM Tivoli Directory Integrator
      • IBM WebSphere DataPower
      • IBM Tivoli Compliance Insight Manager
0
相关文章