navicat cloud“共享连接”默认不安全，因其同步含加密密码的本地项目文件（如.navicat_project），且ssh隧道参数、内网地址等敏感元数据可能构成攻击链路；即使传输存储加密，权限不当或导出解包仍致泄露风险。
navicat cloud 本身不存储数据库密码，也不连接你的数据库，所以“共享连接”本质是同步连接配置元数据——但直接共享含敏感信息的连接，风险不在云端，而在本地项目配置里。
为什么“共享连接”默认不安全？
Navicat Cloud 同步的是整个 navicat_project 文件，其中若包含已保存密码的连接（尤其是勾选了 Save password 的 MySQL/PostgreSQL 连接），该密码会以加密形式存于本地项目文件中，并随项目同步到云端。虽然传输和存储用 AES-256 加密，但一旦项目被多人协作编辑、或成员权限设置不当，密码就可能被意外导出或复用。
更隐蔽的风险是：连接配置里常混着 SSH 隧道参数（ssh_host、ssh_user）、跳板机密钥路径、甚至 mysql_host 指向内网地址——这些信息本身虽不等于密码，但组合起来可构成攻击链路。
- 项目角色设为
Member或Manager的人，能直接双击连接并尝试登录（只要本地有对应私钥或密码） - 导出项目为
.npz包后，可用工具解包查看明文连接定义（不含密码，但含 host/port/user/SSH 设置） -
Owner删除项目 ≠ 清除所有成员本地缓存，旧版 Navicat 可能仍保留已同步的连接副本
怎样剥离敏感信息再共享？
目标不是“不让别人连”，而是“让连接配置只服务于 ER 图或只读查询协作”，不带执行权。关键动作是：在上传前，把连接对象从项目中「逻辑隔离」出来。
- 新建一个空项目（如
shared_er_model.npz），不要导入任何已有连接 - 用
Tools → Import Wizard → Structure Only导入目标库的表结构（不带数据、不带连接） - 右键项目树中的任意
Connection节点 →Delete Connection（确认删除，不是禁用） - 检查
Project Properties → Security → Password Protection是关闭状态（否则别人打不开项目） - 同步前，在项目设置里关闭
Auto-save connection passwords（菜单File → Options → General）
此时项目只剩表结构定义和 ER 图节点，同步到 Cloud 后，团队成员看到的是可读、不可连、无法导出凭证的干净模型。
如果必须共享可连接的配置，该怎么控权？
某些场景下（如 DBA 给开发配只读账号），确实需要让成员能连上查数据。这时不能靠 Cloud 权限控制连接行为，而要靠「连接层隔离」：
- 为每个成员单独建数据库用户，权限精确到
SELECT+ 指定库/表，禁用DROP、INSERT、GRANT - 连接配置中，
mysql_host填127.0.0.1（强制走 SSH 隧道），不填公网 IP；ssh_user用无 sudo 权限的系统账号（如navi-ro） - 私钥文件不放入项目，由成员自行配置；Navicat 中 SSH 选项卡选择
Public Key，但不勾选Save password（私钥有口令时每次手动输） - 在 Cloud 项目中，将该连接所属的子文件夹重命名为
【RO】prod-reporting，靠命名约定而非技术手段提醒用途
注意：Guest 角色在 Navicat Cloud 中只能读取文件，但无法触发连接动作——这是唯一真正“只读”的角色，适合给产品、运营等非技术成员看 ER 图或 BI 工作区。
容易被忽略的同步陷阱
即使做了上述处理，仍可能因路径或版本问题导致连接配置意外泄露或失效：
- 项目路径含中文或空格（如
C:\我的项目\shared）→ Cloud 同步服务静默跳过，但本地 Navicat 仍显示“已同步”，实际没传上去 - 你用 Navicat 17.1 创建的连接，成员用 16.3 打开 → 可能解析失败，报错
Invalid project format，但错误日志不提示具体字段 - 启用了
Windows Hello或 macOS Keychain 自动填充密码 → 表面没存密码，实则系统级凭据已被调用，不属于 Cloud 管控范围
最稳妥的做法：凡涉及生产环境连接，一律不进 Cloud；用 Navicat On-Prem Server 私有部署，配合 LDAP 统一认证，把连接生命周期关在内网里。
