1.3.2 安全关键系统

安全关键系统是指具有如下特性的系统：如果系统的操作丢失或异常（例如：由于不正确的或粗心的操作），将造成灾难性和严重的后果。安全关键系统的提供商有义务对此类损失负责和进行赔偿，而测试工作就要减少这方面的损失。测试活动应该提供证据表明：系统经过了充分的测试，可以避免造成灾难性和严重的损失。

安全关键系统和人们的日常生活息息相关，尤其是随着信息技术的不断发展和推广，人们生活中涉及的安全关键系统越来越多，例如：医疗系统失效就很有可能造成人员的死亡；银行系统的数据存储系统包括了很多人的财务信息，它的损坏或丢失可能会对千家万户带来严重的损害。典型的安全关键系统包括飞机飞行控制系统、自动交易系统、核电站核心控制系统、医疗系统和数据存储系统等。

☆示例：企业级存储设备

企业级存储设备在金融、保险、电信和医疗等行业被广泛应用，这些设备用来存放企业的数据，可能是用户信息，也可能是企业内部运营的数据，它们是企业开展日常业务所必需的基础架构之一。而数据的安全性直接关系到这些企业的生存。所以，存储设备在提供基本的存储功能的基础上，还会提供像数据备份、远程镜像和灾难恢复等一系列高级功能。本地数据复制功能可以在不阻碍相关应用程序服务器负载的情况下，快速、高效地生成异步时间点数据复制，从而满足了获得持续数据可用性的关键要求。当需要数据副本时，源数据及其副本均可立即使用，因此，企业只需最短时间延迟的代价即可继续运行。这些数据副本可用于备份、质量保证测试或其他目的。远程镜像功能可在不同的城市或地区创建远程应用程序数据镜像，例如：可在两个相隔300公里的地方进行同步复制，也可在不同的距离间进行异步复制。城域镜像可以在相距达300公里的两个存储之间提供实时逻辑卷镜像。经特殊申请还可支持更远距离。这是一种同步复制解决方案，写入操作在两个站点（本地站点和远程站点）都完成后，才能被视为完成，保持数据的一致性，从而实现信息的可用性。同时，存储设备还提供对磁盘驱动器完全加密的功能，以提高设备的安全性。

除了设备所自带的功能外，还会配置一些应急手册来提高整个系统应用过程中的安全性，例如：某高端存储设备解决方案中提供灾难恢复程序手册，手册内容包括应对紧急情况需要遵循的步骤。如果发生火灾，负责人员应该知道如何做出反应，并评估系统受到的影响。

在安全关键系统的部署中应该注意下列特性：

● 变更的可追溯性：系统需求或设计发生变更以后，要对发生的变更进行跟踪，保证后续的活动都和变更后的要求保持一致，例如：当某个需求发生变更以后，要保证后续的开发和测试活动都依据变更后的需求开展，如果需求变更之前对应的测试用例已经开发完毕，则还要对相应的测试用例进行更新，或者开发新的测试用例来覆盖变更后的需求。

● 严格的开发和测试方法：开发和测试活动应该采用更严格的方法，保证每个活动的交付物的质量，例如：对于每个活动的交付物都要求进行正式的评审，而避免仅仅进行非正式评审，甚至不评审；在组件测试中，要求代码覆盖率达到100％。

● 安全分析：对安全关键系统进行安全分析，常见的方法有故障树分析、失效模式和影响分析（Failure Mode and Effects Analysis，简写为FMEA）、常见问题检查表等，例如：对于某安全关键系统中涉及的加密算法进行分析，12以保证系统的安全性。

● 架构的冗余：在设计系统架构的时候，要考虑冗余。重复配置系统中一些关键组件或子系统，当系统发生故障时，冗余配置的组件介入并承担故障组件的工作，由此减少系统的故障时间，避免系统无法提供正常的功能，例如：上面提到的企业级存储设备，通常都有两个或多个控制器，只要有一个控制器还能工作，设备就可以继续提供服务。

● 关注质量：项目的开发总是在进度、成本、内容和质量之间进行动态平衡。对于普通的系统，经常出现降低质量来保证开发进度的情况，这种现象在对及时交付（Time-To-Market）很关注的项目中尤其常见。但是对于安全关键系统，当这几个要素之间发生冲突的时候，要尽量保证质量，而通过增加投入或者延长开发时间来进行平衡。因为安全关键系统的质量问题将会带来无法估量的后果，这种后果不仅会对用户造成伤害，也直接影响到企业的生存和发展。

● 高质量的文档（文档的深度和广度）：安全关键系统的开发过程必须配以高质量的文档，不仅需求和设计方案需要详细的记录，测试策略、测试方法以及整个开发过程中的变更都要进行文档化。高质量的文档能够避免不必要的误解，有利于团队内部以及团队和外部组织之间的沟通。同时，高质量的文档也有助于提高评审的质量。

● 更严格的审计：整个系统的开发过程和最终产品都需要接受更严格的审计。对于安全关键系统，通常都要接受第三方的审计，例如：有些安全关键系统需要得到国家权威的软件评测中心的审计才能获得在市场上销售的资格；电信运行设备必须通过工业和信息化部的测试获得入网资格，才能够投入销售。

安全关键系统管理相关的内容参见3.11.3节。

1.遵循规章

安全关键系统经常受到政府的、国际的、组织的规章和标准的影响（更多关于需要遵循的标准的描述，参见6.2节）。这些规章影响到开发过程、组织架构或正在开发的产品。而对于安全关键系统，遵循特定的规章通常是进入市场的一个准入门槛，只有被证实符合了相关的规章和标准才有可能在市场上进行销售。企业组织为了保证对标准或规章的符合，必须对组织架构或过程进行一定的优化和改进。在条件允许的情况下，有些组织还会聘请专业的顾问团队对组织内部结构和过程进行评估和改进。

☆示例：美国食品和药物管理局对软件开发活动的要求

美国食品和药物管理局（Food and Drug Administration，缩写为FDA）是美国政府在健康与人类服务部（DHHS）和公共卫生部（PHS）中设立的执行机构之一。在国际上，FDA被公认为是世界上最大的食品与药物管理机构之一。其他许多国家都通过寻求和接受 FDA 的帮助来促进并监控其本国产品的安全。FDA制定了一系列的规范，要想获得FDA认证，相关组织必须符合相应的规范。FDA对软件开发活动也有具体的要求，下面列了一些具体的要求。

● 需求必须通过文档的方式详细地记录下来，并被验证。

● 应该尽早地开展测试活动，测试活动应该贯穿整个软件生命开发周期。

● 当软件发生变更的时候，必须要对变更的地方进行确认，还必须分析变更对整个软件系统的影响。

● 确认活动的覆盖率应该是基于软件的复杂性和安全相关风险，而不是根据软件的规模或者资源的约束。

● 选择的确认活动、任务或工作项必须和软件设计的复杂性以及使用软件相关的风险相符合。

● 所有的软件确认的计划和过程中的活动都必须进行文档化。

● 采用独立评审。条件允许的情况下最好采用第三方机构对软件开发过程中的交付物进行独立评审；如果是组织内部人员参加评审，这些人必须和被评审的设计或实现无关，并且具备足够的知识技能。

● 所有的测试用例必须有明确的期望结果。

● 既需要根据软件产品的内部结构设计测试用例对软件产品进行测试，也需要根据软件外部规格说明设计测试用例对软件产品进行测试。

● 要建立从需求、设计、编码到测试的跟踪系统，保证所有的需求在整个软件开发生命周期中都有对应的活动进行覆盖，例如：组件测试和详细设计、集成测试和概要设计、系统测试和需求规格应该有详细的跟踪对应关系。

● 整个软件开发生命周期中涉及的和所有任务或活动相关的计划、执行过程、变更和结果都必须被详细地记录下来。

测试作为软件开发过程的重要组成部分，必然是相应规章或标准中重点关注的部分。整个测试活动对于规章或标准的符合程度直接影响最终产品的质量。上面 FDA的例子中甚至明确提到，测试用例必须有明确的预期结果这么详细的要求。所有的测试活动都应该通过文档的方式记录下来，测试的输出是相关审计活动要检查的对象。

2.安全关键系统和复杂性

许多复杂的系统和综合系统都有安全性组件。某些时候，这些安全性要素在当前系统级别（或其子系统的级别）并不显现，而在其高一级的系统级别才显现，或在复杂系统部署时显现（如飞机的飞行控制组件、空中交通管制系统）。

☆示例：安全关键系统组件

一个路由器本身可能不是安全关键系统，但是，如果路由信息应用的环境有安全性要求时，它就是变成安全关键系统（如远程医疗服务系统）。

风险管理的主要目的是通过管理软件开发生命周期中的风险，来减少对项目测试目标造成不利影响的事件发生的可能性及其后果，它是安全关键系统的开发过程和测试过程的必要组成部分。风险管理的主要活动包括风险识别、风险分析和风险减轻。风险管理计划和风险沟通等也是风险管理的重要组成部分。风险识别应该在项目的早期进行，例如：在测试计划开始的时候就进行测试风险的识别。对识别的测试风险进行定性或者定量分析和评估（包括风险发生的可能性、发生的后果、可能发生的时间等），根据分析得到的测试风险级别采取相应的应对措施，从而降低风险对测试目标的威胁，同时在整个测试过程中对测试风险进行监控（详细的测试风险的内容，参见3.9节）。

此外，失效模式和影响分析通常的失效原因分析也会应用在这种环境中。失效模式和影响分析是可靠性设计的重要方法之一，它实际上是失效模式分析和失效影响分析的组合。它对各种可能的风险进行评价、分析，以便在现有技术的基础上消除风险或将风险减小到可接受的程度。及时性是成功实施FMEA的最重要因素之一，它是一个“事前的行为”，而不是“事后的行为”（详细的FMEA的内容，参见3.10节）。