企业级多租户系统网络隔离核心在于按租户语义分层：公网入口须经统一网关识别并注入租户上下文，私网需横向划分租户专属域，资源调度层强制绑定租户网络身份，运维通道必须独立于业务网络。

企业级多租户系统中，公网与私网的规划不是网络配置问题，而是隔离策略的第一道防线。公网暴露面越小、私网域划分越清晰，租户间横向渗透和越权访问的风险就越低。关键不在于“是否用了私网”，而在于“私网如何按租户语义分层”。

公网入口必须收敛且带租户身份识别

所有面向互联网的请求，必须经过统一网关（如API Gateway或Ingress Controller），禁止业务服务直接绑定0.0.0.0:80/443。网关需在首跳完成三件事：

• 解析租户标识：支持子域名（tenant-a.example.com）、请求头（X-Tenant-ID）或路径前缀（/a/orders）等多种方式，并校验其合法性
• 注入租户上下文：将租户ID、安全等级、配额策略等元数据注入后端调用链，供后续服务消费
• 拒绝无标识流量：未携带有效租户标识的公网请求一律拦截，不透传至内部服务

私网按租户维度分域，而非仅按功能分层

传统微服务架构常按“API层→服务层→数据层”纵向划分子网，但这对多租户无效。正确做法是横向构建租户专属私网域：

• 每个核心租户分配独立VPC或VLAN（金融/政务类高合规租户建议物理网卡隔离）
• 跨租户通信必须走网关或服务网格（Service Mesh）控制面，禁止Pod/实例直连
• 数据库、缓存、消息队列等共享中间件，需通过命名空间（Namespace）、Schema前缀或连接池标签实现逻辑分域，并配合网络ACL白名单限制访问源

资源调度层强制绑定租户网络身份

在Kubernetes或YARN等调度平台中，租户不能只是逻辑标签，必须映射为可执行的网络身份：

• K8s场景下，每个Tenant对应独立Namespace，且该Namespace绑定NetworkPolicy，只允许来自同租户Ingress或指定ServiceAccount的流量
• YARN场景下，租户提交任务时必须指定Queue，而Queue底层绑定Linux cgroups + TC限流 + HDFS Quota，实现计算、网络、存储三重隔离
• 容器运行时（如containerd）启用CNI插件（如Calico或Cilium），支持基于租户标签的细粒度网络策略，例如“只允许tenant-b的订单服务调用tenant-b的支付服务”

运维与审计通道必须独立于业务私网

监控、日志、备份、灾备等运维通道，严禁复用业务私网。否则一个租户的网络风暴或配置错误可能瘫痪全平台可观测能力：

• 为运维通道单独建设管理网段（如172.20.0.0/16），所有节点部署双网卡：一张接入业务私网，一张接入管理网
• 各租户的Prometheus采集器、Filebeat日志代理、pg_dump备份脚本，均通过管理网卡上报，避免与业务流量争抢带宽
• 审计日志（如API调用记录、SQL改写日志）必须落盘到租户不可见的中央审计库，且该库只开放给安全团队专用账号