navicat 不提供用户可控的端到端加密，所谓“enable encryption”选项实为灰色占位项；连接文件上传后由服务端硬编码aes-256-cbc加密，密钥不由用户掌控，明文密码存于本地.ncx中，安全共享需禁用云同步、手动脱敏并结合环境变量与git管理。
navicat 本身不提供对团队共享项目文件（如 .ncx 连接配置、.nmd 模型文件、.nqb 查询文件）的端到端加密保护能力——所谓“加密开关”要么灰掉不可用，要么只做服务端托管加密，密钥不由你控制。
为什么 Settings → Cloud → Enable Encryption 是灰色的
这个选项不是加密开关，而是旧版 UI 的遗留占位项。Navicat Team 客户端根本不响应它；所有云同步行为由 cloud.navicat.com 后端强制接管，用硬编码 AES-256-CBC 加密 .ncx 等文件，但密钥和服务逻辑完全由 Navicat 控制，用户无法验证、关闭或替换。
- 你导出的本地
connections.ncx文件是明文（含密码字段），上传后才被服务端加密成密文 blob - 一旦团队成员账号被盗，攻击者可直接从云端下载并解密全部
.ncx内容 - 该机制不支持 BYOK（自带密钥）、不开放算法切换（比如换 SM4 或 ChaCha20）
如何安全共享连接配置而不依赖 Navicat Cloud
真正可控的路径是绕过云同步，把连接信息当作机密处理，而非信任那个灰色按钮。
- 用
navicat --export-connections命令行导出时，明确指定--no-password参数，避免导出明文密码 - 手动编辑导出的
.ncx文件，删掉所有<password>.*</password>节点（XML 格式，可脚本化处理） - 将清理后的
.ncx放入 Git 仓库，并在.gitignore中加入*.ncx——仅用于结构同步，不含凭证 - 团队成员本地用环境变量注入密码：
export NAVICAT_DB_PASSWORD="xxx"，再通过 Navicat 的「变量引用」功能填入连接设置
高敏场景必须禁用的共享方式
这些操作看似提升协作效率，实则直接绕过所有加密前提：
- 禁止导入他人分享的
.ncx文件——它可能含明文密码，且无法审计来源 - 禁用 Navicat 的「Auto-save password」，改用系统钥匙串（macOS Keychain / Windows Credential Manager）或企业 SSO 登录
- 不要用 Navicat Cloud 分享
.nmd模型文件——其中可能包含表字段注释、示例数据等敏感上下文，应改用 Git + 字段脱敏预处理 - 若用私有部署的 Navicat Cloud Server（极少见），仍需确认其加密配置是否启用 FIPS 模式，且日志是否记录密钥使用行为
最易被忽略的一点：加密不是开关，而是数据流动路径的全程控制。只要你让含密码的 .ncx 文件离开本地可信环境，就已失去主动权——那个灰色的 Enable Encryption 不是你手里的锁，只是快递盒封条，拆开它不需要你的同意。
