定义
RBAC（Role-Based Access Control）即基于角色的访问控制，将用户与角色关联、角色与权限关联，实现细粒度权限管理。设备管理平台通过 RBAC 控制不同角色对设备、OTA、告警等功能的访问，配合 Audit Log 记录操作。
模型与权限粒度
RBAC 核心要素包括用户、角色、权限、资源。权限可细化为功能权限（如 OTA 下发、远程控制）与数据权限（如按产品、分组、区域隔离）。设备管理平台常定义管理员、运维、只读、审计等角色；支持角色继承与组合，满足复杂组织架构。数据权限可基于 Device Grouping 设备分组、租户隔离实现，确保用户仅能访问授权范围内的设备与数据。
与 DMP 的集成
平台在 API、控制台、批量操作等入口统一实施 RBAC 校验。敏感操作（如 OTA 下发、设备删除、凭证重置）可要求二次认证或审批流程；Audit Log 审计日志记录谁在何时执行了何种操作，支撑合规与安全审计。与 SSO、LDAP 等身份源集成时，需将外部用户/组映射为平台角色，实现统一身份与权限管理。
应用场景
适用于多租户 SaaS 平台、企业内多部门协作、外包运维与内部审计分离等场景。细粒度 RBAC 可最小化权限暴露，降低误操作与越权风险，满足等保、ISO 27001 等合规要求。
角色、权限与资源范围如何叠在一起
基于角色的访问控制把“你是谁”和“你能做什么”拆开。使用者只加入角色，角色再挂功能权限和资源范围。功能权限决定能否看见远程控制、升级、删除、凭证重置这些入口；资源范围决定这些入口作用在哪些产品、分组、租户或区域。两层都要在同一次请求里同时判定。只判断功能，运维角色就能对全平台设备下发指令；只判断范围，只读账号若被配进了升级接口，仍可以在自己的分组里发起任务。
角色适合表达稳定职责，不适合为每一个临时项目新建一套几乎相同的角色。项目差异应落在资源范围上：同一“现场运维”角色，甲站点的人只能看到甲的分组，乙站点的人只能看到乙的分组。继承关系要短，多层继承会让一张有效权限表无法口头说清。敏感动作，例如批量重启和凭证作废，应在角色允许之后再要求一次单独确认，确认记录进审计，而不是把确认步骤当成角色本身。
组织变更后角色仍可用的条件
角色模型能长期使用的条件，是身份源里的人员变动会反映到平台账号上。人员离职、外包到期、部门合并时，若只在人事系统停用、平台侧账号仍有效，角色配置再细也挡不住旧会话。对接外部目录时，应映射组和角色，而不是把目录里的每一个人复制成平台管理员。映射表本身要可审计：哪个外部组对应平台的哪个角色、哪个资源范围。
临时授权应带结束时间。借出的升级权限到期后自动收回，而不是靠人记得改回去。共用账号不适合进入这套模型，因为审计只能看到账号，看不到实际操作者，事后无法判断是谁对远程控制点了确认。接口调用与控制台使用同一套判定，不能出现页面按钮隐藏了、用令牌仍能调通写接口的情况。批任务在创建时冻结当时的资源范围，避免任务排队期间操作者被调岗，任务却继续作用到新的设备集合。
功能权限放开但数据范围没收紧
最常见的偏差是给实施人员一个“几乎全部菜单”的角色，数据范围却留空，空被系统解释成不限制。页面上能搜到其他租户的设备，导出、升级、工单派发都会越出合同边界。空范围应视为拒绝，而不是视为全部；需要全量的角色必须显式选择平台级范围，并单独审批。
另一处错误是只在查询接口过滤分组，写接口却按设备标识直接操作。知道标识的人可以改不属于自己的设备。写路径必须再次核对这个标识是否落在调用者当前的资源范围内。角色复制时如果连同范围一起复制，新人会继承前任的站点权限，看起来像配置没问题，实际是范围被复制宽了。调整角色后应使旧会话重新取权限，否则已经打开的页面会在令牌过期前继续使用缓存里的旧判定。
权限变更之后要用一张实际生效的清单抽查，而不是只看角色编辑页。清单包括该账号能调用的写接口、能看见的设备标识样本，以及不能看见的邻近租户样本。邻近样本若仍能打开，说明范围判断没有进入那条接口。角色删除前先列出仍引用它的账号和未完成任务，任务若冻结了旧范围，应决定是继续按冻结范围做完还是立即停止。没有这步，删除角色只会让新的登录失败，旧任务仍在越权执行。