.webp){kind=small}
06-企业内部完整权限管理体系-组织授权流程与权限治理
企业内部完整权限管理体系：组织、授权流程与权限治理
运行时鉴权回答“现在能不能做”，企业权限治理还要回答：权限是谁定义的、谁申请和批准、为什么仍然存在、何时复核、转岗和离职后如何回收、无人负责的服务账号怎么办。
只有授权，没有治理，权限会持续累积，最终形成权限蔓延和无法解释的高风险访问。
1. 权限目录与角色目录
每项权限至少需要：编码、名称、业务域、资源、操作、风险等级、负责人、是否可申请、是否允许临时授权、审批要求、复核周期和生命周期状态。
每个角色需要：角色类型、负责人、权限集合、默认 Scope、适用主体、成员上限、可否申请、可否委托、复核周期和角色层级。
权限和角色都必须有 Owner。无人负责的高风险权限不能长期保持 Active。
2. 组织、岗位和用户组驱动授权
组织用于人员和数据归属；岗位用于职责位置；用户组用于跨组织集合；角色用于权限集合。
常见自动化：
王芳担任“华东财务部主管”岗位
→ 自动获得 FINANCE_MANAGER
→ Scope = 华东分公司
→ 来源 = POSITION_ASSIGNMENT
自动授权必须保留来源，岗位撤销后间接角色自动失效。不能把岗位权限复制成永久直接角色。
项目组则适合临时成员：Alice 加入 Project-A 后获得项目文档读取能力，到期或退出项目组后自动回收。
3. 权限申请
申请表单应要求：
- 受益主体；
- 角色或权限；
- 作用域；
- 有效期；
- 业务理由；
- 关联工单或项目；
- 是否紧急；
- 风险提示。
申请人和受益人可以不同，例如主管为员工申请。系统应检测已有等价权限、互斥角色、超过最大授权期限和重复申请。
高风险权限不能只让用户输入“工作需要”，应要求可验证的业务依据。
4. 审批路由
审批人可能包括：直属主管、资源所有者、权限负责人、数据负责人、系统负责人和安全负责人。
审批路由应由权限元数据和 Scope 决定，而不是在每个业务系统中写死。常见模式：
普通角色：直属主管 → 角色负责人
敏感数据：直属主管 → 数据负责人 → 安全负责人
跨租户特权：平台负责人 → 安全双人审批
要处理会签、或签、超时、代理审批、撤回和审批人离职。审批通过并不等于直接修改用户表，而是创建可追踪的 Role Assignment、ACL Entry 或 Delegation。
5. 授权结果和来源
Access Grant 表示治理结果，运行时事实关系可以是：
- Role Assignment；
- ACL Entry；
- Policy Assignment；
- Delegation。
它们需要关联申请单、审批任务、授予人、有效期和版本。管理员手工授权也必须填写来源和理由，不能成为无法审计的“后门入口”。
6. 权限生命周期
权限项有定义、发布、废弃和退役；主体授权有申请、审批、授予、生效、复核、续期、到期和撤销。两种生命周期必须区分。
临时授权应使用明确 valid_until，到期由系统自动失效，而不是只发提醒。长期权限即使没有截止时间，也应有复核周期。
权限撤销后需要：更新授权状态、增加主体权限版本、失效缓存、处理高风险会话、发布变更事件并保留历史记录。
7. Joiner–Mover–Leaver
Joiner 入职
创建身份后，根据组织和岗位授予最小权限。试用期、外包和实习生可以应用更短有效期和更严格数据范围。
Mover 转岗
转岗不是“加上新角色”。应先识别旧岗位、旧组织和临时项目产生的权限，撤销不再需要的来源，再授予新权限，并复核重叠高权限。
Leaver 离职
立即禁用身份和会话，撤销 Role Assignment、委托和第三方授权，转移资源所有权，处理个人拥有的服务账号和 API Client。离职账号不能只从通讯录隐藏。
8. 职责分离
静态职责分离
用户不能同时拥有冲突角色，例如 IAM 权限管理员与审计管理员。分配时即阻止。
动态职责分离
允许拥有多个角色，但限制同一交易或会话中的使用，例如创建人不能审批本人的付款单。
四眼原则
高金额付款、平台管理员授权和 Break Glass 可以要求两名不同主体确认。系统应验证“不同人”，不能只验证两个审批步骤都完成。
9. 委托、代理和临时提权
- Delegation：把已有权限的一部分临时委托给其他主体。
- Impersonation：管理员按目标用户权限模拟访问。
- On Behalf Of：服务或 Agent 代表用户执行，但保留双方身份。
- Temporary Elevation：用户在短时间内激活更高权限。
委托不能超过委托人的权限、Scope 和有效期，默认禁止再次转委托。任何模式都必须记录 Actor、Subject、原因、审批和时间窗。
10. 委托式管理 Delegated Administration
企业不可能让平台超级管理员管理所有部门和项目。管理权限本身也要有 Scope：
李四拥有 iam:role:assign
Scope = 华东销售部
Allowed Roles = SALES_SPECIALIST, PROJECT_MEMBER
他不能给华南员工分配角色，也不能授予自己无权管理的财务角色。项目管理员只能管理项目成员，租户管理员只能管理当前租户，角色负责人只能审批负责的角色。
11. 超级管理员与 Break Glass
应区分平台管理员、租户管理员、应用管理员、权限管理员和审计管理员，不要使用一个 ADMIN 角色包办全部能力。
Break Glass 是紧急访问机制，不是永久超级账号。建议要求：
- MFA；
- 双人审批或事后强制复核；
- 很短有效期；
- 必填原因和事件编号；
- 全量高风险审计；
- 使用后自动撤销；
- 定期演练和检查不可用风险。
即使拥有 *:*:*，也不应绕过租户边界、主体禁用、强制审计和法规策略。
12. 人类主体治理
- 正式员工：由 HR 生命周期驱动。
- 实习生和外包：设置明确结束日期和赞助人。
- 合作伙伴：只进入项目或资源 Scope，不加入内部默认岗位角色。
- 管理员：使用独立管理身份或按需提权，避免日常账号长期高权限。
- 临时人员：授权到期后自动失效并通知负责人。
13. 非人主体治理
服务账号
必须有负责人、用途、环境、凭证轮换、最后使用时间和到期日期。禁止多人共享一个无法归属的账号。
微服务
使用工作负载身份、证书或短期 Token。服务间权限按 API 能力授予，不使用员工角色。用户身份向下游传播时还要验证调用服务本身是否有代理能力。
定时任务
限制时间窗口、查询日期、批量数量和写能力。任务重试不能绕过幂等、数据范围和审计。
第三方应用
使用独立 Client、Scope、字段限制和吊销机制。用户同意不等于应用获得租户内全部数据。
AI Agent
控制可调用工具、参数范围、用户代表权限和人工确认。提示注入不能改变系统授权，工具执行端必须再次校验。Agent 的操作需要可归属到 Agent、用户、模型版本和调用链。
14. 权限定期复核
复核对象包括：
- 用户全部权限；
- 高风险角色成员；
- 角色权限集合；
- 服务账号和第三方应用；
- 长期未使用权限；
- 无负责人的角色；
- 即将过期的临时授权；
- 通配符和跨租户特权。
复核不能只让主管点击“全部保留”。系统应提供使用记录、来源、有效期、风险和替代权限，并允许批量撤销或缩小 Scope。
15. 权限废弃与迁移
权限编码进入 Active 后不应静默改变语义。废弃流程：标记 Deprecated、指定替代权限、禁止新增授权、扫描角色和代码引用、迁移、观察、最终 Retired。退役编码不能重新用于其他含义，历史审计必须保持可解释。
16. 权限管理后台
建议的信息架构：
- 权限目录：查看能力、风险、Owner 和引用。
- 角色目录：权限集合、成员、层级和约束。
- 主体详情：所有直接与间接权限来源。
- 申请与审批：风险提示、Scope 和有效期。
- 授权记录：来源、授予人、版本和到期。
- 委托与模拟：当前会话和历史操作。
- 复核中心：按风险和到期组织任务。
- 审计查询：决策原因、策略和授权链。
最重要的产品能力是“为什么有权限”和“撤销这个来源后还剩什么权限”。
17. 常见错误
- 入职自动加权限，离职依赖人工删除。
- 转岗只加新权限，不回收旧权限。
- 所有权限都由一个超级管理员直接分配。
- 临时授权只有备注，没有系统有效期。
- 审批通过后无法关联实际 Role Assignment。
- 服务账号没有负责人，密钥多年不轮换。
- 管理员模拟用户时日志只记录被模拟用户。
- 定期复核没有使用数据和风险上下文，沦为形式操作。
18. 小结
企业权限管理体系的核心是把权限作为有负责人、有来源、有作用域、有期限、可复核和可撤销的资产。运行时模型决定“能不能”，治理体系决定这种能力为什么存在以及何时消失。
评论