数据库安全性

  在第一章中已经讲到，数据库的特点之一是由数据库管理系统提供统一的数据保护功能来保证数据的安全可靠和正确有效。数据库的数据保护主要包括数据的安全性和完整性。本篇主要介绍数据库的安全性。

数据库安全性概述

  数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏。安全性问题不是数据库系统所独有的，所有计算机系统都存在不安全因素，只是在数据库系统中由于大量数据集中存放，而且为众多最终用户直接共享，从而使安全性问题更为突出。系统安全保护措施是否有效是数据库系统的主要技术指标之一。

数据库的不安全因素

  对数据库安全性产生威胁的因素主要有以下几方面。

非授权用户对数据库的恶意存取和破坏

  一些黑客(hacker)和犯罪分子在用户存取数据库时猎取用户名和用户口令，然后假冒合法用户偷取、修改甚至破坏用户数据。因此，必须阻止有损数据库安全的非法操作，以保证数据免受未经授权的访问和破坏，数据库管理系统提供的安全措施主要包括用户身份鉴别、存取控制和视图等技术。

数据库中重要或敏感的数据被泄露

  黑客和敌对分子千方百计盗窃数据库中的重要数据，一些机密信息被暴露。为防止数据泄露，数据库管理系统提供的主要技术有强制存取控制、数据加密存储和加密传输等。此外，在安全性要求较高的部门提供审计功能，通过分析审计日志，可以对潜在的威胁提前采取措施加以防范，对非授权用户的入侵行为及信息破坏情况能够进行跟踪，防止对数据库安全责任的否认。

安全环境的脆弱性

  数据库的安全性与计算机系统的安全性，包括计算机硬件、操作系统、网络系统等的安全性是紧密联系的。操作系统安全的脆弱，网络协议安全保障的不足等都会造成数据库安全性的破坏。因此，必须加强计算机系统的安全性保证。随着Internet技术的发展，计算机安全性问题越来越突出，对各种计算机及其相关产品、信息系统的安全性要求越来越高。为此，在计算机安全技术方面逐步发展建立了一套可信(trusted)计算机系统的概念 和标准。只有建立了完善的可信标准即安全标准，才能规范和指导安全计算机系统部件的生产，较为准确地测定产品的安全性能指标，满足民用和军用的不同需要。

安全标准简介

  计算机以及信息安全技术方面有一系列的安全标准，最有影响的当推TCSEC和CC这两个标准。
  TCSEC是指1985年美国国防部(Department of Defense, DoD)正式颁布的《DoD可信计算机系统评估准则》(Trusted Computer System Evaluation Criteria, TCSEC 或DoD85)。
  在TCSEC推出后的10年里，不同的国家都开始启动开发建立在TCSEC概念上的评估准则，如欧洲的信息技术安全评估准则(Information Technology Security Evaluation Criteria,ITSEC)、加拿大的可信计算机产品评估准则(Canadian Trusted Computer Product Evaluation Criteria,CTCPEC)、美国的信息技术安全联邦标准(Federal Criteria,FC)草案等。这些准则比TCSEC更加灵活，适应了IT技术的发展。
  为满足全球IT市场上互认标准化安全评估结果的需要，CTCPEC、FC、TCSEC和ITSEC的发起组织于1993年起开始联合行动，解决原标准中概念和技术上的差异，将各自独立的准则集合成一组单一的、能被广泛使用的IT安全准则，这一行动被称为通用准则(Common Criteria,CC)项目。项目发起组织的代表建立了专门的委员会来开发通用准则，历经多次讨论和修订，CC V2.1版于1999年被ISO采用为国际标准，2001年被我国采用为国家标准。
  目前CC已经基本取代了TCSEC，成为评估信息产品安全性的主要标准。
  上述一系列标准的发展历史如图1所示。本节简要介绍TCSEC和CC V2.1的基本内容。

图1 信息安全标准的发展简史

  TCSEC又称桔皮书。1991年4月，美国国家计算机安全中心(National Computer Security Center,NCSC)颁布了《可信计算机系统评估准则关于可信数据库系统的解释》(TCSEC/Trusted Database Interpretation, TCSEC/TDI)，即紫皮书)，将TCSEC扩展到数据库管理系统。TCSEC/TDI中定义了数据库管理系统的设计与实现中需满足和用以进行安全性级别评估的标准，从4个方面来描述安全性级别划分的指标，即安全策略、责任、保证和文档。每个方面又细分为若干项。
  根据计算机系统对各项指标的支持情况，TCSEC/TDI将系统划分为4组(division)7个等级，依次是D、C(Cl, C2)、B(Bl, B2, B3)、A(Al)，按系统可靠或可信程度逐渐增高，如表1所示。

表1 TCSEC/TDI安全级别划分

  D级：该级是最低级别。保留D级的目的是为了将一切不符合更高标准的系统统统归于D组。如DOS就是操作系统中安全标准为D级的典型例子，它具有操作系统的基本功能，如文件系统、进程调度等，但在安全性方面几乎没有什么专门的机制来保障。
  C1级：该级只提供了非常初级的自主安全保护，能够实现对用户和数据的分离，进行自主存取控制(DAC)，保护或限制用户权限的传播。现有的商业系统往往稍作改进即可满足要求。
  C2级：该级实际上是安全产品的最低档，提供受控的存取保护，即将C1级的DAC进一步细化，以个人身份注册负责，并实施审计和资源隔离。达到C2级的产品在其名称中往往不突出“安全”（security）这一特色，如操作系统中的Windows 2000、数据库产品中的Oracle 7等。
  B1级：标记安全保护。对系统的数据加以标记，并对标记的主体和客体实施强制存取控制(MAC)以及审计等安全机制。B1级别的产品才被认为是真正意义上的安全产品，满足此级别的产品前一般多冠以“安全”（security）或"可信的”（trusted）字样，作为区别于普通产品的安全产品出售。
  B2级：结构化保护。建立形式化的安全策略模型，并对系统内的所有主体和客体实施DAC和MAC。
  B3级：安全域。该级的TCB(Trusted Computing Base)必须满足访问监控器的要求，审计跟踪能力更强，并提供系统恢复过程。
  A1级：验证设计，即提供B3级保护的同时给出系统的形式化设计说明和验证，以确信各安全保护真正实现。
  CC是在上述各评估准则及具体实践的基础上通过相互总结和互补发展而来的。和早期的评估准则相比，CC具有结构开放、表达方式通用等特点。CC提出了目前国际上公认的表述信息技术安全性的结构，即把对信息产品的安全要求分为安全功能要求和安全保证要求。安全功能要求用以规范产品和系统的安全行为，安全保证要求解决如何正确有效地实施这些功能。安全功能要求和安全保证要求都以“类-子类-组件”的结构表述，组件是安全要求的最小构件块。
  CC的文本由三部分组成，三个部分相互依存，缺一不可。
  第一部分是简介和一般模型，介绍CC中的有关术语、基本概念和一般模型以及与评估有关的一些框架。
  第二部分是安全功能要求，列出了一系列类、子类和组件。由11大类、66个子类和135个组件构成。
  第三部分是安全保证要求，列出了一系列保证类、子类和组件，包括7大类、26个子类和74个组件。根据系统对安全保证要求的支持情况提出了评估保证级(Evaluation Assurance Level,EAL)，从EAL1至EAL7共分为7级，按保证程度逐渐增高。如表4.2所示。

表2 CC评估保证级(EAL)的划分

  CC的附录部分主要介绍保护轮廓(Protection Profile,PP)和安全目标(Security Target,ST)的基本内容。
  这三部分的有机结合具体体现在保护轮廓和安全目标中，CC提出的安全功能要求和安全保证要求都可以在具体的保护轮廓和安全目标中进一步细化和扩展，这种开放式的结构更适应信息安全技术的发展。CC的具体应用也是通过保护轮廓和安全目标这两种结构来实现的。
  粗略而言，TCSEC的C1和C2级分别相当于EAL2和EAL3；Bl、B2和B3分别相当于EAL4、EAL5和EAL6；A1对应于EAL7。

数据库安全性控制

  在一般计算机系统中，安全措施是一级一级层层设置的。例如，在图2所示的安全模型中，用户要求进入计算机系统时，系统首先根据输入的用户标识进行用户身份鉴定，只有合法的用户才准许进入计算机系统；对已进入系统的用户，数据库管理系统还要进行存取控制，只允许用户执行合法操作；操作系统也会有自己的保护措施；数据最后还可以以密码形式存储到数据库中。操作系统的安全保护措施可参考操作系统的有关书籍，这里不再详述。另外，对于强力逼迫透露口令、盗窃物理存储设备等行为而采取的保安措施，例如出入机房登记、加锁等，也不在这里讨论之列。

图2 计算机系统的安全模型

  下面讨论与数据库有关的安全性，主要包括用户身份鉴别、多层存取控制、审计、视图和数据加密等安全技术。

图3 数据库管理系统安全性控制模型

  图3是数据库安全保护的一个存取控制流程。首先，数据库管理系统对提出SQL访问请求的数据库用户进行身份鉴别，防止不可信用户使用系统；然后，在SQL处理层进行自主存取控制和强制存取控制，进一步还可以进行推理控制。为监控恶意访问，可根据具体安全需求配置审计规则，对用户访问行为和系统关键操作进行审计。通过设置简单入侵检测规则，对异常用户行为进行检测和处理。在数据存储层，数据库管理系统不仅存放用户数据，还存储与安全有关的标记和信息（称为安全数据），提供存储加密功能等。

用户身份鉴别

  用户身份鉴别是数据库管理系统提供的最外层安全保护措施。每个用户在系统中都有一个用户标识。每个用户标识由用户名（user name）和用户标识号（UID）两部分组成。UID在系统的整个生命周期内是唯一的。系统内部记录着所有合法用户的标识，系统鉴别是指由系统提供一定的方式让用户标识自己的名字或身份。每次用户要求进入系统时，由系统进行核对，通过鉴定后才提供使用数据库管理系统的权限。用户身份鉴别的方法有很多种，而且在一个系统中往往是多种方法结合，以获得更强的安全性。常用的用户身份鉴别方法有以下几种。

静态口令鉴别

  这种方式是当前常用的鉴别方法。静态口令一般由用户自己设定，鉴别时只要按要求输入正确的口令，系统将允许用户使用数据库管理系统。这些口令是静态不变的，在实际应用中，用户常常用自己的生日、电话、简单易记的数字等内容作为口令，很容易被破解。而一旦被破解，非法用户就可以冒充该用户使用数据库。因此，这种方式虽然简单，但容易被攻击，安全性较低。
  口令的安全可靠对数据库安全来说至关重要。因此，数据库管理系统从口令的复杂度，口令的管理、储及传输等多方面来保障口令的安全可靠。例如，要求口令长度至少是8个（或者更多）字符；口令要求是字母、数字和特殊字符混合，其中，特殊符号是除空白符、英文字母、单引号和数字外的所有可见字符。在此基础上，管理员还能根据应用需求灵活地设置口令强度，例如，设定口令中数字、字母或特殊符号的个数：设置口令是否可以是简单的常见单词，是否允许口令与用户名相同；设置重复使用口令的最小时间间隔等。此外，在存储和传输过程中口令信息不可见，均以密文方式存在。用户身份鉴别可以重复多次。

动态口令鉴别

  它是目前较为安全的鉴别方式。这种方式的口令是动态变化的，每次鉴别时均需使用动态产生的新口令登录数据库管理系统，即采用一次一密的方法。常用的方式如短信密码和动态令牌方式，每次鉴别时要求用户使用通过短信或令牌等途径获取的新口令登录数据库管理系统。与静态口令鉴别相比，这种认证方式增加了口令被窃取或破解的难度，安全性相对高一些。

生物特征鉴别

  它是一种通过生物特征进行认证的技术，其中，生物特征是指生物体唯一具有的，可测量、识别和验证的稳定生物特征，如指纹、虹膜和掌纹等。这种方式通过采用图像处理和模式识别等技术实现了基于生物特征的认证，与传统的口令鉴别相比，无疑产生了质的飞跃，安全性较高。

智能卡鉴别

  智能卡是一种不可复制的硬件，内置集成电路的芯片，具有硬件加密功能。智能卡由用户随身携带，登录数据库管理系统时用户将智能卡插入专用的读卡器进行身份验证。由于每次从智能卡中读取的数据是静态的，通过内存扫描或网络监听等技术还是可能截取到用户的身份验证信息，存在安全隐患。因此，实际应用中一般采用个人身份识别码(PIN)和智能卡相结合的方式。这样，即使PIN或智能卡中有一种被窃取，用户身份仍不会被冒充。

存取控制

  数据库安全最重要的一点就是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，这主要通过数据库系统的存取控制机制实现。 存取控制机制主要包括定义用户权限和合法权限检查两部分。
  (1)定义用户权限，并将用户权限登记到数据字典中。用户对某一数据对象的操作权力称为权限。某个用户应该具有何种权限是个管理问题和政策问题，而不是技术问题。数据库管理系统的功能是保证这些决定的执行。为此，数据库管理系统必须提供适当的语言来定义用户权限，这些定义经过编译后存储在数据字典中，被称做安全规则或授权规则。
  (2)合法权限检查。每当用户发出存取数据库的操作请求后（请求一般应包括操作类型、操作对象和操作用户等信息），数据库管理系统查找数据字典，根据安全规则进行合法权限检查，若用户的操作请求超出了定义的权限，系统将拒绝执行此操作。定义用户权限和合法权限检查机制一起组成了数据库管理系统的存取控制子系统。C2级的数据库管理系统支持自主存取控制(Discretionary Access Control,DAC)。B1级的数据库管理系统支持强制存取控制(Mandatory Access Control,MAC)。
  这两类方法的简单定义是：
  (1)在自主存取控制方法中，用户对于不同的数据库对象有不同的存取权限，不同的用户对同一对象也有不同的权限，而且用户还可将其拥有的存取权限转授给其他用户，因此自主存取控制非常灵活。
  (2)在强制存取控制方法中，每一个数据库对象被标以一定的密级，每一个用户也被授予某一个级别的许可证。对于任意一个对象，只有具有合法许可证的用户才可以存取。强制存取控制因此相对比较严格。
  下面介绍这两种存取控制方法。

自主存取控制方法

  大型数据库管理系统都支持自主存取控制，SQL标准也对自主存取控制提供支持，这主要通过SQL的GRANT语句和REVOKE语句来实现。
  用户权限是由两个要素组成的：数据库对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据库对象上进行哪些类型的操作。在数据库系统中，定义存取权限称为授权(authorization)。
  在非关系系统中，用户只能对数据进行操作，存取控制的数据库对象也仅限于数据本身。在关系数据库系统中，存取控制的对象不仅有数据本身(基本表中的数据、属性列上的数据），还有数据库模式（包括数据库、基本表、视图和索引的创建等），表3列出了主要的存取权限。

表3 关系数据库系统中的存取权限

  表3中，列权限包括SELECT、REFERENCES、INSERT、UPDATE，其含义与表权限类似。需要说明的是，对列的UPDATE权限指对于表中存在的某一列的值可以进行修改。当然，有了这个权限之后，在修改的过程中还要遵守表在创建时定义的主码及其他约束。列上的INSERT权限指用户可以插入一个元组。对于插入的元组，授权用户可以插入指定的值，其他列或者为空，或者为默认值。在给用户授予列INSERT权限时，一定要包含主码的INSERT权限，否则用户的插入动作会因为主码为空而被拒绝。

授权：授予与收回

  SQL中使用GRANT和REVOKE语句向用户授予或收回对数据的操作权限。GRANT语句向用户授予权限，REVOKE语句收回己经授予用户的权限。

GRANT

  GRANT语句的一般格式为

1
2
3
4

GRANT <权限> [,<权限>]···
ON <对象类型><对象名> [,<对象类型><对象名>]···
TO <用户>[,<用户>]···
[WITH GRANT OPTION]; 

  其语义为：将对指定操作对象的指定操作权限授予指定的用户。发出该GRANT语句的可以是数据库管理员，也可以是该数据库对象创建者（即属主owner），还可以是已经拥有该权限的用户。接受权限的用户可以是一个或多个具体用户，也可以是PUBLIC，即全体用户。
  如果指定了WITH GRANT OPTION子句，则获得某种权限的用户还可以把这种权限再授予其他的用户。如果没有指定WITH GRANT OPTION子句，则获得某种权限的用户只能使用该权限，不能传播该权限。
  SQL标准允许具有WITH GRANT OPTION的用户把相应权限或其子集传递授予其他用户，但不允许循环授权，即被授权者不能把权限再授回给授权者或其祖先，如图4所示。

图4 不允许循环授权

  例1：把查询Student表的权限给用户U1。

1
2
3

GRANT SELECT
ON TABLE Student
TO U1;

  例2：把对Student表和Course表的全部操作权限授予用户U2和U3。

1
2
3

GRANT ALL PRIVILEGES
ON TABLE Student, Course
TO U2,U3;

  例3：把对表SC的查询权限授予所有用户。

1
2
3

GRANT SELECT
ON TABLE SC
TO PUBLIC;

  例4：把查询Student表和修改学生学号的权限授给用户U4。

1
2
3

GRANT UPDATE(Sno),SELECT
ON TABLE Student
TO U4;

  这里，实际上要授予U4用户的是对基本表Student的SELECT权限和对属性列Sno的UPDATE权限。对属性列授权时必须明确指出相应的属性列名。

  例5：把对表SC的INSERT权限授予U5用户，并允许将此权限再授予其他用户。

1
2
3
4

GRANT INSERT
ON TABLE SC
TO U5
WITH GRANT OPTION;

  执行此SQL语句后，U5不仅拥有了对表SC的INSERT权限，还可以传播此权限，即由U5用户发上述GRANT命令给其他用户。例如U5可以将此权限授予U6（例6）。

  例6：

1
2
3
4

GRANT INSERT
ON TABLE SC
TO U6
WITH GRANT OPTION;

  同样，U6还可以将此权限授予U7（例7）。

  例7：

1
2
3

GRANT INSERT
ON TABLE SC
TO U7;

  因为U6未给U7传播的权限，因此U7不能再传播此权限。

  由上面的例子可以看到，GRANT语句可以一次向一个用户授权，如例1所示，这是 最简单的一种授权操作；也可以一次向多个用户授权，如例2、例3所示；还可以一次传播多个同类对象的权限，如例2所示；甚至一次可以完成对基本表和例3属性列这些不同对象的授权，如例4所示。表4是执行了例1~例7的语句后学生—课程数据库中的用户权限定义表。

表4 学生—课程数据库中的用户权限定义

REVOKE

  授予用户的权限可以由数据库管理员或其他授权者用REVOKE语句收回，REVOKE语句的一般格式为

1
2
3

REVOKE <权限> [,<权限>] ···
ON <对象类型><对象名> [,<对象类型><对象名>] ···
FROM <用户> [,<用户>] ··· [CASCADE|RESTRICT];

  例8：把用户U4修改学生学号的权限收回。

1
2
3

REVOKE UPDATE(Sno)
ON TABLE Student
FROM U4;

  例9：收回所有用户对表SC的查询权限。

1
2
3

REVOKE SELECT
ON TABLE SC
FROM PUBLIC;

  例10：把用户U5对SC表的INSERT权限收回。

1
2
3

REVOKE INSERT
ON TABLE SC
FROM U5 CASCADE;

  将用户U5的INSERT权限收回的同时，级联（CASCADE）收回了U6和U7的INSERT权限，否则系统将拒绝执行该命令。因为在例6中，U5将对SC表的INSERT权限授予了U6，而U6又将其授予了U7（例7）。
  注意：这里默认值为CASCADE，有的数据库管理系统默认值为RESTRICT，将自动执行级联操作。如果U6或U7还从其他用户处获得对SC表的INSERT权限，则 他们仍具有此权限，系统只收回直接或间接从U5处获得的权限。 表5是执行了例8~例10的语句后学生-课程数据库的用户权限定义。

表5 学生—课程数据库中的用户权限定义

  SQL提供了非常灵活的授权机制。数据库管理员拥有对数据库中所有对象的所有权限，并可以根据实际情况将不同的权限授予不同的用户。
  用户对自己建立的基本表和视图拥有全部的操作权限，并且可以用GRANT语句把其中某些权限授予其他用户。被授权的用户如果有“继续授权”的许可，还可以把获得的权限再授予其他用户。
  所有授予出去的权力在必要时又都可以用REVOKE语句收回。
  可见，用户可以“自主”地决定将数据的存取权限授予何人、决定是否也将“授权” 的权限授予别人。因此称这样的存取控制是自主存取控制。

创建数据库模式的权限

  GRANT和REVOKE语句向用户授予或收回对数据的操作权限。对创建数据库模式一类的数据库对象的授权则由数据库管理员在创建用户时实现。
  CREATE USER语句一般格式如下：

1

CREATE USER <usemame> [WITH] [DBA | RESOURCE | CONNECT];

  对CREATE USER语句说明如下：
  ◦只有系统的超级用户才有权创建一个新的数据库用户。
  ◦新创建的数据库用户有三种权限：CONNECT、RESOURCE和DBA。
  ◦CREATE USER命令中如果没有指定创建的新用户的权限，默认该用户拥有CONNECT权限。拥有CONNECT权限的用户不能创建新用户，不能创建模式，也不能创建基本表，只能登录数据库。由数据库管理员或其他用户授予他应有的权限，根据获得的授权情况他可以对数据库对象进行权限范围内的操作。
  ◦拥有RESOURCE权限的用户能创建基本表和视图，成为所创建对象的属主，但不能创建模式，不能创建新的用户。数据库对象的属主可以使用GRANT语句把该对象上的存取权限授予其他用户。
  ◦拥有DBA权限的用户是系统中的超级用户，可以创建新的用户、创建模式、创建基 本表和视图等；DBA拥有对所有数据库对象的存取权限，还可以把这些权限授予一般用户。以上说明可以用表6来总结。

表6 权限与可执行的操作对照表

  注意：CREATE USER语句不是SQL标准，因此不同的关系数据库管理系统的语法和内容相差甚远。这里介绍该语句的目的是说明对于数据库模式这一类数据对象也有安全控制的需要，也是要授权的。

数据库角色

  数据库角色是被命名的一组与数据库操作相关的权限，角色是权限的集合。因此，可以为一组具有相同权限的用户创建一个角色，使用角色来管理数据库权限可以简化授权的过程。
  在SQL中首先用CREATE ROLE语句创建角色，然后用GRANT语句给角色授权，用REVOKE语句收回授予角色的权限。

角色的创建

  创建角色的SQL语句格式是

1

CREATE ROLE <角色名>

  刚刚创建的角色是空的，没有任何内容。可以用GRANT为角色授权。

给角色授权

1
2
3

GRANT <权限> [,<权限>] ···
ON <对象类型> 对象名
TO <角色> [,<角色>] ···

  数据库管理员和用户可以利用GRANT语句将权限授予某一个或几个角色。

将一个角色授予其他的角色或用户

1
2
3

GRANT <角色1> [,<角色2>] ···
TO <角色3> [,<用户1>] ···
[WITH ADMIN OPTION]

  该语句把角色授予某用户，或授予另一个角色。这样，一个角色（例如角色3）所拥有的权限就是授予它的全部角色（例如角色1和角色2）所包含的权限的总和。
  授予者或者是角色的创建者，或者拥有在这个角色上的ADMIN OPTION。
  如果指定了WITH ADMIN OPTION子句，则获得某种权限的角色或用户还可以把这种权限再授予其他的角色。
  一个角色包含的权限包括直接授予这个角色的全部权限加上其他角色授予这个角色的全部权限。

角色权限的收回

1
2
3

REVOKE <权限>[,<权限>] ···
ON <对象类型> <对象名>
FROM <角色> [,<角色>] ···

  用户可以收回角色的权限，从而修改角色拥有的权限。
  REVOKE动作的执行者或者是角色的创建者，或者拥有在这个（些）角色上的ADMIN OPTION。

  例11：通过角色来实现将一组权限授予一个用户。
  步骤如下：   ①首先创建一个角色R1。

1

CREATE ROLE R1;

  ②然后使用GRANT语句，使角色R1拥有Student表的SELECT、UPDATE、INSERT权限。

1
2
3

GRANT SELECT,UPDATE,INSERT
ON TABLE Student
TO R1;

  ③将这个角色授予王平、张明、赵玲，使他们具有角色R1所包含的全部权限。

1
2

GRANT R1
TO 王平，张明，赵玲;

  ④当然，也可以一次性地通过R1来收回王平的这三个权限。

1
2

REVOKE R1
FROM王平;

  例12：角色的权限修改。

1
2
3

GRANT DELETE
ON TABLE Student
TO R1;

  使角色R1在原来的基础上增加了Student表的DELETE权限。

  例13：

1
2
3

REVOKE SELECT
ON TABLE Student
FROM R1;

  使R1减少了SELECT权限。
  可以看出，数据库角色是一组权限的集合。使用角色来管理数据库权限可以简化授权的过程，使自主授权的执行更加灵活、方便。

强制存取控制方法

  自主存取控制（MAC）能够通过授权机制有效地控制对敏感数据的存取。但是由于用户对数据的存取权限是“自主”的，用户可以自由地决定将数据的存取权限授予何人，以及决定是否也将“授权”的权限授予别人。在这种授权机制下，仍可能存在数据的“无意泄露”。比如，甲将自己权限范围内的某些数据存取权限授权给乙，甲的意图是仅允许乙本人操纵这些数据。但甲的这种安全性要求并不能得到保证，因为乙一旦获得了对数据的权限，就可以将数据备份，获得自身权限内的副本，并在不征得甲同意的前提下传播副本。造成这一问题的根本原因就在于，这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记。要解决这一问题，就需要对系统控制下的所有主客体实施强制存取控制策略。
  所谓强制存取控制是指系统为保证更高程度的安全性，按照TDI/TCSEC标准中安全策略的要求所采取的强制存取检查手段。它不是用户能直接感知或进行控制的。强制存取控制适用于那些对数据有严格而固定密级分类的部门，例如军事部门或政府部门。
  在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类。
  主体是系统中的活动实体，既包括数据库管理系统所管理的实际用户，也包括代表用户的各进程。客体是系统中的被动实体，是受主体操纵的，包括文件、基本表、索引、视图等。对于主体和客体，数据库管理系统为它们每个实例（值）指派一个敏感度标记(label)。敏感度标记被分成若干级别，例如绝密(Top Secret,TS)、机密(Secret,S)、可信(Confidential,C)、公开(Public,P)等。密级的次序是TS>=S>=C>=P。主体的敏感度标记称为许可证级别(clearance level)，客体的敏感度标记称为密级(classification level)。强制存取控制机制就是通过对比主体的敏感度标记和客体的敏感度标记，最终确定主体是否能够存取客体。
  当某一用户（或某一主体）以标记label注册入系统时，系统要求他对任何客体的存取必须遵循如下规则：
  (1)仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体。
  (2)仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体。
  规则(1)的意义是明显的，而规则(2)需要解释一下。按照规则(2)，用户可以为写入的数据对象赋予高于自己的许可证级别的密级。这样一旦数据被写入，该用户自己也不能再读该数据对象了。如果违反了规则(2)，就有可能把数据的密级从高流向低，造成数据的泄漏。例如，某个TS密级的主体把一个密级为TS的数据恶意地降低为P，然后把它写回。这样原来是TS密级的数据大家都可以读到了，造成TS密级数据的泄露。
  强制存取控制是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据，从而提供了更高级别的安全性。前面已经提到，较高安全性级别提供的安全保护要包含较低级别的所有保护，因此在实现强制存取控制时要首先实现自主存取控制(DAC)，即自主存取控制与强制存取控制共同构成数据库管理系统的安全机制，如图5所示。系统首先进行自主存取控制检查，对通过自主存取控制检查的允许存取的数据库对象再由系统自动进行强制存取控制检查，只有通过强制存取控制检查的数据库对象方可存取。

图5 DAC+MAC安全检查示意图

视图机制

  还可以为不同的用户定义不同的视图，把数据对象限制在一定的范围内。也就是说，通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动对数据提供一定程度的安全保护。
  视图机制间接地实现支持存取谓词的用户权限定义。例如，在某大学中假定王平老师只能检索计算机系学生的信息，系主任张明具有检索和增删改计算机系学生信息 的所有权限。这就要求系统能支持“存取谓词”的用户权限定义。在不直接支持存取谓词的系统中，可以先建立计算机系学生的视图CS_Student，然后在视图上进一步定义存取权限。

  例14：建立计算机系学生的视图，把对该视图的SELECT权限授予王平，把该视图上的所有操作权限授予张明。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

CREATE VIEW CS_Student /*先建立视图 CS Student*/
AS
SELECT *
FROM Student WHERE Sdept='CS';

GRANT SELECT /*王平老师只能检索计算机系学生的信息*/
ON CS_Student TO 王平;

GRANT ALL PRIVILEGES /*系主任具有检索和增删改计算机系学生信息的所有权限*/
ON CS Student
TO 张明;

审计

  前面讲的用户身份鉴别、存取控制是数据库安全保护的重要技术（安全策略方面），但不是全部。为了使数据库管理系统达到一定的安全级别，还需要在其他方面提供相应的支持。例如按照TDI/TCSEC标准中安全策略的要求，审计(audit)功能就是数据库管理系统达到C2以上安全级别必不可少的一项指标。   因为任何系统的安全保护措施都不是完美无缺的，蓄意盗窃、破坏数据的人总是想方设法打破控制。审计功能把用户对数据库的所有操作自动记录下来放入审计日志(audit log)中。审计员可以利用审计日志监控数据库中的各种行为，重现导致数据库现有状况的一系列事件，找出非法存取数据的人、时间和内容等。还可以通过对审计日志分析，对潜在的威胁提前采取措施加以防范。
  审计通常是很费时间和空间的，所以数据库管理系统往往都将审计设置为可选特征，允许数据库管理员根据具体应用对安全性的要求灵活地打开或关闭审计功能。审计功能主要用于安全性要求较高的部门。
  可审计事件有服务器事件、系统权限、语句事件及模式对象事件，还包括用户鉴别、自主访问控制和强制访问控事件。换句话说，它能对普通和特权用户行为、各种表操作、身份鉴别、自主和强制访问控制等操作进行审计。它既能审计成功操作，也能审计失败操作。

审计事件

  审计事件一般有多个类别，例如，
  ◦服务器事件：审计数据库服务器发生的事件，包含数据库服务器的启动、停止、数 据库服务器配置文件的重新加载。
  ◦系统权限：对系统拥有的结构或模式对象进行操作的审计，要求该操作的权限是通 过系统权限获得的。
  ◦语句事件：对SQL语句，如DDL、DML、DQL(Data Query Language,数据查询 语言)及DCL语句的审计。
  ◦模式对象事件：对特定模式对象上进行的SELECT或DML操作的审计。模式对象 包括表、视图、存储过程、函数等。模式对象不包括依附于表的索引、约束、触发器、分 区表等。

审计功能

  审计功能主要包括以下几方面内容：
  ◦基本功能，提供多种审计查阅方式：基本的、可选的、有限的，等等。
  ◦提供多套审计规则，审计规则一般在数据库初始化时设定，以方便审计员管理。
  ◦提供审计分析和报表功能。
  ◦审计日志管理功能，包括为防止审计员误删审计记录，审计日志必须先转储后删除；对转储的审计记录文件提供完整性和保密性保护；只允许审计员查阅和转储审计记录，不允许任何用户新增和修改审计记录；等等。
  ◦系统提供查询审计设置及审计记录信息的专门视图。对于系统权限级别、语句级别 及模式对象级别的审计记录也可通过相关的系统表直接查看。

AUDIT语句和NOAUDIT语句

  AUDIT语句用来设置审计功能，NOAUDIT语句则取消审计功能。
  审计一般可以分为用户级审计和系统级审计。用户级审计是任何用户可设置的审计， 主要是用户针对自己创建的数据库表或视图进行审计，记录所有用户对这些表或视图的一切成功和(或)不成功的访问要求以及各种类型的SQL操作。
  系统级审计只能由数据库管理员设置，用以监测成功或失败的登录要求、监测授权和收回操作以及其他数据库级权限下的操作。

  例15：对修改SC表结构或修改SC表数据的操作进行审计。

1
2

AUDIT ALTER, UPDATE
ON SC;

  例16：取消对SC表的一切审计。

1
2

NOAUDIT ALTER, UPDATE
ON SC;

  审计设置以及审计日志一般都存储在数据字典中。必须把审计开关打开（即把系统参数audit_trail设为true），才可以在系统表SYS_AUDITTRAIL中查看到审计信息。
  数据库安全审计系统提供了一种事后检查的安全机制。安全审计机制将特定用户或者 特定对象相关的操作记录到系统审计日志中，作为后续对操作的查询分析和追踪的依据。通过审计机制，可以约束用户可能的恶意操作。

数据加密

  对于高度敏感性数据，例如财务数据、军事数据、国家机密数据等，除前面介绍的安全性措施外，还可以采用数据加密技术。数据加密是防止数据库数据在存储和传输中失密的有效手段。加密的基本思想是根据一定的算法将原始数据——明文(plain text)变换为不可直接识别的格式——密文(cipher text)，从而使得不知道解密算法的人无法获知数据的内容。
  数据加密主要包括存储加密和传输加密。

存储加密

  对于存储加密，一般提供透明和非透明两种存储加密方式。透明存储加密是内核级加密保护方式，对用户完全透明；非透明存储加密则是通过多个加密函数实现的。
  透明存储加密是数据在写到磁盘时对数据进行加密，授权用户读取数据时再对其进行解密。由于数据加密对用户透明，数据库的应用程序不需要做任何修改，只需在创建表语句中说明需加密的字段即可。当对加密数据进行增、删、改、查询操作时，数据库管理系统将自动对数据进行加、解密工作。基于数据库内核的数据存储加密、解密方法性能较好，安全完备性较高。

传输加密

  在客户/服务器结构中，数据库用户与服务器之间若采用明文方式传输数据，容易被网 络恶意用户截获或篡改，存在安全隐患。因此，为保证二者之间的安全数据交换，数据库管理系统提供了传输加密功能。
  常用的传输加密方式如链路加密和端到端加密。其中，链路加密对传输数据在链路层进行加密，它的传输信息由报头和报文两部分组成，前者是路由选择信息，而后者是传送的数据信息。这种方式对报文和报头均加密。相对地，端到端加密对传输数据在发送端加密，接收端解密。它只加密报文，不加密报头。与链路加密相比，它只在发送端和接收端需要密码设备，而中间节点不需要密码设备，因此它所需密码设备数量相对较少。但这种方式不加密报头，从而容易被非法监听者发现并从中获取敏感信息。
  图6是一种基于基于安全套接层协议(Security Socket Layer, SSL)的数据库管理系统可信传输方案。它采用的是一种端到端的传输加密方式。在这个方案中，通信双方协商建立可信连接，一次会话采用一个密钥，传输数据在发送端加密，接收端解密，有效降低了重放攻击和恶意篡改的风险。此外，出于易用性考虑，这个方案的通信加密还对应用程序透明。它的实现思路包含以下三点。

图6 数据库管理系统可信传输示意图

  (1)确认通信双方端点的可靠性
  数据库管理系统采用基于数字证书的服务器和客户端认证方式实现通信双方的可靠性确认。用户和服务器各自持有由知名数字证书认证(Certificate Authority, CA)中心或企业内建CA颁发的数字证书，双方在进行通信时均首先向对方提供己方证书，然后使用本地的CA信任列表和证书撤销列表(Certificate Revocation List, CRL)对接收到的对方证书进行验证，以确保证书的合法性和有效性，进而保证对方确系通信的目的端。
  (2)协商加密算法和密钥
  确认双方端点的可靠性后，通信双方协商本次会话的加密算法与密钥。在这个过程中, 通信双方利用公钥基础设施(Public Key Infrastructure, PKI)方式保证了服务器和客户端的协商过程通信的安全可靠。
  (3)可信数据传输
  在加密算法和密钥协商完成后，通信双方开始进行业务数据交换。与普通通信路径不同的是，这些业务数据在被发送之前将被用某一组特定的密钥进行加密和消息摘要计算，以密文形式在网络上传输。当业务数据被接收的时候，需用相同一组特定的密钥进行解密和摘要计算。所谓特定的密钥，是由先前通信双方磋商决定的，为且仅为双方共享，通常称之为会话密钥。第三方即使窃取传输密文，因无会话密钥也无法识别密文信息。一旦第三方对密文进行任何篡改，均将会被真实的接收方通过摘要算法识破。另外，会话密钥的生命周期仅限于本次通信，理论上每次通信所采用的会话密钥将不同，因此避免了使用固定密钥而引起的密钥存储类问题。
  数据库加密使用已有的密码技术和算法对数据库中存储的数据和传输的数据进行保护。加密后数据的安全性能够进一步提高。即使攻击者获取数据源文件，也很难获取原始数据。但是，数据库加密增加了查询处理的复杂性，查询效率会受到影响。加密数据的密钥的管理和数据加密对应用程序的影响也是数据加密过程中需要考虑的问题。

其他安全性保护

  为满足较高安全等级数据库管理系统的安全性保护要求，在自主存取控制和强制存取控制之外，还有推理控制以及数据库应用中隐蔽信道和数据隐私保护等技术。
  推理控制(inference control)‌处理的是强制存取控制未解决的问题。例如，利用列的函数依赖关系，用户能从低安全等级信息推导出其无权访问的高安全等级信息，进而导致信息泄露。
  数据库推理控制机制用来避免用户利用其能够访问的数据推知更高密级的数据，即用户利用其被允许的多次查询的结果，结合相关的领域背景知识以及数据之间的约束，推导出其不能访问的数据。在推理控制方面，常用的方法如基于函数依赖的推理控制和基于敏感关联的推理控制等。例如，某个公司信息系统中假设姓名和职务属于低安全等级（如公开）信息，而工资属于高安全等级（如机密）信息。用户A的安全等级较低，他通过授权可以查询自己的工资、姓名、职务，及其他用户的姓名和职务。由于工资是机密信息，因此用户A不应知道其他用户的工资。但是，若用户B的职务和用户A相同，则利用函数依赖关系职务—＞工资，用户A可通过自己的工资信息（假设3000元），推出B的工资也是3000元，从而导致高安全等级的敏感信息泄露。
  隐蔽信道(covert channa)处理内容也是强制存取控制未解决的问题。下面的例子就是利用未被强制存取控制的SQL执行后反馈的信息进行间接信息传递。
  通常，如果INSERT语句对UNIQUE属性列写入重复值，则系统会报错且操作失败。那么，针对UNIQUE约束列，高安全等级用户(发送者)可先向该列插入(或者不插入)数据，而低安全等级用户(接收者)向该列插入相同数据。
  如果插入失败，则表明发送者已向该列插入数据，此时二者约定发送者传输信息位为0；如果插入成功，则表明发送者未向该列插入数据，此时二者约定发送者传输信息位为1。通过这种方式，高安全等级用户按事先约定方式主动向低安全等级用户传输信息，使得信息流从高安全等级向低安全等级流动，从而导致高安全等级敏感信息泄露。
  随着人们对隐私的重视，数据隐私(data privacy)成为数据库应用中新的数据保护模式。
  所谓数据隐私是控制不愿被他人知道或他人不便知道的个人数据的能力。数据隐私范围很广，涉及数据管理中的数据收集、数据存储、数据处理和数据发布等各个阶段。例如，在数据存储阶段应避免非授权的用户访问个人的隐私数据。通常可以使用数据库安全技术实现这一阶段的隐私保护。如使用自主访问控制、强制访问控制和基于角色的访问控制以及数据加密等。在数据处理阶段，需要考虑数据推理带来的隐私数据泄露。非授权用户可能通过分析多次查询的结果，或者基于完整性约束信息，推导出其他用户的隐私数据。在数据发布阶段，应使包含隐私的数据发布结果满足特定的安全性标准。如发布的关系数据表首先不能包含原有表的候选码，同时还要考虑准标识符的影响。
  准标识符是能够唯一确定大部分记录的属性集合。在现有安全性标准中，k-匿名化(k-anonymization)标准要求每个具有相同准标识符的记录组中至少包括k条记录，从而控制攻击者判别隐私数据所属个体的概率。还有1-多样化标准(1-diversity)、t-临近标准(t-closeness)等，从而使攻击者不能从发布数据中推导出额外的隐私数据。数据隐私保护也是当前研究的热点。
  要想万无一失地保证数据库安全，使之免于遭到任何蓄意的破坏几乎是不可能的。但高度的安全措施将使蓄意的攻击者付出高昂的代价，从而迫使攻击者不得不放弃他们的破坏企图。

小结

  随着数据库应用的深入和计算机网络的发展，数据的共享日益加强，数据的安全保密越来越重要。数据库管理系统是管理数据的核心，因而其自身必须具有一整套完整而有效的安全性机制。
  实现数据库系统安全性的技术和方法有多种，数据库管理系统提供的安全措施主要包括用户身份鉴别、自主存取控制和强制存取控制技术、视图技术和审计技术、数据加密存储和加密传输等。本章简要讲解了这些技术。

  在我的生命里，除了爱情找不到别的意义，于是紧紧抓着它。除了期待我的爱人到来之外，我什么也不等待，也不愿等待。

― 安德烈·纪德, 《窄门》