它是2023年，审核日志是任何企业产品产品的核心组成部分。尽管看起来很简单，但审核日志可能很难实现。

作为我在Infisical工作的一部分，我将此功能完成了两次，我讨论了有关本文审核记录的所有内容，特别是如何正确运送它们。

什么是审核日志？

开始，审核日志是安全和合规团队在企业中使用的用户活动的集中式流，以监视任何可疑活动或事件审查时信息访问。乍一看，它们是包括事件，时间戳记和有效载荷的条目。但是，从更深层次的角度来看，它们可以被视为摘要，当串联列出时，逐个框架的叙述详细介绍了任何给定时间时期发生的事情）。

制作出色的审核日志

在本节中，我们概述了我们从审核日志和希望维护的原则中期望的数据结构。

一般数据结构

提醒您，审核日志是针对安全和合规团队的专门构建的，可以在给定时间点监视和检查事件的上下文。鉴于此，一组良好的审核日志应该包含回答您基本疑问代词的字段：

• 事件：发生了什么？对于Infisical，例如，这是与秘密相关的动作，例如被获取或创建。

• 演员：谁触发了事件？这可能是负责执行或导致基础事件的实体的名称，电子邮件或标识符。

• 时间戳：事件何时发生？来源（用户代理 + IP）：事件发生在哪里？如果您构建API，则通常可以从请求本身获得用户信息和IP地址。例如，诸如Express之类的框架在Req.headers [–用户代理]和req.ip中公开请求的用户代理。

• 元数据：为每个事件提供上下文的其他数据。在我们的情况下，这可能是从等等中获取秘密的道路。

除了这些字段之外，存储以下数据可能很有用（这些数据可能适用也可能不适用）：

• 源类型：事件的源类别。在我们的情况下，可以通过Web UI，CLI，Kubernetes运营商或其他（即其他任何地方）提出请求。我们将在稍后再讨论，但包括这样的字段从查询的角度帮助。

• 描述：对所采取的动作的人类可读描述。定义特征。

• 状态：就像HTTP请求一样，事件有可能成功或失败。如果适用，并且您有一种检测此状态信息的方法，则应将其包括在条目中。例如，如果有人试图访问禁止资源，这将很有帮助。

良好的审核记录系统不仅应记录事件数据，而且还应考虑检查日志（即最终用户）和系统本身工程师的各种可用性标准：

• 不变的：系统的用户应只能从中读取数据而不写入数据。具有写入能力会损害审计记录系统的完整性，因为它必须反映过去的确切事件状态。

• 可查询：系统的用户必须能够通过应用任何一个或多个过滤器来有效地搜索审核日志；过滤应该很快。如果发生安全事件，管理员应能够滤除所有事件，其中Actor A从日期D和E.

之间的源c执行的动作B

• 可导出的：数据必须是可导出的和/或可以流到专用的记录解决方案（如Splunk，AWS等）的。这对于安全团队以集中其安全日志的安全为有用，以进行外部分析。 。

最后，您可能会考虑一些其他不错的品质：

• 轻量级：审核日志应捕获简短的摘要，摘要和/或参考数据，而不是包括所有数据。因此，如果您发现自己像捕获数据库备份/快照一样复制整个数据结构，那么您可能会做错了（例如，您不需要附上有关演员的所有细节事件；您可能只需要他们的标识符即可将其链接到活动）。

• 可简约：出色的审核日志数据结构也应该很容易解析，更一般而言。数据的形状和结构可能对在平台UI中渲染以及操纵一些未来的工程努力的容易。

我们如何在无限制

当我们第一次为Infisical构建审核记录功能时，我们没有完全考虑目前的目标用户。

取而代之的是，我们以一种过于简化的方式查看了目标：创建一个按时间顺序排序的事件分类账，以供团队检查过去。我们还误以为审核日志，以获取数据的完整快照，并指出，回想起来，应该是数据库备份/快照的责任。

结果，我们最终获得了一个不切实际的审核记录系统，该系统将我们带回了绘图板。

我们使用的数据结构

经过很多思考后，我们选择了以下审核日志架构：

export interface IAuditLog {
    actor: Actor;
    organization: Types.ObjectId;
    workspace: Types.ObjectId;
    ipAddress: string;
    event: Event;
    userAgent: string;
    userAgentType: UserAgentType;
    expiresAt: Date;
}

const auditLogSchema = new Schema<IAuditLog>(
    {
        actor: {
            type: {
                type: String,
                enum: ActorType,
                required: true
            },
            metadata: {
                type: Schema.Types.Mixed
            }
        },
        organization: {
            type: Schema.Types.ObjectId,
            required: false
        },
        workspace: {
            type: Schema.Types.ObjectId,
            required: false
        },
        ipAddress: {
            type: String,
            required: true
        },
        event: {
            type: {
                type: String,
                enum: EventType,
                required: true
            },
            metadata: {
                type: Schema.Types.Mixed
            }
        },
        userAgent: {
            type: String,
            required: true
        },
        userAgentType: {
            type: String,
            enum: UserAgentType,
            required: true
        },
        expiresAt: {
            type: Date,
            expires: 0
        }
    },
    {
        timestamps: true
    }
);

从根本上讲，我们将必要的组件分成3个根据我们的需求调整的部分：

演员：由于人类和非人类和非人类（即服务）参与者可以触发Infisical中的事件，因此我们将Actor类型添加到模式中。此外，由于人类和非人类演员具有不同的标识符元数据，例如电子邮件，用户ID，服务ID等，因此我们还创建了一个良好的混合类型元数据字段，为每个参与者存储此信息。这里定义的思考过程是查询性能。
event ：事件的名称和每个事件独有的相关元数据。
其他：请求信息，例如IP地址和入站请求的用户代理，以及该信息的时间戳。
配备了这种数据结构，作为蛋糕的审核日志的创建和查询变得很容易。

UI和UX

正如您所期望的那样，我们将审核日志组织到了分页的表观视图中，配备了过滤器，用户可以一起申请范围缩小搜索。

以来，我们的第一次审核日志不限于：

• 过滤选项：您可以按事件，用户，源，日期或这些过滤器的任何组合过滤审核日志。

• 元数据：我们仅显示相关的元数据，没有任何过多。例如，我们在秘密方面没有商店并在审核日志上执行任何加密操作；我们只是将其卸载到责任的另一部分。

• timestamps ：我们在yyyy-mm-dd hh中格式化时间戳记：mm am/pm的格式。

结束思想

审核日志是销售企业软件时的高需求功能，使其正确。通过选择一种多功能数据结构并考虑它们在实践中的使用方式，您可以为软件设计出色的审核日志，以帮助用户获得安全审查和事件的见解。

-

Infisical开源秘密管理平台

Infisical（8.4k+â！）帮助成千上万的团队和组织在其团队和基础架构中存储和同步秘密。

github repo：https://github.com/Infisical/infisical