理解受信系统中配置管理的指南(NCSC-TG-006) - 计算机安全知识 - China...

来源:百度文库 编辑:神马文学网 时间:2024/03/29 01:42:10
理解受信系统中配置管理的指南
翻译:陈海燕,CISSP(phrackchen@hotmail.com)
美国国家标准和技术学会推荐
英文版PDF中文版PDF
注:以下内容因排版原因有所省略,完全信息请查阅中文版PDF。
1. 目的
《受信计算机系统评测标准(TCSEC)》是用于评估ADP系统内建安全控制效率的标准。TCSEC被分为D,C,B和A四部分,A是这个等级序列的最高等级,被保留用于提供最高保证水平的系统。从C到A,又被分为一些被称为级的子部分,这些部分也按照等级序列的方式表现不同级中不同的安全水平。
从TCSEC的B2级到A1级,TCSEC要求所有对受信计算基(TCB)的更改必须由配置管理进行控制。受信系统的配置管理包括在开发、维护和设计过程中,对TCB所有更改的识别、控制、记录和审计。本指南的主要目的是为受信系统的开发者提供配置管理概念,及其在受信系统开发和生命周期中所需的指导。本指南也为其它系统开发者提供配置管理重要性及其实施方式的指导。
本文中的例子不应被解释为满足TCSEC需求的唯一方式。例子只是正确方式的一种建议。本文的建议也不应被解释为TCSEC的补充需求。TCSEC是系统评测的唯一尺度。本指南是旨在为TCSEC议题及其特性提供指导帮助的持续项目的一部分。
2. 范围
TCSEC的B2级到A1级的一个重要安全特性就是有配置管理规程来管理对受信计算基(TCB)的更改,以及所有受更改影响的文档和测试。另外,建议在那些不准备评测或评测目标级低于B2的系统中也应用这种计划和规程。配置管理所提供的保证对所有的系统都有益处。本指南将讨论配置管理及其在计算机系统和产品中应用的特性,特别是那些为了满足TCSEC需求而建立的特性,以及那些准备在评级维护项目(RAMP)(参考第11节,RAMP)下进行重新评测的系统。
除了受信系统和非受信系统在配置管理方面的区别以外, “系统”一词被用于配置管理的对象,包含系统和TCB。应注意到,虽然建议将配置管理应用到整个系统的维护中,但是TCSEC只要求将TCB置于配置管理控制之下。
3. 控制目标
TCSEC给出了以下保证控制目标:
“用于处理保密或其它敏感信息的系统必须被设计为能够保证安全策略的正确和准确解释,必须没有歪曲策略的含义。必须提供正确实施和运行存在于整个系统生命周期中的策略的保证。”[1]
配置管理维护整个生命周期的系统控制,确保运行的系统是正确的系统,执行了正确的安全策略。与配置管理相关的保证控制目标引导以下配置管理控制目标的实现:
“处理和存储敏感或保密信息的计算机系统依赖于硬件和软件来保护信息。因此,硬件和软件本身必须被保护以免遭可能破坏保护机制或使其被完全绕过的非受权更改。[因此,在整个生命周期中对受信计算机系统的更改必须被谨慎地考虑和控制以确保受维护保护机制的完整性。]只有这样,才能认为硬件和软件对安全策略的解释得到了正确的维护而没有被歪曲。”[1]
4. 结构
本文为读者提供了对配置管理概念的解释和在ADP系统中实施的方法。
对于受信系统的开发者,本文还将TCSEC的需求和满足需求的配置管理实务联系在一起。本文通过使用TCSEC需求的编号规则对文章结构进行组织以表现实务和需求间的联系。配置管理的需求在本文的第6节被分为19个分支需求。需求编号附在相应讨论后面的括号中,如(需求2、15)意味着前面的讨论与第6节提到的TCSEC需求2和15相对应。
5. 配置管理原则概述
配置管理包含四个分支任务:识别、控制、状态记录和审计。对于自动化数据处理(ADP)系统的任何更改,系统被更改版本的设计和需求都应该得到识别。配置管理的控制任务由受权当局通过对文档、硬件和软件/固件的每一项更改进行审查和批准来完成。配置状态记录负责记录和报告更改过程中的产品配置。最后,通过配置审计过程,对已完成更改的功能正确性进行验证,对于受信系统,还要对系统安全策略的一致性进行验证。配置管理是保证运行中的系统是所希望使用的系统的一项良好的工程实务。与受信系统配置管理相关的保证控制目标是为了“保证系统的受信部分如希望的那样进行工作。”[1]
应通过配置管理计划建立和记录规程以确保配置管理按照确定的方式进行。任何背离配置管理计划的情况都会造成整个系统配置管理以及受信系统中信任的失效。
5.1 配置管理的目的
由于现有ADP系统的更改是不可避免的,所以需要配置管理。配置管理的目的是确保这些更改在确定的和受控的环境中进行,并且不会对系统的特性造成负面影响,对于受信系统,还不应对TCB安全策略的实施造成负面影响。配置管理保证对TCB的增添、删除或改变不会破坏评测系统原有的信任。它通过提供确保TCB和所有文档得到适当更新的规程来完成这一目标。
6. 满足标准需求
本节列出了TCSEC对配置管理的需求。每一个级别的每一项需求被分别列出和编号。每一个编号所对应的需求在本文的后面得到了讨论。本节被设计为对TCSEC级别需求的快速参考。
6.1 B2级配置管理需求
需求 1 - “在TCB的开发和维护期间必须应用配置管理系统。”[1]
需求 2 - 配置管理系统必须维护“对描述性高级规格说明(DTLS)的更改控制。”[1]
需求 3 - 配置管理系统必须维护对“其它设计数据” [1]的更改控制。
需求 4 - 配置管理系统必须维护对“执行文档” [1]的更改控制(如用户手册、运作规程)。
需求 5 - 配置管理系统必须维护对“源代码” [1]的更改控制。
需求 6 - 配置管理系统必须维护对“目标代码的运行版本” [1]的更改控制。
需求 7 - 配置管理系统必须维护对“测试装置” [1]的更改控制。
需求 8 - 配置管理系统必须维护对测试“文档” [1]的更改控制。
需求 9 - “配置管理系统必须确保所有的文档和TCB当前运行版本的代码具有一致的映射关系。”[1]
需求 10 - 配置管理系统必须提供“用于从源代码生成新版TCB”[1]的工具。
需求 11 - 配置管理系统必须提供“新生成的TCB版本与原先版本进行比较的工具以便确定只有希望的更改被添加到将实际使用的新版TCB代码中。”[1]
6.2 B3级配置管理需求
TCSEC的B3级配置管理需求与TCSEC的B2级需求一样。虽然没有附加的需求添加进来,但是配置管理系统还是必须在设计文档中反映出B3级的变化。这意味着对于TCSEC的B3级,需要有附加的文档在配置管理中进行维护。
6.3 A1级配置管理需求
需求 2到需求 11与6.1节中描述的B2级评级的一样。另外在A1级中还添加了以下需求:
需求 12 - “在整个生命周期中,如在TCB的设计、开发和维护期间,必须对所有安全相关的硬件、固件和软件应用配置管理系统。”[1]
需求 13 - 配置管理系统必须维护对TCB硬件的更改控制。
需求 14 - 配置管理系统必须维护对TCB软件的更改控制。
需求 15 - 配置管理系统必须维护对TCB固件的更改控制。
需求 16 - 配置管理系统必须“维护对形式化模型的更改控制。”[1]
需求 17 - 配置管理系统必须维护对“形式化高级规格说明”[1]的更改控制。
需求 18 - 可用于配置管理的工具必须“在严格的配置控制下进行维护。”[1]
需求 19 - “必须使用技术的、物理的和规程的防范措施组合来保护用于生成TCB的所有材料的主要复件不会被非受权更改或毁坏。”[1]
7. 配置管理的功能
7.1 配置识别
配置管理规程应该能够让人“在任意时间点上识别系统的配置以便系统地控制配置的更改并在整个系统生命周期中维护配置的完整性和可跟踪性。”[4]配置识别的基本功能是识别系统设计和应用的组件。当涉及到受信系统时,尤其指TCB的设计和应用。这项任务可以通过使用识别符和基线完成(参见9.1节,基线的概念)。通过建立配置条目和基线,系统及其TCB的配置能够在整个系统生命周期中被准确地识别。对于TCSEC的B2级,TCSEC要求将TCB的“描述性高级规格说明、其它设计数据、执行文档、源代码、执行代码的当前版本、和测试装置及文档”[1]置于配置管理的控制之下(需求 2、3、4、5、6、7、8)。配置识别协助达成这种控制。TCSEC要求对TCB的每一项更改都必须被单独识别以便能够在任何时刻生成TCB的历史。对于TCSEC的A1级,需求被扩展到TCB的“形式化模型…和形式化高级规格说明”也要置于配置管理系统的维护之下(需求16、17)。
下面是必须在配置管理下被识别和维护的举例清单:
包括硬件、软件和固件的TCB基线 上一个基线以来TCB的硬件、软件和固件的任何变化 设计和用户文档 包括功能和系统集成测试的软件测试 用于生成当前配置条目的工具(只在TCSEC的A1级要求)
配置管理规程应该使正确再生任何以往的TCB配置成为可能。在非当前版本的TCB被发现存在安全缺陷的情况下,需要能够重建过去的环境以便进行分析。只有在系统的整个生命周期中对配置进行适当的识别才有可能进行重建。
TCSEC还要求B2级及其以上级别必须提供“从源代码生成TCB新版本”的工具,并且必须“有对新生成版本与以前TCB版本进行比较的工具以便确定只有希望的更改被添加到将实际使用的TCB新版中”[1](需求 10、11)。这些工具负责提供保证以确保没有系统设计人员不希望的附加更改被插入到TCB中。自动化工具的使用使在线识别系统的更改成为可能(参见附录 A:自动化工具)。任何对系统的更改或被建议的更改应该被输入到在线库中。这一数据以后会被用于比较系统的两个版本。这样的在线库甚至可以提供对软件模块和文档进行逐行比较的能力。对于A1级,用于执行此功能的工具必须被“置于严格的配置控制的维护之下”[1](需求 18)。这些工具在没有受权当局的严格检查的情况下不得被更改。
7.1.1 配置条目
配置条目是系统配置的独特识别子集,表现用于配置管理更改控制规程的系统最小部分。因为对配置条目的任何更改都会影响到系统的特性或TCB的安全策略,所以配置条目需要被独立控制。
对于TCB来说,控制条目是TCB的硬件、固件、软件、文档、测试以及A1级中开发工具的子集。例如,TCB软件的每一个模块可能形成一个单独的配置条目。配置条目应该被设定独立的识别符(如序列号、名字)以便在系统的整个生命周期中进行识别。正确的识别在满足B2级TCSEC需求中要求配置管理系统“确保所有文档和当前TCB版本代码之间的一致映射关系”[1](需求 9)扮演了重要的角色。与配置审计一起使用,一致的标识系统帮助将文档及其所描述的代码联系起来。标识每一项配置条目不仅使识别更加容易,而且通过增加这些条目的可追踪性提高了整个系统维护中的控制水平。
可以通过随机的分配过程将识别赋予给配置条目,但是如果配置识别符能够描述所识别的条目就会更有用。选择配置识别符的不同字段体现配置条目的不同特点是实现这一目的的一种方法。美国社会保险号码就是这样一种我们都有的“配置识别符”。号码的某些字段可以确定我们何处申请的社会保险卡,也就是对我们进行了一定的描述。因为配置识别符与计算机系统有关,所以其中的字段应该确定条目所属的系统版本、软件版本、或其与其它配置条目的接口。当使用这样的编号方案时,对于配置条目的更改应该产生新的配置识别符。这个新的识别符应该是对已有的配置识别符进行更改或添加而产生的。软件程序新版本的配置条目编号应该与原来的不同。通过对两个版本使用不同的配置条目,就有可能实现逐行的比较。
识别配置条目应该是一项在系统开发阶段的早期进行的工作,一旦内容被指定为配置条目,此条目的设计在没有条目控制方知道和许可的条件下就不应被更改。配置条目的早期识别提高了对条目维护的控制水平并能够在系统开发的所有阶段跟踪回顾条目。如果配置条目只是在开发过程后期被识别,系统开发早期阶段的条目的职能就无法实现。配置条目在复杂程度、规模和类型上有可能千差万别,所以选择配置条目的适当粒度是很重要的。如果条目过大,每项条目的识别数据就会过多以至于难以对系统进行审计。如果条目过小,识别数据的整体数量也会过多使系统审计人员难以处理。[2]配置条目的适当粒度应由每个供应商确定并记录在配置管理计划中。
7.2 配置控制
“配置控制涉及到对已经得到正式批准的配置中的配置条目的设计和结构的更改进行系统性的评测、协调、批准或否决。”[5]配置控制应该始于系统设计和开发的早期阶段并扩展到包括设计和开发阶段在内的配置条目的整个生命期。配置控制规程的早期启动通过增加开发的可跟踪性提高了系统的职能。配置控制的可跟踪性功能服务于两个目的。它使评估更改对系统的影响以及控制更改本身的进行成为可能。应用了配置控制,在系统中发生有害系统安全的非希望更改的机会就会减少。
配置控制的初始阶段主要是对设计文档中定义的系统配置进行控制。因此,配置管理计划必须设定规程以确保所有文档得到适当更新并正确体现系统描述和TCB配置。系统某个区域的更改通常会需要另一个区域的更改。所以只是撰写新代码或新更改代码部分是不够的,必须将受到添加或更改影响的TCB所有部分的文档进行相应更新。即使文档是可用的,但如果不将其置于配置管理的保护之下并进行适当的更新,它的用处将会很有限。当在文档中发现系统的缺陷时,应开展工作为系统不完善或缺少的部分创建新的文档。
为了满足TCSEC的需求,配置控制必须覆盖比文档更广阔的领域,对于B2级,还要维护对TCB的“设计数据、源代码、执行代码的运行版本和测试装置”[1](需求3、5、6、7)的控制。对这些内容的任何更改都应该经过受权当局的审查和批准。
对于TCB的配置条目,未经控制方的许可不得进行更改。对于TCSEC的A1级,此需求还增加了对“规程性防护”[1]的要求以防止对TCB所使用材料的未受权更改(需求 19)。这些规程不仅应该要求更改的执行得到控制方的许可,而且还要求由控制方执行将发布的主TCB复件的更改。这样就有效防止了主复件未经授权的更改。
在TCB中实施配置控制的水平将影响到其是否满足TCSEC对于配置管理的需求。TCSEC的配置管理需求要求在B2级中“TCB的开发和维护”(需求 1)过程中,以及在A1级中“整个生命周期”(需求 12)过程中应用配置管理。最低限度的配置控制系统对于满足TCSEC需求是不够的,它只能提供系统更改的事后检查。这样的系统可能确保更改的完全和可接受性并可能控制更改的发行,但是对于大多数情况来说,这样的控制只是事后质量保证检查。这样的系统肯定好于没有应用控制的系统,但是并不满足TCSEC对于配置管理的需求。这种系统要达到B2级的需求就应该控制更改的进行。TCSEC所需的配置控制应为更改提供从其开端、到实施和测试、到发布的持续核查和批准。TCB所应用的控制级别应该超越系统的其它部分,但是建议将系统的所有部分都置于配置控制之下。
对于将应用于多站点的硬件或软件/固件的更改,配置控制也应负责确保每个站点接收的系统版本是正确的。
TCB配置控制的要点在于对TCB的所有更改都必须得到批准、监督和评估以确保TCB功能的正确性和所有安全策略得以维持。
7.3 配置状态记录
配置状态记录负责以特定方式报告开发的进度。这项工作是通过数据记录、数据存储和数据报告过程来实现的。配置状态记录的主要目标是记录和报告对于配置管理过程重要的所有信息。重要信息的内容应该在配置管理计划中概括。建立新的基线(参加9.1节,基线的概念)或满足既定条件是应该被记录的配置状态记录信息的例子。配置管理计划中要求的应该被视为最低要求,任何看起来与配置管理有关的事件都应该被提取和记录,这些内容在将来可能会被证明是有用的。
配置记录系统可以是通过人工记录跟踪来发现更改状态,或使用数据库对更改进行自动化跟踪。以某种正确形式记录信息本身就可以到的一定的目的。在线状态记录系统的好处在于信息被以结构化的方式保存,这样可以帮助保持信息的更新状态。可以在数据库中查询有关配置更改状态或配置条目的信息,这样比通过记录本排序要省事得多。最后,磁盘或硬盘的保存稳定性要超过活页记录本或文件夹,它可以提供适当的备份以防止系统失败引起的数据丢失。
无论使用那种系统,都应该能够快速查找配置条目的所有受权版本,以及所有受权更改及其更改原因的注释,并且既能查出配置条目的当前状态也能查出所需条目的一些中间状态。所有已执行的受权更改状态都应该在提交给配置控制委员会会议(参加9.3节,配置控制委员会)的系统状态报告中阐明。
配置状态记录“建立能够提供适当后勤支持的记录和报告,如提供建立后备、执行手册、培训和维护设施所需的支持。”[5]通过配置状态记录产生的记录和报告应该包括当前配置清单、历史更改清单、初始设计、更改请求及其实施的状态并应该提供跟踪所有更改的能力。
7.4 配置审计
配置审计涉及到检查配置记录信息的整体完全性“以确定只有[受权]更改被添加到将实际使用的TCB新版本中。”[1](需求 11)当更改被添加到系统中时,应该对更改对系统其它部分产生的影响进行检查和审计。这应该包括检查和测试所有软件以确保更改被正确地执行。配置审计关系到对系统控制过程的检查并确保其以正确的方式进行。受信系统的配置审计对TCB已执行的更改进行较验并对安全特性和保证进行维护。配置审计应该被定期执行以验证配置状态记录的信息。配置审计使插入未经审批的更改而不被发现的可能性降低到最小,并且使状态记录信息充分体现配置管理保证的有效性。
“完全的审计应该包括在所有相关的功能中跟踪每一项需求以发现需求是否被满足。”[2]另外,配置审计还应该确保没有不必要的添加。审计提供了技术检查的有效模式,它应该是可以预测的并且尽可能简单易行,如应该有具体所需的结果。
配置审计应验证:
结构设计满足需求 详细设计满足结构设计 代码实施了详细设计 条目/产品执行了每一项需求 配置文档与条目/产品相符
配置审计的主要重点是为用户提供系统的使用版本就是用户想要使用版本的合理保证。配置审计确保配置管理系统的配置控制规程得到遵行。配置审计的保证特性是通过合理和一致的职能规程提供的。所有的代码审计都应该遵行基本相同的规程并对系统的所有更改执行同一系列的核查。
8. 配置管理计划
有效的配置管理应包括在项目启动后立即准备的整体计划。这项计划应该使用简单、确定的语言描述在系统和TCB中实施配置管理所应采取的行动。最小的配置管理计划可能只限于定义怎样实施配置管理相关的识别、控制、记录和审计工作。以下段落描述的配置管理计划是一个更加详细计划的例子,它包括配置管理相关所有方面的文档,如用于配置管理的文档例子、任何可用的自动化工具的规程、或配置控制委员会名册(参加9.3节,配置控制委员会)。配置管理计划应包括描述如何完成配置管理工作的“充分详细的文档,以便任何参与项目的人都能够参考文档确定每项与CM相关的具体工作应该如何开展。”[2]
配置管理计划应该有一个部分用来定义设计、开发、管理、配置控制委员会和所有与系统生命周期相关的人员所扮演的角色。系统任何部分所需的责任都应该在配置管理计划中建立和记录以确保人的因素在配置管理中发挥正确的作用。配置管理委员会成员的清单,或成员的职务也应该包括在这一部分。
任何可以用于配置管理的工具都应记录在配置管理计划中。对于TCSEC的A1级,要求将这些工具“置于严格的配置控制的维护之下”[1](需求 18)。这些工具可能包括用于更改控制的工具、标记配置条目的规则、软件库,以及支持配置管理过程的任何自动化工具。任何用于报告的文档范例也应被包含在配置管理计划中并附带相应的描述。配置管理计划应该有一个部分处理规程。因为配置管理的主要动力来源于所遵行的规程,所以需要在整个文档中明确在配置管理过程中应遵行何种规程。配置管理计划应该提供所应执行的规程以确保用户和设计文档与系统所有的更改一同得到更新。它应该包括创建和维护整个系统生命期的功能测试和文档的指导方针。配置管理计划应该描述如何对更改的设计和实施进行提交、评估、协调和批准或否决的规程。配置管理计划还应该包括确保只有那些得到批准的更改被实际添加并且这些更改添加到所有所需的领域所应采取的步骤。
配置管理计划还应该有一个部分用来定义现存的“应急”规程,如未经完整的审核过程,可能超越标准规程执行时间敏感更改的规程。这些规程应该定义在紧急更改执行完毕后追溯执行配置管理的步骤。
配置管理计划是一个动态的文档并且应该在设计和开发阶段具有灵活性。虽然配置管理计划是用来对项目进行强制控制的,但是它应该具有添加和更改的开放性以便适应设计者和开发者的需要。这不是说配置管理计划只是一种指南而无需遵行,只是说对它的更改也是可以的。如果不遵行计划,就无法提供适当的保证。在需要更改配置管理计划的情况下,应该对更改进行谨慎地评估和审批。对于受信系统配置管理计划的更改,这种评估必须确保计划所支持的安全特性和保证在更改实施后能够得以维持。
9. 实施方法
本节讨论了可能用于满足TCSEC需求的配置管理的实施方法。9.1节讨论做为配置识别方法的基线概念。基线概念使用前面提到过的配置管理特性,但是将系统生命周期分成不同的基线。
9.1节描述了虚拟的MER公司如何进行配置管理。他们试图满足TCSEC对B2级系统的需求。
9.3节讨论了完成配置控制的配置控制委员会(CCB)的概念。CCB是负责配置控制的一些人。这个概念被许多计算机供应商广泛使用。
9.1 基线的概念
基线建立在系统生命周期中预先选择的设计点上。某条基线可能被用于描述一个具体的系统版本,在一些配置管理系统中每种主要的条件可能定义一条单独的基线。基线根据配置控制委员会的判断建立并将其要点记录在配置管理计划中。当建立多条基线时,每条基线做为开发某阶段的一个切点,开发工作同时向另一个阶段的切点移动。所有基线的共同特性是系统的设计应该在其建立的点上得到批准而且可以相信任何对此设计的更改都将影响到未来的系统开发。
基线管理是一种进行配置识别的技术。它将系统和TCB的设计与开发确定为一系列与配置控制相关的阶段或基线。与配置条目一起使用就成为了整个生命周期中对系统及其TCB配置进行识别的另一种有效方法。
“对于每一种不同的基线,每一个单独的受控部件都应该被识别,任何对当前配置的更改都应该得到批准和记录。对于开发[生命周期]中的每一个中间产品都有一条唯一的基线。通过对基线添加所有得到批准的更改就可以获得当前配置。”[2]
在开发的不同阶段定义了多个基线的系统中,这些基线或里程碑应该在系统开始阶段建立并做为整个开发活动的指导。虽然建立了特定的基线,但是还可以建议其它可选的方式以改善设计的灵活性和效率。每个系统可以建立的基线数量依据系统规模和复杂程度以及设计者和开发者所支持的方法的不同而不同。只要对每条基线采取适当的配置管理措施,就有可能建立存在于同一时刻的多条基线。下面的例子将讨论的基线概念使用了三个通用基线类型:功能的、分配的和产品的。应该强调的是,这些都是在设计者和开发者的决策基础上建立的简单而基本的里程碑和基线。
第一种基线,功能的基线建立在系统设计的初始阶段。它由包含定义系统需求的规格说明的性能和目标标准的文档导出。一旦这些规格说明被建立起来,任何对其的更改都应该得到批准。
在功能的基线中产生的需求可能被分为和细分为各种配置条目。一旦决定了配置条目的内容,每一项条目都应赋予一个配置识别符。根据对系统需求的分析应该建立分配的基线。这种基线使用负责相应功能的具体配置条目确定所有所需的功能。在这种基线中,每一项配置条目的责任会分配给一个人。所有影响分配的基线中定义的系统设计需求规格说明的更改都需要负责人的批准。
最后一种基线,产品的基线应该包含将要用作集成测试的系统版本。这种基线标志了开发阶段的结束并且应该包含系统可发行的版本。
在前面提到的基线的例子中为每一个系统版本建立一条基线因同样的原因适用于功能的、分配的和产品的基线的例子。在单一基线的例子中做为基线建立起来的系统其设计在使用前将需要配置控制的批准。在设计得到批准以前,系统设计将必须经过一些形式的功能核查以及将这些功能分配给各种配置条目的过程。虽然在单一基线例子中设计的早期过程不像其早期任务得到单独定义时那样正式,但是系统仍然得益于做为基线得到配置管理的控制。建立任何基线的要点在于通过要求任何对其的更改都必须执行已建立的更改控制过程的方式控制基线的更改。
9.2 MER公司的配置管理
MER公司是一家计算机系统生产商。他们的最新项目包括建造满足TCSEC的B2级需求的系统。在过去,他们的配置管理只包含质量保证检查,但是为了满足B2级需求他们意识到他们将需要在系统的开发和维护过程中应用特定的配置管理规程。
项目经理被指定完成撰写配置管理规程并将其纳入配置管理计划中的工作。在进行了一些有关配置管理计划中应包含内容的研究后,他开始为MER公司撰写计划。配置管理计划中列出了完成系统配置管理所需遵行的步骤。描述了开发团队所应遵行的规程并描述了MER公司将要使用的配置管理自动化工具。这些工具包括用于状态记录的在线跟踪数据库,在线数据库中包括配置控制的所有条目列表以及用于存放软件的自动化库。在开发开始之前,所有的开发团队有责任阅读配置管理计划以确保他们了解配置管理所应遵行的规程。
系统开发时,使用配置管理计划中解释的配置条目编号方案标记TCB的硬件、软件和固件。另外,这些条目的文档和测试也被赋予配置条目编号以确保TCB代码和这些条目具有一致的映射关系。所有的配置条目编号和条目描述被存储在数据库中以便在任何时间进行查询导出整个系统的配置。软件和文档被存储在软件库中这样它们就可以被取出或使用而不影响到主版本。所有软件的主复件被存储在包含软件发行版本的主库中。这些库被任意访问控制机制保护以防止未受权人员对软件的更改。
在系统开发过程中有更改的需要。配置管理计划应描述在配置控制下的更改执行规程。这些规程在整个系统生命周期中都起作用。对于每一项所提出的更改,应该由管理层作出是否可行和需要的决定。MER公司有在线论坛来检查所建议的更改。这个论坛使开发团队的所有成员都可以就所提出更改对其工作的影响提出意见。管理层将经常咨询该论坛以帮助其作出最终决定。决定作出后,会指定一名程序员完成更改。程序员会从软件库中提取最近版本的软件并对其进行更改。当进行更改时,更改被输入到在线追踪数据库中。这使开发团队的成员能够查询数据库以便在任何时间了解更改的当前状态。更改执行后对其进行测试和记录,并在成功完成后转发给检查人。检查人是软件的经理,他是唯一有权批准发行更改版本的人。更改的发行被批准后,更改版本被存储在主库中并且其第二复件被存储在软件库中。被存储在这些库中的每一项更改都被赋予一个新的配置识别编号。MER公司有一种工具可以识别对软件作出的更改。它比较任何两个软件版本并提供两者之间差别的逐行列表。
我们知道,在开发过程开始的时候有时需要执行重要的更改而无法遵行这样的检查过程。对于这些更改,配置管理计划中列出了紧急规程并且有关键修改库可以被用以记录发行以来所发生的关键更改。
在配置管理计划中还提供了TCB硬件的更改控制过程。规程确保TCB硬件更改的可跟踪性并且不违反由TCB软件作出的安全假设。与软件的更改类似,所有的硬件更改在实施前都要经过项目经理的检查。
在完成对TCB软件的更改后,MER公司执行配置审计来验证跟踪数据库中存放的信息。无论更改是否被执行,MER公司的配置管理计划设定一个月至少执行一次配置审计。这种审计将当前主版本与状态记录信息进行比较以验证没有未经批准的更改被插入。
这项配置管理计划涉及到描述性高级规格说明(DTLS)、执行文档、源代码、目标代码、测试装置和测试文档,并且被证明满足TCSEC对B2级的配置管理需求。
9.3 配置控制委员会(CCB)
配置控制可以通过多种方式进行。配置控制的一种方法就是上面提到的经过TCSEC的B2级评测的系统使用的方式,即由一群符合条件的人组成的配置控制委员会(CCB),也被称为配置更改委员会来完成。委员会由一名主席领导,他负责会议进度并最终批准任何所提出的更改。CCB成员的规模和组成在不同机构是不同的,但应该包括任何或全部以下系统领域的团队:
项目管理 系统工程 质量保证 技术支持 集成和测试 系统安装 技术文档 硬件和软件/固件采购 程序开发 安全工程 用户组
CCB的成员应该定期交流,可以通过正式会议、电子论坛或其它任何可用的方式来讨论诸如所提出的更改、配置状态记录报告等配置管理话题,还可以包括系统开发中不同领域的其它话题。这些交流应该定期举行以便整个系统团队了解系统的所有进展和变化的最新情况。委员会服务于对系统更改的控制并且确保只有得到批准的更改被应用于系统。CCB通过考虑有关更改和添加的提议并作出相应决策来完成此项功能。
与系统开发相关的各种小组的CCB成员进行交叉表述的重要性在于防止“对系统进行不必要的和矛盾的更改,并且允许与新需求、更改的功能性分配和失败的测试有关的有益更改。”[2]委员会的所有成员都应该有对所提出的更改发表自己意见的机会。例如,如果系统工程方面提出了影响到安全的更改,双方都应该可以向CCB会议提交他们的意见。如果在CCB中不存在多样性,更改就可能会被执行,应用时可能会发现它与系统的其它部分不兼容。
配置控制过程开始于更改请求的记录。更改请求应该包括所提出更改的理由、受到影响的所有条目和文档以及所提出的解决方案。更改请求应该被记录,可以是手工的也可以是在线的以便跟踪所有所提出的系统更改并确保没有重复的更改请求被处理。更改请求被记录后,它应该被分发以便CCB进行分析来检查和批准或否决更改请求。更改的总体影响分析将决定是否执行更改。CCB将根据更改的检查结果,即更改是否需要和可行并符合系统进一步的设计目标来确定批准还是否决更改。在涉及到受信系统时,CCB还必须确保更改不会影响到系统的安全策略。
一旦作出了任何更改的决定,CCB有责任排定得到批准的更改的优先顺序以确保最重要的内容得到最先开发。当排定更改的优先顺序时,应该努力使更改以符合逻辑的顺序进行。CCB还负责设定执行修改的职权并确保配置文档得到适当更新。被指定进行修改的人应该具有修改系统的适当授权,并且在处理敏感信息的受信系统中,这种授权是必须要求的。在任何增强或新的开发过程中,CCB通过确定所有开发所需的测试级别来持续对整个系统施加控制。
更改完成时,CCB负责验证更改是否被正确加入以及只有得到批准的更改被加入。测试应该在得到更改的系统或TCB上进行以确保更改完成后功能能够正确地执行。CCB应该检查任何开发的测试结果并且应该对于发行有最终决定权。
使用CCB是执行配置控制的一种方式,但是不是所有的供应商都希望或有资源建立这种方式。无论采取什么方式,都应该有执行前面描述的控制过程的措施。
10. 其它话题
10.1 受信分配
与受信系统的配置管理有关的是TCSEC在A1级需求中提到的:
“受信ADP系统的控制和分配设施必须被用来维护描述TCB当前版本的主数据与当前版本的在线主代码复件之间的映射关系。必须有确保被分配给客户的TCB软件、固件和硬件的更新与主复件一致的规程。”[1]
有两个受信分配过程的问题需要回答:(a)收到的产品是否是预期的机构发来的?以及(b)接收方收到的是否是发送方希望发送的?
配置管理通过确保从更改被批准到发行这段时间内没有发生更改来协助受信分配。A1级附加的配置管理需求支持这项功能的是“技术的、物理的和规程的防范措施组合必须被用于保护生成TCB的所有材料的主复件或其它复件免遭非受权修改或毁坏”[1](需求 19)。这项需求要求对TCB任何版本的更改进行严格控制。应该考虑更改未如设定的那样执行或将有害的更改插入TCB的可能性,并应对执行主复件更改的职权进行严格限制。一项主复件的职权应该只确保对主复件实施得到批准的和可接受的更改。
配置状态记录和审计报告可以为所有使用中的TCB版本提供职能。当分配不是由供应商生产的、被篡改的复件或分配“伪造”的复件时,配置管理记录将能够对所有TCB版本的有效性和正确性进行评估。受信分配显示了对TCB所有更改进行配置控制的需求。没有配置控制就不存在TCB版本向客户分配的职能。
10.2 功能测试
“系统开发者必须向评测者提供描述测试计划和测试规程的文档以显示安全机制是如何被测试的,以及安全机制功能测试的结果。”[1]这些功能测试的创建和维护应该是配置管理规程的一部分。测试结果以及任何相关测试文档必须被置于配置管理的维护之下并且在需要时得到更新。(需求 7、8)。测试应该是可重复的,包括充分的文档以便任何有能力的程序员都可以根据文档开展测试。系统的测试计划应该在TCB的功能规格说明(或其它设计文档)中与测试项目一起得到描述。虽然代码标准不需要像受测试的项目标准一样严格,但是测试计划和项目应该与所测试的项目一起得到检查和审计。
不能只对被打开或更换的代码进行测试,而是要对所有受更改影响的TCB部分进行测试。NCSC的评测者会提供满足TCSEC测试需求所需的安全功能测试的描述,包括如上所述的有关配置管理的测试。
10.3 配置管理培训
每一名新的技术员工在上岗之前都应该接受配置管理规程的培训。有经验的程序员虽然可能熟悉一些配置管理的内容,但也需要进行新规程方面的培训,如以后会使用的自动化记录系统。培训既可以“通过举办正式课程的形式也可以通过安排充足时间阅读公司配置标准的方式进行。”[2]新程序员应该在被允许参与任何对设计基线的更改前熟悉配置管理计划。应该强调的是,由于未经培训的员工导致的对配置管理标准的违反可能会妨碍系统得到评级。[2]
10.4 配置管理监督
成功的配置管理系统需要遵行许多规程。系统管理人员可能会犯错误或寻找捷径而破坏了整个配置管理计划,所以需要考虑对他们的要求。应该有检查过程以确保未经某种形式的批准过程,一个人是无法创建并实施对系统的更改的。应该要求对执行更改的人负有责任的管理人员签署更改正确性的正式记录。[2]
适当的监管也为执行更改的人具有适当的工作职权提供了保证。更改不应该由不具备执行更改素质的人执行。在处理敏感信息的系统中,执行更改的程序员还必须具有执行更改的适当安全许可证。
管理本身必须直接支持配置管理计划以便其能够发挥作用。必须在任何情况下防止对配置管理的削弱,如因为进度或预算的原因。管理层应该满足配置管理对的金钱、人员和时间方面的适当需求。
11. 评级维护项目
评级维护项目(RAMP)由NCSC制定,旨在保持测评产品清单(EPL)的更新状态。通过培训使供应商人员了解何种更改会负面影响到系统安全策略的应用,并通过使用配置管理对测评产品的更改进行跟踪,RAMP允许供应商维持其评测产品的评级而无需对新版本进行重新评测。因为操作系统由一个版本更改到下一个版本会影响到该操作系统的安全特性和保证,所以配置管理是RAMP中不可分割的一部分。对于在该项目下维护评级的系统,NCSC必须确定通过供应商的配置管理规程,所进行的更改不会负面影响到系统的安全机制和保证。
每一个RAMP的参与方必须制定NCSC批准的评级维护计划(RMPlan),计划应包括支持评级维护过程的详细的配置管理计划(CMP)。这一要求适用于所有参与到RAMP中的系统,而无论其级别高低。需要RAMP项目的更多信息和有关RAMP对配置管理方面的需求信息请联系:
National Computer Security Center
9800 Savage Road
Fort George G. Meade, MD 20755?6000
Attention: Chief, Requirements and Resources Division
12. 配置管理总结
由配置管理提供的保证对于所有系统都有益处。配置管理系统“应用于对描述性高级规格说明、其它设计数据、执行文档、源代码、目标代码的当前版本、以及测试装置和文档更改控制的维护”[1](需求 1、2、3、4、5、6、7、8)是B2和更高级别受信系统的需求。虽然配置管理是B2和更高级别受信系统的需求,但是所有的非评级系统或已经得到评级的系统都应该应用它。
成功配置管理的建立是为了达成四个主要目标:控制、识别、记录和审计。通过这些目标的达成,配置管理可以对TCB的控制进行维护并保护其免遭“会导致保护机制失效或被完全绕过的非受权更改。”[1]即使对于那些与安全无关的系统问题,配置管理仍然是确保更改后的系统特性得以维护的好方法。要取得配置管理的成功,在系统生命周期中始终坚持正式的配置管理计划是非常重要的。
成功的配置管理计划应开始于对配置管理目标、范围和规程的早期和完整的定义。成功的配置管理依赖于正确性。更改应该被正确地识别和记录,更改完成后,更改及其影响到的所有系统部分都应该被记录和测试。
配置管理为系统所有的更改提供控制和可跟踪性。进行中的更改可以通过配置状态记录信息进行监视,以便对更改进行控制并评估其对系统其它部分的影响。
成功的配置管理计划的一个重要内容是相关人员必须坚持其规程以便使所有的文档和更改记录保持更新状态。
应用了严格和拥有良好文档的配置管理计划,发生任何不必要或重复更改的机会就会大大减少,任何需要的更改就可以很方便地被识别。有效的配置管理系统应该能够显示应该创建的内容、已经创建的内容和正在创建的内容。
附录 A: 自动化工具
自动化工具可以被用于以前不得不手工作业的一些配置管理功能。数据库管理系统,即使只是有限的查询系统也可以被用于配置管理的配置审计和状态记录功能。自动化系统的使用原则是涉及到系统开发的源代码和其它文档的文本都可以被输入到主库中并通过使用自动化系统进行更改。这防止了任何人未经适当授权访问配置管理数据库执行更改。“通常,只有一个程序库管理员,他可以是项目经理或向经理直接负责的人,他应该在开发中具有向主库的写权限。”[2]一些软件开发者创建了可以用于配置状态记录的软件控制设施。其中两个系统的简介如下。
A.1 UNIX SCCS
“在UNIX 系统中,make功能以及admin、get、prs和delta组成的源代码控制系统提供了基本的配置记录系统。最初由mkdir功能创建一个目录。这时,可以使用UNIX 提供的owner、group命令和全局保护方案保护目录。另外还产生了一个登录识别符列表设定谁可以更改由SCCS处理的内容。”[2]
目录创建后,使用admin –n功能输入每个文档。在对新内容进行更新时,该内容被称为delta的新版本被创建出来。每项内容的名字标记有“s.”的前缀并被SCCS存储在一个文件中。如果添加到目录中的文件没有包含这个前缀就会被SCCS功能忽略。当调用admin功能时会设定一些变量来“定义影响文件的参数,并可能被admin后续的调用更改。变量alogin被用于通过列举能够对内容使用delta功能的用户登录名来创建与访问控制列表类似的清单,这样就创建了新的版本(delta)或变体分支。“[2]
每一项代码模块初始的发行版本或初始的delta版本都被通过admin –n功能输入到SCCS目录中,这样就创建了主库。程序员可以通过使用get –e功能更改主库中的每个模块,“该功能指示模块将被编辑并使用delta功能将完成的文档重新输入到目录中。当使用get –e将正在被编辑的模块从SCCS目录中导出时,可以使用delta将其返回到库中,所有需要更改的信息将随之被输入。功能get可以被用于导出任何文档的复件,但是当它被编辑后就不能被重新输入到库中。”[2]
“SCCS提供了通过为每项delta功能输出设定SCCS识别码(SID)的方式进行软件版本创建的能力。“[2]人们可以通过设定适当的SID获得文本或源代码的任何版本。“有明确的规则在get被调用时指定所需的SID。如果没有指定SID,则提供最近的发行版本或级别。” 调用get –e时使用的SID会影响到delta调用结果的SID。[2]“由于prs功能从SCCS目录中的s.文件中导出信息并且打印给用户,所以它可以进行配置记录。Prs可以被用于快速创建报告,列出一两个重要的数值清单,如许多SCCS文件的最后更改日期,或从一两个文件中列出许多值。还可以使用编辑器创建更大的报告。”[2]
A.2 VAX DEC/CMS
“VAX DEC/CMS[7]也被用于跟踪存储在CMS目录中的每一个文本文件,但是CMS比admin拥有更强的审计和交叉检查的功能。例如,如果在CMS目录中直接使用编辑器更改文件,CMS在以后使用该文件时会产生警告信息。任何非CMS功能输入到CMS目录中的文件都会在其在目录中被调用时导致CMS产生警告信息。其配置记录的其它过程与SCCS类似。
CMS CREATE LIBRARY功能可以建立目录并开始初始日志。项目经理使用CMS CREATE ELEMENT功能向目录输入内容。必须RESERVER库中的内容以便更改,并且它只能由REPLACE功能放回到库中。如果某人在早先程序员的RESERVE和REPLACE调用之间RESERVE该内容,会有警告发给双方程序员并将发生的事件记录下来。要获得文本的样本复件,如程序代码,FETCH功能将产生内容的最新版本或任何特定版本,但不允许被编辑的复件被重新输入到库中。SHOW功能可以被用于审计库中的每项内容的信息。
SCCS和DEC/CMS之间的不同体现在软件的版本建立方面。在UNIX中,版本建立只能被描述在makefile文件中,或版本建立使用的每项内容都必须使用get从SCCS目录中导出并放置到另一个目录中,然后makefile文件参照这些源文件创建可执行的程序。CMS的方法是使用类和组机制自动选择源文件的一个子集,包括一些不是最新的内容。为了解释它是如何工作的,人们必须理解CMS版本和变异的概念。文件的每一个版本对应UNIX中的一个delta。版本通常被按照升序编号。CMS还具有在REPLACE功能中设定变异名创建任何版本的变异开发行的能力。例如,有一项内容的RESERVE版本3,然后执行了一个REPLACE/VARIANT = T,这将创建版本3T1,这个版本以后可以与版本3分别开发。这种功能第一次执行时,等同于SCCS创建分支delta版本。而SCCS不具分支本身还可以有分支的能力。
使用CMS CREATE GROUP和CMS INSERT ELEMENT功能可以在CMS目录中定义一个组。组由所有的版本构成,包括变异版本和所有插入组的内容。组可以包含在其它组内。多个组之间可以定义为非空交集以便他们具有交叉的成员关系。
CMS CREATE CLASS功能和CMS INSERT GENERATION功能一起可以被用于设定软件版本建立的明确内容。这样,DECRIPTION文件就可以通过在源代码或相关规则的执行行中使用/GENERATION = classname限定语句引用整个类。当需要描述软件版本的中间测试时,UNIX需要的makefile会更加复杂。”[2]
术语表
自动化数据处理(ADP)系统 - 计算机硬件、固件和软件的组合,被配置用于在尽量少的人为干预下进行数据的分类、排序、计算、处理、汇总、发送和接收、存储和取回。[1]
基线 - 用于比较或控制目的的一系列关键的观察结果或数据。基线体现了配置条目设计和开发中的一个切点,在这一点后,配置在没有严格配置控制策略和规程的情况下不得变化。
配置记录 - 配置条目的描述以及开发和生产期间任何偏离基线情况的记录和报告。[2]
配置审计 - 出于评估所建立的需求、标准和基线执行情况的目的而进行的独立检查。[2]
配置控制 - 控制对系统设计、硬件、固件、软件和文档进行更改的过程,它为保护系统在系统实施前、实施中和实施后免遭不适当更改的干扰提供了充分的保证。
配置控制委员会(CCB) - 所建立的对ADP系统的所有更改提议具有最终职权的委员会。
配置识别 - 在设计、开发、测试和生产工作中对系统配置的识别。
配置条目 - 被配置管理系统跟踪的硬件、软件、固件、文档或其任意部分的最小单元。
配置管理 - 在系统开发和运作的生命周期中对系统的硬件、软件、固件、文档、测试、测试装置和测试文档更改的控制。
描述性高级规格说明(DTLS) - 使用自然语言(如英语)撰写的高级规格说明,非正式的程序设计标注,或二者的组合。[1]
固件 - 需要有计算机程序指令运行以便执行其任意功能的设备,其中程序使用电子方式存储在设备中但是无法在正常的设备运行中使用电子方式擦除。[3]
形式化安全策略模型 - 使用形式化的算术语言对系统支持的安全策略的精确和准确的描述。
形式化高级规格说明 - 使用形式化算术语言撰写的高级规格说明,能够从理论上显示系统规格说明与其形式化需求之间的对应关系的设定和证明。[1]
粒度 - 能够调节机制的相对精细度或粗糙度。词组“单个用户的粒度”意味着能够调节访问控制机制使其包括或排除任何一个用户。[1]
硬件 - 用于处理数据的电气的、电子的和机械的设备。
非形式化安全策略模型 - 使用自然语言(如英语)对系统支持的安全策略的精确和准确的描述。
软件 - 通常由厂商供应的协助采购者有效运行设备的各种程序。这些软件内容包括各种汇编器、生成器、子程序库、编译器、操作系统和行业应用程序。[6]
工具 - 取得某种最终结果的手段。与本指南有关的工具是文档、规程和组织化体系,如CCB,它们为达成配置管理的控制目标作出了贡献。
受信计算基(TCB) - 计算机系统内保护机制的总称 ―― 包括硬件、固件和软件 ―― 组合在一起负责安全策略的强制执行。TCB包括一个或多个组件,它们一起强制执行产品或系统的统一安全策略。TCB正确执行安全策略的能力只依赖于TCB的内部机制和系统管理人员输入正确的安全策略参数(如用户许可证)。[1]
参考资料
1. National Computer Security Center, DOD Trusted Computer System Evaluation Criteria, DOD, DOD 5200.28-STD, 1985.
2. Brown, R. Leonard, "Configuration Management for Development of a Secure Computer System", ATR-88(3777-12)-1, The Aerospace Corporation, 1987.
3. Subcommittee on Automated Information System Security, Working Group #3, "Dictionary of Computer Security Terminology", 23 November 1986.
4. Bersoff, Edward H., Henderson, Vilas D., Siegal, Stanley G., Software Configuration Management, Prentice Hall, Inc., 1980.
5. Samaras, Thomas T., Czerwinski, Frank L., Fundamentals of Configuration Management, Wiley-Interscience, 1971.
6. Sipple, Charles J., Computer Dictionary, Fourth Edition, Howard W. Sams & Co., 1985.
7. Digital Equipment Corporation, VAX DEC/CMS Reference Manual, AA-L372B-TE, Digital Equipment Corporation, 1984.