第4章 权限动作定义：增删改查、审批、审核、查阅、执行
权限动作是业务流程中可执行的最小授权单元，也是构建权限模型的基本原子。本章定义八种标准权限动作：增（Create）、删（Delete）、改（Update）、查（Read） 构成数据操作四元组；审批（Approve）、审核（Review） 属于流程控制动作；查阅（View） 为只读访问动作；执行（Execute） 为运行特定功能或脚本的动作。本章将围绕每个动作的适用场景、前置条件、操作步骤、输入输出物、责任边界、记录材料、异常处理和验收标准展开，确保后续角色与权限映射有统一语义。
核心原则：权限动作应遵循“最小粒度、最少依赖”原则，避免将多个动作合并为一个粗粒度权限。例如，不应定义“编辑”动作同时包含“改”和“查”，而应拆分为Update 和 Read，以便精细控制。
4.1 适用场景
当业务流程中出现以下任一场景时，必须明确定义涉及的动作类型：
- 数据生命周期管理：创建新记录、删除过期数据、修改已有属性、查询记录详情。
- 流程节点控制：提交后需上级审批、质检部门审核通过后方可进入下一环节。
- 信息访问隔离：部分角色只能“查阅”脱敏数据，无法执行变更操作。
- 自动化或脚本执行：定时任务、批量导入、接口调用等需“执行”动作。
- 合规审计：所有动作须记录操作日志，用于事后溯源。
4.2 前置条件
- 已完成业务流程建模（第3章），明确每个节点的操作需求。
- 已建立动作字典，确保动作名称在组织内唯一且无歧义。
- 系统架构支持动作粒度的权限拦截（如Spring Security、RBAC框架）。
- 动作定义与业务术语一致，例如“审批”不得与“审核”混用。
4.3 操作步骤
定义权限动作时，建议按以下流程执行：
- 识别动作类型：对照业务节点判断属于数据操作、流程控制、只读访问还是功能执行。
- 独立命名：使用动词+名词格式，如
create_order、approve_purchase_request。 - 绑定输入输出：明确该动作需要哪些参数，返回什么结果。
- 设置前置校验：例如“修改”动作必须先通过“查阅”动作获得当前数据。
- 记录元数据：在权限配置文件中保存动作定义，并关联到系统模块。
4.3.1 八种标准动作定义表
| 动作名称 | 英文标识 | 语义说明 | 典型场景 | 前置依赖 | 是否纳入审计 |
|---|---|---|---|---|---|
| 增 | Create | 创建一条全新的业务记录 | 新建工单、添加用户、生成订单 | Read（检查重复） | 是 |
| 删 | Delete | 删除一条现有记录（逻辑或物理） | 撤回申请、移除废弃数据 | Read（确认对象） | 是（需保留软删除） |
| 改 | Update | 修改已有记录的属性值 | 编辑客户信息、更新工单状态 | Read（加载原数据） | 是 |
| 查 | Read | 查询或浏览记录内容，不产生变更 | 查看列表、导出报表、搜索详情 | 无 | 可选（记录查询条件） |
| 审批 | Approve | 对提交的请求做出批准或驳回决定 | 请假审批、采购订单审批 | 审查（前置审核） | 是 |
| 审核 | Review | 检查流程或数据的合规性，提出修改意见 | 合同审核、质检复核 | Read（获取完整上下文） | 是 |
| 查阅 | View | 只读访问，不允许复制或导出原始数据 | 阅览敏感报表、查看脱敏日志 | 无 | 是（记录访问IP和时间） |
| 执行 | Execute | 运行指定的系统功能、脚本或定时任务 | 启动备份脚本、调用第三方API | 无（或需系统权限） | 是 |
实践建议：在同一系统中，“查阅”与“查”的区别在于：查阅通常附带脱敏或水印，且禁止复制；而查询允许用户获取完整数据并可能导出。若业务未要求脱敏，可将两者合并为Read。
4.4 输入输出物
- 输入：业务流程节点清单、操作需求文档、现有权限配置表。
- 输出：权限动作定义清单（含英文标识、依赖关系）、动作字典（JSON/YAML格式）、审计字段映射表。
权限动作定义示例（JSON）
{
"actions": [
{
"id": "create_order",
"type": "Create",
"description": "创建新销售订单",
"dependency": ["read_customer", "read_product"],
"audit": true,
"module": "order_processing"
},
{
"id": "approve_purchase",
"type": "Approve",
"description": "审批采购请求",
"dependency": ["review_purchase"],
"audit": true,
"module": "purchase"
}
]
}4.5 责任边界
| 角色 | 责任描述 |
|---|---|
| 流程分析师 | 识别业务节点对应的动作类型，确保动作定义不重叠 |
| 安全管理员 | 审核动作的审计要求，确定哪些动作强制记录全部上下文 |
| 系统架构师 | 实现动作拦截器，确保动作前置依赖能自动校验 |
| 开发团队 | 按动作规范编码，避免将多个动作写入同一个鉴权点 |
4.6 记录材料
- 动作注册表：记录每个动作的名称、创建时间、所属模块、依赖动作列表。
- 审计日志样例：包含主体（用户/角色）、客体（资源ID）、动作、时间戳、结果（成功/失败）。
- 变更历史：动作定义的任何修改（新增、禁用、合并）需记录原因和审批人。
4.7 异常处理
- 动作命名冲突：如“delete_order”和“cancel_order”语义重复→统一仲裁，保留一个并建立别名映射。
- 循环依赖：动作A依赖B，B又依赖A→重新梳理业务逻辑，消除逆向依赖或拆分为原子动作。
- 动作粒度过粗：“编辑”同时包含Update和Delete→拆分为两个独立动作，便于精细化授权。
- 审计缺失：应当审计的动作未配置日志→安全管理员补充审计策略，重建关联。
警告：切勿将“审批”和“审核”混为一谈。审核是检查并提出意见，审批是做出最终决定。若流程要求两者分开，则必须定义两个独立动作，否则会导致角色权限冲突。
4.8 验收标准
- 所有业务节点均已映射到上述八种标准动作之一，无遗漏、无冗余。
- 每个动作在权限管理系统中已被注册，且前置依赖能正常校验。
- 审计日志中可正确记录每个动作的执行主体、时间、资源及结果。
- 通过角色-权限测试：给定普通角色只有Read权限，尝试Update接口被明确拒绝（HTTP 403 或对应业务错误）。
- 动作定义文档版本化并存档，后续变更需走变更流程。
4.9 八种权限动作关系图
下图展示了标准动作的分类层级与典型流转关系：
图中将八种动作分为三大类：数据操作组（蓝/青/红）负责记录生命周期；流程控制组（紫/橙）负责规则校验与决策；信息访问与执行组（绿/青）提供只读查询与功能触发。箭头表达了典型的依赖关系——例如“审核”通常在“审批”之前，“查阅”一般在流程结束后开放。