全宗隔离机制设计原理：构建多租户档案系统的安全基石

对于集团型企业和档案服务商而言，如何在同一套系统中安全、合规地管理多个独立单位（全宗）的档案数据，是系统架构设计的重中之重。本文将揭秘 数凭电子会计档案 的全宗隔离机制。

---

一、 什么是“全宗”？

1.1 背景与定义

在档案学中，“全宗”（Fonds）是一个单位在其职能活动中形成的档案总和。对于大型集团企业，其下属的每一个独立法人单位就是一个全宗。

1.2 为什么需要全宗隔离？

• 合规要求：根据《档案法》，不同全宗的档案应保持其独立性和原始面貌。
• 数据安全：子公司 A 的档案人员绝对不能跨权限看到子公司 B 的敏感财务数据。
• 管理便利：支持独立的档案号生成规则、独立的分类方案。

---

二、 全宗隔离的三种技术方案

在 数凭电子会计档案 架构中，我们支持从逻辑到物理的不同级别的全宗隔离。

2.1 方案 A：逻辑隔离（共享数据库，按全宗 ID 过滤）

最常用的轻量化方案。所有全宗数据存放在同一张表中，通过 fonds_id 字段区分。

技术实现： 利用 MyBatis-Plus 或 Hibernate 的多租户拦截器，自动在每一条 SQL 查询中注入全宗过滤条件：

SELECT * FROM archive_file WHERE fonds_id = 'FONDS_001' AND ...

2.2 方案 B：Schema 级别隔离（共享数据库，独立 Schema）

每个全宗拥有独立的数据库 Schema。

优势：

• 安全性更高：在数据库层面提供了访问隔离。
• 扩展性好：支持针对特定全宗进行独立的索引优化。

2.3 方案 C：物理隔离（完全独立的数据库）

面向敏感度极高的核心单位或涉密全宗。

---

三、 数凭电子会计档案 的“全动态隔离”架构

我们采用了一种灵活的架构，支持按需配置全宗的存储与计算隔离。

3.1 动态数据源路由 (Dynamic DataSource Routing)

系统核心框架通过 ThreadLocal 存储当前请求所属的全宗上下文，并动态切换底层数据源连接池。

public class DynamicDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return FondsContextHolder.getFondsId(); // 动态返回当前全宗ID
    }
}

3.2 附件存储的物理路径隔离

不仅数据库要隔离，二进制原件的存储路径也必须严格隔离。数凭电子会计档案 为每个全宗分配独立的存储前缀和密钥（Secret Key）。

/data/archives/
  ├── FONDS_A/ (采用 Key_A 加密)
  │     ├── 2024/03/voucher_001.pdf
  └── FONDS_B/ (采用 Key_B 加密)
        ├── 2024/03/voucher_456.pdf

---

四、 跨全宗操作的严苛管控

虽然全宗是隔离的，但在某些场景下（如集团审计），需要跨全宗查询。

1. 显式授权机制：默认禁止任何跨全宗操作，必须由最高管理员在安全员监督下显式授予“全局审计员”权限。
2. 穿透式审计日志：所有跨全宗查询操作都被记录在独立的全局审计库中，且标记为高危动作。

---

五、 全宗隔离对企业的价值

5.1 支持“云档案”中心化管理

集团公司可以建设一套中心化系统，各下属单位像使用“网盘”一样使用系统，但数据彼此隔离，既节省了 IT 成本，又保证了管控力。

5.2 灵活的系统扩容

通过隔离机制，当某个子公司的档案量激增时，IT 人员可以将其数据平滑迁移到独立的物理服务器上，而不影响其他全宗的正常运行。

---

六、 总结

全宗隔离机制是 数凭电子会计档案 区分于普通管理软件的分水岭。我们不仅在业务逻辑层面实现了全宗管理，更在底层的存储、计算、密钥管理等多个维度锁死了数据泄露的可能。这套架构不仅符合中国的档案合规标准，也满足了现代企业对大规模多租户系统安全性的严苛要求。

---

相关阅读：

• 三员分立权限管理设计
• AIP 档案信息包标准实现

了解更多：联系架构师深度交流