定义
Audit Log（审计日志）记录用户登录、配置变更、OTA 下发、设备删除等关键操作，包含操作人、时间、对象、结果等信息。用于安全审计、合规追溯与 RCA 根因分析，配合 RBAC 实现权限可追溯。
记录范围与字段
审计日志通常包含：操作主体（用户 ID、IP、客户端）、操作类型（创建/修改/删除/下发）、操作对象（设备、产品、固件等）、操作前后快照或变更摘要、时间戳（建议 UTC 存储）、操作结果（成功/失败及原因）。设备管理平台需对敏感操作如批量删除、证书吊销、OTA 全量推送等做强制审计。
合规与留存
金融、医疗、能源等行业对审计日志有明确合规要求，如日志不可篡改、留存期限（通常 6 个月至数年）、可导出供监管审查。平台可采用 WORM 存储、哈希链或区块链存证增强不可篡改性，并支持按时间、操作人、对象类型等多维度检索与导出。
与运维分析结合
审计日志与 RCA 根因分析结合，可追溯故障前的配置变更、批量操作，快速定位人为误操作。配合 RBAC 权限模型，可实现「谁在何时对何对象执行了何操作」的完整审计链，满足等保、ISO 27001 等安全标准要求。
哪些动作必须留下不可改记录
审计日志的技术含义不是把所有接口流量都存下来，而是对会改变设备命运的动作单独落一条不能事后改写的记录。登录成功与失败、凭证重置、权限变更、批量删除、固件下发、远程控制里的重启和恢复出厂，都属于这一类。每条记录至少要能回答四个问题：谁发起、从哪里发起、作用在哪一个对象、平台判定成功还是拒绝。对象要写稳定标识，例如设备标识和产品标识，不要只写当时的显示名称，因为名称随后会被人改掉。
使用条件是平台已经能区分操作者身份，并且关键写操作都经过同一条鉴权路径。绕过控制台、直接改数据库或由脚本调用内部接口的动作，如果没有进入这条路径，审计就是缺口的。日志应在动作提交时写入，而不是等业务成功后再补；失败和拒绝同样要留，否则暴力尝试和越权调用看不见。留存期间只允许追加，不允许运营人员改时间和结果。需要和设备凭证变更一起看时，重置密钥和吊销证书必须各记一笔，否则无法解释设备为什么突然认证失败。
事后追溯时对不上人的原因
最常见的偏差是许多人共用一个管理员账号，日志里只能看见这个账号，无法对应到当班的人。另一个偏差是只记录“下发成功”，不记录下发了哪一版配置、作用在哪一批设备，事后无法复原现场。时钟若用各自服务器的本地时间且没有统一来源，跨节点的操作顺序会颠倒，排查时会以为后发生的改动才是原因。导出时如果把前后快照裁成一句“已修改”，审计就失去核对价值。
还要注意系统任务和人的操作混在同一列却不标明发起方。定时同步、规则引擎自动下发若显示成某个用户，会把自动动作误判成人为失误。相反，把人的批量操作记成“系统”，又会让责任落空。查询时要能按对象、动作类型和时间收窄，而不是只能整库下载。下行指令的审计应保留指令种类和目标设备，但不要把密钥、口令原文写进日志正文。日志本身若含明文凭证，审计库会变成新的泄露面。
导出的记录怎样才算能核对
审计如果不能按对象把一段时间内的动作按顺序还原，就只是一堆无法核对的文本。导出的每一行应带有不可被导出者修改的时间、动作、对象标识和结果，并说明这条记录是人发起还是系统任务发起。只导出成功记录，会让人以为某段时间没有人尝试过危险操作。时间应来自平台统一的时钟，导出文件里还要注明时区，否则把文件拿到另一个地区打开，顺序会和现场值班表对不上。对象要用稳定标识，显示名称可以另附一列，但不能代替标识，因为名称会在事后被改掉。
留存期内的记录被归档后，仍要能按原条件查到，而不是只在热存储里可检索、冷存储里只剩无法检索的压缩包。校验导出是否完整时，可以核对这段时间的记录条数和首尾时间，而不是只看文件能不能打开。若发现缺了某一次批量删除，应视为审计缺口，而不是用回忆补一句说明。操作者本人不应拥有删除或改写自己记录的权限，审批别人导出范围的人也不应能改写已经被导出的内容。否则日志只能证明系统曾经有过这个功能，不能证明现场发生过什么。