3.1 安全功能组件
CC第2部分给出了描述IT产品安全功能要求（SFR）的一个标准化安全功能组件目录。这个标准化安全功能组件列表用于以下用途。
（1）在PP/ST中描述TOE预期的安全行为。
（2）满足PP/ST中所列TOE的安全目的。
（3）规范用户通过TOE直接交付或促使TOE响应用户请求的可测试安全功能。
（4）应对在TOE预期运行环境中的各种威胁。
（5）覆盖在PP/ST中所有指定的组织安全策略。
3.1.1 功能组件结构
CC第2部分的安全功能组件可用于规范TOE的安全功能要求（SFR）。这些SFR可定义多个安全功能策略（SFP），以表达TOE必须执行的安全规则。每个这样的SFP必须通过定义主体、客体、资源或信息，及其适用的操作，来明确说明该安全功能策略的控制范围。IT产品的所有SFP均由TOE安全功能（TSF）实现，即TSF机制执行SFR中定义的规则并提供必要的TSF自身安全保护能力。
CC将IT产品的安全功能组织为一个分层功能结构（如图3.1所示）。
图3.1 安全功能类、族、组件和元素的层次关系
（1）类：由族组成。
（2）族：由组件组成。
（3）组件：由元素组成。
（4）元素：一个不可分割的基本功能要求。
GB/T 18336—2015第2部分共列出了11个类、65个族和136个安全功能组件。类、族、组件和元素间的层次关系如图3.1所示。组件由元素组成，构成了不能再分的最小安全要求集合，它是PP、ST、TOE或包安全功能要求选择的最小单位。在CC中，以“类_族．组件号”的方式标识组件，例如组件“FDP_DAU.1基本数据鉴别”，其中FDP指“用户数据保护”功能类，DAU指“数据鉴别”族。
CC中的安全功能类是用来描述一组共享共同关注点的安全要求集合。换句话说，类中所有族成员及其安全功能组件关注共同的安全目的。CC中的功能类安全目的是可知的，并且有一个结构化表格来描述组成类的族成员。表3.1列出了CC中11个安全功能类及其安全目的，其中前7个安全功能类与IT产品用户紧密相关，而后4个安全功能类是为确保IT产品自身安全的安全功能模块设置的。因此后4个安全功能类用于对TOE安全功能（TSF）模块自身安全性进行保证。CC给每个功能类都赋予一个长名和一个以F开头的3个字母的助记符短名标识。
表3.1 安全功能类
图3.2展示了CC安全功能类的结构，每个类包括类名、类介绍和一个或多个族成员。
注意，11个安全功能类彼此之间是并列关系，类之间不存在层次关系。因此，在CC第2部分定义的功能类是按照类的助记符短名字母进行排序的。
从图3.2安全功能类结构示意图可看出，类的成员是功能族。族是用来陈述一组共享安全目的但是安全关注点或安全精确度不一样的安全功能组件。在CC第2部分中，每个功能族都在类名下面被分配了一个方便记忆的3个字母的助记符，它和类助记符共同构成一个功能族短名。CC的安全功能族结构提供了标识和划分功能族所必需的分类和描述信息。每个功能族有一个唯一的名称，其标识信息由7个字符组成：前三个字符与类名助记符相同，后面跟一个下画线和3个字符组成的族名助记符。例如“FDP_DAU数据鉴别”，其中FDP指“用户数据保护”类，DAU指“数据鉴别”族。图3.3以框图形式展示了CC的功能族结构，其中族行为描述了功能族的安全目的，是对该族所有安全功能组件要求的概括描述。
图3.2 安全功能类结构示意
图3.3 安全功能族结构示意
图3.3族结构中的“族行为”部分描述可用的组件以及使用这些组件的基本原理（及组件满足的安全目的）。如果一个族成员（组件）存在层次关系或顺序，换句话说如果一个组件相对另一个组件提供更多的安全功能或安全保障能力，那么“组件层次”部分描述这些组件之间的层次关系，即一个组件相对另一个组件来说包含了更高级别的安全功能。有关操作安全管理活动和会被审计的安全事件建议在“管理”部分描述。如果PP/ST中包含来自FAU类“安全审计”中的要求，功能族中的“审计”部分包含了可供PP/ST作者选择的有关该安全功能组件的可审计事件。
图3.3的“组件”是一组安全要求的特殊集合，它由一系列元素构建而成。组件中的元素是一个不可分割的安全要求，它可通过第6章介绍的CEM中某个安全评估工作单元来验证。
每个组件都有一个有意义的长名，用以识别和描述该组件安全要求。CC第2部分给每个安全功能组件分配了一个包含了类助记符、族助记符和一个唯一的数字组成的短名。组件短名的标记结构如图3.4所示，每个组件可由一个或多个元素组成，每个功能元素名都有一个唯一的简化形式。图3.4以FDP_IFF.4.2组件元素为例列出了CC中的安全功能类、族、组件和元素的符号记法，各项意义为：F——功能要求；DP——“用户数据保护”类；_IFF——“信息流控制功能”族；.4——第4个组件；名为“部分消除非法信息流”；.2——该组件的第2个元素。如果一个组件有不止一个元素，那么在PP/ST编制中它们全部都要被使用，否则就必须为该PP/ST定义一个满足特定要求的扩展组件。
图3.4 功能类、族、组件和元素的标准符号记法
图3.5展示了CC第2部分的安全功能组件的结构。“组件标识”部分提供识别、分类、注册和交叉引用组件所必需的描述性信息。“依赖关系”列表提供了一个对其他功能和保障组件依赖关系的完整列表。所依赖的组件又可能依赖其他组件。组件依赖关系中提供的组件列表是直接的依赖关系，这只是为该功能要求能正确实现其功能提供参考。间接依赖关系，也就是由所依赖组件产生的依赖关系。功能组件依赖关系可参见CC第2部分的附录。注意有些组件可能列出“无依赖关系”。“功能元素”是该组件的一个安全功能要求，是一个再进一步划分将不会产生有意义评估结果的组件元素。因此组件元素是CC中标识和认可的最小安全功能要求，当构建包、PP/ST、TOE安全要求时，CC不允许TOE消费者和开发者从一个组件中只选择一个或几个组件元素，必须将组件的所有元素包含在PP、ST、TOE或包中。
图3.5 安全功能组件结构
用户可用CC第2部分的11个功能类描述IT产品常见的安全功能要求。当PP/ST编制人员选择安全功能组件去构建TOE的安全要求时，首先需确定合适的功能类。表3.2～表3.12按照功能类列出了CC第2部分定义的11种安全功能类相关的族及其组件列表。
3.1.2 安全审计功能组件
CC第2部分讨论的第一个安全功能类是安全审计（FAU）。该类由定义如何选择审计事件、产生审计数据、查阅和分析审计数据、对安全事件自动响应以及存储和保护审计数据等方面要求的功能族组成（如表3.2所示）。FAU族和组件的多样化为TSF描述提供了全方位的安全审计要求，提供了识别、记录、存储和分析那些与TOE安全行为有关事件的信息。另外，FAU族和组件也给出可用来对抗针对安全审计功能攻击的一些方式——权限误用以及绕过审计功能来阻止审计事件的获取等安全要求。
表3.2 FAU功能类：安全审计
3.1.3 通信功能组件
CC第2部分讨论的第二个安全功能类是通信（FCO）。如类名所示的那样，FCO安全功能从属于信息传输，特别关注如何确认在数据交换中参与方的身份、确认信息传输的原发者身份（原发证明）和信息传输的接收者身份（接收证明）。通信类有两个族用来确保原发者不能否认发送过信息，接收者也不能否认收到过信息。FCO安全功能类提供了两个族，原发抗抵赖（FCO_NRO）和接收抗抵赖（FCO_NRR），相关组件如表3.3所示，FCO族尤其关注这些安全功能凭据的生成。
表3.3 FCO功能类：通信
3.1.4 密码支持功能组件
密码支持（FCS）类是CC第2部分第三个被讨论的安全功能类。该类应用于IT产品的密码模块（硬件、软件和固件）的数据加密。如2.1节所说，CC并不声明哪些加密算法或密钥长度是可被接受的。取而代之的是，FCS类关注TOE的数据加解密操作和密钥管理——换句话说就是TOE加密功能的安全使用技术要求。每当需要使用生成或验证数字签名、加密或解密数据等安全功能时，就需要调用FCS组件和元素。同样地，FCS组件和元素也被调用来指定TOE整个生命周期内的密钥管理活动，如密钥生成、分发、存取、销毁和运算（如表3.4所示）。
表3.4 FCS功能类：密码支持
3.1.5 用户数据保护功能组件
用户数据保护（FDP）定义了TOE保护用户数据的各种安全要求。这些要求通过4组功能族（如表3.5所示）来描述在输入、输出和存储过程中的TOE内部用户数据保护，以及与用户数据保护直接相关的安全属性。
表3.5 FDP功能类：用户数据保护
本类中的4组功能族如下。
（1）用户数据安全保护策略，包括访问控制策略（FDP_ACC）和信息流控制策略（FDP_IFC）功能组件，以允许PP/ST作者命名用户数据保护安全功能策略，并定义该安全策略的控制范围，这对于说明安全目的是必要的。
（2）在不同类型的在线事务中保护用户数据完整性和一致性的安全功能，包括访问控制功能（FDP_ACF）、信息流控制功能（FDP_IFF）、TOE内部传送（FDP_ITT）、残余信息保护（FDP_RIP）、回退（FDP_ROL）和存储数据的完整性（FDP_SDI）等用户数据保护形式功能组件。
（3）在脱机事务中的用户数据保护功能，如离线导入（FDP_ITC）、导出（FDP_ETC）、数据鉴别（FDP_DAU）等数据转储安全功能。
（4）负责处理TSF与其他可信IT产品间的通信中的用户数据完整性和一致性的安全功能，如TSF间用户数据保密性传送保护（FDP_UCT）和TSF间用户数据完整性传送保护（FDP_UIT）。
3.1.6 用户标识与鉴别功能组件
CC第2部分讨论的第五个安全功能类是用户标识与鉴别（FIA）。正如名称预期，该安全功能类定义了执行和管理用户身份鉴别和认证功能的要求。授权用户的明确标识以及安全属性与用户和主体的正确绑定是实施预定安全策略的关键。本类中的安全功能族负责确认和验证使用TOE的用户身份、确认他们与TOE交互的权限、以及每个授权用户安全属性的正确绑定。CC中的其他安全功能类（如FDP“用户数据保护”、FAU“安全审计”）要求的有效性都是建立在对用户身份的正确标识和鉴别基础上的（如表3.6所示）。用户标识与鉴别确保潜在用户的正确身份都是确定的，无论是认证的或非认证的。用户认证确保用户的声明身份都是被验证的。相对于TOE，每个认证用户的访问控制能力及其授予的权限都应该是确定的。另外，用户认证都应该遵循一定的安全策略，例如在认证失败达到指定次数后TOE要采取的行为也应是定义的。
表3.6 FIA功能类：标识和鉴别
3.1.7 安全管理功能组件
安全管理（FMT）类指定了管理TOE安全功能和它们的属性和数据的要求，包括建立、撤销和终结安全属性的条件（如表3.7所示）。FMT要求TOE安全功能被调用以及被谁调用等管理规则应是确定的。安全管理人员职责分离和责任，以及安全管理人员与其他操作人员的职责和责任分享规则等也应是建立的。安全管理类主要有以下几个目的。
表3.7 FMT功能类：安全管理
（1）管理TSF数据。
（2）管理安全属性。
（3）管理TSF功能。
（4）定义安全角色。
3.1.8 隐私功能组件
隐私要求在CC第2部分的FPR类中指定。这些要求的目的是保护用户身份等个人信息不被泄露、误用或与TOE资源的使用相关联。如表3.8所示，隐私要求类由匿名、假名、不可关联性和不可观察性4个族组成。
表3.8 FPR功能类：隐私
3.1.9 TSF保护功能组件
TSF保护（FPT）类包含了保护TOE安全功能（TSF）和TOE安全功能数据（安全元数据）的要求。TOE依靠的底层硬件和操作系统等IT运行环境必须如预期一样执行，以确保TOE安全功能的正确运行。因此，FPT类中定义了验证TSF正确运行的安全要求，例如自检测、重放检测、响应TOE物理攻击等。如表3.9所示，FPT定义了TOE安全功能输出数据的一致性、完整性和有效性的要求，同样也定义了内部数据传输或复制数据的一致性、完整性和有效性要求。TOE安全功能的可信启动与恢复条件在该类中声明。检测和重播消息、生成可信时间戳、同步重要安全功能时间的机制等也在该类中指定。其他族确保TOE安全策略的要求总是被调用并强制执行。
表3.9 FPT功能类：TSF保护
3.1.10 资源利用功能组件
资源利用（FRU）类中的资源使用要求保证了TOE资源的有效性。本类提供3个族以支持所需资源的可用性，诸如处理能力或存储容量（如表3.10所示）。容错要求确保声明的TOE功能能够继续正确执行，即使是在经历了指定的失败状况下。FRU允许TOE安全功能被分配到与其他低优先级功能相关的资源使用优先级。另外，FRU要求允许资源在已知用户和主体间被分配，从而防止资源垄断和拒绝服务攻击。
表3.10 FRU功能类：资源利用
3.1.11 TOE访问功能组件
评估TOE访问控制功能的要求包含在FTA类中。该类定义了建立一个用户会话的6种类型的控制安全要求（如表3.11所示）。
表3.11 FTA功能类：TOE访问
（1）在一个给定会话中限制用户访问的安全属性范围。
（2）限制单独一个用户通过多个终端访问TOE的多个并行会话。
（3）锁定和解锁用户会话以响应指定控制规则或参数值要求。
（4）显示TOE资源使用的查询。
（5）显示一个用户的TOE访问历史，包含成功的和不成功的尝试。
（6）拒绝会话建立。
3.1.12 可信路径/信道功能组件
可信路径/信道（FTP）类定义了可信路径和可信信道的要求。若要建立和维护一个TOE安全功能和其他可信IT产品之间的安全通信信道，就需要使用可信信道要求。在某个应用中，用户或TOE安全功能数据可能需要被交换以执行重要安全功能，这就需要在它们之间建立一个可信信道。相反地，若需建立和维护用户与TOE安全功能之间的安全通信，就需要用到可信路径要求。对于可信信道和可信路径，通信双方都在该类中被指定，数据将被保护以防止在传输中被未鉴别的非法用户进行有意或无意的修改与泄露。通信可在可信信道或可信路径的任一端被初始化。表3.12给出了FTP类族及其安全组件列表。
表3.12 FTP功能类：可信路径/信道
