操作系统安全技术要求

声明

本文是学习操作系统安全技术要求. 而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们

范围

本标准依据GB17859—1999的五个安全保护等级的划分，根据操作系统在信息系统中的作用，规定了操作系统安全所需要的各等级的安全技术要求。

本标准适用于按等级化要求设计和实现的、安装在计算机上的操作系统的开发、测试及选择。

规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB 17859—1999 计算机信息系统安全保护等级划分准则

GB/T 18336.3—2015 信息技术 安全技术 信息技术安全评估准则
第3部分：安全保障组件

GB/T 20271—2006 信息安全技术 信息系统通用安全技术要求

术语、定义和缩略语

术语和定义

GB 17859—1999、GB/T 20271—2006、GB/T
18336.3—2015界定的以及下列术语和定义适用于本文件。

操作系统 operating system

是管理和控制计算硬件与软件资源的程序，是计算设备中最基本的系统软件，任何其他软件都必须在操作系统的支持下才能运行。

操作系统安全 security of operating system

操作系统自身以及其所存储、传输和处理的信息的保密性、完整性和可用性。

操作系统安全子系统（SSOOS） security subsystem of operating system

操作系统中安全保护装置的总称，包括硬件、固件、软件和负责执行安全策略的组合体。

缩略语

下列缩略语适用于本文件：

SSOOS 操作系统安全子系统 （Security subsystem of operating system）

SSF SSOOS安全功能 （SSOOS security function）

SSP SSOOS安全策略 （SSOOS security policy）

安全技术要求

第一级：用户自主保护级

安全功能

身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。应从以下方面设计和实现SSOOS的身份鉴别功能：

a) 按以下要求设计和实现用户标识功能：

1. 用户进入操作系统前，先进行标识（建立账号）；

2. 操作系统用户标识一般使用用户名和用户标识符（UID）。

b) 按以下要求设计和实现用户鉴别功能：

1. 采用口令进行鉴别，并在每次用户登录系统时和系统重新连接时进行鉴别；

2. 口令是不可见的，在存储和传输时使用加密方法进行安全保护，确保其不被非授权的访问、修改和删除。

c) 通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定达到该值时采取的措施来实现鉴别失败的处理；

d) 对注册到操作系统的用户，将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。

自主访问控制

应从以下方面设计和实现SSOOS的自主访问控制功能：

a) 客体的拥有者对其拥有的全部客体有权修改其访问权限；

b) 客体的拥有者能对其拥有的客体定义其他用户的访问控制属性，访问控制属性至少包括：读、写、执行等；

c) 主体对客体的访问遵循该客体的自主访问控制权限属性；

d) 将访问控制客体的粒度控制在文件和目录。

数据完整性

对操作系统内部传输的用户数据（如进程间的通信），应提供保证用户数据完整性的功能。

网络安全保护

支持基于IP地址、端口、物理接口的双向网络访问控制，将不符合预先设定策略的数据包丢弃。

操作系统安全子系统自身安全保护

运行安全保护

应从以下方面实现SSF运行安全保护：

a) 提供一个设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前，对用户和管理员的安全策略属性进行定义；

b) 区分普通操作模式和系统维护模式；

c) 补丁的发布和使用：操作系统的开发者针对发现的漏洞及时发布补丁。操作系统的管理者及时运用补丁对操作系统的漏洞进行修补；

d) 在SSOOS失败或中断后，保护其以最小的损害得到恢复，并按照失败保护中所描述的内容，实现对SSF出现失败时的处理。

资源利用

1. 容错

应通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行。

2. 服务优先级

应采取适当的策略，设置主体使用SSF控制范围内某个资源子集的优先级，进行SSOOS资源的管理和分配。

3. 资源分配

应按GB/T
20271—2006资源分配中最大限额的要求，进行SSOOS资源的管理和分配。配额机制确保用户和主体将不会独占某种受控的资源。

用户登录访问控制

应从以下方面实现SSOOS的用户登录访问控制：

a) 按GB/T 20271—2006中会话建立机制的要求，对会话建立的管理进行设计；

b) 按GB/T
20271—2006中多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，SSF限制系统的并发会话的最大数量，并利用默认值作为会话次数的限定数；

c) 按GB/T
20271—2006中可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试，对用来建立会话的安全属性的范围进行限制。

安全策略配置

应对身份鉴别、网络安全保护、资源利用、用户登录访问控制提供安全策略配置功能。

安全保障要求

开发

1. 安全架构

开发者应提供产品安全功能的安全架构描述，安全架构描述应满足以下要求：

a) 与产品设计文档中对安全功能要求执行的抽象描述的级别一致；

b) 描述与安全功能要求一致的产品安全功能的安全域；

c) 描述产品安全功能初始化过程为何是安全的；

d) 证实产品安全功能能够防止被破坏；

e) 证实产品安全功能能够防止安全功能要求执行的功能被旁路。

1. 功能规范

开发者应提供完备的功能规范说明，功能规范说明应满足以下要求：

a) 完整描述产品的安全功能；

b) 描述所有安全功能接口的目的与使用方法；

c) 标识和描述每个安全功能接口相关的所有参数；

d) 描述安全功能接口相关的安全功能要求执行行为；

e) 描述由安全功能要求执行行为相关处理而引起的直接错误消息；

f) 证实安全功能要求到安全功能接口的追溯。

1. 产品设计

开发者应提供产品设计文档，产品设计文档应满足以下要求：

a) 根据子系统描述产品结构；

b) 标识产品安全功能的所有子系统；

c) 对每一个安全功能要求支撑或安全功能要求无关的安全功能子系统的行为进行足够详细的描述，以确定它不是安全功能要求执行；

d) 概括安全功能要求执行子系统的安全功能要求执行行为；

e) 描述安全功能要求执行子系统之间以及和其他安全功能子系统间的相互作用；

f) 提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口。

指导性文档

1. 操作用户指南

开发者应提供明确和合理的操作用户指南，操作用户指南与为评估而提供的其他所有文档保持一致，对每一种用户角色的描述应满足以下要求：

a) 描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；

b) 描述如何以安全的方式使用产品提供的可用接口；

c) 描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；

d) 明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；

e) 标识产品运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；

f) 充分实现安全目的所必须执行的安全策略。

1. 准备程序

开发者应提供产品及其准备程序，准备程序描述应满足以下要求：

a) 描述与开发者交付程序相一致的安全接收所交付产品必需的所有步骤；

b) 描述安全安装产品及其运行环境必需的所有步骤。

生命周期支持

1. 配置管理能力

开发者的配置管理能力应满足以下要求：

a) 为产品的不同版本提供唯一的标识；

b) 提供配置管理文档，配置管理文档描述用于唯一标识配置项的方法；

c) 配置管理系统唯一标识所有配置项。

1. 配置管理范围

开发者应提供产品配置项列表，并简要说明配置项的开发者。配置项列表应包含以下内容：

a) 产品、安全保障要求的评估证据和产品的组成部分；

b) 唯一标识配置项；

c) 对于每一个安全功能相关的配置项，配置项列表简要说明该配置项的开发者。

1. 交付程序

开发者应使用一定的交付程序交付产品，并将交付过程文档化。在给用户方交付产品的版本时，交付文档应描述为维护安全所必需的所有程序。

测试

2. 覆盖

开发者应提供测试覆盖文档，测试覆盖的证据应表明测试文档中的测试与功能规范中安全功能接口之间的对应性。

3. 功能测试

开发者应测试产品安全功能，将结果文档化并提供测试文档。测试文档应包括以下内容：

a) 测试计划：标识要执行的测试，并描述执行每个测试的方案，这些方案包括对于其它测试结果的任何顺序依赖性；

b) 预期的测试结果：表明测试成功后的预期输出；

c) 实际测试结果：和预期的测试结果一致；

d) 证实所有已知的漏洞被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，且没有引出新的漏洞。

1. 独立测试

开发者应提供一组与其自测安全功能时使用的同等资源，以用于安全功能的抽样测试。

2. 密码测试

开发者应对所使用的对称、非对称和杂凑密码算法进行正确性和一致性测试，确保实际运算结果与预期的正确结果相符。

开发者应确保使用符合国家密码相关规定的对称、非对称和杂凑密码算法。

脆弱性评定

基于已标识的潜在脆弱性，产品应抵抗具有基本攻击潜力的攻击者的攻击。

第二级：系统审计保护级

安全功能

身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。应从以下方面设计和实现SSOOS的身份鉴别功能：

a) 按以下要求设计和实现用户标识功能：

1. 用户进入操作系统前，先进行标识（建立账号）；

2. 操作系统用户标识使用用户名和用户标识（UID），并在操作系统的整个生存周期实现用户的唯一性标识，以及用户名或别名、UID等之间的一致性。

b) 按以下要求设计和实现用户鉴别功能：

1. 采用强化管理的口令鉴别/基于令牌的动态口令鉴别等机制进行身份鉴别， 并在每次用户登录系统时和系统重新连接时进行鉴别；

2. 鉴别信息是不可见的 ，在存储和传输时使用加密方法进行安全保护，确保其不被非授权的访问、修改和删除。

c) 通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定达到该值时采取的措施来实现鉴别失败的处理；

d) 对注册到操作系统的用户，将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。

自主访问控制

应从以下方面设计和实现SSOOS的自主访问控制功能：

a) 客体的拥有者能对其拥有的客体定义其他用户的访问控制属性，访问控制属性至少包括：读、写、执行等；

b) 主体对客体的访问遵循该客体的自主访问控制权限属性；

c) 当主体生成一个客体时，该客体具有该主体设置的自主访问控制权限属性的默认值；

d) 将访问控制客体的粒度控制在文件和目录；

e) 自主访问控制能与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成功的或不成功的访问，使用户对自己的行为承担明确的责任。

安全审计

应从以下方面设计和实现SSOOS的安全审计功能：

a) 能对以下事件生成审计日志：

1. 身份鉴别、自主访问控制等安全功能的使用；

2. 创建、删除客体的操作；

3. 网络会话；

4. 所有管理员的操作。

b) 在每个审计记录中至少记录下列信息：

1. 事件类型、事件发生的日期和时间、触发事件的用户、事件成功或失败等字段；

2. 身份标识和鉴别事件类审计日志还包括请求的源（如末端号或网络地址）；

3. 创建和删除客体的事件审计日志还包括客体的名字；

4. 网络会话事件还包括：网络程序名称、协议类型、源IP地址、目的IP地址、源端口、目的端口、会话总字节数等字段。

c) 提供以下审计日志分析功能：

1. 潜在侵害分析：设置审计日志累积或组合的规则，使用这些规则去监测已经生成的审计事件，并根据这些规则指示出对实施安全功能要求的潜在侵害。

d) 提供审计日志的可选择查询功能，支持按以下条件之一或逻辑组合进行选择和排序查阅，并能导出查询结果：

1. 事件类型；

2. 日期和/或时间；

3. 用户身份；

4. 客体名称；

5. 成功或失败。

e) 提供审计日志的保护功能，主要包括：

1. 保证审计机制默认处于开启状态，且对审计日志的开启和关闭进行保护；

2. 保护审计日志不被未授权的访问；

3. 保证审计日志不被篡改和删除。

f) 以便于用户理解的方式提供审计日志查阅；

g) 审计日志存储在掉电非遗失性存储介质中。系统管理员能够定义超过审计跟踪存储极限的阈值，当超过阈值时将向管理员报警。当审计存储空间被耗尽时，覆盖所存储的最早的审计记录。

数据完整性

应从以下方面设计和实现SSOOS的数据完整性保护功能：

a. 在对数据进行访问操作时，检查存储在存储介质上的用户数据是否出现完整性错误；

b. 在操作系统内部传输的用户数据，如进程间的通信，提供保证用户数据完整性的功能。

数据保密性

1. 数据加密

应从以下方面设计和实现SSOOS的数据加密功能：

a) 提供文件加密功能，用户可对指定的文件和目录进行加密保护 ；

b) 支持采用硬件形式对密钥进行保护。

网络安全保护

应从以下方面设计和实现SSOOS的网络安全保护：

a) 支持基于IP地址、端口、物理接口的双向网络访问控制，将不符合预先设定策略的数据包丢弃；

b) 对网络传输数据进行加密与完整性保护。

操作系统安全子系统自身安全保护

运行安全保护

应从以下方面实现SSF运行安全保护：

a) 提供设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前，对用户和管理员的安全策略属性进行定义；

b) 区分普通操作模式和系统维护模式；

c) 只允许系统管理员进入维护模式。在普通用户访问系统之前，系统以一个安全的方式进行安装和配置；

d) 对备份或不影响SSOOS的常规的系统维护，不要求所有的系统维护都在维护模式中执行；

e) 当操作系统安装完成后，在普通用户访问之前，系统配置好初始用户和管理员职责、根目录、审计参数、系统审计跟踪设置以及对文件和目录的合适的访问控制；

f) 只允许系统管理员修改或替换系统提供的实用程序；

g) 在SSOOS失败或中断后，确保其以最小的损害得到恢复。并按失败保护中所描述的内容，实现对SSF出现失败时的处理；

h) 控制和审计系统控制台的使用情况；

i) 补丁的发布、管理和使用：操作系统的开发者针对发现的漏洞及时发布补丁。操作系统的管理者及时获取、统一管理并及时运用补丁对操作系统的漏洞进行修补。

资源利用

1. 容错

应从以下方面实现SSOOS的容错功能：

a) 通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行，如系统检测和报告系统的服务水平已降低到预先规定的最小值；

b) 当系统资源的服务水平降低到预先规定的最小值时，能检测和发出报告；

c) 提供维护状态中运行的能力，在维护状态下各种安全功能全部失效，系统只允许由系统管理员使用。

1. 服务优先级

应从以下方面实现SSOOS的服务优先级功能：

a) 采取适当的策略，设置主体使用SSF控制范围内某个资源子集的优先级，进行SSOOS资源的管理和分配；

b) 确保对所有SSOOS资源的每次访问都基于主体所配得的优先级进行协调。

1. 资源分配

应从以下方面实现SSOOS的资源分配功能：

a) 按GB/T
20271—2006资源分配中最大限额的要求，进行SSOOS资源的管理和分配。配额机制确保用户和主体将不会独占某种受控的资源；

b) 确保在被授权的主体发出请求时，资源能被访问和利用；

c) 以每个用户或每个用户组为基础，提供一种机制，控制他们对磁盘的消耗和对CPU等资源的使用。

用户登录访问控制

应从以下方面实现操SSOOS的用户登录访问控制：

a) 按GB/T
20271—2006中会话建立机制的要求，对会话建立的管理进行设计。登录机制不允许鉴别机制本身被旁路；

b) 按GB/T
20271—2006中多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，SSF限制系统的并发会话的最大数量，并利用默认值作为会话次数的限定数；

c) 按GB/T
20271—2006中可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试
，对用来建立会话的安全属性的范围进行限制；

d) 成功登录系统后，SSOOS记录并向用户显示以下数据：

1. 日期、时间、来源和上次成功登录系统的情况；

2. 上次成功访问系统以来身份鉴别失败的情况；

3. 显示口令到期的天数；

4. 成功或不成功的事件次数的显示可以用整数计数、时间戳列表等表述方法。

可信度量

应从以下方面实现SSOOS的可信度量：

a) 在操作系统启动时进行完整性度量，确保操作系统内核的静态完整性。

b) 对可执行程序在启动时进行完整性度量，确保可执行程序的真实性和完整性；

c) 对完整性度量基准值进行安全存储，防止其被篡改，确保完整性度量基准值的自身完整性。

安全策略配置

应对身份鉴别、安全审计 、网络安全保护、资源利用、用户登录访问控制提供安全策略配置功能。

安全保障要求

开发

1. 安全架构

开发者应提供产品安全功能的安全架构描述，安全架构描述应满足以下要求：

a) 与产品设计文档中对安全功能要求执行的抽象描述的级别一致；

b) 描述与安全功能要求一致的产品安全功能的安全域；

c) 描述产品安全功能初始化过程为何是安全的；

d) 证实产品安全功能能够防止被破坏；

e) 证实产品安全功能能够防止安全功能要求执行的功能被旁路。

1. 功能规范

开发者应提供完备的功能规范说明，功能规范说明应满足以下要求：

a) 完全描述产品的安全功能；

b) 描述所有安全功能接口的目的与使用方法；

c) 标识和描述每个安全功能接口相关的所有参数；

d) 描述安全功能接口相关的安全功能要求执行行为；

e) 描述由安全功能接口调用相关的安全实施行为和异常而 引起的直接错误消息；

f) 描述与安全功能接口相关的安全功能要求支撑和无关的行为；

g) 证实安全功能要求到安全功能接口的追溯。

1. 产品设计

开发者应提供产品设计文档，产品设计文档应满足以下要求：

a) 根据子系统描述产品结构；

b) 标识产品安全功能的所有子系统；

c) 对每一个安全功能要求无关子系统的行为进行足够详细的描述，以确定它是安全功能要求无关；

d) 概括安全功能要求执行子系统的安全功能要求支撑和无关 行为；

e) 概括安全功能要求支撑子系统的行为；

f) 描述 安全功能要求执行子系统的安全功能要求执行行为；

g) 描述安全功能所有 子系统间的相互作用；

h) 提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口。

指导性文档

1. 操作用户指南

开发者应提供明确和合理的操作用户指南，操作用户指南与为评估而提供的其他所有文档保持一致，对每一种用户角色的描述应满足以下要求：

a) 描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；

b) 描述如何以安全的方式使用产品提供的可用接口；

c) 描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；

d) 明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；

e) 标识产品运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；

f) 充分实现安全目的所必须执行的安全策略。

1. 准备程序

开发者应提供产品及其准备程序，准备程序描述应满足以下要求：

a) 描述与开发者交付程序相一致的安全接收所交付产品必需的所有步骤；

b) 描述安全安装产品及其运行环境必需的所有步骤。

生命周期支持

1. 配置管理能力

开发者的配置管理能力应满足以下要求：

a) 为产品的不同版本提供唯一的标识；

b) 使用配置管理 系统对组成产品的所有配置项进行维护，并唯一标识配置项；

c) 提供配置管理文档，配置管理文档描述用于唯一标识配置项的方法；

d) 配置管理系统提供措施使得只能对配置项进行授权变更；

e) 配置管理文档包括一个配置管理计划，配置管理计划描述如何使用配置管理系统开发产品；

f) 实施的 配置管理与配置管理计划相一致。

1. 配置管理范围

开发者应提供产品配置项列表，并说明配置项的开发者。配置项列表应包含以下内容：

a) 产品、安全保障要求的评估证据和产品的组成部分和实现表示 ；

b) 唯一标识配置项；

c) 对于每一个安全功能相关的配置项，配置项列表简要说明该配置项的开发者。

1. 交付程序

开发者应使用一定的交付程序交付产品，并将交付过程文档化。在给用户方交付产品的各版本时，交付文档应描述为维护安全所必需的所有程序。

2. 开发安全

开发者应提供开发安全文档。开发安全文档应描述在产品的开发环境中，为保护产品设计和实现的保密性和完整性所必需的所有物理的、程序的、人员的和其他方面的安全措施。

3. 生命周期定义

开发者应建立一个生命周期模型对产品的开发和维护进行的必要控制，并提供生命周期定义文档描述用于开发和维护产品的模型。

测试

4. 覆盖

开发者应提供测试覆盖文档，测试覆盖描述应满足以下要求：

a) 证实测试文档中的测试与功能规范中安全功能接口之间的对应性；

b) 证实已经对功能规范中的所有安全功能接口都进行了测试。

1. 深度

开发者应提供测试深度的分析。测试深度分析描述应满足以下要求：

a) 证实测试文档中的测试与产品设计中的安全功能子系统之间的对应性；

b) 证实产品设计中的所有安全功能子系统都已经进行过测试。

1. 功能测试

开发者应测试产品安全功能，将结果文档化并提供测试文档。测试文档应包括以下内容：

a) 测试计划：标识要执行的测试，并描述执行每个测试的方案，这些方案包括对于其它测试结果的任何顺序依赖性；

b) 预期的测试结果：表明测试成功后的预期输出；

c) 实际测试结果：和预期的测试结果一致。

d) 证实所有已知的漏洞被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，且没有引出新的漏洞。

1. 独立测试

开发者应提供一组与其自测安全功能时使用的同等资源，以用于安全功能的抽样测试。

2. 密码测试

开发者应对所使用的对称、非对称和杂凑密码算法进行正确性和一致性测试，确保实际运算结果与预期的正确结果相符。

开发者应确保使用符合国家密码相关规定的对称、非对称和杂凑密码算法。

脆弱性评定

基于已标识的潜在脆弱性，产品应抵抗具有基本攻击潜力的攻击者的攻击。

第三级：安全标记保护级

安全功能

身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。应从以下方面设计和实现SSOOS的身份鉴别功能：

a. 按以下要求设计和实现用户标识功能：

1. 用户进入操作系统前，先进行标识（建立账号）；

2. 操作系统用户标识使用用户名和用户标识（UID），并在操作系统的整个生存周期实现用户的唯一性标识，以及用户名或别名、UID等之间的一致性。

a. 按以下要求设计和实现用户鉴别功能：

1. 采用强化管理的口令鉴别/基于令牌的动态口令鉴别/生物特征鉴别/数字证书鉴别等机制 进行身份鉴别，并在每次用户登录系统时和系统重新连接时进行鉴别；

2. 鉴别信息是不可见的，在存储和传输时使用加密方法进行安全保护，确保其不被非授权的访问、修改和删除。

a. 通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定达到该值时采取的措施来实现鉴别失败的处理；

b. 对注册到操作系统的用户，将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。

自主访问控制

应从以下方面设计和实现SSOOS的自主访问控制功能：

a) 客体的拥有者能对其拥有的客体定义其他用户的访问控制属性，访问控制属性至少包括：读、写、执行等；

b) 主体对客体的访问遵循该客体的自主访问控制权限属性；

c) 客体的拥有者能对其拥有的客体设置为：拥有者是唯一有权修改其访问权限的主体；

d) 不允许客体拥有者把客体的控制权分配给其他主体；

e) 当主体生成一个客体时，该客体具有该主体设置的自主访问控制权限属性的默认值；

f) 有更细粒度的自主访问控制，将访问控制主体的粒度控制在单个用户 ，将访问控制客体的粒度控制在文件和目录；

g) 自主访问控制能与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成功的或不成功的访问，使用户对自己的行为承担明确的责任。

标记和强制访问控制

应从以下方面设计和实现SSOOS的标记和强制访问控制功能：

a) 采用标记的方法为操作系统的指定主体和客体（例如：系统进程、文件、目录等）标明其安全属性；

b) 客体的标记随客体数据一起流动；

c) 主体和客体的安全属性标记构成了机密性和完整性安全策略模型。强制访问控制基于这些标记和安全策略模型，实现主体对客体读、写和执行等操作的访问控制；

d) 强制访问控制与用户身份鉴别、标记等安全功能密切配合，使系统对用户的安全控制包含从系统启动到退出系统的全过程，强制访问控制对客体的控制范围涉及操作系统内部的存储、处理和传输过程；

e) 由专门设置的系统安全员统一管理操作系统中与强制访问控制等安全机制有关的事件和信息，并将系统的常规管理、与安全有关的管理以及审计管理，分别由系统管理员、系统安全员和系统审计员来承担，按职能分割分别授予它们各自为完成自己所承担任务所需的权限，并形成相互制约关系；

f) 运行于网络环境的多台计算机系统上的网络操作系统，在需要进行统一管理时，考虑各台计算机操作系统的主、客体安全属性设置的一致性，并实现跨网络的SSOOS间用户数据保密性和完整性保护。

安全审计

应从以下方面设计和实现SSOOS的安全审计功能：

a) 能对以下事件生成审计日志：

1. 身份鉴别、自主访问控制、标记和强制访问控制 等安全功能的使用；

2. 创建、删除客体的操作；

3. 网络会话；

4. 所有管理员的操作。

b) 在每个审计记录中至少记录下列信息：

1. 事件类型、事件发生的日期和时间、触发事件的用户、事件成功或失败等字段；

2. 身份标识和鉴别事件类审计日志还包括请求的源（如末端号或网络地址）；

3. 创建和删除客体的事件审计日志还包括客体的名字、客体的安全属性 ；

4. 网络会话事件还包括：网络程序名称、协议类型、源IP地址、目的IP地址、源端口、目的端口、会话总字节数等字段。

c) 提供以下审计日志分析功能：

1. 潜在侵害分析：设置审计日志累积或组合的规则，使用这些规则去监测已经生成的审计事件，并根据这些规则指示出对实施安全功能要求的潜在侵害；

2. 基于模板的异常检测：根据用户的历史使用模式建立模板，用置疑等级表示用户当前活动与模板中已建立的使用模式不一致的程度，当用户的置疑等级超过门限条件时，能指出对安全功能要求实施的可能侵害即将发生。

d) 当检测到潜在的安全侵害时，生成实时报警；

e) 提供审计日志的可选择查询功能，支持按以下条件之一或逻辑组合进行选择和排序查阅，并能导出查询结果：

1. 事件类型；

2. 日期和/或时间；

3. 用户身份；

4. 客体名称；

5. 成功或失败。

f) 提供审计日志的保护功能，主要包括：

1. 保证审计机制默认处于开启状态，且对审计日志的开启和关闭进行保护；

2. 保护审计日志不被未授权的访问；

3. 保证审计日志不被篡改和删除**，并记录尝试篡改和删除审计日志的行为。**

g) 以便于用户理解的方式提供审计日志查阅；

h) 审计日志存储在掉电非遗失性存储介质中。系统管理员能够定义超过审计跟踪存储极限的阈值，当超过阈值时将向管理员报警。当审计存储空间被耗尽时，覆盖所存储的最早的审计记录。

数据完整性

应从以下方面设计和实现SSOOS的数据完整性保护功能：

a. 提供一个实用程序来校验文件系统和磁盘的完整性。此实用程序由操作系统自动执行；

b. 在对数据进行访问操作时，检查存储在存储介质上的用户数据是否出现完整性错误；

c. 在操作系统内部传输的用户数据，如进程间的通信，提供保证用户数据完整性的功能。

数据保密性

1. 客体重用

应对存储介质（至少包括：磁盘和内存等）从以下方面设计和实现SSOOS的客体重用功能：

a) 确保非授权用户不能查找使用后返还系统的记录介质中的信息内容；

b) 确保非授权用户不能查找系统现已分配给他的记录介质中以前的信息内容。

1. 数据加密

应从以下方面设计和实现SSOOS的数据加密功能：

a) 提供文件加密功能，用户可对指定的文件和目录进行加密保护；

b) 支持采用硬件形式对密钥进行保护；

c) 提供文件系统加密功能，对存储在文件系统加密中的文件和目录，进行透明加解密。

网络安全保护

应从以下方面设计和实现SSOOS的网络安全保护：

a) 支持基于IP地址、端口、物理接口和应用程序 的双向网络访问控制，将不符合预先设定策略的数据包丢弃；

b) 支持基于系统身份、系统运行状态双向网络可信接入认证；

c) 对网络访问进行控制，只有被授权的进程才能访问网络；

d) 对网络传输数据进行加密与完整性保护。

操作系统安全子系统自身安全保护

运行安全保护

应从以下方面实现SSF运行安全保护：

a) 提供设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前，对用户和管理员的安全策略属性进行定义；

b) 区分普通操作模式和系统维护模式；

c) 只允许系统管理员进入维护模式。在普通用户访问系统之前，系统以一个安全的方式进行安装和配置；

d) 对备份或不影响SSOOS的常规的系统维护，不要求所有的系统维护都在维护模式中执行；

e) 当操作系统安装完成后，在普通用户访问之前，系统配置好初始用户和管理员职责、根目录、审计参数、系统审计跟踪设置以及对文件和目录的合适的访问控制；

f) 只允许系统管理员修改或替换系统提供的实用程序；

g) 为操作系统安全管理人员提供一种机制，来产生安全参数值的详细报告；

h) 在SSOOS失败或中断后，确保其以最小的损害得到恢复。并按失败保护中所描述的内容，实现对SSF出现失败时的处理。系统因故障或其它原因中断后，有一种机制去恢复系统。系统提供在管理维护状态中运行的能力，管理维护状态只能被系统管理员使用，各种安全功能全部失效；

i) 控制和审计系统控制台的使用情况；

j) 补丁的发布、管理和使用：操作系统的开发者针对发现的漏洞及时发布补丁。操作系统的管理者及时获取、统一管理并及时运用补丁对操作系统的漏洞进行修补。

资源利用

1. 容错

应从以下方面实现SSOOS的容错功能：

a) 通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行，如系统检测和报告系统的服务水平已降低到预先规定的最小值；

b) 当系统资源的服务水平降低到预先规定的最小值时，能检测和发出报告；

c) 提供维护状态中运行的能力，在维护状态下各种安全功能全部失效，系统只允许由系统管理员使用；

d) 系统提供软件及数据备份和复原的过程，在系统中加入再启动的同步点，以便于系统的复原；

e) 系统提供能用于定期确认系统正确操作的机制和过程，这些机制或过程涉及系统资源的监视、硬件和固件单元的正确操作、对可能在全系统内传播的错误状态的检测以及超过用户规定的门限的通讯差错的检测等内容。

1. 服务优先级

应从以下方面实现SSOOS的服务优先级功能：

a) 采取适当的策略，设置主体使用SSF控制范围内某个资源子集的优先级，进行SSOOS资源的管理和分配；

b) 确保对所有SSOOS资源的每次访问都基于主体所配得的优先级进行协调。

1. 资源分配

应从以下方面实现SSOOS的资源分配功能：

a) 按GB/T
20271—2006资源分配中最大限额的要求，进行SSOOS资源的管理和分配。配额机制确保用户和主体将不会独占某种受控的资源；

b) 确保在被授权的主体发出请求时，资源能被访问和利用；

c) 以每个用户或每个用户组为基础，提供一种机制，控制他们对磁盘的消耗和对CPU等资源的使用；

d) 提供用户查看其可访问的系统资源的修改历史记录的权限。

用户登录访问控制

应从以下方面实现SSOOS的用户登录访问控制：

a. 按GB/T
20271—2006中会话建立机制的要求，对会话建立的管理进行设计。登录机制不允许鉴别机制本身被旁路；

b. 按GB/T
20271—2006中多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，SSF限制系统的并发会话的最大数量，并利用默认值作为会话次数的限定数；

c. 按GB/T
20271—2006中可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试
，对用来建立会话的安全属性的范围进行限制；

d. 成功登录系统后，SSOOS记录并向用户显示以下数据：

1. 日期、时间、来源和上次成功登录系统的情况；

2. 上次成功访问系统以来身份鉴别失败的情况；

3. 显示口令到期的天数；

4. 成功或不成功的事件次数的显示可以用整数计数、时间戳列表等表述方法。

a. 在规定的未使用时限后，系统断开会话或重新鉴别用户。系统提供时限的默认值；

b. 系统提供锁定用户键盘的机制，键盘开锁过程要求验证用户；

c. 当用户鉴别过程不正确的次数达到系统规定的次数时，系统退出登录过程并终止与用户的交互；

d. 系统提供一种机制，能按时间、进入方式、地点、网络地址或端口等条件规定哪些用户能进入系统。

可信度量

应从以下方面实现SSOOS的可信度量：

a) 支持硬件可信芯片作为信任根；

b) 在操作系统启动时进行完整性度量，确保操作系统内核的真实性和完整性；

c) 对可执行程序在启动时进行完整性度量，确保可执行程序的真实性和完整性；

d) 对完整性度量基准值进行可信 存储，防止其被篡改，确保完整性度量基准值的自身完整性。

安全策略配置

应对身份鉴别、标记和强制访问控制 、安全审计、网络安全保护、资源利用、用户登录访问控制提供安全策略配置功能。

安全保障要求

开发

1. 安全架构

开发者应提供产品安全功能的安全架构描述，安全架构描述应满足以下要求：

a) 与产品设计文档中对安全功能要求执行的抽象描述的级别一致；

b) 描述与安全功能要求一致的产品安全功能的安全域；

c) 描述产品安全功能初始化过程为何是安全的；

d) 证实产品安全功能能够防止被破坏；

e) 证实产品安全功能能够防止安全功能要求执行的功能被旁路。

1. 功能规范

开发者应提供完备的功能规范说明，功能规范说明应满足以下要求：

a) 完全描述产品的安全功能；

b) 描述所有安全功能接口的目的与使用方法；

c) 标识和描述每个安全功能接口相关的所有参数；

d) 描述安全功能实施过程中，与安全功能接口相关的所有 行为；

e) 证实安全功能要求到安全功能接口的追溯；

f) 描述可能由每个安全功能接口的调用而引起的所有直接错误消息。

1. 实现表示

开发者应提供全部安全功能的实现表示，实现表示应满足以下要求：

a) 按详细级别定义产品安全功能，详细程度达到无须进一步设计就能生成安全功能的程度；

b) 以开发人员使用的形式提供；

c) 提供产品设计描述与实现表示实例之间的映射，并证明其一致性。

1. 产品设计

开发者应提供产品设计文档，产品设计文档应满足以下要求：

a) 根据子系统描述产品结构；

b) 标识和描述 产品安全功能的所有子系统；

c) 描述安全功能所有子系统间的相互作用；

d) 提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口；

e) 根据模块描述安全功能；

f) 提供安全功能子系统到模块间的映射关系；

g) 描述所有安全功能需求执行模块，包括其目的及与其它模块间的相互作用；

h) 描述所有安全功能要求执行模块的安全功能要求相关接口、其它接口的返回值、与其它模块间的相互作用及调用的接口；

i) 描述所有安全功能要求的支撑或无关模块，包括其目的及与其它模块间的相互作用。

指导性文档

1. 操作用户指南

开发者应提供明确和合理的操作用户指南，操作用户指南与为评估而提供的其他所有文档保持一致，对每一种用户角色的描述应满足以下要求：

a) 描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；

b) 描述如何以安全的方式使用产品提供的可用接口；

c) 描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；

d) 明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；

e) 标识产品运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；

f) 充分实现安全目的所必须执行的安全策略。

1. 准备程序

开发者应提供产品及其准备程序，准备程序描述应满足以下要求：

a) 描述与开发者交付程序相一致的安全接收所交付产品必需的所有步骤；

b) 描述安全安装产品及其运行环境必需的所有步骤。

生命周期支持

1. 配置管理能力

开发者的配置管理能力应满足以下要求：

a) 为产品的不同版本提供唯一的标识；

b) 使用配置管理系统对组成产品的所有配置项进行维护，并唯一标识配置项；

c) 提供配置管理文档，配置管理文档描述用于唯一标识配置项的方法；

d) 提供自动化的 措施使得只能对配置项进行授权变更；

e) 配置管理系统提供一种自动方式来支持产品的生产 ；

f) 配置管理文档包括一个配置管理计划，配置管理计划描述如何使用配置管理系统开发产品；

g) 实施的配置管理与配置管理计划相一致；

h) 配置管理计划描述用来接受修改过的或新建的作为产品组成部分的配置项的程序。

1. 配置管理范围

开发者应提供产品配置项列表，并说明配置项的开发者。配置项列表应包含以下内容：

a) 产品、安全保障要求的评估证据和产品的组成部分和实现表示、安全缺陷报告及其解决状态 ；

b) 唯一标识配置项；

c) 对于每一个安全功能相关的配置项，配置项列表简要说明该配置项的开发者。

1. 交付程序

开发者应使用一定的交付程序交付产品，并将交付过程文档化。在给用户方交付产品的各版本时，交付文档应描述为维护安全所必需的所有程序。

2. 开发安全

开发者应提供开发安全文档。开发安全文档应描述在产品的开发环境中，为保护产品设计和实现的保密性和完整性所必需的所有物理的、程序的、人员的和其他方面的安全措施。

3. 生命周期定义

开发者应建立一个生命周期模型对产品的开发和维护进行的必要控制，并提供生命周期定义文档描述用于开发和维护产品的模型。

4. 工具和技术

开发者应明确定义用于开发产品的工具，并提供开发工具文档无歧义地定义所有语句和实现用到的所有协定与命令的含义，无歧义地定义所有实现依赖选项的含义。

测试

5. 覆盖

开发者应提供测试覆盖文档，测试覆盖描述应满足以下要求：

a) 证实测试文档中的测试与功能规范中安全功能接口之间的对应性；

b) 证实已经对功能规范中的所有安全功能接口都进行了测试。

1. 深度

开发者应提供测试深度的分析。测试深度分析描述应满足以下要求：

a) 证实测试文档中的测试与产品设计中的安全功能子系统和安全功能要求执行模块 之间的对应性；

b) 证实产品设计中的所有安全功能子系统和安全功能要求执行模块 都已经进行过测试。

1. 功能测试

开发者应测试产品安全功能，将结果文档化并提供测试文档。测试文档应包括以下内容：

a) 测试计划：标识要执行的测试，并描述执行每个测试的方案，这些方案包括对于其它测试结果的任何顺序依赖性；

b) 预期的测试结果：表明测试成功后的预期输出；

c) 实际测试结果：和预期的测试结果一致。

d) 证实所有已知的漏洞被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，且没有引出新的漏洞。

1. 独立测试

开发者应提供一组与其自测安全功能时使用的同等资源，以用于安全功能的抽样测试。

2. 密码测试

开发者应对所使用的对称、非对称和杂凑密码算法进行正确性和一致性测试，确保实际运算结果与预期的正确结果相符。

开发者应确保使用符合国家密码相关规定的对称、非对称和杂凑密码算法。

3. 代码安全性测试

开发者应对安全功能实现表示和产品内核代码进行安全性测试，证实代码中不包含潜在的安全缺陷或后门。

脆弱性评定

基于已标识的潜在脆弱性，产品应抵抗具有增强型 基本攻击潜力的攻击者的攻击。

注：
抵抗增强型基本攻击潜力的攻击者的攻击，需要综合考虑根据以下5个具体因素：攻击时间、攻击者能力、对产品的了解程度、访问产品时间或攻击样品数量、使用的攻击设备，详见GB/T
30270—2013中的附录A.8。

第四级：结构化保护级

安全功能

身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。应从以下方面设计和实现SSOOS的身份鉴别功能：

a. 按以下要求设计和实现用户标识功能：

1. 用户进入操作系统前，先进行标识（建立账号）；

2. 操作系统用户标识使用用户名和用户标识（UID），并在操作系统的整个生存周期实现用户的唯一性标识，以及用户名或别名、UID等之间的一致性。

b. 按以下要求设计和实现用户鉴别功能：

1. 采用强化口令管理和/或生物特征鉴别和/或数字证书等相结合的方式，采用多鉴别机制， 实现对用户身份的真实性鉴别，并在每次用户登录系统时和系统重新连接时进行鉴别；

2. 鉴别信息是不可见的，在存储和传输时使用加密方法进行安全保护，确保其不被非授权的访问、修改和删除。

a. 通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定达到该值时采取的措施来实现鉴别失败的处理；

b. 对注册到操作系统的用户，将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。

自主访问控制

应从以下方面设计和实现SSOOS的自主访问控制功能：

a) 客体的拥有者能对其拥有的客体定义其他用户的访问控制属性，访问控制属性至少包括：读、写、执行等；

b) 主体对客体的访问遵循该客体的自主访问控制权限属性；

c) 客体的拥有者能对其拥有的客体设置为：拥有者是唯一有权修改其访问权限的主体；

d) 不允许客体拥有者把客体的控制权分配给其他主体；

e) 当主体生成一个客体时，该客体具有该主体设置的自主访问控制权限属性的默认值；

f) 有更细粒度的自主访问控制，将访问控制主体的粒度控制在单个用户，将访问控制客体的粒度控制在文件和目录；

g) 自主访问控制能与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成功的或不成功的访问，使用户对自己的行为承担明确的责任。

标记和强制访问控制

应从以下方面设计和实现SSOOS的标记和强制访问控制功能：

a) 采用标记的方法为操作系统所有主体和客体 （至少包括系统所有进程、文件、目录等）标明其安全属性；

b) 客体的标记随客体数据一起流动，当信息从操作系统控制范围之内向控制范围之外输出时，带有安全标记，当信息从操作系统控制范围之外向控制范围之内输入时，通过标记标明其安全属性。如打印输出的数据，需明显标示出该数据的安全标记；

c) 主体和客体的安全属性标记构成了机密性和完整性安全策略模型，这些安全策略模型具有相应的半形式化证明。 强制访问控制基于这些标记和安全策略模型，实现主体对客体读、写和执行等操作的访问控制；

d) 强制访问控制与用户身份鉴别、标记等安全功能密切配合，使系统对用户的安全控制包含从系统启动到退出系统的全过程，强制访问控制对客体的控制范围涉及操作系统内部的存储、处理和传输过程，及信息进行输入、输出操作的过程 ；

e) 由专门设置的系统安全员统一管理操作系统中与强制访问控制等安全机制有关的事件和信息，并将系统的常规管理、与安全有关的管理以及审计管理，分别由系统管理员、系统安全员和系统审计员来承担，按职能分割和最小授权原则 分别授予它们各自为完成自己所承担任务所需的最小权限，并形成相互制约关系；

f) 运行于网络环境的多台计算机系统上的网络操作系统，在需要进行统一管理时，考虑各台计算机操作系统的主、客体安全属性设置的一致性，并实现跨网络的SSOOS间用户数据保密性和完整性保护。

安全审计

应从以下方面设计和实现SSOOS的安全审计功能：

a) 能对以下事件生成审计日志：

1. 身份鉴别、自主访问控制、标记和强制访问控制等安全功能的使用；

2. 创建、删除客体的操作；

3. 网络会话；

4. 所有管理员的操作。

b) 在每个审计记录中至少记录下列信息：

1. 事件类型、事件发生的日期和时间、触发事件的用户、事件成功或失败等字段；

2. 身份标识和鉴别事件类审计日志还包括请求的源（如末端号或网络地址）；

3. 创建和删除客体的事件审计日志还包括客体的名字、客体的安全属性；

4. 网络会话事件还包括：网络程序名称、协议类型、源IP地址、目的IP地址、源端口、目的端口、会话总字节数等字段。

c) 提供以下审计日志分析功能：

1. 潜在侵害分析：设置审计日志累积或组合的规则，使用这些规则去监测已经生成的审计事件，并根据这些规则指示出对实施安全功能要求的潜在侵害；

2. 基于模板的异常检测：根据用户的历史使用模式建立模板，用置疑等级表示用户当前活动与模板中已建立的使用模式不一致的程度，当用户的置疑等级超过门限条件时，能指出对安全功能要求实施的可能侵害即将发生；

3. 简单攻击探测：当发现一个系统事件与一个预示可能潜在违反安全功能要求实施的特征事件匹配时，能指出潜在违反安全功能要求实施的事件即将发生。

d) 当检测到潜在的安全侵害时，生成实时报警**，并终止违例进程** ；

e) 提供审计日志的可选择查询功能，支持按以下条件之一或逻辑组合进行选择和排序查阅，并能导出查询结果：

1. 事件类型；

2. 日期和/或时间；

3. 用户身份；

4. 客体名称；

5. 成功或失败。

f) 提供审计日志的保护功能，主要包括：

1. 保证审计机制默认处于开启状态，且对审计日志的开启和关闭进行保护；

2. 保护审计日志不被未授权的访问；

3. 保证审计日志不被篡改和删除，并记录尝试篡改和删除审计日志的行为。

g) 以便于用户理解的方式提供审计日志查阅；

h) 审计日志存储在掉电非遗失性存储介质中。系统管理员能够定义超过审计跟踪存储极限的阈值，当超过阈值时将向管理员报警。当审计存储空间被耗尽时，覆盖所存储的最早的审计记录。

数据完整性

应从以下方面设计和实现SSOOS的数据完整性保护功能：

a. 提供一个实用程序来校验文件系统和磁盘的完整性。此实用程序由操作系统自动执行；

b. 在对数据进行访问操作时进行完整性检测和恢复，检查存储在存储介质上的用户数据是否出现完整性错误**，并在检测到完整性错误时进行恢复** ；

c. 在操作系统内部进行的数据传输，如进程间的通信，提供保证数据完整性的功能 。

数据保密性

1. 客体重用

应对存储介质（至少包括：磁盘和内存等）从以下方面设计和实现SSOOS的客体重用功能：

a) 确保非授权用户不能查找使用后返还系统的记录介质中的信息内容；

b) 确保非授权用户不能查找系统现已分配给他的记录介质中以前的信息内容。

1. 数据加密

应从以下方面设计和实现SSOOS的数据加密功能：

a) 提供文件加密功能，用户可对指定的文件和目录进行加密保护；

b) 提供文件系统加密功能，对存储在文件系统加密中的文件和目录，进行透明加解密；

c) 对密钥提供基于硬件信任根的可信存储支持。

可信路径

在本地用户和远程用户进行初始登录和/或鉴别时，SSOOS应在它与用户之间建立一条安全的通信路径。此路径对其端点进行了可信标识，并能保护通信数据免遭修改、泄露。

可信信道

应在SSOOS和另一个可信IT产品之间提供一条通信信道，此信道在逻辑上与其他通信信道截然不同，并对其端点进行了可信标识，并能保护信道中数据免遭修改或泄露。

网络安全保护

应从以下方面设计和实现SSOOS的网络安全保护：

a) 支持基于IP地址、端口、物理接口和应用程序的双向网络访问控制，将不符合预先设定策略的数据包丢弃；

b) 支持基于系统身份、系统运行状态双向网络可信接入认证；

c) 对网络访问进行控制，只有被授权的且通过可信度量 的进程才能访问网络；

d) 对网络传输数据进行加密与完整性保护。

操作系统安全子系统自身安全保护

运行安全保护

应从以下方面实现SSF运行安全保护：

a) 提供设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前，对用户和管理员的安全策略属性进行定义；

b) 区分普通操作模式和系统维护模式；

c) 只允许系统管理员进入维护模式。在普通用户访问系统之前，系统以一个安全的方式进行安装和配置；

d) 对备份或不影响SSOOS的常规的系统维护，不要求所有的系统维护都在维护模式中执行；

e) 当操作系统安装完成后，在普通用户访问之前，系统配置好初始用户和管理员职责、根目录、审计参数、系统审计跟踪设置以及对文件和目录的合适的访问控制；

f) 只允许系统管理员修改或替换系统提供的实用程序；

g) 为操作系统安全管理人员提供一种机制，来产生安全参数值的详细报告；

h) 在SSOOS失败或中断后，确保其以最小的损害得到恢复。并按失败保护中所描述的内容，实现对SSF出现失败时的处理。系统因故障或其它原因中断后，有一种机制去恢复系统。系统提供在管理维护状态中运行的能力，管理维护状态只能被系统管理员使用，各种安全功能全部失效；

i) 控制和审计系统控制台的使用情况；

j) 补丁的发布、管理和使用：操作系统的开发者针对发现的漏洞及时发布补丁。操作系统的管理者及时获取、统一管理并及时运用补丁对操作系统的漏洞进行修补。

资源利用

1. 容错

应从以下方面实现SSOOS的容错功能：

a) 通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行，如系统检测和报告系统的服务水平已降低到预先规定的最小值；

b) 当系统资源的服务水平降低到预先规定的最小值时，能检测和发出报告；

c) 提供维护状态中运行的能力，在维护状态下各种安全功能全部失效，系统只允许由系统管理员使用；

d) 系统提供软件及数据备份和复原的过程，在系统中加入再启动的同步点，以便于系统的复原；

e) 系统提供能用于定期确认系统正确操作的机制和过程，这些机制或过程涉及系统资源的监视、硬件和固件单元的正确操作、对可能在全系统内传播的错误状态的检测以及超过用户规定的门限的通讯差错的检测等内容。

1. 服务优先级

应从以下方面实现SSOOS的服务优先级功能：

a) 采取适当的策略，设置主体使用SSF控制范围内某个资源子集的优先级，进行SSOOS资源的管理和分配；

b) 确保对所有SSOOS资源的每次访问都基于主体所配得的优先级进行协调。

1. 资源分配

应从以下方面实现SSOOS的资源分配功能：

a) 按GB/T
20271—2006资源分配中最大限额的要求，进行SSOOS资源的管理和分配。配额机制确保用户和主体将不会独占某种受控的资源；

b) 确保在被授权的主体发出请求时，资源能被访问和利用；

c) 以每个用户或每个用户组为基础，提供一种机制，控制他们对磁盘的消耗和对CPU等资源的使用；

d) 提供用户查看其可访问的系统资源的修改历史记录的权限。

用户登录访问控制

应从以下方面实现SSOOS的用户登录访问控制：

a. 按GB/T
20271—2006中会话建立机制的要求，对会话建立的管理进行设计。登录机制不允许鉴别机制本身被旁路；

b. 按GB/T
20271—2006中多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，SSF限制系统的并发会话的最大数量，并利用默认值作为会话次数的限定数；

c. 按GB/T
20271—2006中可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试
，对用来建立会话的安全属性的范围进行限制；

d. 成功登录系统后，SSOOS记录并向用户显示以下数据：

1. 日期、时间、来源和上次成功登录系统的情况；

2. 上次成功访问系统以来身份鉴别失败的情况；

3. 显示口令到期的天数；

4. 成功或不成功的事件次数的显示可以用整数计数、时间戳列表等表述方法。

a. 在规定的未使用时限后，系统断开会话或重新鉴别用户。系统提供时限的默认值；

b. 系统提供锁定用户键盘的机制，键盘开锁过程要求验证用户；

c. 当用户鉴别过程不正确的次数达到系统规定的次数时，系统退出登录过程并终止与用户的交互；

d. 系统提供一种机制，能按时间、进入方式、地点、网络地址或端口等条件规定哪些用户能进入系统。

可信度量

应从以下方面实现SSOOS的可信度量：

a) 支持硬件可信芯片作为信任根；

b) 在操作系统启动时进行完整性度量，确保操作系统内核的真实性和完整性；

c) 对可执行程序在启动时进行完整性度量，确保可执行程序的真实性和完整性；

d) 对完整性度量基准值进行可信存储，防止其被篡改，确保完整性度量基准值的自身完整性。

可信恢复

当系统失效或服务中断时，应确保SSOOS能够自动恢复到安全运行状态。

安全策略配置

应对身份鉴别、标记和强制访问控制、安全审计、网络安全保护、资源利用、用户登录访问控制提供安全策略配置功能。

安全保障要求

开发

1. 安全架构

开发者应提供产品安全功能的安全架构描述，安全架构描述应满足以下要求：

a) 与产品设计文档中对安全功能要求执行的抽象描述的级别一致；

b) 描述与安全功能要求一致的产品安全功能的安全域；

c) 描述产品安全功能初始化过程为何是安全的；

d) 证实产品安全功能能够防止被破坏；

e) 证实产品安全功能能够防止安全功能要求执行的功能被旁路。

1. 功能规范

开发者应提供完备的功能规范说明，功能规范说明应满足以下要求：

a) 完全描述产品的安全功能；

b) 使用半形式化方式描述安全功能接口；

c) 描述所有安全功能接口的目的与使用方法；

d) 标识和描述每个安全功能接口相关的所有参数；

e) 描述每个安全功能接口相关的所有行为；

f) 描述可能由每个安全功能接口的调用而引起的所有直接错误消息；

g) 描述不是由安全功能接口调用而引起的所有错误消息；

h) 为每个包含在安全功能实现中但不是由安全功能接口调用而引起的错误消息提供基本原理；

i) 证实安全功能要求到安全功能接口的追溯。

1. 实现表示

开发者应提供全部安全功能的实现表示，实现表示应满足以下要求：

a) 按详细级别定义产品安全功能，详细程度达到无须进一步设计就能生成安全功能的程度；

d) 以开发人员使用的形式提供；

e) 提供产品设计描述与实现表示实例之间的映射，并证明其一致性。

1. TSF内部

开发者应提供TSF内部结构的描述和论证过程文档，TSF内部应满足以下要求：

a) 论证过程描述用于判定"结构合理"的含义的特性；

f) TSF内部结构描述证实指定的整个TSF结构合理。

1. 产品设计

开发者应提供产品设计文档，产品设计文档应满足以下要求：

a) 根据子系统描述产品结构；

b) 根据模块描述安全功能，以安全功能要求执行、支撑或无关标出每一个模块 ；

c) 标识产品安全功能的所有子系统；

d) 提供每一个安全功能子系统的半形式化描述 ，适当时配以非形式化的、解释性的描述；

e) 描述安全功能所有子系统间的相互作用；

f) 提供安全功能子系统到模块间的映射关系；

g) 描述所有安全功能要求执行**、支撑** 和无关模块，包括其目的及与其它模块间的相互作用；

h) 提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口；

i) 描述所有安全功能要求执行和支撑 模块模块的安全功能要求相关接口、其它接口的返回值、与其它模块间的相互作用及调用的接口；

j) 描述所有安全功能的支撑或相关模块，包括其目的及与其它模块间的相互作用。

指导性文档

1. 操作用户指南

开发者应提供明确和合理的操作用户指南，操作用户指南与为评估而提供的其他所有文档保持一致，对每一种用户角色的描述应满足以下要求：

a) 描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；

b) 描述如何以安全的方式使用产品提供的可用接口；

c) 描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；

d) 明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；

e) 标识产品运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；

f) 充分实现安全目的所必须执行的安全策略。

1. 准备程序

开发者应提供产品及其准备程序，准备程序描述应满足以下要求：

a) 描述与开发者交付程序相一致的安全接收所交付产品必需的所有步骤；

b) 描述安全安装产品及其运行环境必需的所有步骤。

生命周期支持

1. 配置管理能力

开发者的配置管理能力应满足以下要求：

a) 为产品的不同版本提供唯一的标识；

b) 使用配置管理系统对组成产品的所有配置项进行维护，并唯一标识配置项；

c) 提供配置管理文档，配置管理文档描述用于唯一标识配置项的方法；

d) 提供自动化的措施使得只能对配置项进行授权变更；

e) 配置管理系统提供一种自动方式来支持产品的生产；

f) 配置管理文档包括一个配置管理计划，配置管理计划描述如何使用配置管理系统开发产品；

g) 实施的配置管理与配置管理计划相一致；

h) 配置管理计划描述用来接受修改过的或新建的作为产品组成部分的配置项的程序。

1. 配置管理范围

开发者应提供产品配置项列表，并说明配置项的开发者。配置项列表应包含以下内容：

a) 产品、安全保障要求的评估证据和产品的组成部分和实现表示、安全缺陷报告及其解决状态、开发工具及其相关信息 ；

b) 唯一标识配置项；

c) 对于每一个安全功能相关的配置项，配置项列表简要说明该配置项的开发者。

1. 交付程序

开发者应使用一定的交付程序交付产品，并将交付过程文档化。在给用户方交付产品的各版本时，交付文档应描述为维护安全所必需的所有程序。

2. 开发安全

开发者应提供开发安全文档。开发安全文档应描述在产品的开发环境中，为保护产品设计和实现的保密性和完整性所必需的所有物理的、程序的、人员的和其他方面的安全措施。

3. 生命周期定义

开发者应建立一个生命周期模型对产品的开发和维护进行的必要控制，并提供生命周期定义文档描述用于开发和维护产品的模型。

4. 工具和技术

开发者应描述所使用的实现标准。 开发者应明确定义用于开发产品的工具，并提供开发工具文档无歧义地定义所有语句和实现用到的所有协定与命令的含义，无歧义地定义所有实现依赖选项的含义。

测试

5. 覆盖

开发者应提供测试覆盖文档，测试覆盖描述应满足以下要求：

a) 证实测试文档中的测试与功能规范中安全功能接口之间的对应性；

b) 证实已经对功能规范中的所有安全功能接口都进行了测试。

1. 深度

开发者应提供测试深度的分析。测试深度分析描述应满足以下要求：

a) 证实测试文档中的测试与产品设计中的安全功能子系统和安全功能要求执行模块之间的对应性；

b) 证实产品设计中的所有安全功能子系统和所有模块 都已经进行过测试。

1. 功能测试

开发者应测试产品安全功能，将结果文档化并提供测试文档。测试文档应包括以下内容：

a) 测试计划：标识要执行的测试，并描述执行每个测试的方案，这些方案包括对于其它测试结果的任何顺序依赖性；

b) 预期的测试结果：表明测试成功后的预期输出；

c) 实际测试结果：和预期的测试结果一致。

d) 证实所有已知的漏洞被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，且没有引出新的漏洞。

1. 独立测试

开发者应提供一组与其自测安全功能时使用的同等资源，以用于安全功能的抽样测试。

2. 密码测试

开发者应对所使用的对称、非对称和杂凑密码算法进行正确性和一致性测试，确保实际运算结果与预期的正确结果相符。

开发者应确保使用符合国家密码相关规定的对称、非对称和杂凑密码算法。

3. 代码安全性测试

开发者应对安全功能实现表示和产品内核代码进行安全性测试，证实代码中不包含潜在的安全缺陷或后门。

脆弱性评定

开发者应从以下方面对SSOOS进行脆弱性评定：

a) 基于已标识的潜在脆弱性，产品应抵抗具有中等 攻击潜力的攻击者的攻击；

b) 通过一般性的隐蔽信道分析，对隐蔽信道进行非形式化搜索，标识出可识别的隐蔽存储信道，并以文档形式描述：

1. 标识隐蔽信道，并估算它们的带宽；

2. 用于确定隐蔽信道存在的过程，以及进行隐蔽信道分析所需要的信息；

3. 隐蔽信道分析期间所作的全部假设；

4. 最坏情况下对隐蔽信道带宽进行估算的方式；

5. 每个可标识隐蔽信道的最大可利用情形；

6. 用封锁、限制带宽或审计等措施，对所标识的隐蔽信道进行处理，并证明处理措施的有效性。

注：
抵抗中等 攻击潜力的攻击者的攻击，需要综合考虑根据以下5个具体因素：攻击时间、攻击者能力、对产品的了解程度、访问产品时间或攻击样品数量、使用的攻击设备，详见GB/T
30270—2013中的附录A.8。

第五级：访问验证保护级

安全功能

身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。应从以下方面设计和实现SSOOS的身份鉴别功能：

a. 按以下要求设计和实现用户标识功能：

1. 用户进入操作系统前，先进行标识（建立账号）；

2. 操作系统用户标识使用用户名和用户标识（UID），并在操作系统的整个生存周期实现用户的唯一性标识，以及用户名或别名、UID等之间的一致性。

a. 按以下要求设计和实现用户鉴别功能：

1. 采用强化管理的口令鉴别和/或生物特征鉴别和/或数字证书鉴别和/以协议形式化分析为基础的鉴别 等相结合的方式，采用多鉴别机制，实现对用户身份的真实性鉴别，并在每次用户登录系统时和系统重新连接时进行鉴别；

2. 鉴别信息是不可见的，在存储和传输时使用加密方法进行安全保护，确保其不被非授权的访问、修改和删除。

a. 通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定达到该值时采取的措施来实现鉴别失败的处理；

b. 对注册到操作系统的用户，将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户。

自主访问控制

应从以下方面设计和实现SSOOS的自主访问控制功能：

a) 客体的拥有者能对其拥有的客体定义其他用户的访问控制属性，访问控制属性至少包括：读、写、执行等；

b) 主体对客体的访问遵循该客体的自主访问控制权限属性；

c) 客体的拥有者能对其拥有的客体设置为：拥有者是唯一有权修改其访问权限的主体；

d) 不允许客体拥有者把客体的控制权分配给其他主体；

e) 当主体生成一个客体时，该客体具有该主体设置的自主访问控制权限属性的默认值；

f) 有更细粒度的自主访问控制，将访问控制主体的粒度控制在单个用户，将访问控制客体的粒度控制在文件和目录；

g) 自主访问控制能与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成功的或不成功的访问，使用户对自己的行为承担明确的责任。

标记和强制访问控制

应从以下方面设计和实现SSOOS的强制访问控制功能：

a) 采用标记的方法为操作系统所有主体和客体（至少包括系统所有进程、文件、目录等）标明其安全属性；

b) 客体的标记随客体数据一起流动，当信息从操作系统控制范围之内向控制范围之外输出时，带有安全标记，当信息从操作系统控制范围之外向控制范围之内输入时，通过标记标明其安全属性。如打印输出的数据，需明显标示出该数据的安全标记；

c) 主体和客体的安全属性标记构成了机密性和完整性安全策略模型，这些安全策略模型具有相应的形式化证明 。强制访问控制基于这些标记和安全策略模型，实现主体对客体读、写和执行等操作的访问控制；

d) 强制访问控制与用户身份鉴别、标记等安全功能密切配合，使系统对用户的安全控制包含从系统启动到退出系统的全过程，强制访问控制对客体的控制范围涉及操作系统内部的存储、处理和传输过程，及信息进行输入、输出操作的过程；

e) 由专门设置的系统安全员统一管理操作系统中与强制访问控制等安全机制有关的事件和信息，并将系统的常规管理、与安全有关的管理以及审计管理，分别由系统管理员、系统安全员和系统审计员来承担，按职能分割和最小授权原则分别授予它们各自为完成自己所承担任务所需的最小权限，并形成相互制约关系；

f) 运行于网络环境的多台计算机系统上的网络操作系统，在需要进行统一管理时，考虑各台计算机操作系统的主、客体安全属性设置的一致性，并实现跨网络的SSOOS间用户数据保密性和完整性保护。

安全审计

应从以下方面设计和实现SSOOS的安全审计功能：

a) 能对以下事件生成审计日志：

1. 身份鉴别、自主访问控制、标记和强制访问控制等安全功能的使用用；

2. 创建、删除客体的操作；

3. 网络会话；

4. 所有管理员的操作。

b) 在每个审计记录中至少记录下列信息：

1. 事件类型、事件发生的日期和时间、触发事件的用户、事件成功或失败等字段；

2. 身份标识和鉴别事件类审计日志还包括请求的源（如末端号或网络地址）；

3. 创建和删除客体的事件审计日志还包括客体的名字、客体的安全属性；

4. 网络会话事件还包括：网络程序名称、协议类型、源IP地址、目的IP地址、源端口、目的端口、会话总字节数等字段。

c) 提供以下审计日志分析功能：

1. 潜在侵害分析：设置审计日志累积或组合的规则，使用这些规则去监测已经生成的审计事件，并根据这些规则指示出对实施安全功能要求的潜在侵害；

2. 基于模板的异常检测：根据用户的历史使用模式建立模板，用置疑等级表示用户当前活动与模板中已建立的使用模式不一致的程度，当用户的置疑等级超过门限条件时，能指出对安全功能要求实施的可能侵害即将发生；

3. 简单攻击探测：当发现一个系统事件与一个预示可能潜在违反安全功能要求实施的特征事件匹配时，能指出潜在违反安全功能要求实施的事件即将发生；

4. 复杂攻击探测：维持一个已知入侵情景的事件序列和预示可能潜在违反安全功能要求实施的特征事件的列表，并对照特征事件和事件序列比对系统活动记录。当发现一个系统活动与特征事件或事件序列匹配时，能指出潜在违反安全功能要求实施的事件即将发生。

d) 当检测到潜在的安全侵害时，生成实时报警，并终止违例进程**、取消服务、断开和锁定用户账户** ；

e) 提供审计日志的可选择查询功能，支持按以下条件之一或逻辑组合进行选择和排序查阅，并能导出查询结果：

1. 事件类型；

2. 日期和/或时间；

3. 用户身份；

4. 客体名称；

5. 成功或失败。

f) 提供审计日志的保护功能，主要包括：

1. 保证审计机制默认处于开启状态，且对审计日志的开启和关闭进行保护；

2. 保护审计日志不被未授权的访问；

3. 保证审计日志不被篡改和删除，并记录尝试篡改和删除审计日志的行为**。能恢复被篡改和删除的审计日志** 。

g) 以便于用户理解的方式提供审计日志查阅；

h) 审计日志存储在掉电非遗失性存储介质中。系统管理员能够定义超过审计跟踪存储极限的阈值，当超过阈值时将向管理员报警。当审计存储空间被耗尽时，覆盖所存储的最早的审计记录。

数据完整性

应从以下方面设计和实现SSOOS的数据完整性保护功能：

a. 提供一个实用程序来校验文件系统和磁盘的完整性。此实用程序由操作系统自动执行；

b. 在对数据进行访问操作时进行完整性检测和恢复，检查存储在存储介质上的用户数据是否出现完整性错误**，并在检测到完整性错误时进行恢复** ；

c. 在操作系统内部进行的数据传输，如进程间的通信，提供保证数据完整性的功能。

数据保密性

1. 客体重用

应对存储介质（至少包括：磁盘和内存等）从以下方面设计和实现SSOOS的客体重用功能：

a) 确保非授权用户不能查找使用后返还系统的记录介质中的信息内容；

b) 确保非授权用户不能查找系统现已分配给他的记录介质中以前的信息内容。

1. 数据加密

应从以下方面设计和实现SSOOS的数据加密功能：

a) 提供文件加密功能，用户可对指定的文件和目录进行加密保护；

b) 提供文件系统加密功能，对存储在文件系统加密中的文件和目录，进行透明加解密；

c) 对密钥提供基于硬件信任根的可信存储支持。

可信路径

在本地用户和远程用户进行初始登录和/或鉴别时，SSOOS应在它与用户之间建立一条安全的通信路径。此路径对其端点进行了可信标识，并能保护通信数据免遭修改、泄露。

可信信道

应在SSOOS和另一个可信IT产品之间提供一条通信信道，此信道在逻辑上与其他通信信道截然不同，并对其端点进行了可信标识，并能保护信道中数据免遭修改或泄露。

网络安全保护

应从以下方面设计和实现SSOOS的网络安全保护：

a) 支持基于IP地址、端口、物理接口和应用程序的双向网络访问控制，将不符合预先设定策略的数据包丢弃；

b) 支持基于系统身份、系统运行状态双向网络可信接入认证；

c) 对网络访问进行控制，只有被授权的且通过可信度量的进程才能访问网络；

d) 对网络传输数据进行加密与完整性保护。

操作系统安全子系统自身安全保护

运行安全保护

应从以下方面实现SSF运行安全保护：

a) 提供设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前，对用户和管理员的安全策略属性进行定义；

b) 区分普通操作模式和系统维护模式；

c) 只允许系统管理员进入维护模式。在普通用户访问系统之前，系统以一个安全的方式进行安装和配置；

d) 对备份或不影响SSOOS的常规的系统维护，不要求所有的系统维护都在维护模式中执行；

e) 当操作系统安装完成后，在普通用户访问之前，系统配置好初始用户和管理员职责、根目录、审计参数、系统审计跟踪设置以及对文件和目录的合适的访问控制；

f) 只允许系统管理员修改或替换系统提供的实用程序；

g) 为操作系统安全管理人员提供一种机制，来产生安全参数值的详细报告；

h) 在确定不减弱保护的情况下启动SSOOS，并在SSF运行中断后能在不减弱SSP保护的情况下以手动或自动方式恢复运行。 在SSOOS失败或中断后，确保其以最小的损害得到恢复，并按失败保护中所描述的内容，实现对SSF出现失败时的处理。**系统因故障或其它原因中断后，有一种机制去恢复系统。**系统提供在管理维护状态中运行的能力，管理维护状态只能被系统管理员使用，各种安全功能全部失效；

i) 控制和审计系统控制台的使用情况；

j) 补丁的发布、管理和使用：操作系统的开发者针对发现的漏洞及时发布补丁。操作系统的管理者及时获取、统一管理并及时运用补丁对操作系统的漏洞进行修补。

资源利用

1. 容错

应从以下方面实现SSOOS的容错功能：

a) 通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行，如系统检测和报告系统的服务水平已降低到预先规定的最小值；

b) 当系统资源的服务水平降低到预先规定的最小值时，能检测和发出报告；

c) 提供维护状态中运行的能力，在维护状态下各种安全功能全部失效，系统只允许由系统管理员使用；

d) 系统提供软件及数据备份和复原的过程，在系统中加入再启动的同步点，以便于系统的复原；

e) 系统提供能用于定期确认系统正确操作的机制和过程，这些机制或过程涉及系统资源的监视、硬件和固件单元的正确操作、对可能在全系统内传播的错误状态的检测以及超过用户规定的门限的通讯差错的检测等内容。

1. 服务优先级

应从以下方面实现SSOOS的服务优先级功能：

a) 采取适当的策略，设置主体使用SSF控制范围内某个资源子集的优先级，进行SSOOS资源的管理和分配；

b) 确保对所有SSOOS资源的每次访问都基于主体所配得的优先级进行协调。

1. 资源分配

应从以下方面实现SSOOS的资源分配功能：

a) 按GB/T
20271—2006资源分配中最大限额的要求，进行SSOOS资源的管理和分配。配额机制确保用户和主体将不会独占某种受控的资源；

b) 确保在被授权的主体发出请求时，资源能被访问和利用；

c) 以每个用户或每个用户组为基础，提供一种机制，控制他们对磁盘的消耗和对CPU等资源的使用；

d) 提供用户查看其可访问的系统资源的修改历史记录的权限。

用户登录访问控制

应从以下方面实现SSOOS的用户登录访问控制：

a. 按GB/T
20271—2006中会话建立机制的要求，对会话建立的管理进行设计。登录机制不允许鉴别机制本身被旁路；

b. 按GB/T
20271—2006中多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，SSF限制系统的并发会话的最大数量，并利用默认值作为会话次数的限定数；

c. 按GB/T
20271—2006中可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试
，对用来建立会话的安全属性的范围进行限制；

d. 成功登录系统后，SSOOS记录并向用户显示以下数据：

1. 日期、时间、来源和上次成功登录系统的情况；

2. 上次成功访问系统以来身份鉴别失败的情况；

3. 显示口令到期的天数；

4. 成功或不成功的事件次数的显示可以用整数计数、时间戳列表等表述方法；

a. 在规定的未使用时限后，系统断开会话或重新鉴别用户。系统提供时限的默认值；

b. 系统提供锁定用户键盘的机制，键盘开锁过程要求验证用户；

c. 当用户鉴别过程不正确的次数达到系统规定的次数时，系统退出登录过程并终止与用户的交互；

d. 系统提供一种机制，能按时间、进入方式、地点、网络地址或端口等条件规定哪些用户能进入系统。

可信度量

应从以下方面实现SSOOS的可信度量：

a) 支持硬件可信芯片作为信任根；

b) 在操作系统启动时进行完整性度量，确保操作系统内核的真实性和完整性；

c) 对可执行程序在启动时进行完整性度量，确保可执行程序的真实性和完整性；

d) 对完整性度量基准值进行可信存储，防止其被篡改，确保完整性度量基准值的自身完整性。

可信恢复

当系统失效或服务中断时，应确保SSOOS能够在不丢失用户数据的情况下 自动恢复到安全运行状态。

安全策略配置

应对身份鉴别、标记和强制访问控制、安全审计、网络安全保护、资源利用、用户登录访问控制提供安全策略配置功能。

安全保障要求

开发

1. 安全架构

开发者应提供产品安全功能的安全架构描述，安全架构描述应满足以下要求：

a) 与产品设计文档中对安全功能要求执行的抽象描述的级别一致；

b) 描述与安全功能要求一致的产品安全功能的安全域；

c) 描述产品安全功能初始化过程为何是安全的；

d) 证实产品安全功能能够防止被破坏；

e) 证实产品安全功能能够防止安全功能要求执行的功能被旁路。

1. 功能规范

开发者应提供完备的功能规范说明，功能规范说明应满足以下要求：

a) 完全描述产品的安全功能；

b) 使用半形式化方式描述安全功能接口；

c) 描述所有安全功能接口的目的与使用方法；

d) 标识和描述每个安全功能接口相关的所有参数；

e) 描述每个安全功能接口相关的所有行为；

f) 描述可能由每个安全功能接口的调用而引起的所有直接错误消息；

g) 描述不是由安全功能接口调用而引起的所有错误消息；

h) 为每个包含在安全功能实现中但不是由安全功能接口调用而引起的错误消息提供基本原理；

i) 证实安全功能要求到安全功能接口的追溯。

1. 实现表示

开发者应提供全部安全功能的实现表示，实现表示应满足以下要求：

a) 按详细级别定义产品安全功能，详细程度达到无须进一步设计就能生成安全功能的程度；

g) 以开发人员使用的形式提供；

h) 提供产品设计描述与全部 实现表示之间的映射，并证明其一致性。

1. TSF内部

开发者应提供TSF内部结构的描述和论证过程文档，TSF内部应满足以下要求：

a) 论证过程描述用于判定"结构合理"及复杂性 的含义的特性；

b) TSF内部结构描述证实指定的整个TSF结构合理且不过于复杂 。

1. 安全策略模型

开发者应提供形式化的安全策略模型，至少包括：自主访问控制策略、强制访问控制策略、完整性策略，安全策略模型应满足以下要求：

a) 模型是形式化的，必要时辅以解释性的文字，并且标识模型化的安全功能的安全策略；

c) 对于所有被模型化的策略，模型定义该产品的安全，提供该产品不能达到非安全状态的形式化证明；

d) 该模型与功能规范的一致性采用正确的形式化级别进行论述；

e) 该对应性表明功能规范相对该模型是一致的和完备的；

f) 该对应性论证表明功能规范中描述的接口相对于自主访问控制策略、强制访问控制策略、完整性策略是一致的和完备的。

1. 产品设计

开发者应提供产品设计文档，产品设计文档应满足以下要求：

a) 根据子系统描述产品结构；

b) 根据模块描述安全功能，把每个模块指定为安全功能要求执行、安全功能要求支撑或安全功能要求无关；

c) 标识产品安全功能的所有子系统；

d) 提供每一个安全功能子系统的半形式化描述，适当时配以非形式化的、解释性的描述；

e) 描述安全功能所有子系统间的相互作用；

f) 提供安全功能子系统到模块间的映射关系；

g) 为每一个模块提供一个半形式化描述，包括它的目的、相互作用、接口、其它接口的返回值、被其它模块调用的接口，适当时配以非形式化的、解释性的描述；

h) 提供的映射关系能够证实设计中描述的所有行为能够映射到调用它的安全功能接口。

指导性文档

1. 操作用户指南

开发者应提供明确和合理的操作用户指南，操作用户指南与为评估而提供的其他所有文档保持一致，对每一种用户角色的描述应满足以下要求：

a) 描述在安全处理环境中被控制的用户可访问的功能和特权，包含适当的警示信息；

b) 描述如何以安全的方式使用产品提供的可用接口；

c) 描述可用功能和接口，尤其是受用户控制的所有安全参数，适当时指明安全值；

d) 明确说明与需要执行的用户可访问功能有关的每一种安全相关事件，包括改变安全功能所控制实体的安全特性；

e) 标识产品运行的所有可能状态（包括操作导致的失败或者操作性错误），以及它们与维持安全运行之间的因果关系和联系；

f) 充分实现安全目的所必须执行的安全策略。

1. 准备程序

开发者应提供产品及其准备程序，准备程序描述应满足以下要求：

a) 描述与开发者交付程序相一致的安全接收所交付产品必需的所有步骤；

g) 描述安全安装产品及其运行环境必需的所有步骤。

生命周期支持

1. 配置管理能力

开发者的配置管理能力应满足以下要求：

a) 为产品的不同版本提供唯一的标识；

h) 使用配置管理系统对组成产品的所有配置项进行维护，并唯一标识配置项；

i) 提供配置管理文档，配置管理文档描述用于唯一标识配置项的方法；

j) 论证接受程序对所有配置项的变更都提供了充分且适当的复查；

k) 提供自动化的措施使得只能对配置项进行授权变更；

l) 配置管理系统提供一种自动方式来支持产品的生产；

m) 配置管理系统确保负责将某个配置项接受到配置管理系统中的人不是开发此配置项的人；

n) 配置管理系统以自动化的方式支持TOE所有变化的审计，审计记录中要包括源发者、日期和时间等信息；

o) 配置管理系统提供自动化的方式标识受已给定配置项的变化影响的所有其它配置项；

p) 配置管理系统能标识用于生成产品的实现表示的版本；

q) 配置管理文档包括一个配置管理计划，配置管理计划描述如何使用配置管理系统开发产品；

r) 实施的配置管理与配置管理计划相一致；

s) 配置管理计划描述用来接受修改过的或新建的作为产品组成部分的配置项的程序。

1. 配置管理范围

开发者应提供产品配置项列表，并说明配置项的开发者。配置项列表应包含以下内容：

a) 产品、安全保障要求的评估证据和产品的组成部分和实现表示、安全缺陷报告及其解决状态、开发工具及其相关信息；

t) 唯一标识配置项；

u) 对于每一个安全功能相关的配置项，配置项列表简要说明该配置项的开发者。

1. 交付程序

开发者应使用一定的交付程序交付产品，并将交付过程文档化。在给用户方交付产品的各版本时，交付文档应描述为维护安全所必需的所有程序。

2. 开发安全

开发者应提供开发安全文档。开发安全文档应描述在产品的开发环境中，为保护产品设计和实现的保密性和完整性所必需的所有物理的、程序的、人员的和其他方面的安全措施。开发安全文档应论证安全措施提供了必需的保护级别以维护产品的机密性和完整性。

3. 生命周期定义

开发者应建立一个生命周期模型对产品的开发和维护进行的必要控制，并提供生命周期定义文档描述用于开发和维护产品的模型。

4. 工具和技术

应描述开发者和任何产品所有部分的第三方提供商 所使用的实现标准。开发者应明确定义用于开发产品的工具，并提供开发工具文档无歧义地定义所有语句和实现用到的所有协定与命令的含义，无歧义地定义所有实现依赖选项的含义。

测试

5. 覆盖

开发者应提供测试覆盖文档，测试覆盖描述应满足以下要求：

a) 证实测试文档中的测试与功能规范中安全功能接口之间的对应性；

b) 证实已经对功能规范中的所有安全功能接口都进行了完全地 测试。

1. 深度

开发者应提供测试深度的分析。测试深度分析描述应满足以下要求：

a) 证实测试文档中的测试与产品设计中的安全功能子系统和安全功能要求执行模块之间的对应性；

v) 证实产品设计中的所有安全功能子系统和所有模块都已经进行过测试。

1. 功能测试

开发者应测试产品安全功能，将结果文档化并提供测试文档。测试文档应包括以下内容：

a) 测试计划：标识要执行的测试，并描述执行每个测试的方案，这些方案包括对于其它测试结果的任何顺序依赖性；

b) 预期的测试结果：表明测试成功后的预期输出；

c) 实际测试结果：和预期的测试结果一致；

d) 测试步骤顺序依赖性的一个分析。

e) 证实所有已知的漏洞被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，且没有引出新的漏洞。

1. 独立测试

开发者应提供一组与其自测安全功能时使用的同等资源，以用于安全功能的抽样测试。

2. 密码测试

开发者应对所使用的对称、非对称和杂凑密码算法进行正确性和一致性测试，确保实际运算结果与预期的正确结果相符。

开发者应确保使用符合国家密码相关规定的对称、非对称和杂凑密码算法。

3. 代码安全性测试

开发者应对安全功能实现表示和产品内核代码进行安全性测试，证实代码中不包含潜在的安全缺陷或后门。

脆弱性评定

开发者应从以下方面对SSOOS进行脆弱性评定：

a) 基于已标识的潜在脆弱性，产品应抵抗具有高等 攻击潜力的攻击者的攻击；

b) 通过严格的 隐蔽信道分析，对隐蔽信道进行严格搜索，以结构化、可重复的方式标识出可识别的隐蔽存储信道和隐蔽时间信道，并以文档形式描述：

1. 标识隐蔽信道，并估算它们的带宽；

2. 用于确定隐蔽信道存在的过程，以及进行隐蔽信道分析所需要的信息；

3. 隐蔽信道分析期间所作的全部假设；

4. 最坏情况下对隐蔽信道带宽进行估算的方式；

5. 每个可标识隐蔽信道的最大可利用情形；

6. 用封锁、限制带宽或审计等措施，对所标识的隐蔽信道进行处理，并证明处理措施的有效性。

注：
抵抗高等 攻击潜力的攻击者的攻击，需要综合考虑根据以下5个具体因素：攻击时间、攻击者能力、对产品的了解程度、访问产品时间或攻击样品数量、使用的攻击设备，详见GB/T
30270—2013中的附录A.8。

附录A

（资料性附录）

操作系统安全技术要求分级表

表1以表格形式列举了操作系统五个安全等级的相关技术要求。

表1 操作系统安全技术要求分级表

参 考 文 献

1. Common Methodology for Information Technology Security
   Evaluation（CCMB-2012-09-004, Version 3.1 Revision 4）

2. GB/T 18336.1—2015信息技术 安全技术 信息技术安全评估准则
   第1部分:简介和一般模型

3. GB/T 18336.2—2015 信息技术 安全技术 信息技术安全评估准则
   第2部分:安全功能组件

4. GB/T 22239—2008 信息安全技术 信息系统安全等级保护基本要求

5. GB/T 29240—2012 信息安全技术
   终端计算机通用安全技术要求与测试评价方法

6. GB/T 29827—2013 信息安全技术 可信计算规范 可信平台主板功能接口

7. GB/T 29828—2013 信息安全技术 可信计算规范 可信连接架构

8. GB/T 29829—2013 信息安全技术 可信计算密码支撑平台功能与接口规范

9. GB/T 30270—2013 信息技术 安全技术 信息技术安全性评估方法

________________________________

延伸阅读

更多内容 可以 操作系统安全技术要求. 进一步学习

联系我们

DB37-T 3454-2018 客运索道使用安全风险分级管控和事故隐患排查治理体系建设实施指南 山东省.pdf