时间：2004-04-19 作者：Paul Patrick 浏览次数： 本文关键字：安全解决方案, 即插即用, 分布式应用, 服务控制

文章工具  推荐给朋友  打印文章

BEA WebLogic Enterprise Security 4.1 为解决企业应用程序出现的分布式应用程序安全问题，提供了一种新型集成化方法。

采用这种基于基础结构的新型分布式方法，应用程序安全将成为应用程序基础结构的一种功能，并和应用程序本身相分离。使用 BEA WebLogic Enterprise Security 部署的任何分布式应用程序，都能够通过即插即用的安全特性，或者通过插入主要安全供应商提供其它专用安全解决方案（客户企业在此基础上实现标准化）而得到安全保障。

本文旨在定义分布式应用程序安全解决方案的主要需求，并解释 BEA WebLogic Enterprise Security 4.1 如何将这些需求提供给您的应用程序。

    随着基于 Web 的应用程序、基于组件的体系结构（如 J2EE）和现在基于服务的体系结构相继出台，导致创建应用程序的方式发生了变化。过去，应用程序可以作为单一实体进行构建，它既包含业务逻辑，又包含一系列嵌入式安全机制。如今，应用程序是在一种分布式环境中，是通过集成一系列为其他组件提供服务的应用程序构建而成的。

但随着这些高度分布的应用程序的不断增加，防止外部人员恶意使用这些应用程序以及控制内部人员活动的能力，继续构成了一种严峻的挑战。这种应用程序构建方式产生的值得注意的影响是，应用程序存在的可以被用于从事恶意活动的潜在进入点数量显著增加了。由于应用程序的各种组件分布于整个企业内，甚至可能跨越了企业的边界，仅在应用程序周围保证安全的传统做法已不再奏效了。仅在应用程序周围采取安全措施，会给心怀叵测的内部人员留下可乘之机，而且导致几乎对应用程序的每个部件都要采取安全防范措施。

为了应对这种挑战，就需要采用这样一种解决方案：它既能够灵活地整合现行应用程序架构与现行安全基础，又能够有效管理旨在调控业务功能访问的策略。应用程序安全不是静态的，因此管理员需要强大的功能来应对日益演进的计算技术和不断变化的威胁环境。他们必须能够确定每个组件在执行它负责的业务功能时所面临的安全态势，必须能够通过交替使用各种安全技术，或通过修改调控资源访问的策略，更新这种安全态势。只有满足了整体安全集成、封装策略实施和响应式管理的需求，应用程序安全解决方案才能够实现这两个目标。

为了减轻繁重的负担，需要采用两种不同的创新技术：基于服务的安全和统一的分布式管理。基于服务的安全这一方面为应用程序容器提供一种通用的安全抽象，另一方面为安全解决方案提供可插入的提供程序接口。当然了，这种灵活性也会在配置服务捆绑和维护一致性策略方面，产生其自己的一系列问题。但采用统一管理方法来避免这些问题，就需要一种健壮的范例，以便同步、传播和分析管理指令。

BEA WebLogic Enterprise Security 是第一个率先通过单一而完整的软件包而提供这两种创新技术的解决方案。它不需要企业更换现有的应用程序容器或现有的安全解决方案。它所做是，允许企业把这些现有的组件组成一个天衣无缝的整体。而且，它易于管理、易于维护和易于扩展。因而，信息技术组织既能够完全看得见，又能够控制安全的各个方面，满足应用程序支持的每种业务功能的需求，这在历史上尚属首创。

作为一种安全基础结构，WebLogic Enterprise Security 的设计宗旨是采用一致的和统一的方法，为整个企业的应用程序容器提供安全服务。它既利用了从成功的分布式系统吸取的许多经验教训，同时又把重心放在可靠性、可用性、可伸缩性和性能方面。此外，对于那些尚未作出应用服务器决策的环境，WebLogic Enterprise Security 也能够完全适合它们。与其它许多产品不同，WebLogic Enterprise Security 不要求客户使用 BEA WebLogic Platform 套件的任何组件，而且，它可以在没有这些部件的环境中使用（请参见图 1）。

WebLogic Enterprise Security 和其它安全解决方案之间存在的一个主要区别是，它使用一种分布式基础架构，从而允许决策点和受保护资源实现同位配置。WebLogic Enterprise Security 不使用集中式安全服务器来确定策略决策，而使用一项专利技术将配置及策略信息分发给受保护资源同位部署的决策点。这样做将避免因网络调用延迟，导致集中式决策点出现性能降级，而且，由于运行时对必须操作和响应的外部进程没有依赖性，将会进一步改进可靠性和可用性。

WebLogic Enterprise Security 基础结构的核心，是一种技术先进的名为 "BEA Security Framework" 的安全框架，它和 BEA WebLogic Server 使用的安全框架相同。因此，这将允许在整个企业中，为与 WebLogic Enterprise Security 利用的 WebLogic Server 一起使用而开发安全服务。此外，采用共用安全基础结构能够为客户提供单一的统一的应用程序安全方法，无论客户是否使用 BEA WebLogic platform 套件。

面向服务的安全性

WebLogic Enterprise Security 方法旨在简化应用程序容器和安全解决方案的集成。应用程序容器是支持组件执行的运行时基础结构。Web 服务器可以充当 CGI、JSP 或 ASP 组件的容器。应用服务器可以充当 J2EE 和 .NET 组件的容器。打包的应用程序充当它们提供的业务功能的容器。使用诸如 Java 或 C 语言编写的独立程序，必须充当它们自己的容器。Web 服务可以运行于框架之上。在这种情况下，框架就是容器，或者充当独立组件。而在后一种情况下，它们就和其它独立程序一样。此时，应用程序组件已把安全功能委托给容器，但 WebLogic Enterprise Security 则是让容器把安全功能委托给它，从而把该过程向前发展了一步。

从原则上讲，特定容器类型的每个实例都能够使用相同的集成接口，由此节省大量的时间和努力。而实际情况会更好，因为所有类型的容器都可以使用这种相同的接口模型。任何类型的安全功能都可能需要容器提供的三类主要信息：请求的安全上下文（如用户名和密码）或任何嵌入式安全性令牌；作为请求目标的资源的标识，如在“Accounts Receivable”(应收帐款)应用程序中，“Customer”（客户）对象的“change address”（改变地址）方法；可选的请求上下文，如代表特定地址和特定客户的请求参数。对所有可能的容器和所有可能的安全功能来说，这三类信息都是相同的。简单地讲，这不过是根据每种容器类型的约定对它们执行编码，并按照正确的顺序，把相关的数据发送给每种安全功能罢了。

图 2 显示了这种方法。当容器接收对受保护资源的请求时，它将调用通用安全抽象过程。然后，该安全抽象过程将调用所有必需的各个安全服务，同时为容器和部件屏蔽细节信息。容器将接收一项决定，指示它应该拒绝或者执行请求。

BEA WebLogic Enterprise Security 的目标是尽可能地方便与应用程序的集成。如果应用程序已经在类似于容器的抽象过程开始执行，它就可能提供收缩包装式（shrink-wrapped）集成。提供开放机制（如 Web 服务器的插件机制）的容器可以用来与 WebLogic Enterprise Security 进行集成，而这种开放机制扩展在处理业务请求的正常流程中可以引入安全决策的容器。。在最初的版本中，WebLogic Enterprise Security 能够为许多容器提供打包集成，其中包括 BEA WebLogic Server 和 Netscape/Sun ONE Web Server。

对独立应用程序而言，每个应用程序必须单独调用 WebLogic Enterprise Security API。对于现行应用程序，开发人员可以使用许多直观的技术增加这种委托功能。这类技术包括使用截取器，改变发送功能，或者创建代理对象，这取决于内部体系架构。对于新应用程序，开发人员可以创建微型容器抽象过程，用它截取请求，调用 WebLogic Enterprise Security 并根据结果采取行动。虽然这些技术都需要增加一定的编程任务，但由于这样做将消除维护所有嵌入式安全码的负担，因此能够取得事半功倍的效果。

服务实现模块集成

BEA WebLogic Enterprise Security 收到应用程序容器的请求之后，将通过一种复杂的内部框架来管理安全处理过程。该安全框架就是在 BEA WebLogic Server 使用的同一种框架。但值得注意的第一个要点是，该框架的每个步骤都须通过一个审核阶段。审核阶段将为执行相关步骤生成一系列完整的事件。一个审核提供程序通过过滤和捕捉这些事件，就能够在必要时创建一个遵守企业策略的细粒度日志。值得注意的第二个要点是，安全处理是一个管道。安全功能按照一个自然顺序来执行，下游步骤需要上游步骤的处理结果。因此，首先必须建立请求者的标识，然后才决定是否允许该标识访问某种资源；首先必须确定标识当前履行的角色，然后才评估是否可以授权该标识对某种资源采取特定操作。在逻辑处理顺序的内部，这项处理功能是非常灵活的。如果出现一种全新的安全功能，WebLogic Enterprise Security 能够通过把它插入管道的适当位置，以透明方式为所有的应用程序容器实现该项功能。

对于在管道中定义的每个步骤，WebLogic Enterprise Security 将调用指定处理该步骤的服务实现模块。如图 3 所示，每种安全服务都有一个相应的服务实现模块接口（Service Provider Interface，SPI），它将定义安全提供程序在提供服务时必须支持的功能。要插入 WebLogic Enterprise Security，安全解决方案只需要为它知道如何提供的服务提供 SPI 实现。在许多情况下，这些接口只由一个包装器组成，它是由解决方案提供商为现有客户机制而提供的。利用 WebLogic Enterprise Security 的通用安全抽象过程，企业就能够以透明而有效的方式切换到备选的服务实现模块，把现有的提供程序升级至新版提供程序，甚至可以实现其自定义的提供程序来处理特殊情况。

WebLogic Enterprise Security 为仅使用框架 SPI 的安全服务包括了安全服务实现模块。通过相同的 SPI，还可以创建安全服务的其它实现，并把它们集成到底层框架的设备内。这些简明的 SPI 允许随着安全生态的日益演进，插入和拔出不同的安全提供程序，进而使有关各方都能够从中受益。尽管 BEA 公司能够单个升级 WebLogic Enterprise Security 附带的提供程序，但安全供应商通过为适当的 SPI 执行产品编码，就能够轻而易举地使他们的服务供所有支持的容器使用。甚至，企业在必要时，可以快速实现定制的安全处理技术。

BEA WebLogic Enterprise Security 体系结构

安全服务模块

WebLogic Enterprise Security 提供称为安全服务模块（Security Service Modules，SSM）的通用安全抽象。一个 SSM 实例包括容器的接口、安全框架及为该实例配置的所有服务实现模块。每个 SSM 实例都支持一个容器实例（请参见图 4）。

每个 SSM 都需要其服务实现模块的配置及其相应的策略信息。一旦安装并将 SSM 注册到管理服务，就要执行初始配置。然后，随着服务实现模块的更换和策略的演变，就会执行更新。由于某些应用程序的执行可能涉及到 100 个不同类型的服务器，而每个服务器有容器的多个实例，因此显而易见的是，这需要一种先进的管理方法。

服务控制模块

第一个先进之处是在相同机器上，聚集跨许多实例的管理操作。在大多数企业体系结构中，用同一机器运行 Web 服务器或应用服务器的多个实例是常见的情形。在某些情况下，功能特别强大的服务器可能会在同一机器上运行不同类型容器的实例。显然，如果每个实例都直接和管理系统进行通信，则该机器将会重复消耗大量的资源。更有甚者，许多类型的容器允许管理员动态创建和删除实例，所以 WebLogic Enterprise Security 需要一种工具来控制相应 SSM 实例的创建和删除。因此，可能运行 SSM 的每台机器都配备一个服务控制模块（SCM），如图 5 所示。

管理服务器

BEA WebLogic Enterprise Security 在管理服务器上维护命名配置。除了分配给配置的服务实现模块外，它还维护该配置管理的所有受保护资源的层次结构。该层次结构可以包括应用程序组、应用程序、部件、对象和方法的级别。这样，策略就能够应用到该层次结构树的任何级别。在这个树上，资源是通过它们的先辈来继承策略的，虽然管理员可以超越这种继承。所有的配置、资源和策略信息，均驻留在策略存储器内，它们可以是 Oracle 数据库或 Sybase 数据库。该策略存储器还维护有关管理角色和特权方面的信息。WebLogic Enterprise Security 有一个旨在保护应用程序资源的管理资源树。管理资源树有四个主要分支：（1）对用户和组的操作；（2）对策略的操作，用于角色分配和授权；（3）对受保护资源定义的操作；（4）对服务实现模块配置的操作。每个分支均可以进行细分。其中，分支 1 有对应于用户和组层次结构相对应的子部分，分支 2 和分支 3 有对应于资源树的子部分，分支 4 有对应于配置树的子部分。资源层次结构的任何一组分支，都可以指派一名管理员，负责创建、读取、更新或删除特权。除分级上的这种灵活性外，WebLogic Enterprise Security 还提供管理方面的其它特性。

结束语

BEA WebLogic Enterprise Security 不会将苛刻的安全模型强加给企业，从而妨碍应用组件与安全服务的集成，迫使企业代价昂贵地处理、混合安全码与业务逻辑。相反，它为企业提供了一种开放式框架，而且该框架可以在整个 BEA 应用程序平台套件共用。因而，运行于现有应用程序平台上的组件能够以无缝方式与现有的安全生态系统实现合作。该框架将消除应用程序组件和安全服务之间的相关性――新型应用程序组件能够无缝地使用现有安全服务，而新型安全服务能够无缝地支持现有的应用程序组件。这种能力将减少用现有安全服务保护现有应用程序组件安全的生命周期成本。

通过采用分布式计算的原则，WebLogic Enterprise Security 既保持了灵活性，又没有损失控制性。其创新的管理模型使企业不仅对每个应用程序组件的安全配置，而且对用于控制业务功能访问的特定策略，都能够了如指掌，而且能够对它们实施控制。他们能够通过单一地点来管理安全问题，在整个分布式应用程序架构内传播配置和策略变化。这种能力有利于更好地评估和降低安全风险。

除支持现有的安全服务外，WebLogic Enterprise Security 还提供富于创新的作用变换和授权服务，从而有利于使安全码脱离业务逻辑。由于它们为评估请求的上下文提供了一种史无前例的灵活性，企业不需要为了实施策略而把安全码和业务逻辑相混合。这种能力将减少维护应用程序的成本，并能够实现更具响应性的风险管理。它是 BEA WebLogic Enterprise Security 首要目标的代表――即通过支持而不是限制业务过程，增强 IT 效率，改进系统安全，同时支持业务目标。

您对本文的评价
您对这篇文章的看法如何?
太棒了！5分 不错啊 4分 一般般 3分 有待提高 2分 不好 1分