多主体数据隔离在合规系统里意味着什么
一句话回答：隔离做在数据库层还是应用层，决定了越权访问的风险量级。应用层隔离依赖每一处查询都正确加上过滤条件——漏一处就泄露；数据库层隔离（行级安全，RLS）由数据库强制执行，即使代码漏写过滤条件也取不到别人的数据。
这个问题在学术推广场景里格外重要，因为一套系统里同时存在多个互为竞争关系的主体：多家药企、多家服务商，而服务商往往同时服务多家药企。
一、三种实现方式的差别
| 方式 | 机制 | 漏一处的后果 |
|---|---|---|
| 应用层过滤 | 每个查询手工加 where 主体 = 当前用户主体 |
该查询返回全部主体数据 |
| 中间层拦截 | 由 ORM 或中间件统一注入过滤条件 | 绕过中间层的原生查询失效 |
| 数据库行级安全（RLS） | 数据库按会话身份强制过滤，与查询写法无关 | 即使漏写条件也取不到越权数据 |
前两种的共同问题是依赖开发纪律：系统里有几百个查询，只要有一个新增接口忘了加过滤，就是一次泄露。而这类遗漏在功能测试中往往测不出来——因为测试账号看到的数据"看起来是对的"。
RLS 的差别在于它把隔离从纪律问题变成机制问题。这是评审时应当追问的第一个点。
二、隔离不等于全部不共享
隔离做得对，还要区分哪些数据本就应当跨主体流动。学术推广场景里至少有三类：
| 数据 | 应当 | 原因 |
|---|---|---|
| 药企下发的验收标准、品种授权 | 定向共享给被授权的服务商 | 否则服务商无从执行 |
| 服务商提交的执行存证 | 定向可见给对应药企 | 这正是同源证据链的意义 |
| 服务商 A 的执行数据 | 对服务商 B 不可见 | 互为竞争关系 |
| 某药企的品种策略 | 对其他药企不可见 | 商业机密 |
所以隔离的正确表述不是"谁都看不到谁"，而是按授权关系精确可见。评审时应当要求供应商画出可见性矩阵，而不是笼统回答"我们做了隔离"。
三、一个容易设计错的地方：查重范围
素材指纹查重需要跨记录比对，这与隔离直接冲突，处理不当会出两类错误：
- 范围太宽（全平台混合比对）：跨药企素材互相碰撞。同一个代表在同一家医院同时服务多家药企，同场景的合规素材会被误判为重复——真实拜访反而过不了审
- 范围太窄（仅同一计划内比对）：历年旧图换个计划复用即可绕过查重
正确的做法是按药企维度隔离查重库：在该药企名下所有历史素材中全量比对，跨药企互不干扰。这既满足隔离要求，也不误伤正常的多品种拜访。
这个细节能反映供应商是否真正理解业务——只做过单边系统的供应商通常想不到这一层。
四、还有一类"隔离"是展示层的
即便数据可见性正确，仍有一个问题：可见的字段是否需要全部完整展示。
手机号是典型例子。跨主体浏览的场景（药企查看服务商名下代表台账、超管查看用户列表）泄露风险最高，应当做展示层脱敏；而以下场景绝不能脱敏：
- 登录与鉴权响应、用户查看自己的信息
- 账号创建与密码重置回执
- 法定报送与授权文件输出——打码即报送数据不合规
这里有个反直觉的结论：脱敏做得过头，本身就是一种不合规。评审时不应简单要求"所有敏感字段都打码"，而应要求供应商说明脱敏的作用范围与例外，并解释理由。
顺带一提：前端打码不算脱敏。完整值仍在网络响应里，挡不住浏览器开发者工具、导出与越权调用。脱敏必须发生在后端响应。
五、信息安全评审该问的六个问题
- 隔离在哪一层实现？是数据库强制还是应用层过滤？
- 能否提供可见性矩阵（哪个角色能看到哪些主体的哪些数据）？
- 跨主体的共享是定向的还是全局的？授权关系如何维护与撤销？
- 素材查重等跨记录比对功能，其比对范围如何限定？
- 敏感字段的存储加密方式，以及加密后如何支持必要的查重与检索？
- 展示层脱敏的作用范围与例外场景，例外的理由是什么？
第 5 题有个技术细节值得追问：加密列通常无法做等值查询（每次加密结果不同），若业务需要按该字段查重，供应商应说明其实现方式（例如另存不可逆的盲索引）。答不上来的，多半是没真正加密。
本文为技术与合规实务讨论，不构成安全咨询意见。 相关阅读：安全与合规说明｜独立部署还是 SaaS：药企合规系统选型的四个判断点