dev2dev 首页 > 资源中心 > 技术文章
BEA WebLogic Enterprise Security：管理分布式应用的安全性
a.
通过加强应用程序的安全来降低风险
b.
简化管理的复杂性
c.
提高IT效率
d.
保证现有应用基础设施和安全资产的投资得到保护
遗憾的是，保证分布式企业应用的安全一直以来就颇具挑战性。一方面，核心业务过程迁移到日益分布的基础设施上，会导致使用现有的、常常是有错误的安全体系更不安全。另一方面，基于服务的应用结构的出现提出了这样一项新任务——需要去实现更加困难、更加复杂的健壮安全体系。
到目前为止，保证分布式应用的安全主要有两种代价昂贵的而且易出错误的情形。第一种情形是，中间件专家不得不耗费大量精力将每个服务器应用与每个安全实施组件集成起来。实际上，这意味着将每个Web服务器、应用服务器和单片机上的应用与每种身份存储、身份验证服务和访问控制模式集成起来。在某些情况下，开发商使用开箱即用（out-of-the-box）的集成。即使是这样，仍需要对每个使用这种集成应用的企业用户进行验证。这解释了为什么所有不同的组合都会需要大量的初始投资来部署、需要切实的运行维护工作、却更容易造成有错误的集成，进而导致安全漏洞。
第二种情形是，应用开发人员不得不将策略实施代码写入业务逻辑里。很多事务依赖于含有请求参数（如支出的数额不能超过预定义的限制）的策略。不幸的是，没有单一的授权模式能够访问到每个请求的完整上下文环境。因此，需要每个开发人员为每个组件编写代码，来检查可用上下文环境并实现适当的策略。一个概念上的全局策略实际上可能会在上百个独立的组件里得到实现，因而更新策略需要进行艰难的代价编写并且耗时长久。更重要的是，如果这些组件当中的任意一个有编程错误，就可能导致不可预见的秘密信息泄漏。
降低这两种情形带来的繁重负担的一个主要创新是，建立在分布式计算体系结构上的基于服务的安全层。基于服务的安全层在一端向服务器应用提供一个统一的安全抽象层，在另一端向安全解决方案提供即插即用的安全实现模块接口。当然，要带来这种灵活性，需要对安全层进行系列服务配置，同时也会带来策略维护问题。要避免此类问题，需要一个统一的管理范例来同步、传播和分析管理指令。
BEA WebLogic Enterprise Security是第一个使用单一且全面的解决方案来解决这些问题的供应商。它不需要企业更换现有应用或者安全基础设施，而是允许企业将这些现有组件结合到一个无缝的整体中，这个整体易于管理、维护和扩充。第一次使得信息技术企业能够完全洞悉并且控制住它的应用所支持的每个业务功能的各种安全问题。
面向服务的安全
应用安全挑战
从概念上讲，应用安全的目标非常简单：（1）不让攻击者访问到任何受保护的资源；（2）实施合法用户能够访问的资源的业务策略。遗憾的是，达到这些目标实际上却非常困难。
服务器应用与安全解决方案的集成是应对第一个目标所面临的问题的良方。阻止攻击需要分布式系统内的所有元素结成一个统一阵线。合作是统一阵线的关键。应用处于前端的客户端和后端的数据库之间。应用的安全系统必须准备从前端的客户端接受尽可能多的有关请求的上下文信息，并向后端的数据库提供尽可能多的有关应用请求的上下文信息。更重要的是，它必须准备与特定的安全服务合作。这些安全服务协调所有层的工作。努力将每个应用的安全子系统分别与每两个应用的安全子系统、每个数据库的安全子系统以及每两个安全解决方案集成起来，这无疑会在统一阵线上留下漏洞，而且这种集成在面对新的应用技术和安全技术时很脆弱。由于这一弱点，这种集成潜在地抑制了采用有益的先进技术。更重要的是，部署和维护这种集成的代价及其昂贵。
第二个目标也会导致问题，原因是在业务逻辑里实施业务策略似乎是可以接受的。实际上这种观点在这里是不正确的，原因是当在业务逻辑里进行实施时，安全策略维护起来非常困难。考虑这样一个类比，对一个安全的文档系统的管理。当安全策略改变时，您不是取出文档并重写它，而是将其放入另外一个文件柜里。不同的文件柜有不同的钥匙。一个安全方面的官员控制着钥匙的分配。返回我们这里的情况，当安全策略改变时，应用开发人员不必对业务逻辑部分做编码的改动，而是交由安全管理员来进行安全操作，改变对受到影响的组件的保护策略。无论如何，我们都不应该指责应用开发人员没有做好对策略实施的封装。我们应该从应用安全模型上找原因。大多数的安全模型不支持很多企业采用的策略类型，如只有帐户持有人能够访问他的帐户，或者支出授权取决于请求的数额。除非这些安全模型需要开始去支持更具动态性的安全类型，开发人员才不得不需要将安全逻辑硬编码到应用程序里去。
对第一个目标和第二个目标都很重要的是可见性和控制。应用安全不是静态的。管理员需要有能力来对发展的业务要求、计算技术和不断改变的威胁环境作出反应。首先，他们必须能够确定每个单一组件的安全形势，每个组件都执行着它所负责的业务功能。其次，他们必须能够通过改变对各种安全技术的使用或改变控制资源访问的策略来更新形势。最后，他们必须能够分析策略在全局上如何影响谁能访问哪些资源。只有解决了全面安全的集成要求、封装的策略实施的要求以及反应灵敏的管理要求，应用安全解决方案才能达到上述两个目标。
BEA WebLogic Enterprise Security从以下三方面入手解决这些早期问题：
1.
统一的安全抽象层，使得任意类型的服务器应用能够将所有安全功能作为服务处理。
2.
复杂的分布式体系结构，在不影响性能的前提下使得能够全面洞悉并控制应用安全的所有元素。
3.
灵活的策略描述语言，使得能够封装任意复杂的访问控制策略。
统一的安全抽象层
BEA WebLogic Enterprise Security特性的第一个方面是简化服务器应用与安全解决方案的集成。服务器应用可能用容器为分布式组件的执行提供大部分的基础功能。Web服务器作为CGI、JSP或ASP组件的容器。应用服务器作为J2EE和.NET组件的容器。包装的应用作为它们提供的业务功能的容器。一个替代方案是，独立的服务器应用（用Java或C语言编写）自身必须提供所有的基础功能。Web服务可以融为下面两种情况之一：从属为容器的功能或独立的服务器应用。如果它们运行在框架的顶部，那么框架就作为它们的容器。如果它们作为独立的组件运行，他们就像其他独立的程序一样。
每个在特定类型容器内运行的应用组件和每个用特定语言编写的独立组件能够使用同样的集成接口，这将大大节省了集成所需的时间和精力。实际上的情况比这还要好，原因是接口模型都是一样的，而不必在乎使用的是哪种类型的容器或采用的是哪一种编程语言开发的，。一个安全功能可能真正只需要应用提供三种信息。它可能需要的请求的安全上下文环境，如用户名和密码、嵌入的安全标记，以及所采用的加密的级别。它可能需要的资源标识，这可能是请求的目标，比如在“Accounts Receivable”应用里的“Customer”对象的“change address”方法。 它可能需要请求参数，如特定地址和特定客户。对所有可能的应用和所有可能的安全功能而言，这三类信息都是相同的。只不过是需要按每种应用类型的约定来对这些信息进行编码，并按照正确的顺序向每个安全功能分派适当的数据块。
图1阐释了这个途径。当服务器应用接收到对保护资源的请求时，它调用统一安全抽象层。该抽象层然后调用所有需要的单独的安全服务，将应用从细节上保护起来。应用然后接收到返回决定，该决定表明应用是应该拒绝请求还是完成请求。
BEA WebLogic Enterprise Security的目标是使服务器应用的集成尽可能简单。对那些已经在类似容器内执行的应用来说，向每个容器提供附带信息的集成是可能的。容器已经能够访问到安全上下文环境、请求目标和请求参数，所以整理这些信息并把它们转给BEA WebLogic Enterprise Security相对来说比较容易，这样就使所有能够在容器内运行的组件能够使用BEA WebLogic Enterprise Security。如果容器有开放的扩展功能的话，如Web服务器的插件机制，BEA就能够通过这一机制提供打包的集成。要得到BEA WebLogic Enterprise Security所支持的环境的完整列表，请访问www.bea.com/wles。
图 1. 使服务器应用从安全复杂性中解脱出来
对于独立的应用，每个服务器应用必须单独调用BEA WebLogic Enterprise Security。对于现有的应用，开发人员可以有多种直接的技术来增加这种授权。根据内部的体系结构，这样的技术包括增加拦截器、改变调度函数、或者创建代理对象。对于新应用，开发人员可以创建小型容器抽象，该抽象可以监听请求，调用BEA WebLogic Enterprise Security，并对结果作出反应。虽然这些技术都需要一些附加的编程，但是这种努力会给投资带来很多倍的收益，附加的编程免去了对所有嵌入的安全代码的维护负担。BEA目前支持Java API，而且在计划支持其他通用编程语言，如C/C++。
Web访问可以使用上面两种方法中的任意一种。很多Web服务在框架内执行，运行在Web或应用服务器之上。在服务器容器的本地框架内实现服务的业务逻辑。在这些情况下，它们能够利用底层容器与BEA WebLogic Enterprise Security的集成。其他Web服务是带有SOAP接口的独立程序。在这些情况下，程序会用编写它的编程语言使用API进行调用。
安全服务
BEA WebLogic Enterprise Security接收到来自应用的请求后，它通过复杂的内部框架来管理安全处理。关于这个内部框架，第一个值得注意的要点是，每一步骤必须要通过审计阶段。审计阶段为每一步骤的执行生成一个全面的事件集合。通过过滤和计算这些事件，审计实现模块可创建必要的经过精细处理的日志，来符合企业策略。第二个值得注意的要点是安全处理是一个管道。安全功能遵循正常的顺序，后续步骤需要前面步骤的结果。一定要在决定是否授权请求者对资源的访问之前，建立请求者的身份。一定要在评估角色是否被授权对某一资源可执行特定的操作之前，决定身份当前执行哪个角色。在逻辑处理顺序内，这个处理是非常灵活的。如果一个全新的安全功能种类出现了，BEA WebLogic Enterprise Security可将其放入管道内适当位置，以非常透明的方式使其支持所有服务器应用。
对于管道内定义的每一步骤，BEA WebLogic Enterprise Security都调用指定的安全服务实现模块来对这一步骤进行处理。如图1所示，每个处理步骤都有一个相应的服务实现模块接口（SPI）。该接口定义服务功能，安全服务实现模块必须支持执行这一步骤所需的安全服务。安全解决方案要接入BEA WebLogic Enterprise Security，只需提供服务的接口。解决方案知道如何提供接口。在很多情况下，这些接口只是一个封装器，它对现有的由解决方案提供商提供的客户程序库进行封装。利用BEA WebLogic Enterprise Security的统一的安全抽象层，
图2. BEA WebLogic Enterprise
企业能够透明、高效地转换到可替代的安全服务实现模块，更新到现有实现模块的新版本，甚至实现自定义的实现模块来对特殊情况进行处理。
开箱即用，BEA WebLogic Enterprise Security含有用于每一步骤的安全服务实现模块（请访问www.bea.com/wles获取当前已交付的实现模块列表），但是它们只使用框架SPI。任何其他的实现模块也可以通过同样的SPI访问底层框架。这些步骤和相关的SPI包括：
身份验证
身份验证。 这一步骤对请求者凭证进行直接验证。当前的开箱即用实现模块支持基于用户名/密码（来源于多种用户存储方式）的验证。使用可用的SPI可进行其他配置。
身份确认。这一步骤处理这样的请求——外部系统担保请求者，并有助于支持专一的身份验证技术和单点登录（SSO）。目前的开箱即用实现模块支持安全确认标记语言（SAML）的身份确认、CORBA IIOP CSIv2 标记，以及SSL连接里使用的X.509证书。因为BEA WebLogic Enterprise Security能够根据确认类型将请求分派到不同的服务程序，您可使用可用的SPI添加用于新系统的新实现模块来支持新型外部系统。
角色映射
这一步骤为特定的请求指定用户角色。开箱即用实现模块根据请求人、请求参数和请求上下文环境支持复杂的动态角色指定。BEA WebLogic Enterprise Security能够支持多个角色映射程序同时使用。
授权
这一步骤使用特定的角色集来决定是否授权特定用户对资源的访问。开箱即用实现模块根据请求人、角色、请求参数和请求上下文环境支持复杂的决策规则。BEA WebLogic Enterprise Security能够支持多个授权程序同时使用。在这种情况下，判决实现模块使用可配置的规则解决有冲突的授权决定。
凭证映射
这一步骤将应用请求人映射到后端系统凭证。这不是访问决定过程中的一部分，因为应用是在进行请求时，而不是在接收到请求时，调用凭证映射程序。开箱即用实现模块支持用户名/密码凭证和SAML身份确认生成。
审计
这一步骤记录安全操作。因为不论何时当任意一种实现模块执行功能时，审计程序都会得到调用，所以这一步骤与其他步骤稍有不同。审计程序接收所有安全事件并决定记录哪个事件、对记录日志采用何种格式。开箱即用实现模块支持基于门限的记录，并将所有记录下来的事件写入到本地的一个日志文件里。BEA WebLogic Enterprise Security还支持log4j实现模块。企业可以使用多个审计实现模块，这样通过SPI集成外部审计和报告系统就容易多了。
这些干净的SPI使企业能够随着安全技术的进步，随时更换不同的安全实现模块，这样每个人都会从中受益。BEA能够个别更新BEA WebLogic Enterprise Security里的实现模块。专家级安全供应商通过将产品对适当的SPI进行编码，能够很容易地使他们的服务被所有支持的应用使用。更重要的是，企业能够在必要时迅速实现定制的安全处理。
BEA WebLogic Enterprise
Security体系结构
安全服务模块
BEA WebLogic Enterprise Security中提供统一安全抽象层的部分称作安全服务模块（SSM）。一个SSM实例包括：与服务器应用类型的接口、处理管道以及为该实例配置的所有服务实现模块。典型来说，每个SSM实例支持一个服务器应用实例，如图3所示，所以每个Web服务器实例、应用服务器实例或独立应用实例都有自己的SSM。
每个SSM都需要为它的服务实现模块和它们的相应策略信息进行配置。在安装和注册SSM时，需要进行初始配置，此后配置随着服务实现模块的改变以及策略的改进而更新。某些企业应用可能有一百多个不同的物理服务器机器参与了其相应的执行，因而对一个专业的安全管理方法的需求是显而易见的。
图3. 安全服务模块
服务控制模块
安全管理专业性的第一特点是，同一个服务器上跨多个实例的操作的聚合。在大多数的企业体系结构上，一台物理机器上运行一个Web服务器或应用服务器的多个实例很常见。在某些情况下，性能强大的服务器可能在一台机器上运行着Web服务器、应用服务器和其它独立应用程序的实例。显然，如果这些实例中的每一个都直接与管理系统通信，在那台机器上就有可能存在不必要的复制资源耗费，也可能由于端口不必要的暴露而导致安全漏洞。进一步来说，很多种类的服务器允许管理员动态创建和销毁实例，以此将硬件资源与不同资源的请求相匹配，因此BEA WebLogic Enterprise Security提供了一种控制创建和销毁相应SSM实例的方法。因而，每个运行着SSM的机器都有一个服务控制模块（SCM），如图4所示。
当SSM初次安装到机器上时，SCM被自动安装并注册到管理服务器。在管理服务器与SCM之间建立起信任关系，安全的SOAP连接被建立，为机器上所有的SSM传递配置和策略数据。因为每个SSM安装到该台机器上，它都要与本地的SCM建立起信任关系，并向其发出请求获得配置信息。SCM只知道与部署在该台机器上的SSM相关的配置和策略，并只为本地SSM提供那些配置信息。
图4. 服务控制模块
配置安全服务模块
一旦SCM注册到管理服务器，管理员就可以通过控制台远程配置机器上支持的安全服务模块（SSM）。如上文所述，SSM配置包括实例要使用的服务实现模块集和它们自身的配置。对于身份验证程序，这个信息可能包括一个指向用于身份验证的用户存储系统的指针，或是一个指向用户目录服务器的指针，或者指向受信的根证书列表。对于角色映射程序和授权程序，这个信息可能分别包括指派角色时和授权访问时所要用到的策略信息。
实际上，企业可能典型拥有几个指定的配置，这些配置被指派给多个SSM实例。例如，一个银行可能有ConsumerBankingWebPortal、CommercialBankingWebPortal、TellerTransactionApplication、ClearingApplication和RiskManagementApplication配置，这些配置被指定给多个SSM，支持在各种服务器群上运行的应用。
管理应用程序
BEA WebLogic Enterprise Security在管理应用内维护这些配置。除了指定给配置的服务实现模块外，它还维护由配置管理的所有受保护资源的层次结构。这个层次结构包括各个级别：应用组、应用、组件、对象和方法，这样策略可以施加到树状层次结构的任一级。树状结构中的资源继承祖先的策略，管理员可以在任一级上覆盖这种继承。所有这些配置、资源和策略的数据都驻留在策略存储上，策略存储目前支持Oracle或Sybase数据库。
这个策略存储还维护有关管理权限的信息。BEA WebLogic Enterprise Security有一棵管理资源树，它像保护应用资源一样保护资源树。资源树有四个分支：（1）对用户和组的操作；（2）对角色指定和授权策略的操作；（3）对受保护资源定义的操作；（4）对服务实现模块配置的操作。每个分支上还有更细的分支。分支（1）上有与用户和组相关的子分支。分支（2）和（3）上有与资源树相关的子分支。分支（4）上有与配置树相关的子分支。一个单独的管理员可能会被授予对这个资源层次结构的任意分支集拥有创建、读取、更新和删除的权限。所以，即使BEA WebLogic Enterprise Security为所有应用统一了安全管理，企业仍需按自身需要划分管理访问权限。
除了在划分上的灵活性外，BEA WebLogic Enterprise Security还提供另外两个重要的管理功能。1，在某些情况下，如果一个管理员去度假或者任务太多，他可以将他的部分或全部安全权限委任给另一个管理员。可以将管理委任功能为特定的权限或根据特定的时间间隔进行设置。2，管理员能够分析他们的安全策略，来决定安全策略是否符合公司策略，或者就资源访问有关的问题展开调查。例如，他们可以查看谁拥有访问角色，他们不仅能够知道谁可能拥有该角色的人，而且还能知道这些人可能拥有的特定资源权限以及对资源访问的适用条件。同时他们能够将这种访问限制设置到只对特定资源拥有访问权限的角色身上，并能够依查询条件查看相应的访问列表。他们能够查看谁被明确地拒绝了某一角色或资源的请求。他们甚至能够查看谁通过被显示的指派了某一特定角色，以及特定的人代理的是什么角色。因为管理服务器在数据库里维护所有这些信息，管理员能够将这些查询组合来生成报告或得出相应的调查结果。
BEA WebLogic Enterprise Security还提供交易管理的全面审计。不但每个管理请求要被审计，而且交易结果也会被纳入审计。下述的附加步骤提供了事实的保证——请求的变化真正被提交到策略存储。通过管理服务器配置，审计实现模块能够访问所有与交易事务管理相关的上下文数据，这样它们就能够记录下企业需要的所有细节。
实施灵活的策略
产品应用中的首要管理任务是指定策略。大多数应用安全模型使用角色这一概念来创建策略。角色提供一个处于用户和资源之间的抽象层，这使管理变得容易。他们像组，但是更具动态性。典型来说，安全管理员按规定将用户指定到一个组，只有当用户的职责改变时，管理员才会更改指定。角色变更非常频繁，在特定条件下，甚至可能一个请求与下一个请求之间角色就变了。BEA WebLogic Enterprise Security策略支持角色和组的使用。管理员能够设置角色，这样角色可以体现一个逻辑身份，如Teller，或是命名一组逻辑许可，如Deposit、Withdraw和Transfer。这的确是一个设计问题。第一种方法更注重用户的逻辑角色，第二种方法更注重资源的逻辑角色。管理员能够设置用户组的层次结构，层次结构反映出企业的组织单位，或与工作职称相关联的渐进的责任等级。管理员然后可以指定角色如何在组的层次结构内继承。
BEA WebLogic Enterprise Security进一步使安全服务实现模块能够根据上下文动态指定角色。内含的角色映射实现模块非常复杂，它利用到了BEA WebLogic Enterprise Security框架在这方面的所有功能。除了用户名、组和时间外，它还考虑了请求参数的值。例如，假设银行有一个Teller应用，该应用被限制为只有拥有Teller角色的用户能使用。如果一个用户是DayTeller组的成员，而且当地时间在上午8点至下午6点之间，那么他就能履行Teller角色。此外，用户不能对他自己的账户履行Teller角色。例子1演示了如何使用BEA WebLogic Enterprise Security策略描述语言实现这个策略，假设AccountHolder是一个表示账户所有人的参数。
例子1—角色映射策略ROLE MAPPING POLICY
grant(//role/Teller, //app/policy/TellerApp, //sgrp/directory/daytellers/)
if time24 in [800..1800] AND
dayofweek in [Monday..Friday] AND
sys_user != AccountHolder;
|
一旦角色映射程序授予用户Teller角色，授权实现模块必须检查该角色是否授予用户对特定功能访问。一个典型的应用安全问题是，根据请求内容制定授权决策。当想评估这些参数的值时，数额门限是一种常见情况。首先，创建一组角色，如Teller、TellerManager和BankManager。然后，创建一组策略，策略根据Amount参数的值对每个角色授权请求，如Teller对应$25,000，Teller Manager对应$100,000，Bank Manager对应$250,000。例子2演示了如何在Teller应用内为所有事务实现这个策略。
例子2—授权策略
grant(//priv/Transaction, //app/policy/TellerApp, //role/Teller)
if Amount =< 25000;
grant(//priv/Transaction, //app/policy/TellerApp, //role/TellerManager)
if Amount =< 100000;
grant(//priv/Transaction, //app/policy/TellerApp, //role/BankManager)
if Amount =< 250000;
|
基于目标内容的授权有点复杂，但是它的功能却非常强大。例如，假设特定应用不包括AccountHolder参数。那么在决定授权事务之前就必须检查Account对象来得到AccountHolder的值。SSM使容器除了能够支持请求参数外，还支持上下文，如EJB主键。您可以编写一个定制的属性转换程序，该转换程序使用由Transaction请求确定的Account对象的键值回调应用。这个转换程序能够检索到AccountHolder值并将其传递给身份验证实现模块。特定的应用也可能不知道AccountHolder的值。在这种情况下，属性转换程序能够从企业内的其他来源检索到该值。不论哪种情况，被转换的AccountHolder属性都会被策略评估，好像它是来自请求参数的原始列表一样。因此，规则句法与例子1相同。
检索授权上下文的最后一种方式是通过评估函数。评估函数与前面的方法类似，只不过它返回一个布尔结果。这种方法要求评估检查作为函数的一部分被执行。例子3与例子1相同，只不过它使用评估函数来进行检查。如果在比较前，AccountHolder的格式需要附加转换的话，可能需要这种方法。
例子3—评估函数
grant(//role/Teller, //app/policy/TellerApp, //sgrp/directory/daytellers/)
if time24 in [800..1800] AND
dayofweek in [Monday..Friday] AND
CheckAccountHolderConflict(AccountHolder, sys_user);
|
注意，必须要编写几乎与连接到Account对象的业务逻辑部分完全相同的代码来执行这项检查。可是，服务实现模块将安全逻辑与业务逻辑分割开来。不同的人能够维护两种逻辑，更改其中一种逻辑不会给另一种逻辑带来损坏的危险。如果考虑实际银行账户的复杂性，有小账户、联合账户和公司账户，那么这种灵活性非常重要。为这样的应用维护安全策略本身就应该是一项专职工作。
另一个普遍的问题是委托管理权力。一个人常常拥有与他的工作职责相对应的权限。如果他要委托权限，那么他应该只能委托适当的权限。这个策略在大多数的系统上都是不可能的。实际情形是用户将他的凭证交给需要的人。遗憾的是，这样一来，如果用户不更改他的凭证，他就将他的所有权限都给了接受者。典型的情况是，用户不愿意作这种更改，所以接受者就会永久拥有用户的所有权限。例子4演示了同时限制权限的范围以及有效时间是可能的。在本例中，董事Alice在她度假期间将她的费用审批权限委托给向她报告的经理Bob。
例子4—委托
delegate (//role/ExpenseAuthorizer, //app/policy/acme, //user/acme/alice/,
//user/acme/bob/)
if date < 02/04/2004;
|
传播变化
除了能够指定灵活的策略，BEA WebLogic Security还赋予了管理员频繁更新这些策略的能力，以响应业务的变化。他们可以用极小的工作量为任意SSM配置实现模块或更新策略。但是，如果这种改变的实现方式不够专业的话，实际实现起来可能会付出昂贵的代价。资源在策略上的小变化是不需要完全重新配置每个SSM的配置，所以如果管理员改变了某一资源上的策略，他可以为只为该资源配置新信息。如果他改变了树状结构上同一分支上的几个资源，他可以只为该分支配置新信息。如果他改变了一个应用，他可以只为该应用配置新信息。当然，接收到更新的不同SSM可能当前拥有不同的配置，但是管理服务器知道这些配置是什么，所以它会为每个SSM比较需要的配置和现有配置，并只发出每个SSM需要的配置。还有，将更新限制在受到影响的资源上，只发出必要更改会大大降低响应更改所需的费用，还会在子系统的安全受到威胁时降低敏感的安全配置数据被暴露的危险。因而在正常条件下，对几个策略进行的一个更新，它们会影响几十个服务器，但这种更新只需要几秒钟即可完成。
图5. 分布策略和配置的更新
系统可靠性
显然，安全是一个重要的计算保障。因为每个使用SSM的容器都依赖BEA WebLogic Enterprise Security来执行，所以可靠性至关重要。BEA对很多潜在的SSM配置组合、服务器应用类型和硬件平台进行严格的测试，以保证SSM至少与它们所支持的应用一样可靠。当然，因为SSM与它们的相应容器运行在相同的物理机器上，所以它们不会带来任何硬件故障引起的额外风险。不管怎样，它们都依赖于中央管理服务器对配置和策略进行的管理和更新。
依赖中央管理服务器使安全管理变得容易，但是可能会降低系统可靠性和性能。BEA WebLogic Enterprise Security通过向SSM分布运行时加强消除了性能瓶颈。为了解决系统可靠性问题，它支持管理服务器镜像。使用主管理服务器和从管理服务器配置每个SCM。管理服务器程序运行在两个独立的服务器上，通过数据库复制来保持同步。未来版本会通过集群来对可靠性进行支持。
管理服务器可能有时会失去与SSM的联系。SSM会继续实施上次部署安全配置并努力与备份管理服务器联系。当SSM与管理服务器重新建立联系时，它会将它的配置版本号与应有的版本号比较。如果版本号过期，它会自我更新并请求刷新它的整个配置。
在企业环境下工作
利用现有用户存储
我们已经讨论了BEA WebLogic Enterprise Security如何通过向现有服务器应用和现有安全解决方案提供干净接口以便在现有的企业环境下工作。但是，基于这种机制之上，存在大量的对平滑集成的功能的需求，这种需求不仅仅要对现有的用户存储进行支持，而且同时，这也是安全管理员最大的难题之一，需要保持用户存储的一致性。所幸的是，BEA WebLogic Enterprise Security并不存在这些难题，因为它的用户和组的定义完全依赖现有存储。
在某些情况下，用户可能被清楚地划分到一个相对少的授权存储里。BEA WebLogic Enterprise Security能够通过它的用于关系数据库和目录服务的身份验证实现模块直接使用这些存储。使用这种方法，当SSM接收到来自服务器应用的身份验证请求时，它使用适当的服务实现模块对特定用户存储（带有应用提供的凭证）进行验证。目标关系数据库或目录服务会评估凭证并将验证决定返回SSM。SSM随后将验证的身份沿应用传递。
当策略决定使用的用户身份的组件或其他用户属性还没有被统一到单一的授权存储时，BEA WebLogic Enterprise Security使用管理应用的元目录来聚合用户、组和属性信息。元目录填充和更新策略存储，它使用目录集成技术访问企业现有存储的用户信息。在管理应用的初始安装阶段，或者用户存储随着时间的推移发生了改变，管理员使用元目录控制台来定义一个从授权存储到BEA WebLogic Enterprise Security策略存储的映射。BEA WebLogic Enterprise Security随后就能够从这些源批载入初始快照，并建立连接来接收实时或渐增的更新。在这个过程中，BEA WebLogic Enterprise Security保持与企业身份生态环境的其余部分同步。BEA WebLogic Enterprise Security的数据库模式被很好地记录，已经拥有目录集成产品的企业能够很容易地使用它们。
图6. 利用企业现有用户存储
使用外围身份验证和Web单点登录
因为企业拥有现有的用户存储，它们也可能有除了用户名和密码之外的用户身份验证方式。这些机制包括二系数系统、基于证书的系统和Kerberos系统。进一步来说，在一个高度分布的应用中，BEA WebLogic Enterprise Security可能需要依赖上游组件来担保用户。这些组件可能包括VPN、中间Web 服务，或参考Web站点。在所有上述情形下，第三方都会提供一个应用能够验证的标记。只要它信任第三方，它就会接受验证过的标记，这个标记就好像是用户凭证原件一样。
BEA WebLogic Enterprise Security使用非常直接的机制与这些系统合作。应用容器从HTTP报头、SSL连接对象、或者使用特定方法提取标记并将其传递到SSM。SSM决定标记类型并分派相应的身份确认程序来验证它的真实性。如果进入的是来自共有SSL身份验证的X.509证书，SSM会分派能够验证证书链到根证书发放部门的实现模块。如果进入的是SAML确认，SSM会分派实现模块来验证确认源并提取它含有的请求人。
一旦实现模块执行验证，它就将凭证里的用户身份映射到本地身份。因此第三方实现模块或企业开发小组就能够将任何身份验证技术与BEA WebLogic Enterprise Security集成起来。结果是，与Web SSO的集成变得非常直接，特别是采用了诸如SAML之类的身份标准。
图7. 与现有的外围验证和Web单点登录解决方案互操作
方便凭证映射
当一个将自身的安全委托给BEA WebLogic Enterprise Security的组件接收到请求时，需要支持外围验证和Web单点登录这一问题就产生了。但是当这样的组件提出一个请求时，又是什么情形呢？当然，如果请求的是另一个组件，目标将会对请求进行验证和授权。还有，很多企业现在想将对后端数据库的请求、对打包的应用的请求、或者对主框架的请求绑定到最终用户。因此，当服务器应用代表用户访问后端系统时，它必须提供适当的凭证。应用能够使用BEA WebLogic Enterprise Security的凭证映射功能来满足这一要求。
BEA WebLogic Enterprise Security含有凭证安全服务实现模块，当目标应用或数据库期望用户名/密码或SAML确认时，在大多数情况下实现模块都能解决这一问题。在需要用户名/密码确认的情况下，这些凭证存储在一个关系数据库里，每个SSM按需要检索它们。在需要SAML确认的情况下，内嵌的实现模块能够生成合适的身份确认。复杂的安全体系结构可能需要第三方或定制的实现模块。例如，某些数据库的最新版本能够使用Kerberos凭证。还有，某些打包的应用的最新版本能够使用各种健壮的身份验证，很多主框架使用RACF。BEA WebLogic Enterprise Security能够轻松兼容第三方的或定制的安全服务实现模块，这些实现模块使用凭证映射SPI来支持替代的方法。
图8. 方便凭证映射
提供全面审计
不论对周期性地检验已声明的策略是否还被执行，还是在出现违规时提供适于庭审的法庭证据，审计都是企业安全过程中越来越重要的一部分。例如，假设两个不同的授权服务有不同观点。通常这将是一个非常值得注意的事件，管理员想知道到底发生了什么。遗憾的是，大多数应用级的安全忽略了这类细节上的安全审计。合理的审计不仅仅只是将信息写入到磁盘上的某个地方。还需要支持他们来验证、检测和调查，管理员需要在一个单一的安全地方有所有安全事件记录、特定事件特别是重要事件的通知，以及迅速查找记录的能力。
安全管理员负责保证有关信息访问的企业策略的实施。显然，他们必须先规定这些策略，当然是希望他们使用如上所述的生产环境管理接口。然后他们必须通过周期性地检查审计来跟踪验证策略的实际实施。政府条例或商业合同可能要求这类审计。管理员采样事务的一个代表集，通过各种应用组件跟踪它们的路径，保证每一步都有正确的安全策略实施。他们需要一个加固的审计跟踪措施，否则他们必须花费大量精力来手动采集、组装不同位置的日志。他们需要详细的记录，并且要保证记录不能被篡改，否则他们就不能决定审计完全合格或满足无懈可击的审查需求。
对潜在的违规作出反应是安全管理员的另一个主要责任。他们需要详细的记录来决定是否系统安全受到威胁、受威胁的程度，以及判断将来如何避免这类威胁。要支持这些任务，每个SSM都为每个安全操作生成事件。管理服务器为每个管理操作生成事件记录，包括请求执行一个操作和操作是否实际发生。每个审计服务实现模块能够选择记录哪些事件以及如何记录它们。BEA WebLogic Enterprise Security含有一个基于log4j的审计实现模块，它使用阈值并将事件以多种格式写入到多个位置。大企业可能拥有复杂的日志聚合和分析的解决方案。通过现有的审计SPI，这些解决方案能够得到及其详细的应用安全事件，然后将这些事件于来自网络和数据库系统的安全事件合并，形成完整的企业安全实施画面。
结束语
BEA WebLogic Enterprise Security不向企业施加僵硬的安全模型。僵硬的安全模型会妨碍应用组件与安全服务的集成，很容易造成一个安全代码与业务逻辑相混淆的工作区。BEA WebLogic Enterprise Security而是交付一个灵活、开放的框架，这样现有的服务器应用就能够与现有的安全服务无缝地合作。这个框架避免了服务器应用与安全服务之间的依赖——新的服务器应用能够无缝地使用现有的安全服务，新的安全服务能够无缝地支持现有的服务器应用。这个能力大大降低了保护分布式企业应用的生命周期费用。
通过将分布式计算的原理包括进来，BEA WebLogic Enterprise Security在不牺牲控制的情况下保持了灵活性。它的革新性的管理模型使企业能够完全洞悉并控制每个应用组件的安全配置以及用于授权对业务功能进行访问的特定策略。它们能够从一个安全管理位置——将配置和策略改变传播到整个分布式应用结构。这个能力因而提供了更好的安全风险管理，从而使得风险得以降低。
除了支持现有的安全服务，BEA WebLogic Enterprise Security还提供突破性的角色映射和授权服务，这些功能使安全代码与业务逻辑的分离变得容易。因为它们在评估请求上下文环境方面提供了前所未有的灵活性，企业不必将安全代码与业务逻辑混合起来就可得到策略实施。这个能力降低了应用维护的费用，并支持更具响应性的风险管理。这是BEA WebLogic Enterprise Security首要目标的重要体现，那就是，通过方便业务过程（不对它们加以限制），在支持业务目标的同时提高IT效率并改进应用安全。
|
