多租户环境下的SDK权限隔离实践 - 第3节
为什么这两个原则是隔离的基石？
说实话，我见过太多团队在做 SDK 权限隔离时，一上来就写代码，然后出了问题再回头打补丁。最后搞出一堆临时策略，维护成本飙升。我个人习惯先抓两个核心原则——最小权限和职责分离。这两个原则不是理论空谈，它们是你在设计阶段必须嵌入到架构里的硬约束。
你想想看，一个租户的 SDK 能访问另一个租户的数据，这种事出了就是安全事故。而几乎所有越权问题，归根结底都是因为权限给多了，或者一个人能干的事太大了。
最小权限原则：只给刚好够用的权限
什么是“最小”
最小权限不是说给得越少越好，而是 刚好完成任务所需。我举个例子：一个 SDK 模块只需要读取某个配置项，你就不要给它写入权限。它只需要访问 A 库，就不要给它 B 库的钥匙。
为什么要坚持？
- 攻击面缩小：权限越少，被利用的路径越少
- 故障隔离：一个模块被攻破，损害范围是可控的
- 审计清晰：每一条权限都有明确理由，不是“以防万一”给的
如何落实到 SDK 设计
我记得有次排查一个租户的 SDK 异常，发现它居然能调用系统级的管理接口。查了半天，原来是 SDK 初始化时用了全局管理员 。这是一个经典反例——权限粒度太粗。
我建议你在 SDK 的权限模型里，明确以下三个维度：
| 维度 | 说明 | 示例 |
|---|---|---|
| 操作 | 允许执行什么行为 | 读取、写入、删除、列举 |
| 对象 | 允许访问哪些资源 | 用户数据表、配置文件、日志流 |
| 范围 | 在多大范围内有效 | 仅当前租户、仅生产环境、仅某个 API 版本 |
在代码层面，可以用 权限令牌 + 作用域 来体现：
// 生成一个只有读取用户资料权限的
= TokenBuilder.newBuilder()
.tenant("租户A")
.scope("user.profile:read")
.expiresIn(3600) // 1 小时后过期
.build();
// SDK 内部校验流程
if (!.hasPermission("user.profile:read")) {
throw new AccessDeniedException("最小权限检查未通过");
}职责分离：不让一个人说了算
为什么必须隔离角色
你有没想过，如果同一个 SDK 既负责生成 ，又负责执行敏感操作，会怎样？一旦那个模块的开发者被攻破，整个系统就完了。这就是职责分离要解决的核心问题——避免权力过于集中。
我记得以前遇到一个案例：某云平台的一个 SDK 组件，既处理租户身份认证，又管理资源配额。结果内部测试时，一个误操作把所有租户的配额全重置了。你想，如果认证和配额管理由不同组件负责，这种事故根本不会发生。
如何在多租户 SDK 中实现
其实就三条规则：
- 认证模块不能同时持有授权决策权
- 数据访问模块不能同时拥有权限管理能力
- 审计日志必须由独立模块收集，业务模块只能写不能读
我建议你给 SDK 架构分层：
- 身份层：只负责验证请求来源是否合法
- 授权层：只判断该请求是否有权限执行
- 执行层：只负责在授权通过后执行具体操作
这三层之间通过 接口契约 隔离，不共享内部状态：
// 身份层：验证 有效性
IdentityResult identity = identityService.verify(request);
// 授权层：检查作用域是否匹配
AuthorizationResult auth = authorizationService.check(
identity.getTenant(),
request.getAction(),
request.getResource()
);
// 执行层：只有前两步都通过才放行
if (identity.isValid() && auth.isGranted()) {
executionService.execute(request);
} else {
auditService.logFailure(request, identity, auth);
}两个原则的协同关系
你可能会问：最小权限和职责分离，是不是独立的？其实它们相辅相成。最小权限管的是 “给多少”，职责分离管的是 “谁给谁用”。
我在项目中用过一张检查清单，你可以参考：
| 检查项 | 最小权限 | 职责分离 |
|---|---|---|
| SDK 初始化 | 只获取当前租户的标识，不获取全局配置 | 初始化代码与业务代码由不同模块处理 |
| 数据查询 | 只返回当前租户的数据，不能跨租户模糊查询 | 查询逻辑与权限校验逻辑不在同一函数内 |
| 配置变更 | 只允许修改租户自身配置，不能修改系统配置 | 配置变更请求必须经过审批链，不直接生效 |
| 日志查看 | 只展示当前租户的操作日志 | 日志写入由 SDK 自动完成，管理员只看写好的 |
实践中常见的坑
我曾经帮一个团队重构 SDK 权限模型，发现他们踩了三个典型坑，我拿出来说说：
- 坑一：给 SDK 分配了“管理员角色”，然后靠代码逻辑去限制实际权限。结果是，攻击者只需要绕过那层代码，就能用管理员权限做任何事。正确做法是从根上不给管理员 。
- 坑二：职责分离做得很完美，但所有模块都共用一个数据库连接池。结果一个模块的 SQL 注入直接污染了权限表。你想想，职责分离在物理上没有隔离，就等于没做。
- 坑三：最小权限检查只做了一次，在 SDK 初始化时。后续所有操作都复用同一个 ，忘了每个请求都应该重新校验作用域。这相当于一把钥匙开了所有门。
一张图看懂本章核心逻辑
下面这张图展示了最小权限与职责分离如何协同，构建 SDK 权限隔离的基础防线：
这张图里，左侧是最小权限的下钻——从操作、对象、范围三个维度控制权限粒度，右侧是职责分离的四个层级——身份、授权、执行、审计。看到了吗？两层之间有虚线关联：最小权限的落地要靠职责分离来保证不被绕过，而职责分离的有效性要靠最小权限来避免“权力过大”。