图数据库的权限管理能做到多细？多租户与数据隔离方案

权限申请单上写着「研发组需要读生产图库」，批了。三个月后审计抽查，这个账号能查到客户的身份证号和手机号。没有人故意放权，问题出在权限只做到了「库」这一层：库里面所有的点、边、属性一起给了，而这张图里同时存着不敏感的订单数据和敏感的实名信息。图数据库的权限管理，难点几乎都藏在这类「库里面」的细节里。

同类事故在关系型数据库时代也有，但图数据库更容易踩。原因不是产品做得粗，是图的形状本身让权限变复杂了——权限判定的单位从「一行」变成了「一条路径」，而路径会跨过多个主体。

一、六个可以卡的口子，多数项目只用了两个

图数据库的权限粒度不是一个开关，是一组从粗到细的层。每一层的实现成本差一个台阶。

层级	控制什么	典型用途	落地成本
集群与实例	能不能连上	环境隔离、生产与测试分开	低
图空间	能不能进这个库	多业务线、多租户	低
点与边的类型	能读写哪类实体和关系	按主题域授权	中
属性	能看见哪些字段	身份证号、手机号、金额	中高
具体元素	能看见哪几条点、哪几条边	按数据归属或密级	高
操作类型	能做什么动作、能走多深	防批量导出、限遍历跳数	高

前两层在管理后台点几下就有，所以绝大多数项目停在这里。这不是技术选择，是成本选择——从第三层起，每一层都需要应用侧配合改造，改的是权限模型，动的是业务代码。

这里必须单独拎出一条判断：「能不能看见某个点」和「能不能顺着边走到它」是两回事。

前五层管的是前者，第六层管的是后者。而图数据库最有价值的能力恰好是后者——一个你本来不该看到的人，可以通过一条两跳路径被「走到」：从你认识的同事，走到他的配偶，再走到配偶名下的另一家公司。每一跳单看都合理，合起来就是一次越权访问。

所以只做元素级权限、不做遍历约束的方案，等于把后门留在了这个产品最擅长走路的那个功能上。这件事在表格里看不出来，只有真去构造路径才会暴露。

顺带说一句数据分级：属性级权限要落地，前提是先知道哪些属性算敏感。这套分级怎么做、按什么维度切，数据安全治理的核心理念里有比较完整的口径，本篇只谈拿到分级之后怎么把它变成权限策略。

二、RBAC 管资格，ABAC 管这一次，顺序不能反

两种模型不是互相替代的关系，分工很清楚。

RBAC 是角色到权限的映射，回答「你有没有资格」。它的好处是稳定、好解释、好审计：出了事能指着角色说，是这个角色带了这条权限。

ABAC 是属性到策略的判定，回答「这一次允不允许」。它把时间、部门、数据密级、访问者所属租户、甚至访问目的都变成条件，能表达 RBAC 表达不了的动态约束。

两种模型的差别，摊开看是一张表。

维度	RBAC	ABAC
判定依据	角色	属性与上下文
回答的问题	有没有资格	这一次允不允许
稳定性	高，人员变动不常改	低，条件随业务变化
可解释性	好，能指着角色说清	差，要逐条看策略
策略数量	与角色数同阶	与条件组合数同阶
典型失效	角色爆炸	策略不可读、排障困难

两层叠在一起时，判定顺序必须先 RBAC 后 ABAC：先用角色筛掉没资格的人，再用属性判这一次的上下文。顺序反了会出两种问题。一是策略数量爆炸——把「研发组」这种相对稳定的角色关系也写成属性条件，条件数会随人数线性增长，最后没人说得清哪些策略在生效。二是排障困难——一条查询被拒，你不知道是角色没给，还是某条属性策略拦的。

全用一种模型也有各自的死法。全 RBAC：遇到「同一个角色，但只能看本部门的低密级数据」就无解，只能不停拆角色，最后角色数量上千，谁也不敢删。全 ABAC：表达能力是够了，但可读性崩塌，半年后没人敢改策略。

权限模型从静态走向动态这件事，行业里已经讨论得比较透，零信任架构下的动态权限管理给过一套把风险上下文接进判定的思路，可以当作 ABAC 那一层的参考实现。本篇关注的是另一半问题：判定通过了，数据本身怎么隔开。

三、多租户三条路线，隔离强度看的是「错一次会怎样」

同一套集群上放多个租户，有三种做法，成本差得很远。

方案	怎么做	隔离强度	主要成本	适合
逻辑隔离	同一图空间，靠租户标识属性加策略过滤	最弱	最低	租户多、数据量小、互不敏感
库级隔离	每租户一个图空间，共用集群资源	中	中	大多数 SaaS 场景
物理隔离	独立集群或独立存储	最强	最高	金融、政务、强监管

选哪条，容易只看数据量和技术偏好，真正该看的是一个更朴素的问题：这个方案错一次，后果是什么。

逻辑隔离的风险不在性能，在容错。它把「不串数据」这件事托付给了每一条查询的条件拼接——只要有一条查询忘了带租户过滤，就会返回别人的数据，而且不报错、不告警，结果集看起来完全正常，只是多了一部分。这类缺陷在上线前的测试里几乎抓不到，因为测试环境通常只有一个租户，串不到任何东西。

库级隔离把这个风险降了一个量级：跨库访问需要显式授权，忘了写条件最多是查不到，而不是查多了。物理隔离再降一级：策略写错也串不了，因为数据根本不在同一套存储上。

但物理隔离有个图特有的代价，值得单独说。关系是跨租户天然存在的——同一个人在集团和子公司各有一个账户，同一台设备在两条业务线都出现过。一旦按租户拆成独立集群，「全局关系视图」就消失了，而这张视图往往正是当初上图的原因。

真实项目里更常见的做法是混合：底层按监管要求物理或库级隔离，上层另建一套脱敏后的共享视图专门做跨租户分析。合规和洞察各拿一半，代价是要多维护一条数据链路。

四、加密和审计：两件常被当成合规附件的事，其实决定权限能不能查清

先说加密，因为它最容易被拿来当权限的替代品。

传输层用 TLS、存储层用 AES-256，这两件事解决的是「介质被拿走」——磁盘被拆走、备份文件被拷出去、链路被监听。它不解决「有正当账号的人看了不该看的数据」。这两类风险经常被混在一句话里讲，讲完就以为安全做完了。

加密保的是数据在静止和传输时的形态，权限保的是数据在被正常访问时的范围。 一个内部人员用合法账号越权查询，加密在这里一点作用都没有，能拦住他的只有权限和审计。

审计日志则是另一回事，而且图数据库的审计做法和关系型差别很大。

关系型记一条 SELECT 语句就够了，因为它的影响范围是一张表里的若干行，事后照着语句重放能大致还原看了什么。图不一样：一条三跳遍历语句可能触达几十万个点，日志里记结果集是不现实的，记语句又还原不出范围。

可行的做法是记「查询模板加边界条件」：起点是什么、跳数上限多少、带了哪些过滤、返回了多少条。这四样记全，事后能回答审计真正想问的三个问题——谁、在什么时候、通过哪条路径看到了哪些点。第三问是图特有的，也是最容易缺的一环。很多系统的审计只能还原到「执行了什么语句」，一旦被问到「所以他到底看到了谁」，就只能回答「理论上应该只有这些」。

五、五道检查，能筛掉大部分「看起来做了权限」的方案

验收时不看配置界面，看五个具体动作能不能挡住。

检查动作	期望结果	挡不住说明什么
用只有 A 租户权限的账号，构造一条已知的跨租户两跳路径	返回空或报错，不得返回 B 租户数据	只做了元素级权限，没做遍历约束
收回某敏感属性的读权限，调接口取该属性	返回空值、脱敏值或明确报错，三种都可接受	权限只做在页面上，接口层没拦
用 6 跳查询打一次深度限制	在服务端被拦住	深度限制只写在前端，改个参数就绕过
用一个有读权限但没有导出权限的账号，调批量导出	被拒	读权限与导出权限没分开，等于给了一把万能钥匙
随机挑昨天的一次查询，要求还原「谁看了哪些点」	能答出来	审计只记了语句，没记边界条件

第五条最有杀伤力。它不需要任何攻击技巧，只是把审计日志拿出来问一句，就能看出这套权限体系有没有真正闭环。

第五行那条还要再强调一层：读权限和导出权限必须是两个位。 能看一百条和能拿走一百万条，是完全不同的两件事，但在很多系统里它们是同一个开关。一旦打开，前四道检查做得再好也没意义——数据已经出去了。

六、两个误区，和一条不会返工的落地顺序

第一个误区：把权限做在应用层就够了。 应用层能挡住正常入口，挡不住直连客户端、挡不住 BI 工具、挡不住运维账号、也挡不住任何一个拿到连接串的人。数据库权限是最后一道，也是唯一一道不依赖调用方自觉的。

第二个误区：权限配好一次就不用管了。 权限会腐化，而且腐化得很安静：人员调岗、项目合并、临时授权忘了回收、离职账号没停。半年后一张权限表能查出十几处对不上的地方。解决办法不是定期人工核对，是给临时授权设过期时间——靠人记的事情，一定会有遗漏。

落地顺序建议按这个走，反了会返工：

先定数据分级，知道哪些属性敏感、哪些点属于哪个租户；
再定隔离层级，按「错一次的后果」选逻辑、库级还是物理；
然后配角色，把稳定的结构性授权交给 RBAC；
最后收遍历深度与导出权限，把能绕过前三层的那两个口子堵上。

这个顺序的逻辑是：前面的决定后面的。 分级没定就配角色，角色一定配不准；隔离没定就做策略，策略写在哪一层都不对。

悦数图数据库在权限这一层提供的能力是 RBAC 加 ABAC 双层控制，配合多租户、多业务组与配额管理；审计日志完整且不可篡改；链路加密采用 TLS，存储加密采用 AES-256；同时支持离线私有化部署，满足金融、政务场景对数据不出域的要求。这些能力怎么组合，仍然取决于前面那四步——能力清单解决「能不能做」，落地顺序决定「做得对不对」。

权限做到多细，最后不由技术能力决定，由能承受多少运维成本决定。每往细走一层，策略数量和维护成本就上一个台阶；而停在哪一层，取决于一旦漏掉这一层，损失有多大。

相关阅读

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边的规模承担关系数据的存储与查询。产品在权限侧提供 RBAC 与 ABAC 双层控制，配合多租户、多业务组与配额管理；安全侧提供 TLS 链路加密与 AES-256 存储加密、不可篡改的完整审计日志，并支持离线私有化部署。

Q2：多租户一定要做物理隔离吗？库级隔离够不够？

A：看两件事：数据敏感到什么程度，以及监管有没有明确要求数据不出某个边界。多数 SaaS 场景库级隔离就够用——每租户一个图空间共用集群资源，跨库访问需要显式授权，忘记写条件的结果是查不到而不是查多了。金融、政务这类场景如果涉及个人敏感信息或跨主体数据，物理隔离更稳妥，但要接受全局关系视图消失的代价，通常还得在上层另建一套脱敏共享视图补回分析能力。判断标准可以简化成一句：这个方案错一次，最坏结果是查到多余数据，还是数据出了边界。

Q3：悦数图数据库在安全资质与认证方面有哪些？

A：体系认证方面，悦数已通过 ISO27001 信息安全管理体系与 ISO9001 质量管理体系认证，并通过 CMMI3 评估；信创适配方面拥有华为鲲鹏、欧拉 OS 等认证，配合统信、麒麟、中科可控等国产软硬件环境形成全栈适配能力。市场与行业侧，IDC《中国图数据库市场概览 2024》中位列中国市场第二位，并连续两年入选中国信通院图数据库「领航者」。资质证明的是体系与流程到位，具体到某个项目的权限方案是否够细，仍然要按第五节那五道检查逐条验一次。