威胁防护过程
威胁防护过程包括下面的步骤：
1.
识别 WebLogic Platform应用程序资产。
识别部署在应用程序环境中包括数据库表、配置文件和安全机密等有价值的和敏感的资源。
2.
分析应用程序体系结构
一旦识别了应用程序体系结构，就应该很容易将应用程序分解成更小的组件，并在更小的粒度级别上识别以下属性：
每个组件的外部访问点。
识别每个组件和整个应用程序的访问点时，需要知道“防护边界”（Protected Boundary）和“入口点（Entry Points）”。“防护边界”的多层部署也是一种可能 (这依赖于应用程序需求)。
数据流
必须保持组件内和跨组件的数据流的机密性和完整性。数据流是指组件内和跨组件的信道。
特权代码
应用程序内部可能被恶意访问或使用的代码。
总的来说，上面的属性有助于识别对整个应用程序的威胁。下例演示了分析过程
示例体系结构如图1所示，此体系结构包含两个组件：域 D1和D2。我们来细致研究 D1。
D1是一个带有被管理的服务器的WebLogic 群集。该域的防护边界有以下入口点：
操作系统的开放端口。要封闭这些端口就需要一个IP 防火墙。
内部用户调用一个关键业务操作所需的开放SSL端口。要加速多个客户端的握手过程，就需要一个硬件代理来进行 SSL认证。从代理端可以用一个预先建立的（pre-established）SSL连接与独立被管理的服务器进行通信。
外部用户调用一个非关键业务操作（比如浏览目录）所需的开放HTTP端口。
密码保护的客户端只能执行非关键操作（比如目录浏览），其他关键操作由SLL进行防护。
内容验证能力（使用XML防火墙）防止密码保护客户端调用关键的Web服务。
拒绝外部T3 客户端的访问（使用 WebLogic 连接过滤器），因为访问的内容无法验证。
两组件 D1 和 D2之间的数据流应当使用SSL对关键业务操作进行保护。一旦代理和被管理的服务器之间的信道建立起来，它们就应当为以后的任何请求所重用。这就使SSL握手时间与常规的请求处理时间脱离关系。传输层的欺骗（spoofing）只能使用SSL握手进行保护，理解这一点很重要。
组件内部的威胁与访问特权代码有关。无效的访问策略与一系列的系统级别的jar有关，这些瓶颈是由于BEA可能允许了对关键资源的非法访问造成的。下面的内容介绍了对特权代码的不同代码段进行防护的方法。
代码访问应用程序/系统队列
weblogic.jar、webservices.jar和其他WLI-specific jar应当使用Java 访问策略进行防护。否则任何非特权代码就可以使用映射，滥用系统级别的jar，像队列一样来访问受保护的资源。
让代码访问配置资源
weblogic.jar "webservices.jar、WLI-specific jar和 WLP-specific jar访问配置相关的资源。这些jar应使用Java访问策略进行防护。
任何应用程序级别的jar都应当定义为拒绝访问“KERNELID”的权限。使用Java策略文件在中的“weblogic.kernelPermission”可以拒绝访问“KERNELID”的权限。
与D1类似，D2所有与外部访问点、数据流和访问特权有关的细节都必须确定。下一步就是将这些信息连接起来以完成应用分析。
3. 设计应用程序体系结构的安全概要文件。
所部署的任何应用程序的安全概要文件都建立在一组漏洞的基础上。安全概要文件确定了设计和实现的方法，从而解决这些漏洞。从应用程序体系结构分析中获得的信息为建立安全概要文件提供了正确的前后关系。
下面总结出安全概要文件的一组强制性方面
输入验证
认证
授权
配置管理
会话管理
密码支持
异常报告
审核和记录
参数操纵
识别威胁
识别已部署应用程序受到的威胁及相关风险。要用更加结构化和可重用的方法来记录攻击数据，可以使用“Attack Tree”。要了解详细内容，请参考 Attack Modeling for Information Security and Reliability。
4.
基于威胁信息来增强安全。
合理使用威胁信息可以增强所部署的应用程序的安全性。
接下来的内容讲述了具体的方法。
识别Weblogic Platform应用程序资源
带有WLPlatform组件的WebLogic域是由不同类型的资源组成的。很多资源都被认为是关键资源，必须进行保护。关键资源的例子包括：
数据库表
系统表
来自BEA的应用程序表
数据库连接池
默认连接池
特定于应用程序的连接池
磁盘中的配置文件
LDAP 存储
私有密钥文件
来自 WLI 的连接器资源
用于WebLogic Platform 组件的JNDI资源。
要获得附加参考资料列表，请参阅： http://edocs.bea.com/wls/docs81/secwlres/types.html#1209988
分析应用程序体系结构：一个示例部署场景
图1描述了一个部署场景。此应用程序由下面这两个逻辑组件组成：
D1：Portal 域
D2：WLI 域
下文描述了每个域的功能和数据流：
D1
D1 接收 Web服务、基于浏览器的请求（HTTP或HTTPS）和来自因特网的T3s请求。
D1 通过Web服务（HTTP/HTTPs）、JMS （T3和 T3s）和 EJB 调用（T3和T3s）发送和接收往来于D2的消息。
D1 使用DB控件和自定义控件来执行关键业务操作。
D2
D2 接收Web服务、B2B （HTTP/HTTPS）和来自因特网的T3s请求。
D2通过Web服务（HTTP/HTTPs）、JMS （T3和 T3s）和 EJB 调用（T3和T3s）发送和接收往来于D1的消息。
D2 使用过程控件和自定义控件执行关键业务过程。
注意：红色箭头表示通过SSL的数据流，黑色箭头表示非SSL通信。虚箭头表示从组件 D2到 D1的通信。
注意以下几点：
每个域都与包含下列内容的 DMZ有关：
IP 防火墙
代理服务器
IP 防火墙应当允许基于通信的HTTP和SSL的两个不同的端口。由于下列原因，两个防火墙进行了类似的配置：
D1和D2都由危险程度相同的资源组成。
每个组件都可以从因特网上通过HTTP进行访问。比如：
D1可以从Web浏览器和 Web服务进行访问。
D2 可以从 Web服务和B2B合作伙伴进行访问。
防止扫描空闲端口的防护也是必要的。
每个组件都与其他的组件进行交互。如果某个组件使用了比较弱的安全约束，那么整个应用程序的一个恶意外部用户就可能更容易地访问到此应用程序。由于其他组件允许从该组件进行“调用”，所以恶意的外部用户就可以驱动调用这个组件，尽管它实在较强的外部防火墙的防护之下。此种情况可以这样处理：
所有组件都保留相同等级的安全防护。可以将防火墙和代理进行相同的配置来避免这种等级不一的问题。图1演示了这样的一个配置。
或者，较弱安全防护的组件将所有客户端信任的验证授权给较强的安全标准。
每个防火墙都应为每种类型的通信选择唯一的端口。 这就引出了防护的另一个层面，并减小同时暴露整个系统的风险。
前面的实例中，由于某个特定的组件相对于其他组件而言需要保护更关键的资源，所以这里的特例可能并不适合。 此时就需要一个更强的防火墙来防护对威胁比较敏感的组件，同时，禁止直接的外部访问。具有不同防护能力的多重防火墙可以做到“纵深安全”。除防火墙的防护之外，我们还需要为试图访问任何应用程序组件的所有用户提供一个集中认证服务。图1所示进行了相同配置的代理服务器 P1和P2 正是满足了此项目的。
每个被管理的服务器都与一个本地XML防火墙有关。到达非SSL端口的所有消息都将继续前往一个XML防火墙进行进一步的基于内容的过滤。这就保证了对 Web服务调用的细致访问控制：
密码保护客户端只能执行非关键操作，比如目录浏览，而其他关键操作却通过SSL保护。
内容验证能力防止了密码保护客户端调用关键的 Web服务。
任何外部T3的客户端访问都被拒绝，因为内容无法通过验证。外部T3连接可以使用一个连接过滤器来拒绝。
代理服务器（比如图1中的P1和P2）分别用443和444端口配置为基于SSL的认证。使用端口80和84配置为基于口令的认证。一旦通过认证，就应当使用安全标记（比如基于SAML的标记）将安全ID传给被管理的服务器。HTTP和T3 流量的负载均衡也通过代理来完成。
所有其他入站端口（inbound port）都应通过防火墙来封闭。出站端口（Outbound port）应保留开放状态，以支持到因特网客户端的回调操作（ Web服务）。类似NAT这样的技术可防止直接暴露内部端口。
代理应当配置为SSL 以处理443和444端口的任何请求。
所有外部T3端口都不允许访问，但外部 T3s客户端却是允许的。
注意：任何群集域都必须用适当防火墙技术进行防护。
图1
定义安全概要文件
