基于AWS Amplify实现员工管理系统细粒度访问控制的方案咨询

1. Cognito 身份配置设计（解决权限变更维护问题） #

放弃全用户组的实现方式，采用「用户组做大角色分类 + 自定义属性存动态权限维度」的组合方案，避免用户组数量爆炸、权限变更维护成本高的问题：

• Cognito用户组仅设置3个大类，基本不会变更：
  • HR：人力资源全角色
  • BusinessLeader：业务线管理人员（包含经理、总监、副总裁）
  • RegularStaff：普通员工、主管（默认无系统访问权限）
• Cognito自定义属性存储可变的权限维度字段，员工调岗、晋升时仅需修改对应属性即可，无需调整用户组：
  • custom:department：所属部门/业务单元，示例值unit1_dept1、hr
  • custom:position_level：职位层级，用数字编码（数值越小层级越高），示例值：1=副总裁、2=总监、3=经理、4=主管、5=普通员工
• 前端运维能力实现：无需使用AdminUI，自行封装一个Lambda函数，通过Cognito Admin API实现用户属性修改、用户组调整的能力，仅对HR或者高级管理人员开放该Lambda的调用权限即可，所有员工账号、权限调整操作都可以在前端完成。

2. GraphQL 权限规则实现（解决职位层级权限控制问题） #

利用Amplify GraphQL @auth指令的动态条件校验能力，直接通过JWT令牌中的Cognito自定义属性做权限判断，无需额外开发自定义Resolver：

type Employee 
  @model
  @auth(
    rules: [
      # HR组拥有所有员工数据的读写权限
      { allow: groups, groups: ["HR"], operations: [read, create, update, delete] }
      # 业务线管理人员权限：同部门 + 仅可访问层级低于自己的员工
      { 
        allow: groups, 
        groups: ["BusinessLeader"],
        operations: [read, create, update],
        condition: { and: [
          # 访问者与被访问员工属于同一部门
          { eq: ["$department", "{employee.department}"] },
          # 访问者的职位层级高于被访问员工（数字更小）
          { lt: ["$position_level", "{employee.position_level}"] }
        ]}
      }
    ]
  ) {
  id: ID!
  name: String!
  department: String!
  position_level: Int!
  # 其余员工信息字段
}

注：$department和$position_level会自动从当前请求用户的JWT令牌自定义属性中读取，{employee.department}和{employee.position_level}为被访问员工记录的对应字段，所有校验逻辑在AppSync层自动执行，无前端越权风险。
RegularStaff组未配置任何权限规则，默认无法访问系统数据，符合需求。

3. 权限变更即时生效方案 #

员工晋升、调岗修改完Cognito属性后，默认下次登录刷新JWT时权限自动生效，如果需要即时生效，可以在前端调用Auth.currentAuthenticatedUser({ bypassCache: true })强制刷新当前用户的令牌，立即同步最新权限。

方案优势 #

• 维护成本极低：用户组仅3个固定分类，权限调整仅需修改自定义属性，无需频繁调整用户组
• 无需依赖AdminUI：所有账号、权限运维能力都可以通过前端调用封装好的Lambda实现
• 权限逻辑集中管理：所有校验逻辑都在GraphQL Schema中声明，无需额外开发后端代码
• 扩展性强：后续如果需要新增层级、或者增加跨部门的特殊权限，仅需调整@auth的条件规则即可，无需重构身份体系。

内容的提问来源于stack exchange，提问作者hellocng