JavaTM安全体系结构（JDK1.2） 　 1. 引言 自从Java技术开始应用以来，人们对Java平台的安全以及由于部署Java技术所引发的安全问题，越来越感兴趣。 按照Java设计者的观点，Java安全包括两个方面的内容： 将Java作为一种安全的、安装好的平台提供给用户（主要通过JDK），在此平台上，可安全地运行Java应用程序。 提供用Java编程语言实现的安全工具和服务，它使得诸如企业界这样一些对安全非常敏感的领域也可应用Java技术。 本文将讨论第一个方面的内容，应用这方面技术的用户包括将Java技术捆绑或嵌入到自身产品中的厂商（如浏览器和操作系统厂商）。 1.1 初始沙箱模型 众所周知, 由Java平台提供的最初的安全模型是一种沙箱模型, 它是为了建立一个极有限的环境而设置的, 在这个环境中, 可运行从开放网络中获取的不可信代码。沙箱模型的实质是，本地代码是可信的，因而可全部访问关键系统资源（如文件系统）；而下载的远程代码（一个Applet）是不可信的，因而只能访问由沙箱内部所提供的有限资源。这种沙箱模型如下图所示： 沙箱模型是通过Java开发工具包（JDK）部署的，一般来说，它可被由JDK1.0（包括可运行Java的Web浏览器）建立的应用程序所采用。 总的安全性的提高是通过采用一系列机制来实现的。首先，Java语言被设计为是类型安全的且便于使用，其目的是为减轻程序员的负担，减少出现象使用其它编程语言时（如C或C++）所出现的编程错误。该语言的特点，如自动内存管理、内存垃圾回收及字符串和数组的越界检查等，都可成为该语言帮助程序员编写安全代码的佐证。 其次，编译器和字节码校验器可保证只有合法的Java字节码才能被执行。字节码校验器与Java虚拟机一起保证了在运行时的语言安全。 再次，类装载器可定义一个本地名空间，这可以保证一个不可信Applet不会干扰其它程序的运行。 最后，对重要系统资源的访问是通过Java虚拟机来传递的，并由SecurityManager类进行预先检查，这就将不可信代码的活动限制到了最小的程度。 JDK1.1引进了"已签字的Applet"的概念，如下图所示。在这个版本中，一个有着正确的数字签字的Applet，如果它的签字被接收该Applet的最终系统确认为是可信的，则这个Applet被认为是可信代码。已签字的Applet，与它们的签字一起，以JAR（Java Archive）格式发出。在JDK1.1中，未签字的Applet始终运行于沙箱之中。 1.2沙箱模型的演化 在JDK1.2中采用的新的安全体系结构(如下图所示)，主要是为了以下目的而引进的： 精致的访问控制 这种能力从一开始就在JDK中存在，但要使用它，应用程序的编写者不得不做大量的编程工作（例如，创建SecurityManager和Classloader类的子类并使其用户化）。HotJava1.0就是一个这样的应用程序，它允许浏览器用户在几个不同的安全等级上进行选择。 然而，这种编程涉及非常敏感的安全问题，它要求程序员对计算机安全有精深的理解和纯熟的技巧。新的安全体系结构将使这些变得简单而安全。 易于设置安全策略 与上述情况相似，这种能力在原来的JDK中也是存在的，但是不便于使用，而且编写安全代码也不是简单明了的事情。于是，人们期望能够允许应用程序的编写者和用户能够不通过编程来设置安全策略。 便于扩展的访问控制结构 一直到JDK1.1为止，为了创建一个新的访问许可，你必须在SecurityManager类中增加一个新的check方法。新的安全体系结构则允许设置各类访问许可（每个都表示对一个系统资源的访问）并能对所有正确访问许可（包括未定义的许可）进行自动处理。在大多数情况下都不必在SecurityManager类中创建新的方法（事实上，至今我们从未遇到过需创建新方法的情形）。 将安全检查扩展至所有Java应用中，包括应用程序和小应用程序 那种所有本地代码是可信的内置概念将不复存在，取而代之的将是，本地代码（例如非系统代码，安装在本地的应用程序包等）服从于与Applet相同的安全控制，尽管（如果需要的话）可以声明对本地代码（甚至是远程代码）的政策是最宽容的，从而使这些代码可被认为是完全可信的而有效地运行。上述原则也可应用与已签字的Applets和任何Java应用程序。 总而言之，上述做法的目的无疑是要对安全类的设计做内部调节（包括SecurityManager和ClassLoader类）以减少在未来编程中出现细小的安全空洞的风险。 ..........|Next|.......... 欢迎与我们联系：webmaster@prc.sun.com 版权所有 1997-1998 Sun(中国)公司，北京南礼士路66号建威大厦16层 All rights reserved.Legal Terms