3. 日志保留周期定义：12个月与3个月的那些事
日志保留周期，说白了就是你的日志文件要在磁盘上躺多久。
PCI DSS 3.2.1 的要求其实很简单：至少保留12个月，并且最近3个月的日志要能在线快速访问。但你看，就是这么简单的两条，我在项目里遇到的坑可不少。
3.1 12个月的基本要求——为什么是整数？
很多人问我：为什么刚好12个月，不是6个月，不是18个月？
我个人习惯把这理解为“审计周期的覆盖需求”。你的安全事件可能在年底才被发现，而攻击痕迹可能藏在上半年的日志里。如果只保留6个月，你就只能看到冰山一角。
核心要点：
- 所有日志类型都必须满足12个月的可用性
- 计算起点：从日志生成之日起算，不是从存储之日
- 不能有“间隙”：1月1日到12月31日，一天都不能少
我的实战技巧：
我在项目中遇到过客户问我：“我们上个月才部署日志系统，之前的日志怎么办？” 我的回答是：从能够收集到的最早数据开始算，但至少保证之后12个月没有断档。
3.2 多久算一次“在线可访问”？3个月，不是开玩笑
嗯，这里要注意。PCI DSS 说的是 “可在线访问”，不是你备份到磁带后扔在仓库里算数。
最近3个月的日志，必须能在你的日常运维工具里直接查、直接搜、直接导出。不能等到审计师来了，你说“我这就去仓库找备份盘”。
| 时间范围 | 存储要求 | 可访问性 |
|---|---|---|
| 0-3个月 | SSD/高速磁盘 | 秒级查询、全文索引 |
| 3-12个月 | 冷存储/归档 | 可检索（允许稍慢） |
| 超过12个月 | 可删除或脱机存储 | 不要求可在线访问 |
你想想看，如果审计师要求你查3个月之前的一次访问记录，而你翻归档花了2天，这算不算违规？我的经验是：审计师看的是你的能力证明，而不是你“真的”花了多少时间。如果没法在合理时间内呈现，通常会被视为不合规。
3.3 例外场景说明——凡事都有意外
真的没有任何例外吗？也不是。以下是我在实际审计中认可的几种例外情况：
- 法律保留要求： 某些地区要求保留日志超过12个月（比如欧洲GDPR），这时你以更长的要求为准。
- 性能瓶颈： 高流量系统的日志每天以TB级增长，12个月的在线存储成本太高。你可以将超过3个月的日志转移到冷存储，但必须保证仍能“在线检索”，只是查询速度可以慢。
- 合规过渡期： 你在第10个月才符合12个月要求，前8个月的日志可以接受离线归档，但必须能恢复。
不要触碰的红线：
我曾经见过有人以“存储空间不够”为由，把6个月前的日志全部删除。结果审计时被直接开出了“未满足12个月保留期”的不合规项。任何主动删除日志的行为，必须事先得到审计或法务的书面批准。
3.4 实战配置示例
说到配置，我分享一种常见的做法。以Linux系统自带的日志轮转工具为例：
# rsyslog日志保留策略
# /etc/logrotate.d/rsyslog
/var/log/messages {
rotate 12
weekly
compress
delaycompress
missingok
notifempty
create 0640 root root
postrotate
/usr/bin/systemctl restart rsyslog.service > /dev/null 2>&1 || true
endscript
}
# 保留12周，约3个月
# 但这里的数字要按实际情况调整
注意，这只是一个基础配置。在生产环境里，我会额外增加一个归档脚本，把超过3个月但不到12个月的日志压缩后移到冷存储。
3.5 一张图看懂日志保留周期
3.6 常见误区与避坑指南
这些年我在审计一线，见过太多“以为合规但实际违规”的情况：
- 误区1：日志保留按“自然年”计算
不对。是按日志生成日期向后推12个月。比如2023年7月15日的日志，必须保留到2024年7月14日。 - 误区2：归档了就等于“可在线访问”
我曾经有个客户，把3个月以上的日志全部刻录到光盘放在资料室。审计时他们找一张特定日期的光盘花了整整一天。这显然不符合“可在线访问”的本意。 - 误区3：系统可以自动删除超过12个月的日志
系统可以自动做，但你必须有告警和控制。比如你在轮转脚本里加了“删除超过12个月”的规则，最好同时加上一个测试：每月检查一次，确保没有误删。
一个小诀窍：
不论是SIEM还是自建日志系统，我建议你在保留策略里加一个显性的“保留标签”。比如每一条日志都打上创建日期和计划删除日期。这样审计时一眼就能看出是否满足12个月的要求。
好了，日志保留周期的定义其实并不复杂，但你在落地上要考虑的东西很多。下一件事？嗯，是时候看看怎么把这条规则写进你的日志管理策略里了。