DBPA · 4.2

其他安全保护机制

承接身份与授权：限制看见什么，记录做过什么，保护信息流

VER. 2608.2 Built with impress.js

学习目标

视图、审计、加密、推理控制、隐私保护和分权分别限制数据访问、追踪行为与降低泄露风险

01用视图、授权和 CHECK OPTION 限制数据窗口
02区分权限检查与审计，记录成功或失败并追溯行为
03区分透明与非透明存储加密
04比较链路与端到端传输加密，说明证书不等于数据库授权
05用最小案例解释推理控制和隐蔽信道的风险
06从隐私生命周期和分权角度评价风险边界

2/17

LEARNING OBJECTIVES

视图把授权边界放在用户可见的数据窗口

视图先限制行列范围，再通过最小权限控制操作；示例采用标准 SQL 语义

SQL

01
02
03
04
05
06
07
08
09
10
11
12
13
14-- 标准 SQL 示意；账号与主机格式需按当前 DBMS 核对
CREATE VIEW CS_Student
AS
SELECT Sno, Sname, Smajor
FROM Student
WHERE Smajor = '计算机科学与技术'
WITH CHECK OPTION;

GRANT SELECT
ON CS_Student
TO 王平;

-- 王平只有 SELECT；若张明获写权限，越出 WHERE 的写入应被拒绝
-- WITH CHECK OPTION 只约束通过该视图进行的写入

Takeaway

视图缩小可见范围，GRANT 决定能做什么；若同时授予 Student 直达权限，用户可绕过这个窗口

3/17

VIEW SECURITY

视图安全仍需要其他机制配合

一个数据窗口不能替代身份、授权、完整性和审计组成的安全控制链

视图

视图隐藏不需要的行和列，但只有授予窗口权限时才形成有效边界

GRANT 授权

GRANT 限制 SELECT、INSERT、UPDATE、DELETE；基本表直达权限可能绕过窗口

完整性与 CHECK OPTION

基本表约束保证状态合法，CHECK OPTION 要求通过视图写入的数据仍满足视图谓词

Takeaway

身份鉴别与 DAC／MAC 决定谁能到达窗口；视图限制窗口，审计记录结果

4/17

VIEW BOUNDARY

审计记录成功与失败的安全事件

审计不负责放行，而是记录访问和控制结果，使事件能够追溯和分析

访问尝试→身份／授权检查→放行或拒绝→审计日志→分析与响应

记录谁

审计可以记录普通用户、特权用户和认证失败中的尝试身份

记录什么

审计可以记录登录、授权、DDL、DML、DCL 和对象访问

记录结果

成功与失败都可能有价值，日志通常还要包含时间、对象和语句

5/17

AUDIT

审计分类要把责任范围与事件类型分开

记录越多，追溯能力越强、资源成本越高；管理责任与事件类型是两个分类轴

分类轴	关注问题	例子
责任范围	谁能设置、查看规则与日志	DBA 配置；审计员查阅
认证事件	谁尝试登录以及是否成功	密码错误、成功登录
特权／授权事件	谁改变了安全规则	GRANT、REVOKE、角色变化
语句与对象事件	对哪个对象做了什么	UPDATE SC、ALTER、SELECT

6/17

AUDIT SCOPE

审计规则要能闭环验证并受到保护

下例采用 KingbaseES 风格；具体语法与日志位置需要查产品手册

SQL

01
02
03
04-- [KingbaseES]，非 MySQL 8.4 通用 SQL
AUDIT ALTER, UPDATE ON SC BY ACCESS;
-- 测试成功／失败 UPDATE；查日志中的用户、时间、对象、语句和结果
NOAUDIT ALTER, UPDATE ON SC;

Takeaway

审计规则的闭环包括开启规则、测试操作、核对日志和撤销规则；MySQL 8.4 需要按审计插件与部署核查，日志也需受到完整性、保密性和访问控制保护

7/17

AUDIT CONFIGURATION

加密保护数据在存储和传输中的形态

明文经过算法变成密文，获得相应密钥的授权端再按规则解密

明文→加密算法与密钥→密文→解密→明文

存储加密

存储加密保护磁盘、备份和其他存储介质中的数据

传输加密

传输加密保护客户端与服务器之间传输的信息

密钥管理与成本

密钥管理需要处理保管、轮换、性能与恢复；密钥访问不等于数据库 SELECT 权限

Takeaway

加密保护数据形态，不替代最小权限和审计

8/17

ENCRYPTION

四种加密方式的保护边界不同

机制选择取决于需要保护的数据所在位置

方式	保护范围	应用影响
透明存储加密	磁盘与存储层	应用通常无需改写
非透明存储加密	应用或数据库函数处理字段／值	需要改造应用并处理密钥
链路加密	每段链路的报头与报文	中间节点可能解密并重新加密
端到端加密	端点之间的报文内容	中间节点通常看不到内容；报头／元数据可能仍可见

Takeaway

这些描述是机制语义，不是当前 DBMS 的统一配置命令；产品、密钥位置和端点都要单独核对

9/17

STORAGE AND TRANSPORT

可信传输先确认通信端点，再协商密钥

这是 TLS／SSL 的概念流程，不等于数据库账户授权

01按证书和配置验证服务器，必要时验证客户端身份
02协商加密算法与会话密钥
03加密传输并校验数据完整性

Takeaway

证书验证确认通信端点，不等于数据库已有 SELECT 权限；账户、视图和 GRANT 仍决定服务器端能读写什么，实际选项属于产品／部署配置

10/17

TRUSTED TRANSFER

合法查询的组合也可能越过权限边界

推理控制关注用户能否从可见信息推出不应获得的结论

多次查询结果　＋　函数依赖与背景知识→未授权结论

已知信息 A

A：职务=教师，工资=3000（用户已知）

查询结果 B

B：职务=教师，但工资字段受限

推理前提

本例假设业务规则 职务 → 工资，所以可能推出 B 的工资为 3000

Takeaway

每条查询都可能获准，但组合关系仍可能越过边界；函数依赖是本例的明确假设，不是普遍事实

11/17

INFERENCE CONTROL

成功与失败反馈也可能成为隐蔽信息通道

这是抽象安全模型，不是当前 Student／SC 的可执行脚本

高密级发送者决定是否先写入 `key=K`→低密级接收者再写入 `key=K`→成功=1／重复错误=0

机制	发送者／接收者动作	反馈编码与风险
唯一约束	高密级先写入或不写入 K；低密级再写 K	成功／重复错误传递 1 比特
查询结果	接收者请求带隐藏状态的查询	行数或错误差异暴露状态
操作时序	观察者比较不同路径的响应时间	快慢差异形成时序侧信道

12/17

COVERT CHANNEL

隐私保护贯穿数据的全生命周期

发布前要先识别准标识符和重新识别风险

收集与存储

收集与存储阶段只保留必要数据，并控制保存和访问

处理

处理阶段要限制推理、关联和二次使用风险

发布

出生年、性别和邮编等可以组成准标识符；若组合只对应一人，重识别风险较高

Takeaway

k 匿名让相同准标识符组合至少对应 k 条记录，但不保证绝对匿名；l 多样性和 t 临近是其他保护思路，匿名发布也不能替代授权、加密或审计

13/17

DATA PRIVACY

分权管理降低超级用户单点失控风险

关键职责相互制约，安全操作更容易被复核

系统管理、数据管理和安全审计相互分离，可以分散高权限

角色	主要职责	不应独立拥有的动作
系统管理员	账户、配置与平台维护	修改业务数据或删除审计记录
数据管理员	维护业务数据	独立修改安全策略或删除审计记录
审计员	读取并分析审计日志	修改业务数据或审计记录

Takeaway

分权降低单点失控风险，同时增加流程和协调成本；它不能消除串通、账户失陷或紧急授权风险

14/17

SEPARATION OF DUTIES

用保护目标和边界判断安全机制

视图、审计、加密、隐私和分权分别保护数据范围、行为记录、信息形态、发布结果和管理职责，但都保留边界

视图 + GRANT

视图和 GRANT 限制数据窗口与操作，但基本表直达权限会绕过窗口

授权 + 审计

授权决定放行或拒绝，审计记录成功与失败

加密

加密保护数据在落盘或传输途中的形态，但不替代最小权限

其他机制

推理控制、隐蔽信道控制、隐私保护和分权可以降低风险，但不能使风险归零

15/17

RECAP

本节知识地图

16/17

KNOWLEDGE MAP

本节问题

01视图、GRANT、CHECK OPTION 各限制什么？为何不能同时开放基本表直达权限？
02审计怎样记录成功与失败？AUDIT／NOAUDIT 为何要标产品边界？
03透明与非透明存储加密在应用改造、密钥管理上有何差异？
04链路与端到端加密如何处理报头、内容和中间节点？证书验证为何不等于 SELECT 权限？
05怎样用“职务 → 工资”解释推理泄露？怎样用唯一约束的成功／失败解释隐蔽信道？
06出生年、性别、邮编为何是准标识符？分权为何不能消除串通风险？

17/17

CHECK YOUR UNDERSTANDING