主从复制中哪些环节会泄露敏感数据
主从复制本身不加密传输，
binlog以明文形式在网络上传输，一旦被中间人截获，所有 DML/DDL 操作（包括密码重置、用户权限变更）都可能暴露。更隐蔽的风险是：从库若未设访问控制，攻击者连上从库就能读取全量业务数据——它和主库一样完整，只是只读。 主库
binlog默认不加密，MySQL 5.7+ 才支持
binlog_encryption=ON（需配合密钥环插件） 复制账户（如
repl_user）若用弱密码或通配符主机（
'%'@'%'），极易成为突破口 从库未关闭远程 root 登录、未限制
SELECT权限范围，等于把备份当公开接口 物理网络未隔离，主从流量混在业务网段，Wireshark 一抓一个准
必须启用的三项最小安全加固配置
不依赖额外中间件，仅靠 MySQL 原生能力就能堵住绝大多数数据泄露口。
强制 TLS 复制通道：在主库创建复制用户时指定REQUIRE SSL，从库
CHANGE MASTER TO中加上
MASTER_SSL=1及对应证书路径；否则
SHOW SLAVE STATUS\G里
Seconds_Behind_Master正常，但流量仍是明文 最小权限复制账户：不要用
root或
admin账户做复制。应单独建用户：
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY '强密码' REQUIRE SSL;，再授
REPLICATION SLAVE权限，禁止
GRANT OPTION从库禁用写入与高危操作：从库配置文件加
read_only=ON（注意：这不阻止 super 用户写入），再加
super_read_only=ON（MySQL 5.7.20+）彻底锁死；同时撤销
FILE、
SHUTDOWN、
PROCESS等非复制必需权限
binlog 加密不是“开箱即用”，得先配密钥环
binlog_encryption=ON看起来很美，但 MySQL 不内置密钥管理。你得手动加载
keyring_file插件，并确保密钥文件权限为
600且仅 MySQL 用户可读——否则服务启动直接失败，报错
Plugin 'keyring_file' init function returned error。 配置示例（主库
my.cnf）：
[mysqld] early-plugin-load=keyring_file.so keyring_file_data=/var/lib/mysql-keyring/keyring目录
/var/lib/mysql-keyring必须由
mysql用户拥有，且不能在 NFS 或容器临时卷上——密钥环不支持网络文件系统 开启后，
SHOW VARIABLES LIKE 'binlog_encryption';返回
ON，但旧 binlog 文件不会自动加密，只对新生成的生效
最容易被忽略的“安全假象”：只开了 read_only
很多团队以为
read_only=ON就万事大吉，却忘了 super 用户仍能绕过。如果从库还运行着监控脚本、备份工具或 DBA 用的 admin 账户，这些 super 权限会直接让
read_only形同虚设。 验证是否真锁死：
mysql -u repl_user -e "INSERT INTO test.t VALUES(1);"应报错
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement但如果用
mysql -u root -e "INSERT..."成功，说明
super_read_only=ON没生效，或 MySQL 版本太低（ 生产环境建议：从库操作系统层面也限制登录，仅开放复制端口（3306）和监控端口（如 9104），关掉 SSH 密码登录，用证书+跳板机管控 实际部署时，
super_read_only和
REQUIRE SSL是两个最廉价也最关键的开关，漏掉任何一个，所谓“安全复制”就只剩心理安慰。
