GBT 20273-2006 信息安全技术 数据库管理系统安全技术要求

实体完整性bodyintegrity

关系模型中的实体完整性是指关系表中字段级的完整性，即数据类型及取值的合理性。实体完 见则要求，数据库中表示的任一实体是可区分的。对于关系模型，实体完整性表现为关系的主属 本键：主键/主码)不能是空值（NULL），也不能是重复值，即基本键的各个分量都不能为空。 11

装饰标准规范范本参照完整性referenceintegrity

关系模型中的参照完整性是指主码值和外码值表间的一致性。参照完整性规则要求，在任一时 关系R1的某些属性是关于关系R2的外键，则该外键的值必须是R2中某元组的主键值或为“ （空值意味着“不知道”的信息和“无意义”的信息）。参照完整性规则是“连接”关系运算正确执行

用户定义完整性userdefinedintegrity

关系模型中的用户定义完整性是指字段与表之间的断言关系（即业务规则）的正确性，也就是根据 业务规则（比如价格的有效范围等）所确定的完整性约束。系统提供定义和检查用户定义完整性规则的 机制，其目的是用统一的方式由系统处理，而不是由应用程序完成，这样不仅可以简化应用程序，还提高 了完整性保证的可靠性。

下列缩略语适用于本标准： SFP 安全功能策略 securityfunctionpolicy SSC SSF控制范围SSFscopeofcontrol SSF SSODB安全功能SSODBsecurityfunction SSODB 数据库管理系统安全子系统securitysubsystemofdatabasemanagementsystem SSP SSODB安全策路SSODBsecuritypolicy

4数据库管理系统安全功能基本要求

4. 1. 1 用户标识

实现。为了管理方便，可将用户分组，也可使用别名。无论用户名、用户ID、用户组还是用户别名 要遵守标识的唯一性原则。用户标识分为： a）基本标识：应在SSF实施所要求的动作之前，先对提出该动作要求的用户进行标识；

GB/T202732006

4. 1. 2用户监别

应对登录到数据库管理系统的用户进行身份真实性鉴别。通过对用户所提供的“鉴别信息”的验 证，证明该用户确有所声称的某种身份，这些“鉴别信息”必须是保密的，不易伪造的。用户鉴别分为： a）基本鉴别：应在SSF实施所要求地动作之前，先对提出该动作要求的用户成功地进行鉴别。 b）不可伪造鉴别：应检测并防止使用伪造或复制的鉴别数据。一方面，要求SSF应检测或防止 由任何别的用户伪造的鉴别数据，另一方面，要求SSF应检测或防止当前用户从任何其他用 户处复制的鉴别数据的使用。 c）一次性使用鉴别：应能提供一次性使用鉴别数据操作的鉴别机制，即SSF应防止与已标识过 的鉴别机制有关的鉴别数据的重用， d 多机制鉴别：应能提供不同的鉴别机制，用于鉴别特定事件的用户身份，并且SSF应根据所描 述的多种鉴别机制如何提供鉴别的规则，来鉴别任何用户所声称的身份。 e 重新鉴别：应有能力规定需要重新鉴别用户的事件，即SSF应在需要重鉴别的条件表所指示 的条件下，重新鉴别用户。例如，用户终端操作超时被断开后，重新连接时需要进行重鉴别。

应由数据库子语言定义，并与数据起存放在数据字典中。对任何SQL对象进行操作应有明确 限许可，并且权限随操作和对象的变化而变化，安全系统应有能力判断这种权限许可。操作与双 密相联，即把“操作十对象”作为一个授权。表1是GRANT（授权）语句对象类型与相关操作的举

表1GRANT语句的对象类型与相关操作

应以访问控制表或访问类 制程序实现。每当执行SQI 实现对访问要求的控制。

4.2.3授权传播限制

应限制具有某一权限的用户将该权限传给其他用户。当一个用户被授予某权限，同时拥有将该 授予其他用户的权力时，该用户才拥有对该授权的传播权。为了增强数据库系统的安全性，需要对 传播进行某些限制。

SSF应为主体指定敏感标记，这些敏感标记是等级分类和非等级类别的组合，是实施强制 的依据：

SSF应为客体指定敏感标记，这些敏感标记是等级分类和非等级类别的组合，是实施强制访问控 衣据。

4.4.1访问控制安全策略

4.4.2访问控制粒度及特点

应根据数据库特点和不同安全保护等级的不同要求，实现不同粒度的访问控制。这些特点主要是： a） 数据以特定结构格式存放，客体的粒度可以是：关系数据库的表、视图、元组（记录）、列（字段） 元素（每个元组的字段）、日志、片段、分区、快照、约束和规则、DBMS核心代码、用户应用程序、 存储过程、触发器、各种访问接口等； b 数据库系统有完整定义的访问操作，如表1所示； 数据库是数据与逻辑的统一，数据库中不仅存放了数据，还存放了大量的用于管理和使用这些 数据的程序，这些程序和数据同样需要进行保护，以防止未授权的使用、篡改、增加或破坏； 数据库中的三级结构（物理结构、逻辑结构、概念模型结构）和两种数据独立性（物理独立性、 逻辑独立性)大大减轻数据库应用程序的维护工作量，但是由于不同的逻辑结构可能对应于相 同的物理结构，给访问控制带来新的问题，应对访问规则进行一致性检查； e 分布式数据库管理系统中，全局应用的访问控制应在全局DBMS层实现，局部应用的访问控 制应在局部DBMS层实现，并根据需要各自选择不同的访问控制策略

在以数据流方式实现数据流动的数据库管理系统中，应采用数据流控制机制实现对数据流动的 以防止有高等级安全的数据信息向低等级的区域流动。

数据库管理系统的安全审计应： a) 建立独立的安全审计系统； b) 定义与数据库安全相关的审计事件； c) 设置专门的安全审计员； d) 设置专门用于存储数据库系统审计数据的安全审计库； e）提供适用于数据库系统的安全审计设置、分析和查阅的工具。

a）数据库管理系统应确保数据库中的用户数据具有实体完整性和参照完整性。关系之间的参

完整性规则是“连接”关系运算正确执行的前提。 用户定义基本表时，应说明主键、外键，被引用表、列和引用行为。当数据录人、更新、删除时， 应由数据库管理系统根据说明自动维护实体完整性和参照完整性

4.7.2用户定义完整性

a）数据库管理系统应提供支持用户定义完整性的功能。系统应提供定义和检查用户定义完整性 规则的机制，其目的是用统一的方式由系统处理，而不是由应用程序完成，从而不仅可以简化 应用程序，还提高了完整性保证的可靠性。 b 数据库管理系统应支持为约束或断言命名（或提供默认名称），定义检查时间、延迟模式或设 置默认检查时间和延迟模式，支持约束和断言的撤消

4.7.3数据操作的完整性

数据操作的完整性药束为： a） 用户定义基本表时应定义主键和外键； b) 对于候选键，应由用户指明其唯一性； c) 对于外键，用户应指明被引用关系和引用行为； d) 应由数据库管理系统检查对主键、外键、候选键数据操作是否符合完整性要求，不允许提交任 何违反完整性的事务； e) 除或更新某元组时，数据库管理系统应检查该元组是否含有外键，若有，应根据用户预定义 的引用行为进行删除

数据库管理系统应确保数据库中存储的用户数据的保密性，

数据库管理系统应确保数据库中存储的用户数据的保密性 4.8.2传输数据保密性 数据库管理系统应确保数据库中传输的用户数据的保密性

数据库管理系统大量使用的动态资源，多由操作系统分配。实现客体安全重用的操作系统和数据 库管理系统应满足以下要求： a）数据库管理系统提出资源分配要求，如创建新库、数据库设备初始化等，所得到的资源不应包 含该客体以前的任何信息内容； b） 数据库管理系统提出资源索回要求，应确保这些资源中的全部信息被清除； 数据库管理系统要求创建新的数据库用户进程，应确保分配给每个进程的资源不包含残留 信息； d）数据库管理系统应确保已经被删除或被释放的信自不再是可用的

在数据库用户进行注册或进行其他安全性操作时，应提供SSODB与用户之间的可信通信通路 用户与SSF间的安全数据交换。

应采用推理控制的方法防止数据库中的用户数据被非授权地获取。运用推理方法获取权限以： 文据库信息，是一种较为隐蔽的信息攻击方法。在具有较高安全级别要求的数据库系统中，应考虑文 攻击的防御。

5数据库管理系统安全技术分等级要求

5.1第一级：用户自主保

5. 1. 1 安全功能

5:1.1.1身份鉴别

5.1.1.2自主访问控制

可根据4.2中访问操作、访同规则和投 设计和实现数据库管理系统的自主访问控制功能，允许命名用户以用户和/或用户组的身份规定并控制 对客体的访问，并阻止非授权用户对客体的访问。

5.1.1.3用户数据完整性

5.1.2.SSODB自身安全保护

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

5.1.2.2SSF运行安全保护

5.1.23SSF数据安全保护

数据传输的基本保护。

5.1.2.4资源利用

GB/T 20273—2006

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

5.1.2.5SSODB访问控制

按GB/1 a) 按会话建立机制，对会话建立的管理进行设计； b) 按多重并发会话限定中基本限定的要求，进行会话管理的设计。在基于基本标识的基础上， SSF应限制系统的并发会话的最大数量，并应利用认值作为会话次数的限定数； c) 按可选属性范围限定的要求，选择某种会话安全属性的所有失败的尝试，对用来建立会话的安 全属性的范围进行限制。

5.1.3SSODB设计和实现

按GB/T20271一2006中6.1.5.1的要求，实现SSODB基本的配置管理能力，即要求开发者所使 用的版本号与所表示的SSODB样本完全对应

5. 1. 3. 2 分发和操作

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

按GB/T20271一2006中6.1.5.3的要求，从以下方面进行SSODB的开发： 按非形式化功能说明、描述性高层设计、SSF子集实现、SSF内部结构模块化、描述性低层设计 和非形式化对应性说明的要求，进行SSODB的设计； b) 系统的设计和开发应保护数据的完整性，例如，检查数据更新的规则，多重输入的正确处理， 返回状态的检查，中间结果的检查，合理值输人检查，事务处理更新的正确性检查等； ) 在内部代码检查时，应解决潜在的安全缺陷，关闭或取消所有的后门； d) 交付的软件和文档，应进行关于安全缺陷的定期的和书面的检查，并将检查结果告知用户； e) 由系统控制的敏感数据，如口令、密钥等，不应在未受保护的程序或文档中以明文形式存储； 应以书面形式提供给用户关于软件所有权法律保护的指南

GB/T202732006

GB/T202732006

5.1.3.4文档要求

a 用户文档应提供关于不同用户的可见的安全机制以及如何利用它们的信息，并说明它们的用 途和提供有关它们使用的指南； b 安全管理员文档应提供有关如何设置、维护和分析系统安全的详细指导，以及与安全有关的 管理员功能的详细描述，包括增加和删除一个用户、改变主、客体的安全属性等； C 文档中不应提供任何一且泄露将会危及系统安全的信息。有关安全的指令和文档应划分等级 分别提供给用户、数据库系统管理员和系统安全员。这些文档应为独立的文档，或作为独立的 意条插人到管理员指南和用户指南中。

5.1 3.5生存周期支持

按GB/T20271一2006中6.1.5.5的要求，从以下方面实现SSODB的生存周期支持： a 按开发者定义生存周期模型进行SSODB开发； b 文档应详细阐述安全启动和操作的过程，详细说明安全功能在启动、正常操作维护时是否能 被撤消或修改，说明在故障或系统出错时如何恢复系统至安全状态。

按GB/T20271一2006中6.1.5.6的要求，从以下方面对SSODB进行测试： a）通过一般功能测试和相符独立性测试，确认SSODB的功能与所要求功能的一致性 b） 所有系统的安全特性，应被全面测试； 所有发现的漏洞应被改正、消除或使其无效，并在消除漏洞后重新测试，以证实它们已被消除 且没有引出新的漏洞； 应提供測试文档,详细措述测试计划、测试过程、测试结果

5.1.4SSODB安全管理

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

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

5. 2. 1. 1 身份鉴别

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

5.2. 1.2自主访问控制

根据4.2中访向操作、访问规则和授权传播的描述，按照GB/T20271一2006中6.2.3.2的要求， 从以下方面设计和实现数据库管理系统的自主访问控制功能： a）充许命名用户以用户的身份规定并控制对客体的访同，并阻止非授权用户对客体的访问； b 用目录表访向控制、存取控制表访问控制、能力表访问控制等访问控制表访问控制确定主体 对客体的访问权限； c） 自主访问控制主体的粒度应是用户级，客体的粒度应是表级和/或记录、字段级： d) 自主访问控制应与身份鉴别和审计相结合，通过确认用户身份的真实性和记录用户的各种成 功的或不成功的访问，使用户对自已的行为承担明确的责任

5. 2. 1.3安全审讯

根据4.6的描述，按GB/T20271一2006中6.2.2.3的要求，设计安全审计功能。本安全保护等级 要求： a) 安全审计功能的设计应与用户标识与鉴别、自主访问控制等安全功能的设计紧密结合； b) 提供审计日志，潜在侵害分析，基本审计查阅和有限审计查阅，安全审计事件选择，以及受保 护的审计踪迹存储等功能； c 能够生成、维护及保护审计过程，使其免遭修改、非法访问及破坏，特别要保护审计数据，要产 格限制未经授权的用户访问； d) 能够创建并维护一个对受保护客体访问的审计踪踪，保护审计记录不被未授权的访问、修改 和破坏。

5.2.1.4用户数据完整性

根据4.7的描述，按GB/T20271一2006中6.2.3.3的要求，从以下方面设计和实现数据库管理系 的用户数据完整性功能： a 在对数据进行访问操作时，检查以库结构形式存储在数据库中的用户数据是否出现完整性 错误； b 对数据库管理系统内部传输的用户数据，如进程间的通信，应提供保证数据完整性的功能； C 对数据库管理系统中处理的用户数据，根据4.7.1、4.7.2、4.7.3的描述，接照GB/T20271 2006中6.2.3.5的要求实现实体完整性、参照完整性和用户定义完整性，按回退的要求设计 用应的SSODB安全功能模块，进行异常情说的需务回退，以确保数据的馨性

5.2.1.5用户数据保密格

根据4.8.1、4.8.2和4.8.3中a)的描述，按GB/T20271一2006中6.2.3.4的要求，设计和实 居库管理系统的用户数据保密性保护功能

5.2.2SSODB自身安全保护

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

5.2.2.2SSF运行安全保护

按GB/T20271一2006中6.2.4.2的要求，从以下方面实现SSF的运行安全保护： 系统在设计时不应留有“后门”。即不应以维护、支持或操作需要为借口，设计有违反或绕过安 全规则的任何类型的人口和文档中未说明的任何模式的入口； b） 安全结构应是一个独立的、严格定义的系统软件的一个子集，并应防止外部于扰和破坏，如修 改其代码或数据结构：

c）应提供设置和升级配置参数的安装机制，在初始化和对与安全有关的数据结构进行保护之前， 应对用户和管理员的安全策略属性进行定义； d) 当数据库管理系统安装完成后，在普通用户访问之前，系统应配置好初始用户和管理员职责、 审计参数、系统审计跟踪设置以及对客体的合适的访问控制 e） 在SSODB失败或中断后，应保护其以最小的损害得到恢复，并按照失败保护中所描述的内 容，实现对SSF出现失败时的处理。

5.2.2.3SSF数据安全保护

按GB/T20271一2006中6.2.4.3的要求，对在SSODB内传输的SSF数据进行以下安全保护： a）实现SSODB内SSF数据传输的基本保护； b）SSODB内SSF数据复制的一致性保护。

5. 2. 2. 4资源利用

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

5.2.2.5SSODB访问控制

5.2 3SSODB设计和实现

5.2.3.1配置管理

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

鉴定新生成的系统版本；

安全生产标准规范范本鉴定新生成的系统版本； 保护源码免遵未授权修改

5. 2. 3.2 分发和操作

GB/T202732006

a） 应以文档形式提供对SSODB安全地进行分发的过程，并对安装、生成和启动的过程进行说 明，最终生成安全的配置。文档中所描述的内容应包括： 一提供分发的过程； 一安全启动和操作的过程； 一建立日志的过程。 b）对系统的未授权修改的风险，应在交付时控制到最低限度。包装及安全分送和安装过程中的 安全性由末端用户确认，所有安全机制都应以功能状态交付。 所有软件应提供安全安装默认值，使安全机制有效地发挥安全功能。 随同系统交付的全部默认用户标识码，在交付时处于非激活状态，并在使用前由管理员激活。 e) 用户文档应同交付的软件一起包装，并应有一套规程确保当前送给用户的软件是严格按照最 新的版本制作的，

按GB/T20271—2006中6.2.5.3的要求，从以下方面进行SSODB的开发： 按非形式化安全策略模型、完全定义的外部接口、描述性高层设计、SSF子集实现、SSF内部结 构层次化、描述性低层设计、非形式化对应性说明的要求，进行SSODB的设计； b 系统的设计和开发应保护数据的完整性，例如，检查数据更新的规则，多重输人的正确处理 返回状态的检查，中间结果的检查，合理值输人检查，事务处理更新的正确性检查等； c) 在内部代码检查时，应解决潜在的安全缺陷，关闭或取消所有的后门； d) 交付的软件和文档，应进行关于安全缺陷的定期的和书面的检查，并将检查结果告知用户； e) 由系统控制的敏感数据，如口令、密钥等，不应在未受保护的程序或文档中以明文形式存储； f) 应以书面形式提供给用户关于软件所有权法律保护的指南。

5. 2. 3. 4文档要求

a）用户文档应提供关于不同用户的可见的安全机制以及如何利用它们的信息，并说明它们的用 途和提供有关它们使用的指南。 b) 安全管理员文档应提供有关如何设置、维护和分析系统安全的详细指导，包括当运行一个安 全设备时，需要控制的有关功能和特权的警告，以及与安全有关的管理员功能的详细描述，包 括增加和剧除一个用户、改变主、客体的安全属性等。 c）文档中不应提供任何一旦泄露将会危及系统安全的信息。有关安全的指令和文档应划分等级 分别提供给用户、数据库系统管理员和系统安全员。这些文档应为独立的文档，或作为独立的 章节插人到管理员指南和用户指南中。文档也可为硬拷贝、电子文档或联机文档。如果是联 机文档应控制对其的访问。 d) 应提供关于所有审计工具的文档，包括为检查和保持审计文件所推荐的过程、针对每种审计 事件的详细审计记录文件、为周期性备份和删除审计记录所推荐的过程等。 e) 应提供如何进行系统自我评估的章节（带有网络管理、口令要求、拨号访问控制、意外事故计划 的安全报告)和为灾害恢复计划所做的建议，以及描述普通人侵技术和其他威胁及查出及阻止 的方法。

海绵城市标准规范范本5.2.3.5生存周期支持

按GB/T20271一2006中6.2.5.5的要求，从以下方面实现SSODB的生存周期支持：