用户字段使用和示例

以下是本页涵盖的主题。

分类编辑

用户字段可以出现在任何类型的事件中，而不会影响事件的分类。

但是，当事件与 IAM（身份和账户管理）相关时，应将其分类如下。在本节中，我们将专门介绍与 IAM 活动相关的 event.category 和 event.type。请务必阅读分类部分以查看所有允许的值，并详细了解 event.kind 和 event.outcome。

以下示例中的许多部分都被省略，以便专注于事件的分类。

创建组“test-group”

{
  "event": {
    "kind": "event",
    "category": ["iam"], 
    "type": ["group", "creation"], 
    "outcome": "success"
  },
  "group": { "name": "test-group", ... },
  "user": { ... },
  "related": { "user": [ ... ] }
}

将“test-user”添加到“test-group”

{
  "event": {
    "kind": "event",
    "category": ["iam"], 
    "type": ["user", "change"], 
    "action": "user added to group", 
    "outcome": "success"
  },
  "user": {
    ...
    "target": { 
      "name": "test-user",
      "group": { "name": "test-group" }
    }
  },
  "related": { "user": [ ... ] }
}

用户标识符编辑

不同的系统对用户标识符使用不同的值。以下是一些有助于规范化一些简单情况的指针。

字段复用编辑

用户字段可以在 ECS 中的许多地方重复使用（或出现）。这使得捕获与单个事件相关的多个用户成为可能。

以下是用户字段可以出现的所有位置的完整列表

让我们来看看每个字段的含义。

为了便于阅读，以下示例将仅在各个 user 嵌套中填充 user.name，有时还会填充 user.id。但是，在实现中，除非另有说明，否则应填充所有可以合理填充在每个位置的 user 字段。

事件根目录下的用户字段编辑

事件根目录下的用户字段用于捕获执行事件所描述的主要操作的用户。当事件中存在多个用户时，这一点尤其重要。事件根目录下的 user.* 字段表示执行操作的用户。

在许多情况下，仅提及一个用户的事件应填充事件根目录下的用户字段，即使该用户不是执行操作的用户。

如果填充了特定用途的用户字段（例如 url.username），则还应使用相同的用户名填充 user.name。

{
  "url": { "username": "alice" }, 
  "user": { "name": "alice" }, 
  "related": { "user": ["alice"] }
}

远程登录编辑

当用户跨越主机边界时，用户将在 source.user 和 destination.user 处被捕获。

适用此情况的数据源示例

为了与 ECS 的设计保持一致，即将事件根目录下的 user 作为执行操作的用户，应将所有 source.user 字段复制到事件根目录下的 user。

以下是一个示例，其中用户“alice”以用户“deus”的身份登录到另一台主机

{
  "user": {
    "name": "alice"
  },
  "source": {
    "user": {
      "name": "alice"
    },
    "ip": "10.42.42.42"
  },
  "destination": {
    "user": {
      "name": "deus"
    },
    "ip": "10.42.42.43"
  },
  "related": { "user": ["alice", "deus"] }
}

每当事件源除了填充 source 和 destination 字段外还填充 client 和 server 字段时，也应相应地复制用户字段。您可以查看映射网络事件以详细了解如何映射网络事件。

权限更改编辑

当存在权限升级或降级并且可以确定请求/执行升级的用户时，user.effective 字段是相关的。

使用事件根目录下的 user 字段捕获请求权限更改的用户，并使用 user.effective 捕获请求的权限级别，无论权限更改是否成功。

以下是适用此情况的示例

如果事件源仅提供有关有效用户的信息，而没有提供请求不同权限的用户的信息，则应使用事件根目录下的 user 字段，而不是 user.effective。

以下是一个用户“alice”通过 sudo 以 root 身份运行命令的示例

{
  "user": {
    "name": "alice",
    "id": "1001",
    "effective": {
      "name": "root",
      "id": "1"
    }
  },
  "related": { "user": ["alice", "root"] }
}

如果无法（或禁止）确定哪个用户请求不同的权限级别，则可以捕获事件根目录下的有效用户。通常，权限更改事件已经发生，例如：bob 以 root 身份“su”；后续事件将显示 root 用户执行的操作。

身份和访问管理编辑

每当用户执行的操作影响到另一个用户（通常在 IAM 场景中）时，受操作影响的用户将在 user.target 处被捕获。执行 IAM 活动的用户在事件的根目录处被捕获。

IAM 活动的示例包括

在创建/删除场景中，没有先前状态（用户创建）或没有后续状态（用户删除）。在这些情况下，必须仅填充事件根目录下的 user 和 user.target。

“root”创建用户“bob”的示例

{
  "user": {
    "name": "root",
    "id": "1",
    "target": {
      "name": "bob",
      "id": "1002",
      ...
    }
  }
  "related": { "user": ["bob", "root"] }
}

当现有用户的状態发生变化时，必须使用 user.target 捕获用户的先前状态，并且 user.changes 应仅列出已执行的更改。

“root”将用户“bob”重命名为“bob.barker”的示例

{
  "user": {
    "name": "root",
    "id": "1",
    "target": {
      "name": "bob",
      "id": "1002"
    },
    "changes": {
      "name": "bob.barker"
    }
  },
  "related": { "user": ["bob", "bob.barker", "root"] }
}

您会在上面的示例中注意到，未修改的属性（如用户 ID）不会在 user.changes.* 下重复，因为它们没有更改。

结合 IAM 和权限更改编辑

我们在上面介绍了如何同时使用 user.target 和 user.changes。如果在同一个 IAM 事件中也存在权限升级，则当然也应使用 user.effective。

以下是上面 IAM 部分中的“重命名”示例。在以下示例中，我们知道“alice”正在将权限升级为“root”，以便修改用户“bob”

{
  "user": {
    "name": "alice",
    "id": "1001",
    "effective": {
      "name": "root",
      "id": "1"
    },
    "target": {
      "name": "bob",
      "id": "1002"
    },
    "changes": {
      "name": "bob.barker"
    }
  },
  "related": { "user": ["alice", "bob", "bob.barker", "root"] }
}

字段复用的微妙之处编辑

ECS 中的大多数字段复用情况是在不同的字段集中重复使用一个字段集。以下是两个示例

user 字段也可以在 user 中以不同的名称重复使用，表示每个相关用户的角色。例如 user.target.* 或 user.effective.* 字段。

但是，请务必注意，在 user 中重复使用的 user 字段_不会被带到其他任何地方_。让我们用不同的排列来 illustrare 什么是有效的，什么不是有效的。

无效

在 user 中重复使用的 user 字段不会被带到其他任何地方。当 user 在 source、client 和 server 下重复使用时，也适用相同的规则。

任何包含用户的事件都应始终使用事件中看到的所有用户名填充数组字段 related.user，包括出现在自定义字段中的事件名称。请注意，此字段不是所有用户字段的嵌套，而是一个包含用户标识符的平面数组。

以 user.changes 为例，我们可以看到，无论每个用户的角色是什么（权限提升之前/之后、受影响的用户、重命名后的用户名），它们都存在于 related.user 中。

{
  "user": {
    "name": "alice",
    "id": "1001",
    "effective": {
      "name": "root",
      "id": "1"
    },
    "target": {
      "name": "bob",
      "id": "1002"
    },
    "changes": {
      "name": "bob.barker"
    }
  },
  "related": { "user": ["alice", "root", "bob", "bob.barker"] }
}

与 related 字段集中的其他字段一样，related.user 旨在促进透视。例如，如果您怀疑用户 "bob.barker"，则在 related.user 中搜索此名称将为您提供与此用户相关的所有事件，无论是用户的创建/重命名，还是该用户在系统中处于活动状态的事件。

映射示例编辑

有关映射来自各种来源的事件的示例，您可以查看RFC 0007 中的“源数据”部分。