什么是审计日志？字段、保留和合规性
什么是审计日志？了解其记录的字段、保留时间，以及如何使其在合规和调查中具备可信度。
审计日志是按时间顺序记录的结构化记录，详细罗列了谁在何时、何地、对什么对象做了什么，以及产生了什么结果，保留这些记录是为了日后可以对活动进行核实。如果您只能看到某项操作已经发生，却无法指明操作者、操作对象或操作结果，那么您拥有的到底是一份证据，还是一条记录了某事发生的普通笔记？
这个问题揭示了各团队在讨论日志记录方式上的分歧。许多系统保存着充满事件的文件，许多供应商将其中任何一个文件都称为审计日志。单凭名称并不能说明任何问题。关键在于，数月后未参与其中的人员是否能够核查记录，以及该记录能否证明控制措施确实按预期运行。
目录
- 什么是审计日志以及企业为何保留审计日志
- 每条记录包含与排除的内容
- 审计日志与审计轨、应用日志及监控数据流的对比
- 哪些标准要求提供审计日志
- 保护完整性与设置保留期限
- 如何通过审计日志还原安全事件
- 在不破坏证据的前提下处理隐私请求
- 信任日志前需要澄清的误区与治理检查
什么是审计日志以及企业为何要保留审计日志
首先从可测试的定义开始。审计日志是一个按时间顺序排列的结构化记录，记录了谁在何时、从何地对哪个对象执行了什么操作，以及获得了什么结果。NIST 词汇表对审计日志的定义 将其界定为一个按时间顺序排列的记录，提供特定系统事件的书面证据，包括在指定期间内执行的访问和操作。
按时间顺序意味着顺序至关重要。结构化意味着每个条目都包含相同的字段，因此你可以搜索和比较条目，而不是阅读自由文本。凭证意味着记录的存在是为了供其他人日后依赖，而不仅仅是给编写代码的工程师看。
记录存在的原因
企业保留审计日志出于四个相互关联的原因。问责制将某个操作与能够为此承担责任的人员、流程或系统关联起来。调查允许团队在发生问题后重建事件序列。合规性能够证明所需的控制措施正在有效运行。变更重建则展示了某项记录或设置是如何达到当前状态的。
这些用途将审计日志与普通的错误日志文件区分开来。错误日志帮助开发人员查找 Bug，它可能记录了堆栈跟踪，但没有任何关于是谁触发了该操作的信息。而审计日志可以记录成功和失败的登录尝试、密码变更、特权使用、配置变更、数据修改、管理员操作以及访问尝试，无论在技术层面是否发生失败。
有效记录确立的六项事实
NIST 指南期望一条有用的审计记录至少确立六个事实：发生了什么事件、何时发生、何地发生、其来源、其结果，以及所涉及的人员、流程或实体的身份。缺失其中任何一项，记录的效力都会削弱。没有结果的记录无法说明变更是否生效；没有身份信息的记录则无法支持问责。
这些字段允许调查人员重建时间线、将授权活动与可疑行为区分开来、识别受影响的系统，并将某项操作与负责的身份联系起来。这就是实际的检验标准。随机挑选任意一条记录，并询问陌生人是否能仅凭该记录回答这六个问题。
从故障排查到问责追责
审计日志最初源于运维需求，作为一种排查系统故障的手段。随着企业需要记录来支持对非法或未经授权活动的监控、分析、调查和报告，审计日志逐渐转向正式的问责和网络安全证据。这种转变改变了您记录的内容。您不再只是为自己写笔记，而是在为未来可能质疑这些记录的读者撰写证据。
假设一个场所平台处理访客身份、同意状态变更、营销活动审批、集成和消息发送。一条合格的记录会记下谁更改了同意状态、审批何时发生、哪个记录或受众受到了影响，以及该操作是否成功。如果它仅显示“更新已完成”，无论这个文件叫什么名字，它都没有起到审计的作用。
每条记录包含的内容与排除的内容
每个事件都必须回答四个问题：何时发生、何地发生、谁发起或受其影响，以及发生了什么？OWASP 日志速查表 围绕这些问题构建其模式，并推荐使用一致的、机器可读的格式。
机器可读性至关重要，因为条目不会停留在单一系统中。您跨应用程序、身份识别系统、API 和基础架构进行查询与关联分析。OWASP 还建议将应用程序日志集中存储在日志服务器或 SIEM 中，因为本地孤立的记录在事件响应期间很难进行关联。如果条目以不同的格式分散在各个服务器上，您在调查时就会把时间耗费在格式转换上，而不是真正的事件调查。
审计日志条目的核心字段
| 字段 | 解答的问题 | 示例值 |
|---|---|---|
| Event ID | 具体是哪一个事件？ | evt_7Qx2，不可变 |
| Timestamp | 发生于何时？ | 2026-03-14T09:12:04Z, UTC |
| Actor | 由谁发起？ | j.smith，员工账户，角色为营销经理 |
| Authentication context | 如何验证发起人身份？ | 已通过 MFA 单点登录 |
| Scope | 受影响的租户或场馆是哪个？ | Venue 214，伦敦站点 |
| Source system | 由哪个应用或服务记录？ | 同意服务，Web 管理控制台 |
| Action | 执行了什么操作？ | consent.status.change |
| Object | 受影响的记录或受众是什么？ | 访客引用 G-48192 |
| Before and after | 发生了什么变更？ | 电子邮件同意状态，从已选择同意更改为已选择退出 |
| Authorization decision | 该操作是否被允许，依据哪条规则？ | 已允许，角色规则 ADMIN_CONSENT |
| Correlation or approval ID | 关联到哪个批次、审批或活动？ | 审批 APR-2210，批次 B-88 |
| Outcome | 成功还是失败？ | 成功 |
| Origin | 来自哪个网络或设备？ | 办公网络 IP 范围，托管笔记本电脑 |
有两个字段最常被遗漏，而它们恰恰是调查人员后续最需要的。授权决定不仅告诉您操作者执行了该动作，还说明其是否被允许这样做。关联 ID 则将数百个单独的变更链接回某次批量更新及其审批。如果没有关联 ID，批量导出看起来就像数百个毫无关联的事件，您将无法证明是谁批准了该批次操作。
实用规则：如果你无法将单个变更链接回批准该批次的授权，你就没有该变更的完整记录。
值得记录的事件
按风险对事件选择进行分组，而不是按应用程序碰巧发出的内容进行分组。
- 身份验证：成功与失败的登录、锁定以及 MFA 更改。
- 授权：权限授予、拒绝访问尝试和特权使用。
- 数据变更：创建、编辑、删除、导出和批量更新。
- 管理与配置变更：策略编辑、API 密钥创建和 webhook 变更（包括 webhook 验证失败）。
- 隐私与同意：选择加入（Opt in）、选择退出（Opt out）、访问请求和删除请求。
- 消息活动：审批决策、消息发送和发送失败。
这种分类能够确保您对覆盖范围保持客观透明。团队往往会全面记录数据变更，却完全忽略管理员的访问操作，而这恰恰是审计人员最先问及的内容。
绝不应放入记录中的内容
阅读审计日志的人比阅读源系统的人更多，且保存时间更长。这使其成为存储机密信息的危险场所。切勿记录密码、令牌、会话 cookie、加密密钥、支付卡数据或不必要的个人信息。
请改用类别、掩码值或稳定的引用标识来表示敏感数据。记录“支付方式已更新”以及对支付记录的引用，而不是记录具体的卡号。记录访客引用 ID，而不是在每条记录中重复记录访客的电子邮件地址和电话号码。
出于同样的原因，选择记录哪些内容必须经过审慎考量。记录所有内容会增加隐私暴露风险和存储成本，并掩盖关键事件。而记录太少会导致事后无法弥补的漏洞。你无法恢复从未写入的事件，因此请根据调查中需要确立的证据来选择覆盖范围，并将该推理过程文档化。
审计日志与跟踪记录、应用日志及监控数据流的对比
人们常常将审计日志与审计跟踪混用，争论这些词汇的字面差异意义不大。真正关键的区别在于治理 - 也就是记录如何得到保护、保留以及在收到请求时如何提供。两个系统可以包含完全相同的事件。作为证据进行治理的那一个，才是真正的审计记录。
审计日志与相关记录的对比
| 记录类型 | 主要目的 | 典型阅读者 | 保留模式 |
|---|---|---|---|
| 审计日志 | 证明谁在何时做了什么，以及结果如何 | 合规人员、调查人员、审计人员 | depositions按策略设定，数月至数年，分为热存储和冷存储层 |
| 审计追踪 | 相同的证据目的，通常作为同义词使用 | 合规人员、审计人员 | 与其所描述的审计日志相同 |
| 应用或调试日志 | 排查错误和行为故障 | 开发者、技术支持工程师 | 通常为数天至数周，短于审计记录 |
| 安全监控数据源 (SIEM) | 跨系统快速检测威胁 | 安全运营分析师 | 由监控团队设定的可搜索时间窗口 |
| 数据库事务日志 | 数据变更的恢复与复制 | 数据库管理员 | 由恢复需求决定，而非审计需求 |
| 版本历史 | 显示记录在每次修订时的状态 | 内容所有者、编辑人员 | 通常与记录本身一同保存 |
最关键的一项区分
审计日志必须保存具有可辩护性的历史证据。而监控数据源则针对快速检测事件进行了优化。这两个目标背道而驰。监控数据源可以进行采样、聚合和丢弃细节以保持高速运行。而作为证据的记录如果丢弃了不方便的条目，就无法再获得信任。
这并不意味着它们是竞争关系。将应用程序日志发送至中央日志服务器或 SIEM 是良好的做法，而且往往是相同的事件同时提供给这两者。由于分析师可以在一个地方查看跨系统的活动，检测能力得到了提升。但是，如果在调查人员提出调取请求之前，事件可能被过滤掉、被聚合概括或被轮换删除，那么单独的 SIEM 数据源并不能满足证据需求。
即使包含相同的事件，旨在快速发出警报的记录与旨在日后获取信任的记录，其承担的任务也是不同的。
辨别您正在查看的记录类型
问问自己，构建该记录是为了回答什么问题。“为什么此请求失败了？”指向调试日志。“现在是否有东西在攻击我们？”指向监控数据源。“我们可以回滚数据库吗？”指向事务日志。“上周二这个页面显示的是什么？”指向版本历史。
审计问题则不同。它是“谁做了这件事、他们是否获得批准，以及我们能否证明这一点？”如果记录无法回答这个问题，那么即使在策略文档中将其称为审计日志，也无法改变其性质。
哪些标准要求提供审计日志
当调查需要利用在安全事件被发现后依然完好保存的历史记录时，审计日志就成为了一项正式的控制措施要求。这是贯穿以下各项标准的主线。每一项标准都假定您会在活动发生后才察觉到问题，并且届时您仍需证实当时究竟发生了什么。
支付卡行业期望标准
遵从支付卡标准的组织面临着最为明确的框架要求。PCI 安全标准委员会指导意见设定了审计轨迹历史的最短留存期，并且该历史记录的一部分必须保持可立即用于分析的状态，而不是放在必须先恢复的归档库中。这种区分在运营层面非常重要。长期持久存储能在整个期限内保存证据。而可立即调用的存储则让您无需等待即可进行检测和响应。
该要求仅约束属于支付卡行业标准适用范围内的组织。如果您不处理银行卡数据，它不会直接适用于您。但这仍是一个有价值的参考，因为它区分了团队容易混淆的两个概念：保存证据与能够快速搜索证据。
NIST 与 OWASP 指南
NIST 指南采取了不同的方法。它要求组织识别其能够记录的事件类型，根据其安全和隐私目标选择所需的事件，记录为什么该选择能够满足事后调查的要求，并定期审查该选择。不存在通用的事件列表。组织的义务在于做出有据可依的选择并记录其理由。
OWASP 指南面向从业人员。它建议将日志保留足够长的时间，以便调查进展缓慢的事件并满足适用的合规义务，并将应用日志集中存储在日志服务器或 SIEM 中，以便进行关联分析。结合来看，NIST 要求您证明覆盖范围的合理性，而 OWASP 则要求您使该覆盖范围具备实用价值。
DORA 与特定行业职责
欧盟数字 Operational Resilience Act（简称 DORA）适用于受监管的金融实体和相关 ICT 提供商。该法案要求将 ICT 活动记录在支持调查和审计的表格中，涵盖数据访问、系统更改和管理操作等领域。发展方向非常明确。仅仅在某处存有日志并不是衡量标准。能够利用这些日志进行调查才是关键所在。
明确适用于您的要求
适用范围决定了一切，因此在选择事件类型或保留期限之前，请先明确适用范围。刷卡支付处理业务可能面临 PCI 合规义务。银行可能面临 DORA 监管。拥有多个场所的运营方可能均不直接属于这两者，但仍需要为其自身的治理、合同以及数据保护职责提供可靠的证据。
这最后一点是团队经常陷入误区的地方。即使不在某个明确命名的标准范围内，并不意味着无需履行问责责任。这仅意味着您需要自行设定要求并将其形成文档。如果您使用某个平台来处理访客数据，请检查合同中关于审计信息和子处理者的规定。我们在 数据处理协议 中为需要书面承诺的客户明确列出了这些承诺条款。
切勿盲目照搬您不适用的标准中的数字保存期限，并将其视为通用规则。请将其作为参考上下文，然后结合您的合规义务、调查需求以及存储成本来设定自己的保存期限。
保护完整性与设置保留期限
审计日志只有在其条目保持可信的前提下才有价值。应控制谁可以访问或删除记录，决定每类事件保存多久，并检查日志记录是否持续有效。如果同一个管理员既能更改同意状态，又能擦除记录该更改的条目，那么该记录就无法可靠地反映发生过的事件。
使条目具备可信度的完整性控制
将审计记录存储在仅追加或防篡改的存储库中，限制删除权限并对管理员访问进行单独监控。仅追加存储允许添加新条目，但能防止常规产品功能编辑或删除现有条目。单独监控意味着访问日志本身就会生成一条记录。
多种技术手段可以增强完整性：
- 哈希链（Hash chaining）： 每个条目的哈希均依赖于前一个条目。修改或删除任何条目都会破坏该链条。
- 已签名事件（Signed events）： 加密签名有助于验证条目确实来自于声明写入它的系统。
- 单写多读存储（Write-once storage）： 存储层防止条目写入后被任意修改。
- 独立时间戳（Independent timestamping）： 独立的时间源可确认条目的具体存在时间。
- 断档预警（Gap alerting）： 当出现序列断档或异常删除时触发告警。
选择适合您系统的控制措施并记录其工作原理。目标是使未授权的更改能够被检测和解释。既要记录已完成的操作，也要记录尝试进行的操作：授权失败、审批、执行结果以及管理变更。一次被拒绝的导出访客数据的尝试，可能比一次例行的成功编辑更为重要。
保留期限参考值
| 要求 | 参考值 | 背景说明 |
|---|---|---|
| PCI-DSS 审计跟踪保留时间 | 至少 1 年 | 受支付卡标准约束的组织 |
| PCI-DSS 即时可用历史数据 | 至少 3 个月 | 无需恢复归档即可直接用于分析 |
| 热数据期后的冷存储 | 剩余保留期内使用成本更低的归档 | 在降低存储成本的同时保持旧记录可用 |
这些原则适用于特定场景，而非通用规则。冷热存储分层有助于平衡查询速度和成本：近期条目保持快速检索，而较旧的记录则移至需要较长时间才能调取的归档中。如果所有内容都留在热存储中，成本压力可能会导致提前删除。如果所有内容都直接存入冷存储，数据调取可能会延误调查进度。
根据适用的合规义务和调查需求，按事件类型划分设定留存期限。无限期留存可能会增加隐私泄露风险、存储成本和搜索时间。记录每个留存期的设定理由，然后按计划删除记录。对于正在制定实用政策的小型组织，来自 Networking2000 的小型企业数据留存建议 提供了一个很好的切入点。
留存规则：保存条目的时间应足够长，以确保能调查很晚才发现的事件；且保存期限不得超过您能书面证明合理性的时间。
防御性实施所需的文档
请记录您所记载的事件类型及其原因、您的保留和法律保留策略、谁拥有哪些访问角色、导出是如何生成和验证的、时钟如何同步、您使用哪些告警阈值，以及哪些备份控制措施在保护数据存储。然后定期检查日志记录功能是否正常运行。静默的日志记录故障可能会让系统表面看起来一切正常。
时钟同步至关重要，因为来自时钟存在偏差的系统的条目可能会生成具有误导性的时间线。请将系统同步至 UTC，并验证同步是否持续正常。
在评估供应商时，请索取有关其安全性和治理实践的说明文档。Purple Engage 的 安全和治理信息 可以帮助 IT 和合规负责人评估该平台。
如何根据审计日志重现事件过程
重建过程需要历史数据，因为入侵往往不会被立即发现。PCI Security Standards Council 指导方针中的有效每日日志监控 要求受相关支付卡标准约束的组织保留审计跟踪历史记录至少 1 年，同时保持最少 3 个月的数据处于即时可调取的分析状态。
提出该要求是出于数字取证方面的考虑。调查人员需要足够的历史记录来确定未经授权的活动何时开始、持续了多久，以及哪些系统或记录受到了影响。如果您的日志仅覆盖过去几周，您就只能描述今天发现了什么，而对它是如何开始的一无所知。
下图展示了后续具体操作步骤之前的重构流程。
七步事件重现法
确定问题和时间窗口。 准确写下您想要确定的内容，例如过去 30 天内某一个场馆的同意状态变更。模糊的问题会导致搜索结果模糊。具体的问题能告诉您需要过滤哪些字段。
确认覆盖范围和时钟同步。 检查日志源是否覆盖该时间窗口，且其时钟已在 UTC 下同步。如果时间窗口有一部分位于冷存储中，请在得出结论前将其检索出来。
按操作类型和范围进行过滤。 拉取与该操作匹配的事件，例如 consent.status.change，范围限定为场馆 214。请优先限定范围，否则多场馆的活动会淹没您需要的条目。
提取操作者、身份验证上下文和来源。 对于每个匹配的事件，记录是谁执行了操作、他们是如何通过验证的，以及他们使用了哪个网络或设备。来自陌生来源的熟悉操作者是一个值得暂停关注的模式。
检查授权决策和相关性 ID。 确认每个操作都已获得许可，并将批量更新与其审批链接起来。共享同一个相关性 ID 的条目属于同一个决策，因此应将其放在一起评估，而不是逐个评估。
构建时间线并对比数值。 按时间戳对事件进行排序，并对比每次变更的前后数值。这一步可以揭示记录是只变更了一次，还是经历了变更、还原、再次变更的过程。
区分授权活动与可疑活动，然后记录调查结果。 标记哪些活动符合审批、哪些不符合，并撰写调查结果，附上事件 ID 作为证据引用。您的结论应当指向具体的条目，而不是凭总体印象。
下面的简短演练展示了在实践中如何采用相同的逐字段方法来构建时间线。
事件重现容易中断的环节
有三个常见问题反复出现。缺失事件是最严重的情况，因为你无法区分是“什么都没发生”还是“什么都没记录”。时区不匹配会扰乱事件顺序，导致审批看起来发生在被批准的操作之后。过早掩码的记录则抹去了将条目与访客或营销活动关联所需的参考信息。
对于多场所运营，覆盖同意、受众、优惠、审批、集成和消息发送操作的仅追加记录可使此工作跨不同位置有效开展。如果缺乏统一的范围字段，你就无法判断某种模式是单一场所的问题还是整个集团的问题。这是你在任何事故发生前很久就必须做出的设计决策。
在不破坏证据的情况下处理隐私请求
访客要求你删除其数据。你的审计日志包含有关该访客的条目，包括你负责的同意变更。删除所有内容会毁掉你的凭证。彻底拒绝则忽视了请求。你需要一种能够兼顾两者的模式。
冲突确实存在，但范围比表面看起来要窄。审计条目不需要包含访客的个人数据就能发挥作用。它只需要证明某个操作已发生、由谁执行以及结果如何。将这两者区分开来，大部分矛盾就会迎刃而解。
五步工作法模式
首先记录请求本身。在对请求采取行动之前，先将其记录为一个事件，包括其类型、接收时间、处理者以及最终结果。如果日后有人询问您是如何处理该请求的，处理过程本身即可作为证据。
将个人数据与事件记录分开。在审计条目中保留稳定的访客引用标识，而不是姓名、联系方式或原始同意文本。该引用标识允许您关联各个条目，同时个人数据保存在运营记录中，以便执行删除操作。
对运营记录执行删除操作。按要求删除或限制访客记录，并在保留期内保留审计条目，除非有书面规则允许提前删除。此时，该条目指向的引用标识不再能解析出个人数据，这通常就是您希望达到的结果。
在需要时设置法律冻结。如果某项未结案的调查或争议仍需要特定的条目，请对其进行明确冻结，而不是非正式地暂停删除。包含原因和责任人的命名冻结可以在人员变动后继续有效，而口头约定则不行。
记录决策及其依据。注明掩码或删除某个字段的原因、您适用的规则以及批准人。审计员如果发现掩蔽字段而没有任何解释，会将其视为缺陷。但如果审计员发现的是经过书面记录的决策，通常就会继续审核下一项。
需要与法律顾问确认的问题
有两个问题需要法律层面的专业建议，而非工程上的主观判断：考虑到您的行业特征和合同条款，各个事件类别分别适用哪个保存期限？出于您保存记录的目的，掩码后的条目是否仍算作完整记录？
按事件类型逐一获取这些问题的答案，而不是给出一个一概而论的声明。同意变更与登录失败不具有相同的证据分量，其保存职责也可能不同。记录这种差异才是使您的立场具备可抗辩性的关键。
透明度在访客端同样有积极作用。提出请求的人希望了解你持有什么数据以及这些数据会如何处理。我们的 隐私声明 阐述了我们对此类处理方式的说明，而你自己的声明也应该能够用通俗的语言解释，在数据删除后，请求本身的最小化记录仍可能被保留。
删除访客记录与保留一条仅供参考的证明已删除的条目并不矛盾。做到后者正是你证明前者的方式。
信任日志前需了解的误区与治理检查
审计日志是否值得信赖？当调查人员索要日志时会发生什么改变？这是大多数入门级解释所忽略的问题。NIST SP 800-171 审计记录生成控制标准 体现了这样一种预期：企业应确定并记录哪些事件对于持续审计需求具有重大意义和相关性，而不是盲目地记录所有数据。
这一预期纠正了四个常见误区。
值得摒弃的四个误区
日志越多，证据越充分。 事实并非如此。对重大事件进行具备可抗辩性的全面记录才是关键，过大的数据量不仅会掩埋您真正需要的条目，还会增加隐私泄露风险。
仅仅保存日志就够了。 可审计性取决于完整性、全面性、访问控制和检索能力，而非仅仅是存储。一条您无法搜索或无法证明未经篡改的日志，在调查中是无法发挥作用的。
审计日志是备份。它只记录活动。它无法恢复已删除的数据，也无法重建已丢失的访客记录。
审计日志可以阻止攻击。 它支持事后调查并可为威胁检测提供数据支持，但其本身无法阻止任何攻击。
DORA 体现了监管的发展趋势。该法案于 2025 年 1 月生效，要求受监管的金融实体和相关 ICT 提供商将 ICT 活动（包括数据访问、系统更改和管理操作）记录在支持调查和审计的表格中。这种转变是从“拥有日志”走向“能够开展调查”。
本周即可执行的治理检查
用证据回答每个问题，而不是凭口头保证。
- 事件范围： 我们记录的事件是否符合我们的风险与法规要求，且是否有文档记录？
- 条目完整性： 每个条目是否都包含 UTC 时间、操作者、范围、结果和相关性 ID？
- 完整性： 存储库是否为仅限追加或具备防篡改功能，且限制删除并对管理员访问权限进行独立监控？管理员能否修改或删除条目？
- 保留期限： 是否按事件类别记录了保留期限，包括冷热分级存储和诉讼冻结？
- 检索能力： 我们能否为审计员导出记录并对该导出进行身份验证？
- 时钟同步： 时钟同步是经过验证的，还是仅仅出于假设？
- 隐私处理： 我们能否在不破坏证据历史记录的情况下，响应同意或删除请求？
不要试图一次性解决所有问题。选择一个高风险工作流程，例如同意变更或批量导出，根据检查清单进行追踪，并修复发现的第一个缺陷。与产生冗长列表却没有任何改变的集团范围审查相比，一个具备完整凭证的工作流程能带来更多实际启发。
这也是评估您所采购平台的合理视角。Purple Engage 为负责审批营销平台的人员提供包括审计记录、API 和 webhook 在内的企业级功能，并在每个渠道上提供统一的访客记录、统一的同意账本和统一的测量系统，整合来自 WiFi、收银机、预订和酒店住宿来源的数据。Engage 为每位访客记录超过 60 种事件类型，包括 WiFi 登录、购买、预订、退房、表单提交、活动参与和问卷回复。只有在背后的记录得到妥善管理的前提下，这些细节才会有所帮助，这就是为什么核查清单比功能列表更为重要。
防篡改和可解释性比单纯的日志数量更重要。当有人询问你自身架构中的审计日志是什么时，如果你能记住一个测试，就用这个：你能把这份记录交给持怀疑态度的外部人员并让他们相信吗？
如果您正在评估如何在各个场所证明同意变更、审批、导出和消息发送，Purple Engage 可以在统一的访客记录和同意账本旁提供完整的审计记录，并在获得批准时以及每条消息发送前再次进行核验。欢迎访问我们的网站，了解该记录的结构形式、涵盖的事件类型，以及您的 IT 和合规负责人如何在您做出决策前对其进行审查。