配置中心多租户隔离怎么做？
简化版
多租户隔离不能只靠配置名称前缀。 要在身份、授权、存储键、加密、查询、推送、缓存、配额和审计各层强制带 tenantId，并由服务端从认证身份确定租户，不能信任客户端随意传入。 高安全租户可独立密钥、命名空间、存储分区甚至独立集群。
详细版
配置主键应包含 tenant、environment、namespace、dataId，所有读写与推送都执行同一授权规则。 用户和机器身份分别采用 RBAC/ABAC，权限细化到环境、命名空间和动作。 客户端缓存目录、长连接订阅和版本上报也要绑定租户，避免控制面隔离了、数据面却串租户。
共享基础设施通过资源配额、限流、公平调度和热点隔离防止 noisy neighbor。 审计记录主体、租户、目标和结果，但敏感配置不落明文。 隔离强度根据合规和威胁模型选择，逻辑隔离不是所有场景的物理隔离。
完整版教学
一、隔离要覆盖完整链路
租户 A 不能读取、修改、订阅或推断租户 B 的配置。 风险不仅在查询 API，也在搜索、导出、通知主题、本地缓存、备份和监控标签。 任何遗漏都可能形成旁路。
tenantId 是每一层的安全边界属性，不是为了好看的路径前缀。
二、租户身份来自可信认证
用户登录令牌包含受签名保护的组织与角色。 机器使用独立工作负载身份，并绑定允许访问的租户。 服务端从认证上下文推导 tenantId，再与请求资源核对。 如果直接信任请求参数，攻击者只需修改 tenantId 就可能越权。
三、统一资源模型
resource = tenant / environment / namespace / dataId
action = read | propose | approve | publish | export授权策略对 API、控制台、批量工具和内部任务一致生效。 缓存键、数据库唯一键、消息主题与对象存储路径都要包含规范化租户维度。 不要让空 tenant 或大小写差异落入公共空间。
四、逻辑和物理隔离
| 等级 | 手段 | 适用 |
|---|---|---|
| 逻辑 | 同库分区键、统一鉴权 | 普通租户 |
| 加强 | 独立 schema/密钥/队列 | 高价值租户 |
| 物理 | 独立集群与网络边界 | 强合规或高风险 |
物理隔离更强，但运维成本更高。 选择应依据法规、影响面和攻击模型，而不是默认越多越好。
五、推送和缓存也要隔离
长连接订阅建立时校验租户，后续每条通知仍携带不可混淆的资源身份。 客户端快照目录和文件权限按租户分开。 进程复用多个租户时，内存缓存键必须包含租户，不能只用 dataId。 版本上报同样校验实例是否属于目标租户。
六、防止资源互相拖垮
一个租户频繁发布可能耗尽推送线程、存储或长连接。 对发布 QPS、配置大小、订阅数和历史版本设配额，并采用租户级限流和公平队列。 例如总处理能力 5000 次/秒，不能让单租户突发 4800 次长期占满。 热点大租户可迁移到独立分区。
七、审计和验证
审计包含身份、租户、动作、资源、基线版本、结果和来源，不记录明文秘密。 定期执行跨租户负向测试：A 的令牌访问 B 的读、写、订阅、导出均应失败。 备份恢复也按租户验证，避免恢复工具绕过在线授权。 监控拒绝访问率、配额使用和跨租户异常，但控制标签基数。
八、常见误区与追问
- 误区：给 key 加租户前缀就完成隔离。 鉴权、推送、缓存和备份仍可能越界。
- 误区：客户端传来的 tenantId 可以直接信任。 必须与认证身份绑定。
- 误区：管理员默认可以查看所有秘密。 运维权限也应最小化并审计。
- 误区：逻辑隔离等同物理隔离。 两者安全边界和成本不同。
- 追问：如何防止大租户拖垮平台？ 配额、租户限流、公平调度和热点迁移。
- 追问：共享进程如何缓存多租户配置？ 所有缓存键都包含规范租户身份。
- 追问：如何验证没有串租户？ 覆盖所有接口与异步链路做负向自动化测试。
九、加强记忆
- 身份可信，tenantId 由服务端确定。
- 资源、权限、存储和推送统一带租户维度。
- 缓存、日志、备份等旁路同样隔离。
- 配额与公平调度隔离资源影响。
- 按风险选择逻辑、加强或物理隔离，并持续做越权测试。