数据库系统安全开发和改造规范模板.doc

数据库系统安全开发和改造规范

某某石油管理局企业标准
数据库系统安全开发和改造规范
某某石油管理局 发布

前 言
本标准由某某石油管理局计算机应用及信息专业标准化委员会提出并归口。
本标准由某某石油管理局信息中心起草。
本标准的主要内容包括:
适用范围、 术语定义、 数据库的开发和改造等几部分。

1范围
本标准规定了局某某石油管理局某某油田数据库系统安全开发与改造规范。
本标准适用于某某油田( 企业内部) 数据库系统安全开发与改造的全过程。

2规范解释权
某某油田信息中心网络标准和规范小组
3基本原则
本规范是参考国家相应标准, 并参考相应国际标准, 并结合某某油田的相应实际而制定
4使用说明
1)本规范所提到的重要数据应用部门, 如无特别说明, 均指某某油田范围内各个有重要数据( 如生产数据, 管理数据等) 的部门, 这里不具体指明, 各单位能够参照执行。
2)本规范说明了如何在现有数据库系统上应用的开发与改造方法, 但不包括数据系统的应用与管理。也不说明数据库系统本身的开发与改造方法。
5总则

1)为加强某某油田各单位数据库技术管理, 有效地保护和利用数据库技术资源, 最大程度地防范技术风险, 保护使用者的合法权益, 根据《中华人民共和国计算机信息系统安全保护条例》及国家有关法律、 法规和政策, 结合油田的实际情况, 制定本规范。
2)本规范所称的数据库, 是指所有与油田业务相关的信息存储体的集合。
3)某某油田中从事数据库开发与改造的人员, 均须遵守本规范。

6数据库系统的基本概念
数据、 数据库、 数据库管理系统和数据库系统是与数据库技术密切相关的四个基本概念。
数据是数据库中存储的基本对象。数据在大多数人的头脑中第一个反应就是数字。其实数字只是最简单的一种数据, 是数据的一种传统和狭义的理解。广义的理解, 数据的种类很多, 文字、 图形、 图像、 声音、 学生的档案记录、 货物的运输情况等等, 这些都是数据。
我们能够对数据做如下定义: 描述事物的符号记录称为数据。描述事物的符号能够是数字, 也能够是文字、 图形、 图像、 声音、 语言等, 数据有多种表现形式, 它们都能够经过数字化后存入计算机。
数据库, 是存放数据的仓库。只不过这个仓库是在计算机存储设备上, 而且数据是按一定的格式存放的。所谓数据库中, 是指长期存储在计算机内、 有组织的、 可共享的数据集合。数据库中的数据按一定的数据模型组织、 描述和存储, 具有较小的冗余度、 较高的数据独立性和易扩展性, 并可为各种用户共享。
数据库管理系统是位于用户与操作系统之间的一层数据管理软件, 它负责科学地组织和存储数据以及如何高效地获取和维护数据。

7数据库系统的分类
7.1 集中型 在这种结构中, 客户程序连接某台指定的机器并经过其完成交易。数据库放置在同一台机器上, 或指定一台专门的机器充当数据库服务器。
7.2 数据分布型 数据分布型结构类似前一种结构, 只是数据库分布在每台服务器上。它具有的优点是: 无单点失败且可独立进行管理。我们能够将这种结构用于数据分割, 例如逻辑分割和地理分割。
7.3 数据集中型 这种结构是对集中型的一种增强, 由其中的一台机器作为数据存取服务器, 而在前台提供更多的应用服务器, 共享一个数据库服务器。这种情况下, 必须使用数据库软件提供的并行处理功能及硬件厂商提供的硬件集群策略。
7.4 高可用性 现在, 所有用户都希望在硬件出现错误时, 应用的迁移能更加简单, 而且在迁移的同时能保证系统继续运行且尽量减少人工干预。中间件能够提供这样的功能, 它能够帮助操作系统自动迁移关键组件到正常的机器上。

8数据库类型的开发方式与访问接口
数据库类型的开发方式主要是用分布式组件技术。组件是独立于特定的程序设计语言和应用系统、 可重用和自包含的软件成分。组件是基于面向对象的, 支持拖拽和即插即用的软件开发概念。基于组件技术的开发方法, 具有开放性、 易升级、 易维护等优点。它是以组合(原样重用现存组件)、 继承(扩展地重用组件)、 设计(制作领域专用组件)组件为基础, 按照一定的集成规则, 分期、 递增式开发应用系统, 缩短开发周期。在开发过程中遵循以组件为核心原则、 组件实现透明原则及增量式设计原则。
基于组件开发方法的优点:
1) 速度快。因为组件技术提供了很好的代码重用性, 用组件开发应用程序主要的工作是”配置”应用, 应用开发人员只需写业已有的组件没有提供的应用新特征的代码, 这比写整个应用的代码快得多。
2) 可靠性高。因为组件开发中所用的组件是已经测试过的, 虽然整个应用依然需要测试, 基于组件的应用还是要比使用传统技术开发的应用要可靠的多。
3) 编程语言和开发工具的透明性。基于组件的开发方法允许用不同的语言编写的组件共存于同一应用中, 这在大型的复杂应用开发中是很重要的。
4) 组件的积累。组件的积累就是财富的积累, 能够为新系统提供一定的支持。
5) 提高系统互操作性。组件必须按照标准开发, 而标准具有权威性和指导作用, 支持更广泛的代码重用。
6) 开发者注意力更多地集中在商业问题上。基于组件的开发, 使编程人员将大多数时间用在所要解决的商业问题上, 而不是用于担心低级的编程细节问题。
7) 为自己开发还是购买提供了最好的选择。购买组件装配到定制的系统中的优势是, 不必要购买一个不完全适合于自己的软件, 还能够减少风险, 因为购买的组件已经经过广泛的使用与测试。
当前, 在组件技术标准化方面, 主要有以下三个比较有影响的规范:
1) OMG起草与颁布的CORBA;
2) 微软公司推出的COM/DCOM/COM+;
3) SUN发表的JavaBeans。

异构数据源访问接口 在网络环境下, 特别是分布式系统中, 异构数据库的访问是一个不可避免的问题, 采用SQL语言的异构数据库为解决相互访问问题提供了可能。当前最有影响的有两种标准是: 1)Microsoft公司的ODBC; 2)以Sun和JavaSoft公司为代表的JDBC。
9开发与改造管理

基于当前某某油田的应用实际, 我们这里所说的安全开发与改造, 并不指对数据系统本身开发与改造, 而是基于数据库上的相关应用的开发与改造。
9.1 关于数据库开发与改造的保密管理的说明
由于在某某油田中的数据库中的数据可能包括敏感数据, 它的泄露与破坏可能对某某油田甚至对国家、 社会造成重大的人力、 物力、 财力损失, 因此, 在涉密数据库系统的开发与改造过程中, 应该对数据的保密性有特殊的要求。
1) 密数据库的开发与改造项目, 必须经某某油田信息安全中心与数据应用单位的主管部门的联合批准立项, 同时要求对开发与改造过程中的安全风险做出评估, 对需要保密的数据字段做出书面上的要求。对于这种评估与要求应做出相应的存档备案。
2) 在开发过程中, 可能使用到的试验数据应该由开发部门自已生成模拟数据, 应用单位不应提供原有的可能涉密的真实数据做试验, 以防泄密。
3) 系统在设计与开发时不应留有”后门”, 即不应以维护、 支持或操作需要为借口, 设计有违反或绕过安全规则的任何类型的入口和文档中未说明的任何模式的入口。如有发现, 应用方有权对系统设计与开发方追究责任。
4) 在数据系统的改造过程中, 系统的原有数据不得做新系统的试验数据, 以防数据被破坏与泄露。但系统改造完成之后, 又要求能无缝地导入原有的数据, 保证系统的顺利运行。
5) 在数据系统的运行维护过程中, 技术维护人员不应得到系统的最高权限。同时为了防止由于系统管理人员或特权用户的权限过于集中所带来的安全隐患, 应将数据库系统的常规管理、 与安全有关的管理以及审计管理, 分别由系统管理员、 系统安全员和系统审计员来承担, 并按最小授权原则分别授予它们各自为完成自己所承担任务所需的最小权限, 还应在三者之间形成相互制约的关系。
6) 对于涉密系统, 我们要求相应要求保密的数据不能以明文的形式存储在物理介质上。这可能采用两种办法,
一种是由数据库系统本身提供的加密方法( 如果具体采用的产品提供) , 另一种是经过应用系统加密之后再交数据库系统操作。
7) 对于涉密系统, 我们要求相应要求保密的数据不能以明文的形式在网络介质上传输。其目的是防止被动攻击。所采用的方法如下:
Ø 能够是对数据进行软件应用层加密;
Ø 也能够在相应的网络硬件中加入加解密设施;
Ø 现在许多数据库在传输过程中也能用相应加密模块加密后再传输;
Ø 如果传输经过的网络范围较小(如一个机房内), 那么物理介质隔离是一种有效的办法。

9.2 关于数据库开发与改造的功能要求规范
对于开发与改造后的数据库应用系统的功能, 我们提出以下要求:
9.2.1 身份鉴别
9.2.1.1 用户标识
应对注册到数据库管理系统中的用户进行唯一性标识。用户标识信息是公开信息, 一般以用户名和/或用户 ID 实现。为了管理方便, 可将用户分组, 也可使用别名。无论用户名、 用户 ID、 用户组还是用户别名, 都要遵守标识的唯一性原则。
9.2.1.2 用户鉴别
应对登录到数据库管理系统的用户进行身份真实性鉴别。经过对用户所提供的”鉴别信息”的验证, 证明该用户确有所声称的某种身份, 这些”鉴别信息”必须是保密的, 不易伪造的。
用户进入数据库管理系统时的身份鉴别, 并按以下要求进行设计:
1) 凡需进入数据库管理系统的用户, 能够选择采用该用户在操作系统中的标识信息, 也能够重新进行用户标识。重新进行用户标识应在用户注册( 建立账号) 时进行。
2) 当用户登录到数据库管理系统或与数据库服务器( 如经过网络) 进行访问连接时, 应进行用户鉴别。这能够参考某某油田的CA认证与授权系统的相关要求进行设计。
3) 数据库管理系统用户标识一般使用用户名和用户标识( UID) 。为在整个数据库系统范围实现用户的唯一性, 应确保数据库管理系统建立的用户在系统中的标识( SID) 与在各数据库系统中的标识( 用户名或别名, UID 等) 之间的一致性。
4) 分布式数据库系统中, 全局应用的用户标识信息和鉴别信息应存放在全局数据字典中, 由全局数据库管理安全机制完成全局用户的身份鉴别。局部应用的用户标识信息和鉴别 信息应存放于局部数据字典中, 由局部数据库安全机制完成局部用户的身份鉴别。
5) 数据库用户的标识和鉴别信息应受到操作系统(包括网络操作系统)和数据库系统的双重保护。操作系统应确保任何用户不能经过数据库以外的使用方式获取和破坏数据库用户的标识和鉴别信息。数据库系统应保证用户以安全的方式和途径使用数据库系统的标识和鉴别信息。
6) 数据库用户标识信息应在数据库系统的整个生命期有效, 被撤消的用户账号的 UID 不得再次使用。

9.2.2 标记与访问控制
9.2.2.1 标记与安全属性管理
应经过标记为 TCB 安全功能控制范围内的主体与客体设置安全属性。具体要求为:
1) 对于自主访问控制, 标记以某种方式表明主体与客体的访问关系;
2) 对于强制访问控制, 不同的访问控制模型有不同的标记方法。基于多级安全模型的强制访问控制, 标记过程授予主体与客体一定的安全属性, 这些安全属性构成采用多级安全模型的强制访问控制机制的属性库——强制访问控制的基础数据。数据库管理系统需要对主、 客体独立进行标记。
3) 用户安全属性应在用户建立注册帐户后由系统安全员经过 TCB 所提供的安全员界面进行标记并维护;
4) 客体安全属性应在数据输入到由 TCB 安全功能所控制的范围内时以缺省方式生成或由安全员进行标记并维护;
5) 系统管理员、 系统安全员和审计员的安全属性应经过相互标记形成制约关系。
9.2.2.2访问控制
应根据数据库特点和要求, 实现不同粒度的访问控制。这些特点主要是:
1) 数据以特定结构格式存放, 客体的粒度能够是: 关系数据库的表、 视图、 元组( 记录) 、 列( 字段) 、 元素( 每个元组的字段) 、 日志、 片段、 分区、 快照、 约束和规则、 DBMS 核心代码、 用户应用程序、 存储过程、 触发器、 各种访问接口等;
2) 数据库系统有完整定义的访问操作;
3) 数据库是数据与逻辑的统一, 数据库中不但存放了数据, 还存放了大量的用于管理和使用这些数据的程序, 这些程序和数据同样需要进行保护, 以防止未授权的使用、 篡改、 增加或破坏;
4) 数据量大、 客体丰富是数据库的又一特点, 考虑到性能和代价, 应对于不同客体给予不同程度的保护, 如对敏感字段加密, 对敏感表建立视图等。
5) 数据库系统具有数据生命周期长、 用户分散、 组成复杂等特点, 要求长期的安全保护;
6) 数据库中的三级结构( 物理结构、 逻辑结构、 概念模型结构) 和两种数据独立性( 物理独立性、 逻辑独立性) 大大减轻数据库应用程序的维护工作量, 可是由于不同的逻辑结构可能对应于相同的物理结构, 给访问控制带来新的问题, 应对访问规则进行一致性检查;
7) 数据库管理系统的访问控制是在 OS 之上实现的, 考虑到效率因素, 数据库管理系统的访问控制应在外层实现;
8) 数据库系统中客体具有相互联系的特点, 这些”联系”本身也是一种非常有效的信息, 防止未授权用户获得或利用这些”联系”, 需要进行”推理控制”;
9) 分布式数据库管理系统中, 全局应用的访问控制应在全局 DBMS 层实现, 局部应用的访问控制应在局部 DBMS 层实现, 并根据需要各自选择不同的访问控制策略;
10)
9.2.2.3自主访问控制
1) 访问操作
应由数据库子语言定义, 并与数据一起存放在数据字典中。对任何 SQL 对象进行操作应有明确的权限许可, 而且权限随着操作和对象的变化而变化, 安全系统应有能力判断这种权限许可。操作与对象紧密相联, 即把”操作+对象”作为一个授权。
2) 访问规则
应以访问控制表或访问矩阵的形式表示, 并经过执行相应的访问控制程序实现。每当执行 SQL语句、 有访问要求出现时, 经过调用相应的访问控制程序, 实现对访问要求的控制。
3) 授权传播限制
应限制具有某一权限的用户将该权限传给其它用户。当一个用户被授予某权限, 同时拥有将该权限授予其它用户的权力时, 该用户就会拥有对该授权的传播权。为了增强数据库系统的安全性, 需要对授权传播进行某些限制。
9.2.2.4 强制访问控制
应采用确定的安全策略模型实现强制访问控制。当前常见的安全策略模型是多级安全模型。该模型将可信计算基安全控制范围内的所有主、 客体成分经过标记方式设置安全属性( 等级和范畴) 。该模型并按由简单保密性原则确定的规则——从下读、 向上写, 根据访问者主体和被访问者客体的安全属性, 实现主、 客体之间每次访问的强制性控制。根据数据库管理系统的运行环境的不同, 强制访问控制分为:
1) 在单一计算机系统上或网络环境的多机系统上运行的单一数据库管理系统, 访问控制所需的安全属性存储在统一的数据库字典中, 使用单一的访问规则实现;
2) 在网络环境的多机系统上运行的分布式数据库系统, 全局应用的强制访问控制应在全局DBMS 层实现, 局域应用的强制访问控制应在局部 DBMS 层实现。其所采用的访问规则应是一致的。
9.2.3 数据完整性
9.2.3.1 实体完整性和参照完整性
1) 数据库管理系统应确保数据库中的数据具有实体完整性和参照完整性。关系之间的参照完整性规则是”连接”关系运算正确执行的前提。
2) 用户定义基本表时, 应说明主键、 外键, 被引用表、 列和引用行为。当数据录入、 更新、 删除时, 由数据库管理系统应根据说明自动维护实体完整性和参照完整性。
9.2.3.2 用户定义完整性
1) 数据库管理系统应提供支持用户定义完整性的功能。系统应提供定义 和检查用户定义完整性规则的机制, 其目的是用统一的方式由系统处理, 而不是由应用程序完成, 从而不但能够简化应用程序, 还提高了完整性保证的可靠性。
2) 数据库管理系统应支持为约束或断言命名( 或提供默认名称) , 定义检查时间、 延迟模式或设置默认检查时间和延迟模式, 支持约束和断言的撤消。
9.2.3.3 数据操作的完整性
数据操作的完整性约束为:
1) 用户定义基本表时应定义主键和外键;
2) 对于候选键, 应由用户指明其唯一性;
3) 对于外键, 用户应指明被引用关系和引用行为;
4) 应由数据库管理系统检查对主键、 外键、 候选键数据操作是否符合完整性要求, 不允许提交任何违反完整性的事务; 删除或更新某元组时, 数据库管理系统应检查该元组是否含有外键, 若有, 应根据用户预定义的引用行为进行删除。
9.2.4 数据库安全审计
数据库管理系统的安全审计应:
1) 建立独立的安全审计系统;
2) 定义与数据库安全相关的审计事件;
3) 设置专门的安全审计员;
4) 设置专门用于存储数据库系统审计数据的安全审计库;
5) 提供适用于数据库系统的安全审计设置、 分析和查阅的工具。
9.2.5 客体重用
数据库系统大量使用的动态资源, 多由操作系统分配。实现客体安全重用的操作系统和数据库管理系统应满足以下要求:
Ø 数据库管理系统提出资源分配要求, 如创立新库, 数据库设备初始化等, 所得到的资源不应包含该客体以前的任何信息内容;
Ø 数据库管理系统提出资源索回要求, 应确保这些资源中的全部信息被清除;
Ø 数据库管理系统要求创立新的数据库用户进程, 应确保分配给每个进程的资源不包含残留信息;
Ø 数据库管理系统应确保已经被删除或被释放的信息不再是可用的。
Ø
9.2.6 数据库可信恢复
数据库系统中的可信恢复具有特定含义, 主要应包括:
1) 确保能在确定不减弱保护的情况下启动安全数据库系统的 DBMS;
2) 运行中发生故障或异常情况时, 能够在尽量短的时间内恢复到正确、 一致、 有效的状态, 这个状态对于系统运行是正常、 安全的状态, 而且对于应用来说是一个真实、 有意义的状态;
3) 数据库系统可信恢复应由操作系统和数据库系统共同支持;
4) 与可信恢复相关的数据库技术有: 事务管理, 日志, 检查点, 备份, 分布式数据库特殊处理。
油田重要数据应用单位应按如下要求进行数据备份:
1) 每个工作日结束后必须制作数据的备份, 数据应至少备份在两种不同的介质上并异地存放, 保证系统发生故障时能够快速恢复;
2) 业务数据必须定期、 完整、 真实、 准确地转储到不可更改的介质上, 并要求集中和异地保存;
3) 备份的数据必须指定专人负责保管, 由数据库技术人员按规定的方法同数据保管员进行数据的交接。交接后的备份数据应在指定的数据保管室或指定的场所保管;
4) 数据保管员必须对备份数据进行规范的登记管理;
5) 备份数据不得更改;
6) 备份数据保管地点应有防火、 防热、 防潮、 防尘、 防磁、 防盗设施。

9.2.7 隐蔽信道分析
数据库管理系统的隐蔽信道分析与数据库管理系统的设计密切相关, 应在系统开发过程中进行。
系统开发者应彻底搜索隐蔽存储信道, 并根据实际测量或工程估量确定每一个被标识信道的最大带宽。隐蔽信道分析是建立在 TCB 的实现、 管理员指南、 用户指南以及完整定义的外部接口等基础上的。

9.2.8 可信路径
在数据库用户进行注册或进行其它安全性操作时, 应提供TCB与用户之间的可信通信路径, 实现用户与TSF间的安全数据交换。
9.2.9 推理控制
应采用推理控制的方法防止数据库中的数据信息被非授权地获取。运用推理方法获取权限以外的数据库信息, 是一种较为隐蔽的信息攻击方法。在某某油田中具有较高安全级别要求的数据库系统中, 应考虑对这种攻击的防御。
11生效期