访问日志便于排查故障、分析请求和识别异常，但完整 IP 地址、查询参数、Cookie 或身份令牌也可能暴露个人信息。落实内容分发服务的访问日志隐私脱敏规范，重点不是把日志全部删掉，而是让每个字段都有明确用途，并只保留完成该用途所需的信息。
下面五项要求适用于提供内容分发、网站托管或类似请求转发能力的服务。具体法律义务应按业务所在地和数据类型核对；在中国处理个人信息时，还应关注《个人信息保护法》关于目的明确、最小必要和保存期限的要求。
一、先盘点字段，再按用途采集
列出日志中的客户端地址、请求路径、查询参数、时间、状态码、来源页、User-Agent、Cookie 和请求头等字段，逐项标注用途、敏感程度、保存位置和责任人。排障通常需要路径、状态码和耗时，却未必需要完整请求头或完整查询串。
在 Nginx 等 Web 服务器中，检查访问日志格式是否记录了完整请求目标；如果分析只需路径，可避免把查询参数一并写入日志。对于无需采集的 Cookie、Authorization 等认证字段，应从记录环节排除，而不是等日志落盘后再处理。
二、对直接标识符做适度脱敏
IP 地址可按用途截断或掩码处理。例如，IPv4 将末段置零能保留部分网段信息，但仍可能与其他数据结合识别用户；IPv6 可配置保留的网络前缀长度。用于安全调查且确需原始地址时，应单独限制访问并缩短保存时间。
脱敏强度要与用途匹配：粗粒度地址适合统计地域或流量趋势，精确地址更适合短期安全排查。内容分发服务的访问日志隐私脱敏规范不应被理解为一种固定掩码格式，服务方需要记录选择理由，并评估重识别风险。
三、清洗查询参数和身份令牌
查询参数可能携带邮箱、订单号、搜索词或临时令牌。按允许名单保留确有分析价值的参数，其余参数删除或统一替换；不要把整段查询串原样写入分析平台。对 Cookie、会话标识和认证头，默认不记录明文值。
确需跨请求关联时，可使用带密钥的 HMAC 生成假名标识，并把密钥与日志分开保管、按计划轮换。普通哈希并不等同于匿名化：标识空间较小或可枚举时，攻击者可能还原原值。
四、限制访问并保留审计记录
按岗位授权：运维排障人员只访问必要时间段和字段，分析人员优先使用脱敏副本，导出原始日志须经过审批。集中日志平台、对象存储和备份都应纳入同一权限边界，并记录查询、下载、授权变更等操作。
定期检查账号权限是否仍有业务需要；离岗或职责变化时及时撤销。若日志供外部处理方使用，应确认其处理目的、访问范围、保密措施和删除安排，避免通过报表或工单重新暴露被遮蔽的信息。
五、设定期限并验证删除
为不同用途分别设置期限：例如，将常规排障日志的内部默认留存期先设为约 7 至 30 天，再依据故障处理周期、风险评估和适用法律调整。这是可供评估的管理起点，不是通用法定期限。需要更久保存的安全事件记录，应单独标记理由、审批人和到期时间。
到期后不仅要清理在线日志，还要核对归档、复制件和备份的删除策略。无法立即从周期性备份中逐条删除时，应限制其恢复和访问，并在备份轮换时完成清除。
落地检查：按顺序完成五步
- 抽样盘点：从 Nginx、Apache httpd 或日志平台抽取配置与样例，识别实际写入的字段。
- 分类定用途：为每个字段标注用途、是否含个人信息、是否可删，以及谁可以访问。
- 在源头改造：优先关闭无用字段，对地址、查询参数和标识符实施截断、过滤或假名化。
- 检查全链路：验证日志代理、分析系统、导出文件和备份没有保留未脱敏副本。
- 留存证据：保存配置变更、抽样检查结果、权限审批和删除记录，并在字段或用途变化时重新评估。
执行效果可通过定期抽样验证：检查是否出现令牌、完整查询参数或不必要的原始地址，并测试普通分析账号能否访问原始日志。内容分发服务的访问日志隐私脱敏规范的核心，是把最小采集、分级保护和到期删除落实到配置与流程，而不是只在文档中声明。
常见问题
脱敏后的日志还算个人信息吗？
不一定。若仍可通过其他数据识别或关联到个人，就不能仅凭已脱敏认定为匿名数据，应按适用规则继续保护。
能否只在分析平台脱敏？
不建议。原始日志可能已进入缓存、传输链路或备份；能在采集端排除的敏感字段，应尽量在源头处理。
安全排查必须保存完整 IP 吗？
不必一概如此。先评估是否可用截断地址、短期受控原始记录或事件级留存满足排查需要，再限制访问并设定到期删除。
留存期限应该设成多少？
没有适用于所有场景的统一天数。结合故障响应周期、业务目的、风险和法律要求确定，并定期验证到期数据确已清理。