GB/T 20272-2006 信息安全技术 操作系统安全技术要求

ICS35.040

L80OB

中华人民共和国国家标准

GB/T20272—2006

信息安全技术

操作系统安全技术要求

Informationsecuritytechnology—

Securitytechniquesrequirementforoperatingsystem

2006-05-31发布2006-12-01实施

发布

GB/T20272—2006

目次

前言ni

引言N

1范围1

2规范性引用文件1

3术语、定义和缩略语1

3.1术语和定义1

3.2缩略语2

4安全等级保护分等级技术要求2

4.1第一级:用户自主保护级2

4.1.1安全功能2

4.1.2SSOOS自身安全保护3

4.1.3SSOOS设计和实现3

4.1.4SSOOS安全管理5

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

4.2.1安全功能5

4.2.2SSOOS自身安全保护7

4.2.3SSOOS设计和实现8

4.2.4SSOOS安全管理10

4.3第三级：安全标记保护级11

4.3.1安全功能11

4.3.2SSOOS自身安全保护14

4.3.3SSOOS设计和实现15

4.3.4SSOOS安全管理19

4.4第四级：结构化保护级19

4.4.1安全功能19

4.4.2SSOOS自身安全保护22

4.4.3SSOOS设计和实现24

4.4.4SSOOS安全管理27

4.5第五级：访问验证保护级28

4.5.1安全功能28

4.5.2SSOOS自身安全保护31

4.5.3SSOOS设计和实现33

4.5.4SSOOS安全管理36

附录A（资料性附录）标准概念说明37

A.1组成与相互关系37

A.2关于安全保护等级划分的说明37

A.3关于主体、客体的进一步说明38

T

GB/T20272—2006

A.4关于SS()()S、SSF、SSP、SFP及其相互关系38

A.5关于密码技术的说明38

参考文献39

D

GB/T20272—2006

前言

本标准的附录A是资料性附录。

本标准由全国信息安全标准化技术委员会提出并归口。

本标准起草单位:北京思源新创信息安全资讯有限公司，江南计算技术研究所技术服务中心。

本标准主要起草人：吉增瑞、汪晓茵、王志强、陈冠直、景乾元、宋健平。

ni

GB/T20272—2006

引言

本标准用以指导设计者如何设计和实现具有所需要的安全保护等级的操作系统，主要说明为实现

GB17859-1999中每一个安全保护等级的要求，操作系统应采取的安全技术措施，以及各安全技术要

求在不同安全保护等级中具体实现上的差异。

计算机操作系统是信息系统的重要组成部分。计算机操作系统的主要功能是进行计算机资源管理

和提供用户使用计算机的界面。操作系统所管理的资源包括各种用户资源和计算机的系统资源。用户

资源可以归结为以文件形式表示的数据信息资源。系统资源包括系统程序和系统数据以及为管理计算

机硬件资源而设置的各种表格，其在操作系统中也都是以文件的形式表现，分别称为可执行文件、数据

文件、配置文件等。可见，对操作系统中资源的保护，实际上是对操作系统中文件的保护。由于操作系

统在计算机系统中有着十分重要的地位和作用，所以对计算机系统的攻击和威胁（包括人为的和自然

的），操作系统往往成为主要的目标。也正因为如此，操作系统的安全就变得十分重要。操作系统安全

既要考虑操作系统的安全运行，也要考虑对操作系统中资源的保护（主要是以文件形式表示的数据信息

资源的保护）。由于攻击和威胁既可能是针对系统运行的，也可能是针对信息的保密性、完整性和可用

性的，所以对操作系统的安全保护的功能要求，需要从操作系统的安全运行和操作系统数据的安全保护

两方面综合进行考虑。根据GB17859—1999所列安全要素及GB/T20271—2006关于信息系统安全

功能要素的描述，本标准从身份鉴别、自主访问控制、标记和强制访问控制、数据流控制、审计、数据完

整性、数据保密性、可信路径等方面对操作系统的安全功能要求进行更加具体的描述。为了确保安全功

能要素达到所确定的安全性要求，需要通过一定的安全保证机制来实现，根据GB/T20271-2006关于

信息系统安全保证要素的描述，本标准从操作系统安全子系统（SSOOS自身安全保护、操作系统安全

子系统（SSOOS的设计和实现以及操作系统安全子系统（SSOOS的安全管理等方面，对操作系统的安

全保证要求进行更加具体的描述。操作系统的安全还需要有相应的安全硬件系统（即物理安全）方面的

支持，以及安全管理方面的支持，这已超出本标准的范围。

综合以上说明，本标准以GB17859—1999五个安全保护等级的划分为基础，对操作系统的每一个

安全保护等级的安全功能技术要求和安全保证技术要求做详细的描述。为清晰表示每一个安全等级比

较低一级安全等级的安全技术要求的增加和增强，在第4章的描述中，每一级新增部分用“宋体加粗字”

表不。

GB/T20272—2006

信息安全技术操作系统安全技术要求

1范围

本标准依据GB17859-1999的五个安全保护等级的划分，根据操作系统在信息系统中的作用，规

定了各个安全等级的操作系统所需要的安全技术要求。

本标准适用于按等级化要求进行的操作系统安全的设计和实现，对按等级化要求进行的操作系统

安全的测试和管理可参照使用。

2规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有

的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究

是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。

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

GB/T20271-2006信息安全技术信息系统通用安全技术要求

3术语、定义和缩略语

3.1术语和定义

GB17859—1999和GB/T20271—2006确立的以及下列术语和定义适用于本标准。

3.1.1

操作系统安全securityofoperatingsystem

操作系统所存储、传输和处理的信息的保密性、完整性和可用性的表征。

3.1.2

操作系统安全技术securitytechnologyofoperatingsystem

实现各种类型的操作系统安全需要的所有安全技术。

3.1.3

操作系统安全子系统securitysubsystemofoperatingsystem

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

一个基本的操作系统安全保护环境，并提供安全操作系统要求的附加用户服务。

注：按照GB17859—1999对TCB（可信计算基）的定义，SSOOS（操作系统安全子系统）就是操作系统的TCB。

3.1.4

SSOOS安全策略SSOOSsecuritypolicy

对SSOOS中的资源进行管理、保护和分配的一组规则。一个SSOOS中可以有一个或多个安全

策略。

3.1.5

安全功能策略securityfunctionpolicy

为实现SSOOS安全要素要求的功能所采用的安全策略。

3.1.6

安全要素securityelement

本标准中各安全保护等级的安全技术要求所包含的安全内容的组成成分。

1

GB/T20272—2006

3.1.7

SSOOS安全功能SSOOSsecurityfunction

正确实施SSOOS安全策略的全部硬件、固件、软件所提供的功能。每一个安全策略的实现，组成

一个SSOOS安全功能模块。一个SSOOS的所有安全功能模块共同组成该SSOOS的安全功能。

3.1.8

SSF控制范围SSFscopeofcontrol

SSOOS的操作所涉及的主体和客体的范围。

3.2缩略语

下列缩略语适用于本标准：

SFP安全功能策略securityfunctionpolicy

SSCSSF控制范围SSFscopeofcontrol

SSFSSOOS安全功能SSOOSsecurityfunction

SSOOS操作系统安全子系统securitysubsystemofoperatingsystem

SSPSSOOS安全策略SSOOSsecuritypolicy

4安全等级保护分等级技术要求

4.1第一级：用户自主保护级

4.1.1安全功能

4.1.1.1身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。可按GB/T20271-2006中6.1.3.1的要求，从以

下方面设计和实现操作系统的身份鉴别功能：

a按GB/T20271—2006中6.1.3.1.1和以下要求设计和实现用户标识功能：

——凡需进入操作系统的用户，应先进行标识（建立账号）；

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

b按GB/T20271—2006中6.1.3.1.2和以下要求设计和实现用户鉴别功能：

——采用口令进行鉴别，并在每次用户登录系统时进行鉴别；

——口令应是不可见的，并在存储时有安全保护；

—通过对不成功的鉴别尝试的值（包括尝试次数和吋间的阈值）进行预先定义，并明确规定

达到该值时应采取的措施来实现鉴别失败的处理。

c对注册到操作系统的用户，应按以下要求设计和实现用户一主体绑定功能：

-将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户；

-将注系统进程动态地与当前服务要求者用户相关联，使系统进程的行为可以追溯到当前

服务的要求者用户。

4.1.1.2自主访问控制

可按GB/T20271—2006中6.1.3.2的要求，从以下方面设计和实现操作系统的自主访问控制

功能：

a允许命名用户以用户和/或用户组的身份规定并控制对客体的访问，并阻止非授权用户对客体

访问；

b设置默认功能，当一个主体生成一个客体时，在该客体的访问控制表中相应地应具有该主体

设置的默认值。

4.1.1.3用户数据完整性

可按GB/T20271—2006中6.1.3.3的要求，对操作系统内部传输的用户数据完整性保护，如进程

间通信数据的完整性保护，设计和实现操作系统的用户数据完整性保护功能。

2

GB/T20272—2006

4.1.2SSOOS自身安全保护

4.1.2.1SSF物理安全保护

可按GB/T20271—2006中6.1.4.1的要求，实现SSF的物理安全保护，通过对物理安全的检查，

发现以物理方式的攻击对SSF造成的威胁和破坏。

4.1.2.2SSF运行安全保护

可按GB/T20271—2006中6.1.4.2的要求，从以下方面实现SSF的运行安全保护：

a系统在设计吋不应留有“后门”，即不应以维护、支持或操作需要为借口，设计有违反或绕过安

全规则的任何类型的入口和文档中未说明的任何模式的入口。

b安全结构应是一个独立的、严格定义的系统软件的一个子集，并应防止外部干扰和破坏，如修

改其代码或数据结构。

c操作系统程序与用户程序要进行隔离。一个进程的虚地址空间至少应被分为两个段：用户空

间和系统空间，两者的隔离应是静态的。驻留在内存中的操作系统应由所有进程共享。用户

进程之间应是彼此隔离的。应禁止在用户模式下运行的进程对系统段进行写操作，而在系统

模式下运行吋，应允许进程对所有的虚存空间进行读、写操作。

d提供一个设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护

之前，应对用户和管理员的安全策略属性进行定义。

e区分普通操作模式和系统维护模式，

D补丁的发布和运用：补丁是对操作系统安全漏洞进行修补的程序的总称。操作系统的开发者

应针对发现的漏洞及吋发布补丁。操作系统的管理者应及吋运用补丁对操作系统的漏洞进行

修补。

g在SSOOS失败或中断后，应保护其以最小的损害得到恢复，并按照失败保护中所描述的内

容，实现对SSF出现失败时的处理。

4.1.2.3SSF数据安全保护

可按GB/T20271—2006中6.1.4.3的要求，对在SSOOS内传输的SSF数据，实现SSOOS内

SSF数据传输的基本保护。

4.1.2.4资源利用

可按GB/T20271—2006中6.1.4.4的要求，从以下方面实现SSOOS的资源利用：

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

b采取适当的策略，按有限服务优先级，提供主体使用TSC内某个资源子集的优先级，进行

SSOOS资源的管理和分配；

c按资源分配中最大限额的要求，进行SSOOS资源的管理和分配，要求配额机制确保用户和主

体将不会独占某种受控的资源。

4.1.2.5SSOOS访问控制

可按GB/T20271—2006中6.1.4.5的要求，从以下方面实现SSOOS的访问控制：

a按会话建立机制的要求，对会话建立的管理进行设计。

b按多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，

SSF应限制系统的并发会话的最大数量，并应利用默认值作为会话次数的限定数。

c按可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试，对用来建立会话的

安全属性的范围进行限制。

4.1.3SSOOS设计和实现

4.1.3.1配置管理

可按GB/T20271—2006中6.1.5.1的要求，实现具有基本配置管理能力的SSOOS的配置管理，

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

3

GB/T20272—2006

4.1.3.2分发和操作

可按GB/T20271—2006中6.1.5.2的要求，从以下方面实现SSOOS的分发和操作：

a以文档形式提供对SSOOS安全地进行分发的过程，并对安装、生成和启动的过程进行说明，

最终生成安全的配置。文档中所描述的内容应包括：

提供分发的过程；

——安全启动和操作的过程。

b对系统的未授权修改的风险，应在交付时控制到最低限度。在包装及安全分送和安装过程

中，这种控制应采取软件控制系统的方式，确认安全性会由最终用户考虑，所有安全机制都应

以功能状态交付。

c所有软件应提供安全安装默认值，在客户不做选择时，默认值应使安全机制有效地发挥作用。

d随同系统交付的全部默认用户标识码，应在交付吋处于非激活状态，并在使用前由管理员

激活。

e用户文档应同交付的软件一起包装，并应有一套规程确保当前送给用户的系统软件是严格按

最新的系统版本来制作的。

4.1.3.3开发

可按GB/T20271—2006中6.1.5.3的要求，从以下方面进行SSOOS的开发：

a按非形式化功能说明、描述性高层设计、SSF子集实现、SSF内部结构模块化、描述性低层设计

和非形式化对应性说明的要求，进行SSOOS的设计；

b系统的设计和开发应保护数据的完整性，例如，检查数据更新的规则、二重或多重输入的正确

处理、返回状态的检查、中间结果的检查、合理值输入检查、事务处理更新的正确性检查等；

c在内部代码检查时，应解决潜在的安全缺陷，关闭或取消所有的后门；

d所有交付的软件和文档，应进行关于安全缺陷的定期的和书面的检查，并将检查结果告知

用户；

e由系统控制的敏感数据，如口令和密钥等，不应在未受保护的程序或文档中以明文形式储存；

f应以书面形式向用户提供关于软件所有权法律保护的指南。

4.1.3.4文档要求

可按GB/T20271—2006中6.1.5.4的要求，从以下方面编制SSOOS的文档：

a用户文档应提供关于不同用户的可见的安全机制以及如何利用它们的信息，并解释它们的用

途和提供有关它们使用的指南；

b安全管理员文档应提供有关如何设置、维护和分析系统安全的详细指导，包括当运行一个安

全设备时，需要控制的有关功能和特权的警告，以及与安全有关的管理员功能的详细描述，包

括增加和删除一个用户、改变用户的安全特征等；

c文档中不应提供任何一旦泄露将会危及系统安全的信息，有关安全的指令和文档应划分等级

分别提供给用户、系统管理员和系统安全员。

4.1.3.5生存周期支持

可按GB/T20271—2006中6.1.5.5的要求，从以下方面实现SSOOS的生存周期支持：

a按开发者定义生存周期模型进行开发；

b提供安全安装默认值；在未做特殊选择时，应按默认值安装安全机制；

c随同系统交付的全部默认用户标识号，在刚安装完时应处于非激活状态，并由系统管理员加以

激活；

d操作文档应详细阐述安全启动和操作的过程，详细说明安全功能在启动、正常操作维护吋是

否能被撤消或修改，说明在故障或系统出错吋如何恢复系统至安全状态。

4

GB/T20272—2006

4.1.3.6测试

可按GB/T20271—2006中6.1.5.6的要求，从以下方面对SSOOS进行测试：

a通过一般功能测试和相符独立性测试，确认SSOOS的功能与所要求的功能相一致；

b所有系统的安全特性，应被全面测试；

c所有发现的漏洞应被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除，

且没有引出新的漏洞；

d提供测试文档，详细描述测试计划、测试过程、测试结果。

4.1.4SSOOS安全管理

可按GB/T20271—2006中6.1.6的要求，实现SSOOS的安全管理，对相应的SSOOS的访问控

制、鉴别控制、安全属性管理等相关的功能，以及与一般的安装、配置等有关的功能，制定相应的操作、运

行规程和行为规章制度。

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

4.2.1安全功能

4.2.1.1身份鉴别

身份鉴别包括对用户的身份进行标识和鉴别。应按GB/T20271-2006中6.2.3.1的要求，从以

下方面设计和实现操作系统的身份鉴别功能：

a按GB/T20271—2006中6.2.3.1.1和以下要求设计和实现用户标识功能：

——凡需进入操作系统的用户，应先进行标识（建立账号）；

-操作系统用户标识应使用用户名和用户标识（UID,并在操作系统的整个生存周期实现

用户的唯一性标识，以及用户名或别名、UID等之间的一致性。

b按GB/T20271-2006中6.2.3.1.2和以下要求设计和实现用户鉴别功能：

—采用强化管理的口令鉴别/基于令牌的动态口令鉴别等机制进行身份鉴别，并在每次用

户登录系统时进行鉴别；

——鉴别信息应是不可见的，并在存储和传输吋进行安全保护；

—通过对不成功的鉴别尝试的值（包括尝试次数和时间的阈值）进行预先定义，并明确规定

达到该值吋应采取的措施来实现鉴别失败的处理。

0对注册到操作系统的用户，应按以下要求设计和实现用户一主体绑定功能：

-将用户进程与所有者用户相关联，使用户进程的行为可以追溯到进程的所有者用户；

-将注系统进程动态地与当前服务要求者用户相关联，使系统进程的行为可以追溯到当前

服务的要求者用户。

4.2.1.2自主访问控制

按GB/T20271-2006中6.2.3.2的要求，从以下方面设计和实现操作系统的自主访问控制功能:

a允许命名用户以用户的身份规定并控制对客体的访问，并阻止非授权用户对客体的访问。

b设置默认功能，当一个主体生成一个客体吋，在该客体的访问控制表中相应地具有该主体设

置的默认值。

c有更细粒度的自主访问控制，将访问控制的粒度控制在单个用户；对系统中的每一个客体，都

能够实现由客体的创建者以用户指定方式确定其对该客体的访问权限，而别的同组用户或非

同组的用户和用户组对该客体的访问权则由创建者用户授予。

d自主访问控制能与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成

功的或不成功的访问，使用户对自己的行为承担明确的责任。

e客体的拥有者应是唯一有权修改客体访问权限的主体，拥有者对其拥有的客体应具有全部控

制权，但是，不允许客体拥有者把该客体的控制权分配给其他主体。

D定义访问控制属性，并保护这些属性；主体的访问控制属性至少应有：读、写、执行等；客体的访

5

GB/T20272—2006

问控制属性应包含可分配给主体的读、写和执行等权限。

g定义分配和修改主体和客体的访问控制属性的规则，并执行对主体和客体的访问控制属性的

分配和修改，规则的结果应达到只有被授权的用户才允许访问一个客体。

h定义主体对客体的访问授权规则；该规则应基于主体对客体的访问控制属性，同时应指出主

体和客体对这些规则应用的类型。

4.2.1.3安全审计

按GB/T20271-2006中6.2.2.3的要求，从以下方面设计和实现操作系统的安全审计功能：

a安全审计功能应与身份鉴别、自主访问控制等安全功能紧密结合。

b提供审计日志，潜在侵害分析，基本审计查阅和有限审计查阅，安全审计事件选择，以及受保

护的审计踪迹存储等功能。

c能够生成、维护及保护审计过程,使其免遭修改、非法访问及破坏，特别要保护审计数据，要严

格限制未经授权的用户访问。

d能够创建并维护一个对受保护客体访问的审计踪踪，保护审计记录不被未授权的访问、修改

和破坏。

e指出可记录的审计事件的最少类型，包括建立会话登录成功和失败、使用的系统接口、系统数

据库管理的改变（改变用户账户属性、审计跟踪设置和分析、为程序分配设置用户ID、附加或

改变系统程序或进程、改变日期和吋间等），超级用户命令改变用户身份、将某个客体引入某个

用户的地址空间（如打开文件）、删除客体、系统管理员及系统安全管理员进行的操作等。当审

计激活时应确保审计跟踪事件的完整性;应提供一个机制来显示当前选择的审计事件，这个机

制的使用者应是有限的授权用户。

f每个事件的数据记录，应包括的信息有：事件发生的日期和时间、触发事件的用户、事件的类

型、事件成功或失败等。对于身份标识和鉴别事件，应记录请求的源（如末端号或网络地址）；

对于创建和删除客体的事件，应记录客体的名字和客体的安全属性°

g应提供一个受保护的打开和关闭审计的机制。该机制能选择和改变审计事件，并在系统工作

时处于默认状态；该机制的使用应受到系统管理员的授权限制，系统管理员应能够选择一个或

多个基于身份鉴别或客体属性的用户的审计活动；审计工具应能够授权个人使用、修改和删除

审计;应提供对审计跟踪管理功能的保护，使之可以完成审计跟踪的创建、破坏、腾空和存档；

系统管理员应能够定义超过审计跟踪极限的阈值；当存储空间被耗尽吋，应能按管理员的指定

决定采取的措施，包括:报警并丢弃未记录的审计信息、暂停审计、覆盖以前的审计记录等。

4.2.1.4用户数据完整性

按GB/T20271—2006中6.2.3.3的要求，从以下方面设计和实现操作系统的用户数据完整性保

护功能：

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

统对磁盘设备中存储的数据，可通过增加磁盘扫描程序实现以下功能：

——自动检查文件与磁盘表面是否完好；

——将磁盘表面的问题自动记录下来；

——随吋检查、诊断磁盘上的错误。

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

c对操作系统中处理的用户数据，应按回退的要求设计相应的SSOOS安全功能模块，进行异常

情况的操作序列回退，以确保用户数据的完整性。

4.2.1.5用户数据保密性

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

护功能：

6

GB/T20272—2006

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

不能查找系统现已分配给他的记录介质中以前的信息内容。

b在单用户系统中，存储器保护应防止用户进程影响系统的运行。

c在多用户系统中，存储器保护应保证系统内各个用户之间互不干扰。

d存储器保护应包括：

——对存储单元的地址的保护，使非法用户不能访问那些受到保护的存储单元；

-对被保护的存储单元的操作提供各种类型的保护，最基本的保护类型是“读/写”和“只

读”,不能读/写的存储单元，若被读/写时，系统应及时发出警报或中断程序执行；

-可采用逻辑隔离的方法进行存储器保护，具体有：界限地址寄存器保护法、内存标志法、

锁保护法和特征位保护法等。

4.2.2SSOOS自身安全保护

4.2.2.1SSF物理安全保护

按GB/T20271—2006中6.2.4.1的要求，实现SSF的物理安全保护，通过对物理攻击的检查，发

现以物理方式的攻击对SSF造成的威胁和破坏。

4.2.2.2SSF运行安全保护

按GB/T20271—2006中6.2.4.2的要求，从以下方面实现SSF的运行安全保护：

a系统在设计时不应留有“后门”。即不应以维护、支持或操作需要为借口，设计有违反或绕过安

全规则的任何类型的入口和文档中未说明的任何模式的入口。

b安全结构应是一个独立的、严格定义的系统软件的一个子集，并应防止外部干扰和破坏，如修

改其代码或数据结构。

c操作系统程序与用户程序要进行隔离。一个进程的虚地址空间至少应被分为两个段：用户空

间和系统空间，两者的隔离应是静态的。驻留在内存中的操作系统应由所有进程共享。用户

进稈之间应是彼此隔离的.应禁止在用户模式下运行的进程对系统段进行写操作，而在系统

模式下运行时，应允许进程对所有的虚存空间进行读、写操作。

d提供设置和升级配置参数的安装机制。在初始化和对与安全有关的数据结构进行保护之前，

应对用户和管理员的安全策略属性应进行定义。

e应区分普通操作模式和系统维护模式。

f应防止一个普通用户从未经允许的系统进入维护模式，并应防止一个普通用户与系统内维护

模式交互。从而保证在普通用户访问系统之前，系统能以一个安全的方式进行安装和配置。

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

h当操作系统安装完成后，在普通用户访问之前，系统应配置好初始用户和管理员职责、根目

录、审计参数、系统审计跟踪设置以及对文件和目录的合适的访问控制。

i）执行系统所提供的实用程序，应（默认地）限定于对系统的有效使用，只允许系统管理员修改或

替换系统提供的实用程序。

J）操作环境应为用户提供一个机制，来控制命令的目录/路径的查找顺序。

k在SSOOS失败或中断后，应确保其以最小的损害得到恢复。并按失败保护中所描述的内容,

实现对SSF出现失败吋的处理。

D操作系统环境应控制和审计系统控制台的使用情况。

m补丁的发布、管理和使用：补丁是对操作系统安全漏洞进行修补的程序的总称。操作系统的

开发者应针对发现的漏洞及时发布补丁。操作系统的管理者应及时获取、统一管理并及时运

用补丁对操作系统的漏洞进行修补，

4.2.2.3SSF数据安全保护

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

7

GB/T20272—2006

a实现SSOOS内SSF数据传输的基本保护；

bSSOOS内SSF数据复制的一致性保护。

4.2.2.4资源利用

按GB/T20271—2006中6.2.4.4的要求，从以下方面实现SSOOS的资源利用：

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

测和报告系统的服务水平已降低到预先规定的最小值；

b应采取适当的策略，有限服务优先级提供主体使用TSC内某个资源子集的优先级，进行

SSOOS资源的管理和分配；

c应按资源分配中最大限额的要求，进行SSOOS资源的管理和分配，要求配额机制确保用户和

主体将不会独占某种受控的资源；

d系统应确保在被授权的主体发出请求吋，资源能被访问和利用；

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

f系统应提供维护状态中运行的能力•在维护状态下各种安全性能全部失效，系统只允许由系统

管理员使用；

g系统应以每个用户或每个用户组为基础，提供一种机制，控制他们对磁盘的消耗和对CPU的

使用。

4.2.2.5SSOOS访问控制

按GB/T20271—2006中6.2.4.5的要求，从以下方面实现SSOOS的访问控制：

a按会话建立机制的要求，对会话建立的管理进行设计。在建立SSOOS会话之前，应鉴别用户

的身份。登录机制不允许鉴别机制本身被旁路。

b按多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上，

SSF应限制系统的并发会话的最大数量，并应利用默认值作为会话次数的限定数。

c按可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试，对用来建立会话的

安全属性的范围进行限制。

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

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

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

——应显示口令到期的天数；

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

4.2.3SSOOS设计和实现

4.2.3.1配置管理

按GB/T20271—2006中6.2.5.1的要求，从以下方面实现SSOOS的配置管理：

a在配置管理能力方面应实现对版本号等方面的要求。

b在SSOOS的配置管理范围方面，应将SSOOS的实现表示、设计文档、测试文档、用户文档、管

理员文档以及配置管理文档等置于配置管理之下。

c在系统的整个生存期，即在它的开发、测试和维护期间，应有一个软件配置管理系统处于保持

对改变源码和文件的控制状态。只有被授权的代码和代码修改才允许被加进已交付的源码的

基本部分。所有改变应被记载和检查，以确保未危及系统的安全。在软件配置管理系统中，应

包含从源码产生出系统新版本、鉴定新生成的系统版本和保护源码免遭未授权修改的工具和

规程。通过技术、物理和保安规章三方面的结合，可充分保护生成系统所用到的源码免遭未授

权的修改和毁坏。

4.2.3.2分发和操作

按GB/T20271—2006中6.2.5.2的要求，从以下方面实现SSOOS的分发和操作：

8

GB/T20272—2006

a应以文档形式提供对SSOOS安全地进行分发的过程，并对安装、生成和启动的过程进行说

明，最终生成安全的配置。文档中所描述的内容应包括：

——提供分发的过程；

——安全启动和操作的过程；

——建立日志的过程。

b对系统的未授权修改的风险，应在交付时控制到最低限度。在包装及安全分送和安装过程

中，这种控制应采取软件控制系统的方式，确认安全性会由最终用户考虑，所有安全机制都应

以功能状态交付。

c所有软件应提供安全安装默认值，在客户不做选择吋，默认值应使安全机制有效地发挥安全

功能。

d随同系统交付的全部默认用户标识码，应在交付时处于非激活状态，并在使用前由管理员

激活。

e用户文档应同交付的软件一起包装，并应有一套规程确保当前送给用户的系统软件是严格按

最新的系统版本来制作的。

4.2.3.3开发

按GB/T20271—2006中6.2.5.3的要求，从以下方面进行SSOOS的开发：

a要求按非形式化安全策略模型、完全定义的外部接口、描述性高层设计、SSF子集实现、SSF内

部结构层次化、描述性低层设计、非形式化对应性说明的要求，进行SSOOS的设计；

b系统的设计和开发应保护数据的完整性，例如，检查数据更新的规则、二重/多重输入的正确

处理、返回状态的检查、中间结果的检查、合理值输入检查、事务处理更新的正确性检查等；

c在内部代码检查时，应解决潜在的安全缺陷，关闭或取消所有的后门；

d所有交付的软件和文档，应进行关于安全缺陷的定期的和书面的检查，并将检查结果告知

用户；

e由系统控制的敏感数据，如口令和密钥等