第4章 数据库安全性——4.2 数据库安全性控制

4.2  数据库安全性控制

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

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

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

4.2.1  用户身份鉴别

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

    用户身份鉴别的方法有很多种，而且在一个系统中往往是多种方法结合，以获得更强的安全性。常用的用户身份鉴别方法有以下几种。

1.静态口令鉴别

     这种方式是当前常用的鉴别方法。静态口令一般由用户自己设定，鉴别时只要按要求输入正确的口令，系统将允许用户使用数据库管理系统。这些口令是静态不变的，在实际应用中，用户常常用自己的生日、电话、简单易记的数字等内容作为口令，很容易被破解。而一旦被破解，非法用户就可以冒充该用户使用数据库。因此，这种方式虽然简单，但容易被攻击，安全性较低。

     口令的安全可靠对数据库安全来说至关重要。因此，数据库管理系统从口令的复杂度，口令的管理、存储及传输等多方面来保障口令的安全可靠。例如，要求口令长度至少是8个（或者更多）字符；口令要求是字母、数字和特殊字符混合，其中，特殊符号是除空白符、英文字母、单引号和数字外的所有可见字符。在此基础上，管理员还能根据应用需求灵活地设置口令强度，例如，设定口令中数字、字母或特殊符号的个数；设置口令是否可以是简单的常见单词，是否允许口令与用户名相同；设置重复使用口令的最小时间间隔等。此外，在存储和传输过程中口令信息不可见，均以密文方式存在。用户身份鉴别可以重复多次。

2.动态口令鉴别

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

3.生物特征鉴别

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

4.智能卡鉴别

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

4.2.2存取控制

     数据库安全最重要的点就是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，这主要通过数据库系统的存取控制机制实现。

     存取控制机制主要包括定义用户权限和合法权限检查两部分。

(1)定义用户权限，井将用户权限登记到数据字典中

     用户对某一数据对象的操作权力称为权限。其个用户应该具有何种权限是个管理问题和政策问题，而不是技术问题。数据库管理系统的功能是保证这些决定的执行。为此，数据库管理系统必须提供适当的语言来定义用户权限，这些定义经过编译后存储在数据字典中，被称做安全规则或授权规则。

(2)合法权限检查

     每当用户发出存取数据库的操作请求后(请求一般应包括操作类型、操作对象和操作用户等信息)，数据库管理系统查找数据字典，根据安全规则进行合法权限检查，若用户的操作请求超出了定义的权限，系统将拒绝执行此操作。

     定义用户权限和合法权限检查机制一起组成了数据库管理系统的存取控制子系统。

     C2级的数据库管理系统支持自主存取控制(Discretionary Access Control, DAC)，B1级的数据库管理系统支持强制存取控制(Mandatory Access Control, MAC)。

     这两类方法的简单定义是：

     (1)在自主存取控制方法中，用户对于不同的数据库对象有不同的存取权限，不同的用户对同一对象也有不同的权限，而且用户还可将其拥有的存取权限转授给其他用户。因此自主存取控制非常灵活。

     (2)在强制存取控制方法中，每一个数据库对象被标以一定的密级，每一个用户也被授予某一个级别的许可证。对于任意一个对象，只有具有合法许可证的用户才可以存取，强制存取控制因此相对比较严格。

下面介绍这两种存取控制方法。

4.2.3自主存取控制方法

     大型数据库管理系统都支持自主存取控制，SQL标准也对自主存取控制提供支持，这主要通过SQL的GRANT语句和REVOKE语句来实现。

     用户权限是由两个要素组成的：数据库对象和操作类型。定义一个用户的存取权限就是要定义这个用户可以在哪些数据库对象上进行哪些类型的操作。在数据库系统中，定义存取权限称为授权(authorization)。

     在非关系系统中，用户只能对数据进行操作，存取控制的数据库对象也仅限数据本身。

     在关系数据库系统中，存取控制的对象不仅有数据本身(基本表中的数据、属性列上的数据)，还有数据库模式（包括模式、基本表、视图和索引的创建等），表4.3列出了主要的存取权限。

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

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

4.2.4  授权：授予与收回

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

GRANT语句的一般格式为

    GRANT <权限> [,<权限>]···

    ON<对象类型> <对象名> [,<对象类型> <对象名>]···

    TO <用户> [,<用户>]···

    [WITH GRANT OPTION]；

     其语义为：将对指定操作对象的指定操作权限授予指定的用户。发出该GRANT语句的可以是数据库管理员，也可以是该数据库对象创建者(即属主owner，还可以是已经拥有该权限的用户。接受权限的用户可以是一个或多个具体用户，也可以是PUBLIC，即全体用户。

     如果指定了WITH GRANT OPTION子句，则获得某种权限的用户还可以把这种权限再授予其他的用户。如果没有指定WITH GRANT OPTION子句，则获得某种权限的用户只能使用该权限，不能传播该权限。

    SQL标准允许具有WITH GRANT OPTION的用户把相应权限或其子集传递授予其他用户，但不允许循环授权，即被授权者不能把权限再授回给授权者或其祖先，如图4.4所示。

图4.4 不允许循环授权

例4.1  把查询Student表的权限授给用户U1。

GRANT SELECT ON TABLE Student TO UI；

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

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

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

GRANT SELECT 
ON TABLE SC 
TO PUBLIC;

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

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

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

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

GRANT INSERT 
ON TABLE SC 
TO U5
WITH GRANT OPTION;

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

例4.6

GRANT INSERT ON TABLE SC TO U6 HAF LAC WITH GRANT OPTION;

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

例4.7

GRANT INSERT ON TABLE SC TO U7；

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

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

表4.4  执行了例4.1～4.7语句后学生-课程数据库的用户权限定义

02REVOKE

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

    REVOKE <权限>[，<权限>]···

    ON <对象类型><对象名> [，<对象类型><对象名>]···

    FROM <用户>[，<用户>]···[CASCADE|RESTRICT]；

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

REVOKE UPDATE(Sno) 
ON TABLE Student 
FROM U4；

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

REVOKE SELECT ON TABLE SC FROM PUBLIC;

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

REVOKE INSERT ON TABLE SC FROM U5 CASCADE；

    将用户 U5 的 INSERT 权限收回的同时，级联（CASCADE）收回了 U6 和 U7 的INSERT权限，否则系统将拒绝执行该命令。因为在例4.6中，U5将对SC表的INSERT 权限授予了U6，而U6又将其授予了U7（例4.7）。

    注意：这里默认值为 CASCADE，有的数据库管理系统默认值为 RESTRICT，将自动执行级联操作。如果U6或U7还从其他用户处获得对SC表的INSERT权限，则他们仍具有此权限，系统只收回直接或间接从U5处获得的权限。

    表4.5是执行了例4.8～4.10的语句后学生-课程数据库的用户权限定义。

表4.5 执行了例4.8～4.10语句后学生-课程数据库的用户权限定义

    SQL 提供了非常灵活的授权机制。数据库管理员拥有对数据库中所有对象的所有权限，并可以根据实际情况将不同的权限授予不同的用户。

    用户对自己建立的基本表和视图拥有全部的操作权限，并且可以用GRANT语句把其中某些权限授予其他用户。被授权的用户如果有“继续授权”的许可，还可以把获得的权限再授予其他用户。

    所有授予出去的权力在必要时又都可以用REVOKE语句收回。

    可见，用户可以“自主”地决定将数据的存取权限授予何人、决定是否也将“授权”的权限授予别人。因此称这样的存取控制是自主存取控制。

03创建数据库模式的权限

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

CREATE USER 语句一般格式如下：

CREATE USER <username>

[WITH] [DBA|RESOURCE|CONNECT];

对CREATE USER语句说明如下：

● 只有系统的超级用户才有权创建一个新的数据库用户。

● 新创建的数据库用户有三种权限：CONNECT、RESOURCE和DBA。

● CREATE USER 命令中如果没有指定创建的新用户的权限，默认该用户拥有CONNECT权限。拥有CONNECT权限的用户不能创建新用户，不能创建模式，也不能创建基本表，只能登录数据库。由数据库管理员或其他用户授予他应有的权限，根据获得的授权情况他可以对数据库对象进行权限范围内的操作。

● 拥有 RESOURCE 权限的用户能创建基本表和视图，成为所创建对象的属主，但不能创建模式，不能创建新的用户。数据库对象的属主可以使用GRANT语句把该对象上的存取权限授予其他用户。

● 拥有DBA权限的用户是系统中的超级用户，可以创建新的用户、创建模式、创建基本表和视图等；DBA拥有对所有数据库对象的存取权限，还可以把这些权限授予一般用户。

    以上说明可以用表4.6来总结。

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

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

4.2.5 数据库角色

      数据库角色是被命名的一组与数据库操作相关的权限，角色是权限的集合。因此，可以为一组具有相同权限的用户创建一个角色，使用角色来管理数据库权限可以简化授权的过程。

      在SQL中首先用CREATEROLE语句创建角色，然后用GRANT语句给角色授权，用REVOKE语句收回授予角色的权限。

01角色的创建

创建角色的SQL语句格式是

CREATE ROLE <角色名>

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

02给角色授权

GRANT<权限>[,<权限>]···

ON <对象类型>对象名

TO <角色>[,<角色>]···

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

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

GRANT<角色1>[,<角色2>]···

TO<角色3>[,<用户1>]···

[WITH ADMIN OPTION]

     该语句把角色授予某用户，或授予另一个角色。这样，一个角色（例如角色3）所拥有的权限就是授予它的全部角色（例如角色1和角色2）所包含的权限的总和。

     授予者或者是角色的创建者，或者拥有在这个角色上的ADMIN OPTION.

     如果指定了WITH ADMIN OPTION 子句，则获得某种权限的角色或用户还可以把这种权限再授予其他的角色。

     一个角色包含的权限包括直接授予这个角色的全部权限加上其他角色授予这个角色的全部权限。

04角色权限的收回

REVOKE <权限> [，<权限>]···

ON <对象类型><对象名>

FROM <角色> [，<角色>]···

      用户可以收回角色的权限，从而修改角色拥有的权限。

      REVOKE动作的执行者或者是角色的创建者，或者拥有在这个（些）角色上的ADMIN OPTION。

例4.11  通过角色来实现将一组权限授予一个用户。

步骤如下：

①首先创建一个角色R1。

CREATE ROLE R1;

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

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

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

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

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

REVOKE R1 FROM 王平；

例4.12  角色的权限修改。

GRANT DELETE
ON TABLE Student
TO R1

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

例4.13

REVOKE SELECT
ON TABLE Student
FROM R1；

使R1减少了SELECT权限。

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

4.2.6 强制存取控制方法

      自主存取控制（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），即自主存取控制与强制存取控制共同构成数据库管理系统的安全机制，如图 4.5 所示。系统首先进行自主存取控制检查，对通过自主存取控制检查的允许存取的数据库对象再由系统自动进行强制存取控制检查，只有通过强制存取控制检查的数据库对象方可存取。

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