Share via

Устранение неполадок с соединителем 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 должен содержать эту политику на вкладке Политика доступа .

Причина 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 на расшифровку файлов. Проверьте необходимые разрешения 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. Если она отключена, включите ее.

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

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

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