一、模型概述
多租户 SaaS 或集团多子公司场景下，同一套达希设备管理平台承载多个逻辑租户。RBAC（基于角色的访问控制）将权限打包为角色：如租户管理员、运维工程师、只读审计、伙伴集成账号。每个主体被赋予角色与资源范围（项目、区域、设备组），API 与控制台统一鉴权，避免「控制台管得细、API 却全开」的裂缝。
设计角色时建议遵循「岗位而非个人」：权限挂在角色上，人员变动只调整角色成员关系，减少一次性授权散落。对跨国组织，可在角色中嵌入数据区域约束，与 数据驻留 策略一致。
二、隔离边界
数据面：查询默认注入租户 ID 过滤，防止 SQL/NoSQL 层越权。控制面：MQTT/HTTP 接入令牌绑定租户上下文。存储桶与加密密钥可按租户隔离，满足驻留与密钥轮换要求。跨租户操作仅平台超级管理员可执行，且强审计并需双人复核（可配置）。
缓存层、搜索索引与报表导出同样需要租户标签，防止「读缓存串租」。达希在规则引擎与 Webhook 投递链路中携带租户上下文，避免集成方误用全局密钥拉取他租数据。
三、常见角色模板
租户管理员： 用户与计费、角色审批。运维： OTA、配置、远程会话（可再细分只读与可写）。客服： 查看设备状态与工单，不可改配置。开发者： API 密钥管理仅限沙箱环境，生产密钥由单独角色保管。伙伴账号： 常限时、限 IP、限只读范围。
对 OEM 多品牌场景，可为品牌方配置「跨项目只读」角色，避免其看到集团内其他品牌的设备明细。角色模板应版本化，重大变更前在 沙箱 验证集成影响。
四、与 MFA 结合
高危角色强制 MFA。服务账号使用短期令牌与自动轮换，禁止写入镜像层。与 零信任 策略对齐时，可在异常地理位置或新终端首次登录时要求步进验证。
五、API 治理
结合 API 管理 做速率限制、scope 与 IP 白名单。Webhook 回调验签密钥分租户存储，旋转时支持双密钥并存窗口。误配公共回调 URL、或回调域与租户备案不一致时，策略应拒绝注册。
对 开放生态 伙伴，建议单独应用注册与审计维度，避免与内部员工账号混用同一 OAuth 客户端。
六、合规证据
定期导出角色矩阵、权限评审记录与例外审批单，供 监管映射 使用。人员离职、外包退场应自动回收角色与 API 密钥，避免幽灵账号。季度评审可抽样「长期未登录但仍持有写权限」的账号并清理。
七、实施节奏与评审
上线新功能时同步更新权限模型说明，避免研发默认「管理员测通即上线」。建议在变更窗口执行「权限差异预览」：展示将新增哪些 API 对哪些角色可见。重大促销或活动前冻结高危角色成员变更，降低人为失误面。
八、反模式与规避
反模式包括：共享超级账号排障、在生产环境长期使用伙伴沙箱密钥、为省事给客服开放配置下发权限。达希提供 break-glass 紧急账号模式，使用后强制审计与密码重置，兼顾应急与可追溯。
九、总结
RBAC 与多租户隔离是规模化平台的安全基石。达希设备管理平台在数据、控制、存储多层落实租户边界，并提供可审计的权限生命周期。延伸阅读：设备分组、合规审计追踪。如需多租户权限基线评审，请联系达希物联解决方案团队。