📚 课程目录第4章租户隔离原则

租户隔离原则：逻辑隔离、物理隔离、加密隔离在日志中的应用

说起来挺有意思的。做了这么多年安全，每次跟客户聊租户隔离，大家第一反应都是「把数据分开存不就行了？」。嗯，想法没错，但真落到日志系统里，事情就没那么简单了。

日志数据有个特点——它一直在产生，量还特别大。你想想看，如果每个租户都搞一套独立的日志管道，那成本谁受得了？所以我们在设计多租户日志系统时，通常会考虑三个层面的隔离策略：逻辑隔离、物理隔离和加密隔离。这三种方式不是互斥的，而是互补的。我记得有一次做金融级项目，三种都用上了。

好了，我一个个说。

逻辑隔离：成本最低的默认方案

逻辑隔离，说白了就是在同一套基础设施里，通过软件层面的机制把不同租户的数据「隔开」。它不增加硬件成本，但依赖你的代码和配置够不够严谨。

我常用的逻辑隔离手段有这三种：

命名空间隔离：每个租户分配独立的索引/表/桶前缀。比如 Elasticsearch 用 tenant-{id}-logs-{date} 这样的索引命名模式，查询时强制带上租户 ID 过滤。
权限模型隔离：用 RBAC（基于角色的访问控制）或 ABAC（基于属性的访问控制）来限制跨租户数据访问。我在项目中见过最粗心的配置——给所有租户共用一个 Service Account，那跟没隔离一样。
数据分区隔离：在数据库层面按租户 ID 做分区，比如 ClickHouse 的 PARTITION BY tenant_id。这样查询时直接走分区裁剪，既安全又提升性能。

实践建议：逻辑隔离一定要做「默认拒绝」策略。我习惯在网关层统一注入租户上下文，任何未携带有效租户标识的请求直接拦截，不要在应用层做二次判断。

但逻辑隔离有个硬伤——如果底层有越权漏洞，比如 SQL 注入或者索引数据跨分片查询，数据还是会泄露。所以它不能单独用在合规要求严格的场景下。

物理隔离：用硬件换安心

物理隔离就比较好理解了——每个租户用独立的服务器、独立的存储、独立的网络。钱到位了，隔离就简单了。

不过现实中很少有人会为每个小租户单独部署一套日志集群，那太奢侈了。我遇到过的物理隔离场景主要有两种：

专有基础设施：给高安全需求的租户分配单独的日志节点或集群。比如金融客户要求日志数据不能跟其他租户混在同一块 SSD 上，那就划一批专用节点。
独立实例部署：为每个租户启动独立的日志服务实例（比如单独的 Fluentd 或 Logstash 管道），各自有独立的缓冲区和处理线程。

隔离方式	适用场景	成本	安全等级
逻辑隔离	中小型租户、SaaS 标准化服务	低（软件层面）	中等，依赖代码健壮性
物理隔离	高安全/高合规客户（如金融、政府）	高（硬件+运维）	高，硬件级隔离
加密隔离	必须确保数据即使被窃取也无法读取	中（密钥管理成本）	极高，数学级保障

我曾经遇到一个客户，他们内部审计要求日志数据「物理分离于任何可能被其他租户访问的介质」。最后我们用了独立 NFS 挂载点+专用日志代理节点，虽然运维麻烦，但审计一次过。

物理隔离的代价很明显：扩展性差、资源利用率低、运维复杂度高。如果你有 1000 个租户都走物理隔离，光管理 SSH 密钥和监控告警就能让人崩溃。

加密隔离：最后一道防线

加密隔离，有的人也叫它「密码学隔离」。它的核心思路是：不管数据存在哪、流经哪些系统，只要密钥不泄露，其他租户（甚至平台管理员）都无法读取你的日志内容。

常见做法分两个层面：

传输加密：所有日志管道走 TLS/mTLS，日志代理到收集器之间做双向证书认证。这没什么好说的，现在基本是标配。

存储加密：这里就有讲究了。我比较推荐的是字段级加密，而不是简单的全盘加密。为什么？

全盘加密只能防硬盘被偷，阻挡不了平台管理员直接读数据库文件
字段级加密可以只加密敏感字段（如用户 ID、IP、交易金额），其他字段保持明文方便检索


// 字段级加密示例（简化逻辑）
const encryptedLog = {
  timestamp: Date.now(),
  level: "INFO",
  tenant_id: "tenant_abc123",          // 未加密，用作分区
  message: encryptAES("用户登录"),       // 业务描述加密
  client_ip: encryptAES("192.168.1.1"), // 敏感字段加密
};

注意：字段级加密会破坏全文检索能力。如果你需要按日志内容搜索，得搭配加密搜索方案（如 AES-SIV 或安全 MPC），或者只在明文上做预索引，加密存原始值。我踩过这个坑——客户非要查关键词，结果加密后的数据没法搜，最后搞了一套双写方案才解决。

加密隔离最大的风险是密钥管理。每个租户的密钥怎么生成、怎么轮换、怎么在服务重启后恢复？我曾经见过一个团队把所有租户的密钥写死在配置文件里，那跟没加密有什么区别？

我的经验是：用 Key Management Service（KMS）来管理密钥，每个租户一个 Key ID，日志代理只拿加密后的密钥密文，解密动作放在内存里定期刷新。

三种隔离如何选型

来来来，我画了一张图，把这三种隔离的关系和适用逻辑说清楚。

你看这张图就清楚了。三种隔离不是非此即彼的三个选项，而是可以叠加的。我个人习惯的做法是：默认逻辑隔离 + 传输加密，针对高安全租户叠加字段级加密，只有合规强制要求或客户明确出钱买专属资源时，才走物理隔离。

别忘了密钥管理：如果你选了加密隔离，一定要设计好密钥生命周期。我见过最典型的翻车现场——加密用的密钥 3 年没换过，管理员离职后密钥文件找不到了，结果整个租户的日志解密失败。嗯，那就是灾难。

最后说一句，隔离方案没有银弹。你设计的时候一定要想清楚：你的威胁模型是什么？是防外部攻击、防租户互访、还是防平台管理员？不同假设下，三种隔离的权重完全不同。