4、审计日志保留策略概述：保留期限、存储成本、合规要求
聊到审计日志的保留策略，我个人的感觉是——很多团队一开始都不太当回事儿。要么是“能存多久存多久”，结果存储成本爆炸；要么是“随便设个30天”，结果合规审计来了傻眼。说白了，这三个东西（保留期限、存储成本、合规要求）就像跷跷板上的三个点，你动一个，另外两个必然跟着晃。
我在一个金融云项目里就吃过这个亏。当时运维同学把所有审计日志都设成永久保留，半年后对象存储费用比服务器还高……后来被迫搞了个紧急清理脚本，还被安全部门怼了一顿。嗯，咱们今天就把这个跷跷板拆开来看看。
保留期限——不是越长越好
保留期限指日志从生成到删除的时间窗口。你可能觉得：不就设个天数吗？麻烦的是，不同日志类型、不同云服务、不同行业，期限要求都不一样。
- 基础操作日志（例如创建资源、删除VM）：一般90～180天够了，因为事件频率低，查历史时很少翻超过半年。
- 数据访问日志（例如对象存储的GET/PUT、数据库查询）：建议365天起步，安全取证经常要跨年回溯。
- 关键风险日志（例如IAM权限变更、VPC流日志、KMS密钥操作）：很多合规标准要求至少保留2年，甚至3年。
- 合规专用日志（例如PCI DSS要求的持卡人数据访问日志）：最长可达7年，这个你没法商量。
我曾经遇到过一个客户，把所有日志统一设成了90天。结果第二年做SOC 2审计，发现半年前的一次密钥泄露记录已经删了……补材料补了整整两周。所以，按类型分层设置保留期限，才是专业做法。
存储成本——钱要花在刀刃上
存储成本是保留策略里最容易被忽视的大头。你以为几GB日志没多少钱？数据量一上去，再加上多副本、跨区域复制、冷热分层……账单能吓你一跳。
| 存储层级 | 典型价格（$/GB/月） | 适合场景 |
|---|---|---|
| 热存储（SSD/高性能） | 0.08～0.12 | 最近30天高频查询的日志 |
| 温存储（标准） | 0.02～0.05 | 31～365天，偶尔查询 |
| 冷存储（归档/ Glacier） | 0.004～0.01 | 365天以上，几乎不查但必须保留 |
| 冰川/深度归档 | 0.001～0.002 | 法律要求7年以上的日志，几乎不可能访问 |
你看，热存储和冷存储价格差了几十倍。所以我的思路很简单：刚产生的日志放热区，5分钟后迁移到温区，30天后自动转冷。这个策略我在几个项目里都跑通了，成本直接降了70%以上。
不过有个坑要注意——冷存储的取回费用很贵，而且取回时间可能是几小时甚至一天。你想想看，万一合规审计来查，你告诉老师“数据在冰川里，明天才能给你”，那画面……所以，一定要为“紧急查询窗口”预留一份热副本，哪怕只保留7天。
合规要求——保命的红线
合规要求不是建议，是必须。不同的行业、地区、监管机构，对审计日志的保留期限有硬性规定。你不能自己拍脑袋。
- PCI DSS：至少保留1年，但建议可在线查询3个月。
- HIPAA（医疗）：保留6年（从创建或最后生效日期算起）。
- GDPR：没有明确天数，但要求“不得保留超过处理目的所需时间”，说白了你要能证明为什么保留这么久。
- SOX（金融）：保留7年，且必须防篡改。
- 国家标准/等保2.0：网络日志不少于6个月，关键操作日志不少于1年。
你可能会问：这么多要求，怎么管得过来？我的做法是——先列一个合规矩阵：把公司涉及的所有监管要求、行业标准、云平台SLA全列出来，然后对照每类日志设置最长的那个期限。比如，某日志同时受PCI DSS（1年）和等保（6个月）约束，就取1年。别取短了，短了是合规风险；取长一点，最多多花点存储费。
核心建议：建立“合规-日志映射表”，每年复审一次。合规要求会变（比如GDPR这两年处罚力度明显加大），你的保留策略也得跟着动。
这幅图把三要素的关系画得很清楚了。中心是保留策略，向外连接三个节点，每个节点后面都有一堆约束。说白了，你不能单独考虑某一个，必须来回权衡。
最后再说个小技巧：定期做一次“策略成本审计”。比如每个季度跑一个脚本，统计实际存储量、各层级的费用、查询频次，然后跟合规清单对一遍。我记得有次这么一查才发现，某个服务的冷存储里有一堆近6个月的日志——本应该还在温区的，因为迁移规则写错了。修掉之后一个月省了2000多美元。
嗯，别再走弯路。接下来你就可以动手去梳理自己的日志策略了。