备份文件泄露等于暴露数据库明文数据、账号哈希与配置路径；mysqldump默认导出敏感信息，需从权限控制、字段筛选、视图脱敏、安全命令、加密传输及严格文件权限六方面系统防护。
备份文件一旦泄露，等于把数据库明文数据、账号哈希、甚至配置路径全交出去——mysqldump 生成的 SQL 文件不是“备份完成就安全了”，而是刚出生就暴露在风险中。
为什么 mysqldump 输出默认就是敏感数据放大器
它不做过滤、不脱敏、不拦截字段，只要权限够，SELECT * 就能导出 mysql.user 表里的 authentication_string、information_schema.PROCESSLIST 里的连接信息、甚至 @@datadir 这种系统变量拼接结果。
- 执行
mysqldump -u root mysql→ 直接拿到所有账号密码哈希（可离线爆破） - 导出
information_schema→ 暴露全部库名、表结构、引擎类型、字符集 - 应用层 SQL 拼接了
CONCAT('HOST=', @@hostname)→ 备份里明文写着服务器主机名和路径
secure-file-priv 完全不管这些——它只管“能不能写到 /etc/shadow”，不管“写出来的内容有没有 root:$6$...”。
导出前必须显式过滤敏感源
不能指望备份工具自动识别哪些字段敏感，得在 SQL 层就掐断源头。
- 禁用非 DBA 账户访问系统库：
REVOKE SELECT ON mysql.* FROM 'app_user'@'%'; - 业务数据导出时禁止
SELECT *，只列必要字段：SELECT id, name, email_masked FROM users; - 用视图封装脱敏逻辑：
CREATE VIEW v_users AS SELECT id, name, REGEXP_REPLACE(phone, '(\d{3})\d{4}(\d{4})', '\1****\2') AS phone_masked FROM users; - 导出元数据前先清洗：
CREATE TEMPORARY TABLE clean_info AS SELECT table_schema, table_name FROM information_schema.TABLES WHERE table_schema NOT IN ('mysql', 'performance_schema');
备份命令本身就得带安全约束
从第一字节输出开始，就不能让它以明文落地。
- 绝对不用
mysqldump -u root -p'password' db > backup.sql—— 密码进ps aux和~/.bash_history - 改用
mysql_config_editor存凭据：mysql_config_editor set --login-path=backup --user=backup_user --password --host=localhost，调用时写mysqldump --login-path=backup db - 管道直连加密，不落地明文：
mysqldump --login-path=backup db | gpg --cipher-algo AES256 --symmetric --compress-algo 1 > backup.sql.gpg - 远程备份必须加
--ssl-mode=REQUIRED，否则传输过程裸奔：mysqldump --login-path=backup --ssl-mode=REQUIRED -h db-prod.example.com db
备份文件权限和存储路径是最后一道物理防线
哪怕加密了，如果文件权限是 644、存放在 /var/www/html/backups/ 或 /tmp，照样会被直接下载或读取。
- 所有备份文件立即设为
600：chmod 600 backup.sql.gpg - 备份目录整体设为
700，属主为专用用户（如backup），绝不用root或mysql - 禁止存于 Web 可访问路径、
/tmp、MySQL 数据目录（如/var/lib/mysql） -
xtrabackup备份目录内，特别检查xtrabackup_binlog_info和backup-my.cnf是否含主从凭证，它们也得是600
真正难的不是加一行 gpg，而是让每个环节都默认拒绝明文：SQL 不选敏感字段、命令不带密码、输出不落地、文件不放错地方、权限不松手——漏掉任何一环，前面所有加密都可能白做。
