34、Java安全技术架构与应用解析

Java安全技术架构与应用解析

1. 可插拔安全提供者的演进

在设计Java安全API时，我们期望构建一个能适应技术发展和变革的架构。由于无法实现所有功能，也难以预见所有人的需求，因此引入了服务提供者接口（Service Provider Interface），它展现出了很强的通用性。

服务提供者接口对Java安全团队大有裨益，更为重要的是，它为第三方开发者提供了所需的灵活性。例如，Java加密架构（JCA）借助插入的加密算法来实现各种密码套件。随着标准化椭圆曲线密码学（ECC）密码套件的出现，我们预计JCA加密服务提供者会实现底层的ECC签名和加密算法。不过，Java安全套接字扩展（JSSE）目前尚未提供服务提供者接口，以便插入TLS/SSL协议的替代实现。若能有此接口，将增加灵活性，更利于集成对不断发展的标准的支持。

Java GSS - API在IETF的安全领域得到开发和标准化，并被纳入J2SE。与J2SE中的大多数安全API不同，它未公开服务提供者接口。最初期望在IETF内对其进行标准化，但IETF现在更关注互联网协议。然而，由于GSS机制（如SPKM、SPNEGO和LIPKEY）已标准化并广泛部署，若无开放的编程接口，Java GSS绑定可能会过时。因此，我们期望通过Java社区流程对Java GSS - API服务提供者接口进行标准化。

2. 安全表达式

在Java 2发布前后，可扩展标记语言（XML）逐渐成熟。XML是一种用于描述数据的语言，其成功的原因众多，其中易用性与Java编程语言相似。目前，用于描述和表示加密数据的XML语法标准化工作已基本完成，XML签名和XML加密规范也已稳定。Java社区正在创建相关的Java API，以纳入核心平台安全API。同时，XML密钥管理规范（XKMS）也在趋于稳定，它规定了用于分发和注册公钥的XML语法和协议，旨在简化公钥基础设施（PKI）的复杂性。围绕简化PKI的理念，计划开发Java API以支持与XKMS信任服务的协议交互，用于检索公钥和处理XML签名密钥信息。

当基本的XML安全基础架构就位后，可应用于更高级的基础设施，如Web服务。行业研究表明，在安全基础标准化之前，Web服务难以广泛采用。目前，Java社区正在对相关Java API进行早期标准化工作。

3. 安全管理

通常，使用难度越大的东西越可能不被使用。J2SE的设计原则之一是易用性和易部署性，但这有时与安全要求相冲突。实现平台、网络和信息安全是一项复杂的任务，部署安全系统需考虑诸多因素。大多数J2SE发行版默认采用限制性沙箱安全模型，虽安全但限制较大。为满足系统部署需求，我们设计了多种配置系统的方法，但这些方法较为底层。为更好地管理环境安全，出现了一些专门的部署范式，常见的Java部署范式有J2EE、Java Web Start和Java Plug - in。

4. Jini网络技术简介

Jini网络技术于1999年推出，其核心是构建一个动态自适应的可用服务网络。它基于联合的概念，即用户及其依赖资源的集合。Jini分布式系统的目标包括：
- 让用户共享服务和资源；
- 便于用户访问资源；
- 实现位置独立性和移动性；
- 简化用户、网络可用服务和网络设备的管理。

Jini由底层基础设施、编程模型以及组成联合的客户端和服务构成。其基础设施可进一步分为发现协议和查找服务，发现协议帮助实体找到查找服务，查找服务则是服务发布和客户端查找服务的场所。Jini基础设施基于Java RMI编程模型，依赖代理（proxy）来处理网络相关功能。

由于分布式系统面临诸多威胁，Jini技术项目团队开展了Davis项目，以构建Jini技术安全架构并改进Jini技术。

5. Jini技术安全架构概述

Jini充分利用代码移动性，实现联合分布式系统的自适应和动态行为。其安全架构确保在使用可能有威胁的代码前，代理是可信的，并且支持可配置的安全。该架构提供了一个编程模型，通过定义基于约束的系统来表达网络安全要求，客户端和服务器的调用约束分别通过代理接口和远程对象导出时传递。

6. 约束模型

可指定的调用约束类型是可扩展的，常见的有身份验证、消息完整性和保密性。客户端和服务器都可指定这些约束，代理实现需满足双方的安全约束。

Jini技术依赖Java身份验证和授权服务（JAAS）进行网络身份验证，客户端的Subject是进行远程调用的线程的当前Subject，服务器的Subject通常取自导出远程对象时的线程。实体在远程调用中可作为其Subject中部分Principals进行身份验证，前提是Subject包含必要的凭证。身份验证后可能会派生额外的Principals和凭证，服务器用于身份验证的Principals和凭证通常不直接提供给客户端，客户端通过安全约束限制其要求。服务器中，客户端身份验证的结果由包含认证后Principals和凭证的Subject表示，该Subject通常不包含私钥凭证，除非使用委托，否则不能用于进一步的远程调用身份验证，但可用于服务器的本地授权。

7. 建立代理信任

要确保代理可信，采取的方法是先让客户端信任服务器（要求服务器进行身份验证），再让服务器信任代理（向服务器获取验证器并将代理传递给它）。若客户端信任服务器且服务器信任代理，则客户端可信任代理。但这两个步骤存在一些问题：
- 客户端在不信任下载的代理时，如何可靠地验证服务器的身份验证？代理需支持客户端信任的引导远程通信机制，如提供客户端信任的引导代理。在常见情况下，若动态代理的调用处理程序不依赖下载的代码，它可作为引导代理。不过，与服务器的正常通信不一定使用与引导代理相同的协议，引导代理可仅用于信任验证。
- 如何可靠地从服务器获取验证器？为确保远程调用和接收到的验证器对象可信，在通过引导代理进行远程调用以获取验证器时，需进行服务器身份验证和对象完整性保护。客户端需指定信任的服务器Principals并强制实施确保完整性保护和服务器身份验证的约束。

8. 动态策略

确定代理可信后，客户端可动态授予其权限，使其能与远程对等方交互并使用客户端Subject中的Principals和凭证。为防止不可信代理滥用权限，应在确定信任后再授予权限。Jini技术指定了一个动态策略接口，安全策略提供者可实现该接口。Sun的Jini实现包含一个通用包装策略提供者，可包装任意Policy实例，支持在运行时向具有特定类加载器和Principals集合的保护域进行动态授权。

对于已知受信任的代码源的部署，可配置RMIClassLoader提供者，使代码仅从具有足够权限的代码源下载，从而有效避免来自不可信代码的拒绝服务攻击。

9. J2EE简介

J2EE是J2SE的超集，用于管理容器内应用程序的安全。它提供基于组件的开发和部署模型，常见的容器类型有JavaServer Pages（JSP）、Java Servlet和Enterprise JavaBeans（EJB）。J2EE平台管理组件的底层基础设施，使应用程序开发者可专注于应用功能，而无需关注安全和计算基础设施的管理。当组件安装到容器中时，其安全要求在部署描述符中声明，部署后容器确保在组件调用和交互的整个生命周期内满足这些要求。

随着企业应用的成功，也带来了新的平台需求。为集成到企业的访问管理系统中，未来的J2EE平台规范将纳入Java容器授权契约，将J2SE的安全策略功能与J2EE的容器管理概念完全集成，具体表现为实现Permission、Policy和管理接口，以便容器部署工具创建和管理与角色对应的权限集合。

目前，J2EE平台管理托管组件的对等身份验证，其身份验证机制由平台规范固定为最常见的机制。预计短期内需要支持新的身份验证技术，为此Java社区正在开发Java身份验证服务提供者接口。

10. 客户端容器

自Java诞生以来，客户端容器就是应用程序交付模型的一部分。最初的客户端容器是appletviewer实用程序，随着Java的普及，浏览器厂商将Java运行时环境集成到浏览器中以支持小程序。为满足企业需求，Sun开发了Java Plug - in（JPI）小程序容器，它可指定版本信息以选择和安装兼容的Java运行时，已成为主流浏览器的默认Java运行时环境。

虽然小程序是一种很好的交付和部署机制，但在许多情况下，独立应用程序是更好的选择。为解决应用程序的交付、可管理性和兼容性问题，Java社区开发了Java Web Start（JWS）应用程序容器。

JPI和JWS都有独特的集成和安全要求。JPI需确保小程序遵循Java安全模型并能与文档对象模型交互，这对小程序的访问权限有一定限制。JWS需确保应用程序的权限符合策略要求，且用户接受签名证书。为此，JPI和JWS都实现了自定义的ClassLoader和SecurityManagers，以满足客户端容器的独特需求。例如，JPI需确保缓存的JAR文件仅由符合CodeSource规则的类访问，当遇到权限不足的小程序时，可能需要与用户交互以覆盖安全策略，并记录用户的选择，避免后续重复提示。

用户管理安全策略并非解决此类问题的最佳方式，未来可能会出现更好的解决方案。策略表达语言和证书状态及撤销检查的改进将大大减轻用户的负担。同时，对于应用程序开发者来说，简单的安全API可帮助他们在不深入了解安全细节的情况下编写安全的应用程序，提高开发效率和应用程序的安全质量。

以下是Jini技术信任代理建立过程的mermaid流程图：

graph LR
    A[客户端] -->|要求服务器验证| B[服务器]
    B -->|返回验证信息| A
    A -->|向服务器请求验证器| B
    B -->|返回验证器| A
    A -->|将代理传递给验证器| C[验证器]
    C -->|验证结果| A
    A -->|根据结果决定是否信任代理| D{是否信任代理}
    D -- 是 --> E[授予代理权限]
    D -- 否 --> F[不授予权限]

以下是常见Java部署范式的对比表格：
| 部署范式 | 特点 | 适用场景 |
| ---- | ---- | ---- |
| J2EE | 管理容器内应用程序安全，提供组件化开发和部署模型 | 企业级应用开发 |
| Java Web Start | 解决独立应用程序的交付、管理和兼容性问题 | 独立应用程序部署 |
| Java Plug - in | 支持小程序，可指定Java运行时版本 | 小程序运行 |

Java安全技术架构与应用解析

11. 技术综合分析与对比

为了更清晰地了解不同技术在安全方面的特点和适用场景，我们对Jini、J2EE、JPI和JWS进行综合对比，如下表所示：
| 技术 | 安全核心特点 | 适用场景 | 优势 | 挑战 |
| ---- | ---- | ---- | ---- | ---- |
| Jini | 基于代理的信任机制，支持可配置安全和动态策略 | 动态自适应服务网络 | 灵活的安全配置，支持代码移动性 | 建立代理信任过程复杂 |
| J2EE | 管理容器内应用安全，集成J2SE安全策略 | 企业级应用开发 | 组件化开发，简化安全管理 | 需适应企业复杂安全环境 |
| JPI | 确保小程序遵循安全模型并与DOM交互 | 小程序运行 | 可指定Java运行时版本，支持小程序 | 需处理小程序与文档的复杂交互 |
| JWS | 保证应用权限符合策略，用户接受签名证书 | 独立应用程序部署 | 解决应用交付、管理和兼容性问题 | 需确保用户接受签名证书 |

从这个表格可以看出，不同技术在安全方面各有侧重，开发者需要根据具体的应用场景和需求选择合适的技术。

12. 安全技术的发展趋势

随着信息技术的不断发展，Java安全技术也在不断演进。未来，可能会出现以下发展趋势：
- 更强大的可插拔性 ：现有的服务提供者接口将进一步完善，更多的安全功能可以通过插件的形式集成，如JSSE和Java GSS - API可能会有更完善的SPI，以支持更多的加密算法和身份验证机制。
- XML安全的广泛应用 ：随着XML安全规范的稳定，XML安全技术将在Web服务等领域得到更广泛的应用，为企业级应用提供更强大的安全保障。
- 简化安全管理 ：通过改进策略表达语言和证书管理机制，进一步简化安全管理，减轻用户和开发者的负担。例如，用户可以更方便地管理安全策略，开发者可以更轻松地调用安全服务。
- 增强代码移动性安全 ：对于像Jini这样依赖代码移动性的技术，将进一步加强代码下载和执行的安全性，防止恶意代码的攻击。

13. 实际应用案例分析

为了更好地理解这些安全技术的实际应用，我们来看一个企业级Web应用的案例。假设一家企业要开发一个基于Web的客户关系管理系统（CRM），该系统需要处理大量的客户信息，对安全性要求较高。

• 选择J2EE平台 ：由于CRM系统是企业级应用，需要管理多个组件（如JSP页面、Servlet和EJB），因此选择J2EE平台来管理应用的安全。J2EE的组件化开发和部署模型可以让开发者专注于业务逻辑，而J2EE平台会管理底层的安全基础设施。
• 集成XML安全 ：在数据传输和存储过程中，使用XML签名和加密技术来保护客户信息的完整性和保密性。例如，在将客户数据存储到数据库之前，对数据进行XML加密；在数据传输过程中，使用XML签名来验证数据的来源。
• 使用Jini技术进行服务发现 ：如果CRM系统需要与其他企业内部的服务进行交互，可以使用Jini技术来实现服务的发现和调用。Jini的动态自适应网络可以让系统更灵活地适应不同的服务环境。
• 采用JPI和JWS进行客户端部署 ：对于需要在浏览器中运行的部分功能（如报表查看），可以使用JPI来确保小程序的安全运行；对于独立的客户端应用（如数据同步工具），可以使用JWS来解决应用的交付和管理问题。

14. 操作步骤总结

在实际应用中，涉及到一些具体的操作步骤，下面进行简要总结：
- Jini代理信任建立步骤 ：
1. 客户端要求服务器进行身份验证，服务器返回验证信息。
2. 客户端向服务器请求验证器，服务器返回验证器。
3. 客户端将代理传递给验证器进行验证。
4. 根据验证结果，客户端决定是否信任代理，若信任则授予代理权限。
- J2EE组件安全配置步骤 ：
1. 在部署描述符中声明组件的安全要求。
2. 部署组件到J2EE容器中。
3. J2EE容器在组件调用和交互过程中检查并确保安全要求得到满足。
- JPI和JWS权限管理步骤 ：
1. JPI确保缓存的JAR文件仅由符合CodeSource规则的类访问。
2. 当遇到权限不足的小程序或应用时，JPI和JWS与用户交互，请求用户覆盖安全策略。
3. 记录用户的选择，避免后续重复提示。

15. 总结与建议

Java安全技术为开发者提供了丰富的工具和机制来保障应用程序的安全。不同的技术适用于不同的场景，开发者需要根据具体需求选择合适的技术。在实际应用中，要注意以下几点：
- 合理选择技术 ：根据应用的规模、复杂度和安全要求，选择合适的Java安全技术，如J2EE适用于企业级应用，Jini适用于动态服务网络。
- 遵循安全规范 ：在使用XML安全、JAAS等技术时，要遵循相关的规范和标准，确保安全机制的正确实现。
- 持续关注技术发展 ：随着安全威胁的不断变化和技术的不断进步，要持续关注Java安全技术的发展趋势，及时更新和改进应用的安全策略。

以下是企业级Web应用安全架构的mermaid流程图：

graph LR
    A[客户端] -->|HTTP请求| B[J2EE服务器]
    B -->|调用服务| C[Jini服务网络]
    B -->|数据处理| D[数据库]
    B -->|XML安全处理| E[XML签名/加密]
    E -->|加密数据| D
    D -->|解密数据| E
    E -->|返回数据| B
    B -->|返回响应| A
    F[JPI/JWS客户端] -->|访问应用| B

通过以上的分析和总结，我们可以看到Java安全技术在保障应用程序安全方面的重要性和多样性。开发者可以根据实际情况灵活运用这些技术，构建安全可靠的应用系统。