第四章——数据库的安全性

---

前言

问题的提出：数据库安全性产生的原因

• 数据库的一大特点是共享性
• 数据共享必然带来数据库安全性问题
• 数据库系统中的数据共享不能是无条件的共享

---

4.1 数据库安全性概述

数据库的安全性是指保护数据库以防止不合法的使用所造成的的数据泄露、更改或破坏
系统安全保护措施是否有效是数据库系统主要的性能指标之一

4.1.1数据库的不安全因素

• 非授权用户对数据库的恶意存取和破坏
  一些黑客（Hacker）和犯罪分子在用户存取数据库时猎取用户名和用户口令，然后假冒合法用户偷取、修改甚至破坏用户数据。数据库管理系统提供的安全措施主要包括用户身份鉴别、存取控制和视图等技术。
• 数据库中重要的敏感数据被泄露
  黑客和敌对分子千方百计盗窃数据库中的重要数据，一些机密信息被暴露。为防止数据泄露，数据库管理系统提供的主要技术有强制存取控制、数据加密存储和加密传输等，同时部分安全性要求高的部门提供审计日志分析。
• 安全环境的脆弱性
  数据库的安全性与计算机系统的安全性紧密联系。计算机硬件、操作系统、网络系统等的安全性脆弱。建立一套可信（Trusted）计算机系统的概念和标准。

4.1.2 安全标准简介

信息安全标准发展史

TCSEC/TDI安全级别划分

2 CC标准

CC评估保证级（EAL）划分

4.2数据库安全性控制

计算机系统中，安全措施是一级一级层层设置：


数据库安全性控制的常用方法：用户标识和鉴定、存取控制、视图、审计、数据加密

4.2.1用户身份鉴别

这是系统提供的最外层安全保护措施，用户标识：由用户名（user name）和用户标识号（UID）组成（用户标识号（UID）在系统整个生命周期内唯一）

4.2.2 存取控制

数据库安全最重要的一点是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，通过存取控制机制实现。
存取控制主要包括定义用户权限和合法权限检查两部分

1. 定义用户权限

用户对某一数据对象的操作权力称为权限，DBMS提供适当的语言来定义用户权限，存放在数据字典中，称做安全规则或授权规则

2. 合法权限检查
   用户发出存取数据库操作请求，DBMS查找数据字典，进行合法权限检查，若请求超定义的权限，系统将拒绝执行此操作

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

常用存取控制方法：

• 自主存取控制（DAC）
  C2级
  用户对不同的数据对象有不同的存取权限
  不同的用户对同一对象也有不同的权限
  用户还可将其拥有的存取权限转授给其他用户

• 强制存取控制（MAC）
  B1级
  每一个数据对象被标以一定的密级
  每一个用户也被授予某一个级别的许可证
  对于任意一个对象，具有合法许可证的用户才可以存取

4.2.3 自主存取控制方法

通过 SQL 的GRANT 语句和REVOKE 语句实现
用户权限组成：数据对象 + 操作类型
定义用户存取权限：定义用户可以在哪些数据库对象上进行哪些操作
定义存取权限称为授权

关系数据库系统中存取控制对象：
（ps：ALL PRIVLEGES 即全部权限）

4.2.4 授权：授予与回收

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

• 1 GRANT 授予：

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

WITH GRANT OPTION子句:
指定：可以再授予其他用户
没有指定：不能传播改权限
注：不允许循环授权

语义：将对指定操作对象的指定操作权限授予指定的用户（即写了WITH GRANT OPTION的话，TO之后的用户能继续传播相应的权限）



ALL 权限已不再推荐使用，并且只保留用于兼容性目的。它并不表示对实体定义了 ALL 权限。 官方文档中对参数ALL有以下讲解，很不错！

*来看例 6*： 使用登录名U5登录后执行如下语句（因为在一个数据库中登录名和用户名是一一对应的，所以登录U5后切换至STUDENT数据库进行如下操作实验），将权限授予给U6：
（ps：登录名必须映射到数据库用户才能连接到数据库。 一个登录名可以作为不同用户映射到不同的数据库，但在每个数据库中只能作为一个用户进行映射）

- 2 REVOKE 回收
授予的权限可以由数据库管理员或其他授权者用REVOKE语句收回
REVOKE的语句格式：

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

因为U5还将该权限传播给了U6和U7，所以将U5的INSERT权限收回的时候应该使用CASCADE（级联收回）

小结：SQL灵活的授权机制

• 3 数据库模式的权限
  
  
  

4.2.5 数据库角色

1.角色的创建

CREATE ROLE <角色名> 

2.给角色授权

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

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

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

ps：该语句把角色授予某用户，或授予另一个角色，授予者是角色的创建者或拥有在这个角色上的ADMIN OPTION（即授予者能传播该权限）
指定了WITH ADMIN OPTION则获得某种权限的角色或用户还可以把这种权限授予其他角色（能继续传播该权限）
一个角色的权限：直接授予这个角色的全部权限 + 其他角色授予这个角色的全部权限（这和上面例子中用户权限可以叠加起来（来自很多用户授予）是一样的，即这里某个角色的权限可以来自很多角色）

4.角色权限的收回

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

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




在SQL sever中我们使用以下语法添加或删除角色

（ps：需要注意的是，一条SQL语句只能添加一个角色！！）

4.2.6 强制存取控制

自主存取控制缺点： 可能存在数据的“无意泄露”
原因：这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记
（自主存取控制能够通过授权机制有效地控制其他用户对敏感数据的存取。但是由于用户对数据的存取权限是“自主”的，用户可以自由地决定将数据的存取权限授予何人、决定是否也将“授权”的权限授予别人。在这种授权机制下，仍可能存在数据的“无意泄露”）
解决：对系统控制下的所有主客体实施强制存取控制策略
————————————————
强制存取控制（MAC）：

• 保证更高程度的安全性
• 用户不能直接感知或进行控制
• 适用于对数据有严格而固定密级分类的部门：军事部门、政府部门

在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类

• 主体是系统中的活动实体，即：数据库管理系统所管理的实际用户
• 客体是系统中的被动实体，受到主体的操纵，即：文件、基本表、索引、视图

敏感度标记（Label）： 对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记（Label）
敏感度标记分成若干级别：

绝密（Top Secret，TS）
机密（Secret，S）
可信（Confidential，C）
公开（Public，P）
TS>=S>=C>=P

主体的敏感度标记称为许可证级别（Clearance Level）
客体的敏感度标记称为密级（Classification Level）

强制存取控制规则：
（1）仅当主体的许可证级别大于或等于客体的密级时，该主体才能读相应的客体
（2）仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体

简单记作：向下读，向上写

就比如，某个TS（绝密）密级的主体把一个密级为TS的数据恶意地降为P（公开），然后把它写回。这样原来是TS密级的数据大家都可以读到了，这样就导致了TS密级数据的泄露
另一方面，如果许可证级别大于客体的密级能写的话也很可怕，因为上级（领导）能在大家不知道的情况下随意修改，这，，，肯定是不行的
至于为什么等于，是因为自己写的东西自己肯定也要能看到吖，不然自己写完就看不到了，写错了或是想再看看也没办法了，no way，，，

4.3 视图机制

把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护
视图机制间接地实现支持存取谓词的用户权限定义

什么是“存取谓词”？
我的理解是，存取谓词是能直接对数据进行操作（增删改查）的谓词，需要系统能支持给用户定义相关的存取谓词的权限，在不支持存取谓词的系统中，可以先建立相关视图，然后在视图上进一步定义存取权限。
为什么要用视图间接实现，直接用基本表不可以么？
emmm，可以为不同的用户定义不同的视图，把数据对象限制在一定的范围内，也就是说，通过视图机制把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护（不想让他看到的数据就不定义在视图里，这相对于直接给他看基本表要安全很多）

4.4 审计（Audit）

什么是审计：

• 审计日志（Audit Log）： 将用户对数据库的所有操作记录在上面（就像记录流水账一样的）
• 审计员利用审计日志：
  监控数据库中的各种行为找出非法存取数据的人、时间和内容。
• 审计功能的可选性：
  审计很费时间和空间
  DBA可以打开或关闭审计功能，灵活的打开或关闭审计功能
  审计功能主要用于安全性要求较高的部门

4.4.1 审计事件

4.4.2 审计功能

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

AUDIT ALTER, UPDATE  
ON SC;

这里T-SQL是不支持这样写的，具体写法暂时没搞明白，待弄清楚之后第一时间回来更新补充上~
先附上官方文档：SQL Server 审核（数据库引擎）
来看例 2： 取消对SC表的一切审计：

NOAUDIT ALTER, UPDATE  
ON SC;

适用于T-SQL的写法例子

4.5 数据加密

数据加密： 防止数据库中数据在存储和传输中失密的有效手段
加密的基本思想： 根据一定的算法将原始数据—明文（Plain text）变换为不可直接识别的格式—密文（Cipher text）
加密方法： ①存储加密；②传输加密
— — — — — — — — — — — — — — — — — —

4.5.1 存储加密

• 透明存储加密
  ①内核级加密保护方式，对用户完全透明
  ②将数据在写到磁盘时对数据进行加密，授权用户读取数据时再对其进行解密
  ③数据库的应用程序不需要做任何修改，只需在创建表语句中说明需加密的字段即可
  内核级加密方法: 性能较好，安全完备性较高

• 非透明存储加密：通过多个加密函数实现

4.5.2 传输加密

• 链路加密
  ①在链路层进行加密
  ②传输信息由报头和报文两部分组成
  ③报文和报头均加密
• 端到端加密
  ①在发送端加密，接收端解密
  ②只加密报文不加密报头
  ③所需密码设备数量相对较少，容易被非法监听者发现并从中获取敏感信息
  
  

小结

数据库加密后对数据的安全性又进一步的提高，但是数据库加密增加了查询处理的复杂性，查询的效率会受到影响，加密数据的密钥管理和数据加密后对应用程序的影响也是需要考虑的问题

4.6其他安全防护

总结

数据库的共享性和操作系统的脆弱性使数据库安全性问题尤为突出，为防止数据库遭到蓄意攻击、破坏，导致敏感数泄露，研究人员和组织设计了一些列包括TCSEC、CC等安全标准，实现数据库系统安全性的技术和方法有多重，数据库管理系统DBMS提供的主要的安全措施包括:

• 用户身份鉴别
• 自主存取控制
• 强制存取控制
• 视图技术
• 审计技术
• 加密存储
• 加密传输