Snowflake遭遇ACCOUNTADMIN被盗恶意攻击后的恢复与防护咨询

可以恢复，核心逻辑如下：
DATA_RETENTION_TIME_IN_DAYS参数的修改仅对修改完成后新生成的数据快照生效，修改前已经存在的所有历史快照，仍然遵循修改前配置的保留周期规则。
只要攻击发生的时间距离当前没有超过原本配置的Time Travel保留周期，你可以直接通过UNDROP DATABASE/UNDROP SCHEMA/UNDROP TABLE命令恢复被销毁的对象，也可以通过时间点克隆语法恢复到攻击发生前的任意时间点。如果已经超出Time Travel保留周期，还可以申请Snowflake支持团队通过Failsafe能力恢复数据。

该认知不正确。
Failsafe确实是在Time Travel保留周期结束后才生效，但Failsafe本身有独立的保留时长：对于企业版及以上版本的永久类数据库对象（永久表、永久库等），Failsafe保留周期为7天。也就是说如果原本Time Travel设置为90天，攻击发生后最长可以在97天内申请恢复数据，而非只能恢复到90天前的状态。
注意：Failsafe的恢复操作只能由Snowflake官方支持团队执行，用户侧没有自主操作权限，且仅针对永久类对象生效，临时表、瞬态表不提供Failsafe能力。

• 严格遵循最小权限原则：收紧ACCOUNTADMIN角色的授权范围，仅给极少数核心运维人员分配该角色，日常操作使用权限更小的自定义角色，禁止业务人员、普通开发人员持有高权限角色。
• 强制高权限角色开启MFA：所有持有ACCOUNTADMIN、SECURITYADMIN等高权限角色的账号必须开启多因素认证，避免账号被盗后直接获取高权限。
• 配置参数修改限制：通过账户级策略约束DATA_RETENTION_TIME_IN_DAYS的最小取值，禁止普通角色修改该参数，仅允许指定的安全管理员角色调整保留期配置。
• 开启高危操作审计与告警：对修改数据保留期、DROP数据库/模式/表、修改权限配置等高危操作开启实时审计，配置异常告警规则，发生可疑操作时第一时间通知安全团队响应。
• 定期做独立备份：除了依赖Snowflake原生的Time Travel和Failsafe能力，定期将核心数据克隆到独立的备份库、或者导出到离线对象存储中留存，备份数据设置独立的更严格的权限控制，避免被攻击者同时销毁。
• 配置对象删除保护：对核心数据库/表开启DROP_PROTECTION参数，开启后即使持有DROP权限也无法直接删除对象，需要先关闭保护才能执行删除操作，给攻击响应留出缓冲时间。

内容的提问来源于stack exchange，提问作者Hans Deragon