2. 多租户架构基础：租户隔离模型、数据隔离策略与身份权限管理
在多租户签名链路中，租户隔离是安全与合规的基石。不同的隔离模型决定了流水线如何分配计算资源、存储签名密钥以及执行身份校验。本章从 SaaS 与 PaaS 两种交付模式出发，系统梳理隔离模型、数据策略与权限基础。
2.1 租户隔离模型：SaaS vs PaaS
多租户架构的核心差异在于共享层与隔离边界的位置。SaaS 模式下，服务商管理整个应用栈，租户共享实例但逻辑隔离；PaaS 模式下，租户拥有独立的运行时环境或容器，隔离粒度更粗。
| 维度 | SaaS 多租户 | PaaS 多租户 |
|---|---|---|
| 隔离粒度 | 应用层逻辑隔离（租户 ID 路由） | 进程/容器级隔离（独立 Pod 或 VM） |
| 资源共享 | 共享数据库、应用实例 | 共享集群管理面，数据面独立 |
| 签名链路影响 | 密钥存储需按租户分区，HSM 共享 | 每个租户可挂载独立 HSM 或 KMS 密钥 |
| 流水线集成 | CI/CD 中注入租户上下文变量 | CI/CD 按租户触发独立构建环境 |
| 典型场景 | 电子合同平台、统一签名网关 | 金融级签名服务、私有化部署 |
实践建议：签名链路对密钥隔离要求极高，即使采用 SaaS 模型，也建议将租户密钥存储与签名计算分离——使用租户专属密钥槽（Key Slot）而非仅靠应用层路由。
2.2 数据隔离策略
数据隔离直接影响签名链路中待签文档、签名证书与审计日志的存储方式。常见策略包括：
- 独立数据库（Database per Tenant）：隔离性最强，适合金融、政务等高合规场景；但运维成本高，不适合超大规模租户。
- 共享数据库 + 独立 Schema：每个租户拥有独立表空间，查询天然隔离；适合中型 SaaS 平台。
- 共享数据库 + 租户 ID 列：所有租户数据混存，通过
tenant_id字段路由；成本最低，但需严防 SQL 注入与越权查询。 - 混合策略：敏感数据（如私钥、证书）使用独立存储，非敏感数据（如签名模板、配置）共享。
| 策略 | 隔离强度 | 签名链路适用性 | 流水线测试要点 |
|---|---|---|---|
| 独立数据库 | ★★★★★ | 私钥、审计日志 | 验证跨库查询隔离，测试连接池泄漏 |
| 独立 Schema | ★★★★☆ | 签名请求、证书链 | Schema 迁移自动化，租户级回滚 |
| 租户 ID 列 | ★★★☆☆ | 签名模板、配置 | 强制注入 tenant_id 过滤，模糊测试 |
| 混合策略 | ★★★★☆ | 全链路（按敏感度分级） | 数据分类标签驱动测试用例 |
关键风险：在共享数据库 + 租户 ID 列模式下，签名私钥绝不能与非敏感数据混存。即使应用层做了过滤，一旦发生 SQL 注入或 ORM 映射错误，可能导致租户 A 使用租户 B 的私钥签名——这是合规灾难。
2.3 身份与权限管理基础
多租户签名链路的身份模型通常采用三层主体结构：
- 平台管理员：管理租户生命周期、全局策略、审计。
- 租户管理员：管理本租户内的用户、角色、签名密钥。
- 签名操作员：执行签名请求，受租户级 RBAC 约束。
权限模型推荐使用 RBAC（基于角色的访问控制） 结合 ABAC（基于属性的访问控制） 的混合方案：
- RBAC：定义“签名者”、“审核者”、“审计员”等角色，每个角色绑定一组操作权限。
- ABAC：在签名链路中增加属性约束，例如“仅允许在工作时间签名”、“仅允许对
contracts/路径下的文档签名”。 - 租户上下文：所有权限判断必须携带
tenant_id，防止跨租户越权。
2.4 流水线中的隔离验证要点
在 CI/CD 流水线中，多租户隔离的正确性必须通过自动化测试持续验证。以下是关键测试维度：
- 数据隔离测试：使用租户 A 的令牌查询，不应返回租户 B 的签名记录或密钥元数据。
- 权限越权测试：租户 A 的操作员尝试使用租户 B 的签名密钥，应被明确拒绝并记录审计事件。
- 密钥隔离测试：验证每个租户的签名密钥在 HSM/KMS 中是否位于独立槽位或独立密钥空间。
- 资源配额测试：PaaS 模式下，验证租户 A 的签名请求不会耗尽租户 B 的容器资源。
流水线集成建议：在 CI 阶段为每个租户创建独立的测试数据库或 Schema，运行隔离性测试套件；在 CD 阶段使用金丝雀发布，先验证单个租户的签名链路，再逐步扩至全量租户。