Navicat Cloud 直接共享连接配置 inherently 不安全——SSH 参数、内网地址、用户名、端口等组合可构成攻击链；同步 .navicat_project 文件会暴露敏感元数据，即使密码加密，成员仍可通过本地私钥或缓存密码触发登录；.npz 包解压后含明文 XML（含 host/port/user/SSH 路径），且云端删除不清理本地缓存；安全协作应剥离连接实体，仅同步结构：新建空项目 → Import Wizard → Structure Only → 删除 Connection 节点 → 关闭密码自动保存与项目密码保护；必须共享连接时，须通过数据库层权限隔离（如限定 SELECT 权限、禁用高危操作、限制主机白名单），而非依赖 Navicat Cloud 角色控制。
直接共享 navicat cloud 中的连接配置，默认就是不安全的——哪怕你没传密码，ssh 隧道参数、内网地址、用户名、端口、跳板机路径这些信息拼在一起，就能构成一条可被利用的攻击链路。
为什么 navicat_project 同步等于暴露敏感元数据
Navicat Cloud 同步的是整个 .navicat_project 文件，不是“连接对象”本身。这个文件里哪怕密码是 AES-256 加密存储，只要项目被设为 Member 或 Manager 权限，成员双击连接就能触发本地尝试登录（尤其当他们本机已配好对应 SSH 私钥或保存过密码时）。
更隐蔽的风险点包括：
-
ssh_host、ssh_user、ssh_key_file路径暴露后，可能指向跳板机或内网运维节点 -
mysql_host值为10.10.20.5或db-prod.internal，配合用户名可定位真实拓扑 - 导出项目为
.npz包后，用 7-Zip 解压即可看到明文 XML 定义（不含密码，但含全部 host/port/user/SSH 参数） - Owner 删除云端项目 ≠ 清除所有成员本地缓存；旧版 Navicat 可能仍保留已同步的连接副本
只共享结构：用 Import Wizard → Structure Only 替代连接导入
目标不是“不让别人连”，而是让协作停留在 ER 图设计、SQL 审核、字段对齐等只读场景。关键动作是剥离连接实体，只留结构定义。
操作步骤如下：
- 新建空项目（如
shared_er_model.npz），不要从已有项目导入 - 用
Tools → Import Wizard → Structure Only导入目标库的表结构（不选数据、不选存储过程、不选视图定义） - 右键项目树中的
Connection节点 →Delete Connection（确认删除，不是禁用） - 检查
Project Properties → Security → Password Protection是关闭状态（否则别人打不开项目） - 同步前，在
File → Options → General中关闭Auto-save connection passwords
此时项目只剩 ER Diagram 和 Table Definition 节点，同步到 Cloud 后，团队看到的是可读、不可连、无法导出凭证的干净模型。
必须共享可连接配置时，用数据库层权限隔离代替云权限控制
Navicat Cloud 的 Member/Manager 角色不能限制“能否执行 DROP TABLE”，它只管“能否编辑项目文件”。真要让成员能连上查数据，控制点必须下沉到数据库本身。
实操要点：
- 为每个成员单独创建数据库用户，例如
dev_readonly_john@'%' - 只授予
SELECT权限，并精确限定到具体库和表（如GRANT SELECT ON sales.orders TO 'dev_readonly_john'@'%'） - 显式禁用高危权限：
REVOKE DROP, INSERT, UPDATE, DELETE, GRANT OPTION, CREATE, ALTER ON *.* FROM 'dev_readonly_john'@'%' - 避免使用通配符主机（如
'%'），优先用 IP 段或域名白名单（如'192.168.10.%'） - 连接配置中，
mysql_user字段填该只读账号，而非 root 或 DBA 账号
真正的风险不在 Navicat Cloud 是否加密传输，而在于你是否把生产环境的连接元数据当成“配置”来管理，而不是当成“凭证+策略”的组合体来约束。一旦连接里混着内网地址、SSH 设置、高权限账号，再强的 AES 加密也挡不住配置泄露后的横向移动。
