CI／CD多租户SaaS鉴权自动化测试 - 第1节
1.1 多租户 SaaS 定义与核心特征
多租户（Multi-Tenancy）是 SaaS 区别于传统软件最根本的架构属性。它允许一套软件实例同时服务多个租户（Tenant），每个租户在逻辑上相互隔离，但在物理上共享同一套基础设施与代码版本。
| 维度 | 传统单租户软件 | 多租户 SaaS |
|---|---|---|
| 部署方式 | 每客户独立部署一套实例 | 一套实例服务 N 个客户 |
| 运维成本 | 随客户数线性增长 | 边际成本趋近于零 |
| 版本管理 | 多版本并行，升级困难 | 单一主干，灰度发布 |
| 鉴权复杂度 | 仅需用户级认证 | 需叠加租户级路由与隔离 |
关键认知：多租户不是简单的"数据库加个 tenant_id 字段"，而是从网络层、应用层、数据层到 CI/CD 流水线都需要感知租户上下文的系统性架构。
1.2 租户隔离模型：共享 vs 独享
租户隔离模型决定了数据安全边界与资源成本之间的平衡。业界主流有三种模式，按隔离强度从低到高排列：
- 共享数据库 + 共享 Schema —— 所有租户数据存放在同一数据库的同一表中，通过 tenant_id 字段区分。成本最低，隔离最弱。
- 共享数据库 + 独立 Schema —— 每个租户拥有独立的 Schema（表结构相同），数据库实例共享。隔离性中等，适合中小规模。
- 独立数据库 —— 每个租户独占一个数据库实例。隔离性最强，成本最高，适合金融、医疗等强合规场景。
| 隔离模型 | 数据隔离强度 | 资源成本 | 运维复杂度 | 典型场景 |
|---|---|---|---|---|
| 共享 DB + 共享 Schema | 低 | 极低 | 低 | 内部工具、轻量协作 |
| 共享 DB + 独立 Schema | 中 | 中 | 中 | 通用 SaaS、CRM |
| 独立数据库 | 高 | 高 | 高 | 金融、医疗、合规 |
架构陷阱：很多团队初期选择"共享 Schema"以快速上线，后期发现租户数据泄露风险或备份恢复困难，再迁移到独立 Schema 或独立数据库，成本往往是重新开发的 3-5 倍。建议在架构选型阶段就确定隔离模型，并在 CI/CD 流水线中为每种模型设计对应的鉴权拦截测试用例。
1.3 SaaS 鉴权的核心挑战
多租户鉴权不是"用户登录 + 角色权限"的简单叠加。在 SaaS 架构中，鉴权链路必须解决以下四个核心挑战：
- 租户路由（Tenant Routing）： 请求到达时，系统必须能准确识别请求属于哪个租户。常见方式包括域名前缀、请求头 X-Tenant-ID、JWT 中的 tenant claim。
- 跨租户隔离（Cross-Tenant Isolation）： 必须防止租户 A 的用户通过修改参数、伪造 Token 等方式访问租户 B 的数据。这是 SaaS 安全红线。
- 租户级 RBAC（Tenant-Aware RBAC）： 同一用户在不同租户下可能拥有不同角色。例如张三在租户 A 是管理员，在租户 B 是普通成员。
- 鉴权链路的可测试性： 鉴权拦截逻辑通常嵌入在网关、中间件或 AOP 切面中，传统单元测试难以覆盖完整的租户上下文传递链路。
1.4 鉴权拦截链路在 CI/CD 中的位置
在传统单体应用中，鉴权逻辑通常散落在各个 Controller 中，测试覆盖依赖人工回归。而在多租户 SaaS 架构中，鉴权拦截链路是一条横跨网关、中间件、业务服务的完整请求处理管道，必须通过 CI/CD 流水线实现自动化验证。
实践建议：将鉴权拦截测试视为"安全冒烟测试"的一部分，在每次代码合并前自动运行。测试用例应覆盖：合法租户请求通过、非法租户请求拦截、跨租户越权尝试、租户 Token 过期/伪造等场景。
下表总结了鉴权拦截链路各层在 CI/CD 中的测试关注点：
| 链路层级 | 组件示例 | CI/CD 测试关注点 | 自动化工具 |
|---|---|---|---|
| 入口网关 | Kong / APISIX / Envoy | 租户路由规则、限流、IP 白名单 | Postman / Newman |
| 鉴权中间件 | Spring Security / OPA | JWT 校验、租户上下文注入 | JUnit / pytest |
| 业务服务 | 微服务 API | 数据级隔离、RBAC 策略 | 集成测试框架 |
| 数据层 | PostgreSQL / MongoDB | 租户级查询过滤、行级安全 | DBUnit / Testcontainers |
从本章开始，我们将逐步拆解如何在 CI/CD 流水线中构建这套自动化测试体系，确保每次发布都不会出现"租户 A 看到了租户 B 的数据"这类致命事故。