3.5 用户、角色与权限：最小权限的图上实践

3.5 用户、角色与权限：最小权限的图上实践

本节摘要：安全的地基是最小权限：每个人只拿到完成任务所需的那点权力。本节讲 Neo4j 的三层安全模型——用户、角色、权限，示范只读分析账号与限定写入账号的标准配置流程，覆盖库级、标签级、属性级的权限粒度，并给出企业内常见的账号盘点表。

前面的写入与运维都默认你以管理员身份操作。真实环境里，跑报表的分析师、写数据的流水线、偶尔救火的 DBA，权力边界必须分开。本节把这道篱笆立起来。

一、三层模型：用户、角色、权限

Neo4j 的访问控制是三层结构：用户登录，角色聚合权限，权限落在具体动作（读、写、建索引等）与作用域（库、标签、关系类型、属性）上。内置四类角色覆盖大多数需求：

admin      ：全权，含用户管理
publisher  ：读写全库，不能管用户
editor     ：读写数据，不能建删索引与约束
reader     ：只读
​

只读分析账号用内置 reader 就够；要更细的边界时才自建角色。

二、标准流程：立一个只读分析账号

-- 第一步：建用户（初始密码必须首登更换）
CREATE USER analyst SET PASSWORD 'change-me-first' CHANGE REQUIRED

-- 第二步：授只读角色
GRANT ROLE reader TO analyst

-- 第三步：验证——写入应当被拒绝
-- 以 analyst 登录后执行：
CREATE (p:Person {name: 'X'})
→ SecurityError: 写操作被禁止
​

三步走完，分析师能跑全部查询、不能改一个字节。验证环节不要省——权限配完必须用失败用例确认，"应该不行"和"确认不行"是两回事。

三、细粒度：把权限修到标签与属性

自建角色可以精确到"哪张图、哪些标签、哪些属性"：

-- 自建角色：只能读写 Person 与 Movie，碰不到别的标签
CREATE ROLE data_steward IF NOT EXISTS
GRANT MATCH {*}        ON GRAPH neo4j NODES Person, Movie TO data_steward
GRANT WRITE            ON GRAPH neo4j NODES Person, Movie TO data_steward

-- 属性级：财务数据只授给特定角色
GRANT MATCH {name, email} ON GRAPH neo4j NODES Person TO data_steward
DENY  READ {salary}       ON GRAPH neo4j NODES Person TO data_steward
​

GRANT 授予、DENY 显式拒绝（优先级高于 GRANT），组合起来能表达"看得见用户、看不见工资"这类需求。作用域从粗到细依次是：实例 → 库 → 标签/关系类型 → 属性，配权限时从细往粗收，别从粗往细放。

图：从访问者到数据的四层闸门

四、企业内账号盘点表

一个能直接抄走的盘点模板，每个账号一行，问三个问题：它是谁、它需要什么、多余的权力收掉没有：

💡 应用连接账号给 editor 而不是 admin：应用侧从不需要建索引、管用户，多给的权力就是多出的爆炸半径。第 4 章驱动连接用的正是这类账号。

五、常见权限事故与对策

权限体系的价值在避免事故，四类高频事故值得预演：

事故一：所有人都用 neo4j 超管账号连库
  对策：超管密码进密码库，日常账号按角色分发，
       超管登录记录审计

事故二：离职人员的账号还活着
  对策：账号盘点表（上文模板）与 HR 名单季度对账，
       离职当天 SUSPEND

事故三：数据分析直连生产写库
  对策：分析走 reader 专用账号 + 副本路由，
       从源头隔离读写

事故四：临时授权永久化
  对策：CREATE USER 时写好备注与到期提醒，
       季度盘点清零
​

其中事故二的命令很直白，别忘了它：

-- 暂停（保留账号与权限）与彻底删除
ALTER USER former_analyst SET STATUS SUSPENDED
DROP USER former_analyst
​

六、FAQ

问：社区版有权限体系吗？
社区版只有基础的用户认证，细粒度角色权限属于企业版能力。用社区版上生产的团队，替代方案是在应用层做账号隔离（不同服务不同账号）＋网络层限制访问来源。

问：权限改完要重启吗？
不用。角色与授权即时生效，正在运行的会话按新权限裁决下一次操作——这也是"拒绝测试"能当场做的原因。

七、权限与数据安全的边界分工

最后理清权限体系管什么、不管什么，边界感决定安全感：

权限体系管的：谁能连、能查哪些库/标签/属性、能执行哪类写
权限体系不管的：
  应用内部的业务级隔离（"普通会员看不到 VIP 价格"）
  字段的展示逻辑（脱敏、打码）
  数据加密与传输安全
​

业务级隔离要在应用层实现（3.5 的篱笆挡外不挡内）；传输加密在协议配置里开（bolt+s）；两边各管一段，合起来才是完整的安全面。把平台权限当万能锁，是安全设计里最常见的错位。

问：怎么给账号改名与重置密码？
ALTER USER 一并处理：改名、改密码、取消"必须更换"标记都是它。忘记 admin 密码时，用离线的 neo4j-admin 系统库重置流程——这也是超管密码要进密码库的原因，重置流程并不轻松。

本节要点回顾

• 三层模型：用户认证 → 角色聚合 → 权限作用域；
• 内置四角色（admin/publisher/editor/reader）覆盖多数需求，细粒度再自建；
• 权限作用域可细到属性，DENY 优先于 GRANT；
• 配权限必须做拒绝测试，"应该不行"不算数；
• 一任务一账号、最小权限、季度盘点是三条铁律。

写入、可靠性、导入、运维、安全——图库的生产资格集齐了。下一章离开命令行，进入应用：驱动、工具与多语言集成。