wiredtiger加密对gridfs勒索无防护作用，因其仅加密磁盘文件防物理窃取，无法阻止病毒获权后执行remove/drop清空fs.files与fs.chunks集合；真正有效的是访问控制、ip绑定、审计日志、延迟副本集及快照备份。
GridFS 本身不提供加密能力，开启 WiredTiger 加密存储引擎也无法保护 GridFS 文件内容免受勒索病毒直接删除或覆盖。 它只加密磁盘上的 wiredtiger.wt 等数据文件，而勒索病毒一旦获得数据库写权限（如未启用认证、暴露在公网），可直接执行 db.fs.files.remove({}) 和 db.fs.chunks.remove({}) 清空全部 GridFS 数据——此时加密毫无意义。
为什么 WiredTiger 加密对 GridFS 勒索无实际防护作用
WiredTiger 的静态加密（at-rest encryption）仅防止物理磁盘被盗后被离线读取。但勒索病毒攻击路径通常是：通过弱口令 / 未绑定 IP / 无认证的 MongoDB 实例登录 → 获取 admin 或读写权限 → 主动删除或覆盖 fs.files 和 fs.chunks 集合。加密引擎对此类逻辑层破坏完全不设防。
- 加密不等于访问控制：即使启用了
enableEncryption: true，只要连接能进、权限够大，remove()、drop()照样执行 - GridFS 是逻辑结构：它只是两个普通集合（
fs.files+fs.chunks）的约定用法，WiredTiger 不识别也不特殊保护它们 - 备份链路更关键：真实恢复依赖的是快照、副本集延迟节点、或外部备份，而非磁盘加密
真正有效的 GridFS 防勒索配置组合
必须从“阻断入口”和“保留恢复能力”两端下手，单靠存储引擎加密是典型的安全错觉。
- 强制启用基于角色的访问控制：
mongod --auth启动，并在admin库中创建最小权限用户，例如只授予readWrite到特定数据库，**绝不使用 root 或 dbOwner 角色操作 GridFS** - 绑定内网 IP 并禁用公网监听：
--bind_ip 127.0.0.1,192.168.10.5，避免--bind_ip 0.0.0.0这类高危配置 - 为 GridFS 操作单独建库并启用审计日志：
mongod --auditDestination file --auditFormat JSON --auditPath /var/log/mongodb/audit.log，重点监控remove、dropCollection行为 - 设置副本集并启用
slaveDelay：例如配置一个延迟 24 小时的 secondary 节点，它不会同步勒索操作，可作为紧急回滚源
被勒索后 GridFS 数据能否恢复
取决于是否还有未被覆盖的底层数据块。MongoDB 删除操作本质是标记文档为“可复用”，不是立即擦除磁盘；但一旦有新写入（如日志滚动、其他业务插入），旧 chunks 就可能被覆盖。
- 立即停机：发现勒索后，**立刻停止 mongod 进程，不要重启、不要 compact、不要做任何写操作**
- 检查
db.fs.files.countDocuments()和db.fs.chunks.countDocuments()：若返回 0，说明元数据已清空，需依赖文件系统级恢复（如 ext4 的extundelete）或快照 - 若部分文件仍在，用
mongodump -d yourdb -c fs.files -c fs.chunks紧急导出剩余数据，再尝试用mongorestore恢复到隔离环境 - 注意：GridFS 文件名、上传时间等元信息存在
fs.files，一旦该集合被删，就无法按原始名称还原，只能靠_id和filename字段残留判断
最常被忽略的一点：GridFS 恢复成败，80% 取决于你有没有在勒索发生前启用副本集延迟节点或定期快照。加密存储引擎既不能阻止删除，也不能帮你找回已删的 fs.chunks 文档——它只让硬盘小偷看不懂你的 0101，却拦不住管理员自己把整个保险柜砸了。
