通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

排查 AWS S3 连接器问题

  • 项目

通过 Amazon Web Services (AWS) S3 连接器，可将收集在 AWS S3 Bucket 中的 AWS 服务日志引入到 Microsoft Sentinel。 我们目前支持的日志类型包括 AWS CloudTrail、VPC 流日志和 AWS GuardDuty。

本文介绍如何快速确定 AWS S3 连接器出现问题的原因，以便找到解决问题所需的步骤。

了解如何将 Microsoft Sentinel 连接到 Amazon Web Services 以引入 AWS 服务日志数据。

Microsoft Sentinel 未从 Amazon Web Services S3 连接器或其数据类型之一接收数据

连接连接器后，AWS S3 连接器（或其数据类型之一）的日志在 Microsoft Sentinel 工作区中不可见超过 30 分钟。

在搜索原因和解决方案之前，请查看以下注意事项：

  • 从连接器连接到数据被引入到工作区可能需要大约 20-30 分钟。
  • 连接器的连接状态表明存在收集规则；这不表明数据已被引入。 如果 Amazon Web Services S3 连接器的状态为绿色，则表示其中一个数据类型有集合规则，但仍没有数据。

确定问题的原因

在本部分中，我们将讨论以下原因：

  1. AWS S3 连接器权限策略未正确设置。
  2. 数据未引入 AWS 中的 S3 桶。
  3. AWS 云中的 Amazon 简单队列服务 (SQS) 不接收来自 S3 桶的通知。
  4. 无法从 AWS 云中的 SQS/S3 读取数据。 对于 GuardDuty 日志，该问题是由错误的 KMS 权限引起的。

原因 1：AWS S3 连接器权限策略未正确设置

此问题由 AWS 环境中的权限不正确所引起。

创建权限策略

你需要权限策略来部署 AWS S3 数据连接器。 查看所需的权限并设置相关权限。

原因 2：S3 桶中不存在相关数据

S3 桶中不存在相关日志。

解决方案：搜索日志，如果需要则将其导出

  1. 在 AWS 中打开 S3 存储桶，根据所需的日志搜索相关文件夹，并检查该文件夹中是否有任何日志文件。
  2. 如果数据不存在，则表示 AWS 配置存在问题。 在这种情况下，需要配置 AWS 服务以将日志导出到 S3 桶。

原因 3：S3 数据未到达 SQS

数据未成功从 S3 传输到 SQS。

解决方案：验证数据是否已到达并配置事件通知

  1. 在 AWS 中打开相关 SQS。
  2. 在“监视”选项卡中，应该会在“发送的消息数”小组件中看到流量。 如果 SQS 中没有流量，则存在 AWS 配置问题。
  3. 确保 SQS 的事件通知定义包含正确的数据筛选器（前缀和后缀）。
    1. 若要查看事件通知，请在 S3 Bucket 中选择“属性”选项卡，找到“事件通知”部分 。
    2. 如果未看到此部分，请创建它。
    3. 确保 SQS 具有从 S3 存储桶获取数据的相关策略。 SQS 必须将此策略包含在“访问策略”选项卡中。

原因 4：SQS 未读取数据

SQS 未成功读取 S3 数据。

解决方案：验证 SQS 是否读取数据

  1. 在 AWS 中打开相关 SQS。

  2. 在“监视”选项卡中，应该会在“已删除的消息数”和“收到的消息数”小组件中看到流量。

  3. 一个峰值的数据是不够的。 等待有足够的数据（几个峰值）后，再检查问题。

  4. 如果至少有一个小组件为空，请通过运行以下查询检查运行状况日志：

    SentinelHealth 
| where TimeGenerated > ago(1d)
| where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
| where OperationName == 'Data fetch failure summary'
| mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
| extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
| extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
| project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedProperties

  5. 请确保已启用运行状况功能:

    SentinelHealth 
| take 20

  6. 如果未启用运行状况功能，请启用它。

可在 Microsoft Sentinel 中看到来自 AWS S3 连接器（或其数据类型之一）的数据，延迟超过 30 分钟

当 Microsoft 无法读取 S3 文件夹中的文件时，通常会发生此问题。 Microsoft 无法读取文件是因为文件已加密或格式不正确。 在这些情况下，重试多次最终会导致引入延迟。

确定问题的原因

在本部分中，我们将讨论以下原因：

  • 日志加密设置不正确
  • 事件通知未正确定义
  • 运行状况错误或已禁用运行状况

原因 1：日志加密未正确设置

如果密钥管理服务 (KMS) 完全或部分加密日志，Microsoft Sentinel 可能没有此 KMS 的文件解密权限。

解决方案：检查日志加密

请确保 Microsoft Sentinel 对此 KMS 具有文件解密权限。 查看 GuardDuty 和 CloudTrail 日志的所需 KMS 权限。

原因 2：事件通知未正确配置

配置 Amazon S3 事件通知时，必须指定 Amazon S3 应将通知发送到哪些受支持的事件类型。 如果 Amazon S3 桶中存在未指定的事件类型，Amazon S3 不会发送通知。

解决方案：验证是否已正确定义事件通知

若要验证是否正确定义了从 S3 到 SQS 的事件通知，请检查：

  • 通知是从包含日志的特定文件夹定义的，而不是从包含桶的主文件夹定义的。
  • 通知使用“.gz”后缀进行定义。 例如：

原因 3：运行状况错误或已禁用运行状况

运行状况日志中可能存在错误，或者可能未启用运行状况功能。

解决方案：验证运行状况日志中是否存在错误并启用运行状况

  1. 通过运行以下查询，验证运行状况日志中是否存在错误：

    SentinelHealth
| where TimeGenerated between (ago(startTime)..ago(endTime))
| where SentinelResourceKind  == "AmazonWebServicesS3"
| where Status != "Success"
| distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description

  2. 请确保已启用运行状况功能:

    SentinelHealth 
| take 20

  3. 如果未启用运行状况功能，请启用它。

后续步骤

本文介绍了如何快速确定原因并解决 AWS S3 连接器的常见问题。

我们欢迎反馈、建议、功能请求、Bug 报告或改进和添加。 请前往 Microsoft Sentinel GitHub 存储库创建问题或分支并上传贡献。