先从业务动作而不是职位名称开始
权限梳理的第一步不是创建“管理员、经理、员工”三个笼统角色，而是选取真实流程，列出每个岗位需要执行的业务动作及其对象。例如同样处理客户资料，查看、创建、修改、转交、导出和删除代表不同风险，不能因为都在一个页面里就合并成一项权限。
NIST 对基于角色的访问控制说明，权限通过角色而不是逐个用户身份来组织，角色通常对应组织中的工作职能。落到项目中，可以先整理稳定岗位职责，再把人员分配给角色；频繁变化的个人需求不要反过来制造大量只服务一个人的角色，否则后续调岗和审查会迅速失控。
- 选三到五条高频业务流程作为梳理入口
- 列出流程中每个岗位实际执行的动作
- 标明动作针对的单据、客户、文件或配置
- 区分本人操作、协作查看和最终决策
- 确认岗位变化时角色是否仍然成立
第一层建立功能权限矩阵
功能层回答“能做什么”。建议用“业务对象×动作”建立矩阵，行可以是客户、订单、合同、报表和系统配置，列可以是查看、新建、编辑、提交、撤回、删除、导入、导出和配置。每个角色只勾选完成职责所需的动作，不使用一个含义不清的“完全访问”覆盖所有能力。
界面隐藏只能改善使用体验，不能代替服务端授权。OWASP 的授权指南建议默认拒绝，并在每次请求上验证权限。因此验收时既要点击页面按钮，也要检查直接请求接口、修改记录编号或调用导出地址时是否仍会重新判断；没有明确授予的动作应返回拒绝结果。
- 查看和编辑分开定义
- 删除与作废按业务含义分别处理
- 导入、导出和批量操作单独列出
- 配置类动作不随普通业务权限自动获得
- 页面入口与服务端接口使用同一授权规则
- 未匹配任何规则时默认拒绝
第二层单独定义数据范围
数据层回答“能处理哪些记录”。拥有客户查看功能的人，可能只能看本人负责客户、本部门客户、指定区域客户或全公司客户。数据范围必须与功能动作组合判断；不能因为用户能打开客户列表，就默认可以读取所有客户，也不能只过滤列表而遗漏详情、搜索、统计和导出接口。
设计数据范围时要写清组织关系从哪里来、何时更新以及历史记录如何处理。例如员工调岗后，旧部门记录是立即不可见、保留只读还是通过交接转移，应由业务负责人确定。若规则依赖客户负责人、部门、区域或项目成员等属性，还要规定空值、多人负责和跨部门协作时的处理方式。
- 本人创建与本人负责是否代表同一范围
- 部门范围是否包含下级部门
- 跨部门项目按成员还是组织归属授权
- 详情、搜索、统计和导出的范围保持一致
- 调岗、离职和交接后数据范围如何变化
- 范围字段为空或异常时是否安全拒绝
第三层把审批权与操作权分离
审批授权不是给某个角色增加一个“审批按钮”就结束。需要明确什么单据、什么条件、什么金额或业务级别进入哪个审批路径，审批人如何确定，能否转交、加签、退回或撤回，以及审批人缺席时怎样临时代理。条件阈值和人员来源都应形成可测试规则。
还要识别不应由同一人同时完成的关键动作。例如申请、最终审批、付款执行和结果核对是否需要分离，要结合实际风险决定，而不是机械套用层级。若小团队确实需要一人承担多个环节，应把例外原因、适用范围、有效期和补充复核措施写清，避免长期使用共享账号绕开规则。
- 审批条件使用可计算字段而不是口头判断
- 审批人来源能够在人员变化后自动更新
- 申请、审批、执行和复核的职责冲突已检查
- 代理与转交有明确期限和可追踪记录
- 共享账号不能作为缺岗时的替代方案
第四层规定授权生命周期
权限不是上线时配置一次就不再变化。入职、转岗、兼岗、项目加入、临时支援和离职都会改变授权。每一种变化都应定义申请人、批准人、生效时间、失效时间和回收动作；临时权限默认带截止日期，到期自动失效，确需延长时重新说明原因。
个人例外应当少而可见。长期职责优先通过角色配置，短期需求才使用临时授权，并在管理页面显示来源和期限。定期复核时，不只看用户拥有哪些角色，还要检查角色本身是否累积了多余能力、组织关系是否过期、离岗账号是否停用以及高权限是否仍有业务必要。
- 新增授权有申请依据和批准人
- 临时授权设置明确失效时间
- 转岗时先回收旧职责再授予新职责
- 离职和外部协作结束触发账号与权限回收
- 定期复核用户、角色和个人例外三张清单
审计留痕要能还原关键操作
审计记录至少要帮助回答：谁在什么时间，通过哪个入口，对什么对象执行了什么动作，结果成功还是失败，权限或数据在操作前后发生了什么关键变化。OWASP 的日志指南把权限变更、管理操作、数据导入导出和访问控制失败列为需要重点考虑的事件，这些内容应在需求阶段进入范围。
记录越多不一定越安全。日志应服务于追溯和告警，同时避免直接保存密码、访问令牌、连接串等秘密信息，对个人和商业敏感字段做掩码或必要的受控存储。日志本身也需要访问权限、防篡改措施和保留规则；普通管理员能随意删除自己的操作记录，会破坏审计价值。
- 登录、授权失败和权限配置变更有记录
- 高风险新增、修改、删除、导入与导出可追溯
- 记录包含操作者、对象、动作、时间和结果
- 敏感凭证与不必要的个人数据不进入日志
- 日志读取、导出和删除本身也受控并留痕
- 异常事件有明确的查看人与处理方式
用三类场景完成权限验收
权限验收不能只让管理员登录后确认菜单齐全。第一类是正向场景，验证每个角色能完成职责；第二类是越权场景，验证同级跨数据、低权限调用高权限接口、猜测记录编号和直接导出都会被拒绝；第三类是变更场景，验证调岗、代理到期、离职和角色调整后权限及时变化。
验收表应把前置账号、角色、数据归属、操作步骤、预期结果和实际结果写在同一行，并覆盖网页、移动端、接口和批量任务等真实入口。上线前保留一份经过业务负责人确认的权限矩阵作为基线，后续新增模块或角色时继续补充测试。如果准备定制系统，可在首页提交真实流程，由业务与开发共同把权限表转成验收场景。
- 每个角色至少有一条完整正向业务路径
- 每项高风险动作至少有一条拒绝测试
- 同级越权和上下级越权分别验证
- 调岗、离职、代理到期和权限回收均有测试
- 新增接口与批量任务不会绕过既有规则
- 权限矩阵、测试记录和上线配置能够对应