模块四：数据库安全与DCL权限设计

这一部分对应开卷考核的模块四，满分10分。教材第4章讲解了数据库安全性，其中自主存取控制的核心SQL语句就是 GRANT 和 REVOKE；教材还强调，权限由“数据库对象”和“允许的操作类型”共同构成。

也就是说，安全设计不能只写“管理员权限最高”，而要明确：

谁可以访问；
能够访问哪些表或视图；
可以执行查询、插入、修改还是删除；
权限如何授予和回收；
如何防止账号滥用与数据泄漏。

---

1. 评分任务拆解

任务	分值	完成要点
用户与角色权限体系	4	根据当天业务角色分层设计权限
DCL代码实现	3	创建用户、授权、回收权限、角色分配
安全防护策略	3	访问、密码、非法访问、数据泄漏等方案

---

2. 数据库安全的基本目标

2.1 保密性

未经授权的用户不能读取敏感数据。

例子：

普通业务人员只能看订单处理字段，不能查询用户密码信息或完整联系方式。

2.2 完整性

数据不能被无权限修改或恶意破坏。

例子：

查询人员只能查询统计视图，不能删除订单或修改支付金额。

2.3 可用性

合法用户在需要时能够正常使用数据。

例子：

管理员应做好备份和权限管理，避免误操作导致业务系统不可用。

---

3. 角色权限体系如何设计

3.1 最小权限原则

最小权限原则是安全设计中的核心思路：

每个用户或角色只获得完成本职工作所必需的权限，不额外授予高风险权限。

例如，客服需要查看订单状态，不一定需要删除订单；统计人员需要读取汇总结果，不一定需要查看全部个人敏感字段。

3.2 通用角色模板

下面以通用业务系统为例，考试当天可以换成题目指定的角色名称和表名。

角色	业务职责	可访问对象	建议权限
数据库管理员 db_admin	系统维护、备份恢复、账号管理	全部表及系统对象	必要管理权限，谨慎使用
业务管理员 biz_manager	维护基础资料、查看业务统计	商品/项目表、订单表、统计视图	SELECT、必要的 INSERT、UPDATE
业务操作员 operator	录入和处理日常业务	订单及明细相关表	SELECT、INSERT、有限 UPDATE
查询统计员 analyst	查看统计信息	汇总视图	仅 SELECT
普通用户对应应用账号	提交或查看本人业务	由应用控制访问范围	避免直接数据库管理权限

3.3 权限设计说明示例

系统采用基于角色的权限控制。数据库管理员负责数据库维护与备份恢复；业务管理员负责基础数据维护和业务统计；操作员只允许新增业务记录并更新处理状态，不授予删除核心业务数据的权限；统计人员仅可查询脱敏后的统计视图。该设计遵循最小权限原则，降低误操作和越权访问风险。

---

4. 权限对象与操作类型

对表和视图，常见权限包括：

权限	含义	使用场景
SELECT	查询数据	查看订单、查看汇总视图
INSERT	新增数据	新建业务记录
UPDATE	修改数据	更新状态或基础资料
DELETE	删除数据	仅授予确有删除职责的角色
REFERENCES	允许建立引用该对象的外键	建立关联表结构时使用
ALL PRIVILEGES	授予全部相关权限	应谨慎，通常只用于管理员

安全设计中应优先授予明确的少量权限，不要为了省事给普通账号授予 ALL PRIVILEGES。

---

5. MySQL中的DCL代码示例

下面用模块二中的订单示例表演示。实际考试需要把数据库名、表名和角色换为当天业务设计。

5.1 创建用户与角色

CREATE USER 'app_operator'@'localhost'
IDENTIFIED BY 'ChangeMe_Strong!2026';

CREATE ROLE 'operator_role';

说明：

app_operator表示日常业务操作员账号；
operator_role表示将一组权限集中管理的角色。
密码示例仅用于演示，正式系统应使用独立强密码并妥善保管。

5.2 向角色授予权限

GRANT SELECT, INSERT, UPDATE
ON examdb.Orders
TO 'operator_role';

GRANT SELECT, INSERT, UPDATE
ON examdb.OrderItem
TO 'operator_role';

GRANT SELECT
ON examdb.Product
TO 'operator_role';

解释：

操作员需要查看和处理订单及明细，因此可以查询、插入和有限修改；
对商品基础信息只授予查询权限，防止操作员随意修改商品数据。

5.3 将角色分配给用户

GRANT 'operator_role' TO 'app_operator'@'localhost';

SET DEFAULT ROLE 'operator_role'
TO 'app_operator'@'localhost';

5.4 回收权限

若后续规定操作员不能修改订单明细，可以从角色回收权限：

REVOKE UPDATE
ON examdb.OrderItem
FROM 'operator_role';

报告中应说明回收理由：

订单明细在业务确认后应保持稳定，因此回收操作员对明细表的修改权限，仅允许由审核角色在规定流程中处理异常调整。

---

6. openGauss中的DCL代码示例

如果考试选用 openGauss，可以使用下列形式。不同实验环境的数据库名、模式名或账号权限可能存在配置差异，因此必须在自己的环境中执行验证并截图。

6.1 创建角色和用户

CREATE ROLE operator_role;

CREATE USER app_operator
PASSWORD 'ChangeMe_Strong_2026!';

6.2 授予模式和表权限

GRANT USAGE ON SCHEMA public TO operator_role;

GRANT SELECT, INSERT, UPDATE
ON TABLE Orders, OrderItem
TO operator_role;

GRANT SELECT
ON TABLE Product
TO operator_role;

6.3 分配角色

GRANT operator_role TO app_operator;

6.4 回收权限

REVOKE UPDATE
ON TABLE OrderItem
FROM operator_role;

6.5 代码说明

openGauss中先建立角色，再将针对表的访问权限授予角色，最后把角色授予具体用户。这样当多个操作员权限一致时，只需维护角色权限，不必为每个用户重复配置。

---

7. 如何设计一个“只读统计”角色

若系统有统计人员，最好不让其直接读含敏感字段的原始表，而是让其读取统计视图。

假设已建立视图：

V_OrderSummary(OrderID, CustomerName, OrderTime, OrderStatus, TotalAmount)

MySQL示例：

CREATE ROLE 'analyst_role';

GRANT SELECT
ON examdb.V_OrderSummary
TO 'analyst_role';

设计解释：

统计人员只通过视图访问完成统计所需的数据，不获得原始客户资料表和业务修改权限，从而降低敏感信息泄漏以及误修改风险。

如果当天业务包含身份证号、手机号、地址、医疗记录等敏感字段，可以进一步在视图中隐藏或脱敏显示。

---

8. 安全防护策略

8.1 数据访问安全

可以写：

系统按照角色授予表或视图级权限，采用最小权限原则。普通操作员仅获得业务处理所需权限，统计人员仅查询汇总视图；对删除核心业务数据、修改金额等高风险操作只授权给经过审批的管理角色，并记录审计日志。

8.2 密码与账号安全

可以写：

数据库账号使用强密码，避免使用默认密码或多人共用账号；定期更换高权限账号密码；离职或岗位调整后及时回收权限；管理员账号只用于维护任务，日常业务使用低权限账号连接数据库。

8.3 防范非法访问与SQL注入

可以写：

应用程序访问数据库时应使用参数化查询或预编译语句，不将用户输入直接拼接成SQL；对登录失败、异常高频查询和越权操作进行记录和告警；数据库服务器限制不必要的外部网络访问。

错误做法示意：

把用户输入直接拼接进 SELECT 或 DELETE 语句，可能被构造输入绕过条件或破坏数据。

8.4 防止数据泄漏

可以写：

对手机号、身份证号等敏感字段进行脱敏展示，统计角色只访问必要视图；数据库备份文件应设置访问权限并加密保存；导出数据需要审批并记录用途；测试数据优先使用脱敏或模拟数据。

8.5 审计与备份保护

可以写：

系统记录关键数据的新增、修改、删除和授权变更操作，便于问题追溯；备份文件与日志同样属于敏感资产，应限制访问并保存于独立位置，防止攻击者通过备份获取完整数据。

---

9. 与当天业务结合的答题模板

9.1 权限体系表模板

角色	职责	可访问表/视图	权限	设计原因
管理员
操作员
查询人员

填写时必须使用当天业务中的实体，例如“借阅记录”“预约信息”“报修工单”，而不是无关的订单表。

9.2 DCL实现描述模板

本系统首先建立______角色，用于承担______业务操作；随后创建具体用户______，并通过角色授予其对______表的SELECT、INSERT、UPDATE权限。考虑到______数据一旦确认后不应由普通操作员修改，系统通过REVOKE语句回收其对______表的UPDATE权限。

9.3 安全策略段落模板

本系统遵循最小权限原则，以角色为单位管理访问范围。对普通业务账号仅授权完成工作所需的表和操作，对涉及敏感信息或核心数据修改的功能进行严格限制。账号采用强密码并及时回收失效权限；程序访问数据库时使用参数化SQL防止注入；敏感字段在查询与导出时进行脱敏，备份与日志文件限制访问并安全保存。

---

10. 常见失分点

失分问题	为什么失分	修改方法
只列角色，不写具体权限	没有形成权限体系	标明表/视图及 SELECT、UPDATE 等
授权代码没有回收权限	未覆盖题目要求	至少写一条有业务理由的 REVOKE
给普通角色全部权限	不符合最小权限原则	按职责拆分操作权限
SQL代码混用MySQL与openGauss语法	可能无法运行	选择一种环境实际调试
安全策略只写“加强管理”	内容空泛	写密码、注入、脱敏、审计、备份保护

---

11. 本模块快速背诵版

数据库安全设计的目标是保护数据的保密性、完整性和可用性。自主存取控制通过GRANT授予权限，通过REVOKE回收权限；角色可以集中管理一类用户的权限。

权限由访问对象与操作类型共同决定，例如允许某角色对订单表执行SELECT、INSERT和UPDATE，而不授予DELETE。设计权限时应遵循最小权限原则，将管理员、业务操作员和只读统计人员的访问范围区分开。

安全防护策略应包括强密码与账号回收、参数化查询防止SQL注入、敏感数据脱敏与导出控制、关键操作审计以及备份和日志文件的安全保护。