Поделиться через

Устранение неполадок соединителя 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. На вкладке Monitoring (Мониторинг) вы должны увидеть трафик в мини-приложении Number Of Messages Sent (Количество отправленных сообщений). Если в SQS трафик отсутствует, проблема заключается в конфигурации AWS.
  3. Убедитесь, что в определении уведомлений о событиях для SQS содержаться правильные фильтры данных (префикс и суффикс).
    1. Чтобы просмотреть уведомления о событиях, откройте вкладку Properties (Свойства) в контейнере S3 и перейдите в раздел Event notifications (Уведомления о событиях).
    2. Если этот раздел не отображается, создайте его.
    3. Убедитесь, что для SQS настроены соответствующие политики для получения данных из контейнера S3. Эта политика SQS должна отображаться на вкладке Access policy (Политика доступа).

Причина 4. SQS не считывал данные

SQS не успешно считывал данные S3.

Решение. Убедитесь, что SQS считывает данные

  1. В AWS откройте соответствующую службу SQS.

  2. На вкладке Monitoring (Мониторинг) вы должны увидеть трафик в мини-приложениях Number Of Messages Deleted (Количество удаленных сообщений) и Number Of Messages Received (Количество полученных сообщений).

  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, чтобы создать проблему или вилку и отправить предложения.