GeoXMind

多租户隔离要覆盖身份、计算、网络与数据边界

说明租户上下文、共享集群、网络数据隔离和资源公平性，并把运维路径与生命周期纳入验证。

多租户隔离要覆盖身份、计算、网络与数据边界

多租户系统让不同客户、团队或组织共享部分基础设施，同时要求一个租户的行为和数据不能越过约定边界。隔离不是单个开关，而是身份、控制面、计算资源、网络、存储、密钥和运维流程共同形成的属性。共享程度越高，资源效率通常越好，但爆炸半径和证明隔离的难度也越大。

设计前要定义租户是谁、租户之间是否互不信任、平台管理员能看到什么、合规是否要求物理或账户分离。没有明确威胁模型时，“逻辑隔离”无法对应可验证的安全目标。

租户标识必须贯穿请求和数据

入口认证后应从受信身份声明解析租户，而不是接受客户端任意提交租户 ID。租户上下文要随请求、异步消息和后台任务传播，并在每个授权边界重新验证。日志和跟踪可以记录受控租户标识，但不应泄露敏感名称或数据内容。

共享数据库可采用每行租户键与行级策略、每租户 schema，或独立数据库。每行模型密度最高，却要求所有查询、唯一约束、缓存键和索引都包含正确租户范围；独立数据库隔离更强，但迁移、连接和成本管理更复杂。选择应由风险、规模和运维能力决定。

备份、分析仓库、搜索索引和对象存储同样属于数据边界。生产查询已隔离而导出文件共用未受控路径，仍会造成泄露。删除和租户退出流程要覆盖副本、缓存、派生数据与保留策略。

共享集群需要分层控制

Kubernetes 官方多租户文档区分共享集群中的不同隔离需求，并讨论命名空间与虚拟控制面等方式：https://kubernetes.io/docs/concepts/security/multi-tenancy/ 。命名空间提供资源组织和策略作用域，但不是完整安全边界。集群级资源、节点内核、特权工作负载和错误的 RBAC 都可能跨越命名空间。

较可信团队可共享集群并使用命名空间、RBAC、准入策略、网络策略和资源配额。互不信任或高风险租户可能需要独立集群、账户、节点池，甚至独立云项目。虚拟集群能增强控制面分离，但底层节点、网络和存储仍可能共享。

平台组件的权限尤其关键。控制器、日志代理、备份程序和服务网格控制面常拥有跨命名空间读取能力，应使用最小权限、专用身份和审计。一个公共运维组件被攻破时，其可达范围决定真实隔离上限。

网络隔离从默认拒绝开始

网络策略应限制租户命名空间之间、工作负载到控制面以及出站到外部的路径。默认拒绝后按服务依赖逐项开放，比在开放网络上维护拒绝名单更容易审计。DNS、镜像仓库、时间服务和可观测端点等基础依赖要显式纳入。

服务身份和双向认证可以减少对 IP 的信任，但仍需授权策略。NIST 零信任架构把保护对象放在资源而非网络位置上：https://csrc.nist.gov/pubs/sp/800/207/final 。租户内合法身份不应自动获得租户所有资源权限，跨租户管理操作则应有更强身份验证和审批。

网络隔离必须用真实连接测试验证。不同容器网络接口、主机网络、负载均衡器和出站网关可能改变策略执行位置。策略对象创建成功不代表底层插件已支持或覆盖全部流量。

资源公平性防止邻居干扰

CPU、内存、磁盘 I/O、网络带宽、连接池和外部配额都可能被一个租户耗尽。请求与限制、配额、优先级和公平队列需要组合使用。只限制容器 CPU 而共享数据库连接池不分租户，仍可能出现某个租户占满连接导致全局故障。

配额应覆盖稳态和突发，并定义超额后的行为。关键控制面要保留独立容量，避免租户负载阻塞认证、计费或运维。按租户监控吞吐、错误、延迟、队列和成本，但高基数指标必须控制标签生命周期。

限流键要来自受信租户上下文，不能被请求头伪造。多个实例执行本地限流时，总额度会随实例数变化；集中限流又可能形成可用性瓶颈。实现应说明近似程度和故障时是开放还是关闭。

生命周期和验证决定隔离是否持续

租户创建应自动配置身份、数据空间、密钥、配额、网络策略和审计；人工遗漏会造成配置漂移。变更租户等级或迁移隔离模式时，要保持标识稳定并核对所有数据副本。租户删除需要分阶段停用访问、导出、按保留期清除并生成证明。

隔离测试应包含越权 API、跨租户对象引用、缓存键冲突、消息主题配置、搜索过滤、备份恢复和管理员工具。安全测试之外，还要做资源争用压测和故障注入，确认一个租户的高负载、异常数据或部署失败不会扩散。

多租户架构不能只看正常请求路径。批处理、调试终端、数据库迁移、客服查询和灾难恢复往往拥有更高权限。把这些运维路径纳入同一身份和审计模型，才能让租户隔离从设计约束变成持续可验证的系统属性。

资料依据