企业将业务流量交给CDN分发后，源站看到的访问记录往往不再完整，一旦面临等保2.0三级测评或ISO27001外部审核，审计人员首先会追问：用户通过CDN访问系统的完整日志在哪里？保存了多久？能否追溯到具体IP和时间？这三个问题如果答不上来，测评结果很可能不理想。本文围绕阿里云CDN的日志能力，讲清楚如何搭建一套满足合规要求的日志留存体系。
一、先弄清楚合规条款对日志留存到底要求什么
等保2.0在安全计算环境和安全管理中心两个层面都提出了日志相关要求。其中最常被引用的是8.1.10.4和8.1.5.4条款：应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖，审计记录的留存时间应满足法律法规规定。而网络安全法第二十一条明确要求采取监测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月。这条是硬性红线，测评机构在现场核查时会直接查看日志保存周期配置。
ISO27001附录A中的A.12.4控制项同样强调事件记录和日志的保护，要求记录管理者、用户的活动、异常情况，并保护日志信息免遭篡改和未授权访问，同时规定了日志保护的操作程序。与等保相比，ISO27001更强调日志的完整性、防篡改能力以及访问控制策略，审核员通常还会要求提供日志审查的操作记录，也就是你不仅要有日志，还要证明有人定期在看日志。
对CDN场景来说，这两套体系的共同要求可以归纳为四点：日志内容完整（包含时间、源IP、URL、状态码、流量等关键字段）、留存时间达标（不低于六个月）、存储可靠且防篡改（集中存储并限制访问权限）、可检索可审计（出现安全事件时能快速回溯）。阿里云CDN默认控制台只能查询近三天的实时日志和一定期限的离线日志，显然无法直接满足六个月的要求，必须通过日志投递能力将日志外发到持久化存储中。
二、配置CDN实时日志投递，把日志集中落地到SLS
阿里云CDN提供了实时日志投递功能，可以将边缘节点产生的请求日志以秒级延迟推送到日志服务SLS的Project中。相比传统的离线日志（按小时打包成CSV放在OSS上），实时日志的优势是延迟低、字段结构化、可以直接使用SLS的查询分析和告警能力，更适合作为审计场景的首选方案。
开通步骤大致如下：首先在日志服务控制台创建一个专门的Project和Logstore，建议命名为独立的审计专用库，与其他业务监控日志分开管理；然后进入CDN控制台的实时日志页面，创建投递项目，选择需要采集的加速域名，勾选需要投递的字段并关联目标Logstore。关键字段建议至少包含以下内容：
# 实时日志投递建议勾选的核心字段 - unix_time # 请求时间戳，审计追溯的关键 - client_ip # 客户端真实IP - uri # 请求路径 - status # HTTP状态码 - user_agent # 客户端标识 - referer # 来源页 - hit_info # 缓存命中情况 - response_time # 响应耗时 - request_size / response_size # 请求与响应流量 - cdn_ip # 边缘节点IP
投递配置完成后，可以在SLS中执行一条简单查询验证日志是否正常到达：
-- 查询最近一小时某域名的访问日志 * | SELECT unix_time, client_ip, uri, status FROM log WHERE uri LIKE '/api/%' ORDER BY unix_time DESC LIMIT 100
这里有一个容易踩的坑：实时日志投递是按量收费的，大流量站点每天产生的日志条数可能达到数亿条，如果不加规划直接全量投递，日志费用可能超过CDN本身的费用。合规视角下不能随意丢弃日志，但可以做成本优化，例如对静态资源类域名只投递核心字段，对API类域名投递全量字段；或者结合业务敏感度分级，将不同域名的日志投递到不同Logstore，分别设置保存周期。
三、设置六个月以上的留存周期并做好防篡改保护
日志落地之后，第一件事是检查Logstore的保存时间。SLS默认保存周期为30天或90天，必须手动调整为不少于180天。对于安全等级要求更高的系统，建议设置为365天，给审计追溯留出更充裕的时间窗口。修改方式很简单，在Logstore的属性设置中调整TTL即可：
# 通过aliyun CLI将日志保存周期调整为365天 aliyun log put_logstore \ --project-name cdn-audit-logs \ --logstore-name cdn-access \ --ttl 365 \ --shard-count 4
仅仅保存够久还不够，等保2.0要求日志免受未预期的删除和修改。实践中可以从三个层面加固：第一，使用RAM权限精细化管控，只为审计岗位的账号授予SLS的只读权限，禁止运维人员随意删除Logstore或修改TTL；第二，开启SLS的日志投递到OSS的功能，将日志再归档一份到OSS，并启用OSS的合规保留策略（WORM特性），设置保留期内任何人都无法删除和覆盖对象，这是应对防篡改审计要求最有效的手段；第三，定期将关键查询结果导出并离线备份，形成多重保障。
归档到OSS时，建议使用Parquet或ORC等列式存储格式，既能压缩体积降低长期归档成本，又便于后续用Athena类工具做离线分析。归档任务在SLS控制台的投递配置中设置即可，支持按天分区存储，方便按需拉取某一天的日志做回溯。
四、让日志真正可审计：检索、告警与报表输出
很多企业日志留了半年，但审计人员要求演示回溯某个安全事件时却拿不出结果，问题出在缺乏检索和审查的闭环。SLS自带查询分析能力，常用的审计场景可以直接用查询语句覆盖，例如快速定位可疑扫描行为：
-- 找出最近一天状态码为404次数最多的IP，识别扫描行为
* | SELECT client_ip, count(*) AS cnt
FROM log
WHERE status = 404
AND unix_time > to_unixtime(date_trunc('day', now()))
GROUP BY client_ip
ORDER BY cnt DESC
LIMIT 20还可以基于SLS的告警功能设置安全监控规则，比如单IP在五分钟内请求数超过阈值、404比例突然升高、出现大量敏感路径的访问等，触发告警并通知安全值班人员。这些告警配置本身就是等保测评中入侵防范和安全管理中心条款的加分项，测评时直接展示告警记录和处理流程即可。
针对ISO27001的日志审查要求，建议建立固定的日志审查制度并留痕。可以每周在SLS中执行几条固定的审计查询（异常登录、高频错误、敏感接口访问），将结果导出为报表存档，由安全负责人签字确认。这样在年度外审时，不仅能证明日志保存了足够长时间，还能证明组织确实在按规程使用这些日志，形成完整的管理证据链。总结来说，一套合规的CDN日志体系等于实时投递加长期留存加防篡改归档加定期审查，四个环节缺一不可，提前规划好这套流程，无论是等保测评还是ISO27001审核都能从容应对。