📚 课程目录第4章权限审计实践

四、权限审计实践：审计用户角色分配、角色继承关系、权限变更记录与回滚

权限审计这事儿，说白了就是回答几个问题：谁拥有什么角色？这些角色从哪继承来的？什么时候改过权限？改错了能不能撤回去？

我在好几个项目里发现，很多团队把 RBAC 建得像模像样，但一查日志就傻眼——要么没记录，要么记了也看不懂。所以这一节，咱们就把审计这件事做到位。

4.1 审计用户角色分配

审计的第一步，就是搞清楚当前「用户-角色」的映射关系。说白了，就是一张表能查出来：张三到底绑了哪些角色，这些角色是谁在什么时候给他分配的。

核心原则：

每个用户与角色的绑定必须可追溯（谁、何时、通过什么渠道）
停用的角色分配也要保留历史记录，不能物理删除
审计查询要能按时间范围、按用户、按角色做过滤

我习惯在数据库里建一张 user_role_assignments 表，不只是存当前状态，还存历史状态。大致结构如下：

CREATE TABLE user_role_assignments (
    id              BIGSERIAL PRIMARY KEY,
    user_id         INT NOT NULL,
    role_id         INT NOT NULL,
    assigned_by     VARCHAR(64),   -- 分配人
    assigned_at     TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    revoked_at      TIMESTAMP,     -- 撤销时间，NULL 表示当前有效
    reason          TEXT           -- 分配/撤销理由
);

-- 查询用户当前所有有效角色
SELECT * FROM user_role_assignments
WHERE user_id = ?
  AND revoked_at IS NULL;

-- 查询用户历史角色变更记录
SELECT * FROM user_role_assignments
WHERE user_id = ?
ORDER BY assigned_at DESC;

你在做审计时，要特别注意「谁分配了角色」这个字段。我曾经遇到过一个 case，某运维同学给自己加了 admin 角色，系统里记录的是「系统自动分配」——这明显不对。所以我要强调：每次人工分配都必须记录操作人。

踩坑提醒： 千万别用「软删除」标记代替时间戳字段。如果只是用 is_deleted=1，那你怎么查「2024年3月到6月间张三有哪些角色」？时间戳能准确地告诉你每个角色的生命周期。

4.2 审计角色继承关系

角色继承是 RBAC 里最容易被搞出问题的环节。你想想看，如果角色 A 继承了角色 B，角色 B 又继承了角色 C，那这个链有多长？万一中间某个环节出了问题，权限就扩散了。

我在做审计时，会重点关注两件事：

继承关系有没有环： 比如 A→B→C→A，这种循环继承会导致权限计算死循环
继承链是否合理： 比如「guest 角色继承了 admin 角色的权限」，这明显不合逻辑

个人经验： 每次角色继承关系变更时，除了记录变更本身，还要生成一张「当前角色权限推导图」的快照。说白了，就是拍一张照片，将来审计时可以对比不同时间点的快照，一眼看出变化。

快照的存储方式，我一般用 JSON 格式：

-- 角色继承快照表
CREATE TABLE role_inheritance_snapshots (
    id              BIGSERIAL PRIMARY KEY,
    snapshot_time   TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    snapshot_data   JSONB NOT NULL  -- 角色–权限映射树
);

-- 快照示例 JSON
{
  "admin": ["read", "write", "delete"],
  "editor": ["read", "write"],
  "viewer": ["read"],
  "senior_editor": ["read", "write", "approve"]
}

为什么要存快照？因为如果只记录变更日志，等你回溯时再重新推导权限，计算量可能会很大。拍快照就是「预计算」，审计时直接查结果，省事。

4.3 审计权限变更记录

权限变更记录是审计日志的核心。我个人习惯是「事无巨细，全记下来」。别管是权限添加、撤销，还是修改，每条记录都要包含：

字段	含义	示例
actor	操作人	admin@company.com
action	操作类型	GRANT / REVOKE / UPDATE
target	被操作对象	role_id=42
detail	变更前后内容	{"before": ["read"], "after": ["read","write"]}
timestamp	操作时间	2025-04-01 14:23:11
source_ip	操作来源 IP	192.168.1.100

你看这个表，其实没啥特别高深的技术，关键是坚持。每次权限操作都要走这个日志接口，不能走旁路。我曾经在一家公司见过，某同事改权限时直接连数据库改表，系统日志没记录——这就等于审计盲区了。

4.4 审计回滚操作

最后一个环节是回滚。说白了，权限改错了怎么办？

回滚的基础是「可逆的变更日志」。每条变更记录都要存够信息，让你能还原到上一个状态。我个人推荐的实践是：

增量回滚： 只回滚某一次变更，比如把 role A 的「write」权限撤回
快照回滚： 直接把角色或用户的权限恢复到某个快照点
时间点回滚： 恢复到某个时间之前的完整权限状态

-- 增量回滚示例
-- 假设要撤销 "2025-04-01 14:23:11" 那次授予 write 权限的操作
REVOKE write FROM role_admin;
INSERT INTO permission_change_log (actor, action, target, detail)
VALUES ('rollback_agent', 'REVOKE', 'role_admin',
        '{"rollback_from_log_id": 12345, "reason": "误操作回滚"}');

注意： 回滚本身也要被审计。你不能偷偷把权限改回去还不留记录。回滚操作的日志里，必须注明「回滚的目标变更记录 ID」以及回滚原因。这样以后查起来，才能知道当时为什么变了。

最后，我把这一章的核心逻辑画成了一张图，方便你理解审计的四步闭环：

避坑指南： 我曾经在一个项目中，只做了「变更记录」但没做「回滚」功能，结果有一次误操作把某核心角色的 delete 权限给撤了，影响。最后花了三个小时人工追踪日志、挨个补权限。从那以后，我的每个项目都必须包含回滚机制。

总结一下这一节的重点：

分配审计： 记录每个绑定的生命周期，不物理删除
继承审计： 关注环和快照，防止权限扩散
变更审计： 全字段日志，operator、target、before/after、时间一个不能少
回滚审计： 三种回滚方式，回滚本身也要记日志

嗯，到这里，权限审计的实践我们就聊完了。接下来怎么把这些日志整合成一个可用的审计系统，那就是后面章节的事了。