DBeaver无法回收用户权限，权限控制必须在数据库服务端或身份系统中执行；其连接配置仅存储本地信息，删除连接不等于禁用账号。
DBeaver 本身不管理用户权限，也不对接企业身份系统，所以它**没有“回收离职人员连接权限”这个功能**。所谓“权限回收”，实际发生在数据库服务端或中间件层，DBeaver 只是客户端工具——它连不上，是因为后端账号已被停用或密码失效。 下面直说关键操作点，避免你在客户端白忙活。
为什么在 DBeaver 里删连接 ≠ 回收权限
DBeaver 的 connections.json 文件只存本地连接配置（地址、用户名、密码明文/加密、驱动参数等），删掉它只是清除你本机的快捷入口，不影响数据库账号状态。离职员工只要账号还活着，换台电脑装个 DBeaver 或用命令行照样能连。
常见错误现象：管理员在 DBeaver 里把离职员工的连接配置删了，就以为“权限已回收”，结果对方仍可通过其他设备、其他客户端甚至 JDBC URL 直连数据库。
- 真正生效的权限控制点永远在数据库侧（如 MySQL 的
DROP USER或REVOKE） - DBeaver 的“连接”本质是配置快照，不是权限载体
- 如果启用了 LDAP/OAuth 等统一认证，回收也要在对应 IdP 中操作，而非 DBeaver
如何配合数据库服务端完成权限回收
如果你是 DBA 或运维人员，需同步执行以下动作（以 MySQL / PostgreSQL 为例）：
- 立即执行
DROP USER 'xxx'@'%'（MySQL）或DROP ROLE xxx（PostgreSQL），而非仅改密码 - 检查该用户是否被授予了
GRANT OPTION，如有，先REVOKE GRANT OPTION再删用户，防止权限残留扩散 - 若使用连接池（如 HikariCP、Druid），确认应用层已下线对应数据源配置，避免连接复用旧会话
- 对 AnalyticDB for MySQL 等云数据库，必须进控制台 → 账号管理 → 删除账号，不能只依赖 SQL 命令（部分云厂商限制 DROP USER 权限）
DBeaver 客户端可做的辅助动作
虽然不能回收权限，但可以降低误连风险和信息泄露面：
- 批量清理本地连接：打开 DBeaver → 导航栏右键 “数据库” → “删除所有连接”，再手动保留在职人员常用连接
- 禁用自动保存密码：设置 → 用户界面 → 连接设置 → 取消勾选 “保存密码”，避免离职交接时密码被导出
- 关闭连接池自动重连：在连接编辑页 → “驱动属性” → 将
autoReconnect设为false（MySQL）或reWriteBatchedInserts=false（PostgreSQL），防止断连后静默重试暴露凭证 - 导出连接列表做审计：菜单栏 → 数据库 → 导出连接 → 生成 JSON，比对其中
userName字段与 HR 离职名单
容易被忽略的共享场景
多人共用一台开发机或跳板机时，DBeaver 的连接配置可能被多个账号访问。这时候光删连接没用：
- 检查
$HOME/.dbeaver4/connections.json（Linux/macOS）或%APPDATA%\DBeaverData\connections.json（Windows）是否被设为全局可读 - 确认 DBeaver 是否以系统服务方式运行（如 systemd service），导致连接配置驻留内存中未刷新
- 若使用 SSH 隧道连接，还要同步回收对应 Linux 账号的
~/.ssh/authorized_keys和sshd_config中的 AllowUsers 规则
真正的权限回收链条是：HR 提交离职 → IAM 系统停用账号 → 数据库侧删用户/ revoke 权限 → 应用配置下线 → 最后才是清理 DBeaver 这类客户端上的残留配置。漏掉任何一环，都可能让“已离职”变成“影子访问”。
