Снимаем пелену с M365: почему стандартные коннекторы SIEM оставляют вас «слепыми»

By Mirko Peters · 2026-08-11

Снова добро пожаловать в блог! Если вы отвечаете за операции безопасности в организации, которая использует Microsoft 365, скорее всего, у вас возникает ложное чувство безопасности. Вы нажали «en…

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в блог! Если вы отвечаете за операции безопасности в организации, которая использует Microsoft 365, вероятно, у вас есть ложное ощущение защищённости. Вы нажали «включить» в стандартном коннекторе M365 вашей SIEM, проверили, что логи поступают, и поставили галочку для соответствия требованиям. Но вы действительно защищены? Неприятная правда в том, что коннекторы SIEM «из коробки» часто оставляют серьёзные слепые зоны, полностью пропуская современные облачные нагрузки, в которых любят действовать злоумышленники. Чтобы полностью разобраться в этой важной теме, обязательно послушайте наш сопутствующий подкаст Send Critical Microsoft 365 Logs to Your SIEM, где мы подробно разбираем эти пробелы.

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

Слепые зоны Microsoft 365 в популярных SIEM

Используете ли вы Microsoft Sentinel, Splunk или QRadar, стандартные шаблоны приёма данных обычно ориентированы на базовые входы в Azure Active Directory и простые журналы действий Office 365. Это покрывает абсолютный минимум, но оставляет критически важные нагрузки полностью незащищёнными. На популярных платформах SIEM постоянно проявляются несколько крупных слепых зон:

• Exchange: стандартные коннекторы часто пропускают доступ к почтовым ящикам не их владельцами, подозрительное создание правил и перенаправления, действия SendAs и SendOnBehalf, а также внезапные изменения разрешений на почтовые ящики.
• SharePoint и OneDrive: вы можете видеть скачивания файлов, но видите ли вы создание и использование внешних и анонимных ссылок, повторный общий доступ к файлам или изменения привилегированных разрешений сайтов?
• Teams: злоумышленники любят сотрудничать на виду. Стандартные конфигурации редко фиксируют внешний обмен через каналы на базе SharePoint, удаление и редактирование сообщений, изменения политик собраний или несанкционированную загрузку приложений в обход магазина.
• Power Platform: рост сред low-code/no-code приносит скрытые риски. Всплески создания потоков и приложений, рискованное использование коннекторов (например, Outlook, Teams или произвольных HTTP-коннекторов) и обходы политик предотвращения утечек данных (DLP) часто не учитываются.
• Конфиденциальность и DLP: события применения и удаления меток, срабатывания политик и ручные переопределения часто полностью отсутствуют, если их прямо не настроить.
• Контекст Azure AD: критически важный контекст о рискованных входах, результатах условного доступа, а также аномалиях устройств и географии часто выпадает из стандартных запросов.

Первопричины: почему вы не видите важных событий

Почему эти важные потоки телеметрии отсутствуют? Это редко происходит случайно; скорее, это результат архитектурных и коммерческих решений, которые принимают как поставщики платформ, так и корпоративные покупатели.

Во-первых, огромную роль играют ограничения лицензий. Расширенный аудит, детальная телеметрия Exchange и богатое журналирование событий SharePoint часто доступны только в более высоких лицензиях, таких как Microsoft 365 E5, или по дополнительным пакетам Advanced Audit. Если ваш клиент работает на уровне E3, эти события просто не генерируются и не сохраняются.

Во-вторых, ограничения области коннекторов сужают сбор данных. Стандартные коннекторы обычно забирают базовые потоки «OfficeActivity», игнорируя расширенные нагрузки. В-третьих, ограничение пропускной способности API и задержки пакетной обработки могут перегрузить встроенные коллекторы в часы пиков, из-за чего логи теряются. В-четвёртых, пробелы в парсерах означают, что даже если сырые JSON-объекты поступают в SIEM, немаппированные поля и незаметные изменения схемы делают их бессмысленным набором символов. Наконец, меры контроля затрат, которые принимают команды, стремящиеся к экономии бюджета, тихо исключают «шумные» категории без понимания последствий для безопасности.

Контроль затрат без потери видимости

Один из самых весомых аргументов против приёма «полной» телеметрии Microsoft 365 — стоимость. Приём каждого журнала, который генерирует крупный клиент M365, может обескровить бюджет на хранение данных службы безопасности. Однако выбирать между разорением и слепотой не нужно. Фильтровать нужно умно, а не меньше.

Начните с фильтрации на входе. Настройте механизмы приёма так, чтобы в SIEM попадали только события с высокой информативностью, например New-InboxRule, Add-MailboxPermission, а также события создания и использования анонимных ссылок. Дедуплицируйте и агрегируйте шумные события с низкой ценностью, например фоновые сохранения версий в SharePoint, до того как они попадут в ваш SIEM.

Внедрите многоуровневые стратегии хранения. Держите горячее хранилище коротким сроком (30–60 дней) для активных расследований, а холодное или архивное хранилище переносите в более дешёвые объектные хранилища, чтобы соответствовать требованиям комплаенса по срокам хранения. Кроме того, смоделируйте объём данных до включения новых потоков. Прогнозируйте объём в гигабайтах в сутки по каждому источнику и удваивайте эти оценки, чтобы учесть пиковые нагрузки в бизнесе, квартальные аудиты или периоды юридического поиска (legal discovery).

Проектирование отказоустойчивого конвейера приёма данных

Полагаться на хрупкие коннекторы с прямым опросом источников — верный путь к пропущенным оповещениям в самые напряжённые моменты инцидентов безопасности. Вместо этого спроектируйте отказоустойчивый конвейер, учитывающий ограничения частоты запросов (throttling). Надёжный шаблон выглядит так:

• Источник: Получайте данные из единого журнала аудита Microsoft 365, расширенного аудита, журналов входа и рисков Azure AD, Microsoft Information Protection (MIP), оповещений DLP и оповещений Microsoft Defender.
• Транспорт: Направляйте данные из Graph или Management API в Azure Event Hub (он выступает буфером и механизмом повторного воспроизведения) и только потом пересылайте их в SIEM.
• Обработка: Нормализуйте и обогащайте данные прямо в зоне приёма, добавляя контекст пользователя, флаги отделов, обозначения VIP, состояния устройств и географические данные.
• Управление: Внедрите ежедневные проверки полноты данных, обработчики повторных попыток с экспоненциальной задержкой при ошибках 429 (превышение лимита запросов), контроль изменений схемы и оповещения об очереди недоставленных сообщений (dead-letter queue).

Нормализация и обогащение данных для аналитиков

Сырые журналы Microsoft 365 известны своей запутанностью: вложенные JSON-объекты и непоследовательные имена полей в разных сервисах. Если передать сырые данные аналитику первой линии, он потратит половину смены на расшифровку полезной нагрузки вместо анализа угроз.

Выделяйте ключевые поля на этапе приёма: Actor, Target, Action, ResourcePath, LinkType (anonymous, organization или specific people), ExternalRecipient и LabelName. Сопоставьте эти поля с единой схемой, например Azure Monitor Common Security Incident Model (ASIM) или Elastic Common Schema (ECS), чтобы ваша разработка детектирования охватывала все сервисы без разрывов. Наконец, обогатите события данными HR (роль, тип занятости, отдел), списками VIP, списками разрешённых партнёров, состояниями соответствия устройств и классификациями конфиденциальности.

Высокоинформативные детекции, которые стоит внедрить сейчас

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

• Эксфильтрация из почтового ящика: Обнаруживайте новое правило входящей почты, которое пересылает письма во внешний адрес или перемещает сообщения в RSS или «Нежелательную почту», если это происходит в течение часа после входа с новой географической точки или неизвестного устройства.
• Скрытый доступ: Отмечайте доступ к почтовому ящику VIP-пользователя, выполненный не владельцем, если за предшествующие 24 часа было событие Add-MailboxPermission.
• Утечка через SharePoint: Оповещайте о анонимных ссылках или ссылках для «определённых пользователей», созданных для файлов с метками «Confidential» или «Restricted».
• Злоупотребление ссылками: Обнаруживайте большое количество внешних загрузок в течение 15-минутного окна от недавно созданной ссылки для общего доступа, поступающих с нового IP-адреса или ASN.
• Переход через Teams: Выявляйте сценарии, когда файл открыт для внешнего доступа, а тот же пользователь в течение двух часов добавляет внешнего гостя в команду.
• Злоупотребление Power Automate: Отмечайте внезапный всплеск создания трёх и более потоков в день учётной записью, не являющейся разработчиком, в частности с использованием коннекторов HTTP или Outlook.
• Накопление привилегий: Отслеживайте повторяющиеся добавления и удаления ролей участника или администратора в одном и том же чувствительном рабочем пространстве или сайте в течение 24-часового окна.
• Устаревшие данные: Обнаруживайте случаи, когда наборы данных с содержимым для руководства или финансов не обновляются два и более цикла подряд, чтобы руководство не принимало решения на основе устаревших данных.

Ваш 30-дневный план устранения пробелов во внедрении

Чтобы устранить пробелы в видимости Microsoft 365, не нужно целый год. Вы можете системно закрыть их всего за 30 дней:

• Неделя 1: Включите расширенный аудит там, где это необходимо, составьте инвентаризацию текущих коннекторов SIEM и определите недостающие категории событий.
• Неделя 2: Разверните конвейер Event Hub. Направьте в него телеметрию Unified Audit Logs, Advanced Audit, Azure AD и Defender и настройте фильтры на стороне источника.
• Неделя 3: Нормализуйте и обогатите потоки данных, загрузите данные за последние 30 дней по критически важным журналам и разверните семь высокоинформативных детекций, перечисленных выше, с корректно настроенными окнами подавления.
• Неделя 4: Оптимизируйте расходы, отбрасывая оставшийся шум и корректируя уровни хранения. Добавьте мониторинг полноты данных и проведите учебное упражнение purple team по настольному сценарию, проверяя правила почтовых ящиков, внешний обмен и всплески потоков Power Automate.

Ключевые KPI для руководства, подтверждающие эффективность

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

• Охват: Доля целевых групп событий M365, которые были успешно переданы и разобраны (целевой показатель 95% и выше).
• Скорость: Среднее время подтверждения (MTTA) и среднее время устранения (MTTR) инцидентов, связанных с M365 (с тенденцией к снижению).
• Шум: Соотношение оповещений и истинно положительных срабатываний (с тенденцией к росту качества сигнала).
• Стоимость: Стоимость загрузки одного гигабайта данных (с тенденцией к снижению примерно на 40% благодаря фильтрации на стороне источника).
• Надежность: Количество дней с пробелами в загрузке данных (цель: ноль) и SLA на изменения схемы (обновление парсеров в течение семи дней после изменения схемы Microsoft).

Типичные ловушки и способы их избежать

Даже самые продуманные планы могут натолкнуться на препятствия. Обратите внимание на следующие распространенные ошибки:

Команды часто говорят: «Мы включили», но журналы так и не появляются, потому что лицензии Advanced Audit или базовые настройки аудита почтовых ящиков никогда не проверялись должным образом. Еще одна распространенная проблема: правила SIEM полностью молчат во время атак, потому что анализируют события изолированно, а не сопоставляют создание правил, географические сдвиги и внешний обмен.

Резкий рост счетов возникает, когда пропускается предварительная фильтрация. Всегда предварительно фильтруйте шумные операции и исключайте фоновые события синхронизации. Устаревание парсеров — еще один незаметный убийца: установите ежемесячную проверку различий схемы и запускайте модульные тесты на образцах данных. Наконец, усталость аналитиков наступает быстро, если оповещения лишены контекста. Всегда убеждайтесь, что оповещения содержат информацию о том, кто, что, где и какие метки конфиденциальности применены, и прямые ссылки на Microsoft Compliance Center для углубленного анализа.

Вывод: перестаньте полагаться на Compliance как на защиту

Главный вывод прост: стандартные коннекторы SIEM помогают соответствовать требованиям, но не защищают. Получая нужные журналы Microsoft 365, приводя их к единой схеме, обогащая важным бизнес-контекстом и выполняя поиск угроз с детекциями, настроенными под реальное поведение злоумышленников, вы можете полностью устранить слепые зоны. Так ваш SIEM перестает пропускать историю и начинает ее записывать. Чтобы глубже разобраться в этой стратегии, послушайте полный эпизод Send Critical Microsoft 365 Logs to Your SIEM и начните закрывать пробелы в видимости уже сегодня!