Устранение неполадок с соединителем AWS S3

Соединитель Amazon Web Services (AWS) S3 позволяет принимать журналы служб AWS, собранные в контейнерах AWS S3, для 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. Данные не подается в контейнер S3 в AWS.
  3. Amazon Simple Queue Service (SQS) в облаке AWS не получает уведомления от контейнера S3.
  4. Данные не могут быть считаны из SQS/S3 в облаке AWS. При использовании журналов 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 откройте вкладку Свойства и найдите раздел Уведомления о событиях .
    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. Если функция работоспособности не включена, включите ее.

Данные из соединителя AWS S3 (или одного из его типов данных) видны в Microsoft Sentinel с задержкой более 30 минут.

Эта проблема обычно возникает, когда корпорация Майкрософт не может прочитать файлы в папке S3. Корпорация Майкрософт не может прочитать файлы, так как они зашифрованы или в неправильном формате. В этих случаях многие повторные попытки в конечном итоге вызывают задержку приема.

Определение причины проблемы

В этом разделе рассматриваются следующие причины:

  • Шифрование журналов настроено неправильно
  • Уведомления о событиях определены неправильно
  • Ошибки работоспособности или работоспособности отключены

Причина 1. Шифрование журналов настроено неправильно

Если журналы полностью или частично зашифрованы службой управления ключами (KMS), у Microsoft Sentinel может не быть разрешения на расшифровку файлов.

Решение: проверка шифрования журналов

Убедитесь, что Microsoft Sentinel имеет разрешение на расшифровку файлов. Просмотрите необходимые разрешения KMS для журналов GuardDuty и CloudTrail.

Причина 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. Если функция работоспособности не включена, включите ее.

    Дополнительные сведения о следующих элементах, используемых в предыдущем примере, см. в документации по Kusto:

    Дополнительные сведения о KQL см. в статье Общие сведения о язык запросов Kusto (KQL).

    Другие ресурсы

Дальнейшие действия

В этой статье вы узнали, как быстро определить причины и устранить распространенные проблемы с соединителем AWS S3.

Мы приветствуем отзывы, предложения, запросы на функции, отчеты об ошибках или улучшения и дополнения. Перейдите в репозиторий Microsoft Sentinel GitHub, чтобы создать проблему или вилку и отправить вклад.

  • Last updated on