多租户物联网平台的数据隔离

一套平台同时服务多个客户，是集成商和设备厂商常见的形态。隔离做得不够，一次查询条件写漏就可能让 A 客户看到 B 客户的设备；隔离做得过重，每新增一个客户就要部署一整套环境，运维成本随客户数线性上升。

三种粒度

1. 共享库加租户键：所有表带租户标识，查询层强制注入条件。成本最低、扩展最容易，代价是依赖代码纪律；
2. 独立 schema：每个租户一套表结构，连接时切换。隔离更强，迁移和备份也更灵活，代价是表结构变更要逐个执行；
3. 独立实例：每个租户一套完整环境。隔离最彻底，适合有强监管要求的客户，成本也最高。

多数项目从第一种开始是合理的。关键在于不要把租户条件交给每个业务函数自己记得写 —— 应当在数据访问层统一注入，让漏写在代码层面不可能发生。靠代码评审兜底的做法，在团队变动后迟早会漏。

设备接入侧才是薄弱点

管理后台的权限通常会被认真对待，设备接入侧反而容易被忽略。几条典型的越权路径：

• 设备凭据未绑定租户，设备可以往任意主题发布，于是 A 租户的设备能把数据写进 B 租户的主题；
• 订阅权限未限制通配符，一台设备订阅上层通配主题，就能收到同平台其他租户的下行命令；
• 设备注册接口未校验所属租户，任何人用一套注册凭据即可把设备挂到指定租户名下。

对策是让租户标识成为主题结构的固定层级，并在凭据的权限规则里写死：这台设备只能读写自己租户、自己设备标识下的主题。这也是主题设计要把租户放在靠前层级的原因之一。

容易遗漏的几处

导出功能、报表任务、告警通知、以及各类后台定时作业。这些路径常常绕过了常规的查询层：一个按天汇总所有设备的定时任务，如果没带租户维度，生成的报表就会把各租户数据混在一起。上线前应当专门盘一遍所有不经过用户请求触发的代码路径。

日志和监控同样要注意。把租户标识打进日志便于排障，但日志平台本身的访问权限也要控制，否则隔离在业务层做到了，却在日志层泄露。隔离粒度是架构层面的早期决策，属于平台与系统开发里最先要定的问题之一。