GBT 20272-2006 信息安全技术 操作系统安全技术要求

可按GB/T20271一2006中6.1.4.1的要求，实现SSF的物理安全保护，通过对物理安全的 发现以物理方式的攻击对SSF造成的威胁和破坏。

41 2 2SSF 运行安全保据

可接GB/T20271一2006中6.1.4.2的要求，从以下方面实现SSF的运行安全保护： a）系统在设计时不应留有“后门”，即不应以维护、支持或操作需要为借口，设计有违反或绕过安 全规则的任何类型的人口和文档中未说明的任何模式的人口。 b) 安全结构应是一个独立的、严格定义的系统软件的一个子集，并应防止外部干扰和破坏，如修 改其代码或数据结构。 C 操作系统程序与用户程序要进行隔离。一个进程的虚地址空间至少应被分为两个段：用户空 司和系统空间，两者的隔离应是静态的。驻留在内存中的操作系统应由所有进程共享。用户 进程之间应是彼此隔离的。应禁止在用户模式下运行的进程对系统段进行写操作，而在系统 模式下运行时，应允许进程对所有的虚存空间进行读、写操作。 d 提供一个设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护 之前，应对用户和管理员的安全策略属性进行定义。 e) 区分普通操作模式和系统维护模式。 f）补丁的发布和运用：补丁是对操作系统安全漏洞进行修补的程序的总称。操作系统的开发者

燃气标准规范范本免费标准下载网（ww.freebz.n

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

4.1.23SSF数据安全保护

4.1.2.4资源利用

可按GB/T20271一2006中6.1.4.4的要求，从以下方面实现SSOOS的资源利用： a 通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行； b 采取适当的策略，按有限服务优先级，提供主体使用TSC内某个资源子集的优先级，进行 SSOOS资源的管理和分配； ） 按资源分配中最大限额的要求，进行SSOOS资源的管理和分配，要求配额机制确保用户和主 体将不会独占某种受控的资源

1.2.5SSOOS访问控制

可接GB/T20271一2006中6.1.4.5的要求，从以下方面实现SSOOS的访向控制： a） 按会话建立机制的要求，对会话建立的管理进行设计。 b 按多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上 SSF应限制系统的并发会话的最大数量，并应利用默认值作为会话次数的限定数。 按可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试，对用来建立会话的 安全属性的范围进行限制

4.1.3SSOOS设计和实现

开发者所使用的版本号与所应表示的SSOOS样本完全对应

4.1.3.2分发和操作

可按GB/T20271一2006中6.1.5.2的要求，从以下方面实现SSOOS的分发和操作： a)[ 以文档形式提供对SSOOS安全地进行分发的过程，并对安装、生成和启动的过程进行说明， 最终生成安全的配置。文档中所描述的内容应包括： 提供分发的过程； 一安全启动和操作的过程。 b）对系统的未授权修改的风险，应在交付时控制到最低限度。在包装及安全分送和安装过程 中，这种控制应采取软件控制系统的方式，确认安全性会由最终用户考虑，所有安全机制都应 以功能状态交付。 c) 所有软件应提供安全安装献认值，在客户不做选择时，认值应使安全机制有效地发挥作用， d) 随同系统交付的全部款认用户标识码，应在交付时处于非激活状态，并在使用前由管理员 激活。 e） 用户文档应同交付的软件一起包装，并应有一套规程确保当前送给用户的系统软件是严格按 最新的系统版本来制作的

4. 1.3. 3 开发

4. 1.3. 4文档要求

可按GB/T20271一2006中6.1.5.4的要求，从以下方面编制SSOOS的文档： 用户文档应提供关于不同用户的可见的安全机制以及如何利用它们的信息，并解释它们的用 途和提供有关它们使用的指南； 6） 安全管理员文档应提供有关如何设置、维护和分析系统安全的详细指导，包括当运行一个安 全设备时，需要控制的有关功能和特权的警告，以及与安全有关的管理员功能的详细描述，包 括增加和删除一个用户、改变用户的安全特征等； C 文档中不应提供任何一旦泄露将会危及系统安全的信息，有关安全的指令和文档应划分等级 分别提供给用户系统管理员和系统安全员

4. 1.3. 5生存周期支持

可按GB/T20271一2006中6.1.5.6的要求，从以下方面对SSOOS进行测试： a) 通过一般功能测试和相符独立性测试，确认SSOOS的功能与所要求的功能相一致； b) 所有系统的安全特性，应被全面测试； C 所有发现的漏洞应被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除 且没有引出新的漏洞：

4.1.4SSOOS安全管理

可按GB/T20271一2006中6.1.6的要求，实现SSOOS的安全管理，对相应的SSOOS的访问控 制、鉴别控制、安全属性管理等相关的功能，以及与一般的安装、配置等有关的功能，制定相应的操作、运 行规程和行为规章制度。

4.2第二级：系统审计保护级

身份鉴别包括对用户的身份进行标识和鉴别。应按GB/T20271一2006中6.2.3.1的要求 下方面设计和实现操作系统的身份鉴别功能： a）按GB/T20271一2006中6.2.3.1.1和以下要求设计和实现用户标识功能： 凡需进人操作系统的用户，应先进行标识（建立账号）：

4. 2. 1. 2 自主访间控制

按GB/T a）允许命名用户以用户的身份规定并控制对客体的访问，并阻止非授权用户对客体的访问。 b) 设置款认功能，当一个主体生成一个客体时，在该客体的访间控制表中相应地只有该主体设 置的款认值。 有更细粒度的自主访问控制，将访问控制的粒度控制在单个用户；对系统中的每个客体，都 能够实现由客体的创建者以用户指定方式确定其对该客体的访问权限，而别的同组用户或非 同组的用户和用户组对该客体的访问权则由创建者用户授予。 d) 自主访问控制能与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成 功的或不成功的访问，使用户对自已的行为承担明确的责任。 e) 客体的拥有者应是唯一有权修改客体访问权限的主体，拥有者对其拥有的客体应具有全部控 制权，但是，不允许客体拥有者把该客体的控制权分配给其他主体， f) 定义访间控制属性，并保护这些属性；主体的访问控制属性至少应有：读、写、执行等；客体的访

GB/T 202722006

向控制属性应包含可分配给主体的读、写和执行等权限。 & 定义分配和修改主体和客体的访问控制属性的规则，并执行对主体和客体的访问控制属性的 分配和修改，规则的结果应达到只有被授权的用户才允许访向一个客体。 h 定义主体对客体的访问授权规则；该规则应基于主体对客体的访问控制属性，同时应指出主 体和客体对这些规则应用的类型。

4. 2. 1.3安全审计

接GB/T20271一2006中6.2.2.3的要求，从以下方面设计和实现操作系统的安全审计功能： a）安全审计功能应与身份鉴别、自主访向控制等安全功能紧密结合。 b）提供审计日志，潜在侵害分析，基本审计查阅和有限审计查阅，安全审计事件选择，以及受保 护的审计踪迹存储等功能。 c） 能够生成、维护及保护审计过程，使其免遭修改、非法访及破坏，特别要保护审计数据，要产 格限制未经授权的用户访同。 d) 能够创建并维护一个对受保护客体访问同的审计踪踪，保护审计记录不被未授权的访向、修改 和破坏。 e) 指出可记录的审计事件的最少类型，包括建立会话登录成功和失败、使用的系统接口、系统数 据库管理的改变（改变用户账户属性、审计跟踪设置和分析、为程序分配设置用户ID、附加或 改变系统程序或进程、改变日期和时间等），超级用户命令改变用户身份、将某个客体引入某个 用户的地址空间（如打开文件）、删除客体、系统管理员及系统安全管理员进行的操作等。当审 免费标准下 制的使用者应是有限的授权用户。 f)4 每个事件的数据记录，应包括的信息有：事件发生的日期和时间、触发事件的用户、事件的类 型、事件成功或失败等。对于身份标识和鉴别事件，应记录请求的源（如末端号或网络地址）； 对于创建和删除客体的事件，应记录客体的名字和客体的安全属性。 g 应提供一个受保护的打开和关闭审计的机制。该机制能选择和改变审计事件，并在系统工作 时处于默认状态；该机制的使用应受到系统管理员的授权限制，系统管理员应能够选择一个或 多个基于身份鉴别或客体属性的用户的审计活动；审计工具应能够授权个人使用、修改和删除 审计；应提供对审计跟踪管理功能的保护，使之可以完成审计跟踪的创建、破坏、腾空和存档； 系统管理员应能够定义超过审计跟踪极限的阀值；当存储空间被耗尽时，应能按管理员的指定 范彩时的 的注量

4.2.1.4用户数据完整性

户功能： a) 在对数据进行访问操作时，检查存储在存储介质上的用户数据是否出现完整性错误。操作系 统对磁盘设备中存储的数据，可通过增加磁盘扫描程序实现以下功能： 一自动检查文件与磁盘表面是否完好； 一将磁盘表面的问题自动记录下来； 一随时检查、诊断磁盘上的错误。 b）对操作系统内部传输的用户数据，如进程间的通信，应提供保证数据完整性的功能。 C 对操作系统中处理的用户数据，应按回退的要求设计相应的SSOOS安全功能模块，进行异常 情况的操作序列回退，以确保用户数据的完整性。

4.2.1.5用户数据保密

按GB/T20271一2006中6.2.3.4的要求，从以下方面设计和实现操作系统的用户数据保 户功能：

确保动态分配与管理的资源，在保持信息安全的情况下被再利用，主要包括：确保非授权用户 不能查找系统现已分配给他的记录介质中以前的信息内容。 在单用户系统中，存储器保护应防止用户进程影响系统的运行。 在多用户系统中，存储器保护应保证系统内各个用户之间互不于扰。 一存储黑保护应包托

确保动态分配与管理的资源，在保持信息安全的情况下被再利用，主要包括：确保非授权用户

a）确保动态分配与管理的资源，在保持信息安全的情况下被再利用，主要包括：确保非授权用户 不能查找系统现已分配给他的记录介质中以前的信息内容。 b）在单用户系统中，存储器保护应防止用户进程影响系统的运行。 c）在多用户系统中，存储器保护应保证系统内各个用户之间互不于扰。 d）存储器保护应包括： 一对存储单元的地证的保护，使非法用户不能访向那些受到保护的存储单元； 一对被保护的存储单元的操作提供各种类型的保护，最基本的保护类型是“读/写”和“只 读”，不能读/写的存储单元，若被读/写时，系统应及时发出警报或中断程序执行； 可采用逻辑隔离的方法进行存储器保护，具体有：界限地址寄存器保护法、内存标志法、 锁保护法和特征位保护法等。

对存储单元的地址的保护，使非法用户不能访问那些受到保护的存储单元； 对被保护的存储单元的操作提供各种类型的保护，最基本的保护类型是“读/写”和“只 读”，不能读/写的存储单元，若被读/写时，系统应及时发出警报或中断程序执行； 可采用逻辑隔离的方法进行存储器保护，具体有：界限地址寄存器保护法、内存标志法 锁保护法和特征位保护法等

4.2.2SSOOS自身安全保护

按GB/T20271·2006中6.2.4.1的要求，实现SSF的物理安全保护，通过对物理攻击的检查.发 现以物理方式的攻击对SSF造成的威胁和破坏

4.2.2.2SSF运行安全保护

按GB/T202712006中6.2.4.2的要求，从以下方面实现SSF的运行安全保护： a）系统在设计时不应留有“后门”。即不应以维护、支持或操作需要为借口，设计有违反或绕过安 全规则的任何类型的入口和文档中未说明的任何模式的入口

系统在设计时不应留有“后门”。即不应以维护、支持或操作需要为借口，设计有违反或绕过安 全规则的任何类型的入和文档中未说明的任何模式的入口。 免费标准下载网( 改其代码或数据结构， 操作系统程序与用户程序要进行隔离。一个进程的虚地址空间至少应被分为两个段：用户空 间和系统空间，两者的隔离应是静态的，驻留在内存中的操作系统应由所有进程共享。用户 进程之间应是彼此隔离的。应禁止在用户模式下运行的进程对系统段进行写操作，而在系统 模式下运行时，应允许进程对所有的虚存空间进行读、写操作， 1） 提供设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前， 应对用和管理员的安全策略属性应进行定义。 应区分普通操作模式和系统维护模式。 应防止一个普通用户从未经允许的系统进人维护模式，并应防止一个普通用户与系统内维护 模式交互。从而保证在普通用户访问系统之前，系统能以一个安全的方式进行安装和配置。 对备份或不影响SSOOS的常规的系统维护，不要求所有的系统维护都在维护模式中执行。 ) 当操作系统安装完成后，在普通用户访问之前，系统应配置好初始用户和管理员职责、根目 录、审计参数、系统审计跟踪设置以及对文件和目录的合适的访问控制 执行系统所提供的实用程序，应（默认地）限定于对系统的有效使用，只允许系统管理员修改或 替换系统提供的实用程序。 I 操作环境应为用户提供一个机制，来控制命令的目录/路径的查找顺序。 ) 在SSS失败或中断后.应确保其以最小的损害得到恢复。并按失败保护币所描述的内容 实现对SSF出现失败时的处理， 操作系统环境应控制和审计系统控制台的使用情况。 m）补丁的发布、管理和使用：补丁是对操作系统安全漏洞进行修补的程序的总称。操作系统的 开发者应针对发现的漏洞及时发布补丁。操作系统的管理者应及时获取、统一管理并及时运 用补工对操作系统的温温进行终补

4.2.2.3SSF数据安全保护

按GB/T20271一2006中6.2.4.3的要求，对在SSOOS内传输的SSF数据进以下安全保护：

a）实现SS()OS内SSF数据传输的基本保护： b）SSOOS内SSF数据复制的一致性保护。

4.2.2. 4 资源利用

按GB/T20271一2006中6.2.4.4的要求，从以下方面实现SSO()S的资源利用： a) 应通过一定措施确保当系统出现某些确定的故障情况时，SSF也能维持正常运行，如系统应检 测和报告系统的服务水平已降低到预先规定的最小值； b）应采取适当的策略，有限服务优先级提供主体使用TSC内某个资源子集的优先级，进行 SSOS资源的管理和分配； c) 应按资源分配中最大限额的要求，进行SS)O)S资源的管理和分配.要求配额机制确保用户和 主体将不会独占某种受控的资源； d) 系统应确保在被授权的主体发出请求时，资源能被访问和利用； e） 当系统资源的服务水平降低到预先规定的最小值时，应能检测和发出报告； 系统应提供维护状态中运行的能力，在维护状态下客种安全性能全部失效，系统只充许由系统 管理员使用； g）系统应以每个用户或每个用户组为基础，提供一种机制，控制他们对磁盘的消耗和对CPU的 使用。

4. 2. 2.5SSOOS 访问控制

免费标准下载 的身份。登录机制不允许鉴别机制本身被旁路， b）按多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上， SSF应限制系统的并发会话的最大数量，斥应利用默认值作为会话次数的限定数。 按可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试，对用来建立会话的 安全属性的范闹进行限制。 d 成功登录系统后，SSOOS应记录并向用户显示以下数据： 日期、时间、来源和上次成功登录系统的情况； 上次成功访问系统以来身份鉴别失败的情况； 应显示口令到期的天数； 成功或不成功的事件次数的显示可以用整数计数、时间截列表等表述方法

4.2.3SSOOS设计和实现

4.2.3.1配置管理

按（B/T202712006中6.2.5.1的要求.从以下方面实现SS()OS的配置管理： a）在配置管理能力方面应实现对版本号等方面的要求。 b衣 在SSOOS的配置管理范围方面，应将SSOOS的实现表示、设计文档、测试文档、用户文档、管 理员文档以及配置管理文档等置于配置管理之下。 c）在系统的整个生存期，即在它的开发、测试和维护期间，应有一个软件配置管理系统处于保持 对改变源码和文件的控制状态。只有被授权的代码和代码修改才充许被加进已交付的源码的 基本部分。所有改变应被记载和检查，以确保未危及系统的安全。在软件配置管理系统中，应 包含从源码产生出系统新版本、鉴定新生成的系统版本和保护源码免道未授权修改的工具和 规程。通过技术、物理和保安规章三方面的结合，可充分保护生成系统所用到的源码免遭未授 权的修改和股坏

4. 2. 3. 2分发和操作

06中6.2.5.2的要求，从以下方面实现SS(OS的

GB/T202722006

按GB/T20271一2006中6.2.5.3的要求，从以下方面进行SS()()S的开发： a）要求按非形式化安全策略模型、完全定义的外部接口、描述性高层设计、SSF子集实现、SSF内 部结构层次化、描述:低层设计、非形式化对应性说明的要求，进行SS()OS的设计； 免费标准下载网(ww.freebz.nel 处理、返回状态的检查、中间结果的检查、合理值输人检查、事务处理更新的正确性检查等； c 在内部代码检查时，应解决潜在的安全缺陷，关闭或取消所有的后门； d）所有交付的软作和文档.应进行关于安全缺陷的定期的和书面的检查并将检查结果告知 用户； e）由系统控制的敏感数据.如「i令和密钥等，不应在未受保护的程序或文档中以明文形式储存：

4.2.3.4文档要求

文件所利用的磁盘剩余空间所推荐的过程； 关于设置所有文件和目录的最低访问许可的建议； 运行文件系统或磁盘完整性检测所做的建议； 如何进行系统自我评估的章节（带有网络管理、口令要求、拨号访问控制、意外事故计划的 安全报告），为灾害恢复计划所做的建议； 一描述普通入侵技术和其他威胁，及查出和阻止它们的方法。 d）文档中不应提供任何一旦泄露将会危及系统安全的信息。有关安全的指令和文档应划分等 级分别提供给用户、系统管理员和系统安全员。这些文档应为独立的文档，或作为独立的章 节插入到管理员指南和用户指南中。文档也可为硬拷贝、电子文档或联机文档。如果是联机 文档应控制对其的访问。

4.2.3.5生存周期支持

接GB/T202712006中6.2.5.5的要求，从以下面实现SSS的生存周期支持： a）应按开发者定义生存周期模型和明确定义开发工具的要求进行开发，并提供开发过程中的安 全措施说明。 b） 所有安全软件应提供安全安装默认值。在未做特殊选择时，应按默认值安装安全机制。 随同系统交付的全部默认用户标识号，在安装完时应处于非激活状态，并由系统管理员加以 激活

极假消修改·说明仕胶晖取系玩出珀时叫伙发系玩王文主伙芯 e） 如果系统含有加强安全性的硬件，那么管理员、最终用户或自动的诊断测试，应能在各自的操 作环境中运行它并详细说明操作过程

4. 2 3. 6测试

8） 应通过一般功能测试、相符独立.性测试、范围证据和范围分析、高层设计的测试，确认SSOOS 的功能与所要求的功能相一致。 b 所有系统的安全特性，应被全面测试，包括查找漏洞，如允许违反系统访问控制要求、允许违 反资源访问控制要求、允许拒绝服务、允许多审计或验证数据进行未授权访问等。所有被发现 的漏洞应被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，且没有引 出新的漏洞，

4. 2. 3. 7脆弱性评定

接GB/T20271一2006中6.2.5.7的要求，从以下方面对SSOOS进行脆弱性评定： a) 对防止误用的评定，通过对文档的检查，查找SSOOS以不安全的方式进行使用或配置而不为 人们所察觉的情况； 6) 对SSOOS安全功能强度评估，通过对安全机制的安全行为的合格性或统计结果的分析，证明 其达到或超过安全目标要求所定义的最低强度； c) 开发者脆弱性分析，通过确定明显的安全脆弱性的存在，并确认在所期望的环境中所存在的脆 弱性不会被利用

4.2.4SSOOS安全管理

按GB/T20271一2006中6.2.6的要求，从以下方面实现SSO()S的安全管理： a）对相应的SS()OS的访问控制、鉴别控制、审计和安全属性管理等和关的功能，以及与一般的 安装、配置和维护有关的功能，制定相应的操作、运行规程和行为规章制度

根据本级中安全功能技术要求和安全保证技术要求所涉及的安全属性，设计SSOOS安 性管理； C) 根据本级中安全功能技术要求和安全保证技术要求所涉及的安全数据，设计SSOOS安 据管理。

4.3.1.2自主访问控制

4. 3. 13 标记

一般应按GB/T20271一2006中6.3.3.4的要求，从以下方面设计和实现操作系统的标记功能： a）采用标记的方法为操作系统SSOOS安全功能控制范围内的主体和客体设置敏感标记。这些 敏感标记构成多级安全模型的属性库。操作系统主、客体的敏感标记应以默认方式生成或由 安全员进行建立、维护和管理。 b） 当信息从SSOOS控制范围之内向SSOOS控制范围之外输出时，可带有或不带有敏感标记； 当信息从SSOOS控制范围之外向SSOOS控制范围之内输人时，应通过标记标明其敏感 标记

4.3.1.4强制访问控制

一般应接GB/T20271一2006中6.3.3.5的要求，从以下方面设计和实现操作系统的强制访问控 功能： a 由专门设置的系统安全员统一管理操作系统中与强制访问控制等安全机制有关的事件和信 息，并将系统的常规管理、与安全有关的管理以及审计管理，分别由系统管理员、系统安全员和 系统审计员来承担，按职能分割原则分别授予它们各自为完成自已所承担任务所需的权限，并 形成相互制药关系 b 强制访问控制应与用户身份鉴别、标记等安全功能密切配合，使系统对用户的安全控制包含 从用户进入系统到退出系统的全过程，对客体的控制范围涉及操作系统内部的存储、处理和传 输过程：

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

4.3.1.5数据流控制

对于以数据流方式实现数据交换的操作系统，一般应按GB/T20271一2006中6.3.3.6的要 计和实现操作系统的数据流控制功能，

4.3.1.6安全审计

f）每个事件的数据记录，应包括的信息有：事件发生的期和时间、触发件的用户、事件的类 型、事件成功或失败等。对于身份标识和鉴别事件，应记录请求的源（如未端号或网络地址：》 对于创建和删除客体的事件，应记求客体的名字和客体的安全属性。 g 应提供一个受保护的打开和关闭中计的机制。该机制能选择和改变审计事件，并在系统工作 时处于默认状态；该机制的使用应受到系统管理员的授权限制.系统管员应能够选择一个或 多个基于身份鉴别或客体属性的用的审计活动：审计.具应能够授权个人监察利浏览审计 数据.同时数据应得到授权的使用、修改利删除；应提供对审计跟踪管理功能的保护，使之可以 完成中计跟踪的创建、破坏、腾空和存档：系统管理员应能够定义超过审计跟踪极限的阀值；" 存储空间被耗尽时，应能按管理员的指定决定采取的措施，包括：报警并丢弃末记录的审计信 息、暂停审计、覆盖以前的年计证求签

4.3.1.7用户数据完整

一白动检查文件与磁盘表面是否完好； 将磁盘表而的问题自动记录下来； 随时检、诊断和修复磁盘上的错误； 修复扇区交错和扇区流失； 一将数据移到好的扇区； 一可增加硬盘数据备份和修复程序，将硬盘中的数据压缩、备份，并在必要时恢复。 在操作系统内部传输的户数据，如进程间的通信，应提供保证用户数据完整性的功能，完整 性标签应随数据一起流动，系统应保证低完整性的数据不能插入、覆盖到高完整性的数据。 对操作系统中处理的数据.应按回退的要求设计相应的SS())S安全功能模块，进行异常情况 的操作序列回退。以确保用户数据的完整性。系统应保证在处理过程中不降低数据完整性的 级别，

白动检查文件与磁盘表面是否完好； 将磁盘表而的问题自动记录下来； 随时检查、诊断和修复磁盘上的错误 修复扇区交错和扇区流失； 一将数据移到好的扇区； 可增加硬盘数据备份和修复程序，将码 在操作系统内部传输的别户数据，如进程间 性标签应随数据一起流动，系统应保证低完 对操作系统中处理的数据.应按回退的要习 的操作序列回退以确保用户数据的完整 级别

4.3.1.8用户数据保密性

一般应按GB/T20271一2006中6.3.3.8的要求，从以下方面设计和实现操作系统的川数据保 密作保护功能： a） 应确保动态分配与管理的资源，在保持信息安全的情况下被再利用，主要包括： 确保非授权用户不能查找使用后返还系统的记录介质中的信息内容； 确保非授权用户不能查找系统现已分配给他的记录介质中以前的信息内容。 b）在单用户系统中，存储器保护应防止用进程影响系统的运行。 C 在多川用户系统中，存储器保护应保证系统内各个川户之间不1扰。 d） 存储器保护应包括： 对存储单元的地址的保护，使非法用户不能访问那些受到保护的存储单元； 对被保护的存储单元的操作提供各种类型的保护，最基本的保护类型是“读/写”和“只 读”，不能读/凹的存储单元，若被读/写时，系统应及时发山警报或中断程序执行：

可采用逻辑隔离的方法进行存储器保护，只体有：界限地址寄存器保护法、内存标志法、 锁保护法和特征位保护法等

4.3.2SSOOS自身安全保护

一般应按GB/T20271·2006中6.3.4.1的要求.实现SSF的物理安全保护，通过对物理攻击的检 查和自动报告，及时发现以物理方式的攻击对SSF造成的威胁和破坏，

.2.2SSF运行安全保折

4.3.2.3SSF数据安全保护

4. 3.2. 4资源利用

定的门限的通讯差错的检测等内容。

4.3.2.5SSOOS访问控制

免费标准下载网(ww.freebz.n

4.3.3SSOOS设计和实现

的要求.从以下方面实现SSO)S的配置管理： ）在配置管理能力方面应实现对版本号、配置项、授权控制等方而的要求：

b）在配置管理自动化方面要求部分的配置管理自动化； c）在SSOOS的配置管理范围方面，应将SSCOOS的实现表示、设计文档、测试文档、用户文档、管 理员文档以及配置管理文档等置于配置管理之下，要求实现对配置管理范围内的向题跟踪，特 别是安全缺陷问题进行跟踪； d）在系统的整个牛:存期，即在它的开发、测试和维护期间.应有一个软件配置管理系统处于保持 对改变源码和义件的控制状态。只有被授权的代码和代码修改才允许被加进已交付的源码的 基本部分。所行改变应被记载和检查，以确保术危及系统的安全。在软件配置管理系统中，应 包含从源码产生系统新版本、鉴定新生成的系统版本和保护源码免遭未授权修改的工具和 规程。通过技术、物理和保安规章三方面的结合，可充分保护生成系统所用到的源码免遭未授 权的修改和毁坏

包装标准4.3.3.2分发和操作

一般应按GB/T20271一2006中6.3.5.2的要求.从以下方面实现SSOOS的分发和操作： a）以文档形式提供对SSOOS安全地进行分发的过程，并对修改检测的过程进行说明，最终生成 安全的配置。文档中所描述的内容应包括： 提供分发的过程； 安全启动和操作的过程； ·· 建立日志的过程： 一修改内容的检测：

在故障或硬件、软件出错后恢复系统至安全状态的规程； 对含有加强安全性的硬件部件，应说明用户或自动的诊断测试的操作环境和使用方法； 所有诊断测试过程中，为加强安全性的硬件部件所提供例证的结果； 在启动和操作时产生审计踪迹输出的例证。 b）对系统的未授权修改的风险，应在交付时控制到最低限度。在包装及安全分送和安装过程 中，这种控制应采取软件控制系统的方式，确认安全性会由最终用户考虑，所有安全机制都应 以功能状态交付。 c）所有软件应提供安全安装默认值.在客户不做选择时，默认值应使安全机制有效地发挥安全 功能。 d) 随同系统交付的全部默认用户标识码，应在交付时处于非激活状态，并在使用前由管理员 激活。 e）用户文档应同交付的软件一起包装，并应有一套规程确保当前送给用户的系统软件是严格按 最新的系统版本来制作的。 f） 以安全方式开发并交付系统后，仍应提供对产品的长期维护和评估的支持，包括产品中的安全 漏洞和现场问题的解决。 g） 应采用书面说明的方式向客户通告新的安全问题。 h）对可能受到威胁的所有的安全问题，均应描述其特点，并作为主要的问题对待，直到它被解决 或在用户同意下降级使用。 i）为了支持已交付的软件的每个版本，对所有已有的安全漏洞都应有文档书面说明，并且用户能 在限制的基础上得到该文档。 对安全漏润的修改不必等到系统升级到下一个版本。安全功能的增加和改进应独立于系统版 本的升级，也就是说，应存在适应性独立于系统其他功能的改进。 k) 只有经过客户授权，才允许在生产性运行的系统上进行新特性和简易原型的开发、测试和 安装。

在故障或硬件、软件出错后伙复系统至安全状态的规程； 对含有加强安全性的硬件部件，应说明用户或自动的诊断测试的操作环境和使用方法； 所有诊断测试过程中，为加强安全性的硬件部件所提供例证的结果； 在启动和操作时产生审计踪迹输出的例证。 b）对系统的未授权修改的风险，应在交付时控制到最低限度。在包装及安全分送和安装过程 中，这种控制应采取软件控制系统的方式，确认安全性会由最终用户考虑，所有安全机制都应 以功能状态交付。 c）所有软件应提供安全安装默认值.在客户不做选择时，默认值应使安全机制有效地发挥安全 功能。 d) 随同系统交付的全部默认用户标识码，应在交付时处于非激活状态，并在使用前由管理员 激活。 e）用户文档应同交付的软件一起包装，并应有一套规程确保当前送给用户的系统软件是严格按 最新的系统版本来制作的。 f) 以安全方式开发并交付系统后，仍应提供对产品的长期维护和评估的支持，包括产品中的安全 漏洞和现场问题的解决。 g） 应采用书面说明的方式向客户通告新的安全问题。 h） 对可能受到威胁的所有的安全问题，均应描述其特点，并作为主要的问题对待，直到它被解决 或在用户同意下降级使用。 i）为了支持已交付的软件的每个版本，对所有已有的安全漏洞都应有文档书面说明，并且用户能 在限制的基础上得到该文档。 对安全漏润的修改不必等到系统升级到下一个版本。安全功能的增加和改进应独立于系统版 本的升级，也就是说，应存在适应性独立于系统其他功能的改进。 k） 只有经过客户授权，才允许在生产性运行的系统上进行新特性和简易原型的开发、测试和 安装。

新的版本应避免违反最初的安全策略和设想，也应避免在维护、增加或功能升级中引人安全漏 洞，所有功能的改变和安全结构设置的默认值都应作记录。在新版本交付给用户使用前，用 户应能得到相应的文档

一股应按GB/T20271一2006巾6.3.5.3的要求，从以下方面进行SS()OS的开发： a) 按非形式化安全策略模型、非形式化功能说明、完全定义的外部接口、安全加强的高层设计、 SSF完全实现、SSF内部结构层次化、描述性低层设计、非形式化对应作说明的要求，进行 SSOOS的开发。 b） 系统的设计和开发应保扩数据的完整性，例如.检查数据更新的规则、二重/多重输人的正确 处理、返回状态的检查、中间结果的检食、合理值输人检查、事务处理更新的正确性检查等。 在内部代码检查时，应解决潜在的安全缺陷，关闭或取消所有的后门。 d) 所有交付的软件和文档，应进行关于安全缺陷的定期的和书面的检查，并将检查结果告知 用户。 e 山系统控制的敏感数据，如口令和密钥等，不应在未受保护的程序或文档中以明文形式储存。 应以书面形式向用户提供关于软件所有权法律保护的指南， 在操作系统开发的敏感阶段，应保持一个安全环境，该安全环境要求： 描述操作系统开发所使用的计算机系统的安全使用和维护情况的安全策略和措施应有 书面记载，并可供检查；

免费标准下载网(ww.freebz.n

稀土标准4.3.3.4文档要求