Microsoft AZ-801: Microsoft Sentinel и мониторинг безопасности — Руководство по подготовке

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Часть Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Microsoft Sentinel — это облачная SIEM- и SOAR-система, которая объединяет сбор журналов, аналитику, обнаружение угроз, реагирование на инциденты и проактивный поиск угроз в гибридных средах Windows Server. Для сценариев AZ-801 успешное освоение включает подключение источников Windows Security Events, Linux Syslog и сторонних CEF в больших масштабах, разработку аналитики с минимальной задержкой, сопоставление оповещений с сущностями для точного расследования и автоматизацию мер сдерживания с помощью сценариев на базе Logic Apps. Успех также зависит от продуманной архитектуры рабочей области Log Analytics, хорошо управляемых правил сбора данных (DCR) для Azure Monitor Agent (AMA), надежной стратегии хранения данных и операционных навыков в работе с UEBA, списками наблюдения, поиском угроз и книгами.

Коннекторы и сбор данных

События безопасности Windows (Windows Security Events) через AMA — это канонический источник для событий входа в систему, создания процессов, изменения политик и других событий аудита на Windows Server. Включите коннектор “Windows Security Events via AMA” в Microsoft Sentinel и создайте DCR, которое выбирает наборы событий, соответствующие вашему профилю рисков (Minimal, Common или All, либо пользовательский выбор по Event ID). Данные в основном попадают в таблицу SecurityEvent; события из каналов Windows, не связанных с безопасностью (если они включены), попадают в WindowsEvent. Используйте групповые политики, чтобы убедиться, что базовые параметры безопасности и подкатегории аудита (например, Logon/Logoff, Account Logon, Object Access, DS Access) включены на исходных серверах для генерации необходимой телеметрии.

Syslog через AMA собирает данные с Linux-серверов и сетевых устройств, поддерживающих Syslog. Установите AMA на хосты Linux (или на выделенный сборщик Linux) и настройте DCR для указания объектов (facilities) и уровней серьезности (severities) для сбора. События записываются в таблицу Syslog. Для объектов с большим объемом, но низкой ценностью данных, рассмотрите возможность выборочного сбора или преобразования на источнике для контроля затрат и шума.

CEF через AMA позволяет собирать нормализованные журналы безопасности от сторонних продуктов (межсетевых экранов, IDS/IPS, прокси, EDR). Разверните AMA на сборщике Linux и настройте ваши устройства на пересылку CEF локальному демону syslog (rsyslog/syslog-ng), обычно на порт 514/UDP или TCP. В Sentinel включите коннектор данных “CEF via AMA” и свяжите хост через DCR, которое анализирует CEF. Проанализированные данные попадают в таблицу CommonSecurityLog с согласованной схемой (поля deviceVendor, deviceProduct, destination/source и атрибуты расширения), что упрощает аналитику и корреляцию данных от разных поставщиков.

Для локальных серверов Windows Server используйте серверы с поддержкой Azure Arc для подключения к Azure. Подключите машины с помощью агента Azure Connected Machine, затем разверните расширение AMA через Azure Policy для масштабирования. Создавайте DCR, нацеленные на области видимости серверов Arc, для маршрутизации Windows Security Events, журналов Windows Firewall и, если используется Sysmon, пользовательское DCR для канала Microsoft-Windows-Sysmon/Operational. Этот подход централизует конфигурацию, управление версиями и таргетинг на основе области видимости, обеспечивая согласованный сбор данных без ручной работы на каждом хосте.

Архитектура рабочей области и жизненный цикл данных

Sentinel подключается к одной рабочей области Log Analytics на каждое развертывание. Архитектура рабочей области должна минимизировать межрегиональную задержку и исходящий трафик — размещайте рабочие области рядом с большинством источников данных и избегайте излишней фрагментации, которая усложняет запросы, обработку инцидентов и RBAC. Распространенные подходы — это одна рабочая область безопасности на клиент или по одной на каждый крупный регион, где требуется разделение из-за требований к местоположению данных и задержек. По возможности используйте доступ в контексте ресурсов, чтобы команды могли запрашивать журналы для ресурсов, которыми они владеют, без широких разрешений на уровне рабочей области, в то время как роли Sentinel (Reader, Responder, Contributor) управляют операциями SOC.

DCR определяют, какие типы телеметрии, каналы и наборы событий собираются и куда отправляются. Относитесь к DCR как к коду: стандартизируйте именование, контроль версий и области применения (подписки, группы ресурсов, теги). Группируйте связанные источники и назначения и предпочитайте несколько целевых DCR одному монолитному правилу, чтобы упростить управление жизненным циклом и ограничить радиус последствий изменений. При больших объемах syslog и CEF рассмотрите возможность использования отдельных DCR для независимой настройки объектов/уровней серьезности и для поддержки поэтапного тестирования.

Хранение и стоимость контролируются на уровне таблиц. Установите срок хранения по умолчанию для рабочей области в соответствии с политикой (например, 90–180 дней для активного поиска), затем при необходимости переопределите срок хранения для отдельных таблиц. Таблицы с высокой ценностью (SecurityEvent, CommonSecurityLog, SecurityAlert) обычно хранятся дольше; таблицы с подробными данными (Syslog с уровнем DEBUG) могут храниться меньше. Используйте архив для долгосрочного и недорогого хранения с возможностью поиска через задания; при необходимости для расследований переводите данные в «горячий» уровень. Где это уместно, переместите некоторые таблицы с подробными данными (например, Syslog) в Basic Logs для снижения затрат, учитывая ограничения на запросы и то, что некоторые таблицы безопасности (например, SecurityEvent) не могут быть переведены в Basic. Регулярно пересматривайте лимиты данных, уровни обязательств и тенденции сбора данных, чтобы предотвратить регулирование (throttling) и оптимизировать затраты.

Аналитика, инциденты и автоматизация реагирования

Правила аналитики — это механизм обнаружения. Правила запланированных запросов выполняют KQL по расписанию (например, каждые 5 минут) за определенный период ретроспективного анализа (например, 30 минут), поддерживая агрегации, объединения, обогащение с помощью списков отслеживания и окна подавления. Они идеально подходят для хорошо изученных паттернов, таких как множественные неудачные попытки входа с последующей успешной, эвристики бокового перемещения или подозрительные цепочки процессов. Правила почти реального времени (NRT) минимизируют задержку обнаружения, непрерывно обрабатывая новые данные с выполнением примерно каждую минуту и оповещением в течение около двух минут; создавайте NRT-правила лаконичными и используйте ingestion_time() или узкие временные окна, чтобы избежать тяжелых сканирований исторических данных. Правила Fusion используют многоэтапную аналитику атак от Microsoft для корреляции низкоуровневых оповещений из разных продуктов (например, Defender for Endpoint, Defender for Identity, Entra ID Protection, сторонние CEF) в высокоточные инциденты для кампаний, таких как кража учетных данных или атаки программ-вымогателей. Правила аномалий используют встроенные шаблоны ML, которые изучают базовые показатели (например, необычные места входа в систему, редкое выполнение процессов) и генерируют оповещения об отклонениях; они обычно считывают данные из BehaviorAnalytics и других нормализованных источников.

Инциденты объединяют несколько оповещений, сущностей и доказательств в рамках одного дела для расследования. Уровень серьезности назначается правилом аналитики (или динамически с помощью Fusion) и может быть повышен или понижен с помощью правил автоматизации. Сопоставление сущностей критически важно для эффективности расследования: в мастере правил сопоставляйте столбцы запроса с типами сущностей (Account, Host, IP, URL, File, Process, CloudApplication, AzureResource). Правильное сопоставление заполняет граф расследования, который визуализирует связи между оповещениями, событиями и сущностями, позволяя переключаться между учетными записями, хостами, процессами и IP-адресами. Используйте комментарии, теги, владельца и классификацию для фиксации решения аналитика и для обучения рабочих процессов по настройке.

Автоматизация сочетает в себе правила автоматизации и Playbooks. Правила автоматизации оценивают метаданные инцидента при его создании или обновлении, чтобы назначать владельцев, изменять уровень серьезности, добавлять теги, закрывать ложные срабатывания или вызывать Playbooks. Playbooks — это приложения Azure Logic Apps, созданные с помощью коннекторов Microsoft Sentinel. Playbooks, запускаемые по инциденту, реагируют на события жизненного цикла инцидента (например, при его создании) и подходят для действий в рамках инцидента, таких как уведомление команды, обогащение всех сущностей или создание заявки в ServiceNow. Playbooks, запускаемые по оповещению, срабатывают на отдельные оповещения до их группировки в инцидент — это полезно для обогащения данных от конкретного поставщика или для предварительной сортировки. Используйте управляемые удостоверения для Playbooks, предоставляйте минимально необходимые привилегии через Azure RBAC и разрешения API, а также параметризуйте идентификаторы рабочих областей, конечные точки систем заявок и пути к спискам блокировки для содействия повторному использованию. Там, где требуется сдерживание угрозы, включайте действия по помещению конечных точек в карантин (Defender for Endpoint), отключению учетных записей (Entra ID), блокировке IP-адресов (межсетевые экраны) или отзыву сессий (Conditional Access) только после достижения пороговых значений уверенности.

Проактивные операции по обеспечению безопасности (охота на угрозы, UEBA, списки наблюдения, книги)

Охота на угрозы (threat hunting) в Sentinel зависит от владения KQL и использования раздела Hunting. Начните со встроенных запросов для охоты, сгруппированных по тактикам; адаптируйте их для своей среды, обращаясь к таблицам, таким как SecurityEvent (аудит Windows), таблицы Device* из Defender, CommonSecurityLog (CEF) и SigninLogs (Entra). Используйте закладки (bookmarks) для создания снимков интересных записей, их аннотирования и обмена контекстом в команде; несколько закладок можно объединить в новый или существующий инцидент. Livestream непрерывно выполняет шаблон KQL для обнаружения новых совпадающих событий почти в реальном времени — это идеально подходит для расследований с ограниченным временем или сценариев быстрого реагирования. Преобразуйте отработанные запросы для охоты в запланированные правила аналитики, чтобы ввести обнаружения в эксплуатацию.

UEBA (аналитика поведения пользователей и сущностей) обогащает обнаружение поведенческими базовыми линиями и оценкой аномалий. Включите UEBA в конфигурации Sentinel и убедитесь, что подключены источники данных об удостоверениях и действиях (входы в Microsoft Entra, Defender for Endpoint, Defender for Identity, активность M365). На страницах сущностей для пользователей и хостов отображаются временные шкалы, сравнения с аналогами, аномальные действия (редкая геолокация входа, необычный процесс) и агрегированные оценки риска. Аналитики могут переходить от инцидентов к страницам сущностей, чтобы оценить, является ли действие типичным для данного удостоверения или устройства; оценки и последовательности аномалий помогают приоритизировать анализ и быстро подтвердить или опровергнуть гипотезы.

Списки наблюдения (Watchlists) предоставляют быстрый доступ к справочным данным, поддерживаемым аналитиками. Создавайте списки наблюдения путем загрузки CSV-файлов или указания пути к учетной записи хранения, определите псевдоним и выберите ключевой столбец для эффективного поиска. Используйте функцию watchlist() в KQL для объединений — распространенные варианты использования включают списки разрешенных/запрещенных административных учетных записей, чувствительных хостов, санкционированных доменов или VIP-пользователей. Включайте списки наблюдения в правила аналитики, чтобы подавлять известную легитимную активность (уменьшать количество ложных срабатываний) или повышать уровень серьезности, когда совпадение затрагивает критически важный актив. Интегрируйте их с аналитикой угроз, объединяя списки наблюдения с таблицей ThreatIntelligenceIndicator для получения контекста (например, обогащая обнаруженные IP-адреса внутренней оценкой серьезности или заметками по делу) или преобразуя курируемые потоки TI в список наблюдения для быстрого обращения и переопределения.

Книги (Workbooks) обеспечивают мониторинг и наглядность для руководства. Начните со встроенных шаблонов, таких как Security Operations Efficiency, Active Directory Sign-ins, Fusion Detections и UEBA insights. Создавайте пользовательские книги, используя запросы KQL, параметры и визуализации, чтобы формировать дашборды SOC для контроля состояния сбора данных, производительности правил, SLA по инцидентам и возникающих угроз. Применяйте RBAC к ресурсу книги и параметризуйте подписки, рабочие области и временные диапазоны, чтобы одна и та же книга могла обслуживать разные команды. Комбинируйте плитки из нескольких таблиц, чтобы сопоставлять состояние безопасности (Defender for Cloud), обнаружения (Sentinel) и метрики реагирования в одном представлении.

Практический сценарий проблемы

Компании Spotify необходимо централизовать мониторинг безопасности для 2000 серверов Windows в Azure и локальных центрах обработки данных, а также для сторонних межсетевых экранов и прокси-серверов. Им требуются обнаружения злоупотреблений учетными данными с низкой задержкой, автоматизированное создание заявок и сдерживание, а также понятные дашборды и рабочие процессы охоты на угрозы для SOC.

Подключение гибридных серверов с помощью Azure Arc и AMA

Масштабно разверните подключение серверов с поддержкой Azure Arc с помощью Azure Policy, затем назначьте политику расширения AMA для области действия Arc. Создайте DCR для «Событий безопасности Windows через AMA» (общий набор), брандмауэра Windows и пользовательский DCR для Sysmon, где он установлен. Этот подход обеспечивает последовательный, централизованно управляемый сбор данных без скриптов для каждого хоста и гарантирует заполнение таблицы SecurityEvent для аналитики удостоверений и процессов.

Сбор телеметрии сетевых устройств и устройств безопасности через Syslog и CEF

Разверните виртуальную машину-сборщик на Linux с AMA. Настройте «Syslog через AMA» для соответствующих служб и включите «CEF через AMA» для разбора данных CEF от межсетевых экранов и прокси-серверов в таблицу CommonSecurityLog. Использование CEF нормализует данные от разных поставщиков, обеспечивая переносимость правил и простоту объединения данных из разных источников.

Проектирование аналитики для скорости и точности

Включите Fusion для выявления многоэтапных атак с минимальной настройкой. Создайте правила NRT для всплесков неудачных входов, за которыми следует успешный вход под привилегированными учетными записями, используя SecurityEvent и ingestion_time(), что обеспечивает обнаружение менее чем за две минуты. Создайте запланированные правила для выявления паттернов бокового перемещения (например, создание процесса net.exe на серверах с использованием необычных административных учетных записей) и для аномалий исходящего трафика через прокси, объединенных со списками наблюдения VIP-пользователей и критически важных хостов. Такое сочетание минимизирует MTTR, одновременно сокращая количество ложных срабатываний.

Сопоставление сущностей и формирование инцидентов

В каждом запланированном правиле сопоставьте сущности Account, Host, IP и Process из столбцов запроса. Используйте правила автоматизации для назначения инцидентов по бизнес-подразделениям (определяемым по тегам хостов), стандартизации серьезности, добавления тегов MITRE и автоматического закрытия известных тестовых сигналов. Правильное сопоставление позволяет графу расследования показывать связи, по которым аналитики Spotify могут быстро перемещаться.

Автоматизация обогащения данных, создания заявок и сдерживания с помощью сборников схем (playbooks)

Создайте playbook, запускаемый по инциденту, который обогащает данные по всем учетным записям и хостам (поиск в графе, риск устройства), публикует сообщение в Teams и открывает заявку в Jira. Отдельный playbook, запускаемый по оповещению, обогащает конкретные оповещения CEF с помощью API поставщиков. Используйте управляемые удостоверения с RBAC по принципу наименьших привилегий и условное ветвление, которое изолирует устройства (через Defender for Endpoint) или отключает пользователей (через Entra ID) только при достижении пороговых значений уверенности (например, несколько подтверждающих оповещений и высокая оценка UEBA). Это сохраняет непрерывность бизнеса, обеспечивая быстрое и управляемое реагирование.

Включение UEBA и введение охоты на угрозы в эксплуатацию

Включите UEBA и проверьте источники данных (SigninLogs, активность M365, сигналы Defender). Обучите аналитиков переходить от инцидентов к страницам сущностей для просмотра оценок аномалий и сравнений с аналогами. Преобразуйте два ценных запроса для охоты — «Новые инструменты удаленного администрирования на серверах» и «Редкие паттерны эксфильтрации данных на внешние IP» — в запланированную аналитику после их проверки с помощью закладок и livestream. UEBA в сочетании с дисциплинированной охотой на угрозы улучшает обнаружение новых техник.

Управление жизненным циклом данных и визуализация состояния безопасности

Установите срок хранения 180 дней для SecurityEvent и CommonSecurityLog, 30 дней для подробного Syslog с архивацией на 1 год и отслеживайте затраты с помощью уровней обязательств (commitment tiers). Опубликуйте пользовательскую книгу SOC, которая отслеживает состояние сбора данных, самые «шумные» правила, MTTA/MTTR, очереди инцидентов по серьезности и аномалии UEBA с течением времени. Это обеспечивает прозрачность для руководства и стимулирует непрерывную настройку.

Каждый инструмент был выбран за его сильные стороны, соответствующие конкретной задаче: Arc и AMA+DCR обеспечивают масштабируемый, управляемый политиками сбор данных; CEF гарантирует нормализацию журналов безопасности от разных поставщиков; Fusion и NRT снижают задержку обнаружения без чрезмерной настройки; сопоставление сущностей и граф расследования ускоряют анализ; сборники схем (playbooks) обеспечивают управляемую автоматизацию на основе удостоверений; UEBA предоставляет поведенческий контекст; инструменты охоты на угрозы совершенствуют обнаружения; а книги (workbooks) делают операции измеримыми и наглядными.

← Microsoft Defender for Cloud и безопасность конечных точек · Все домены · Безопасность Active Directory Domain Services →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →