内容


部署安全的软件配置管理

IBM Rational ClearCase 安全特性概述

Comments

总体上讲,计算机安全性破坏会给受到攻击的组织造成巨大的财务损失。尽管所有组织都必须保护其资产免受攻击,但依据每个组织的信息安全需求,他们采取的保护措施具有不同的类型和权重。相应地,对计算机安全性的投资也不同,但根据 Gordon-Loeb 模型 的建议,每个组织应投入破坏导致的损失价值的约 1/3。必须分配该投资的一部分来确保用于生成资产的工具本身是安全的。

ClearCase 安全性

IBM® Rational® ClearCase® 是一个闭源软件配置管理 (SCM) 系统,支持针对不同需求的不同安全解决方案。它是一个企业级系统,提供了比其他 SCM 系统更严格的安全机制。评估 SCM 系统的安全性时,需要考虑以下几点:

  • 开源解决方案的内在风险:它们的漏洞容易被公众发现。
  • 您的安全需求:实施最简单的有效措施。随着管理的复杂性的增加,错误管理所带来的安全风险也会增加。
  • 您的组织需求:ClearCase 可以轻松地扩展到大型、全球分布式企业,同时支持基于 WAN 和副本的分布式开发。它提供了同时支持这些分发模型的安全特性。

本文将介绍 ClearCase 如何解决计算机安全性的以下方面:

  • 身份验证:验证安全性主体的身份
  • 授权:向经过验证的主体授予资产的访问权
  • 加密:编码信息,以便仅供授权的主体使用
  • 事件日志:创建主体在对象上的操作的可审核记录

ClearCase 身份验证

图 1 给出了 ClearCase 支持的两种基本的客户端类型:

  • 支持 LAN 的客户端,指的是 ClearCase 本地客户端 (CCLC)
  • WAN 友好的客户端,指的是 ClearCase 远程客户端 (CCRC)

这篇文章包含的基本 客户端类型,表示它们非常容易依据工作区类型(ClearCase 视图 类型)和其他参数而配置。

图 1. 客户端身份验证机制

ClearCase 本地客户端身份验证

ClearCase 本地客户端 (CCLC) 用户以及用户计算机的操作系统身份注册在一个安全域中,这个域的控制器专门用于保证 ClearCase 主体的身份。CCLC 用户向 ClearCase 授权机制提供其网络身份(从操作系统登录名提供)来发起 ClearCase 操作。经过验证的身份会持久保存,直到用户明确退出该域。

ClearCase 远程客户端身份验证

尽管 CCLC 用户被假设是受信任的主体,但 ClearCase 远程客户端 (CCRC) 用户被视为不值得信任。因此,身份验证比 CCLC 身份验证更明确(而且更繁琐)。CCRC 用户可能位于:

  • 域的外部
  • 包含该域的 LAN 上
  • 一个私有 WAN 上
  • 互联网上

备注:LAN 上的 CCRC 用户可能也是该域的成员,但 CCRC 客户端必须是经过明确验证的,无论它们的用户的域凭证是什么。

尽管 LAN 上的 CCRC 用户可以假设比互联网上的客户端更受信任,但所有不是该域的成员的客户端都同样地被视为不受信任。

CCRC 主体的身份首先建立为 CCRC WAN 服务器上的操作系统级身份。这个服务器位于该域中,而且经过了域控制器的验证。CCRC WAN 服务器使用用户名/密码验证通过 http(s) 连接的 CCRC 用户的身份后,用户可以通过向 CCRC WAN 服务器发出请求来发起 ClearCase 操作,这会代表它们向 ClearCase 服务器发出相应的请求。不同于 CCLC 用户,CCRC 用户必须登录到 CCRC WAN 服务器来运行每个会话,而且会话的超时取决于服务器设置。

ClearCase MultiSite

借助 ClearCase MultiSite 复制,您可以配置位于分布式域中的 ClearCase 部署的双向同步。这样一种配置构成了需要它们的开发项目的多个 “信任中心”。您还可以在参与副本之间的相互信任条件不适用时配置单向同步:例如,一个专用开发项目的副本从一个开源项目的副本接收更新,但没有将它的任何更改同步到开源副本。

授权

不受访问控制的授权

授权策略应首先解决不依赖于显式授权机制的访问控制。这些控制大大减少了违反授权的可能性,因为它们会阻止用户访问敏感的操作和数据。

ClearCase 远程客户端

CCRC 凭借其与敏感操作的隔离来支持不受访问控制的授权,如图 2 所示。而 CCLC 支持所有 ClearCase 功能(约 270 个操作,包括开发、管理和构建活动),CCRC 支持约 50 个操作,除了少数会话管理命令外,所有操作都仅限于开发活动。CCRC 操作由 CCRC WAN 服务器协调:CCRC 用户无法直接访问 ClearCase 服务器。CCRC 是不需要访问仅在 CCLC 中提供的特性(例如经过审核的构建版本和管理性操作)的用户的合适接口。

图 2. 不同客户端类型和与 ClearCase 服务器的间接性级别的 ClearCase 操作

将客户端部署在虚拟机上

用户与 SCM 数据的隔离得到保证后,您可以将 ClearCase 客户端部署到防火墙后的虚拟机 (VM) 上。在这种情况下,可以使用类似远程桌面的解决方案来访问 VM。因此,ClearCase 视图数据不在开发人员机器上,而是尽在受防火墙保护的 VM 上。

受访问控制的授权

ClearCase 授权机制的讨论需要从文件系统对象级别上开始。ClearCase 使用 UNIX/Linux® 平台上的 UNIX 权限(模式)和 Windows 上的 UNIX 风格的权限。UNIX/Linux 上的用户身份 (UID) 和 Windows® 上的会话 ID (SID) 可以单独分配权限,还可以组织到操作系统组中。操作系统组是被授予了分配给这些组的权限的指定 UID/SID 集。一个经过操作系统验证的主体可以属于多个组,这样它的权限就可以累积,并依据请求访问的对象上的保护级别不同而有所不同。

版本对象库

ClearCase 版本文件和目录位于一个名为版本对象库 (VOB) 的数据库中。VOB 是受保护对象和适用于 VOB 及其内含对象的大多数访问控制操作的主要存储库。VOB 本身受一个内置的 ClearCase 身份保护,该身份被称为 VOB 所有者,是 VOB 的创建者的身份。VOB 所有者(或另一个高特权身份,比如 UNIX 或 Linux 上的 root)可以编辑 VOB 保护设置来更改所有者和主体组,并添加或删除辅助组。如果高特权用户未在本地登录,VOB 所有者也可拒绝该用户对服务器的访问。

元素

ClearCase 版本对象称为元素。每个元素有一个所有者(一个 UID 或 SID)、一个组和一个保护模式。一个 VOB 可以包含与多个组有关的元素,可以通过此方法管理授权。

文件系统级授权管理的限制

只要对象数量不是太大,文件系统级别上的管理就很有效。随着部署规模增加,管理可能变得很难。考虑大量包含许多版本对象的 VOB 一起充当着产品开发存储库的部署情形。一位开发人员可能仅需访问这些对象的子集,所以被指定为提供了该访问权限的一些组的成员。另一方面,构建者需要访问所有对象,因此需要获得许多允许全面访问的组的成员资格。

但是,文件系统级别上的管理可能引起一些问题:

  • 大量的组可能难以管理,可能导致错误管理引起的授权违规。
  • 用户所属的组的数量可能超出了操作系统和 ONC-RPC 协议支持的限制。
  • Unix 风格的权限仅允许每个元素一个组。

访问控制列表 (ACL) 可以解决这些问题。

访问控制列表

借助 VOB ClearCase ACL,可以通过策略和角色映射来管理身份和保护模式。策略定义了授予指定角色的权限,角色映射将角色映射到主体(组和用户)。

策略中的每一项列出一个元类型对象,后跟一个主体列表和这些主体的权限:

[element]
Role:Manager read
Role:Developer change
Role:Integrator change

角色映射指定了承担策略中列出的角色的主体:

Role:Manager --> Group:DOMAIN/mgrs
Role:Developer --> User:DOMAIN/savitri
Role:Integrator --> Group:DOMAIN/integs

通过组合角色映射和它的策略,并用角色映射图中的一个映射来替代策略项中的一个角色,可以制定一条未指定任何间接主体的有效 ACL:

Group:DOMAIN/mgrs read
User:DOMAIN/savitri change
Group:DOMAIN/integs change

示例

下面的例子演示了这一场景:

  • 一个产品的核心和安全性组件位于 VOB A 中
  • 这些组件的每个组件都拥有相应的开发人员团队
  • GUI 组件位于 VOB B 中;用户 Savitri 负责 GUI 代码
  • 版本工程师 Jo 负责构建产品

为两个 VOB 建立单条策略;它在每个 VOB 中创建一次:

#Policy for VOBs A and B
[element]
Role:maintainer change
Role:consumer read
Role:builder read,write-dir
#write-dir allows view-private file creation (build output)

3 个角色映射对应于 3 个组件:

#Rolemap for core component
Role:maintainer --> Group:DOMAIN/core_dev
Role:consumer --> User:DOMAIN/savitri
Role:builder -->User:DOMAIN/jo

#Rolemap for security component
Role:maintainer --> Group:DOMAIN/security_dev
Role:builder -->User:DOMAIN/jo

#Rolemap for GUI component
Role:maintainer --> User:DOMAIN/savitri
Role:consumer --> Group:DOMAIN/core_dev
Role:builder -->User:DOMAIN/jo

策略和角色映射得到以下有效的 ACL:

#EACLs for core component
Group:DOMAIN/core_dev change
User:DOMAIN/savitri read
User:DOMAIN/jo read, write-dir

#EACLs for security component
Group:DOMAIN/security_dev change
User:DOMAIN/jo read, write-dir

#EACLs for gui component:
User:DOMAIN/savitri change
Group:DOMAIN/core_dev read
User:DOMAIN/jo read, write-dir

VOB 副本的身份和权限管理

一个 ClearCase VOB 副本不仅可以使用针对版本对象的更改来更新其他副本,还可以使用附加到这些对象的身份和权限信息来更新它们。可以通过配置副本来:

  • 保留身份和权限;这些副本称为完全保留 副本
  • 仅保留权限
  • 既不保留身份,也不保留权限

理想情况下,完全保留副本(它们共享 ACL)部署在信息安全性是重要考虑因素的环境中。在这些副本中,策略和角色映射可由单个受信任的主体(管理员)来管理,而不是在每个非保留副本上由其管理员独立管理。独立副本管理的不足之处是,它需要一些协调,协调失败可能导致授权违规。作为进一步的安全措施,完全保留副本的管理员可以设置 ACL 来拒绝其他副本对控制角色映射和策略的请求。

加密

分布式开发上下文中的加密有 3 个方面:

  • 在一个域内移动的数据
  • 在 WAN 上移动的数据
  • 静止数据

因为 CCLC 是为部署在受信任的域中而设计的,所以没有对在域中移动的数据采用加密。但是假设会拒绝 CCLC 用户尝试攻击该用户访问的数据的不太可能发生的场景。攻击者需要将 NFS/SMB 路径名称的对象 ID (OID) 表示映射到人类可读的路径名称。这是可能做到的,但是大量的 RPC 需要解决大海捞针的问题:哪些数据对攻击者有价值?

由于存在不受信任的主体,在 WAN 上移动的数据带来了巨大的风险。ClearCase 采用对这些通信采用安全套接字 (SSL/TLS) 加密协议。

存储的未加密数据带来了应在适当时应对的风险。ClearCase 视图和 VOB 存储可采用全磁盘或全分区加密模式来加密,比如 BitLocker、PGP Desktop 和 LUKS。域中的存储设备应保存在安全的设施中。

事件日志

事件日志解决了两个安全方面问题:

  • 事件日志的审核帮助确定违规者的身份
  • 对事件日志的了解可以有效地遏制攻击

ClearCase 会记录约 80 种事件,这些事件会影响约 20 种对象,包括哪些对象的类型是实例。ClearCase 历史功能的输出可以是一个扫描异常活动模式的脚本的输入。ClearCase 管理员还可以查阅 ClearCase access_log,其中专门记录了失败的访问尝试。

对比 SCM 系统时,评估未维护其历史且未记录事件类型的对象。根据您的安全需求,这些遗漏可能带来风险。

管理威胁

防火墙、反病毒软件、设备的安全存放和员工访问胸卡都被认为是任何存在信息风险的组织的最低限度的外层保护。尽管本文中描述的所有保护性机制都可以通过组织的安全策略来指定,但对于某些具有无法估量的价值的资产(比如由情报机构持有的资产),它们显然还是不够。信息安全分析师可推荐针对您的信息资产风险的合适保护。

致谢

非常感谢 IBM 同事 Peter Hack(ClearCase 架构师)和 John Kohl(安全架构师)对本文的认真评审(包括所有 8 篇草稿!)。还要感谢 developerWorks 的 Robin Wood 的建议和帮助发表本文。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, Security
ArticleID=1026068
ArticleTitle=部署安全的软件配置管理
publish-date=01252016