etcd 快照落在未加密磁盘超 90 天：如何量化暴露面、分批轮换 30+ 密码而不打断业务、最小代价给快照加密？

【背景】 3 节点自建 K8s 1.28（containerd 1.6），etcd 数据在本地 SSD（/var/lib/etcd）。运维脚本每天 etcdctl snapshot save /backup/etcd/etcd-$(date).db，然后 rsync 到一台内网备份服务器。快照文件未加密（etcd 原生不支持快照加密，文件里所有 Secret 都是 base64）。40+ 微服务，K8s Secrets 里存了约 30 组数据库密码、若干 API Token。

【现象 / 卡点】 合规审计发现三个问题，需要一次处理：

1. 暴露面不明：3 个节点里 2 个的 /backup/etcd/ 目录保留了 >90 天的快照文件，且磁盘没有全盘加密（裸 SSD）。我无法确认这 90 天内有没有人（或进程）读过这些文件——没有文件访问审计，没有 chattr +i，没有独立日志。
2. 轮换不敢一次做完：30 组密码分属 MySQL（12 组）、Redis（8 组）、PostgreSQL（6 组）、其他（4 组）。40+ 服务里有的有连接池（HikariCP / go-sql-driver），有的用长连接（gRPC over DB proxy）。一次性全换，怕某个服务没拾到 Secret 就断连。
3. 快照加密没有现成方案：不想引入 Vault / AWS KMS（3 节点自建、没有云依赖），但也不想像现在这样裸奔。

【已尝试的排查与结果】

• ls -lt /backup/etcd/ + stat 看 atime：atime 不可靠（mount 选项 noatime 开了），无法作为"谁读过"的证据；
• etcdctl snapshot status 确认快照完整，但没有访问日志；
• 试了 chattr +a（append-only）保护目录，但快照文件需要定期清理旧文件，append-only 反而卡住了清理脚本；
• 用 kubectl get secret -o jsonpath 导出了 30 组密码的清单，确认哪些服务引用了哪些 Secret（通过 Deployment 的 env / volumeMount 反查），但 无法确认哪些服务当前连接池里还缓存着旧密码；
• 看了社区关于安全加固"反噬效应"和"可用性让步"的讨论，确认这个场景确实卡在"安全做扎实了、恢复/轮换反而变难"的矛盾上。

【期望得到的答案形态】

1. 暴露面评估：在没有文件审计日志的前提下，有哪些可操作的取证手段？（比如：检查 cron / systemd timer 的 rsync 日志、备份服务器上的文件 inode 时间线、auseaudit 是否来得及补装？）——给出一个"尽力而为"的 checklist，而不是"上 SIEM"。
2. 分批轮换方案：30 组密码、40+ 服务，具体怎么排批次？
   • 批次粒度（按数据库实例？按服务重要性？按连接池类型？）；
   • 每批次内的切换顺序（先改 DB 侧密码 → 再更新 K8s Secret → 再滚动重启？还是反过来？）；
   • 连接池里旧连接怎么"优雅排空"（HikariCP 的 connectionTimeout / maxLifetime 怎么配合？）；
   • 回滚预案：某批次切换后 P99 抖动，怎么 30 秒内回退？
3. 快照最小加密方案：不引入 Vault / KMS 的前提下，etcdctl snapshot save → openssl enc -aes-256-cbc → 密钥存哪里？怎么保证"备份服务器宕机时能恢复"又不让密钥和密文放一起？给一个最小可落地的脚本框架。

谢谢。