4. 多租户数据隔离模型：独立数据库模式、共享数据库独立Schema模式、共享数据库共享Schema模式

在多租户签名链路中，数据隔离是决定租户安全边界与运营成本的核心设计决策。不同的隔离模型直接影响密钥存储、签名日志审计、性能隔离以及租户间的故障域。业界主流的多租户数据隔离模型可归纳为以下三种模式：

4.1 独立数据库模式（Database per Tenant）

每个租户拥有完全独立的数据库实例（或独立的数据库服务）。在签名链路中，租户的密钥表、证书链、签名日志、审计记录均存储在专属数据库中。

• 优势：最强的数据隔离与故障隔离；一个租户的数据库故障不影响其他租户；备份与恢复可针对单个租户执行；满足PCI-DSS、GDPR等严格合规要求。
• 劣势：资源利用率低（每个租户需预留独立连接池与存储）；运维成本随租户数量线性增长；跨租户全局查询（如全平台签名量统计）需要聚合层。
• 签名链路适配：签名服务启动时根据租户标识动态路由到对应数据库；密钥材料与签名日志严格按库隔离。

4.2 共享数据库独立Schema模式（Shared Database, Separate Schemas）

所有租户共享同一个数据库实例，但每个租户拥有独立的数据库Schema（如 tenant_a_keys、tenant_b_keys）。Schema是数据库内部的命名空间隔离单元。

• 优势：资源利用率高于独立数据库模式；仍保持较好的逻辑隔离；支持跨租户查询（通过Schema前缀）；运维成本低于独立数据库模式。
• 劣势：数据库实例级别的故障会影响所有租户；连接池共享，一个租户的慢查询可能影响其他租户；Schema数量过多时管理复杂。
• 签名链路适配：签名服务在建立数据库连接后，通过 SET search_path TO tenant_schema（PostgreSQL）或 USE database_tenant（MySQL）切换Schema上下文。

4.3 共享数据库共享Schema模式（Shared Database, Shared Schema）

所有租户的数据存储在同一个数据库实例的同一个Schema中，通过行级字段（如 tenant_id）来区分数据归属。这是最经济但隔离性最弱的模式。

• 优势：资源利用率最高；运维最简单（单库单表）；跨租户聚合查询最方便；适合租户数量极大但数据量小的场景。
• 劣势：隔离性最弱（依赖应用层SQL过滤）；一个租户的恶意查询或错误更新可能影响全局数据；备份恢复无法按租户粒度执行；审计追溯需要依赖 tenant_id 字段。
• 签名链路适配：所有签名密钥表、日志表均包含 tenant_id 列；签名服务在每次查询时强制附加 WHERE tenant_id = ? 条件；必须使用行级安全策略（RLS）作为防御层。

4.4 三种模式的对比决策矩阵

4.5 签名链路中的模式选择建议

在签名链路中，数据隔离模型的选择应遵循以下优先级原则：

1. 合规优先：如果租户涉及金融、政务、医疗等高合规行业，强制使用独立数据库模式，确保审计与数据主权满足监管要求。
2. 性能与成本平衡：对于企业级SaaS签名平台，推荐共享数据库独立Schema模式，在隔离性与资源效率之间取得最佳平衡。
3. 轻量级内部服务：仅当签名链路用于低风险场景（如内部文档签名、测试环境）时，才考虑共享Schema模式，且必须启用行级安全策略。
4. 混合策略：大型签名平台可采用混合模式——高安全租户使用独立数据库，普通租户使用独立Schema，通过统一的路由层透明切换。