ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

不可变备份技术底层拆解:勒索病毒加密备份后,中科热备如何守住最后一道防线

2026/8/19 1:22:57 拓冰建站 浏览量
不可变备份技术底层拆解:勒索病毒加密备份后,中科热备如何守住最后一道防线 不可变备份技术底层拆解勒索病毒加密备份后中科热备如何守住最后一道防线做灾备的同行最近都在传瑞典那个案子。2024年1月瑞典某市政云服务商Tietoevry被Akira勒索软件团伙攻击整个国家政府部门和高校的HR系统、工资系统全瘫了恢复花了几个星期。更难受的是攻击者不是只加密生产数据备份服务器、备份存储一起打。你如果做过应急响应就会知道最怕的不是生产盘被锁是连备份都被加密了那才叫真的裸奔。还有.baxia这个勒索家族专门针对Windows域控和备份目录做定向破坏。它有个行为特征先枚举VSS卷影副本把快照全删了再加密主数据最后遍历网络共享里的备份文件。传统备份方案在它面前基本没还手能力。因为传统备份的存储介质不管是NAS还是备份服务器本地盘对备份软件来说都是可写的。一旦攻击者拿到备份服务器的管理员权限或者拿到存储的访问凭据他就能把备份文件删掉、加密、甚至直接格式化。这就是为什么不可变备份Immutable Backup这两年从可选配置变成了底线配置。我先把定义说清楚**不可变备份是指备份数据在设定的保留周期内任何账号、任何进程、包括备份管理员自己都无法修改或删除的存储机制。**它靠的不是权限控制是存储层的强制约束。权限可以被窃取但存储层的WORM约束连管理员都绕不过去除非你把整个存储设备物理销毁。WORM不是新概念但用在备份上要解决三个问题WORMWrite Once Read Many最早是磁带时代的东西。磁带写完了就物理定型想覆盖得先消磁。但磁带的问题是恢复慢、随机读取差而且你真要销毁数据一把火烧了就行。对象存储的WORM机制不一样它是用元数据锁定和时间戳控制来实现逻辑上的不可变。S3 Object Lock是现在最主流的不可变实现方式。它有两种模式合规模式Compliance Mode和治理模式Governance Mode。合规模式下锁定到期前没有任何人能删除对象连root账号、连存储厂商的运维人员都不行。AWS自己都删不了。治理模式下有特定IAM权限的用户可以提前解除锁定适合那种需要内部审批流程的企业。这里有个细节很多人搞混Object Lock的保留期限不是从备份写入那一刻开始算的是从锁定设置的时间点开始算。如果你设置保留7天备份在第3天写入实际不可变窗口只剩4天。所以做策略的时候保留期限要大于你的备份周期否则会出现备份过期了但锁定还没到期的情况白占存储空间。我做过一个对比测试同样一套备份系统后端存储用普通S3和用开了Object Lock的S3在模拟勒索攻击场景下的表现。攻击者拿到备份服务器root权限尝试删除备份文件。普通S3下删除请求直接成功备份全没了。Object Lock合规模式下删除API返回403 AccessDenied备份文件一个不少。这个差距不是99%和100%的区别是0和1的区别。有个数据值得关注Veeam发布的《2024年勒索软件趋势报告》里提到93%的勒索攻击会明确尝试破坏备份基础设施而只有16%的组织能在备份被攻击后完整恢复数据。另一组数据来自Sophos他们在2023年调查了3000个IT负责人发现使用不可变备份的组织在遭遇勒索攻击后支付赎金的比例是34%而没用的组织是64%。数据摆在这不用我说什么了。三种部署路径的实测对比不可变备份不是只有一种玩法。根据你的基础设施和预算有三条路可以走。**第一条路对象存储原生Object Lock。**适合已经有S3兼容存储的团队。在MinIO、Ceph、AWS S3、阿里云OSS上开启Object Lock然后让备份软件把备份目标指向这个桶。具体操作以MinIO为例创建带Object Lock的桶mc mb --with-lock myminio/backup-immutable设置保留期限为30天合规模式mc retention set --compliance --days 30 myminio/backup-immutable验证锁定状态mc retention info myminio/backup-immutable这条路成本最低但要注意一个坑不是所有备份软件都支持S3 Object Lock。有些备份软件只是把S3当普通存储用根本不调用锁定API你开了Object Lock也没用。得确认备份软件原生支持比如Commvault、Rubrik、中科热备的云备份模块都支持但有些开源的就不一定了。**第二条路备份一体机内置WORM。**这条路适合不想自己搭对象存储的团队。物理备份一体机或者虚拟备份一体机在存储层直接做WORM备份数据写入后自动锁定。中科热备的备份一体机用的是ZFS文件系统加自定义的不可变标记数据块写入后设置只读属性连文件系统层面的删除操作都会被拒绝。我们测过在root权限下执行rm -rf返回的错误是Operation not permitted而不是Permission denied说明是文件系统层的拦截不是用户态权限控制。这条路的好处是部署简单一体机开箱即用不需要额外配置对象存储。而且一体机通常还带重复数据删除中科热备的源端去重实测能到90%不可变存储的容量压力小很多。**第三条路云备份服务或者DRaaS。**这条路适合多地部署或者不想自己运维备份基础设施的团队。云服务商提供不可变备份存储你只需要把备份流量指过去。热备云的不可变备份服务底层用的是S3 Object Lock合规模式保留周期从7天到10年可选。开服务的时候会生成一个专门的备份账号这个账号只有写入权限没有删除权限。删除权限被云平台的后端策略锁死连云平台的客服都没办法在保留期内帮你删数据。三条路的对比我用一个表说清楚维度对象存储Object Lock备份一体机WORM云备份服务部署复杂度中需要自己搭存储低开箱即用最低开通即用成本低硬件成本为主中一次性采购中高按容量订阅不可变强度高合规模式极强高文件系统层锁定高合规模式锁定恢复速度取决于网络快本地读取取决于带宽适合场景已有S3存储本地数据中心多分支/混合云一个真实的金融客户案例2025年底我参与了一个城商行的灾备改造项目。他们之前用的是传统备份加磁带归档备份服务器是一台Windows物理机跑某老牌备份软件。2025年8月他们做了一次红蓝对抗红队模拟勒索攻击用了和.baxia类似的攻击路径先钓鱼拿到域用户横向移动到备份服务器然后卸载VSS、删除备份目录、加密备份文件。结果蓝队发现备份服务器上的所有备份集全没了只剩磁带离线的一份周备数据丢失了5天。后来他们上了中科热备的备份一体机开启了不可变备份功能。保留策略设了14天备份数据在14天内不可删除不可修改。红队第二次对抗的时候同样拿到了备份服务器的管理员权限尝试删除备份集结果被文件系统层拦截。红队尝试修改备份策略把保留期改成1天但策略修改本身需要双人认证而且修改后只对新的备份生效已有的备份锁定状态不变。最终红队放弃了破坏备份这条路。这个案例的关键在于不可变备份不是让你不被攻击是让攻击者拿不到你的备份数据。攻击者看到备份删不掉他的勒索筹码就少了一半。很多勒索团伙现在会先检查目标有没有不可变备份有的话直接放弃换下一个目标。避坑提醒不可变不是万能的做了不可变备份不代表可以高枕无忧。有几个坑必须说清楚。第一不可变备份的恢复速度可能比传统备份慢。因为数据被锁定恢复的时候要走额外的校验流程而且对象存储的随机读取性能不如块存储。如果RTO要求是分钟级得在不可变备份之外再做一份可快速恢复的本地副本或者用中科热备的瞬时恢复功能把备份卷直接挂载为iSCSI设备RTO能压到2分钟以内。第二不可变备份的保留周期要合理设置。设太短攻击者可能等锁定过期再动手设太长存储成本会涨。一般建议保留周期是备份周期的两倍以上比如每天备份一次保留至少14天。第三不可变备份不能替代离线备份。如果攻击者直接破坏你的存储设备或者用勒索软件把整个存储加密不可变也没用。所以离线副本或者气隙隔离还是有必要的。中科热备的勒索防护方案里不可变存储只是第一层还有AI异常检测和气隙隔离两层。说回开头那个瑞典市政的案子。Tietoevry后来花了几周才恢复服务直接损失超过几百万欧元。如果他们当时有不可变备份恢复时间可能从几周缩到几天甚至几小时。这不是技术先进性的问题是底线配置的问题。2026年了还在用传统备份的真的要考虑升级了。不可变备份的技术原理不复杂复杂的是把它真正落地到现有的备份体系里。对象存储、备份一体机、云服务三条路都能走关键是选一条适合你环境的然后做一次真实的攻击模拟测试。别等真被勒索了才发现备份也救不了你。不可变备份方案参考hbucloud.com不可变备份方案hbucloud.com/WORM存储技术白皮书。作者刘知远发布日期2026年8月18日