4数据库安全性

第四章数据库安全性

4.1 数据库安全性概述

1. 问题的提出

核心矛盾 ：数据库的一大特点是数据共享 ，而数据共享必然带来数据库的安全性问题。
基本原则 ：数据库系统中的数据共享不能是无条件的共享。
敏感数据示例：军事秘密、国家机密、新产品实验数据、市场营销策略、客户档案、医疗档案、银行储蓄数据等。

2. 数据库安全性的定义

定义：保护数据库以防止不合法使用 所造成的数据泄露、更改或破坏。
重要性：系统安全保护措施是否有效是数据库系统的主要性能指标之一。
严峻挑战：(如T-Mobile、Apple等)近年来的大规模数据泄露事件表明，数据库安全性面临严重挑战。

3. 数据库的不安全因素

非法用户对数据库的恶意存取和破坏
- 手段：
  - 在用户存取数据库时猎取用户名和口令，假冒合法用户。
  - 利用计算机硬件、操作系统、网络系统等的安全漏洞，非法捕获或篡改数据。
- DBMS对策：用户身份鉴别、数据加密存储、数据加密传输。
合法用户非法访问数据库
- 手段：合法用户超越其权限访问和操纵数据库中的数据。
- DBMS对策 ：自主存取控制、视图、审计日志。
合法用户合法访问数据库，但非法使用和传播
- 手段：合法获取数据后，进行非法使用或恶意传播，导致数据泄露。
- DBMS对策 ：强制存取控制 、审计日志分析。
合法用户合法访问数据库，但推演出机密数据
- 手段：
  - 利用数据之间的关联关系，推演出敏感数据。
  - 多人协同，将各自合法获取的数据综合分析，获取敏感数据。
- 核心难题 ：数据的安全性 与可用性之间的平衡。

4.安全标准简介

发展历程：
1. 1985年：美国国防部 TCSEC (可信计算机系统评估准则)
2. 1991年：欧洲 ITSEC (信息技术安全评估准则)
3. 1991年：美国NCSC颁布 TDI (可信数据库系统的解释)，又称"紫皮书"，将TCSEC扩展到DBMS。
4. 1999年：CC (通用准则) V2.1 成为国际标准 (ISO15408)。
5. 2001年：CC被中国采用为国家标准。
TCSEC/TDI 安全级别 (从低到高)
- D：最小保护 (Minimal Protection)
- C1：自主安全保护 (Discretionary Security Protection)
- C2：受控的存取保护 (Controlled Access Protection)
- B1：标记安全保护 (Labeled Security Protection)
- B2：结构化保护 (Structural Protection)
- B3：安全域 (Security Domains)
- A1：验证设计 (Verified Design)
C级提供的是自主存取控制 (DAC) ，B级及以上开始提供强制存取控制 (MAC)。C2级要求具备审计功能。
CC 评估保证级 (EAL) (与TCSEC近似对应)
- EAL1：功能测试
- EAL2：结构测试 (≈ C1)
- EAL3：系统地测试和检查 (≈ C2)
- EAL4：系统地设计、测试和复查 (≈ B1)
- EAL5：半形式化设计和测试 (≈ B2)
- EAL6：半形式化验证的设计和测试 (≈ B3)
- EAL7：形式化验证的设计和测试 (≈ A1)

4.2 数据库安全性控制

1. 计算机系统的安全模型 (层层设防)

系统级：用户身份鉴别
DBMS级：存取控制
OS级：操作系统保护
数据级：数据密码存储

2. DBMS安全性控制模型

事前控制 ：身份鉴别 (防止不可信用户使用系统)。
事中控制 ：在SQL处理层进行多层存取控制：
- 自主存取控制 (DAC)
- 强制存取控制 (MAC)
- 推理控制
事后控制 ：审计 (对用户访问行为和关键操作进行审计)。
数据保护 ：
- 存储保护：对存储数据加密。
- 传输保护：对传输数据加密。

3. 安全性控制常用方法

用户身份鉴别
存取控制 (DAC 和 MAC)
视图机制
审计
数据加密

4. 用户身份鉴别

定义：系统提供的最外层安全保护措施。
用户标识：用户名 + 用户标识号 (唯一)。
鉴别方法 ：
1. 静态口令：用户自己设定，静态不变 (最常用，但最不安全)。
2. 动态口令：每次鉴别使用动态产生的新口令 (一次一密)。
3. 生物特征：指纹、虹膜、掌纹等。
4. 智能卡：内置芯片，具有硬件加密功能。
5. 入侵检测：定义规则，发现入侵行为并实时处理。

5. 存取控制

机制组成 ：
1. 定义用户权限 (授权) ：
  - 权限：用户对某一数据对象的操作权力。
  - DBMS提供SQL语言定义权限，存入数据字典 (称为安全规则或授权规则)。
2. 合法权限检查 ：
  - 用户发出操作请求。
  - DBMS查找数据字典，进行合法权限检查。
存取控制子系统 = 用户权限定义 + 合法权限检查。

6. 自主存取控制 (DAC)

定义：Discretionary Access Control。
- 用户对不同数据对象有不同权限。
- 不同用户对相同数据对象有不同权限。
- 用户可将其拥有的存取权限转授给其他用户。
实现：通过 SQL 的 GRANT 和 REVOKE 语句实现。
关系数据库中的存取权限 (对象与操作)
- 数据库模式中操作的权限是数据库管理员在创建用户时实现的；
- 数据中操作的权限可以通过GRANT/REMOVE控制。

7. 授权：授予 (GRANT) 与回收 (REVOKE)

1. 授予权限：GRANT

一般格式：

sql 复制代码

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

语义：将对指定操作对象的指定操作权限授予指定的用户。
发出者：
- 数据库管理员
- 数据库对象创建者 (属主, Owner)
- 已拥有该权限并被授予 WITH GRANT OPTION 的用户。
接受者：
- 一个或多个具体用户。
- PUBLIC (即全体用户)。
WITH GRANT OPTION：
- 允许接受权限的用户再将此权限授予其他用户。
- 不允许循环授权 (例如 U1 授给 U2，U2 授给 U3，U3 不能再授给 U1)。
GRANT 示例：
- [例 4.1] 授查询Student表权限给U1：将一种权限授予一个用户
  sql 复制代码
```
GRANT SELECT ON TABLE Student TO U1;
```
- [例 4.2] 授Student和Course表的全部权限给U2和U3：一次向多个用户传播多种同类对象的权限
  sql 复制代码
```
GRANT ALL PRIVILEGES ON TABLE Student, Course TO U2, U3;
```
- [例 4.3] 授SC表的查询权限给所有用户：
  sql 复制代码
```
GRANT SELECT ON TABLE SC TO PUBLIC;
```
- [例 4.4] 授查询Student表和修改学生姓名的权限给U4 (列级权限)：一次完成了对基本表和属性列这些不同对象的授权
  sql 复制代码
```
GRANT UPDATE(Sname), SELECT ON TABLE Student TO U4;
```
- [例 4.5 & 4.6] 权限传播：
  sql 复制代码
```
/* U5 获得 INSERT 权限，并可以传播此权限 */
GRANT INSERT ON TABLE SC TO U5 WITH GRANT OPTION;

/* U5 将此权限传播给 U6，U6 也可以继续传播 */
GRANT INSERT ON TABLE SC TO U6 WITH GRANT OPTION;

/* U6 将此权限传播给 U7，但 U7 不能再传播 */
GRANT INSERT ON TABLE SC TO U7;
```

2. 回收权限：REVOKE

一般格式：

sql 复制代码

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

CASCADE (级联回收)：
- 不仅回收指定用户的权限，还级联回收 该用户利用 WITH GRANT OPTION 授予出去的所有权限。
RESTRICT (受限回收)：
- 如果该用户已将此权限授予其他用户，则系统拒绝执行 REVOKE 语句 (通常是默认值)。
REVOKE 示例：
- [例 4.8] 收回U4修改学生姓名的权限：
  sql 复制代码
```
REVOKE UPDATE(Sname) ON TABLE Student FROM U4;
```
- [例 4.9] 收回所有用户对SC表的查询权限：
  sql 复制代码
```
REVOKE SELECT ON TABLE SC FROM PUBLIC;
```
- [例 4.10] 级联收回U5对SC表的INSERT权限 (重要)：
  sql 复制代码
```
/* 这条语句会同时收回 U5, U6, U7 的 INSERT 权限 (假设 U6, U7 的权限来自 U5) */
REVOKE INSERT ON TABLE SC FROM U5 CASCADE;
```
如果U6还从其他用户(如DBA)处获得了SC表的INSERT权限，则他们仍具有此权限。CASCADE 只回收从U5这条路径上获得的权限。

3. 创建数据库/模式的权限

CREATE USER 语句不是SQL标准，各系统实现相差甚远。

Kingbase ES 示例：

DBA创建用户时指定权限。
WITH SUPERUSER：超级用户。
WITH CREATEDB：允许创建数据库。

sql 复制代码

/* 由超级用户 system 登录后,创建超级用户system2 */
CREATE USER system2 WITH SUPERUSERPASSWORD'123456';

/*以超级用户system登录，创建用户U1，U2*/

CREATE USER U1 WITH CREATEDB PASSWORD'123456';  /*U1具有创建数据库的权限*/
/* U1 登录后，可以创建自己的数据库 */
CREATE DATABASE U1DB;   /* U1 成为 U1DB 的属主 (Owner) */

CREATE USER U2PASSWORD '123456';  /*U2是普通用户*/

Oracle 示例 (权限等级)：
- DBA ：可执行 CREATE USER, CREATE SCHEMA, CREATE TABLE, 登录等所有操作。
- RESOURCE ：可执行 CREATE TABLE, 登录。
- CONNECT：仅可登录 (需要额外授权才能执行其他操作)。

8. 数据库角色

引入原因 ：将同一组权限授予大量用户时，逐个GRANT非常繁琐，且权限变更时难以维护。
什么是角色？
- 角色：被命名的一组与数据库操作相关的权限的集合。
优点：
- 简化授权过程：权限 -> 角色，角色 -> 用户。
- 权限变更方便：只需修改角色的权限，所有被授予该角色的用户权限自动变更。

角色的使用：

创建角色：
sql 复制代码
```
CREATE ROLE <角色名>;
```

给角色授权：

sql 复制代码

GRANT <权限>... ON <对象>... TO <角色>;

将角色授予用户 (或其他角色)：

sql 复制代码

GRANT <角色1> [, <角色2>]... 
TO <角色3> [, <用户1>]...
[WITH ADMIN OPTION]; 
/* WITH ADMIN OPTION: 允许接收者将此角色转授给他人 */

从角色收回权限 (修改角色的能力)：
sql 复制代码
```
REVOKE <权限>... ON <对象>... FROM <角色>;
```

角色示例：

[例 4.14] 使用角色管理学生信息权限：

sql 复制代码

/* (1) 创建角色 R1 */
CREATE ROLE R1;

/* (2) 给角色 R1 授权 */
GRANT SELECT, UPDATE, INSERT ON TABLE Student TO R1;

/* (3) 将角色 R1 授予三个用户 */
GRANT R1 TO 王平, 张明, 赵玲;

/* (4) 一次性收回王平的全部权限 */
REVOKE R1 FROM 王平;

[例 4.15] 增加角色的权限：

sql 复制代码

/* 王平, 张明, 赵玲 (未被收回的) 现在也自动拥有了 Student 表的 DELETE 权限 */
GRANT DELETE ON TABLE Student TO R1;

[例 4.16] 减少角色的权限：

sql 复制代码

/* 所有被授予 R1 的用户都失去了 Student 表的 SELECT 权限 */
REVOKE SELECT ON TABLE Student FROM R1;

9. 强制存取控制 (MAC)

DAC 的缺陷 ：存在数据的无意泄露。
- 例子：财务人员A有权访问工资表 EMP-Salary。A创建了一个副本 Salary-copy，并将此副本的查询权限授予 PUBLIC。这就导致了机密数据的泄露。
- 原因：DAC 仅仅控制谁有什么权限 ，而数据本身并无安全性标记。
MAC定义：
- 保证更高程度的安全性，用户不能直接感知或控制。
- 适用于对数据有严格而固定密级分类的部门 (如军事、政府)。
- DBMS所管理的全部实体被分为主体和客体。
主体：系统中的活动实体。
- 实际用户、代表用户的各进程。
客体：系统中的被动实体。
- 文件、基本表、索引、视图等。
敏感度标记：
- 系统为每个主体和客体指派一个敏感度标记。
- 标记分级：绝密 (TS) >= 机密 (S) >= 可信 © >= 公开 §
- 主体的标记 ：许可证级别
- 客体的标记 ：密级
MAC 的强制存取控制规则 (Bell-LaPadula 模型)
1. 读规则：
  - 仅当主体的[许可证级别] >= 客体的[密级]时，主体才能读取该客体。
  - 例子："机密"主体可以读"公开"、"可信"、"机密"客体，但不能读"绝密"客体。
2. 写规则：
  - 仅当主体的[许可证级别] <= 客体的[密级]时，主体才能写该客体。
  - 例子："机密"主体可以写"机密"、"绝密"客体，但不能写"公开"、"可信"客体。这是为了防止高密级数据被"泄露"到低密级文件中。
MAC 如何解决 DAC 缺陷：
- 强制存取控制是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据。
- 在DAC的泄露例子中：
DAC + MAC：
- 实现MAC必须首先实现DAC (高安全级别要包含低级别的保护)。
- 安全检查流程 ：

4.3 视图机制

定义：把要保密的数据对无权存取的用户隐藏起来，从而对数据提供一定程度的安全保护。
视图与授权：
- GRANT SELECT ON TABLE Student ... (授权访问整个表)
- GRANT SELECT(Sno, Sname) ON TABLE Student ... (授权访问某些列)
- 如何授权访问某些行？
  - 答案：使用视图机制间接实现。

视图机制示例：

[例 4.17] 授权王平老师查询计算机系学生，授权系主任张明对计算机系学生进行所有操作。

(1) 先建立计算机系学生的视图 CS_Student：

sql 复制代码

CREATE VIEW CS_Student AS
SELECT *
FROM Student
WHERE Smajor = '计算机科学与技术';

(2) 在视图上进一步定义存取权限：

sql 复制代码

/* 王平老师只能查询 CS_Student 视图，即只能查询计算机系的学生行 */
GRANT SELECT ON CS_Student TO 王平;

/* 张明主任可以对该视图进行所有操作 */
GRANT ALL PRIVILEGES ON CS_Student TO 张明;

4.4 审计

定义：
- DAC, MAC, View 是预防性措施。
- 审计是监控性措施 (事后检查)。
- 启用一个专用的审计日志，将用户对数据库的所有操作记录在上面。
- 审计员 利用审计日志来监控行为、发现非法存取和潜在威胁。
安全标准：C2以上安全级别的DBMS必须具有审计功能。
可被审计的事件：
1. 服务器事件：数据库启动、停止、配置重载等。
2. 系统权限 ：对模式对象进行操作的审计 (如 CREATE TABLE 操作)。
3. 语句事件：对SQL语句 (DDL, DML, DQL, DCL) 的审计。
4. 模式对象事件 ：对特定表上的 SELECT 或 DML 操作的审计。
审计日志管理：
- 提供多种查阅方式、分析和报表功能。
- 日志必须先转储后删除。
- 保护转储文件的完整性和保密性。
- 只允许审计员查阅和转储，任何用户(包括DBA)不得新增和修改审计记录。
审计功能设置 (AUDIT / NOAUDIT)
- AUDIT 语句：设置审计功能。
- NOAUDIT 语句：取消审计功能。
- 可选性：审计很耗费时间和空间，DBA可以灵活开关。
审计级别：
- 用户级审计：用户对自己创建的表和视图进行审计。
- 系统级审计：(只能由DBA设置) 监测登录、授权/收回操作等。
审计示例：
- [例 4.18] 对修改SC表结构 (ALTER) 或修改SC表数据 (UPDATE) 的操作进行审计：
  sql 复制代码
```
/* (1) 打开审计开关 (具体命令因系统而异) */
SET AUDIT_TRAIL TO ON; 

/* (2) 设置审计规则 */
/* BY ACCESS: 每次操作都记录 */
/* BY SESSION: 同一会话中的同类操作只记录一次 */
AUDIT ALTER, UPDATE ON SC BY ACCESS; 
```
- [例 4.19] 取消对SC表的一切审计：
  sql 复制代码
```
NOAUDIT ALTER, UPDATE ON SC;
```
- [例 4.19-1] 取消对SC表UPDATE操作的审计：
  sql 复制代码
```
NOAUDIT UPDATE ON SC;
```
教授提示 ：审计日志通常存储在数据字典中 (如 SYS_AUDITTRAIL 表)，必须打开审计开关才能查看到审计信息。

4.5 数据加密

定义：防止数据在存储和传输中失密的有效手段。
思想：将明文通过加密算法变为密文。

1. 存储加密

透明存储加密 ：
- 内核级 加密，对用户完全透明。
- 数据在写入磁盘时 自动加密，授权用户读取数据时自动解密。
- 应用程序无需修改 ，只需在 CREATE TABLE 时指定加密字段。
- 性能较好，安全完备性高。
非透明存储加密 ：
- 通过多个加密函数实现 (例如在应用程序层面或SQL函数中调用)。

2. 传输加密

信息组成：报头 (路由信息) + 报文 (数据信息)。
链路加密 ：
- 加密报文和报头。
端到端加密 ：
- 在发送端加密，接收端解密。
- 只加密报文，不加密报头。
- 优点：所需密码设备少；缺点：报头暴露，易被非法监听者进行流量分析。
基于SSL/TLS的可信传输方案 (端到端加密的实现)：
1. 创建可信连接 (握手)。
2. 确认双方端点可靠性 (交换数字证书)。
3. 协商加密算法和密钥。
4. 可信传输数据 (加密传输)。
5. 关闭可信连接。

4.6 其他安全性保护

1. 推理控制

目的：处理 MAC 未解决 的问题，避免用户利用能够访问的低密级数据，推知更高密级的数据。
方法：基于函数依赖的推理控制、基于敏感关联的推理控制、统计推断。
例子 (统计推断) ：
- 职工表(职工号, 姓名, 职务, 工资)。
- 假设"姓名"和"职务"是公开的，"工资"是机密的。
- 用户A (P级) 无法直接查询工资。
- 但如果用户A可以执行统计查询，如 AVG(工资)，并且知道某个部门只有一个人，他就可以推断出这个人的工资。

2. 隐蔽信道

目的：处理 MAC 未解决的问题。
定义：高安全等级用户 (如"绝密") 按事先约定的方式，利用系统的某些机制 (如错误码、资源锁定)，主动向低安全等级用户 (如"公开") 传输信息。
例子 (利用UNIQUE约束)：
1. 表 T 在 X 列上有 UNIQUE 约束。
2. 用户A (绝密) 和 用户B (公开) 约定好通信。
3. 传输 "1"：用户A 向 T INSERT 105 (成功)。用户B 稍后也 INSERT 105，收到"主键冲突"错误，得知信息为 "1"。
4. 传输 "0"：用户A DELETE 105。用户B 稍后 INSERT 105 (成功)，得知信息为 "0"。
- 这里，数据库的"错误提示系统"被当作了隐蔽信道。

3. 数据隐私保护

定义：控制不愿他人知道或他人不便知道的个人数据的能力。
范围：贯穿数据收集、存储、处理和发布的各个阶段。
核心思想 ：实现数据可用不可见。

4数据库安全性

第四章 数据库安全性

4.1 数据库安全性概述

1. 问题的提出

2. 数据库安全性的定义

3. 数据库的不安全因素

4.安全标准简介

4.2 数据库安全性控制

1. 计算机系统的安全模型 (层层设防)

2. DBMS安全性控制模型

3. 安全性控制常用方法

4. 用户身份鉴别

5. 存取控制

6. 自主存取控制 (DAC)

7. 授权：授予 (GRANT) 与回收 (REVOKE)

1. 授予权限：GRANT

2. 回收权限：REVOKE

3. 创建数据库/模式的权限

8. 数据库角色

9. 强制存取控制 (MAC)

4.3 视图机制

4.4 审计

4.5 数据加密

1. 存储加密

2. 传输加密

4.6 其他安全性保护

1. 推理控制

2. 隐蔽信道

3. 数据隐私保护

第四章数据库安全性