1. 多租户概念与SDK权限隔离概述
这些年我接过不少SaaS平台的项目，发现有个问题几乎每个团队都会踩坑——租户之间的数据打架。说白了，就是把A客户的数据不当心给了B客户。这事儿在合规上可是要命的。
所以这门课，我们聊聊多租户环境下SDK的权限隔离。先打好基础，从最基本的概念讲起。
什么是多租户？
多租户不是啥新鲜概念。你看微信办公、飞书、钉钉这些平台——一家公司注册一个账号，里面的员工各自用各自的权限。这就是多租户的典型场景。
我习惯把多租户理解为「一栋写字楼里的多家公司」。物业（平台方）提供水电、电梯、安保（基础设施），但每家公司有自己的门锁、办公室、会议室（业务数据）。谁也不该进别人的房间。
多租户的三个核心要素
| 要素 | 说明 | 我碰到的坑 |
|---|---|---|
| 租户身份 | 每个租户有唯一标识（tenant_id） | 有次系统升级忘了带 tenant_id，所有数据串了 |
| 数据隔离 | 不同租户的数据互不可见 | 用共享数据库时，SQL 漏写 WHERE 子句就完了 |
| 资源配额 | 每个租户能用的资源上限不同 | 免费版客户调用频率没限制，直接把 API 打挂了 |
SDK 权限隔离为什么重要？
你想想看，如果你的 SDK 被嵌入到甲方的应用里，这个应用又服务着几十个租户……
这时 SDK 能接触到哪些数据？能调用哪些接口？写操作怎么限制？
我曾经遇到过一家公司的 SDK，所有租户的数据查询接口都走同一个 key。后来有个租户的开发者「不小心」遍历了其他租户的订单列表。嗯，场面一度非常尴尬。
一旦出现租户数据泄露，GDPR、CCPA 等法规的罚款可不是小数目。关键是客户信任一旦碎了，可很难修。
SaaS 中的租户管理流程
一个典型的多租户系统，租户管理大概这么走：
- 注册租户 — 客户完成注册，系统分配 tenant_id
- 配置隔离策略 — 选择数据库方案、存储方案、API 访问规则
- 下发 SDK 凭证 — 生成该租户专属的 + secret，绑定权限范围
- 运行时校验 — 每次 SDK 请求都要校验身份、权限、配额
- 审计与监控 — 记录所有跨租户操作，异常行为告警
这里面最容易出问题的就是第 3 步——凭证下发。凭证的权限粒度直接决定了后续的隔离效果。
SDK 权限隔离的层次模型
下面这张图是我自己梳理的权限隔离层次。你看每一层都有对应的隔离手段：
这个模型我最看重的是SDK 层。为什么？因为租户层和应用层的隔离，是大平台在负责的。但 SDK 一旦发出去，就跑在客户的环境里了。可控性下降了，但安全性要求一点没降。
我在上一个项目里，把 SDK 层的权限隔离做成了「最小必要原则」——SDK 只拿到它执行当前操作所需的最小权限。宁可在初始化时多做几次校验，也别图省事一把梭给全部权限。
你需要掌握哪些前置知识？
说白了，这门课假定你已经接触过：
- RESTful API 设计 — 知道怎么设计接口、校验请求
- OAuth 2.0 / JWT — 明白 是怎么签发的、怎么验证的
- 数据库隔离方案 — 了解独立库、共享库+隔离schema、共享表+tenant_id 这三种模式
- Python / Go 开发经验 — 因为部分代码示例会用这两门语言
如果没有这些基础也别慌。每涉及新概念，我会在对应的章节里简单回顾。毕竟我也记不住所有东西，遇到不熟的，查一下就好。
总结一下本章重点
- 多租户 就是一套系统服务多个客户，核心在于隔离
- SDK 权限隔离 是保障租户数据安全的关键防线
- 隔离分 4 层：租户层 → 应用层 → SDK 层 → 资源层
- SDK 层是攻防的焦点，因为它在不可控的执行环境中运行
ok，概念部分就聊到这。下一章我们直接上手——看看怎么设计一个租户感知的 SDK 架构，我会用代码带你把隔离逻辑跑通。
（别担心，代码量不会很大，但每行都有用。）