本标准等同采用国际标准ISO/IEC15408-2:1999《信息技术 安全技术 信息技术安全性评估准则 第2部分：安全功能要求》。 GB/T 18336.2-2001 信息技术 安全技术 信息技术安全性评估准则 第2部分：安全功能要求 GB/T18336.2-2001 标准下载解压密码：www.bzxz.net

ICS35.040
中华人民共和国国家标准
GB/T18336.2—2001
idt IS0/1EC 15408-2:1999
信息技术
，安全技术
信息技术安全性评估准则
第2部分：安全功能要求
Information technologySecurity techniques+Evaluation criteria for IT securityPart 2:Security functional requirements2001-03-08发布
国家质量技术监督局
2001-12-01实施
GB/T18336.2—2001
本标准等同采用国际标准ISO/EC15408-2.1999《信息技术安全技术
信息技术安全性评估准
第2部分：安全功能要求》。
本标准介绍了信息技术安全性评估的安全功能要求。GB/T18336在总标题《信息技术安全技术信息技术安全性评估准则》下，由以下几个部分组成：
第1部分：简介和一般模型
一第2部分：安全功能要求
一第3部分：安全保证要求Www.bzxZ.net
本标准的附录A到附录M是提示的附录。本标准由国家质量技术监督局提出。本标准由全国信息技术标准化技术委员会归口。本标准由中国国家信息安全测评认证中心、信息产业部电子第30研究所、国家信息中心、复旦大学负责起草。
本标准主要起草人：吴世忠、龚奇敏、陈晓桦、李守鹏、罗建中、方关宝、昊亚飞、雷利民、张建军、叶红、吴承荣、黄元飞、任卫红、崔玉华。本标准委托中国国家信息安全测评认证中心负责解释。I
GB/T18336.2—2001
ISO/IEC前言
ISO（国际标准化组织)和IEC（国际电工委员会）形成了全世界标准化的专门体系。作为ISO或IEC成员的国家机构，通过相应组织所建立的涉及技术活动特定领域的委员会参加国际标准的制定。ISO和IEC技术委员会在共同关心的领域里合作，其它与ISO和IEC有联系的政府和非政府的国际组织也参加了该项工作。
国际标准的起草符合ISO/IEC导则第3部分的原则。在信息技术领域，ISO和IEC已经建立了二个联合技术委员会一一ISO/IECJTC1。联合技术委员会采纳的国际标准草案分发给国家机构投票表决。作为国际标准公开发表，需要至少75%的国家机构投赞成票。
国际标准ISO/IEC15408-2是由联合技术委员会ISO/IECJTC1（信息技术）与通用准则项目发起组织合作产生的。与ISO/IEC15408-2同样的文本由通用准则项目发起组织作为《信息技术安全性评估通用准则》发表。有关通用准则项目的更多信息和发起组织的联系信息由ISO/IEC15408-1的附录A提供。
ISO/IEC15408在“信息技术一一安全技术一一信息技术安全性评估准则的总标题下，由以下几部分组成：
第1部分：简介和一般模型
第2部分：安全功能要求
第3部分：安全保证要求
ISO/IEC15408本部分的附录A到M仅供参考。以下具有法律效力的提示已按要求放置在ISO/IEC15408的所有部分：在ISO/IEC15408-1附录A中标明的七个政府组织（总称为通用准则发起组织），作为《信息技术安全性评估通用准则》第1至第3部分（称为CC”版权的共同所有者，在此特许ISO/IEC在开发ISO/IEC15408国际标准中，非排他性地使用CC。但是，通用准则发起组织在他们认为适当时保留对CC的使用、拷贝、分发以及修改的权利。1范围
中华人民共和国国家标准
信息技术安全技术
信息技术安全性评估准则
第2部分：安全功能要求
InformationtechnologySecuritytechniquesEvaluationcriteriaforIT securityPart 2Security functional requirementsGB/T18336.2—2001
idtIS0/IEC15408-2:1999
本标准定义的安全功能组件是保护轮廓(PP)或安全目标(ST)中所表述的TOEIT安全功能要求的基础。这些要求描述了对评估对象(TOE)所期望的安全行为，目的是满足PP或ST中陈述的安全目的。这些要求描述用户通过与TOE直接交互(即输入，输出)或通过TOE对刺激的反应，可以检测到的安全特性。
安全功能组件表达用于在假定的TOE运行环境中对抗威胁的要求，或涉及所有标识的组织安全策略和假设。
本标准的读者包括安全IT系统和产品的用户、开发者和评估员。GB/T18336第1部分第4章提供了关于本标准的目标读者，以及这些目标读者群使用本标准的附加信息。这些读者群可按如下形式使用本标准：
一用户，当选择组件来表达功能要求以满足PP或ST中的安全目的时，使用本标准。GB/T18336第1部分5.3条给出了有关安全目的和安全要求之间关系的详细信息。一开发者，针对实际或预期的用户安全要求建立TOE时，可以在本标准中找到理解这些安全需求的标准化方法。他们也可以将本标准的内容作为进一步定义符合这些要求的TOE安全功能和机制的基础。
一评估者，使用本标准中定义的功能要求，验证PP或ST中的TOE功能要求是否满足IT安全目的，并且应考虑所有依赖关系是否得到满足。评估者也应使用本标准内容来帮助确定给定TOE满足所陈述的要求。
1.1功能要求的扩展和维护
本标准及在此描述的相关安全功能要求，并不打算成为所有IT安全问题的确定答案，而是提供一组广为理解的安全功能要求，用于创建反映市场需求的可信产品或系统。这些安全功能要求的给出，体现当前要求规范和评估的技术发展水平。本标准不包括所有可能的安全功能要求，而是包含那些在发布时作者已知并认为有价值的那些要求。
因为用户的理解和需求可能会变化，因此需要维护本标准中的功能要求。PP/ST作者可能还有些安全要求未包含在本标准功能要求组件中。此时，PP/ST的作者可考虑使用不是来自本标准的功能要求（称之为可扩展性)，参见GB/T18336第1部分中的附录B和附录C。1.2本标准的结构
国家质量技术监督局2001-03-08批准2001-12-01实施
第1章是本标准的简介。
GB/T18336.2—2001
第2章介绍本标准功能组件的分类，第3章到第13章描述这些功能类。附录A为可能使用功能组件的用户提供感兴趣的附加信息，其中包括完整的功能组件间依赖关系的交叉参照表。
附录B至附录M提供功能类的应用注释。它们是本标准用户的参考资料库，可以帮助用户应用相关的操作并选择恰当的审计或文档信息。有关结构、规则和指南的信息，编写PP或ST的作者应参考GB/T18336第1部分第3章；第1部分第3章，定义本标准中使用的术语。第1部分附录B，定义PP的结构。第1部分附录C，定义ST的结构。1.3功能要求范例
本条描述本标准中安全功能要求所使用的范例。图1.1和图1.2描述了范例的一些关键概念。本条为这些图和图中没有的其他关键概念提供文字描述。所讨论的关键概念以粗斜体突出表示。本条并不打算替换或取代GB/T18336第1部分第3章标准术语表中的任何术语。评估对象(TOE)
个大用户！
远程 IT 产品
安伞晨件
安全展性
安全属性
TOE安全功能接口
TOL安全协能
(TSF）
执行TOE安全策略
客体/值高表
安全同性
TSF控制弱用
图1.1安全功能要求范例（单个TOE）安企属性
本标准是一个可为评估对象（TOE）规定安全功能要求的录。TOE是包含电子存储媒体（如磁盘）、外设（如打印机)和计算能力(如CPU时间)等资源的IT产品或系统(同时带有用户和管理员指南文档)，可用于处理和存储信息，是评估的对象。TOE评估主要关系到：确保对TOE资源执行了规定的TOE安全策略（TSP）。TSP定义了一些规则，通过这些规则TOE支配对其资源的访问，这样TOE就控制了所有信息和服务。而TSP又由多个安全功能策略（SFP）所构成。每一SFP有其控制范围，定义该SFP控制下的主体、客体和操作。SFP由安全功能(SF)实现，SF的机制执行该策略并提供必要的能力。2
本地用户
本可信IT产品
GB/T18336.2—2001
本地（TOE内）
可信酪径
TOE内部传送
TSF控制
外传送
TSF间
可信路径
选程用户
本地TOE
SF间传送
Rr:远程
还超可信[T产品
图1.2分布式TOE内的安全功能图为正确执行TSP而必须依赖的TOE中的那些部分，统称为TOE安全功能(TSF）。TSF包括实施安全所直接或间接依赖的TOE中的所有软件、硬件和固件。参照监视器是实施TOE的访问控制策略的抽象机。参照确认机制是参照监视器概念的实现，它具有以下特性：防篡改、一直运行、简单到能对其进行彻底的分析和测试。TSF可能包括一个参照确认机制或TOE运行所需要的其他安全功能。TOE可能是一个包含硬件、固件和软件的单个产品，也可能是一个分布式产品，内部包括多个单独的部分，每一部分都为TOE提供一个特别的服务，并且通过一个内部通信信道与TOE其他部分相连接。该信道可以与处理器总线一样小，也可能包含TOE的一个内部网络。当TOE由多个部分组成时，TOE的每一部分可拥有自已的TSF部分，此部分通过内部通信信道与TSF的其他部分交换用户数据和TSF数据。这种交互称为TOE内部传送。在这种情况下，这些TSF的分离部分抽象地形成一个复合的TSF来实施TSP。TOE接口可能限于特定的TOE使用，也可能允许通过外部通信信道与其他IT产品交互。这些与其他T产品的外部交互可以采取两种形式：a）“远程可信IT产品”的安全策略和本地TOE的TSP已在管理上进行了协调和评估。这种情况下的信息交换称为TSF间传送，如同它们是在不同可信产品的TSF之间。b）远程IT产品可能没有被评估，因此它的安全策略是未知的，如图1.2中所示的“不可信IT产品”。这种情况下的信息交换称为TSF控制外传送，如同在远程IT产品中没有TSF（或它的策略特性未知)。
可与TOE或在TOE中发生的并服从TSP规则的交互集合称为TSF控制范围（TSC)。TSC包括组根据主体、客体和TOE内的操作定义的交互集，但不必包括TOE的所有资源。组交互式（人机接口）或编程（应用编程接口）接口，通过它，TSF访问、调配TOE资源，或者从TSF中获取信息，称为TSF接口（TSFI)。TSFI定义了为执行TSP而提供的TOE功能的边界。3
GB/T18336.2—2001
用户在TOE的外部，因此也在TSC的外部。但为请求TOE执行服务，用户要通过TSFI和TOE交互。本标准安全功能要求关心两种用户：个人用户和外部IT实体。个人用户进一步分为本地个人用户，他们通过TOE设备（如工作站）直接与TOE交互，或远程个人用户，他们通过其他IT产品间接与TOE交互。
用户和TSF间的一段交互期称为用户会话。可以根据各种考虑来控制用户会话的建立，如：用户鉴别、时段、访问TOE的方法和每个用户允许的并发会话数。本标准使用术语“已授权”来表示用户具有执行某种操作所必需的权力或特权。因此术语“授权用户”表示允许用户执行TSP定义的操作。为表达需要管理员责任分离的要求，本标准相关的安全功能组件（来自子类FMT_SMR）明确说明要求管理性角色。角色是预先定义的一一组规则，这些规则建立起用户和TOE简所充许的交互。TOE可以支持定义任意数自的角色。例如，与TOE安全运行相关的角色可能包括“审计管理员”和用户帐号管理员”。
TOE包括可用于处理和存储信息的资源。TSF的主要目标是完全并正确地对TOE所控制的资源和信息执行TSP。
TOE资源能以多种方式结构化和利用。但是，本标准作出了特殊区分，以允许规定所期望的安全特性。所有由资源产生的实体能以两种方式中的一种来表征：实体可能是主动的，意指他们是TOE内部行为发生的原因，并导致对信息执行操作；实体也可能是被动的，意指他们是发出信息或存入信息的容器。
主动的实体称为主体。TOE内可能存在以下几种类型的主体：a）代表授权用户，遵从TSP所有规则的那些实体（例如：UNIX进程）；b）作为特定功能进程，可以轮流代表多个用户的那些实体（例如：在客户/服务器结构中可能找到的功能）；
c）作为TOE自身一部分的那些实体（例如：可信进程）。本标准所述的安全功能针对上述列出的各种主体执行TSP。被动实体（即信息存储器）在本标准中被称作“客体”。客体是可以由主体执行操作的对象。在一个主体(主动实体)是某个操作的对象（例如进程间通信)的情况下，该主体也可以作为客体。客体可以包含信息。在FDP类中说明信息流控制策略时，需要这个概念。用户、主体、信息和客体具有确定的属性，这些属性包括使TOE正确运转的信息。有些属性，可能只是提示性信息（即，增加TOE的用户友好性），如文件名，而另一些属性，可能专为执行TSP而存在，如访问控制信息，后面这些属性通常称为“安全属性”。在本标准中，属性一词将用作“安全属性”的简称，除非另有说明。但正如TSP规定的那样，无论属性信息的预期目的如何，对属性加以控制还是必要的。TOE中的数据分为用户数据和TSF数据，图1.3表明了这种关系。用户数据是存储在TOE资源中的信息，用户可以根据TSP对其进行操作，而TSF对它们并不附加任何特殊的意义。例如，电子邮件消息的内容是用户数据。TSF数据是在进行TSP决策时TSF使用的信息。如果TSP充许的话，TSF数据可以受用户的影响。安全属性、鉴别数据以及访问控制表都是TSF数据的例子。有几个用于数据保护的SFP，诸如访问控制SFP和信息流控制SFP。实现访问控制SFP的机制，是基于控制范围内的主体属性、客体属性和操作来决定建立他们的策略，这些属性用于控制主体可以对客体执行操作的规则集中。
实现信息流控制SFP的机制，是基于控制范围内的主体和信息的属性以及制约主体对信息操作的一组规则来决定他们的策略。信息的属性，可能与容器属性相关联（也可能没有关联，如多级数据库），在信息移动时与其相随。
TOE数据
用户致据
GB/T18336.2—2001
ST数据
鉴别致据
安全同性
用户期性
客体属性
主体底性
信息调性
图1.3用户数据和TSF数据的关系本标准涉及的两种特殊TSF数据，鉴别数据和秘密，可以是但不必一定是相同的。鉴别数据用于验证向TOE请求服务的用户声明的身份。最通用的鉴别数据形式是口令。口令要成为有效的安全机制，依赖于对其进行保密。但是，不是所有形式的鉴别数据都需要保密，生物测定学鉴别设备(例如，指纹阅读器、视网膜扫描仪)就不依赖于数据保密，因为这些数据只有一个用户拥有，其他人不能伪造。
本标准功能要求中用到的术语“秘密”，对鉴别数据适用，对其他为执行一特定SFP而必须保密的数据也同样适用。例如，依靠密码技术保护在信道中传送信息的保密性的可信信道机制，其强度应与用来保持密钥的秘密以防止未授权泄露的方法的强度相当。因此，不是所有的鉴别数据都需要保密；也不是所有的秘密都被用作鉴别数据。图1.4说明了秘密和鉴别数据间的关系。图中指出了常见的鉴别数据和秘密的数据类型。监别数据
生物测定学
图1.4“鉴别数据”和“秘密”的关系2引用标准
下列标准所包括的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。GB/T18336.1一2001信息技术安全技术信息技术安全性评估准则第1部分：简介和一般模型（idtISO/IEC15408-1：1999）3安全功能组件
3.1综述
本章定义本标准的功能要求的内容和形式，并为需要向ST中添加新组件的组织提供指南。功能要5
求以类、子类和组件来表达。
3.1.1类结构
GB/T18336.2—2001
图3.1以图表的形式阐明了功能类的结构。每个功能类包括一个类名、类介绍及一个或多个功能子类。
功能类
类介绍
3.1.1.1类名
A包括B和芯个C
功能类结构
功能了类
类名提供标识和化分功能类所必需的信息。每个功能类都有一个唯一的名称，类的分类信息由三个字符的简名组成。类的简名用于该类中的子类的简名规范中。3.1.1.2类介绍
类介绍描述这些子类满足安全目标的通用意图或方法。功能类的定义不反映要求规范中的任何正式分类法。
类介绍用图来描述类中的子类和每个子类中组件的层次结构，见3.2条的解释。3.1.2子类结构
图3.2以框图形式说明功能子类的结构。功能了炎
了类名
了类行为
组件次
图3.2功能子类结构
3.1.2.1子类名
子类名部分提供标识和化分功能子类所必需的分类和描述信息。每个功能子类有一个唯一的名称。子类的分类信息由七个字符的简名组成，开头三个字符与类名相同，后跟一个下划线和子类名，例如XXX_YYY。唯一的简短子类名为组件提供主要的引用名。3.1.2.2子类行为
子类行为是对功能子类的叙述性描述，陈述其安全目的，以及对功能要求的一般描述。以下是更详细的描述：
a）子类的安全目的阐述在包含该子类的一个组件的TOE的帮助下，可以解决的安全问题；6
GB/T18336.2——2001
b）功能要求的描述总结组件中包含的所有要求。该描述针对PP、ST和功能包的作者，他们希望评价该子类是否与他们的特定需求相关。3.1.2.3组件层次
功能子类包含一个或多个组件，任何一个组件都可被选择包括在PPST和功能包中。本条的目的是，一且子类被认为是用户安全要求的一个必要或有用的部分时，向用户提供选择恰当的功能组件的信息。
功能子类描述部分描述所用组件和它们的基本原理。组件的更多细节包含在每个组件中。功能子类内组件间的关系可能是也可能不是层次化的。如果一个组件相对另一个组件提供更多的安全，那么该组件对另一个组件来说是有层次的。如3.2条所述，子类的描述中提供了关于子类内组件层次结构的图示。3.1.2.4管理
管理要求包含PP/ST作者应考虑的作为给定组件的管理活动的信息。管理要求在管理类（FMT）的组件里详述。
PP/ST作者可以选择已指出的管理要求或者可以包括其他没有列出的管理要求。因而这些信息应认为是提示性的。
3.1.2.5审计
如果PP/ST中包含来自类FAU（安全审计)中的要求，则审计要求包含供PP/ST作者选择的可审计的事件。这些要求包括按FAU_GEN（安全审计数据产生）子类的组件所支持的以各种不同详细级别表示的安全相关事件。例如，一个审计记录可能包括下述行动：最小级一一安全机制的成功使用；基本级安全机制的成功使用以及所涉及到的安全属性的相关信息；详细级一一所有对机制配置的改变，包括改变前后的实际配置值。
显然可审计事件的分类是层次化的。例如，当期望“基本级审计产生”时，所有标识为最小级和基本级的可审计事件都应通过适当的赋值操作包括在PP/ST内，只是高级事件仅仅比低级事件提供更多的细节。当期望“详细级审计产生”时，所有标识为最小级、基本级和详细级的可审计事件都应包括在PP/ST内。
FAU类更详尽地解释了管理审计的规则。3.1.3组件结构
图3.3描绘功能组件的结构。
组件标识
功能元素
依赖关系
图3.3功能组件结构
3.1.3.1组件标识
组件标识提供标识、分类、注册和交叉引用组件时所必需的描述性信息。下列各项作为每个功能组件的部分：
个唯一一的名字，该名字反映了组件的目的。7
GB/T18336.2——2001
一个简名，即功能组件名的唯一简写形式。简名作为分类、注册和交叉引用组件的主要引用名。简名反映出组件所属的类和子类以及在子类中组件的编号。一个从属于表。这个组件所从属于的其他组件列表，以及该组件可用来满足与所列组件间的依赖关系。
3.1.3.2功能元素
为每一组件提供了一组元素。每个元素都分别定义并且是相互独立的。功能元素是一个安全功能要求，如果进一步划分将不会产生有意义的评估结果。它是GB/T18336中标识和认同的最小安全功能要求。当建立包、PP或ST时，不允许从一个组件中只选择一个或几个元素，必须选择组件的全部元素。每个功能元素名都有一个唯一的简化形式。例如，要求名FDP_IFF.4.2意义如下：F一一功能要求，DP一一“用户数据保护”类，_IFF一一“信息流控制功能”子类，4一一第四个组件，名为“部分消除非法信息流”，.2——该组件的第2个元素。3.1.3.3依赖关系
当一个组件本身不充分而要依赖手其他组件的功能，或依赖于与其他组件的交互才能正确发挥其功能时，就产生了功能组件间的依赖关系。每个功能组件都提供一个对其他功能和保证组件的完整的依赖关系表。有些组件可能列出“无依赖关系”。所依赖的组件又可能依赖其他组件，组件中提供的列表是直接的依赖关系。这只是为该功能要求能正确完成其功能提供参考。间接依赖关系，也就是由所依赖组件产生的依赖关系，见本标准附录A。值得注意的是，在某些情况下依赖关系可在提供的多个功能要求中选择，这些功能要求中的每一个都足以满足依赖关系(例如FDP_UIT.1)。依赖关系列表标识出，为满足与已标识组件相关的安全要求所必需的最少功能或保证组件。从属于已标识组件的那些组件也可用来满足依赖关系。本标准指明的依赖关系是规范的，在PP/ST中它们必须得到满足。在特定的情况下这种依赖关系可能不适用，只要PP/ST作者在基本原理中说清不适用的理由，就可以在包、PP和ST中不考虑依赖的组件。
3.1.4允许的功能组件操作
用于在PP，ST或功能包内定义要求的功能组件可以与本标准第4到第14章中说明的完全一样，也可以经裁剪以满足特定的安全目的。但是，选择和裁剪这些功能组件是复杂的，因为必须考虑所标识组件依赖关系。因此这种裁剪只限于一组允许的操作。每个功能组件都包括一个允许的操作列表。对所有功能组件，并非一切操作都是允许的。允许的操作选自：
一反复：采用不同的操作多次使用同一组件；一赋值：对指定参数的说明；
一选择：对列表中的一个或多个元素的说明；一细化：增加细节。
3.1.4.1反复
当需要覆盖同一要求的不同方面时（如，标识一个以上类型的用户），允许重复使用本标准的同一组件来覆盖每个方面。
3.1.4.2赋值
某些功能组件元素包含一些参数和变量，这些参数和变量使PP/ST作者可以指定PP或ST中包含的一个策略或一组值，以满足特定的安全目的。这些元素清楚地标识出每个参数及其可以分配给该参数的值。
元素任一方面的可接受值如能无歧义地描述和列举，就可用一个参数来表述。该参数可能是一个属8
GB/T18336.2-—2001
性或规则，它把要求限定为一个确定的值或值的范围。例如，根据指定的安全目的，功能组件元素可以规定一给定的操作应执行数次。在这种情况下，赋值应提供用于该参数中的次数或次数范围。3.1.4.3选择
这是为缩小一个组件元素的范围，从列表中选取一个或多个项目的操作。3.1.4.4细化
对所有功能组件元素来说，为满足安全目的，允许PP/ST作者通过增加细节来限定可接受的实现集。元素的细化由这些增加的技术细节来组成。在ST中，可能需要就TOE对术语“主体”和“客体”的含义作出有意义的解释，因此需要细化。像其他操作一样，细化不增加任何完全新的要求。根据安全目的，它对要求、规则、常量和条件施以详细阐述、解释或特别的含义。细化应只是进一步限定实现要求所可能接受的功能或机制集，而不是增加要求。细化不充许建立新要求，因此不会增加与组件相关的依赖关系列表。PP/ST作者必须注意，其他要求对该要求的依赖关系仍应得到满足。3.2组件分类
本标准中组件的分组不代表任何正式的分类法。本标准包括子类和组件的分类，它们是基于相关的功能和目的的粗略分组，按字母顺序给出。每个类的开头是一个提示性框图，指出该类的分类法、类中的子类和子类中的组件。这个图对指示可能存在于组件间的层次关系是有用的。在功能组件的描述中，有一段指出该组件和任何其他组件之间的依赖关系。在每个类中，都有一个与图3.4类似的描述子类层次关系的图。在图3.4中，第1个子类（子类1）包括了三个有从属关系的组件，其中组件2和组件3都可以用来满足对组件1的依赖关系。组件3从属于组件2，并且可以用来满足对组件2的依赖关系。类名
子类1
子类？
图3.4示范类分解图
在子类2中有三个组件，这三个组件不全都有从属关系。组件1和组件2不从属于其他组件。组件3从属于组件2，可以用来满足对组件2的依赖关系，但不能满足对组件1的依赖关系。在子类3中，组件2、3、4从属于组件1。组件2和3也都从属于组件1，但无可比性。组件4从属于组件2和3。
这些图的目的是补充子类中的文字说明，使关系的识别更容易。它们并不取代每个组件中的“从属于，”注释，这些注释是对每个组件从属关系的强制声明。3.2.1突出组件变化
子类中组件的关系约定以粗体字突出表示。粗体字约定所有新的要求用粗体表示。对于有从属关系的组件，当要求或依赖关系被增强或修改而超出前一组件的要求时，要用粗体字表示。另外，超出前一9
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。