审计追踪的设计

什么是审计追踪（Audit Trail）服务？

审计轨迹（Audit trail、Audit log），也译作审计追踪、审计跟踪、审计日志、文件日志或轨迹纪录等名称，是一种作为信息系统审计手段的与安全相关的时间顺序记录、记录集和/或目的地和记录来源，它们提供了在任何时候影响特定操作，程序的活动顺序的文件证据或事件。 审计记录通常来自一些活动，例如：金融交易、科学研究和医疗保健数据交易，或个人、系统、账号以及其他实体的通信等活动。 透过对系统上的活动作时间顺序的纪录，从而监察系统是否存在违规的活动，协助审核人员快速的找出相关的交易资料。 ——维基百科

审计追踪服务应该具备哪些能力？

1. 日志内容不可篡改。
2. 日志链结构完整：不可任意添加或删除单独的日志条目。
3. 兼容性：发送日志的客户端应该避免侵入式设计。
4. 系统的加密服务应该尽早初始化，以减少未受保护的日志。
5. 服务重启/关闭不应导致审核日志不一致。如果服务因紧急情况而关闭，审计日志应该是可验证的。
6. 密钥安全性：加密密钥（用于计算完整性检查）应存储在专用密钥存储中，并在内存中驻留最短的时间。
7. 性能：能够在几秒钟内验证受保护日志。
8. 日志轮换友好性：审核日志应与分布式系统典型的日志轮换策略兼容。
9. 可观测性：日志易于被解析（machine-readable）、人类可读（human-readable）。兼容主流日志处理程序的格式，维度设计便于日后做过滤筛选。

审计追踪涉及的行业标准

常见的工业标准有 IEC62443、NIST SP 800-92。

常见问题及应对措施

日志格式（协议）

对于本地运行的软件，通常 Syslog 具有更好的系统兼容性。对于使用 ELK 采集日志的项目更适合用 CEF，其他情况建议使用 自定义的 JSON。

下面是三种格式（协议）的对比。

Common Event Format (CEF)

Elastic-Search 使用的、一种基于 Event-souring 思想设计的日志格式。优点是冗余信息少，适合配合 ELK 体系构建监控系统。

Syslog

Syslog 是 Linux 操作系统默认的审计日志格式，通常采用其 RFC5424 版本。大部分 SIEM¹ 系统都支持这种格式的导入。 Syslog 协议适配性很好，基于 mTLS 的 Syslog 传输可以在兼容传统软件的同时，最大程度保证系统的安全性。但是对于微服务来说，实现和维护标准协议成本较高。所以如 AWS CloudTrail, OpenTelemetry 等都选择更简单的 HTTPS + JSON 格式。

JSON

大部分 SaaS 产品都是用 JSON，简单高效。例如，下面是OpenTelemetry 官方文档提到的日志模型中的字段：

审计追踪的安全性要求

对于审计日志来说，安全性要求会被一般日志系统更高。

安全性，通常可以从机密性（Confidentiality），完整性（Integrity），可用性（Availability）三个维度来考量。

机密性

攻击者可以通过系统的安全漏洞，获取特殊权限，进而查看某些审计日志。

可以采取以下措施：

• 加密日志：使用加密技术对日志进行保护，确保只有授权用户能够访问和修改日志。
• 访问控制：限制对发送、接收日志接口的访问权限。
• 敏感信息过滤：不应该在日志中记录用户敏感信息，如密码、证书等。

完整性

攻击者可以通过系统的安全漏洞，修改、删除某些审计日志。

除了上面提到的加密和权限控制，还可以采取以下措施：

• 完整性检查²：在日志条目中添加哈希值，以便在验证日志时能够快速检测到任何篡改或截断。
• 定期备份：定期备份日志，以防止攻击者删除或修改所有的日志条目。

可用性

攻击者可以攻击审计追踪服务，导致审计追踪服务内存、磁盘空间不足等。

• 设置最大用量限制：对内存、磁盘等服务器资源做出限制。
• 监测和响应：及时监测系统资源指标和日志的变化，并对异常活动进行响应。

开源项目的架构设计

根据自身项目需求，可以参考一些开源的架构设计。由于每个框架（方案）的设计侧重点不同，需要认真评估它们的优势和不足。

Auditd

大部分 Linux 系统默认的审计服务，配合 rsyslog 等工具，可以解决本地设备的日志采集、查看、过滤。

• 优点：基于进程通信，标准日志格式，易于导出。性能优异。
• 不足：标准繁琐，进程模型不适用于网络服务。

AWS Cloud Trail

AWS 的 Cloud Trail 采用应用服务主动推送审计事件的模式，用户可以为设计追踪服务设置策略，收集到的日志会分别按需流入后续的批处理和流处理工具链中。

• 优点：微服务设计，JSON 格式日志更灵活，中心化的日志收集服务易于集成更多应用服务和导出到开源数据处理工具。
• 不足：分布式架构对存储、服务端加密、通信安全性和完整性要求更难实现。

Kubenetes

K8s 的日志收集与 AWS 实现类似，也是基于中心化的服务，但是这套架构设计并非只为审计日志一种情况设计。

• 优缺点同上

OpenTelemetry

OpenTelemetry 是现在云原生最主流的日志框架。可以支持侵入式（SDK）、非侵入式（Agent）两种日志采集模式。Collector 的设计可以让一部分日志处理的工作放在日志发送端完成。

• 优点：微服务设计，支持 K8s 等基础设施，多语言多平台提供了 SDK 和扩展能力。有完善的安全、完整性考虑。未来可期。
• 不足：大部分情况下日志采集依然需要侵入到 App 内部修改代码。日志收集工具对 Go 等语言支持不够好（截至本文写作时还是测试版）。

小结（由 Claude AI 提供）

审计追踪（Audit Trail）是指系统记录下所有影响操作或事件的时间顺序记录,用于追踪系统活动，核查是否存在违规行为。

审计日志应具备以下特性:

• 不可篡改(加密存储、完整性校验)
• 高性能(快速验证)
• 可观测性(机器/人类可读)
• 安全性(保密性、可用性、完整性)

常见的审计日志格式有 Syslog、CEF、JSON 等,主要区别在于冗余信息、可读性和与日志收集系统的兼容性。

审计日志具有较高的安全性要求：

• 机密性：只有授权用户可访问,通过访问控制实现
• 可用性：防止被攻击者删除或破坏,通过限制资源使用、多副本存储等实现
• 完整性：防止被篡改或截断,通过加密、完整性校验等实现

一些典型的审计日志系统架构：

• Auditd(Linux 默认) + rsyslog 等工具，基于进程通信
• AWS CloudTrail 等云产品方案
• Kubernetes 架构
• OpenTelemetry 开源框架