基于corba的电子商务系统的安全性(doc10)-电子商务(编辑修改稿)

基于corba的电子商务系统的安全性(doc10)-电子商务(编辑修改稿)内容摘要：

中的通用安全互操作部分定义了通用安全性机制，使得可以安全互操作。 分布式对象系统的 CORBA 安全模式建立在表 1 所示的安全性特征的基础上。 机密 性（ Confidentiality） 完整性 (Integrity) 可说明性 (Accountability) 表 1： 安全性特 征 CORBA 安全服务规范定义了不同的对象接口，这些接口提供了下面的安全功能来增强上面提及的安全性特征（见表 2）。 安全性管理：方法和范围（ Security Administration：Policies and Domains） 鉴定 (Authentication) 安 全 性 上 下 文 制 定 （ Security context establishment） 存取控制（ Access control） 通讯保护（完整性，机密性） Communications protection(integrity,confidentiality) 5 安全性审计 (Security audit) 认可 (Nonrepudiation) 表 2 ： CORBA 安全服务规范中的安全性功能 实际上，特别是在电子商务中， CORBA 安全服务规范中的安全服务将不可避免的过于沉重和复杂。 个别电子商务系统可能有不同于最初由 OMG 预想中 CORBA 系统的特别安全性需求。 值得指出的是，在这个阶段， CORBA 安全性服务是围绕分布式计算环境（ DCE）而设计的，典型地都 工作在类似于校园的封闭式环境中，下层平台和政策都可控制（也就是说，可以安装和管理 DCE 底层安全性结构）。 在这种环境中，基本的安全需求是保护系统，防止未验证的使用和修改。 5．电子商务安全需求 今天的电子商务系统中，一些安全需求与类似于 DCE 的环境大相径庭。 在 DCE 中，客户必须信任服务器和系统，但需保护服务器以防未验证的客户。 电子商务环境中，也需要防止有恶意的会员。 因此，系统必须保护客户以防恶意的服务器和另外的客户，也要保护服务器以防未验证的客户。 互相不信任的参与者这个概念并不是 DCE所固有的。 在传统的 环境中，通过所有权来指定系统的责任，并用通过这些所有权的范围来定义信任边界。 在开放式系统中，信任边界、所有权和责任范围可能不同，这引发了不同的问题。 例如，商家可能负责购物过程的安全性，而不能控制客户系统。 另外，也常常不能规定客户软件所运行的平台（例如， CORBA 产品， Java 版本，操作系统）或安全政策（例如，操作系统安全性配置）。 另一方面，客户可能负责一段它并不理解的而后台透明运作的软件，而这个软件可能是由一个后来和客户发生纠纷的供应商提供的。 这造成了系统中可信部分如何在供应商和客户间分配的问题。 交易的合 伙人之间的契约关系应该指明风险分派，责任分派和解决纠纷的原则。 就电子商务来说，我们现在必须处理可能来自一些不可信任源，并且运行在不安全的下层操作系统上的硬件和软件，因此建立这种契约关系的困难就更大了。 这样的软件偶尔会失效或者恶意 6 地运作，并且太复杂而不能成为多数终端用户的责任。 在更技巧性的层上，事务和支付需求更强的完整性和机密性保护，同时需要保证电子兑现的匿名性。 也可能存在购物时可以在浏览器端下载轻量的客户应用程序的需求。 在这些情况下，客户机装不上大的安全基本设施。 客户端的安全政策也许也不允许购物软件永 久安装。