数据库系统原理 (四): 数据库安全性

最新推荐文章于 2022-07-26 10:03:04 发布

连理o

最新推荐文章于 2022-07-26 10:03:04 发布

阅读量924

点赞数 2

分类专栏：数据库

本文链接：https://blog.csdn.net/weixin_42437114/article/details/115447582

版权

数据库专栏收录该内容

11 篇文章 5 订阅

订阅专栏

参考《数据库系统概论》

数据库安全性控制

数据库的一大特点是数据可以共享，数据共享必然带来数据库的安全性问题；数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏

计算机系统中，安全措施是一级一级层层设置；这里只讨论与数据作有关的用户标识和鉴别，存取控制视图和密码存储等安全技术

用户标识和鉴别（Identification & Authentication）

用户标识和鉴别是系统提供的最外层安全保护措施；常用的方法有：
- 用户标识 (User ldentification): 用一个用户名或用户标识号(UID)来标明用户身份。系统内部记录着所有合法用户的标识，系统鉴别此用户是否是合法用户，若是，则可以进入下一步的核实，若不是，则不能使用系统
- 口令 (Password): 为了进一步核实用户，系统常常要求用户输入口令
- 通过用户名和口令鉴别用户的方法简单易行，但用户名与口令容易被人窃取，因此还可以用更复杂的方法
  - 例如每个用户都预先约定好一个函数，鉴别用户身份时系统提供随机数，用户根据自己预先约定的函数进行计算，系统根据用户计算结果是否正确进一步鉴定用户身份

存取控制

存取控制机制组成

定义用户权限，井将用户权限登记到数据字典中
合法权限检查

常用存取控制方法

自主存取控制（Discretionary Access Control ，简称 DAC）
- 用户对于不同的数据库对象有不同的存取权限，不同的用户对同一对象也有不同的权限，而且用户还可将其拥有的存取权限转授给其他用户。因此自主存取控制非常灵活
强制存取控制（Mandatory Access Control，简称 MAC）
- 每个数据库对象被标以一定的密级，每一个用户也被授予某一个级别的许可证。对任意一个对象，只有具有合法许可证的用户才可以存取。强制存取控制因此相对比较严格

自主存取控制方法

用户权限组成: 数据对象、操作类型; 定义用户权限 (授权) 就是定义用户可以在哪些数据库对象上进行哪些类型的操作

DBA：拥有所有对象的所有权限，并可将不同的权限授予不同的用户
用户：拥有自己建立的对象的全部的操作权限，并可以用 GRANT 把某些权限授予其他用户

授权与回收

通过 SQL 的 GRANT 语句和 REVOKE 语句实现

`GRANT`

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

发出 GRANT 的可以是 DBA，也可以是数据库对象创建者（即属主Owner）
按受权限的用户：一个或多个具体用户 或 PUBLIC（全体用户）
如果指定 WITH GHANT OPTION 子句，则获得某种权限的用户还可以把这种权限再授予其他的用户，但不允许循环授权，即被授权者不能把权限再授回给授权者或其祖先；如果没有指定，则获得某种权限的用户只能使用该权限，不能传播该权限

例

把查询Student表权限授给用户U1

GRANT SELECT
ON TABLE Student 
TO U1;

例

把对Student表和Course表的全部权限授予用户U2和U3

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

例

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

GRANT SELECT 
ON TABLE SC 
TO PUBLIC;

例

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

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

补充: 列上的 INSERT 权限指，用户可以插入一个元组。对于插入的元组，授予了用户 INSERT 权限的列，用户可以插入指定的值，其他列或者为空，或者为默认值。在给用户授予列 INSERT 权限的时候， 一定要包含主码的 INSERT 权限，否则用户的插入动作会因为主码为空而被拒绝

例

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

GRANT INSERT
ON TABLE SC
TO U5
WITH GRANT OPTION;

执行上例后，U5不仅拥有了对表SC的INSERT权限，还可以传播此权限：

GRANT INSERT 
ON TABLE SC
TO U6
WITH GRANT OPTION;

`REVOKE`

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

例

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

REVOKE UPDATE(Sno)
ON TABLE Student
FROM U4;

例

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

REVOKE SELECT
ON TABLE SC
FROM PUBLIC;

例

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

REVOKE INSERT
ON TABLE SC
FROM U5 CASCADE;

将用户U5的INSERT权限收回的时候必须级联（CASCADE）收回，不然系统(RESTRICT)将拒绝执行该命令. 系统只收回直接或间接从U5处获得的权限

注：这里缺省值为 RESTRICT, 有的 DBMS 缺省值值为 CASCADE, 会自动执行级联操作而不必明显地写出 CASCADE

创建数据库模式的权限

DBA 在创建用户时实现

CREATE USER <username>
［WITH］［DBA | RESOURCE | CONNECT］

只有系统的超级用户才有权创建一个新的数据库用户
新创建的数据库用户有三种权限：CONNECT, RESOURCE 和 DBA; 如果不指定则默认为 CONNECT

数据库角色

数据库角色：被命名的一组与数据库操作相关的权限的集合
- 可以为一组具有相同权限的用户创建一个角色来简化授权的过程

// 角色的创建
CREATE ROLE <角色名>

// 给角色授权
GRANT <权限> [, <权限>] ... 
ON <对象类型> 对象名
TO <角色> [, <角色>] ...

// 将一个角色授予其他的角色或用户
GRANT <角色1> [,<角色2>]...
TO <角色3> [,<用户1>]...
[WITH ADMIN OPTION] 
// 如果指定了WITH ADMIN OPTION子句，
// 则获得某种权限的角色或用户还可以把这种权限再授予其他角色

// 角色权限的收回
REVOKE <权限> [,<权限>]...
ON <对象类型> <对象名> 
FROM <角色>[,<角色>]...

例

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

CREATE  ROLE  R1;

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

REVOKE SELECT 
ON TABLE Student 
FROM  R1;

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

// 可以一次性通过R1来回收王平的2个权限
REVOKE R1 
FROM 王平;

强制存取控制方法

自主存取控制缺点

用户可以自由地决定将数据的存取权限授予任何人，可能存在数据的“无意泄露”
原因在于：这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记
解决：对系统控制下的所有主客体实施强制存取控制策略

强制存取控制（MAC)

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

在 MAC 中，DBMS 所管理的全部实体被分为主体和客体
- 主体是系统中的活动实体；包括 DBMS 所管理的实际用户、代表用户的各进程
- 客体是系统中的被动实体，是受主体操纵的；包括文件、基本表、索引、视图
对于主体和客体，DBMS 为它们每个实例（值）指派一个敏感度标记 (Label)；MAC 机制就是通过对比主体的 Label 和客体的 Label, 最终确定主体是否能够存取客体
- 敏感度标记被分成若干级别，例如绝密（Top Secret）、机密（Secret）、可信（Confidential）、公开（Public）
- 主体的敏感度标记称为许可证级别（Clearance Level）
- 客体的敏感度标记称为密级（Classification Level）
强制存取控制规则
- (1) 仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体
- (2) 仅当主体的许可证级别等于客体的密级时，该主体才能写相应的客体
  - 修正规则(2) (某些系统): 主体的许可证级别 $\leq$ 客体的密级 $\rightarrow$ 主体能写客体
  - 共同点: 禁止了拥有高许可证级别的主体更新低密级的数据对象，从而防止了敏感数据的泄漏

MAC 与 DAC

较高安全性级别提伊的安全保护要包含较低级别的所有保护，因此在实现MAC时要首先实现DAC, 即 DAC 与 MAC 共同构成 DBMS 的安全机制
系统首先进行DAC检查，对通过DAC检查的允许存取的数据库对象再由系统自动进行MAC检查，只有通过MAC检查的数据库对象方可存取

视图机制

视图机制可以把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护
- 主要功能是提供数据独立性，无法完全满足要求
- 间接实现了支持存取谓词的用户权限定义

例

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

// 建立计算机系学生的视图
CREATE VIEW CS_Student
AS
SELECT *
FROM Student
WHERE Sdept='CS';

// 在视图上进一步定义存取权限
GRANT SELECT
ON CS_Student
TO 王平;

GRANT ALL PRIVILIGES
ON CS_Student
TO 张明;

审计 (Audit)

审计日志 (Audit Log): 审计功能将用户对数据库的所有操作记录在上面；DBA 利用审计日志找出非法存取数据的人、时间和内容

审计分为
- 用户级审计：针对用户自己创建的数据库表或视图进行审计，记录所有用户对这些表或视图的一切成功和（或）不成功的访问要求以及各种类型的 SQL 操作
- 系统级审计: 只能由 DBA 设置。用以监测成功或失败的登录要求、 GRANT 和 REVOKE 操作以及其他数据库级权限下的操作

AUDIT 语句：设置审计功能
NOAUDIT 语句：取消审计功能

例

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

AUDIT ALTER, UPDATE
ON SC;

例

取消对SC表的一切审计

NOAUDIT ALTER, UPDATE
ON SC;

数据加密

数据加密: 根据一定的算法将原始数据 (明文 Plain text) 变换为不可直接识别的格式 (密文 Cipher text), 防止数据库中数据在存储和传输中失密

统计数据库安全性

统计数据库

允许用户查询聚集类型的信息（如合计、平均值等）
不允许查询单个记录信息；例如，查询“程序员的平均工资是多少？” 是合法的，但是查询＂程序员张勇的工资是多少？”就不允许

统计数据库中特殊的安全性问题

可能存在隐蔽的信息通道，使得可以从合法的查询中推导出不合法的信息
例如，查询：
- ① 本公司共有多少女高级程序员？
- ② 本公司女高级程序员的工资总额是多少？
- 如果第一个查询的结果是1，则第二个查询结果显然就是这个程序员的工资数。这样统计数据库的安全机制就失效了
为此，规定任何查询至少要涉及 $N$ （足够大）个以上的记录。但是即使这样还是存在另外的泄密途径，看下面的例子：
- 考察用户 $A$ 执行如下查询：
  - ① 用户 $A$ 和其他 $N$ 个程序员的工资总额是多少？
  - ② 用户 $B$ 和其他 $N$ 个程序员的工资总额是多少？
  - 假设第一个查询结果是 $X$ ，第二个查询结果是 $Y$ ， $A$ 知道自己的工资数是 $Z$ ，则 $B$ 的工资数 $= Y - (X - Z)$ . 这个例子的关键之处在于两个查询之间有很多重复的数据项（即其他 $N$ 个程序员的工资）
因此可以再规定任意两个查询的相交数据项不能超过 $M$ 个. 可以证明，在上述两条规定下，如果想获知用户 $B$ 的工资额，用户 $A$ 至少需要进行 $1 + (N - 2) / M$ 次查询。因此可以继续规定任一用户的查询次数不能超过 $1 + (N - 2) / M$ ，但是如果两个用户合作查询就可以使这一规定仍然失效
无论采用什么安全性机制，都仍然会存在绕过这些机制的途径。好的安全性措施应该使得那些试图破坏安全的人所花费的代价远远超过他们所得到的利益，这也是整个数据库安全机制设计的目标