IBM中国移动企业信息化数据库安全规范.docx
《IBM中国移动企业信息化数据库安全规范.docx》由会员分享，可在线阅读，更多相关《IBM中国移动企业信息化数据库安全规范.docx（33页珍藏版）》请在冰豆网上搜索。
IBM中国移动企业信息化数据库安全规范
密级：
文档编号：
项目代号：
中国移动企业信息化
数据库安全规范
Version1.0
中国移动通信有限公司
二零零四年十二月
拟制:
审核:
批准:
会签:
标准化:
版本控制
版本号
日期
参与人员
更新说明
分发控制
编号
读者
文档权限
与文档的主要关系
1
创建、修改、读取
负责编制、修改、审核
2
批准
负责本文档的批准程序
3
标准化审核
作为本项目的标准化负责人，负责对本文档进行标准化审核
4
读取
5
读取
第1章目的与范围
1.1.目的
为了加强中国移动集团企业信息化办公室下属各公司的网络数据库系统安全管理，提高中国移动集团下属各公司办公网的网络数据库系统安全水平，保证数据库系统的正常安全运行，特制定本数据库的安全加固规范。
随着基础网络建设和应用系统开发的日益成熟与完善，尤其是企业信息化建设的前景和风险共存的事实，安全问题逐步成为企业信息化部门关注和讨论的焦点。
对于企业来说，信息系统最重要的资源并不是网络和设备，而是有价值的数据和存贮这些关键数据的地方--数据库。
本文档旨在于规范中国移动集团企业信息化办公室下属各公司对通用数据库进行的安全加固。
1.2.适用范围
数据库安全包含传统的备份与恢复，用户认证与访问控制，数据存贮和通信环节的加密，而且它作为操作系统之上的应用平台，其安全与网络和主机安全息息相关。
本文对中国移动集团企业信息化办公室下属各公司办公网系统的数据库系统，加固进行指导。
1.3.数据库安全保护目标
中国移动关键数据库中存储的数据是中国移动的宝贵的信息资源，这些数据的安全的需求概括来讲就是：
正确的人能够及时地存取到正确的数据。
数据安全保护目标有下面三方面：
●数据机密性
安全的数据库系统需保证数据的机密性，只能让合法的用户看到他该看到的数据。
●数据完整性
数据完整性要求：
（1）保证数据合法有效；
（2）保护数据不被恶意删除和修改；（3）保证数据之间的逻辑依赖关系。
●数据可访问
数据可用性意味着数据对授权用户是可用的，能够保证业务的正常运行。
包括对数据的备份恢复和避免恶意的拒绝服务攻击。
第2章数据库数据安全风险分析与对策
2.1.数据安全风险分析
在数据库应用中，数据安全面临着以下威胁：
数据被篡改
通信的私有性对保证数据在传输过程中不被篡改非常重要。
分布式的环境给恶意攻击者篡改数据带来了可能。
在数据篡改的攻击中，一个未授权的攻击者对传输中的数据进行拦截、篡改后，再把数据继续进行传输。
比如一个攻击者把银行交易的金额从100元改为1000元，导致交易错误。
数据被窃取
数据必须能够安全地存储和传输，因此敏感信息诸如信用卡号、密码等不会被窃取。
在大多数网络中，即使通信通道全部是有线链路，未授权用户也可以用workstation或者PC设法接入网络以窃听网络上的传输数据。
对于所有类型的网络，包括局域网和广域网这种数据窃听都有可能。
用户身份被伪造
攻击者可能冒充合法用户从网络上登录到数据库系统。
在分布式环境中，攻击者很容易伪造身份获取到敏感重要的信息。
并且，攻击者还可以劫持连接。
例如声称的客户机B和声称的服务器A可能并不是真正的客户机B和服务器A。
伪造身份现已成为网络安全的最大威胁之一。
密码潜在的问题
在大型的系统中，用户必须记住不同应用和不同服务的多个密码，他们通常选择易于猜测的密码，如姓名、字典里的一个单词等以方便记住。
这些密码对于攻击来说是很脆弱的；并且，由于不同的应用都需要密码，用户往往把密码标准化，不同的应用的密码略有不同，从一个应用的密码可以推知另外一个应用的密码，这样方便记住。
所有这些问题都给安全带来了威胁。
XX对表、列存取
数据库可能含有机密的表，或者表里可能含有机密的列，这些机密数据不应该不加区分地被所有用户访问。
所以应该在列这个更细的级别对数据进行保护。
XX对行存取
有一些数据行可能含有机密的信息，这些机密的数据行不应该不加区分地被能访问该表的所有用户访问，应该有更细粒度的安全控制保证数据的机密性。
比如说在一个共享的业务环境中，用户应该只能够存取他自己的信息：
每个客户只能看到他自己的订单记录，而不能够看到所有的订单记录。
这些限制可以通过应用强加上去，但是如果用户绕过应用，直接访问数据库，就会有数据机密性的风险。
所以需要在数据这一层加上访问安全策略的控制。
缺乏有效的跟踪、监控机制
如果系统管理员不能跟踪用户的行为，则用户对他们的行为不会负责任。
所以必须有可靠的机制来监控用户对数据的操作。
2.2.典型数据库安全攻击方式
数据库通常包含最为敏感、机密的数据。
例如：
人力资源部门的个人详细资料、客户详细资料、订单或信用卡详细资料。
必须安全地存储这类数据，并防止其在XX的情况下被披露、篡改或恶意使用。
即便数据库服务器并未直接与Internet相连，仍需防止其遭受利用配置弱点、现有缓冲器溢出或不良开发惯例而实施的攻击。
数据库攻击的执行者可能是：
●为利用数据库而使用的不安全的Web应用程序。
●具有网络访问权限的不道德的管理员。
●受骗而运行恶意代码的数据库用户。
下图显示的是一些主要的威胁和漏洞，它们可导致数据库服务器的安全受到威胁并可能使敏感数据被毁或被窃取。
数据库服务器的安全威胁和漏洞
2.2.1.SQL注入
实施SQL注入攻击时，攻击者会充分利用应用程序的输入验证和数据访问代码中的漏洞，使用Web应用程序的安全上下文在数据库中随意运行命令。
"SQL注入"是一种攻击，它将恶意代码插入稍后将传递到数据库系统以进行分析和执行的字符串中。
任何返回SQL语句的客户端应用程序都会使信任它的服务器遭受这样的插入攻击，因为该服务器将执行接收到的任何语法上有效的语句。
当应用程序根据用户输入的内容构造SQL语句时，最容易插入。
当客户端将用户输入的内容传递到服务器端存储过程时，也有可能进行插入攻击。
如果应用程序使用特权过多的帐户连接，可能会对服务器造成重大破坏。
2.2.2.网络窃听
大多数应用程序的部署体系结构都包括从数据库服务器中物理分离出数据访问代码。
因此，必须防止网络窃听者窃取诸如应用程序特定数据或数据库登录凭据等敏感数据。
可加大网络窃听可能性的漏洞包括：
●不安全的通信渠道
●以明文方式向数据库传送凭据
2.2.3.XX的服务器访问
应仅限特定客户端计算机可以直接访问数据库服务器，以防止XX的服务器访问。
使数据库服务器易遭XX的服务器访问的漏洞包括：
●未在外围防火墙封锁数据库服务端口
●缺少IPSec或TCP/IP筛选策略
经过身份验证的用户和无用户名及密码的用户都可遭受直接连接攻击。
例如：
●使用查询分析器等工具建立到数据库系统的直接连接并发出命令。
●如果攻击者向侦听端口发送精心构建的数据包，诸如软件版本等服务器信息便会泄漏。
2.2.4.密码破解
常见的密码攻击方式是尝试破解众所周知的帐户名称。
导致密码破解的常见漏洞为：
●弱密码或空密码
●包含日常用语的密码
常见的密码破解攻击包括：
●字典攻击
●手动猜测密码
2.3.数据库安全管理关键要点
一个强大的数据库安全系统应当确保其中信息的安全性并对其有效地控制。
下面列举的原则有助于企业在安全规划中实现客户利益保障，策略制订以及对信息资源的有效保护。
2.3.1.管理细分和委派原则
在典型的数据库工作环境中，DBA总是独立执行所有的管理和其它事务工作，传统数据库管理并没有"安全管理员（SecurityAdministrator）"这一角色，这就迫使数据库管理员（DBA）既要负责帐号的维护管理，又要专门对数据库执行性能和操作行为进行调试跟踪，从而导致管理效率低下。
通过管理责任细分和任务委派，安全管理员将得以从常规事务中解脱出来，而更多地关注于解决数据库安全执行以及管理相关的重要问题。
2.3.2.最小权限原则
许多新的保密规则针对对特定数据的授权访问。
企业必须本着"最小权限"原则，从需求和工作职能两方面严格限制对数据库的访问权。
通过角色（role）的合理运用，最小权限可确保数据库功能限制和对特定数据的访问。
2.3.3.帐号安全原则
用户帐号对于每一个数据库联接来说都是必须的。
用户帐号设置在缺乏基于字典的密码强度检查和用户帐号过期控制的情况下，只能提供很有限的安全功能。
帐号应遵循传统的用户帐号管理方法来进行安全管理。
这些方法包括：
更改缺省密码；应用适当的密码设置；当登录失败时实施帐号锁定；对数据提供有限制的访问权限；禁止休眠状态的帐户，以及管理帐户的生命周期等。
2.3.4.有效的审计
数据库审计是数据库安全的基本要求。
数据库审计经常被DBA以提高性能或节省磁盘空间为由忽视或关闭，这大大降低了管理分析的可靠性和效力。
审计跟踪对了解哪些用户行为导致数据的修改至关重要，它将与数据直接相关的事件都记入日志，因此，对监视数据访问和用户行为是最基本的管理手段。
企业应针对自己的应用和数据库活动定义审计策略。
审计并非一定要按"要么对所有目标，要么没有"审计的粗放模式进行，从这一点来看，智能审计的实现对安全管理意义重大--不仅能节省时间，而且能减少执行所涉及的范围和对象；通过智能限制日志大小，还能突出更加关键的安全事件。
2.3.5.加强关键数据库安全保护
关键数据库中的数据是支撑企业业务工作的宝贵信息资产，为了保护关键数据库的机密性、完整性和可用性，必须建立完善的数据库安全访问控制策略，采用数据库提供的安全机制对数据库数据安全保护，实行用户帐号管理、密码管理、访问权限管理控制、数据库加密、备份恢复等方面的安全加固。
第3章数据库基本安全架构
3.1.数据库安全机制考虑
数据库系统面对安全的挑战，业界通常采用以下技术对安全进行控制：
●身份验证
●访问控制
●权限管理
●审计
●加密
●数据完整性
以下是针对不同的数据库安全风险可采用的数据库安全技术对照表。
安全风险
解决之道
安全技术
未验证用户
确认用户身份
帐户认证
未授权的数据存取
限制数据存取
访问控制
加密存储数据
存储数据加密
限制权限
权限管理
网络数据侦听、窃取
保护网络
网络加密
数据破坏
备份恢复
数据库备份
账号密码脆弱
强制密码安全
密码规则
缺乏跟踪
监控用户的行为
安全审计
系统入侵
加密敏感数据
存储数据加密技术
及时修补安全漏洞
安全补丁
3.2.成熟数据库安全机制
3.2.1.账户认证机制
数据库安全性中最基本的概念之一就是验证。
系统通过这个过程来证实用户身份。
用户可以通过提供身份证明或验证令牌来响应验证请求。
用户提供身份标识表示其声称自己是被授权可访问该环境的人，密码则将提供用户的验证证据。
当然，这种验证假定用户的密码受到很好的保护，而且是唯一一个知道这个密码的人。
用户验证由数据库系统或者是数据库系统之外的安全性工具完成，许多大型的数据据库系统都提供了用户验证的功能。
如果采用数据库系统之外的安全性工具，这些工具通常是操作系统的一部分或独立第三方身份验证工具。
事实上，安全性不仅是数据库问题，操作系统厂商也要花费很多的时间、金钱和心思确保他们的产品是安全的。
但是，有些操作系统并没有本地安全机制。
如果使用的是没有安全机制的操作系统，那可以把环境配置成依靠在更安全的系统上运行的数据库系统服务器来提供这种安全性。
也可以采用独立的第三方身份验证工具（如由OpenGroup定义的分布式计算环境安全服务（DistributedComputingEnvironment（DCE）SecurityServices）来给数据库系统环境添加一层安全层。
数据库系统可以协调这些外部安全工作与其安全主动性来保护事务或分析环境。
一旦用户身份验证成功，数据库系统记下用户的身份标识和其它相关的安全信息，如用户组列表。
用户必须使用授权名或授权标识以被数据库系统识别，授权名或授权标识可以与用户标识或映射值相同。
这一连接信息将在用户连接期间保留。
用户验证的方式
因为验证可以由数据库系统、操作系统或第三方认证工具处理，所以数据库系统的验证可以通过参数的配置来选择的不同验证选项。
数据库系统使用这一参数确定验证应该以何种方式、在何处发生。
设置在逻辑上可以分组为以下不同类别：
SERVER（服务器）、Client（客户机）、第三方工具（如DCE）。
服务器验证
服务器验证提供两种方式：
∙普通方式缺省安全性机制，指明验证应该使用服务器的操作系统在服务器上发生。
如果用户标识和密码是在连接期间指定的，那么数据库系统将调用操作系统函数来验证提交的用户标识和密码。
（在基于Windows的环境中，用户标识常被称为用户名。
用户名和密码合起来常被称为用户账户。
）
∙加密方式本质上同缺省选项是一样的，只有一点例外，即从客户机传到服务器的密码是加密的。
数据库系统在连接时使用密码加密技术和Diffie-Hellman算法为加密算法生成密钥。
Client（客户机）验证
客户机验证指的是用户身份验证将在客户机上发生。
如果客户机驻留在原本就具有安全特性的操作系统（例如，AIX）上，那么它就是可信任客户机。
通常，除MicrosoftWindows95和98被认为不可信任之外，所有客户机都是可信任的。
如果服务器接收到来自可信任客户机和不可信任客户机的请求，那么根据配置选项允许可信任客户机使用客户机验证（clientauthentication）获得访问权，而不可信任客户机则必须提供密码才能成功验证。
第三方产品验证选项
一些管理员愿意实现第三方产品安全性服务，原因是它提供用户和密码集中式管理，不传送明文密码和用户标识，并且向用户提供单次登录。
数据库系统使用第三方产品来提供对安全性服务的集成支持。
3.2.2.视图控制机制
视图的作用
不同的用户对数据库中数据管理和使用的范围是不同的。
为此，DBMS提供了将数据分类的功能，即建立视图。
管理员把某用户可查询的数据逻辑上归并起来，简称一个或多个视图，并赋予名称，在把该视图的查询权限授予该用户（也可以授予多个用户）。
视图经常用于对数据设置行级保密和列级保密。
例如，可以授权用户访问一个视图，这个视图只显示该用户可以访问的行，而不显示表中所有行。
同样，可以通过视图限制该用户访问的列。
视图的实现
视图是数据库的一个子集，它仅包含用户有权访问的信息。
这样单个用户的所有查询仅在自己的数据库子集上进行。
子集视图保证用户不会访问允许范围之外的其它设计。
除了元素之外，视图由数据库中相应的一系列关系构成。
用户可以在已有的属性元素上进行相应的操作。
视图（view）像表一样由列组成，其查询方式与表相同。
但是视图中没有数据。
从理论上讲，可以把视图看作是覆盖一个或多个表的“蒙版”，视图中的列可以在一个或多个基本表中找到。
所以视图不使用物理存储位置来存储数据。
对一个视图进行查询时，视图将查询其基于的表，并且以视图定义所规定的格式和顺序返回值。
由于视图没有直接相关的物理数据，因此视图是一种非常安全的数据保护手段。
3.2.3.访问控制机制
由于数据库中存放着大量的数据，为了防止数据被非法地使用，有必要限制合法用户操纵数据库的权限。
数据库中的权限可以分为系统级权限和对象级权限。
系统级权限用来控制整个数据库的访问权限，例如创建或删除数据库对象的权限。
对象级权限使用户可以访问不属于自己的数据库对象。
可以通过授权来对不同的数据库用户授予不同的系统级和对象级权限。
系统权限
可以使用角色来管理对用户有效的系统级权限。
这些权限包括create table和alter index等等。
对于每种数据库对象的操作都是由各自的权限授权的。
例如，一个用户可以被授予CREATE TABLE权限，而不是CREATETYPE权限。
可以创建一些自定义的系统级角色，这些角色只向用户授予他们在数据库中所需的权限而不是过多的特权。
以Oracle8i为例，可以使用系统级角色分派以管理数据库的系统级命令。
可以创建自定义的系统级角色或使用数据库自带的角色。
可通过系统级授予的权限。
下表列出了Oracle8i提供的11个系统级角色。
使用这些角色就能对授予数据库管理角色的系统级权限进行限制。
Oracle8i提供的系统级角色
角色
授予角色的权限
CONNECT
ALTERSESSION、CREATECLUSTER、CREATEDATABASELINK、REATESEQUENCE、CREATESESSION、CREATESYNONYM、CREATETABLE、CREATEVIEW
CREATEVIEW
CREATECLUSTER、CREATEPROCEDURE、CREATESEQUENCE、CREATETABLE、CREATETRIGGER
RESOURCE
CREATECLUSTER、CREATEPROCEDURE、CREATE
DBA
全部系统权限WITHADMINOPTION
EXP_FULL_DATABASE
SELECTANYTABLE、BACKUPANYTABLE、INSERT、DELETE、ANDUPDATEONTHETABLESSYS.INCVID、SYS.INCFIL、ANDSYS.INCEXP
IMP_FULL_DATABASE
BECOMEUSER
DELETE_CATALOG_ROLE
所有字典软件包上的DELETE权限
EXECUTE_CATALOG_ROLE
所有字典软件包上的EXECUTE权限
SELECT_CATALOG_ROLE
所有类别表和视图上的SELECT权限
CREATETYPE
CREATETYPE、EXECUTE、EXECUTEANYTYPE、ADMINOPTION、GRANTOPTION
RECOVERY_CATALOG_OWNER
DROPROLERECOVERY_CATALOG_OWNER、CREATEROLE、RECOVERY_CATALOG_OWNER、CREATETRIGGER、CREATEPROCEDURETORECOVERY_CATALOG_OWNER
HS_ADMIN_ROLE
HS_EXTERNAL_OBJECT、HS_EXTERNAL_USER
对象权限
对数据库中对象的访问是通过权限（privilege）来完成的。
数据库管理系统通过grant命令就可以针对特定的数据库对象使用特定的数据库命令。
例如，如果用户THUMPER拥有一个叫作EMPLOYEE的表，数据库管理员将此表的Select权授予全部用户（PUBLIC）。
那么全部用户（PUBLIC）就可以从THUMPER的EMPLOYEE表中选择记录。
数据库管理员通过授权机制，将授予权限存于数据字典中。
对表、视图、序列（以及它们的同义词）的访问，加上执行过程、函数、软件包及类型的能力都可以授权给用户。
以Oracle8i为例，下表是数据库对象权限列表。
允许的对象权限
权限授予能力
SELECT
可查询对象
INSERT
可以把行插入对象中，该权限可授予对象的特定列
UPDATE
可更新对象的行，该权限可授予对象的特定列
DELETE
可从对象中删除行
ALTER
可修改对象
INDEX
可以在表上创建索引
REFERENCES
可以创建引用表的外键
EXECUTE
可以执行函数、软件包、过程、库或类型
READ
可访问目录
可以使用withgrantoption子句向授与用户传递授权能力，以便在基对象上进一步授权。
下面的SQL*Plus清单就示出了一个这样的例子。
在这个例子中，用户用withgrantoption选项向第二个用户授予在EMPLOYEE表上SELECT和部分UPATE访问的权限。
这个用户又将其中一个权限授予另一用户JFISHER。
如果EMPLOYEE是一个分区表，不允许只对它的一个分区授予SELECT访问权。
不过，可以创建只从一个分区中选择数据的视图，然后把对这个视图的SELECT访问权授予用户。
该视图是一个附加的管理对象，但是可以用它实现分区级数据安全。
角色权限
对象权限控制管理工作复杂，可以通过创建角色（role）—即权限组—来简化权限的管理。
对于有大量用户的应用程序，角色将大大减grant命令的使用量。
由于角色可以用口令保护且能被动态地允许和禁止，所以它们给数据库增加了一个附加安全层。
以Oracle8i为例，数据库管理系统提供了一些系统级角色，如connect、resource和dba等。
角色就是一组权限的集合。
connect角色一般是授予最终用户,它具有创建会话、表和视图等的能力，但它未给用户任何表空间的定额。
由于用户没有表空间定额，所以也就不能创建表。
resource角色是授予开发人员的，它可以创建各种数据库对象，并且会给用户无限的表空间。
如果用户具有无限的表空间，它可以写一个小的脚本，然后恶意将系统用垃圾数据填满，这样数据库系统也就无法运行，并将直接导致最终的瘫痪。
所以不要轻易地把resource角色赋给用户。
dba角色包括了所有的系统级权限，并具有将这些权限授予其他用户的选项。
dba角色一般赋给系统管理员。
下面的清单中示出了角色的使用例子。
在这个例子中创建了两个角色。
第一个角色是APPLICATION_USER，被给予系统级权限CREATESESSION；被授予该角色的用户可以在数据库登录。
第二个角色是DATA_ENTRY_CLERK，被授予表上的权限。
createroleAPPLICATION_USER;
grantCREATESESSIONtoAPPLICATION_USER;
createroleDATA_ENTRY_CLERK;
grantselect,insertonTHUMPER.EMPLOYEEtoDATA_ENTRY_CLERK;
角色也可以被授予其他角色。
例如，可以把APPLICATION_USER角色授予DATA_ENTRY_CLERK角色。
如下例所示：
grantAPPLICATION_USERtoDATA_ENTRY_CLERK;
3.2.4.安全审计机制
数据库具有审计发生在其内部的所有操作的能力。
审计记录可以写入数据库系统审计记录表或操作系统的审计跟踪中。
使用操作系统审计跟踪的能力依赖于操作系统。
有三种不同的操作类型可以被审计：
登录企图、对象访问和数据库操作。
这些类型将在下面分别描述。
登录审计
每个连接数据库的企图都可被审计。
登录审计记录列出了使用的操作系统帐户、数据库帐户名、使用的终端ID、登录和注销的时间、验证结果（成功、失败当用户输入一个用户名但无口令、失败当用户输入一个无效口令）
操作审计
影响数据库对象（如一个表、数据库链接、表空间、同义词、回滚段、用户或索引）的任何操作都可被审计。
影响对象的可能操作（如create、alter和drop）可以在审计时编成组。
这些命令组可以减少建立和维护审计设置值所需管理工作量。
审计记录列出了所用的操作系统帐户、数据库帐户名、所用的终端ID，执行操作的操作外，对象拥有者和对象名，操作结果（成功，失败及失败原因）
对象审计
升级会员 