guide · platform
IoT SaaS 多租户隔离
在身份、主题、存储、控制和运营层面统一租户边界。
版本、来源核对与技术审阅
- 适用场景
- 设备影子:期望状态、报告状态与不确定性
- 发布日期
- 版本
- 版本信息见一手来源
- 事实与来源
- 已于 2026年7月14日 对照所引来源核对
- 技术审查
- 暂无独立技术审阅记录
结论先行
一句话决策建议
租户隔离在最薄弱的层失效,因此使用一个权威租户上下文并在每个边界独立执行。
直接回答
使用一个从认证身份派生的可信租户上下文,贯穿每个请求和消息,并在代理、API、任务队列、缓存、数据库、对象存储和运维工具中独立执行。绝不能因为负载、主题、URL 或查询参数仅仅声明了租户 ID 就授予访问权限。
共享基础设施可以是安全的,但隔离强度取决于保护最少的路径。当影响、合规义务、噪声邻居风险或客户合同无法通过共享逻辑控制可靠处理时,应选择更强的物理或账户级隔离。
范围与非范围
本指南涵盖为多个客户组织提供服务的 IoT SaaS 平台的租户隔离。包括用户、设备、网关、遥测、命令、存储、后台工作、支持访问和计量。
不定义通用合规架构,也不保证某种隔离模型满足特定监管机构要求。也不覆盖物理控制器内部的安全分区。监管、数据驻留、加密和客户特定要求须与合格的安全和法律审查人员共同映射。
建立权威身份与所有权
分别建模用户身份、设备身份和租户成员关系。一个用户可能属于多个租户,而设备应有明确的所有权记录和受控的转移生命周期。认证证明谁在连接;授权决定该主体是否可对属于某租户的资源执行操作。
从已验证的令牌、证书映射或服务端会话派生租户范围。从平台注册表解析设备所有权。如果设备在负载中发布 tenantId,将该值视为待验证或可忽略的数据——而非授权证据。将凭证绑定到设备和租户,在所有权转移时轮换,并防止旧凭证保留访问权限。
按工作负载选择隔离层级:
| 模型 | 适用场景 | 主要权衡 |
|---|---|---|
| 共享服务和共享表 | 控制成熟且租户风险相似 | 对策略和查询正确性依赖最高 |
| 共享服务、分区模式或数据库 | 数据边界需要更强的运维防护 | 更多迁移、连接和集群管理 |
| 专用数据平面或账户 | 合同、规模、驻留或风险证明其必要性 | 更高成本和部署复杂度 |
平台可以组合这些模型。小型租户可以共享数据平面,而受监管的租户获得专用接入和存储。保持应用契约一致,使移动租户不需要重写产品行为。
在每一层执行边界
- 创建租户感知的资源模型。每个设备、站点、告警、命令、文件、任务和 API 密钥都需要一个明确的所有者。
- 从可信身份一次性解析租户上下文,然后传递不可变内部标识符。拒绝路径、负载和身份范围冲突的请求。
- 对所请求资源而非仅路由应用 API 授权。加载不透明 ID 后检查租户所有权。
- 为 MQTT 客户端提供从凭证所有权派生的主题 ACL。分离发布和订阅权限,拒绝逃逸所分配命名空间的通配符访问。
- 在队列信封、分区键、对象路径、加密上下文、搜索文档、缓存键、速率限制和指标标签中包含租户上下文。
- 在靠近数据的位置执行存储控制。根据风险使用行级安全、租户过滤仓库、独立模式或独立数据库;不要仅依赖 UI 过滤。
- 后台工作器和导出与交互请求一样精确地限定范围。在执行敏感工作时重新授权,而非假设入队时的上下文永远有效。
- 将支持和事件访问置于即时提权、理由或工单、窄时间窗、强认证和不可变审计之下。
避免在各处理器中散布自由格式的租户过滤器。集中资源加载和查询原语,使其在构造上即要求租户上下文。对于 SQL,getDevice(tenantId, deviceId) 这样的仓库方法比通用设备查找后再做可选所有权检查更安全。纵深防御仍需要数据库策略和测试。
消息与控制需要特殊处理
主题命名有助于组织但不是访问控制。配置代理授权,使设备只能发布其批准的遥测和确认,只能订阅自己的命令命名空间。服务端服务也应仅获得所需的最小通配符范围。验证共享订阅、保留消息、会话恢复和死信路径是否保留租户边界。
命令必须绑定租户、目标设备、发起主体、过期时间和幂等键。命令执行器在投递前应重新检查当前所有权。在租户间转移的设备不得收到前所有者的延迟命令,前租户也不得保留对历史或新生成数据的访问权限——除非产品明确定义了该行为。
故障模式与负面测试
缓存键中缺失租户上下文可能将一个客户的设备响应泄露给另一个客户,即使数据库查询是正确的。CDN 键、幂等记录、搜索索引、临时导出文件和可观测性链接中存在相同风险。
不透明标识符减少猜测但不授权访问。用属于另一租户的有效 ID 测试每个读取、更新、删除、导出和命令端点。包括 GraphQL 解析器、批量 API、WebSocket 订阅、报告下载和移动同步端点。
运维捷径是常见的逃逸路径。全局支持令牌、数据库控制台、重放工具和死信重处理器需要明确的租户范围和审计。日志可能在支持团队间泄露负载或凭证;对可观测性栈也应用访问控制和脱敏。
噪声邻居故障即使没有数据泄露也是隔离问题。对连接、消息、规则、存储、查询、导出和后台工作执行每租户配额。测试一个租户的重连风暴或大范围查询是否会耗尽为其他租户预留的容量。
实施清单
- 租户上下文仅来自认证的、服务端验证的身份。
- 用户、设备、凭证和所有权转移有明确的生命周期模型。
- 每个资源和异步任务有权威租户所有者。
- 代理发布和订阅 ACL 经过跨租户通配符测试。
- 数据库、缓存、对象、搜索和队列键始终包含租户上下文。
- 跨租户负面测试覆盖读取、写入、命令、导出和订阅。
- 支持访问有时间限制、有理由、最小权限且可审计。
- 每租户配额控制噪声邻居流量和昂贵查询。
- 备份、恢复、删除和设备转移保持预期边界。
主要参考来源
NIST IoT 设备网络安全能力基线提供了设备级别的标识、逻辑访问、数据保护、安全更新和状态感知能力。OASIS MQTT 5.0 规范定义了协议行为,而代理 ACL 语义是具体实现相关的。对于服务范围的访问控制族和审计目标,使用NIST SP 800-53 Rev. 5,然后在每个选定的基础设施产品中验证具体控制。
上线前必读
实施检查清单
- 从认证身份派生租户归属。
- 测试跨租户的负面用例。
- 在共享控制不足时隔离高风险工作负载。
一手来源
事实核验
- NISTIR 8259 — IoT Device Cybersecurity Capability Core Baseline访问日期 2026年7月14日
- OASIS MQTT Version 5.0访问日期 2026年7月14日
来源核对日期 2026年7月14日 · 下次计划核对: 2027年7月14日
维护记录
更新历史
- 2026年7月14日
- 首次发布
- 2026年7月14日
- 更新内容并核对来源
如有不清晰、不准确或过时的内容,请告诉我们。