数据导出安全防护需聚焦连接加密与文件传输加密两环节：mysqldump 连接必须启用 SSL/TLS（服务端 require_secure_transport=ON 且客户端 --ssl-mode=REQUIRED），导出文件须经 GPG 加密或云存储服务端加密后传输，严禁明文传输及脚本硬编码密码。
导出数据本身不涉及“传输过程”，真正需要防护的是 mysqldump 连接数据库时的通信链路，以及导出文件后续在网络中移动（如 scp、rsync、上传到对象存储）这两个环节。直接用 mysqldump 本地导出到磁盘，只要文件权限设对，就不存在传输风险。
mysqldump 连接阶段必须启用 SSL/TLS
默认情况下，mysqldump 走的是明文 TCP 连接，密码、SQL 查询、甚至部分数据都可能被中间设备截获。必须强制走加密通道：
- 确认 MySQL 服务端已配置 SSL：检查
ssl-ca、ssl-cert、ssl-key已在[mysqld]段落中设置，且require_secure_transport = ON已生效 - 客户端连接时显式指定 SSL 参数：
mysqldump --ssl-mode=REQUIRED -u user -p db_name > backup.sql - 若服务端未强制 SSL，仅靠客户端加
--ssl-mode=REQUIRED无效——连接会直接失败，而非降级；此时必须先配好服务端 - 避免使用
--ssl-mode=PREFERRED，它会在 SSL 不可用时自动回退到明文，等于没开
导出文件跨网络传输时别裸传
mysqldump 生成的 .sql 文件本身是纯文本，含 CREATE 和 INSERT 语句，一旦泄露，敏感字段（如用户邮箱、手机号）全暴露。不能直接 scp 或拖进 FTP 客户端发走：
- 导出后立即用
gpg加密：gpg --encrypt --recipient 'backup@company.com' backup.sql，再传输backup.sql.gpg - 如果目标是云存储（如 S3），上传前启用服务端加密（SSE-S3 或 SSE-KMS），并确保上传通道本身走 HTTPS
- 禁用 HTTP/FTP 明文协议上传；哪怕用
curl -T，也必须配-k（跳过证书验证）以外的完整 TLS 验证 - 不要把密码写进脚本里传参，例如
-p'mypass'—— 进程列表和 shell 历史里都能看到
避免导出时意外暴露敏感字段
导出内容本身也可能带安全风险，尤其当表里存了不该外流的原始数据：
- 不用
--all-databases或通配符导出，只导明确需要的库/表，减少攻击面 - 对含敏感信息的表（如
users），导出前用--where="id 限制行数，或用 <code>--ignore-table=db.users排除整张表 - 不依赖应用层脱敏——
mysqldump导出的是原始值，不会执行 SELECT 中的HEX()、AES_ENCRYPT()等函数结果 - 若必须导出敏感字段，应在导出后、传输前用
sed或 Python 脚本做字段级替换（例如把邮箱替换为***@***.com），但需确保逻辑可逆且不破坏 SQL 语法
最易被忽略的一点：mysqldump 的临时文件和 stdout 重定向过程本身可能被进程窥探。在多用户服务器上，尽量用 mysql_config_editor 存凭据，而不是命令行输密码；导出路径设为 /tmp 外的私有目录，并设 chmod 600，别留着等别人 cat。
