引言
图数据库的权限问题比关系库更微妙。关系库里「一张表」是天然的权限边界，而图里「一个节点」不是——你允许某人查 :Person 节点，他却能顺着 FRIEND 边一路走到你不想让他看到的 :SensitiveRecord；你给 :Person 的 name 属性开了读权限，但同一个节点上的 idCard 属性是敏感字段。更麻烦的是，图的价值恰恰在于「关系」，而关系本身就是信息：即便两个实体各自公开，它们之间「存在一条转账边」这件事本身可能就是机密。本文系统讲图数据库的访问控制与数据安全：先讲图安全的特殊挑战（关系即信息、权限沿边传播），再讲认证与角色模型、标签级与关系级权限、属性级脱敏与掩码、查询改写与行级过滤、多租户隔离、审计与合规、传输与静态加密、注入防护与查询安全，最后是实践清单与常见坑。目标：你能在共享图上建立一套「可验证、可审计、不靠应用层自觉」的权限边界。
目录
- 1. 图安全的特殊挑战
- 2. 认证与角色模型
- 3. 标签级与关系级权限
- 4. 属性级脱敏与掩码
- 5. 查询改写与行级过滤
- 6. 多租户隔离
- 7. 审计与合规
- 8. 传输与静态加密
- 9. 注入防护与查询安全
- 10. 实践清单与常见坑
- 速查表
- 延伸阅读
1. 图安全的特殊挑战
挑战一：关系即信息：
- 两个实体各自公开，但「它们之间存在一条边」本身可能是机密
- 例：员工 A 与竞争对手 B 之间存在通话边 → 边本身敏感
- 例：某账户与黑名单账户之间存在转账边 → 边本身敏感
→ 图里「边」是一等公民，权限必须覆盖边，而不只是点
挑战二：权限沿边传播：
- 给了 :Person 的读权限，就能顺着边走到所有可达节点
- 「允许读 A」+「允许读边」= 隐式允许读 A 的整个连通分量
- 关系库的「表边界」在图里不存在
→ 权限要按「可达性」而非「实体类型」思考
挑战三：路径泄露：
- 返回一条最短路径 = 泄露了中间经过的所有节点与边
- 即便中间节点本身有权访问，路径组合仍可能敏感
- 例：通过「共同好友路径」推断两人认识
→ 路径返回要按「路径上的最小权限」裁剪
挑战四：推理攻击：
- 通过多次查询的「有/无结果」推断敏感事实
- 例：二分搜索式查询推断某属性值
- 例：通过计数差异推断隐藏关系的存在
→ 仅靠「隐藏数据」不够，还要限制「可推断的信息量」
心智：图安全的四个特殊挑战——「关系即信息」（边本身可能是机密，权限必须覆盖边）、「权限沿边传播」（给了节点读权限等于给了整个连通分量，图里没有表边界）、「路径泄露」（返回路径等于泄露中间所有点边，要按最小权限裁剪）、「推理攻击」（靠有/无结果推断敏感事实，要限流、扰动、审计）；用「实体类型」思考权限是关系库的惯性，图里必须按「可达性」思考。
2. 认证与角色模型
认证的层次：
1. 传输层认证：TLS 客户端证书（mTLS）
2. 数据库认证：用户名 + 密码 / LDAP / Kerberos / SSO
3. 服务账号 vs 个人账号：服务用独立账号，便于审计与吊销
4. 凭据管理：密钥轮换、禁止硬编码、用密钥管理服务
→ 认证是权限的前提，先解决「你是谁」
RBAC 的基本模型：
用户（User）→ 角色（Role）→ 权限（Privilege）
- 用户可拥有多个角色
- 角色可嵌套（角色继承）
- 权限作用在「资源」上（图、标签、关系、属性、过程）
→ RBAC 是基线，细粒度需求再叠加属性级授权
Neo4j 的角色与授权示例：
// 创建角色
CREATE ROLE analyst;
CREATE ROLE risk_manager;
// 授予读权限（所有标签的节点与关系）
GRANT MATCH {*} ON GRAPH neo4j NODES * TO analyst;
GRANT MATCH {*} ON GRAPH neo4j RELATIONSHIPS * TO analyst;
// 授予特定过程的执行权限
GRANT EXECUTE PROCEDURE db.labels ON DBMS TO analyst;
// 授予写权限（仅风险管理员）
GRANT CREATE ON GRAPH neo4j NODES * TO risk_manager;
GRANT SET PROPERTY {*} ON GRAPH neo4j NODES * TO risk_manager;
最小权限原则的落地：
- 默认拒绝：新账号无任何权限，按需逐条授予
- 只给需要的标签：不给「所有标签」通配
- 只给需要的过程：禁止 apoc.* 全量执行权限
- 定期复核：账号与权限的季度审计
→ 「最小权限」不是一次性配置，是持续治理
角色设计与命名：
按「职责」而非「人」设计角色（role_analyst_readonly 好，role_zhangsan 差）
角色要回答：谁能读哪些标签与属性 / 谁能写能删 / 谁能改权限（「谁能改谁能」）
→ 最后一条最关键，权限管理权要单独收口
服务账号与凭据轮换：
- 每个应用一个服务账号（便于审计与吊销）
- 凭据放密钥管理服务（Vault / KMS），不落配置文件
- 定期轮换（如 90 天），轮换过程要无感（双凭据过渡）
- 离职/下线即吊销（自动化，不靠人工）
→ 凭据管理是「认证」里最容易出事的一环
心智：认证先解决「你是谁」——传输层用 mTLS、数据库层用密码/LDAP/SSO、服务用独立服务账号、凭据放密钥管理服务并定期轮换；授权用 RBAC（用户→角色→权限，权限作用在图上），落地必须坚持「默认拒绝、按需授予、不给通配、定期复核」的最小权限原则；角色按职责而非人命名，且要单独回答「谁能改权限」这个问题——权限管理权必须单独收口。
3. 标签级与关系级权限
为什么标签级权限不够：
- 只给 :Person 读权限 → 顺边可走到 :SensitiveRecord
- 只给节点权限不给关系权限 → 无法沿边遍历（图变成孤立点）
- 关系权限太宽 → 等于给了整个连通分量
→ 节点权限与关系权限必须「成对设计」
标签级权限的粒度：
// 细到「标签 + 属性」的读权限
GRANT MATCH {name, city} ON GRAPH neo4j NODES Person TO analyst;
GRANT MATCH {id} ON GRAPH neo4j NODES Company TO analyst;
// 关系级：只允许遍历特定类型
GRANT MATCH {*} ON GRAPH neo4j RELATIONSHIPS FRIEND TO analyst;
GRANT MATCH {*} ON GRAPH neo4j RELATIONSHIPS WORKS_AT TO analyst;
// 注意：不给 TRANSFER 关系权限 → 无法沿资金边遍历
关系类型即权限边界：
设计思路：把「敏感程度」编码进关系类型
:FRIEND 公开
:WORKS_AT 内部
:TRANSFER 机密
:FLAGGED_AS 机密
→ 权限按关系类型授予，天然形成边界
可达性约束（防止沿边逃逸）：
问题：允许读 :Person 和 :FRIEND，但 :FRIEND 能走到 :SensitiveRecord
解法 1：不授予「能走到敏感标签」的关系类型（成本最低）
解法 2：查询层强制「路径上不得出现敏感标签」
解法 3：把敏感子图拆到独立数据库（物理隔离，最稳）
路径裁剪的实现：
// 路径上出现敏感标签则整条路径不可见
MATCH p = (a:Person {id: $id})-[:FRIEND*1..3]->(b)
WHERE NONE(n IN nodes(p) WHERE n:SensitiveRecord)
RETURN p
权限的继承与冲突：
- 多角色时取「并集」（允许优先）还是「交集」（拒绝优先）？
- 安全实践：显式拒绝优先（Deny overrides Allow）
- 但多数图库只支持「允许」的并集
→ 需要「拒绝」语义时，靠「不给权限 + 应用层过滤」实现
→ 权限模型要明确「冲突时谁赢」
心智：标签级权限必须「节点 + 关系成对设计」——只给节点权限图变孤立点，关系权限太宽等于给了整个连通分量；最实用的技巧是「把敏感程度编码进关系类型」（FRIEND 公开 / TRANSFER 机密），权限按关系类型授予天然形成边界；可达性约束优先用「不授予能走到敏感标签的关系类型」，最稳的是把敏感子图拆到独立数据库；权限模型要明确「冲突时谁赢」（安全实践是显式拒绝优先，但多数图库只有允许并集）；权限变更要做影响分析与回归。
4. 属性级脱敏与掩码
属性级权限的三种需求：
1. 完全不可见：属性根本不出现在结果里
2. 掩码可见：手机号 138****1234（可用但不可还原）
3. 哈希/令牌化：存令牌，真值在独立的受控服务
→ 按敏感级别选手段，不要一刀切
应用层脱敏（通用做法）：
SENSITIVE = {
"idCard": lambda v: v[:3] + "***********" + v[-4:],
"phone": lambda v: v[:3] + "****" + v[-4:],
"bankCard":lambda v: "**** **** **** " + v[-4:],
"email": lambda v: v.split("@")[0][:2] + "***@" + v.split("@")[-1],
}
def mask_row(row, allowed_fields):
out = {}
for k, v in row.items():
if k not in allowed_fields:
continue
out[k] = SENSITIVE[k](str(v)) if k in SENSITIVE else v
return out
查询层脱敏（投影时掩码）：
// 在 RETURN 里直接掩码；真值仍在库里，此写法只防「无意泄露」
MATCH (p:Person {id: $id})
RETURN p.name AS name, left(p.phone, 3) + '****' + right(p.phone, 4) AS phoneMasked
数据库层属性权限（更强）：
// 只授予非敏感属性
GRANT MATCH {id, name, city, createdAt} ON GRAPH neo4j NODES Person TO analyst;
// idCard / phone 未授予 → 查询引用会报权限错误
心智：属性级安全有三种需求（完全不可见、掩码可见、令牌化），按敏感级别选手段；敏感属性要先分类（标识/财务/生物/位置/行为）再定策略；三层实现是「数据库层属性授权（最强，查询直接被拒）> 查询层 RETURN 掩码（防无意泄露）> 应用层返回前替换（通用兜底）」；令牌化把泄露面从图库缩到受控的令牌服务；脱敏必须集中式实现（统一在数据访问层），否则不同接口规则不一致就等于泄露。
5. 查询改写与行级过滤
为什么需要查询改写：
- 图库的权限模型可能不支持「行级」（如按部门过滤）
- 应用层手写过滤容易被漏掉（新增接口忘记加 WHERE）
- 集中式改写能保证「所有查询都被同一条规则约束」
→ 查询改写 = 把权限规则「编译」进每一条查询
行级过滤的改写规则：
原始查询：
MATCH (p:Person) RETURN p.name
改写后（强制加上租户/部门过滤）：
MATCH (p:Person) WHERE p.tenantId = $__tenant RETURN p.name
→ 改写层注入 $__tenant，应用代码无需感知
改写层的实现（AST 级）：
def inject_tenant(cypher_ast, tenant_id):
"""在 AST 上为每个节点模式注入租户谓词"""
for pattern in cypher_ast.find_all("node_pattern"):
pattern.where.append(prop_eq("tenantId", tenant_id))
return cypher_ast.to_cypher()
- 用 AST 而非字符串正则（正则会被注释/字符串绕过）
- 改写后再过一次「语法 + 安全校验」（防改写引入错误）
- 改写规则要有单元测试（覆盖各种查询形态）
→ 字符串替换式改写是安全漏洞的常见来源
列级过滤（属性投影裁剪）：
- 查询 RETURN * → 改写为 RETURN 允许的字段；敏感字段被引用则在改写阶段报错
→ 「默认不返回」比「默认返回再脱敏」更安全
改写的边界情况与网关位置：
边界：子查询 / CALL / UNION 分支 / 变长路径中间节点 / 写操作都要改写
位置：应用 → 查询网关（改写 + 校验）→ 图库
- 网关是唯一入口，绕过网关的直连要被网络策略禁止
- 网关日志记录「原始查询 + 改写后查询」
→ 网关是「强制点」，不能是「可选层」
心智：查询改写把权限规则「编译」进每条查询，解决「图库不支持行级权限」与「应用层忘记加过滤」两类问题；改写必须在 AST 级做（字符串替换会被注释/字符串绕过），改写后再过一次语法与安全校验，规则要有单元测试覆盖子查询、UNION、变长路径、写操作等边界；改写层要放在唯一入口的查询网关上（网关是强制点不是可选层，绕过网关的直连必须被网络策略禁止）；最佳组合是「数据库原生权限打底 + 查询网关补充行级规则」，两层叠加，任一层失效仍有保护。
6. 多租户隔离
三种隔离模式：
模式 A：独立数据库（每租户一个库）
- 隔离最强、故障与性能互不影响
- 成本最高（每租户一套资源）
模式 B：共享图 + 租户标签（同一图里用 tenantId 区分）
- 成本最低、资源利用率高
- 隔离最弱（靠查询改写保证）
模式 C：共享库 + 独立数据库实例（图库的多数据库特性）
- 折中：同一实例、逻辑隔离
→ 按租户的「数量、敏感度、规模」选模式
共享图模式的强制点：
// 租户隔离的三重保险
// 1) 每个节点必须有 tenantId（约束保证）
CREATE CONSTRAINT tenant_required FOR (n:Person) REQUIRE n.tenantId IS NOT NULL
// 2) 租户属性必须有索引（查询效率 + 强制走索引）
CREATE INDEX person_tenant_idx FOR (n:Person) ON (n.tenantId)
// 3) 查询必须带 tenantId（改写层强制注入）
MATCH (p:Person) WHERE p.tenantId = $tenant RETURN p
跨租户泄露的典型路径：
查询忘加 tenantId（最常见）/ 共享节点只有一个 tenantId
关系没带 tenantId 顺边逃逸 / 聚合计数包含他租户
→ 节点、关系、聚合三处都要带租户约束
共享节点的处理：
- 真实世界有「共享实体」（如同一家公司属于两个租户）
- 方案 1：复制节点（每租户一份）→ 简单但数据冗余
- 方案 2：共享节点 + 访问关系（租户通过关系访问）
- 方案 3：把共享性建模为「可见性边」，权限沿边判定
→ 共享节点是「共享图模式」最容易出错的地方
资源公平与租户数据删除：
公平：大租户的重查询影响小租户 → 按租户限流（并发/配额），大租户「毕业」到独立库
删除：共享图删除 = 删所有带该 tenantId 的节点与关系，要防「漏删」（关系/索引/缓存/备份）
→ 「共享起步、大者独立」是常见演进路径；「删除权」在共享模式下成本远高于独立库
心智：多租户有三种隔离模式——独立库（最强但最贵）、共享图 + 租户标签（最省但最弱）、共享库多数据库（折中），按租户数量、敏感度、规模选；共享图模式要靠三重保险（约束保证 tenantId 非空 + 租户属性索引 + 查询改写强制注入）；跨租户泄露的典型路径是「忘加 tenantId」「共享节点只有一个 tenantId」「关系没带租户」「聚合计数包含他租户」，节点、关系、聚合三处都要带约束；共享节点是共享模式最易出错处；大租户要限流甚至「毕业」到独立库；合规的「删除权」在共享模式下成本远高于独立库。
7. 审计与合规
审计要记录什么：
- 谁（身份、来源 IP、客户端）
- 做了什么（查询原文、参数、读/写）
- 对什么（涉及的标签、关系、敏感属性）
- 结果如何（成功/失败、返回行数、耗时）
- 何时（时间戳，含时区）
→ 审计日志是「事后追责」与「合规证明」的唯一依据
审计日志的采集层次：
层次 1：数据库查询日志（内核级，最全但含敏感数据）
层次 2：查询网关日志（含改写前后，能关联身份）
层次 3：应用审计日志（业务语义，如「客服查看用户资料」）
→ 三层结合：内核保完整、网关保身份、应用保语义
审计日志的敏感性：
- 审计日志本身可能含敏感数据（查询里的身份证号）
- 需要「脱敏后的审计」：记录「查询了 idCard 字段」而非字段值
- 日志的访问权限要严于业务数据（谁能看审计？）
→ 审计日志是高价值目标，必须单独保护
合规要求的映射：
| 合规项 | 图场景要求 |
|---|---|
| GDPR 访问权 | 能导出某主体的全部关联数据 |
| GDPR 删除权 | 能彻底删除某主体及其关系 |
| 最小必要 | 只采集/只保留必要的图数据 |
| 可追溯 | 数据来源与变更历史可追溯 |
| 数据本地化 | 敏感数据不出境（区域部署） |
GDPR 访问权在图上的实现：
// 导出某主体的全部关联数据（含关系）
MATCH (s:Subject {id: $subjectId})
OPTIONAL MATCH (s)-[r]-(other)
RETURN s, collect({rel: type(r), props: properties(r), other: other}) AS relations
GDPR 删除权在图上的实现：
// 删除主体及其所有关系（含反向关系）
MATCH (s:Subject {id: $subjectId})
DETACH DELETE s
// 注意：还要清理「关系历史」「物化结果」「缓存」「备份」
- DETACH DELETE 只删图里的当前状态
- 历史版本（时态图）、物化算法结果、外部缓存、备份都要处理
- 备份里的数据是「删除权」最难的部分（需按主体加密或定期淘汰）
→ 「彻底删除」在图里是跨系统的工程问题
数据血缘与审计运维：
血缘：记录节点来源（系统/导入批次/时间）与属性变更历史（谁改、改前改后）
→ 用于质量溯源、合规举证、误操作回滚
运维：保留期达标（常 6 个月到数年）、不可篡改（WORM / 哈希链）
容量规划、定期异常分析 → 审计不是「存下来」，是「能查出来」
心智：审计要记录「谁、做了什么、对什么、结果、何时」五要素，采集分三层（内核查询日志保完整、网关日志保身份、应用日志保业务语义），三层结合才完整；审计日志本身含敏感数据，需要「记录访问了敏感字段」而非字段值，且其访问权限要严于业务数据；合规上 GDPR 的访问权靠「导出主体全部关联数据」、删除权靠「DETACH DELETE + 清理时态历史/物化结果/缓存/备份」——备份是删除权最难的部分；血缘（来源与变更历史）是可追溯的技术实现；审计日志要不可篡改、保留期达标、定期做异常分析，否则「存了但查不出来」等于没审计。
8. 传输与静态加密
加密的三个位置：
1. 传输中（in transit）：客户端到数据库、集群节点之间
2. 静态（at rest）：数据文件、备份文件、日志文件
3. 使用中（in use）：内存中的敏感数据（最难，通常不做）
→ 前两个是必做，第三个按合规要求评估
传输加密的配置：
- 客户端连接：TLS（neo4j+s:// / bolt+s:// 强制加密）
- 证书校验：必须校验证书链（禁止跳过校验）
- 集群内通信：节点间也走 TLS（防内网嗅探）
- 证书轮换：定期换证，避免过期导致集群中断
→ 「加密」不等于「安全」，证书校验才是关键
静态加密的实现：
方案 A：存储层加密（云盘加密 / LUKS）
- 优点：对数据库透明、性能损耗小
- 缺点：密钥与存储绑定，粒度粗
方案 B：文件级加密（数据库自带或外部工具）
- 优点：可针对数据文件
- 缺点：可能与备份/恢复流程耦合
方案 C：应用层字段加密（敏感属性单独加密）
- 优点：粒度最细、跨存储一致
- 缺点：无法对加密字段做索引与范围查询
→ 存储层打底 + 应用层加密敏感字段是常见组合
密钥管理：
- 密钥存 KMS / HSM，不落磁盘明文
- 密钥轮换（定期 + 事件驱动）
- 密钥与数据分离（拿到数据文件也解不开）
- 密钥访问审计（谁用了密钥、何时）
→ 「加密的强度 = 密钥管理的强度」
加密与查询能力的冲突、备份与日志加密：
冲突：加密字段无法索引 → 折中：确定性加密（可等值，泄露频率信息）
或保序加密（可范围，泄露顺序信息）或只加密不需查询的字段
备份与日志：必须加密（泄露面最大），且密钥与数据库密钥分离（防一锅端）
→ 「加密」与「可查询」按字段权衡；别忘了「非主数据文件」的加密
心智：加密分传输中（客户端到库、节点间都要 TLS，且必须校验证书链，mTLS 强于单向 TLS）、静态（存储层加密打底 + 应用层敏感字段加密）、使用中（通常不做）三个位置；静态加密三种方案（存储层透明但粒度粗、文件级与备份流程耦合、应用层字段级最细但无法索引）常组合使用；密钥必须存 KMS/HSM、定期轮换、与数据分离、访问审计——加密强度等于密钥管理强度；加密与可查询存在冲突（加密字段无法索引），按字段权衡用确定性加密或保序加密；备份与日志文件同样是高价值目标，必须加密且密钥与主库分离。
9. 注入防护与查询安全
Cypher 注入的本质：
- 把用户输入拼接进查询字符串
- 攻击者构造输入改变查询语义
- 例：参数 name = "x' RETURN 1 //" 之类
→ 与 SQL 注入同源，防护手段也同源
危险写法与安全写法：
# 危险：字符串拼接
cypher = f"MATCH (p:Person {{name: '{user_input}'}}) RETURN p"
session.run(cypher)
# 安全：参数化
session.run("MATCH (p:Person {name: $name}) RETURN p", name=user_input)
动态标签/属性的处理：
- 标签与属性名「不能参数化」（Cypher 限制）
- 危险：MATCH (n:`{user_label}`) RETURN n
- 安全：用白名单校验标签名
ALLOWED_LABELS = {"Person", "Company", "Account"}
def safe_label(name: str) -> str:
if name not in ALLOWED_LABELS:
raise ValueError("非法标签")
return name
APOC 与过程调用的风险：
高危过程：apoc.load.*（SSRF）、apoc.cypher.run（二次注入）、apoc.do.* / periodic.*（写操作）
配置：dbms.security.procedures.allowlist 只允许白名单（或 denylist 禁高危）
→ 原则：默认禁用、按需开放、限制其网络访问
查询资源限制（防 DoS）：
- 查询超时（statement timeout）
- 最大返回行数（强制 LIMIT）
- 并发查询数限制（按账号）
- 禁止无上界的变长路径（* 无上界）
→ 「查询安全」不只是注入，还包括「不被一条查询打垮」
编码陷阱与安全测试：
编码陷阱：Unicode 同形字（西里尔 а 冒充拉丁 a）、大小写、全角半角都能绕过黑名单
→ 黑名单不可靠，白名单 + 参数化才可靠
安全测试：对每个接收用户输入的查询做注入测试，覆盖参数/标签/属性/ORDER BY 位置
→ 把注入用例纳入 CI，注入防护要「有测试证明」
心智：Cypher 注入与 SQL 注入同源，唯一可靠防护是「参数化 + 白名单」——参数化用于值，白名单用于「不能参数化」的标签与属性名，永远不要用「过滤关键词」的黑名单（Unicode 同形字、大小写、全半角都能绕过）；高危过程（apoc.load. 的 SSRF、apoc.cypher.run 的二次注入、apoc.do. 的写操作）必须用过程白名单默认禁用、按需开放并限制网络；查询安全还包括资源限制（超时、强制 LIMIT、并发上限、禁止无上界变长路径）以防范 DoS；注入防护要有 CI 里的测试用例覆盖参数、标签、属性、ORDER BY 各位置。**
10. 实践清单与常见坑
权限体系的分层设计：
第 1 层（物理）：敏感子图独立库 → 第 2 层（数据库）：RBAC + 标签/关系/属性授权
第 3 层（网关）：查询改写 + 行级过滤 + 参数化校验 → 第 4 层（应用）：脱敏兜底
第 5 层（监控）：审计日志 + 异常检测 → 五层叠加，任一层失效仍有保护
上线检查清单：
[ ] 认证：服务账号独立、凭据在 KMS、支持轮换
[ ] 授权：默认拒绝、按需授予、无通配、有复核机制
[ ] 标签权限与关系权限成对设计
[ ] 敏感属性有属性级授权或脱敏（集中式实现）
[ ] 查询网关是唯一入口，直连被网络策略禁止
[ ] 行级过滤在 AST 级改写，有单元测试
[ ] 多租户：节点、关系、聚合三处都带租户约束
[ ] 审计：五要素齐全、不可篡改、保留期达标
[ ] 加密：传输 TLS + 静态加密 + 密钥在 KMS
[ ] 注入：全参数化 + 标签白名单 + 过程白名单
[ ] 资源：超时 + 强制 LIMIT + 并发上限
[ ] 演练：权限绕过测试、越权访问测试
常见坑清单：
坑 1：给了节点权限忘了关系权限 → 图变孤立点（功能坏）
坑 2：给了关系权限没考虑可达性 → 沿边逃逸到敏感子图
坑 3：查询改写用字符串正则 → 注释/字符串绕过
坑 4：应用层各自脱敏 → 接口间规则不一致 = 泄露
坑 5：共享图只给节点加 tenantId → 关系与聚合泄露他租户
坑 6：审计日志不脱敏 → 审计日志成了新的泄露源
坑 7：备份未加密 → 泄露面比生产库还大
坑 8：动态标签直接拼接 → 注入（标签不能参数化）
坑 9：开放 apoc.load.* → SSRF 与内网探测
坑 10：无查询超时 → 一条查询打垮整个实例
坑 11：权限只增不减 → 累积成「人人都是管理员」
坑 12：没有越权测试 → 以为安全，其实可绕
越权测试的用例设计：
- 水平越权：租户 A 的用户查租户 B 的数据
- 垂直越权：只读角色尝试写/删/改权限
- 路径逃逸：从有权限的标签沿边走到无权限标签
- 属性越权：查询引用未授权属性
- 推理攻击：用聚合/计数推断隐藏数据
→ 每类都要有自动化用例，纳入 CI
心智：权限体系分五层（物理隔离、数据库 RBAC、网关改写、应用脱敏、监控审计），层层叠加而非二选一；十二个坑集中在四处——权限设计（节点/关系不成对、可达性未考虑、租户约束不全）、实现方式（字符串改写、分散脱敏、拼接标签、开放高危过程）、数据保护（审计未脱敏、备份未加密、无超时）、治理（权限只增不减、无越权测试）；越权测试要覆盖水平、垂直、路径逃逸、属性越权、推理攻击五类并纳入 CI——「以为安全」和「验证过安全」之间隔着整套测试。
速查表
权限粒度与手段：
| 粒度 | 手段 | 强度 |
|---|---|---|
| 数据库 | 独立库隔离 | 最强 |
| 标签/关系 | GRANT MATCH ON NODES/RELATIONSHIPS | 强 |
| 属性 | GRANT MATCH {props} / 属性授权 | 强 |
| 行（租户/部门） | 查询网关 AST 改写 | 中 |
| 字段值 | 掩码 / 令牌化 | 中 |
| 应用层 | 返回前过滤 | 弱（兜底） |
隔离模式速记：
独立库：最强、最贵、运维 N 套
共享图 + 租户标签：最省、最弱、靠三重保险
共享库多数据库：折中
演进路径：共享起步 → 大租户毕业到独立库
一句话记忆：图安全比关系库多四个挑战——「关系即信息」（边本身可能是机密，权限必须覆盖边）、「权限沿边传播」（给了节点读权限等于给了整个连通分量，图里没有表边界）、「路径泄露」（返回路径等于泄露中间所有点边，要按最小权限裁剪）、「推理攻击」（靠有/无结果推断敏感事实）；授权必须「节点权限与关系权限成对设计」，最实用的技巧是把敏感程度编码进关系类型（FRIEND 公开 / TRANSFER 机密）；属性安全分三层（数据库层属性授权最强、查询层 RETURN 掩码防无意泄露、应用层替换兜底），脱敏必须集中式实现否则接口间不一致就等于泄露，令牌化把泄露面缩到受控服务；行级权限靠查询网关在 AST 级改写（字符串正则会绕过），网关必须是唯一入口且绕过直连被网络策略禁止；多租户三模式（独立库最强最贵、共享图最省最弱、多数据库折中），共享图要靠「约束保证 tenantId + 租户索引 + 改写强制注入」三重保险，且节点、关系、聚合三处都要带约束，共享节点与「删除权」是最易出错处；审计要记「谁、做了什么、对什么、结果、何时」五要素并不可篡改，加密覆盖传输（TLS + 证书校验）、静态（存储层打底 + 敏感字段加密）、密钥（KMS + 轮换 + 与数据分离）；注入防护唯一可靠手段是「参数化 + 白名单」（值参数化、标签属性白名单、高危过程白名单），永远别用关键词黑名单；最后，权限体系是五层叠加（物理隔离、数据库 RBAC、网关改写、应用脱敏、审计监控）而非二选一，并用水平/垂直/路径逃逸/属性越权/推理攻击五类自动化测试在 CI 里持续证明——「以为安全」和「验证过安全」之间隔着整套测试。
延伸阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。