2、多租户架构基础：SaaS多租户模型、数据隔离模式与租户身份标识
多租户（Multi-Tenancy）是SaaS可观测性系统的核心架构属性。它允许一个软件实例同时服务多个租户（组织、团队或客户），同时确保每个租户只能访问自己的数据与配置。理解多租户模型、数据隔离策略以及租户身份标识机制，是进行安全评估与RBAC设计的前提。
2.1 SaaS多租户模型
根据租户共享资源的粒度与隔离程度，SaaS多租户模型主要分为三种。下表从资源隔离、运维成本、安全边界三个维度进行对比：
| 模型 | 资源隔离 | 运维成本 | 安全边界 | 典型场景 |
|---|---|---|---|---|
| 单租户（Single-Tenant） | 每个租户独享一套完整实例（计算+存储） | 高（独立部署、升级、监控） | 物理/虚拟级隔离，安全性最高 | 金融、政府、合规要求极高的客户 |
| 纯共享（Shared Multi-Tenant） | 所有租户共享同一套应用与数据库实例 | 低（统一运维、弹性扩缩） | 逻辑隔离，依赖应用层权限控制 | 中小型SaaS、内部工具、POC环境 |
| 混合模型（Hybrid Multi-Tenant） | 部分组件共享（如计算层），关键数据独享 | 中（需编排调度） | 按数据敏感度分层隔离 | 大型SaaS、可观测性平台、数据仓库 |
安全评估要点： 在可观测性系统中，纯共享模型最容易出现“跨租户数据泄露”风险。如果日志、指标、链路数据的查询接口未严格校验租户ID，一个租户可能通过修改请求参数查看到其他租户的敏感数据。建议在架构选型时优先考虑混合模型，将元数据与热数据共享，冷数据与审计日志独享。
2.2 数据隔离模式
数据隔离是多租户架构中最关键的安全设计决策。根据数据存储层的实现方式，可分为以下三种模式：
- 共享数据库 + 共享Schema（Shared DB, Shared Schema）
所有租户的数据存放在同一张表中，通过tenant_id列进行逻辑区分。优点是资源利用率高、运维简单；缺点是隔离性最弱，一旦SQL注入或查询遗漏租户过滤条件，将导致全局数据泄露。 - 共享数据库 + 独享Schema（Shared DB, Separate Schema）
每个租户拥有独立的Schema（或表空间），但共用同一个数据库实例。隔离性优于共享表，但仍存在数据库实例级别的风险（如连接数耗尽、慢查询影响全局）。 - 独享数据库（Separate DB）
每个租户拥有独立的数据库实例。隔离性最强，但资源开销与运维复杂度最高，适合高合规场景。
以下SVG图展示了三种数据隔离模式的架构对比：
2.3 租户身份标识
在多租户系统中，租户身份标识（Tenant Identity）是贯穿所有请求与数据访问的核心上下文。它决定了“当前请求属于哪个租户”，是实施数据隔离与RBAC策略的基础。
2.3.1 标识方式
- 请求路径/域名标识：通过URL路径前缀（如
/tenant-a/api/v1/metrics）或子域名（如tenant-a.observability.io）区分租户。优点是直观、易于负载均衡；缺点是租户信息暴露在URL中，需防止路径遍历攻击。 - HTTP Header标识：在请求头中携带自定义Header（如
X-Tenant-ID: tenant-a）。优点是灵活、不污染URL；缺点是需确保Header在网关与后端服务间正确传递，防止被篡改。 - JWT Token声明：在JWT的payload中包含
tenant_id声明。优点是安全、防篡改，且可同时携带角色、权限等上下文；缺点是Token需定期刷新，且解析开销略高。
2.3.2 标识传递与校验流程
以下SVG图展示了租户身份标识在可观测性系统请求链路中的传递与校验流程：
2.3.3 安全最佳实践
- 禁止客户端直接指定租户：租户身份必须由服务端根据认证信息（如JWT中的
tenant_id）推导，而非从请求参数或Header中直接读取。 - 租户上下文传递：在微服务架构中，使用gRPC Metadata或HTTP Header（如
X-Tenant-ID）在服务间传递租户上下文，确保所有下游服务都能感知当前租户。 - 租户隔离审计：在数据访问层记录每次查询的
tenant_id，用于事后审计与异常检测。
常见陷阱： 在可观测性系统中，聚合查询（如“全局告警统计”）容易忽略租户过滤。如果管理员或跨租户报表功能未正确限定
tenant_id范围，可能导致一个租户的运维人员看到所有租户的指标数据。建议对跨租户查询单独设置审批流程与审计日志。