Устранение неполадок с соединителем blob-объектов хранилища Azure

Соединитель больших двоичных объектов хранилища Azure упрощает процесс приема данных из больших двоичных объектов хранилища Azure в Microsoft Sentinel.

В этой статье описывается, как быстро определить причину проблем, возникающих с соединителем blob-объектов хранилища Azure, чтобы найти действия, необходимые для устранения проблем.

Узнайте, как подключить Microsoft Sentinel к хранилищу BLOB-объектов Azure для приема данных.

Microsoft Sentinel не получает данные от соединителя BLOB-объектов хранилища Azure

Журналы соединителя для BLOB-объектов хранилища Azure не отображаются в рабочей области Microsoft Sentinel спустя более 30 минут после подключения соединителя.

Прежде чем искать причину и решение, ознакомьтесь со следующими рекомендациями:

• С момента подключения соединителя до приема данных в рабочую область может потребоваться около 20–30 минут.
• Состояние подключения соединителя указывает на наличие правила сбора; оно не означает, что данные были получены. Если статус соединителя BLOB-объектов служба хранилища Azure отображается зеленым, для одного из типов данных настроено правило сбора, но данные по-прежнему отсутствуют.

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

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

1. Данные не загружаются в контейнер BLOB-объектов в службе хранилища Azure.
2. Очередь хранилища Azure не получает уведомления о событиях создания BLOB-объектов.
3. Разрешения для соединителя служба хранилища Azure Blob или сетевые политики настроены некорректно.
4. Недопустимо содержимое сообщения очереди или формат данных BLOB-объекта хранилища служба хранилища Azure.
5. Неправильная конфигурация DCR или DCE.

Причина 1. Данные не поставляются в контейнер BLOB-объектов хранилища Azure

Вышестоящей системе не удается успешно доставить данные в ожидаемый контейнер хранения.

Решение: Проверьте входящий поток данных в учетной записи хранения

1. Убедитесь, что в учетной записи хранения включено иерархическое пространство имен (Azure Data Lake Storage 2-го поколения). Соединителю требуются учетные записи хранения ADLS 2-го поколения.
2. В портал Azure перейдите к учетной записи хранения и просмотрите метрики, чтобы подтвердить активность входящего трафика.
3. Убедитесь, что ожидаемый контейнер хранилища получает BLOB-объекты.
4. Если контейнер пуст, проверьте вышестоящую систему-источник на наличие проблем с доставкой данных в учетную запись.

Причина 2: Очередь хранилища Azure не получает уведомления о событиях создания BLOB-объектов.

Системные разделы Event Grid обеспечивают передачу событий создания BLOB-объектов из исходной учетной записи хранения в целевую очередь хранения. Если системная тема или подписка настроены неправильно, события не будут поступать в очередь.

Решение: проверьте системную тему Event Grid и подписку

1. Проверьте развертывания группы ресурсов на наличие сбоев при создании ресурсов системного раздела. Если в учетной записи хранения уже существует системная тема, созданная другой конфигурацией, она может конфликтовать с подпиской соединителя.
2. Если системная тема и подписка Сетки событий были успешно созданы, просмотрите метрики подписки Сетки событий. Рассмотрите возможность включения журналов диагностики.
3. Убедитесь, что источник подписки соответствует нужной учетной записи хранения и целевой очереди.
4. Проверьте критерии фильтрации, указанные в разделе Дополнительные компоненты, чтобы убедиться, что они соответствуют ожидаемым шаблонам.
5. В метриках подписки сетки событий должны отображаться события, соответствующие условиям создания BLOB-объекта. Если метрики указывают на сбои доставки, просмотрите журналы диагностики Сетки событий и перейдите к следующему разделу на наличие проблем, связанных с политикой.
6. Проверьте метрики очереди хранилища, чтобы подтвердить поступление сообщений. В портал Azure перейдите к учетной записи хранения, выберите Очереди и просмотрите приблизительное число сообщений для очереди соединителя. Если очередь пуста, но Event Grid показывает успешную доставку, коннектор может получать сообщения, но не обрабатывать указанные BLOB-объекты.

Причина 3: Разрешения соединителя служба хранилища Azure Blob или сетевые политики настроены неправильно.

Эта проблема вызвана неправильными политиками доступа на основе ролей, применяемыми к учетным записям хранения, в котором размещен контейнер BLOB-объектов и (или) очередь сообщений, или параметрами безопасности сети, блокирующими трафик.

Решение: проверка разрешений и сети

Ознакомьтесь с документацией по настройке соединителя хранилища Azure и убедитесь в наличии следующих компонентов:

Проверки субъекта-службы и RBAC:

1. Убедитесь, что идентификатор приложения субъекта-службы соответствует идентификаторам приложений для Azure среды, указанной в справочнике по API соединителей BLOB-объектов хранилища Azure.
2. Убедитесь, что субъект-служба имеет роль читателя данных BLOB-объектов хранилища в учетных записях хранения, где размещен контейнер BLOB-объектов.
3. Убедитесь, что у субъекта-службы есть роль Участник данных очереди хранилища в учетных записях хранения, где размещены очереди сообщений.

Проверки безопасности сети:

Если при устранении неполадок с сервисным субъектом и RBAC не удается выявить проблему, ее причиной могут быть параметры сетевой безопасности в учетных записях хранения. Решение сетевой безопасности для этого соединителя зависит от защиты на основе периметра сетевой безопасности . Ознакомьтесь с документацией по включению сетевой безопасности, чтобы убедиться, что все шаги выполнены правильно, и проверьте следующее:

• Если вы не используете NSP для защиты ресурса, проверьте раздел учетной записи хранения Сеть, чтобы убедиться, что публичный сетевой доступ включен.

• Убедитесь, что учетная запись хранения не использует выбранные сетевые ограничения через IPv4-адреса CIDR. Этот подход не работает с IP-трафиком соединителя из-за задокументированных ограничений брандмауэра хранилища в отношении диапазонов IP-адресов и сопоставления регионов вызывающего объекта и учетной записи.

• Если NSP используется для защиты учетной записи, включите журналы диагностики периметра для устранения неполадок. Правила NSP применяются только к ресурсам в режиме принудительного доступа. Кроме того, режим перехода не применяет правила к ресурсу, продолжая собирать данные телеметрии о шаблонах трафика. Просмотрите профиль, связанный с учетными записями хранения:

  • Убедитесь, что правила для входящего трафика для производителя установлены. Проверьте наличие ошибок при записи BLOB-объектов на стороне производителя.
  • Проверьте, что правила для входящего трафика коннектора настроены в соответствии с документацией Включение сетевой безопасности. Убедитесь, что диапазоны IP-адресов тега службы Scuba включены во входящие правила NSP.
  • Убедитесь, что правила для входящих подключений включают правило для подписки учетной записи хранения и системный раздел Сетки событий.
  • Убедитесь, что в подписке системного раздела Сетки событий используется доставка на основе управляемого удостоверения, назначаемого системой .

  

Причина 4: Содержимое сообщения очереди или формат данных Azure Blob Storage недопустимы

Формат BLOB-данных или структура сообщения очереди не соответствуют ожидаемой конфигурации.

Решение. Проверка формата данных и сообщений очереди

1. Проверьте таблицу SentinelHealth на наличие подсказок о недопустимых сообщениях, выполнив следующий запрос:

   SentinelHealth
   | where TimeGenerated > ago(1d)
   | where SentinelResourceKind == "StorageAccountBlobContainer"
   | where Status != "Success"
   | distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description
   

2. Если данные о работоспособности ссылаются на недопустимые данные, убедитесь, что формат больших двоичных объектов, отправленных в хранилище, соответствует модели сериализации и сжатия, заданной в конфигурации ответа соединителя. Соединитель поддерживает следующие форматы: JSON, CSV, XML и Parquet. Дополнительные сведения см. в разделе Конфигурация ответа в справочнике по API.

3. Исключения, связанные с форматом сообщений в очереди, возникают из-за того, что сообщения в очереди не соответствуют EventGridSchema для событий BlobCreated. Проверьте раздел Фильтры подписки сетки событий, чтобы подтвердить следующее:

   • Для фильтра установлено значение Создание BLOB-объекта.
   • Схема события — EventGridSchema.

   

Причина 5. Неправильная конфигурация DCR или DCE

Правило сбора данных (DCR) или конечная точка сбора данных (DCE), на которые ссылается коннектор, настроены неправильно, из-за чего после успешного считывания коннектором данных из BLOB-объекта возникают сбои при приеме данных.

Решение. Проверка конфигурации DCR и DCE

1. Убедитесь, что DCE, указанный в свойстве соединителя dcrConfig.dataCollectionEndpoint , доступен и находится в том же регионе, что и рабочая область Log Analytics.
2. Убедитесь, что неизменяемый идентификатор DCR в dcrConfig.dataCollectionRuleImmutableId указан правильно. Неизменный идентификатор можно найти, открыв свойства ресурса DCR в портале Azure или с помощью API DCR.
3. Убедитесь, что streamName в конфигурации соединителя соответствует значению streamDeclarations , определенному в DCR.
4. Если DCR использует запрос преобразования KQL, проверьте запрос независимо в рабочей области Log Analytics, чтобы убедиться, что он действителен.
5. Убедитесь, что целевая таблица, определенная в DCR, существует в рабочей области Log Analytics и имеет ожидаемую схему.
6. Дополнительные сведения о настройке DCR см. в разделе Конфигурация DCR справочника по API.

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

Из этой статьи вы узнали, как быстро определить причины и устранить распространенные проблемы с соединителем blob-объектов хранилища Azure.

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

Связанные материалы

• Настройка соединителя хранилища Azure для потоковой передачи журналов в Microsoft Sentinel
• Справочник по соединителю данных Azure Blob Storage для платформы соединителей без написания кода
• Включите сетевую безопасность для ресурсов интегрированного хранилища коннектора
• Создание соединителя без кода для Microsoft Sentinel