4. 权限模型基础
数据库权限模型决定了“谁在什么条件下可以对哪些对象执行哪些操作”。理解自主访问控制（DAC）、强制访问控制（MAC）和基于角色的访问控制（RBAC）三种基础模型，是设计可维护、可审计权限体系的前提。三者并非互斥，主流数据库往往以其中一种为主、辅以其他机制。
一、自主访问控制（DAC）：对象所有者说了算
DAC 的核心思想是：对象的所有者（Owner）自主决定把权限授予谁。权限以“主体—客体—操作”三元组形式存在，典型实现是 SQL 的 GRANT / REVOKE。例如在 PostgreSQL 中：
-- 创建用户并授予表级权限
CREATE USER alice WITH PASSWORD 'Alice@2024';
GRANT SELECT, INSERT ON orders TO alice;
-- 允许 alice 再把 SELECT 转授给他人
GRANT SELECT ON orders TO alice WITH GRANT OPTION;
DAC 的优点是灵活、贴近业务；缺点是权限分散、难以集中治理。当用户数量增长时，会出现“权限爆炸”：每个新员工都要单独授权，离职时又容易漏回收。此外，WITH GRANT OPTION 会造成权限链式扩散，审计时难以追溯最终授权来源。因此 DAC 适合对象数量少、人员稳定的场景，不适合大规模企业级权限治理。
二、强制访问控制（MAC）：系统策略高于个人意愿
MAC 由系统统一制定安全策略，主体和客体都被打上安全标签（如密级：公开、内部、秘密、机密），访问是否允许由标签比较规则决定，而非对象所有者决定。经典规则是 Bell-LaPadula 模型：
- 不上读（No Read Up）：低密级主体不能读取高密级客体，防止信息向上泄露。
- 不下写（No Write Down）：高密级主体不能写入低密级客体，防止高密级信息向下扩散。
在主流关系数据库中，纯 MAC 实现较少，Oracle 的 Label Security（OLS）是典型代表：通过 SA_POLICY_ADMIN 为表和行打上标签，用户会话携带标签，查询时自动追加过滤条件。MAC 的优点是安全性强、策略集中；缺点是灵活性差、标签维护成本高，通常用于政府、军工等高安全等级场景。
三、基于角色的访问控制（RBAC）：权限与角色绑定，角色与用户绑定
RBAC 引入“角色”作为用户与权限之间的中间层，用户通过被授予角色间接获得权限。其核心关系可概括为：用户—角色—权限。RBAC 还支持角色继承（角色包含子角色）和职责分离（SoD），是当前企业数据库权限治理的主流模型。
以 MySQL 8.0 为例，创建角色并授予权限：
-- 创建角色
CREATE ROLE 'app_read', 'app_write';
-- 给角色授权
GRANT SELECT ON shop.* TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON shop.* TO 'app_write';
-- 将角色授予用户
GRANT 'app_read' TO 'bob'@'%';
-- 激活角色（MySQL 需显式激活）
SET DEFAULT ROLE 'app_read' TO 'bob'@'%';
在 PostgreSQL 中，角色本身就可以作为用户使用，语法更统一：
CREATE ROLE analyst NOLOGIN;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO analyst;
GRANT analyst TO carol;
RBAC 的优势在于：权限变更只需调整角色，无需逐个用户操作；新员工入职只需授予对应角色；审计时可通过角色快速定位权限范围。实践中常采用“角色分层”设计：底层是对象权限角色（如 sales_read），中层是职能角色（如 sales_analyst），上层是岗位角色（如 regional_manager），用户只绑定岗位角色。
四、三种模型的对比与选型
| 维度 | DAC | MAC | RBAC |
|---|---|---|---|
| 授权主体 | 对象所有者 | 系统安全策略 | 管理员/角色所有者 |
| 权限粒度 | 对象级、列级 | 行级、标签级 | 对象级、角色级 |
| 灵活性 | 高 | 低 | 中高 |
| 可审计性 | 弱 | 强 | 强 |
| 典型实现 | GRANT/REVOKE | Oracle OLS | MySQL Role、PostgreSQL Role |
| 适用场景 | 小规模、稳定团队 | 高密级、强管控 | 企业级、多岗位 |
实际选型时，多数企业以 RBAC 为主干，在敏感表上叠加 DAC 的列级授权，在极高密级数据上引入 MAC 标签。三者组合使用，才能兼顾灵活性与安全性。
五、实践中的关键判断
无论采用哪种模型，都应遵循最小权限原则：只授予完成工作所必需的权限，并定期复核。判断权限设计是否合理，可以问三个问题：新员工入职时，是否只需绑定一个角色即可获得全部所需权限？员工转岗时，是否只需更换角色而无需逐表调整？离职时，是否只需禁用账号或撤销角色即可彻底回收权限？如果答案都是肯定的，说明 RBAC 分层设计基本到位。
SET DEFAULT ROLE 或 SET ROLE 显式激活；PostgreSQL 中角色可直接登录，也可作为权限集合被授予其他角色，设计时需注意区分 LOGIN 与 NOLOGIN 角色。WITH GRANT OPTION 时，被授权者可将权限继续转授，形成权限链。审计时应重点关注此类授权，避免权限失控。建议在生产环境中限制该选项的使用，改由管理员集中授权。掌握三种模型的差异与数据库实现方式后，下一步需要结合具体业务场景，设计角色分层与权限矩阵，把模型落到可执行的授权脚本和复核流程中。