Database 2026-05-19

第4章数据库安全性

4.1 本章总览

数据库的一大特点是数据共享。

但数据一旦共享，就一定会带来一个问题：

不是所有人都应该无条件地访问所有数据。

例如：

军事秘密、国家机密；
新产品实验数据；
市场需求分析与营销策略；
销售计划、客户档案；
医疗档案、银行储蓄数据。

因此，数据库系统必须回答一个非常现实的问题：

谁可以访问数据；
可以访问哪些数据；
可以做什么操作；
访问后是否能追踪和审查；
数据在存储和传输过程中是否会泄露。

4.1.1 什么是数据库安全性

数据库的安全性，是指：

保护数据库，防止不合法使用所造成的数据泄露、篡改或破坏。

这里要抓住三个关键词：

数据泄露：本不该知道的人知道了；
数据篡改：本不该修改的人改了数据；
数据破坏：数据被删除、毁坏或不可用。

通俗地说，数据库安全性关注的是：

如何让“该看的人能看，不该看的人看不到；该改的人能改，不该改的人改不了；出了问题还能查到是谁干的”。

4.1.2 本章主要内容

本章围绕数据库安全性的五个核心方面展开：

数据库安全性概述：安全问题从哪里来，数据库面临哪些不安全因素；
数据库安全性控制：身份鉴别、存取控制、授权与回收、角色、MAC；
视图机制：通过隐藏部分数据来实现一定程度的安全保护；
审计：记录用户操作，为事后追踪提供依据；
数据加密：保护数据在存储和传输中的机密性。

如果把整章压缩成一句话，可以概括为：

数据库安全性的核心，就是“限制能做什么、隐藏不该看的、记录做过什么、保护传输和存储中的数据”。

4.2 数据库安全性概述

4.2.1 数据库安全问题产生的根源

数据库和普通文件系统相比，最大的不同之一就是：

数据集中管理；
多用户共享；
应用广泛；
经常运行在网络环境中。

这带来了效率，也带来了风险。

课件中强调：数据库系统中的数据共享不能是无条件的共享。

也就是说，数据库不是“谁连上系统谁就能看全部数据”，而必须建立一套严格的安全机制。

4.2.2 计算机系统安全问题的范围

数据库安全不是孤立存在的，它和整个计算机系统安全密切相关。

课件把计算机系统安全问题分为三大类：

技术安全类；
管理安全类；
政策法律类。

本章重点讨论的是：

数据库技术安全类问题，即从技术上如何保证数据库系统的安全。

所以你要建立一个正确认识：

数据库安全不仅仅是 SQL 权限问题；
它还涉及身份鉴别、操作系统保护、审计、加密、网络传输保护等多个层次。

4.2.3 数据库面临的三类主要不安全因素

课件列出了数据库的三个主要不安全因素。

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

这是最直接、最常见的一类安全威胁。

表现为：

未经授权访问数据库；
越权查询敏感数据；
非法插入、修改、删除数据；
通过恶意操作破坏数据库正常运行。

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

即使攻击者没有“破坏”数据库，只要敏感信息被看到了，安全就已经失效。

例如：

学生成绩被无关人员查看；
客户隐私信息泄露；
医疗记录泄露；
财务数据泄露。

这说明安全问题不只是“系统崩没崩”，还包括：

机密信息有没有被不该看到的人看到。

3. 安全环境的脆弱性

数据库并不是孤立工作的，它依赖于：

操作系统；
网络环境；
主机硬件；
应用程序；
管理制度。

只要其中某一环节脆弱，数据库安全就会被拖累。

因此，数据库安全控制必须是分层的、整体的，而不是只靠一条 GRANT 语句解决全部问题。

4.2.4 安全标准简介

课件提到了两个安全标准：

TCSEC 标准；
CC 标准。

其中重点展开的是 TCSEC/TDI 安全级别划分。

1. TCSEC/TDI 的级别结构

TCSEC/TDI 把系统安全级别划分为：

4 组（division）：D、C、B、A；
7 个等级：D、C1、C2、B1、B2、B3、A1。

安全级别越高，系统的可靠或可信程度越高。

2. 各级别的核心含义

安全级别	含义
D	最小保护（Minimal Protection）
C1	自主安全保护（Discretionary Security Protection）
C2	受控的存取保护（Controlled Access Protection）
B1	标记安全保护（Labeled Security Protection）
B2	结构化保护（Structural Protection）
B3	安全域（Security Domains）
A1	验证设计（Verified Design）

3. 需要重点掌握的几个级别

D 级

这是最低级别。

凡是不符合更高标准的系统，都归入 D 级。

C1 级

属于非常初级的自主安全保护。

它能够实现：

用户和数据的分离；
自主存取控制（DAC）；
对用户权限传播的保护或限制。

C2 级

这是安全产品的最低档。

它在 C1 的基础上进一步增强，能够提供：

更细化的受控存取保护；
以个人身份注册负责；
审计；
资源隔离。

B1 级

B1 级开始引入一个非常重要的思想：

给数据加标记，并对标记后的主体和客体实施强制存取控制（MAC）。

同时配合审计等安全机制。

课件明确指出：

B1 级才可以被认为是真正意义上的安全产品；
这类产品常被称为“安全的”或“可信的”产品。

4.2.5 本节核心理解

这一节最重要的不是背定义，而是形成下面这个认识：

数据库因为共享而产生安全问题；
安全问题不只来自数据库内部，也来自整个系统环境；
安全控制是分层、分级进行的；
从 C1 开始有 DAC，从 B1 开始有 MAC；
安全级别越高，控制越严格、机制越完整。

4.3 数据库安全性控制

4.3.1 安全控制是分层设置的

课件给出了一个“计算机系统安全模型”。

整个安全链条可以理解为：

用户 → 数据库管理系统 → 操作系统 → 数据库存储

对应的安全措施分别包括：

用户标识与身份鉴别；
数据库管理系统的安全保护；
操作系统自身的保护；
对敏感数据的传输加密与存储加密。

也就是说，数据库安全不是只发生在“查表”这一瞬间，而是从用户登录开始，一直到数据落盘结束，层层设防。

4.3.2 数据库管理系统的安全性控制模型

课件进一步把数据库管理系统的安全性控制总结为五类：

1. 事前控制

通过：

身份鉴别；
入侵检测。

目的：在用户真正接触数据库之前，先识别其身份并判断其行为是否异常。

2. 事中控制

在 SQL 处理层提供多层访问控制。

这是数据库安全控制的核心阶段，主要涉及：

自主存取控制；
强制存取控制；
合法权限检查。

3. 事后控制

配置审计规则，对：

用户访问行为；
系统关键操作。

进行记录和审查。

4. 存储保护

在数据存储层，对：

敏感数据；
重要的存储过程定义；

进行加密存储。

5. 传输保护

通过传输加密，避免数据在网络传输过程中泄露。

4.3.3 用户身份鉴别

用户身份鉴别是系统提供的最外层安全保护措施。

课件指出：

用户标识由用户名和用户标识号组成；
其中用户标识号在系统整个生命周期内是唯一的。

常见的身份鉴别方法有：

静态口令鉴别；
动态口令鉴别；
生物特征鉴别；
智能卡鉴别；
入侵检测。

这里要注意：

静态口令是最传统的方法，但安全性相对弱；
动态口令、生物识别、智能卡等方法更安全；
入侵检测不完全等同于登录认证，但它属于事前防御体系的重要组成部分。

4.3.4 存取控制的基本组成

数据库中的存取控制机制由两部分组成：

1. 定义用户权限

用户对某一数据对象的操作权力，称为权限。

数据库管理系统需要提供相应语言来定义权限，并把这些规则存入数据字典。

这些规则也称为：

安全规则；
授权规则。

2. 合法权限检查

当用户发出存取数据库的操作请求时，DBMS 会：

查找数据字典；
检查该用户是否拥有相应权限；
只有检查通过后，操作才能执行。

这两部分合起来，构成了：

数据库管理系统的存取控制子系统。

也就是说，安全控制不是“写一次权限就完了”，而是：

平时先定义规则；
真正执行时再逐次检查。

4.4 自主存取控制（DAC）与强制存取控制（MAC）

4.4.1 两类常用存取控制方法

课件给出了两种常用的存取控制方法：

自主存取控制（DAC）；
强制存取控制（MAC）。

这是本章最重要的知识点之一。

4.4.2 自主存取控制（DAC）

DAC 的核心思想是：

由系统为不同用户分配不同对象的不同操作权限，并在访问时进行检查。

其特点是：

不同用户对同一对象可以有不同权限；
同一用户对不同对象也可以有不同权限；
用户还可以把自己拥有的某些权限再授予其他用户。

这也是“自主”二字的真正含义：

用户在一定范围内可以“自主”地把权限授给别人。

DAC 对应的安全级别是 C2 级。

DAC 的优点

灵活；
适合一般商业数据库系统；
容易与 SQL 语言结合。

DAC 的缺点

课件强调：DAC 可能导致数据的“无意泄露”。

原因在于：

DAC 主要控制的是“谁对什么对象有什么权限”；
但数据本身没有强制性的安全标记；
某个用户如果拿到权限后再传播，就可能造成扩散。

所以 DAC 的问题不是“不控制”，而是：

控制是灵活的，但也正因为灵活，所以更容易被扩散和间接泄露。

4.4.3 强制存取控制（MAC）

MAC 的核心思想是：

对系统中的主体和客体都赋予安全标记，系统根据标记自动决定是否允许访问。

MAC 对应 B1 级。

和 DAC 最大的区别在于：

DAC 是“按权限表控制”；
MAC 是“按安全级别控制”；
DAC 可以传播权限；
MAC 不能由普通用户随意决定。

因此 MAC 的安全性更高，但灵活性更弱。

4.4.4 主体、客体与敏感度标记

在强制存取控制中，数据库管理系统所管理的全部实体分为：

1. 主体（Subject）

主体是系统中的活动实体，例如：

实际用户；
代表用户的进程。

2. 客体（Object）

客体是系统中的被动实体，例如：

文件；
基本表；
索引；
视图等。

3. 敏感度标记（Label）

DBMS 会为主体和客体的每个实例赋予一个敏感度标记。

常见等级为：

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

等级关系为：

TS ≥ S ≥ C ≥ P

其中：

主体的敏感度标记称为许可证级别；
客体的敏感度标记称为密级。

4.4.5 MAC 的两条基本规则

课件给出了强制存取控制的两条规则。

1. 读规则

仅当主体的许可证级别大于或等于客体的密级时，主体才能读取该客体。

也就是：

高级别可以读低级别，低级别不能读高级别。

2. 写规则

仅当主体的许可证级别小于或等于客体的密级时，主体才能写该客体。

也就是：

高级别不能把数据写到低级别对象中。

这个规则非常关键，因为它是为了防止：

高密级数据流入低密级对象；
从而造成敏感信息泄露。

课件也明确指出：

无论是读规则还是写规则，本质上都在防止敏感数据泄露。

4.4.6 DAC 与 MAC 的关系

课件强调了一个非常重要的结论：

实现 MAC 时要首先实现 DAC。

原因是：

高安全级别提供的安全保护，必须包含低级别的全部保护；
因此 MAC 不是替代 DAC，而是在 DAC 的基础上再增加一层更严格的控制。

实际检查流程是：

先进行 DAC 检查；
通过 DAC 的对象，再由系统自动进行 MAC 检查；
只有两者都通过，数据对象才允许被访问。

所以可以把两者的关系概括为：

DAC 负责权限层面的“你有没有资格”，MAC 负责密级层面的“你够不够级别”。

4.4.7 DAC 与 MAC 的比较

比较项	DAC	MAC
控制依据	用户权限	安全级别/密级标记
灵活性	高	低
安全性	相对较低	更高
权限传播	可以传播	不能由用户随意传播
典型适用场景	一般数据库应用	军事、政府等高保密场景

4.5 自主存取控制方法的 SQL 实现

4.5.1 权限由什么组成

在关系数据库中，用户权限由两部分组成：

数据对象；
操作类型。

定义用户在某些数据对象上可以执行哪些操作，这个过程就叫：

授权。

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

课件给出了一个非常重要的权限分类表。

对象类型	对象	可执行的操作类型
数据库和模式	数据库和模式	`CREATE`
数据库和模式	基本表	`CREATE TABLE`，`ALTER TABLE`
数据库和模式	视图	`CREATE VIEW`
数据库和模式	索引	`CREATE INDEX`
数据	基本表和视图	`SELECT`，`INSERT`，`UPDATE`，`DELETE`，`REFERENCES`，`ALL PRIVILEGES`
数据	属性列	`SELECT`，`INSERT`，`UPDATE`，`REFERENCES`，`ALL PRIVILEGES`

从这个表要看出两点：

权限不是只针对“表”，还可以针对数据库、模式、视图、索引、列；
列级授权比表级授权更细。

4.6 授权：GRANT

4.6.1 GRANT 语句的作用

GRANT 用于把某些对象上的某些权限授予某些用户。

一般格式为：

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

语义是：

把对指定对象的指定操作权限授予指定用户。

4.6.2 谁可以发出 GRANT

可以发出 GRANT 的包括：

数据库管理员（DBA）；
数据库对象创建者（Owner）；
已经拥有该权限的用户。

被授权对象可以是：

一个或多个具体用户；
PUBLIC，即全体用户。

4.6.3 WITH GRANT OPTION 的含义

WITH GRANT OPTION 表示：

被授予权限的用户还可以把该权限再授予其他用户。

若不写该子句，则被授权者只能自己使用该权限，不能继续传播。

课件还特别强调：

不允许循环授权。

也就是说，权限传播不能形成环。

4.6.4 典型授权示例

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

GRANT SELECT ON TABLE Student TO U1;

例 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;

这个例子特别重要，因为它说明：

列级授权时，必须明确指出属性列名。

例 4.5：把对表 `SC` 的 `INSERT` 权限授给 `U5`，并允许其继续授权

GRANT INSERT ON TABLE SC TO U5 WITH GRANT OPTION;

之后，U5 可以把该权限授给 U6：

GRANT INSERT ON TABLE SC TO U6 WITH GRANT OPTION;

再之后，U6 可以把该权限授给 U7：

GRANT INSERT ON TABLE SC TO U7;

这里要注意：

U5 可以传播；
U6 也可以传播；
U7 因为没有 WITH GRANT OPTION，所以不能再传播。

4.6.5 从示例中看出什么

例 4.1 到例 4.7 展示了 DAC 的几个关键特点：

可以按对象授权；
可以按操作类型授权；
可以按列授权；
可以授权给单个用户、多个用户或 PUBLIC；
可以通过 WITH GRANT OPTION 形成权限传播链。

这说明 SQL 的授权机制非常灵活。

4.7 收回权限：REVOKE

4.7.1 REVOKE 语句的作用

授权出去的权限不是永久不变的，必要时可以收回。

REVOKE 的一般格式为：

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

语义是：

收回指定用户在指定对象上的指定权限。

4.7.2 典型回收示例

例 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 从 DBA 得到权限；
U5 授予 U6；
U6 再授予 U7。

当执行：

REVOKE INSERT ON TABLE SC FROM U5 CASCADE;

就会发生：

收回 U5 的 INSERT 权限；
同时级联收回 U6、U7 从 U5 这条链路间接获得的权限。

但是要注意：

如果 U6 或 U7 还从其他用户处获得了相同权限，那么那部分权限仍然保留。

系统只收回：

直接或间接从 U5 传播出去的那部分权限。

4.7.3 CASCADE 与 RESTRICT 的理解

从语义上理解：

CASCADE：级联收回；
RESTRICT：受限收回。

学习时要重点记住：

一旦存在传播链，权限回收就不再是“删一条记录”这么简单，而要考虑整个授权依赖关系。

4.7.4 SQL 授权机制的小结

课件对 SQL 授权机制做了一个总结：

数据库管理员

拥有所有对象的所有权限；
可以把不同权限授给不同用户。

用户

拥有自己建立对象的全部操作权限；
可以用 GRANT 把权限授予其他用户。

被授权用户

如果具有继续授权许可，可以再授权给别人。

权限回收

所有已授出的权限，在必要时都可以用 REVOKE 收回。

这体现了 SQL 授权机制的特点：

灵活、细粒度、可传播、可回收。

4.8 数据库角色

4.8.1 什么是角色

数据库角色，是：

被命名的一组与数据库操作相关的权限。

本质上，角色就是权限的集合。

引入角色的目的，是为了：

简化授权过程；
便于统一管理一类用户；
避免把同样的一批权限一遍遍授给不同用户。

4.8.2 角色的基本操作

1. 创建角色

CREATE ROLE <角色名>;

2. 给角色授权

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

3. 把角色授予用户或其他角色

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

4. 收回角色权限

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

4.8.3 角色示例

课件中的例 4.14 展示了如何通过角色把一组权限授给多个用户。

第一步：创建角色 `R1`

CREATE ROLE R1;

第二步：让角色 `R1` 拥有 `Student` 表的 `SELECT`、`UPDATE`、`INSERT` 权限

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

第三步：把角色 `R1` 授给王平、张明、赵玲

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

这样三个人就同时拥有了 R1 所包含的全部权限。

第四步：一次性收回王平的这组权限

REVOKE R1 FROM 王平;

4.8.4 角色机制的优点

角色最重要的价值有三个：

降低授权复杂度：把“给人授权”变成“给角色授权”；
便于统一管理：同岗位的人直接分配同一角色；
方便批量回收：直接回收角色即可。

在实际系统中，角色通常比“逐个用户直接授权”更常用。

4.9 视图机制与数据库安全

4.9.1 视图为什么能提供安全性

视图机制的核心作用是：

把要保密的数据对无权存取这些数据的用户隐藏起来。

也就是说，视图并不是直接改变数据，而是：

重新定义用户“能看到的数据范围”；
只把允许暴露的部分展示出去。

因此，视图能为数据提供一定程度的安全保护。

4.9.2 视图与授权配合使用

课件特别强调：

视图机制配合授权机制，可以间接地实现支持存取谓词的用户权限定义。

这句话的意思是：

普通授权往往是“整张表可不可以访问”；
但借助视图，可以把“满足某个条件的那部分数据”单独取出来；
然后只对这个视图授权。

于是你就实现了：

不是让用户访问整张表；
而是让用户访问表中“符合某种条件的一部分行”。

4.9.3 视图安全示例

课件中的例 4.17：

建立“计算机科学与技术专业学生”的视图：

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

然后在这个视图上定义权限：

GRANT SELECT ON VIEW CS_Student TO 王平;
GRANT ALL PRIVILEGES ON VIEW CS_Student TO 张明;

4.9.4 这个例子说明了什么

这个例子说明：

视图可以筛选数据范围；
用户不必直接接触原始基本表；
不同用户可以在同一个视图上拥有不同权限；
WITH CHECK OPTION 可以约束通过视图进行更新时，更新后的数据仍然满足视图定义条件。

因此，视图的本质价值是：

把“数据安全”从“只控制权限”扩展到“还能控制用户看见的数据子集”。

4.10 审计

4.10.1 什么是审计

审计（Audit）就是：

把用户对数据库的操作自动记录下来，以便事后检查。

课件中提到会启用一个专用的审计日志（Audit Log），把数据库中的各种操作自动写入日志。

审计员可以利用审计日志来：

监控数据库中的各种行为；
找出非法存取数据的人；
查明操作发生的时间；
确定被访问的内容。

4.10.2 审计的重要性

审计最大的价值在于：

它不能总是阻止问题发生；
但它能让问题可追踪、可定位、可追责。

这属于典型的事后控制机制。

课件指出：

C2 级以上安全级别的数据库管理系统必须具有审计功能。

4.10.3 审计功能的可选性

虽然审计很重要，但它不是越多越好。

因为：

审计会消耗时间；
审计会占用存储空间；
如果记录过多，还会带来管理负担。

因此 DBA 通常会根据应用对安全性的要求，灵活地打开或关闭审计功能。

课件强调：

审计功能主要用于安全性要求较高的部门。

4.10.4 审计事件的类型

课件给出了四类审计事件。

1. 服务器事件

对数据库服务器发生的事件进行审计。

2. 系统权限事件

对系统拥有的结构或模式对象进行操作的审计。

前提是：

执行该操作的权限，是通过系统权限获得的。

3. 语句事件

对 SQL 语句进行审计，例如：

DDL；
DML；
DCL。

4. 模式对象事件

对特定模式对象上的：

SELECT；
或其他 DML 操作。

进行审计。

4.10.5 审计语句

课件给出了：

AUDIT：设置审计功能；
NOAUDIT：取消审计功能。

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

SHOW AUDIT_TRAIL;
SET AUDIT_TRAIL TO ON;
AUDIT ALTER, UPDATE ON SC BY ACCESS;

从这个例子中要掌握三点：

审计通常先检查当前开关状态；
再打开审计开关；
最后指定对哪些对象、哪些操作进行审计。

4.11 数据加密

4.11.1 为什么要加密

数据加密是：

防止数据库中数据在存储和传输中失密的有效手段。

这说明加密主要解决的是：

数据被窃听；
数据被非法获取；
数据在落盘或传输过程中泄露。

4.11.2 加密的基本思想

加密的基本思想是：

根据一定算法；
将原始数据，也就是明文（Plain text）；
转换为不可直接识别的格式，也就是密文（Cipher text）。

所以加密不是“把数据藏起来”，而是：

即使别人拿到了数据，也看不懂。

4.11.3 加密方式分类

课件把加密方法分为两大类：

存储加密；
传输加密。

4.11.4 存储加密

存储加密用于保护数据写入磁盘后的安全。

1. 透明存储加密

特点：

对用户完全透明；
数据在写到磁盘时自动进行加密。

课件中特别提到：

内核级加密方法性能较好；
安全完备性较高。

所谓“透明”，就是用户在使用数据库时，通常感受不到加密过程的存在。

2. 非透明存储加密

特点：

通过多个加密函数实现；
用户或应用更明显地参与加密过程。

4.11.5 传输加密

传输加密用于保护数据在网络中的传输安全。

课件提到两种方式：

1. 链路加密

对通信链路进行加密。

2. 端到端加密

对通信两端之间传输的数据直接加密。

学习时要理解：

存储加密解决“落盘后泄露”的问题；
传输加密解决“路上被窃听”的问题。

二者保护的阶段不同，但目标一致，都是防止失密。

4.12 创建数据库权限的补充说明

课件最后补充了“创建数据库的权限”问题。

这一点很容易被忽略，但实际上也属于安全控制的一部分。

4.12.1 为什么创建数据库也需要授权

因为“创建数据库”本身就是一种高权限操作。

如果不控制：

用户可能随意创建数据库；
增加系统资源消耗；
破坏管理秩序；
甚至借机进行其他安全风险操作。

所以：

创建数据库本身也必须纳入授权控制。

4.12.2 课件中的 KingbaseES 示例

以金仓数据库 KingbaseES 为例，通常做法是：

先由超级用户创建普通用户；
再决定哪些用户拥有 CREATEDB 权限。

CREATE USER 的格式示意为：

CREATE USER <username> [WITH]
[SUPERUSER | CREATEDB]
PASSWORD 'password';

例 4.12：创建具有 `CREATEDB` 的用户 `U1` 和普通用户 `U2`

CREATE USER U1 WITH CREATEDB PASSWORD '123456';
CREATE USER U2 PASSWORD '123456';

说明：

U1 具有创建数据库的权限；
U2 是普通用户。

例 4.13：以 `U1` 身份创建数据库 `U1DB`

CREATE DATABASE U1DB;

4.12.3 这一补充的意义

这一部分提醒你：

权限控制不只针对“表中数据”；
也包括数据库对象的创建能力；
不同 DBMS 在具体语法上可能有差异，但“创建数据库需要授权”这一思想是一致的。

4.13 本章知识结构总结

学完这一章后，你应该形成下面这张“脑图式理解”。

4.13.1 数据库为什么需要安全机制

因为数据库：

数据共享；
多用户访问；
常处于网络环境；
经常保存敏感信息。

因此必须防止：

非法访问；
数据泄露；
数据篡改；
数据破坏。

4.13.2 数据库安全控制的主线

数据库安全控制可以按逻辑顺序理解为：

先识别人是谁：身份鉴别；
再判断他能不能做：DAC / MAC / 权限检查；
必要时只给他看部分数据：视图；
把做过的事情记下来：审计；
即使数据被截获也不能直接看懂：加密。

4.13.3 本章最核心的几个结论

结论 1：安全性控制是分层的

从用户登录、数据库访问、操作系统保护，到存储与传输加密，都是数据库安全的一部分。

结论 2：DAC 和 MAC 是两种核心存取控制方法

DAC 灵活，适合一般系统；
MAC 严格，适合高保密场景。

结论 3：SQL 通过 `GRANT` 和 `REVOKE` 实现 DAC

GRANT 用于授权；
REVOKE 用于收权；
可以按表、按列、按用户、按全体用户进行控制；
权限可传播，也可级联回收。

结论 4：角色是权限集合

角色能显著降低授权和回收的复杂度。

结论 5：视图机制可以隐藏敏感数据

它能把“整表权限”细化成“只看满足条件的数据子集”。

结论 6：审计解决“可追踪”问题

它是安全管理中的事后控制手段。

结论 7：加密解决“即使拿到数据也难以看懂”问题

存储加密保护落盘数据，传输加密保护网络中的数据。

4.14 复习时最容易混淆的点

4.14.1 安全性与完整性不要混淆

安全性：谁可以访问、如何防泄露、防破坏；
完整性：数据本身是否正确、是否符合约束。

本章讲的是前者。

4.14.2 DAC 与 MAC 不要混淆

DAC：按“权限”控制；
MAC：按“密级/许可证级别”控制。

4.14.3 `WITH GRANT OPTION` 与 `WITH CHECK OPTION` 不要混淆

WITH GRANT OPTION：允许继续授权；
WITH CHECK OPTION：保证通过视图更新后的数据仍满足视图条件。

4.14.4 表级授权与列级授权不要混淆

表级授权针对整张表；
列级授权只针对某些属性列；
列级授权时必须显式写出列名。

4.14.5 审计与加密不要混淆

审计：记录行为，便于追踪；
加密：保护数据内容不被直接识别。

一个偏“记录”，一个偏“保护内容”。

4.15 本章一句话总结

数据库安全性的本质，就是通过身份鉴别、存取控制、视图、审计和加密等机制，保证数据库中的数据只能被合法用户以合法方式访问，并且在出现问题时能够追踪责任、降低泄露风险。

第4章 数据库安全性