2023年军用计算机安全评估准则

军用计算机安全评估准则

GJB2646-96

Militarycomputersecurityevaluationcriteria

（国防科学技术工业委员会1996年6月4E发布1996年12月1口实施）

一范围

1.1主题内容

本标准规定了评估计算机安全的准则，等级划分及每个等级的安全要求。

1.2适用范围

本标准适用于军用计算机安全评估，主要面向操作系统，也适用于其他需要进行安全评

估的计算机。

二引用文件

GJB2255-95军用计算机安全术语

三定义

3.1术语

本章未列入的术语，见GJK2255。

3.1.1自主保护discretionaryprotection

辨识用户身份和他们的需求，限制用户使用信息的访问控制的方法。

3.1.2强制访问控制mandatoryaccesscontrol

根据客体所包含信息的敏感性以及主体访问此类敏感信息的权限,限制主体访问客体的

方法。

3.1.3安全等级securitylevel

为表示信息的不同敏感度，按保密程度不同对信息进行层次划分的组合或集合。

3.1.4审计audit

对影响系统安全的各种活动进行记录并为系统安全员提供安全管理依据的程序。

3.1.5隔离isolation

为防止其他用户或程序的非授权访问，把操作系统、用户程序、数据文件加以彼此独立

存储的行为。

3.1.6可信计算基(TCB)trustedcomputingbase

计算机系统内保护装置的总体，包括硬件、固体、软件和负责执行安全策略的组合体。

它建立了一-个基本的保护环境并提供一个可信计算系统所要求的附加用户服务。

3.1.7敏感标号sensitivitylabel

表示客体安全级别并描述客体数据敏感性的一组信息，可信计算基中把敏感标号作为

强制访问控制决策的依据，

3.1.8系统完整性systemintegrity

系统不能以非授权手段被破坏或修改的性质。

3.1.9描述性顶层规格说明(DTLS)descriptivetop-levelspecification

用自然语言、形式化程序设计符号，或两者结合写在的一种最高层的设计规格说明书。

3.1.10形式化顶层规格说明(FILS)formaltop-levelspecification

用形式化数学语言写成的一种高层规格说明书。使用这种规格，可以从理论上证明假定

的形式化要求与系统规格的一致性。

3.1.11最小特权原则principleofleastprivilege

为完成特定任务，授予主体所需要的最小访问特权的过程、策略。

3.1.12分层密级hierarchicalclassification

用层次结构的方式将主体和客体分成不同的保密等级。

3.1.13粒度granularity

一次访问操作所涉及到的访问对象的大小。

四一般要求

计算机系统安全将通过使用特定的安全特性控制对信息的访问，只有被授权的人或为

人服务的操作过程可以对信息进行访问。在本准则中提出了以下六条要求。4.1安全策略

必须有一种由系统实施的、明确的和定义好的安全黄略。对于主体和客体，必须有一个

由系统使用的规则集合。利用这个规则合来决定是否允许一个给定的主体对一特定客体访问。

对于处理敏感信息的计算机系统必须施加一种强制安全策略来有效地实现访问规则。这些规

则要求包括：任何人如果缺少适当的安全许可证都不能获得对敏感信息的访问；同时也要

求有自主的安全控制，以保证只有指定的用户或用户组才可以获得对数据的访问。

4.4.2标号

客体应当按敏感程度加以标号，访问控制标号必须与客体联系起来。为了控制对存储在

计算机内的信息进行访问，根据强制安全策略规则，每个客体必须有一个标号，这个标号

表示客体的敏感级别并记录哪些主体可以对特定的客体进行访问的方式。

4.3标识

每个主体都必须在验明身份（身份标识）后才能对客体进行访问。每次对信息的访问都应

标识谁在要求访问，他有权访问什么信息？标识和授权信息必须由计算机系统在秘密情况

下进行维护并与完成某些与安全有关动作的每个活动元素结合起来。

4.4责任

对审计信息应有选择地保存并妥善加以保护，以便以后对影响安全的动作进行跟踪,

查清责任。一个可信系统应将与安全有关的事件记录在一个审计日志中，为了降低审计费用

并提高分析效率，必须具有选择审计事件的能力。审计信息必须很好地保护，以防修改和未

经授权的毁坏。

4.5保证

计算机系统应包括能使上述各条要求实现所必须的硬件和软件机制，必须有一批硬件

和软件控制，这些机制可嵌入操作系统内，并用秘密方法执行指定的任务。这些机制应在文

件中写清楚并能独立检验其结果，以便能独立地考评它们是否充分。

4.6连续保护

对实现上述基本要求的可信机制必须能连续地提供保护，以对抗未授权的篡改.圻果实

现上述策略的硬件和软件机制本身遭到未授权的修改或破坏，那么这个计算机系统是做不

到真正安全的。连续保护要求与计算机系统的整个生存周期有着直接的关系。

五详细要求

本准则根据上述六条要求，按处理的信息等级和采取的相应措施，将计算机系统的安

全分为四等八级别。D为最低等级，随着等级的提高，系统可信度也随之增加，风险逐渐减

少。

注：在本标准中，凡是使用黑体字的部分均表示在较低等级中不包含那些要求，或表

示对已定义要求的变动和增加；凡是不使用黑体字的部分均表示这些要求与较低等级的那

些对应要求相同。

5.1D等：最小保护

本等只含一级，它是为那些已作评估，但不能满足纹高评估等级要求的系统而准备的。

5.2C等：自主保护

本等分为C1和C1两个级别，它主要提供自主访问控制保护，并具有对主体责任和他们

的初始动作审计的能力。

5.2.1C1级：自主安全保护

Cl级的可信计算基（TCB）通过提供用户与数据的分离来标称满足无条件安全要求。它包

括某种形式的可信控制，以便能在个体基础上执行访问限制，即外表上允许用户保护项目

和保护私有数据，并阻止其他用户意外地读取或破坏他们的数据。C1级环境是在同一敏感等

级上处理数据的那些协同用户所要求的。卜.述是C1级的最低要求。

5.2.1.1安全策略

5.2.1.1.1自主访问控制

TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控

制访问。实施机制（如自身/组/公共控制，访问控制表）应允许用户通过己命名的单个用户或

已定义的组或两者来规定和控制这些客体的共享。

5.2.1.2责任

5.2.1.2.1标识和鉴别

在开始执行TCB仲裁的任何其他动作之前，TCB要求用户自己向TCB作出标识。因此,

TCB应使用•种受保护的机制（如口令）来鉴别用户的身份。TCB应保护鉴别数据，以使它不

能被任何未授权用户访问，

5.2.1.3保证

5.2.1.3.1操作保证

5.2.1.3.1.1系统体系结构

TCB应维持它自己执行的区域，以保护它免受外部干预或篡改（如它代码或数据结构

的修改）。由TCB控制的资源可以是计算机系统中已定义的主体和客体的子集。

5.2.1.3.1.2系统完整性

应提供硬件特性或软件特性或同时提供两者，用于定期地验证TCB硬件和固件单元的

运行正确性。

5.2.1.3.2生存周期保证

5.2.1.3.2.1安全测试

应对计算机系统的安全机制进行测试，并按系统文档的要求工作。测试应当保证：没有

明显的让未授权用户旁越的途径，或没有其他击败TCB安全保护机制的方法，见附录C（补

充件）。

5.2.1.4文档

5.2.1.4.1安全特性为用户指南

用户文档中的摘要、章节或手册应描述由TCB提供的保护机制，有关它们使用的指南以

及它们如何相互作用。

5.2.1.4.2可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告，这种特权在一个安全

设施运行时应受到控制。

5.2.1.4.3测试文档

系统开发者应向评估者提供一个文档，该文档描述测试计划，怎样测试安全机制的测

试过程，以及安全机制的功能测试结果。

5.2.1.4.4设计文档

设计文档应当具有描述制造厂家的保护宗旨以及怎样把这种宗旨转换成TCB的解释。如

果TCB是由不同的模块组成，则应描述这些模块之间的接口。

5.2.2C2级:可控制访问保护

这一级实施一种比C1级粒度更细的自主访问控制。可通过注册过程、与安全相关事件

的审计以及资源隔离等措施，使用户对它们的活动分别负责。下述是C2级的最低要求。

5.2.2.1安全策略

5.2.2.1.1自主访问控制

TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控

制访问。实施机制（如自身/组/公共控制，访问控制表）应允许用户通过已命名的单个用户或

已定义的单个用户组或两者来规定和控制这些客体的共享，同时应提供控制，以限制访问

权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护，避免无

授权的访问。这些访问控制应既能包括或乂能排除单用户粒度的访问。如已不具有访问许可

的用户要得到对一个客体的访问许可，只应当由授权用户分配。

5.2.2.1.2客体重用

在向一个主体初始转让、分配或重分配TCB的未使用存储器客体池之前，应废除所有包

含在存储器客体内的信息授权。对已释放回系统的客体，有访问权的任何主体都不能使用任

何先前主体动作产生的信息，包括已加密表示的信息。

5.2.2.2责任

5.2.2.2.1标识和鉴别

在开始执行TCB仲裁的任何其他动作之前，TCB要求用户自己向TCB作出标识。因此,

TCB应使用一种受保护的机制（如口令）来鉴别用户的身份，TCB应保护鉴别数据，以使它不

能被任何未授权用户访问，TCB应通过提供极好的保护计算机系统各个单个用户的能力来实

现其责任。TCB还应当提供把这种身份与该单个用户发生的所有可审计动作相联系的能力。

5.2.2.2.2审计

TCB应能建立、维持和保护对它所保护的客体访问的审计跟踪，防止修改、未授权访问

或破坏。审计数据应受TCB保护，以便对它的读访问被限制在对审计数据已授权的那些用户

上。TCB应能记录下述类型的事件：标识和鉴别机制的使用;把客体引入到一个用户佗地址

空间（如打开文件，起动程序）；删除客体；计算机操作员、系统管理员或系统安全员或后两者

同时所发生的动作；以及其他有关的安全事件。对每个己汜录的事件，审计记录应标出:事件

发生的口期和时间；用户、事件的类型；事件的成功或失败。对于标识和鉴别事件，请求源

（如终端ID）也应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件，

审计记录也应包括客体名。计算机系统管理员应能基于单个用户身份有选择地审计任一或多

个用户的活动。

5.2.2.3保证

5.2.2.3.1操作保证

5.2.2.3.1.1系统体系结构

TCB应维持它自己执行的区域，以保护它免受外部干预或篡改（如对它的代码或数据结

构进行修改）。由TCB控制的资源可以是计算机系统中已定义的主体和客体的子集。TCB应

隔离被保护的资源，以使它们易受访问控制，并达到审计要求。

5.2.2.3.1.2系统完整性

应提供硬件特性或软件特性或同时提供两者，用于定期地验证TCB硬件和固件单元的

运行正确性。

5.2.2.3.2生存周期保证

5.2.2.3.2.1安全测试

应对计算机系统的安全机制进行测试，并按系统文档的要求工作，测试应当保证；没

有明显的让未授权用户旁越的途径，或没有其他击败TCB安全保护机制的方法。测试还应包

括搜索明显的缺陷，这些缺陷会使资源隔离破坏或会允许对审计或鉴别数据的未授权访问，

见附录C（补充件）。

5.2.2.4文档

5.2.2.4.1安全特性的用户指南

用户文档中的摘要，章节或手册应描述由TCB提供的保护机制，有关它们使用的指南

以及它们如何相互作用。

5.2.2.4.2可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告，这种特权在一个安全

设施运行时应受到控制。对各类审计事件，应给出供检查和维护审计文件以及详细审计记录

结构用的规程。

5.2.2.4.3测试文档

系统开发者应向评估者提供•个文档，该文档描述测试计划、如何测试安全机制的测试

过程以及安全机制的功能测试结果。

5.2.2.4.4设计文档

设计文档应当具有描述制造厂家的保护宗旨以及怎样把这种宗旨转换成TCB的解糅。如

果TCB是由不同的模块组成，则应描述这些模块之间的接口。

5.3B等：强制保护

本等分为Bl,B2和B3三个级别，它主要要求客体必须保留敏感标号,TCB利用它去施

加强制访问控制保护。在本等级中，对于计算机系统中大多数数据结构都必须带有敏感标号;

系统开发者要提供安全策略模型，根据此模型生成TCB。同时系统开发者也要提供TCB的技

术规范说明并提供基准监控器概念J被实现的证据。

5.3.1B1级：有标号的安全保护

B1级要求具有C2级的全部特征。另外，必须提出安全策略模型的非形式化说明、数据

标号以及已命名主体对客体的强制访问控制。对输出信息必须有正确的标号能力；必须排除

任何经测试而标识的缺陷,下述是B1级的最低要求。

5.3.1.1安全策略

5.3.1.1.1自主访问控制

TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控

制访问。实施机制（如自身/组/公共控制，访问控制表）应允许用户通过已命名的单个用户或

已定义的单个用户组或两者来规定和控制这些客体的共享，同时应提供控制，以限制访问

权利的扩散。自主访问控制应既能包括或乂能排除单用户粒度的访问。如已不具有访问许可

的用户要得到对一个客体的访问许可，只应当由授权用户分配。

5.3.1.1.2客体重用

在向一个主体初始转让、分配或重分配TCB的未使用存储器客体池之前，应废除所有包

含在存储器客体内的信息授权。对已释放回系统的客体，有访问权的任何主体都不能使用任

何先前主体动作产生的信息，包括已加密表示的信息。

5.3.1.1.3标号

与每个主体及在其控制下的存储器客体（如进程、文件、段、设备）有关的敏感标号应由

TCB维护。这些标号应被用作强制访问控制判断的依据。为了输入无标号的数据，TCB应提

出要求，并从授权用户那里接受该数据的安全等级，而且TCB应对主体的所有这类活动都

能

进行审计。

5.3.1.1.3.1标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级，主体和客体应以此发生关联。当

TCB输出时，敏感标号应能准确地和明确地表示内部标号，而且应与正在输出的信息发生

联系。

5.3.1.1.3.2有标号信息的输出

TCB应对每个通信信道和1/（）设备标明单级或多级。这个标志的任何变化都应由人工实

现，并可由TCB审计。TCB应维持并且能够对安全等级的任何变化进行审定，或对与通信信

道或I/O设备有关的等级进行审计。

5.3.1.1.3.2.1向多级设备的输出

当TCB将一客体输出到一个多级I/O设备时，与该客体有关的敏感标号也应输出。应与

输出信息相同的形式（如机器可读或人可读形式）驻留在同一物理媒体上。当TCB在多级通信

信道上输出或输入一客体时，该信道使用的协议应在敏感标号和被发送或被接收的有关信

息之间提供明确的配对关系。

5.3.1.1.3.2.2向单级设备的输出

单级I/O设备和单级通信信道不需要维持其处理信总的敏感标号。但是TCB应包含一种

机制，TCB和一个授权用户按该机制可靠地与指定的单安全级的信息通信。这种信息经由单

级通信信道或I/O设备输入/输出。

5.3.1.1.3.2.3人可读标记的输出

计算机系统管理员应能规定与输出敏感标号有关的可打印标号名。TCB应标记所有人可

读的、编页的、具有人可溟的敏感标号的硬拷贝输出（如行打E「J机输出）的开始和结束，它适

当地D表示输出敏感性。TCB应按默认值标记人可读的、编页的、具有人可读的敏感标号的

硬拷贝输出（如行打印机输出）每页的顶部和底部，它适当地1）表示该输出总的敏感性，或

适当地1）表示该页信息的敏感性。TCB应该按默认值，弁以-一种适当方法标记具有人可读的

敏感标号的其他形式的人可读的输出（如图、图形），它适当地1）表示该输出的敏感性。这

些标记默认值的任何滥用都应由TCB审计。

注：1）人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密

级；非分层等级应包括与该标号输出有关信息的全部非分层等级，但不包括其他非分层等

级。

5.3.1.1.4强制访问控制

TCB应对全部主体及在其控制下的存储器客体（如进程、文件、段、设备）实施强制访问

控制策略。这些主体和客体，应给予敏感标号，这些标号是分层密级和非分层等级的结合,

而且应作为强制访问控制判断的依据。TCB应能支持两种或两种以上安全等级，见附录B（补

充件）。对于在受TCB控制的主体和客体之间的全部访问应遵循下列要求：仅当主体安全级

中的分层密级大于或等于客体安全级中的分层密级，而主体安全级中非分层等级包括了

客体安全级中全部非分层等级时，主体才能读一个客体。仅当主体安全级中分层密级小于等

于客体安全级中分层密级，而且主体安全级中非分层等级被包含在客体安全级中非分层等

级时，主体才能写一个客体。TCB应该用标识和鉴别数据来鉴别用户的身份，并用来保证那

些相对于TCB外部的可代表单个用户建立动作的主体的安全等级和授权，并且受批准和授

权的那个用户支配。

5.3.1.2责任

5.3.1.2.1标识和鉴别

在开始执行TCB仲裁的任何其他动作之前，TCB要求用户自己向TCB作出标识。因此,

TCB应维持鉴别数据，该数据包括用于验证单个用户身份的信息以及用于确定批准和授权

单个用户的信息，这种数据应被TCB用来鉴别用户身份，以及保证那些相对于TCB外部的可

代表单个用户建立动作的主体的安全等级和授权，并且受批准和授权那个用户支配.TCB应

保护鉴别数据，以使它不能被任何未授权用户访问.TCB应通过提供极好的标识计算机系统

各个单个用户的能力来实现其责任。TCB还应具有把这种身份与该单个用户发生的所有可审

计动作相联系的能力。

5.3.1.2.2审计

TCB应能建立、维持和保护对它所保护的客体访问的审计跟踪，防止修改、未授权访问

或破坏。审计数据应受TCB保护，以便对它的读访问被限制在对审计数据已授权的那些用户

上。TCB应能记录下述类型的事件：标识和鉴别机制的作用；把客体引入到一个用户的地址

空间（如打开文件，起动程序）；删除客体；计算机操作员、系统管理员或系统安全员或后两

者同时所发生的动作；以及其他有关的安全事件。TCB还应能审计人可读标记的输出的任何

滥用。对每个记录的事件，审计记录应标出：事件发生的日期和时间；用户事件的类型；事件

的成功或失败。对于标识和鉴别事件，请求源（如终端：D）应包括在审计记录中。对于把客

体引入用户地址空间的事件和客体删除事件，审计记录应包括客体名和客体的安全等级。计

算机系统管理员应能基于每个用户身份或客体安全级或同时基于两者有选择地审计任一或

多个用户的活动。

5.3.1.3保证

5.3.1.3.1操作保证

5.3.1.3.1.1系统体系结构

TCB应维持它自己执行的区域，以保护它免受外部干预或篡改（如对它的代码或数据结

构进行修改）。由TCB控制的资源可以是计算机系统中已定义的主体和客体的子集。TCB应

在其控制下通过提供不同的地址空间来维护进程隔离。TCB应隔离被保护的资源，以使它们

易受访问控制，并达到审计要求。

5.3.1.3.1.2系统完整性

应提供硬件特性或软件特性或同时提供两者，用于定期地验证TCB硬件和固件单元的

运行正确性。

5.3.1.3.2生存周期保证

5.3.1.3.2.1安全测试

应对计算机系统的安全机制进行测试，并按系统文档的要求工作。一个充分熟悉TCB

特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。他们的目标应是：暴

露全部设计和实现的缺陷，这些缺陷将允许一个TCB外H勺主体去读、更改或删除通常在TCB

执行强制或自主安全策略时拒绝的数据，并且保证没有主体（尚未授权）能使TCB进入一种

对其它用户发起的通信作出响应的状态。所有已发现的缺陷应被纠正，或者其无效，而且

TCB应重新测试，以验证已缺陷，并证明没有产生新的缺陷，见附录C（补充件）。

5.3.1.3.2.2设计规格说明和验证

应在计算机系统的整个生命周期内维持由TCB支撑的安全策略的非形式化或形式化模

型，并应证实与它的原理相一致。

5.3.1.4文档

5.3.1.4.1安全特性的用户指南

用户文档中的摘要、章节或手册应描述由TCB提供的保护机制、有关它们使用的指南以

及它们如何相互作用。

5.3.1.4.2可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告，这种特权在一个安全

设施运行时应受到控制。对各类审计事件，应给出供检查和维护审计文件以及详细审计记录

结构用的规程。手册应描述操作员和管理员有关安全功能和用户安全特征的变化。它应提供

有关系统保护特性的一致和有效的用法。如他们怎样互相作用，怎样安全地生成一个新的

TCB;提供设施规程、警告和需要受控的特权，以便安全地操作该设施。

5.3.1.4.3测试文档

系统开发者应向评估者提供一个文档，该文档描述测试计划，如何测试安全机制的测

试过程，以及安全机制的功能测试结果。

5.3.1.4.4设计文档

设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成TCB的解释。如

果TCB是由不同的模块组成，则应描述这些模块之间的接口。由TCB实施的安全策略模型的

非形式化或形式化描述应是可用的，而且提供一种解释来表示实施安全策略是足够的.应当

标识特定的TCB保护机制.而且给出一种解释表示它们满足该模型。

5.3.2B2级：结构化保护

在B2级中，TCB是是立在对形式化安全策略模型清晰定义和提供文档的基础之上的。

该模型要求执行B1级所是立的自主和强制访问控制，并扩展到计算机系统的全部主体和客

体。另外，提出了隐蔽信道。TCB必须是仔细地构成严格保护和非严格保护的单元。TCB接

口应定义恰当，而且TCB设计和实现能使它经受比较彻底的测试和比较安全的检查。要加强

鉴别机制，以支撑系统管理员和操作员功能的方式提供可信设施管理，而且要加强严格的

配置管理控制。该系统有相对的抗渗透能力。下述是B2级的最低要求。

5.3.2.1安全策略

5.3.2.1.1自主访问控制

TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控

制访问。实施机制（如自身/组/公共控制，访问控制表）应允许用户通过已命名的单个用户或

己定义的单个用户组或两者来规定和控制这些客体的共享，同时应提供控制，以限制访问

权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护，避免无

授权的访问。这些访问控制应既能包括或乂能排除单用户粒度的访问。如已不具有访问许可

的用户要得到对一个客体的访问许可，只应当由授权川户分配。

5.3.2.1.2客体重用

在向一个主体初始转让、分配或重分配TCB的未使用存储器客体池之前，应废除所有包

含在存储器客体内的信息授权。对已释放回系统的客体，有访问权的任何主体都不能使用任

何先前主体动作产生的信息，包括已加密表示的信息。

5.3.2.1.3标号

与每个由TCB外部主体直接或间接访问的计算机系统资源（如主体、存储器客体、ROM）

有关的敏感标号应由TCB维护。这些标号应被用作强制访问控制判断的依据。为了输入无标

号的数据，TCB应提出请求，并从授权用户那里接受该数据的安全等级，而且TCB应对所有

这类活动进行审计。

5.3.2.1.3.1标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级，主体和客体应以此发生关联,

当TCB输出时，敏感标号应能准确地和明确地表示内部标号，而且应与正在输出的信息发

生联系。

5.3.2.1.3.2有标号信息的输出

TCB应对每•个通信信道和I/O设备标明单级或多级。这个标志的任何变化都应由人工

实现，并可由TCB审计。TCB应维持并且能够地安全等级的任何变化进行审计，或对与通信

信道或I/O设备有关的等级进行审计。

5.3.2.1.3.2.1向多级设备的输出

当TCB将一客体输出到一个多级I/O设备时，与该客体有关的敏感标号也应输出。应与

输出信息相同的形式（如机器可读或人可读形式）驻留在同一物理媒体上,当TCB在多级通信

信道上输出或输入一客体时，该信道使用的协议应在敏感标号和被发送或被接收的有关信

息之间提供明确的配对关系。

5.3.2.1.3.2.2向单级设备的输出

单级I/O设备和单级通信信道不需要维持其处理信息的敏感标号。但是TCB应包含一种

机制，TCB和一个授权用户按该机制可靠地与指定的单安全级的信息通信。这种信息经由单

级通信信道或I/O设备输入/输出。

5.3.2.1.3.2.3人可读标记的输出

计算机系统管理员应能指定与输出敏感标号有关的可打印标号名。TCB应标记所有人可

读的、编页的、具有人可读敏感标号的硬拷贝输出（如行打印机输出）的开始和结束，它适当

地D表示输出敏感性。TCB应按默认值标记人可读的、编页的、具有人可读的敏感度标记的

硬拷贝输出（如行打印机输出）每页的顶部和底部，它适当地1）表示该输出总的敏感性，或

适当地1）表示该页信息的敏感性。TCB应该按默认值，并以一种适当方法标记具有人可读的

敏感标号的其他形式的人可读输出（如图、图形），它适当地1）表示该输出的械感性。这些

标记默认值的任何滥用都应由TCB审计。

注：1）人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密

级；非分层等级应包括与该标号输出有关信息的全部非分层等级，但不包括其他非分层等

级。

5.3.2.1.3.3主体敏感标号

在终端用户交互对话期内，与该用户有关的安全等级的各种变化，TCB应立即通知该用

户。当需要显示完整的主体敏感标号时，终端用户应能向TCB提出询问。

5.3.2.1.3.4设备标号

对各种附加物理设备：TCB应能支持最小和最大安全等级的分配。TCB应利用这些安全

等级来实施由该设备安放的物理环境的强加的约速。

5.3.2.1.4强制访问控制

TCB应对所有被TCB外部主体直接或间接存取的资源（如主体、存储器客体以及I/O设

备）实施强制访问控制策略。这些主体和客体应给予敏感标号。这些标号是分层密级和非分

层等级的结合，而且应作为强制访问控制判断的依据。TCB应能支持两种或两种以上安全等

级，见附录B（补充件）。对TCB外部的全部主体和由这些主体直接或间接存取的全部客体之

间的所有访问应遵循下列要求：仅当主体安全级中的分层密级大于等于客体安全级中的分

层密级，而且主体安全级中非分层等级包括了客体安全级中全部非分层等级时，主体才能

读一个客体仅当主体安全级中分层密级小于等于客体安全级中分层密级，而且主体安全级

中非分层等级被包括在客体安全级中非分层等级时，主体才能写一个客体。TCB应该用标识

和鉴别数据来鉴别用户的身份，并用来保证那些相对于TCB外部可代表单个用户建立动作

的主体的安全等级和授权：并且受批准和授权的那个用户支配。

5.3.2.2责任

5.3.2.2.1标识和鉴别

在开始执行TCB仲裁任何其他动作之前，TCB要求用户自己向TCB作出标识。因此，TCB

应维持鉴别数据，该数据包括用于验证单个用户身份的信息以及用于确定批准和授权单个

用户的信息。这种数据应被TCB用来鉴别用户身份，以及保证那些相对于TCB外部可代表单

个用户建立动作的主体的安全等级和授权，并旦受批准和授权的那个用户支配。TCB应保护

鉴别数据，以使它不能被任何未授权用户访问。TCB应通过提供极好的标识计算机系统每个

单个用户的能力来实现其责•任。TCB还应具有把这种身份与该单个用户发生的所有可审计动

作相联系的能力。

5.3.2.2.1.1可信路径

TCB应在它自身与初始注册及鉴别用户之间支持一个可信的通信路径，经由这种路径

的通信应由一个用户独占地启动。

5.3.2.2.2审计

TCB应能建立、维护和保护对它所保护的客体访问的审计跟踪，防止修改、未授权访问

或破坏。审计数据应受TCB保护，以便对它的读访问被限制在对审计数据已授权的那些用户

l-.oTCB应能记当下述类型的事件：标识和鉴别机制的速用；把客体引入到一个用户的地址

空间（如打开文件、启动程序）；删除客体;计算机操作员、系统管理员或系统安全员或后两者

同时所发生的动作；以及其他有关的安全事件。TCB还应能审计人可读标记输出的任何潴用。

对每个已记录的事件，审计记录应标出：事件发生的日期和时间；用户、事件的类型；事件

的成功或失败。对于标识和鉴别事件，请求源（如终端1D）应包括在审计记录中。对于把客

体引入用户地址空间的事件和客体删除事件，审计记录应包括客体名和客体的安全等级。计

算机系统管理员应能基于单个用户身份或客体安全级或同时基于两者有选择地审计任一或

多个用户的活动。TCB应能审计利用隐蔽存储信道的标识事件。

5.3.2.3保证

5.3.2.3.1操作保证

5.3.2.3.1.1系统体系结构

TCB应维护它自己执行的区域，以保护它免受外来干预或篡改（如对它代码或数据结构

修改）oTCB应在其控制下，通过提供不同的地址空间来维护进行隔离。TCB内部应由定义恰

当的、基本上独立的模块构成。它应有效地使用可获得的硬件，把那些严格保护的单元与那

些不严格保护的单元分离开来。TCB模块应如此设计，以便它能实施最小特权原则。硬件中

诸如分段的特性，应被用来支持逻辑上截然不同的存储器客体，这些客体具有分离的属性

（如：可读、可写）。应完整地定义用户与TCB的接口，并标识所有TCB的单元。

5.3.2.3.1.2系统完整性

应提供硬件特性或软件特性或同时提供两者，用于定期地验证TCB硬件和固件单元的

运行正确性。

5.3.2.3.1.3隐蔽信道分析

系统开发者应对隐蔽存储信道作彻底地搜查，并且通过实际测量或通过工程估计确定

每个已标识信道的最大带宽，见附录A（补充件）。

5.3.2.1.4可信设施管理

TCB应支持操作员和管理员的职能分隔。

5.3.2.3.2生存周期保证

5.3.2.3.2.1安全测试

应对计算机系统的安全机制进行测试，并按系统文档的要求工作。一个充分熟悉TCB

特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。它们的目标应是：暴

露全部设计和实现的缺陷：这些缺陷将允许一个TCB外的主体去读、更改或删除通常在TCB

实施强制或自主安全策略时拒绝的数据，并且保证没有主体（尚未授权）能使TCB进入一种

对其它用户启动的通信作出响应的状态。TCB应建立相对的抗渗透能力。所有已发现的缺陷

应被纠正，而且TCB应重新测试，以验证已排除缺陷，并证明没有产生新的缺陷。测试应证

明TCB的实现与描述性顶层规格说明相一致，见附录C（补充件）。

5.3.2.3.2.2设计规格说明和验证

应在计算机系统的整个生命周期内维持由TCB支撑的安全策略形式化模型、并证明与它

的原理相一致。应维持TC3的描述性顶层规格说明（DTLS）,以使用异常、出错消息和影响等

方面来完整地和准确地描述TCB,还应说明描述性顶层规格说明是TCB接口的准确描述。

5.3.2.3.2.3配置管理

在TCB开发和维护期间，应把配置管理系统放在适当的位置，以维持对描述性顶层规

格说明、其他设计数据、实现文档、源代码、目标代码的运行版本以及测试夹具和文档等方

面改变的控制。配置管理系统应保证与当前TCB版本相关联的所有文档和代码之间的一致的

映射。应提供由源代码生成新的TCB版本的工具。另外，本应获得TCB新旧版本比较的工具，

以便查明实际用作新版本的TCB的代码只发生了所需的改动。

5.3.2.4文档

5.3.2.4.1安全特性的用户指南

用户文档中的摘要、章节或手册应描述由TCB提供的保护机制、有关它们使用的指南以

及它们如何相互作用。

5.3.2.4.2可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告，这种特权在一个安全

设施运行时应受到控制。对各类审计事件，应给出供检查和维护审计文件以及详细审计记录

结构用的规程。手册应描述操作员和管理员有关安全功能和用户

安全特征的变化。它应提供有关系统保护特性的一致和有效的用法。如它们怎样互•相作

用，怎样安全地生成一个新的TCB;提供设施规程、警告和需要受控的特权，以便安全地操

作该设施。应标识基准确认机制的TCB模块。TCB的任何模块修改后，应描述由源代码安全

生成新TCB过程。

5.3.2.4.3测试文档

系统开发者应向评估者提供一个文档。该文档描述测试计划，怎样测试安全机制的测试

过程，以及安全机制的功能测试结果；它应包括用来减少隐蔽信道带宽方法的有效性测试

结果。

5.3.2.4.4设计文档

设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成TCB的解释。也

应描述TCB模块之间的接口。由TCB实施的安全策略模型形式化描述应是可用的，并且证明

它对于实施安全策略是足够的。应当标识特定的TCB保护机制，而且给出一种解释表示它们

满足该模型。描述性顶层规格说明应当表明TCB接口的准确描述。文档应描述TCB怎样实现

基准监控器概念，并解称它为什么能防篡改，为什么不能被旁越，以及为什么它能被正确

地实现。文档应描述如何物造TCB才便于测试和实施最小特权。该文档还应给出隐蔽信道分

析的结果和与限定该信道有关的折衷方案。应当标识可用来利用已知隐蔽存储信道的所有可

审计事件。由于已知隐蔽存储信道的使用不是用审计机制可检测的，所以应提供已知隐蔽存

储信道的带宽，见附录A（补充件）。

5.3.3B3级:安全域

B3级TCB必须满足基准监控器的要求，以便它能仲裁所有主体向客体的访问。它必须

是防篡改的，而且是小到足以提供分析和测试。为此，在TCB设计及实现期间，要用有效的

系统工程方法，使构造的TCB能排除与安全策略实施无关的代码，从而使其复杂性达到最

小。要支持安全管理员；要把审计机制扩展到用信号报知与安全有关的事件；并且要提供系

统恢及过程。该系统有高度的抗渗透能力。下述是B3级的最低要求：

5.3.3.1安全策略

5.3.3.1.1自主访问控制

TCB应在计算机系统已命名的用户和已命名的客体（如文件和程序）之间进行定义和控

制访问。实施机制（如访问控制表）应允许用户通过已命名的单个用户或已定义的单个用户组

或两者来规定和控制这些客体的共享，同时应提供控制，以限制访问权利的扩散。自主访问

控制机制应当按明确的用户动作或按默认值向客体提供保护，避免无授权的访问。对于每个

、命名的客体，这些访问控制应能规定一份」命名的单个用户表和一份己命名的单个用户

组表，以表示它们对该客体相应的访问方式。此外，对于每个已如此命名的客体，应能规定

不能访问该客体的已命名单个用户表和已命名单个用户组表。如已不拥有访问许可的用户要

得到对一个客体的访问许可，只应当由授权用户分配。

5.3.3.1.2客体重用

在向一个主体初始转让、分配或重分析TCB的未使用存储器客体池之前，应废除所有包

含在存储器客体内的信息授权。对已释放回系统的客体，有访问权的任何主体都不能使用任

何先前主体动作产生的信息，包括已加密表示的信息。

5.3.3.1.3标号

与每个由TCB外部主体直接或间接访问的计算机系统资源（如主体、存储器客体、ROM）

有关的敏感标号应由TCB维护。这些标号应被用作强制访问控制判断的依据。为了输入无标

号的数据。TCB应提出请求，并从授权用户那里接受该数据的安全等级，而且TCB应对所有

这类活动进行审计。

5.3.3.1.3.1标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级，主体和客体应以此发生关联。当

TCB输出时，敏感标号应能准确地和明确地表示内部标号，而且应与止在输出的信息发生

联系。

5.3.3.1.3.2有标号信息的输出

TCB应对每个通信信道和1/（）设备标明单级或多级。这个标志的任何变化都应由人工实

现，并可由TCB审计。TCB应维持并且能够对安全等级的任何变化进行审计，或对与通信信

道或I/O设备有在的等级进行审计。

5.3.3.1.3.2.1向多级设备的输出

当TCB将一客体输出到一个多级I/O设备时，与该客体有关的敏感标号也应输出。应与

输出信息相同的形式（如机器可读或人可读形式）驻留在同一物理媒体上。当TCB在多级通

信信道上输出或输入一客体时，该信道使用的协议应在敏感标号和被发送或被接收的有关信

息之间提供明确的配对关系。

5.3.3.1.3.2.2向单级设备的输出

单级I/O设备和单级通信信道不需要维持其处理信息的敏感标号。但是TCB应包含一种

机制，TCB和一个授权用户应按该机制可靠地与指定的单安全级的信息通信。这种信息经由

单级通信信道或I/O设备输入/输出。

5.3.3.1.3.2.3人可读标记的输出

计算机系统管理员应能指定与输出敏感标号有关的可打印标号名。TCB应标记所有人可

读的、编页的、具有人可读敏感标号的硬拷贝输出（如行打印机输出）的开始和结束，它适当

地1）表示输出敏感性。TC3应按默认值标记人可读的、编页的，具有人可读的敏感标记的硬

拷贝输出（如行打印机输出）每页的顶部和底部，它适当地D表示该输出总的敏感性，或适

当地1）表示该页信息的敏感性。TCB应该按默认值，并以一种适当方法标记具有人可读敏感

标号的其他形式的人可读输出（如图、图形），它适当地1）表示该输出敏感性。这些默认值

的任何滥用都应由TCB审计。

注：1）人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密

级；非分层等级应包括与该标号输出有关信息的全部非分层等级，但不包括其他非分层等

级。

5.3.3.1.3.3主体敏感标号

在终端用户交互对话期内，与该用户有关的安全等级的各种变化TCB应立即通知该用

户。当需要显示完整的主体敏感标号时，终端用户应能向TCB提出询问。

5.3.3.1.3.4设备标号

对各种附加物理设备.TCB应能支持最小和最大安全等级的分配。TCB应利用这些安全

等级来实施由该设备安放的物理环境所强加的约束。

5.3.3.1.4强制访问控制

TCB应对所有被TCB外部主体直接或间接访问的资源（如主体、存储器客体以及I/O设

备）实施强制访问控制策略，这些主体和客体应给予敏感标号。这些标号是分层密级和非分

层等级的结合，而且应作为强制访问控制判断的依据。TCB应能支持两种或两种以上安全等

级，见附录B（补充件）。对TCB外部的全部主体和由这些主体直接或间接存取的全部客体之

间的所有访问应遵循下列要求：仅当主体安全级中的分层密级大于等于客体安全级中的分

层密级，而且主体安全级中非分层等级包括「客体安全级中全部非分层等级时，主体才能

读一个客全。仅当主体安全级中分层密级小于等于客体安全级中分层密级，而且主体安全级

中非分层等级被包含在客体安全级中非分层等级时，主体才能写一个客体。TCB应该用标识

和鉴别数据来鉴别用户的身份，并用来保证那些相对于TCB外部可代表单个用户建立动作

的主体的安全等级和授权、并且受批准和授权的那个用户支配。

5.3.3.2责任

5.3.3.2.1标识和鉴别

在开始执行TCB仲裁任何其他动作之前，应要求用户自己向TCB作出标识。因此，TCB

应维护鉴别数据，该数据包括用于验证单个用户身份的信息以及为确定批准和授权单个用

户的信息。这种数据应被TCB用来鉴别用户身份，以及保证那些相对于TCB外部的可代表单

个用户建立动作的主体的安全等级和授权，并且受批准和授权那个用户支配。TCB应保护鉴

别数据，以使它不能被任何未授权用户访问。TCB应通过提供极好的标识计算机系统每个单

个用户的能力来实现其责任。TCB还应具有把这种身份与该单个用户所发生的所有可审计动

作相联系的能力。

5.3.3.2.1.1可信路径

TCB应支持自身与诸用户之间的可信通信路径，以供TCB与用户需要可靠连接（如注册、

改变主体安全等级）时使用。经由这种可信路径的通信安全由一个用户或TCB独占地激活。

这种路径逻辑上应与其他路径隔离，并与其他路径截然地区分开来。

5.3.3.2.2审计

TCB应能建立、维持和保护对它所保护的客体访问的审计跟踪，防止修改、未授权访问

或破坏。审计数据应受TCB保护，对便对它的读访问被限制在对审计数据已授权的那些用户

上。TCB应能记录下述类型的事件：标识和鉴别机制的使用；把客体引入到一个用户地址空

间（如打开文件.启幻程序）：删除客体：计算机操作员、系统管理员或系统安全员或后

两者同时所发生的动作；以及其他有关的安全事件。TCB还应能审计人可读标记输出的任何

滥用。对每个已记录的事件，审计记录应标出：事件发生的日期和时间；用户、事件的类型；

理件的成功或失败。对于标识和鉴别事件，请求源（如终端ID）应包括在审计记录中。对于

把客体引入用户地址空间的事件和客体删除事件，审计记录应包括客体名和客体的安全等

级。计算机系统管理员应能基于单个用户身份或客体安全级或同时基于两者有选择地审计任

一或多个用户的活动°TCB应能审计利用隐蔽存储通道的标识事件。TCB应包含一种机制，它

能监控安全可审计事件的发生或累积，从而可以指出安全策略迫在眉睫的破坏。当阈值超过

时，这种机制应能立即通知安全管理员，而且当这些有关安全事件的发生或积累再继续下

去时，则系统应采取最小破坏的操作终止该事件。

5.3.3.3保证

5.3.3.3.1操作保证

5.3.3.3.1.1系统体系结构

TCB应维持它自己执行的区域，以保护它免受外来干预或篡改（如时它代码或数据结构

修改）。TCB应在其控制下，通过提供不同的地址空间来维护进程隔离，TCB内部应由定义恰

当的、基本上独立的模块构成。它应有效地使用可获得的硬件，把那些严格保护的单元与那

些不严格保护的单元分离开来。TCB模块应如此设计，以便它能执行最小特权原则。硬件中

诸如分段的特性，应被用来支持逻辑上截然不同的存储器客体,这些客体具有分离的属性

（如可读、可写）。应完整地定义用户与TCB的接口，并标识所有TCB的单元。TCB的设计和

构造应使用一种完整的、原理简单的、具有精确定义语义的保护机制，这种机制在实现TCB

和系统内部结构时将起中心的作用。TCB应把分层、抽象和数据隐蔽等方面的有效使用结合

起来。有效的系统工程应以TCB的复杂度极小化为目标，而且应排除没有严格保护的TCB

模块。

5.3.3.3.1.2系统完整性

应提供硬件特性或软件特性或同时提供两者，用于定期地验证TCB硬件和固件单元的

运行正确性。

5.3.3.3.1.3隐蔽信道分析

系统开发者应对隐蔽信道作彻底的搜杳，并且通过实际测量或通过工程估计确定每个

己标识信道的最大带宽，见附录A（补充件）。

5.3.3.3.1.4可信设施管理

TCB应支持操作员和管理员的职能分隔。应标识在安全管理员任务中所执行的职能。只

有在计算机系统上发生了与安全管理员任务截然不同的可审计活动后，计算机系统管理员

才能执行安全管理员职能。在安全管理任务中所能执行的非安全职能应严格限制在那些对有

效执行完全任务必不可少的职能。

5.3.3.3.1.5可信恢复

在计算机系统故障或其它间断后，应提供规程或机制或同时提供两者，以保证在不危

及保护情况下，使系统得到恢复。

5.3.3.3.2生存周期保证

5.3.3.3.2.1安全测试

应对计算机系统的安全机制进行测试，并按系统文档的要求工作。一个充分熟悉TCB

特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。它们的臼然应是：暴

露全部设计和实现的缺陷，这些缺陷将允许一个TCB外的主体去读、更改或删除通常由TCB

实施强制或自主安全策略时拒绝的数据，并且保证没有主体（尚未授权）能使TCB进入一种

对其它用户启动的通信作出响应的状态。TCB应建立相对•的抗渗透能力.所有已发现的缺陷

应被纠正，而且TCB应重新测试，以验证TCB已排除缺陷，并证明没有产生新的缺陷,测试

应证明TCB的实现与描述性顶层规格说明相一致，见附录C（补充件）。在测试中，没有发现

设计缺陷，也许发现少量可校正的实现缺陷，而应该确信这少量缺陷的存在是合理的。

5.3.3.3.2.2设计规格说明和验证

应在计算机系统的整个生命周期内维持由TCB支撑的安全策略的形式化模型，并证明

与它的原理是一致的。应维持TCB的描述性顶层规格说明，以便用异常、出错消息和影响等

方面来完整地和准确地描述TCB,还应说明描述性顶层规格说明是TCB接口的准确描述。应

给出有说服力的证据，以表明描述性顶层规格说明与该模型的一致性。

5.3.3.3.2.3配置管理在TCB开发和维护期间，应把配置管理系统放在适当的位置，

以维护对描述性顶层规格说明、其他设计数据、实现文档、源代码、目标代码的运行版本以

及测试夹具和文档等方面改变的控制1。配置管理系统应保证与当前TCB版本相关联的所有文

档和代码之间一致的映射，应提供由源代码生成新的TCB版本的工具。另外，还应获得TCB

新旧版本比较的工具，以便查明实际用作新版本的TCBH勺代码只发生了所需的改动。

5.3.3.4文档

5.3.3.4.1安全特性的用户指南

用户文档中的摘要、章节或手册应描述由TCB提供的保护机制，有关它们使用的指南以

及它们如何相互作用。

5.3.3.4.2可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告，这种特权在一个安全

设施运行时应受到控制。对各类审计事件，应给出供检查和维护审计文件以及详细审计记录

结构用的规程。手册应描述操作员和管理员有关安全功能和用户安全特性的变化。它应提供

有关系统保护特性的一致和有效的用法。如它们怎样互相作用，怎样安全地生成一个新的

TCB,提供设施规程，警告和需要受控的特权，以便安全地操作该设施。应标识基准确认机

制的TCB模块，TCB的任何模块修改后，应描述由源代码安全生成新TCB的过程。它应包括

保证系统以安全方式启动的过程，还应包括那些在系统运行间断后，重新开始安全运行的

过程。

5.3.3.4.3测试文档

系统开发者应向评估者提供一个文档，该文档描述测试计划，怎样测试安全机制的测

试过程以及安全机制的功能测试结果。它应包括用来减少隐蔽信道带宽方法的有效性测试结

果。

5.3.3.4.4设计文档

设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成TCB的解释。也

应描述TCB模块之间的接口。由TCB实施的安全策略模型形式化描述应是可用的，并且证明

它对实施安全策略是足够的。应当标识特定的TCB保护机制，而目.给出一种解释表示它们满

足该模型。应当表明描述性顶层规格说明是TCB接口的准确描述。文档应描述TCB怎样实施

基准监控器概念，并解释它为什么能防篡改，为什么不能被旁越，以及为什么它能被正确

地实现。TCB的实现（如硬件、固件和软件方式）应非形式化地表明与描述性顶层规格说明相

一致。应使用非形式化技术表明描述性顶层规格说明的要素与TCB单元相一致。文档应描述

如何构造TCB才便于测试和实施最小特权。该文档还应给出隐蔽信道分析的结果和与限定该

信道有关的折衷方案。应当标识可用来利用已知隐蔽存储信道的所有可审计事件。由于已知

隐蔽存储信道的使用不是用审计机制可检测的，所以应提供己知隐蔽存储信道的带宽，见

附录A（补充件）。

5.4A等：验证保护

本等级的特征是使用形式化安全验证方法，以保证系统采用的强制和自主安全控制能

有效地保护该系统存储或处理的保密或其它敏感信息。为了证明TCB满足设计、开发和实现

各方面的安全要求，需要扩展文件。该等分为A1和超A1两级。

5.4.1A1级：验证设计

A1级在功能上与B3级相同，不必增加任何关于策略或结构特性的要求。本等级佗显著

特点是用形式化顶层规范说明（FTLSO和验证技术来进行分析・，以确保TCB完全正确地实现。

实际上，由于这种保证是开始于安全策略的形式化模型和设计形式化顶层规格说明，所以

它是不断发展的。

在这里，无论使用何种特殊规格语言或验证系统，对该级的设计验证必须遵循以下五

条原则：

a.必须能对安全策略的形式化模型进行清晰地验证和文件化，包括要求用数学方法证

明模型与公理的一致性，模型对安全策略支持的有效性。

b.形式化顶层规格说明必须提出包括TCB完成功能的同象定义和用于支持隔离执行区

域的硬件或固件机制或硬件和固件机制的抽象定义。

c.如有验证工具，应使用形式化技术证明TCB的形式化顶层规格说明和模型的一致性,

否则可采用非形式化技术。

d.必须能用非形式化技术证明TCB的工具（如：硬件、固件和软件）与形式化顶层规格

说明的一致性。还能用非形式化技术证明形式化顶层规格说明的各要素对应于TCB的各单位。

形式化顶层规格说明必须能表示符合安全策略要求的统一的保护机制，而且TCB各单元的

映射正是保护机制的要素。

e.必须使用形式化分析技术去标识和分析隐蔽信道，非形式化技术可用于标识隐蔽定

时信道，在系统中，必须对被标识的隐蔽信道的连续存在加以说明。

为了配合A1级所要求的TCB扩展设计和开发分析，需要更严格的配置管理，并建立把

该级安全地分配到现场的过程。要支持系统安全管理员。

下述是A1级的最低要求

5.4.1.1安全策略

5.4.1.1.1自主访问控制

TCB应在计算机系统已命名的用户和已命