主从复制中敏感数据泄露环节包括：binlog明文传输、从库未设访问控制、复制账户弱密码或通配符主机、从库开放远程root登录、物理网络未隔离；必须启用TLS加密通道、最小权限复制账户、从库read_only与super_read_only双锁。
主从复制中哪些环节会泄露敏感数据
主从复制本身不加密传输，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 是两个最廉价也最关键的开关，漏掉任何一个，所谓“安全复制”就只剩心理安慰。 
