29、Java 2平台安全配置与管理全解析

Java 2平台安全配置与管理全解析

在Java 2平台的应用开发与部署过程中,安全是至关重要的一环。本文将深入探讨Java 2平台安全相关的多个方面,包括安全属性设置、部署安全保障、提供者包安装以及策略配置等内容,为开发者提供全面的安全配置与管理指导。

1. 安全属性设置

安全属性在Java 2平台安全中起着关键作用,它可以指定Policy实现类等重要信息。例如, policy.provider 安全属性用于指定要安装的Policy实现类的规范名称。默认情况下,Sun Microsystems的实现为:

policy.provider=sun.security.provider.PolicyFile

若要使用不同的Policy实现,可将值修改为扩展了Policy类的其他类,示例如下:

policy.provider=com.example.MyPolicy

还可以通过调用 java.security.Security.setProperty 方法动态设置安全属性,示例代码如下:

Security.setProperty("propertyName", "propertyValue");

若要设置 com.example.MyPolicy 实现,可使用以下代码:

Security.setProperty("policy.provider", "com.example.MyPolicy");
2. 部署安全保障

为确保部署的安全性,首先要保证JRE安装的安全性。通常,默认安装(如Solaris上预装的JRE或Netscape Navigator捆绑的JRE)不会自定义安全属性,而是依赖J2SE平台供应商提供的默认设置。然而,当部署环境需要更严格的控制时,默认安全属性可能并不适用。

2.1 限制属性覆盖机制

J2SE 1.4引入了系统属性 java.security.properties ,指定该属性可使应用程序覆盖或追加安全属性。覆盖与追加的区别取决于使用的是双等号还是单等号。例如,以下命令可增强安全属性文件中的设置:

java -Djava.security.properties=someURL someApp

当安全属性文件URL前使用单等号时,指定的文件将与已安装的安全属性文件一起使用,且指定文件中的属性将与默认安全属性文件中的属性合并,并优先使用。URL可以是常规URL,也可以是当前目录中安全属性文件的名称。

为抑制覆盖机制,可将 security.overridePropertiesFile 安全属性设置为 false ,默认情况下该属性设置为 true

2.2 配置特定于应用程序的策略

安全属性文件中指定的策略文件是系统范围的,运行任何小程序或应用程序时都会使用同一组策略文件。调用应用程序时,可通过 -Djava.security.policy 命令行参数指定额外或不同的策略文件,示例如下:

java -Djava.security.manager -Djava.security.policy=someURL someApp

其中, someURL 是指定策略文件位置的URL。当策略文件URL前使用单等号时,指定的策略文件将与安全属性文件中指定的所有策略文件一起使用。URL可以是绝对URL,也可以是当前目录中策略文件的名称。

-Djava.security.manager 参数可确保安装默认安全管理器,使应用程序在安全策略生效的情况下运行。若应用程序本身安装了安全管理器,则无需此选项。

若策略文件URL前使用双等号,如以下命令:

java -Djava.security.manager -Djava.security.policy==someURL someApp

则仅使用指定的策略文件,其他文件将被忽略。

使用 appletviewer 运行小程序时,可使用 -Djava.security.policy 参数指定策略,根据需要使用一个或两个等号,示例如下:

appletviewer -J-Djava.security.policy=someURL someApplet

需注意,若 policy.allowSystemProperty 安全属性值设置为 false -Djava.security.policy 选项中指定的策略文件值将被忽略,该属性默认设置为 true

3. 提供者包安装

提供者是提供Java 2 SDK安全API或其扩展(可选包)中部分加密或其他安全服务具体实现的包或包集合。Java 2运行时已预装了Sun Microsystems的多个提供者,如SUN提供者,它包含数字签名算法(DSA)、DSA密钥对和算法参数生成器等实现;SunJCE提供者则提供更多加密服务。

应用程序可请求实现特定服务的特定类型对象,并从已安装的提供者中获取实现。例如,请求特定签名算法的Signature对象,可调用 getInstance 静态工厂方法,示例代码如下:

Signature dsa = Signature.getInstance("SHA1withDSA")

调用此方法时,会搜索已安装的提供者,直到找到支持 SHA1withDSA 算法的提供者,并使用该提供者的实现。若需要特定提供者的实现,可调用包含提供者参数的 getInstance 方法,示例如下:

Signature dsa = Signature.getInstance("SHA1withDSA", "SUN")
3.1 安装提供者类

使用提供者前必须先安装,若请求的提供者未安装,即使其他已安装的提供者实现了请求的算法,也会抛出 java.security.NoSuchProviderException 异常。安装提供者类有两种方式:
- 将包含类的zip或JAR文件放置在 CLASSPATH 中的任何位置。
- 将提供者JAR文件作为已安装或捆绑的扩展(可选包)提供。

安装完成后,还需配置提供者,即将其添加到请求服务时搜索的提供者列表中。

3.2 配置提供者

可静态或动态配置提供者。静态配置需编辑Java安全属性文件,可设置的一种属性是定义提供者主类的属性,格式如下:

security.provider.n=masterClassName

此属性声明一个提供者并指定其优先级顺序 n ,优先级顺序是在未请求特定提供者时搜索请求算法或其他服务的提供者的顺序,顺序从1开始,1为最优先。 masterClassName 指定提供者主类的规范名称,该类必须是 java.security.Provider 类的子类,其构造函数会设置Java 2安全API所需的各种属性值。

例如,若主类为 COM.abcd.provider.Abcd ,要将Abcd配置为优先级顺序中的第三个提供者,可在安全属性文件中添加以下行:

security.provider.3=COM.abcd.provider.Abcd

也可通过调用 java.security.Security 类中的 addProvider insertProviderAt 方法动态注册提供者,但这种注册方式不是持久的,且只有被授予足够权限的程序才能执行。调用这些方法需要具有目标名称为 "insertProvider.providerName" java.security.SecurityPermission ,其中 providerName 为提供者名称,也可用 * 表示可添加任何提供者。

以下是一个使用Sun策略语法的示例,指定从本地文件系统 /home/sysadmin/ 目录下的签名JAR文件加载的代码可调用 Security 类中的方法添加或删除提供者:

grant signedBy "sysadmin", codeBase "file:/home/sysadmin/*" {
    permission java.security.SecurityPermission "insertProvider.*";
    permission java.security.SecurityPermission "removeProvider.*";
};
4. 策略配置

若安装了安全管理器但未为运行小程序或应用程序指定安全策略,JRE将默认使用沙盒安全模型。为充分利用Java 2安全模型,需制定安全策略,明确允许访问哪些安全敏感资源,并将该策略指定给JRE。

4.1 配置系统范围和特定于用户的策略

默认的J2SE Policy实现从静态策略配置文件(通常称为策略文件)获取信息,策略文件可使用简单的文本编辑器编写。默认系统策略文件的位置如下:
- Solaris、Linux系统: <java.home>/lib/security/java.policy
- Windows系统: <java.home>\lib\security\java.policy
其中, <java.home> java.home 系统属性的值。

默认用户策略文件的位置如下:
- Solaris、Linux系统: <user.home>/.java.policy
- Windows系统: <user.home>\.java.policy
其中, <user.home> user.home 系统属性的值。

Policy对象首次调用 getPermissions 方法或 refresh 方法时会初始化,初始化过程包括解析策略文件并将策略信息填充到Policy对象中。初始化时,先加载系统策略,再加载用户策略,若两者都不存在,则使用内置的沙盒策略。

策略文件位置默认在安全属性文件中指定,属性名称格式为 policy.url.n ,其中 n 为数字,值为URL,即使在Windows系统上也始终使用正斜杠。例如,默认系统和用户策略文件在安全属性文件中的定义如下:

policy.url.1=${java.home}/lib/security/java.policy
policy.url.2=${user.home}/.java.policy

其中, ${java.home} ${user.home} 分别表示 java.home user.home 系统属性的值。

若要忽略默认用户策略,可删除或注释掉第二行。若要指定多个策略文件以形成复合安全策略,可提供多个 policy.url.n 行,每行指定一个不同的URL。所有指定策略文件的内容将用于填充Policy对象。需注意, policy.url.n 中的 n 必须从1开始且为连续整数,否则后续不连续的行将被忽略。

4.2 默认策略文件格式

JRE安装的策略配置文件指定了来自指定代码源的代码允许访问的系统资源类型(即权限)。程序要执行安全操作(如读取或写入文件),必须被授予该特定操作的权限。默认Policy实现使用时,权限必须通过策略文件中的 grant 条目授予(代码自动拥有读取自身CodeSource及其子目录下文件的权限,无需显式授权)。

策略配置文件的语法包含一个条目列表,可能包含一个密钥库条目和零个或多个 grant 条目。

  • 密钥库条目 :密钥库是私钥及其关联数字证书(如X.509证书链)的受保护数据库。J2SE中的默认密钥库实现将密钥库作为文件处理,可使用 keytool 实用工具创建和管理。策略配置文件中指定的密钥库用于查找 grant 条目中指定的签名者的公钥。密钥库条目语法如下:
keystore "some-keystore-url", "keystore-type";

其中, "some-keystore-url" 指定密钥库的URL, "keystore-type" 可选,用于指定密钥库类型。URL通常相对于策略文件位置,若策略文件中有如下条目:

keystore ".keystore";

且策略文件的URL为 policy.url.1=http://foo.bar.com/fum/some.policy ,则密钥库将从 http://foo.bar.com/fum/.keystore 加载。

  • Grant条目 :策略配置文件包含零个或多个 grant 条目。执行的代码始终被视为来自特定的代码源,在运行时由 CodeSource 类型的对象表示。每个 grant 条目可指定可选的 codeBase signedBy principal 字段,基本格式如下:
grant signedBy "signer-names", codeBase "URL",
    principal principal-class-name "principal-name",
    ... {
    permission permission-class-name "target-name", "action",
    ...
};

其中, signedBy 字段指定签名者别名列表,多个别名用逗号分隔,关系为AND; codeBase 字段指定代码源位置(URL); principal 字段指定执行代码的主体。 permission 条目指定权限类名、目标名称和操作,目标名称对所有权限类型都是必需的,操作对某些权限类型是可选的,对其他类型是必需的。

以下是一个策略文件格式的正式BNF(巴科斯 - 诺尔范式)语法:

PolicyFile --> PolicyEntry | PolicyEntry; PolicyFile
PolicyEntry -->    grant {PermissionEntry}
   | grant SignerEntry {PermissionEntry}
   | grant CodebaseEntry {PermissionEntry}
   | grant PrincEntry {PermissionEntry}
   | grant SignerEntry, CodebaseEntry {PermissionEntry}
   | grant SignerEntry, PrincEntry {PermissionEntry}
   | grant CodebaseEntry, SignerEntry {PermissionEntry}
   | grant CodebaseEntry, PrincEntry {PermissionEntry}
   | grant PrincEntry, SignerEntry {PermissionEntry}
   | grant SignerEntry, CodebaseEntry, PrincEntry {PermissionEntry}
   | grant PrincEntry, CodebaseEntry, SignerEntry {PermissionEntry}
   | keystore "url"
SignerEntry -->   signedBy (a comma-separated list of strings)
CodebaseEntry --> codeBase (a string representation of a URL)
PrincEntry --> OnePrincipal | OnePrincipal, PrincEntry
OnePrincipal --> principal [ principal-class-name ] "principal-name"
PermissionEntry --> OnePermission | OnePermission PermissionEntry
OnePermission --> permission permission-class-name [ "target-name" ] [, "action"] [, SignerEntry];

综上所述,Java 2平台的安全配置与管理涉及多个方面,包括安全属性设置、部署安全保障、提供者包安装和策略配置等。开发者需根据具体的应用场景和安全需求,合理配置和管理这些安全要素,以确保Java应用程序的安全性和稳定性。

以下是一个简单的mermaid流程图,展示了配置特定于应用程序的策略的流程:

graph TD;
    A[启动应用程序] --> B[是否指定-Djava.security.policy参数];
    B -- 是 --> C[参数中使用单等号?];
    C -- 是 --> D[指定的策略文件与安全属性文件中的策略文件一起使用];
    C -- 否 --> E[仅使用指定的策略文件,忽略其他];
    B -- 否 --> F[使用安全属性文件中指定的策略文件];

另外,为了更清晰地展示不同操作系统下默认策略文件的位置,我们可以使用表格:
| 操作系统 | 默认系统策略文件位置 | 默认用户策略文件位置 |
| — | — | — |
| Solaris、Linux | <java.home>/lib/security/java.policy | <user.home>/.java.policy |
| Windows | <java.home>\lib\security\java.policy | <user.home>\.java.policy |

通过以上的配置和管理,开发者能够在Java 2平台上构建出更加安全可靠的应用程序。

5. 策略文件语法详解

策略文件在Java 2平台安全中起着关键作用,它定义了代码源与权限之间的映射关系。以下将对策略文件中各个部分的语法进行更详细的解释。

5.1 策略文件整体结构

策略文件可以包含一个密钥库条目和多个 grant 条目。密钥库条目用于指定存储签名者公钥的密钥库,而 grant 条目则用于授予代码源特定的权限。

下面是一个简单的策略文件示例:

keystore "file:/path/to/keystore.jks", "JKS";

grant signedBy "signer1", codeBase "file:/path/to/code/" {
    permission java.io.FilePermission "file:/path/to/file.txt", "read,write";
};
5.2 密钥库条目详解

密钥库条目指定了存储签名者公钥的密钥库的位置和类型。其语法如下:

keystore "some-keystore-url", "keystore-type";
  • some-keystore-url :指定密钥库的URL,可以是相对路径或绝对路径。
  • keystore-type :可选参数,指定密钥库的类型,如 JKS PKCS12 等。默认类型为 JKS

例如:

keystore "file:/home/user/keystore.jks", "JKS";
5.3 Grant条目详解

grant 条目用于授予代码源特定的权限。其基本格式如下:

grant signedBy "signer-names", codeBase "URL",
    principal principal-class-name "principal-name",
    ... {
    permission permission-class-name "target-name", "action",
    ...
};
  • signedBy :指定签名者的别名列表,多个别名用逗号分隔。例如: signedBy "signer1,signer2" 表示代码必须由 signer1 signer2 签名才能获得相应的权限。
  • codeBase :指定代码源的URL。例如: codeBase "file:/path/to/code/" 表示授予该URL下的代码相应的权限。
  • principal :指定执行代码的主体。例如: principal java.security.Principal "user1" 表示只有由 user1 主体执行的代码才能获得相应的权限。
  • permission :指定授予的权限。其格式为 permission permission-class-name "target-name", "action"
  • permission-class-name :指定权限类的名称,如 java.io.FilePermission java.lang.RuntimePermission 等。
  • target-name :指定权限的目标,如文件路径、系统属性名等。
  • action :指定权限的操作,如 read write execute 等。

以下是一个更详细的 grant 条目示例:

grant signedBy "signer1", codeBase "file:/path/to/code/" {
    permission java.io.FilePermission "file:/path/to/file.txt", "read,write";
    permission java.lang.RuntimePermission "modifyThread";
};
6. 安全属性设置与策略配置的实际应用

在实际开发中,安全属性设置和策略配置是保障Java应用程序安全的重要手段。以下将通过具体的示例说明如何进行安全属性设置和策略配置。

6.1 安全属性设置示例

假设我们需要使用自定义的Policy实现类 com.example.MyPolicy ,可以通过以下两种方式进行设置:

静态设置 :在Java安全属性文件中添加以下行:

policy.provider=com.example.MyPolicy

动态设置 :在Java代码中使用 Security.setProperty 方法进行设置:

import java.security.Security;

public class SecurityPropertyExample {
    public static void main(String[] args) {
        Security.setProperty("policy.provider", "com.example.MyPolicy");
    }
}
6.2 策略配置示例

假设我们有一个Java应用程序,需要对不同的代码源授予不同的权限。可以创建一个策略文件 myPolicy.policy ,内容如下:

grant codeBase "file:/path/to/trusted/code/" {
    permission java.io.FilePermission "file:/path/to/trusted/files/*", "read,write";
    permission java.lang.RuntimePermission "modifyThread";
};

grant codeBase "file:/path/to/untrusted/code/" {
    permission java.io.FilePermission "file:/path/to/untrusted/files/*", "read";
};

然后在启动应用程序时,通过 -Djava.security.policy 参数指定该策略文件:

java -Djava.security.manager -Djava.security.policy=file:/path/to/myPolicy.policy MyApp
7. 总结与建议

通过对Java 2平台安全配置与管理的深入探讨,我们了解到安全属性设置、部署安全保障、提供者包安装和策略配置等方面的重要性。以下是一些总结和建议:

  • 安全属性设置 :根据实际需求选择静态或动态设置安全属性。静态设置适用于全局配置,而动态设置适用于在运行时根据不同情况进行调整。
  • 部署安全保障 :限制属性覆盖机制可以防止恶意代码篡改安全属性,配置特定于应用程序的策略可以根据不同应用的需求进行精细的权限控制。
  • 提供者包安装 :根据应用程序的需求选择合适的提供者,并正确安装和配置提供者类。
  • 策略配置 :合理设计策略文件,明确代码源与权限之间的映射关系,确保应用程序的安全性。

以下是一个简单的mermaid流程图,展示了Java 2平台安全配置的整体流程:

graph TD;
    A[开始] --> B[设置安全属性];
    B --> C[保障部署安全];
    C --> D[安装提供者包];
    D --> E[配置策略文件];
    E --> F[应用程序运行];
    F --> G[监控与调整];
    G --> E;

同时,为了更清晰地展示不同操作的注意事项,我们可以使用表格:
| 操作 | 注意事项 |
| — | — |
| 安全属性设置 | 静态设置需修改安全属性文件,动态设置需在代码中调用 Security.setProperty 方法 |
| 部署安全保障 | 限制属性覆盖机制可通过设置 security.overridePropertiesFile 属性,配置特定于应用程序的策略需注意 -Djava.security.policy 参数的使用 |
| 提供者包安装 | 安装提供者类有两种方式,配置提供者可静态或动态进行 |
| 策略配置 | 策略文件语法需正确, policy.url.n 中的 n 必须从1开始且为连续整数 |

通过遵循以上建议,开发者可以更好地保障Java应用程序的安全性和稳定性。

【电能质量扰动】基于ML和DWT的电能质量扰动分类方法研究(Matlab实现)内容概要:本文研究了一种基于机器学习(ML)和离散小波变换(DWT)的电能质量扰动分类方法,并提供了Matlab实现方案。首先利用DWT对电能质量信号进行多尺度分解,提取信号的时频域特征,有效捕捉电压暂降、暂升、中断、谐波、闪变等常见扰动的关键信息;随后结合机器学习分类器(如SVM、BP神经网络等)对提取的特征进行训练分类,实现对不同类型扰动的自动识别准确区分。该方法充分发挥DWT在信号去噪特征提取方面的优势,结合ML强大的模式识别能力,提升了分类精度鲁棒性,具有较强的实用价值。; 适合人群:电气工程、自动化、电力系统及其自动化等相关专业的研究生、科研人员及从事电能质量监测分析的工程技术人员;具备一定的信号处理基础和Matlab编程能力者更佳。; 使用场景及目标:①应用于智能电网中的电能质量在线监测系统,实现扰动类型的自动识别;②作为高校或科研机构在信号处理、模式识别、电力系统分析等课程的教学案例或科研实验平台;③目标是提高电能质量扰动分类的准确性效率,为后续的电能治理设备保护提供决策依据。; 阅读建议:建议读者结合Matlab代码深入理解DWT的实现过程特征提取步骤,重点关注小波基选择、分解层数设定及特征向量构造对分类性能的影响,并尝试对比不同机器学习模型的分类效果,以面掌握该方法的核心技术要点。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值