COM+安全特性分析

阅读更多

COM(Componet Object Model)是微软开发的一项具有位置透明性、语言无关性、版本升级鲁棒性等特征的系统级别的面向对象组件技术,它通过接口方式定义并实现不同软件模块之间的通信与协作功能。COM+在COM、DCOM(Distributed COM)和MTS(Microsoft Transaction Server)基础上进一步优化了组件管理环境与事务服务,并提供队列组件、事件模型、负载均衡、对象缓存、内存数据库以及安全机制等服务内容扩展。COM+把COM模型推向了更高层次,使得其成为了企业级别分布式软件开发领域的重要技术。
COM+的安全性依赖Windows的安全特性来验证调用者的身份以及相关授权,COM+还使用可靠的编码技术和相应目录配置来确保服务组件的部署的安全。


以下说明COM+应对一些常见威胁的对策
网络
在 Web 和应用程序之间使用 Internet 协议安全性 (IPSec) 加密通道。该解决方案常用于 Internet 数据中心。服务组件还支持远程过程调用 (RPC) 数据包级身份验证。该技术可提供基于数据包的加密,常用于确保与基于桌面的客户端的通信安全。

未经授权的访问
通过启用基于 COM+ 角色的授权(在默认情况下,它在 Microsoft Windows 2000 系统中禁用),可禁止匿名用户的访问,并提供基于角色的授权,从而控制了对服务组件展示的受限操作的访问。

无约束的委派
如果在 Windows 2000 系统中启用委派来许可远程服务器使用客户端模拟令牌访问网络资源,这种委派就是无约束的。这意味着,用户可创建无限多网络跃点 (network hop)。Microsoft Windows Server 2003 引入了受约束的委派。

配置数据泄漏
很多应用程序都使用对象构造函数字符串在 COM+ 目录中保存敏感数据(如数据库连接字符串)。这些字符串在对象创建时由 COM+ 检索并传递给该对象。如果要在目录中保存敏感的配置数据,请首先加密数据。

抵赖
如果用户否认执行了某项操作或事务,而您又没有足够的证据反驳,则产生抵赖威胁。必须在所有应用程序层执行审核工作。服务组件应在中间层记录用户的活动。通常,服务组件有访问原始调用者身份的权限,因为前端的 Web 应用程序常在企业服务方案中启用模拟。

编写的代码应具备以下一些安全特性
基于角色的授权
对于使用 COM+ 角色的基于角色的有效授权,请确保原始调用者的安全上下文用于调用服务组件。这样就能基于调用者的组成员身份执行基于角色的粒度授权。如果 ASP.NET Web 应用程序调用服务组件,则表示该 Web 应用程序要在调用您的组件前模拟它的调用者。

敏感数据保护
如果服务组件要处理敏感数据,则必须确保这些信息在网络中传输时非常安全。如果应用程序不在安全的 Internet 数据中心 (IDC) 环境(由 IPSec 提供传输级加密)中运行,可选择使用 RPC 加密。为此,必须使用数据包隐私性身份验证级别。

审核要求
要解决抵赖问题,必须记录企业服务组件执行的敏感事务。在设计时,应考虑需要审核的操作类型,以及应记录的详细信息。其中应至少包括启动事务的身份信息和执行事务的身份信息(二者可能相同,也可能不同)。

应用程序激活类型
在设计时,可决定激活服务组件的方式。可使用 Dllhost.exe 进程的实例激活,也可在客户端进程中运行。服务器应用程序在 Dllhost.exe 实例的进程外运行。库应用程序在客户端进程的地址空间中运行。由于缺少进程间的通信,使用库应用程序的效率更高。但是,库应用程序的可配置性较差,且不受进程级隔离的保护。很多安全设置(如身份验证和模拟级别)都继承自客户端进程。

事务
如果打算使用分布式事务,请考虑在何处启动事务,以及在防火墙分隔的组件和资源管理器间运行事务的后果。在本方案中,防火墙必须支持 Microsoft 分布式事务处理协调器 (DTC) 通信。

如果您的物理部署体系结构包括一个中间层应用程序服务器,通常应尽量从应用程序服务器中的企业服务启动事务,而不是从前端 Web 应用程序启动。

代码访问安全性
通常,使用服务组件的应用程序都是完全信任的。因此,代码访问安全性在授权调用代码方面作用有限。但是,企业服务要求调用代码必须有必要的权限来调用非托管代码。结果,您将无法直接从部分信任的 Web 应用程序中调用数据至企业服务应用程序。ASP.NET 的部分信任级别(高、中等、低和最低)不授予非托管代码权限。如果要从部分信任应用程序中调用服务组件,必须通过沙盒 (sandbox) 来处理调用您组件的特权代码。有关详细信息,请参阅本模块后面的代码访问安全性注意事项。

身份验证
企业服务应用程序使用 Windows 身份验证。具体是 NTLM 验证还是 Kerberos 验证由客户端和服务器操作系统决定。Windows 2000 或 Windows Server 2003 环境使用 Kerberos 身份验证。
在构建服务组件时,首要问题是确保所有的调用都进行了身份验证,从而防止匿名用户访问组件功能。

总结
企业服务 (COM+) 安全性要依赖 Windows 安全性来验证调用者的身份并进行授权。授权是使用含 Windows 组或用户帐户的 COM+ 角色来配置并控制的。与企业服务应用程序和服务组件相关的大多数威胁都可通过可靠的编码技术和正确的目录配置来解决。

开发人员必须使用声明性属性来设置服务组件的安全配置。这些属性决定了应用程序首次在企业服务中注册(常使用 Regsvcs.exe)时的配置方式。

并不是所有的安全配置设置都可使用属性来设置。管理员必须为服务器应用程序指定运行身份。此外,管理员还必须在部署时根据 Windows 组或用户帐户填充角色。

整理自:

微软《构建安全型服务组件》

张志军《一种高性能的分布式工作流系统实现框架》

你可能感兴趣的:(企业应用,应用服务器,网络应用,Windows,配置管理)