Microsoft AZ-500: Microsoft Sentinel и операции по обеспечению безопасности — Руководство по подготовке

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Часть Microsoft Azure Security Engineer Associate AZ-500 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Аналитика, обнаружение и расследование

• Типы правил аналитики

  • Запланированные правила (Scheduled rules): выполняют запросы KQL к историческим данным с заданной периодичностью (например, каждые 5 минут с ретроспективным анализом за 1 час). Используйте для большинства обнаружений; настраивайте окно ретроспективного анализа так, чтобы оно превышало типичную задержку данных во избежание пропусков.
  • Правила почти реального времени (NRT): обнаружение менее чем за минуту с ограниченным KQL и фиксированным коротким окном ретроспективного анализа. Используйте экономно для шаблонов высокой срочности, где важны секунды (например, массовое назначение ролей). Для высокой производительности используйте минимальное количество объединений (joins) и простые фильтры.
  • Fusion: многоэтапная корреляция на основе машинного обучения по сигналам от продуктов Microsoft (Defender, Entra, Cloud Apps). Обоснование: значительно снижает усталость от оповещений, создавая единый инцидент для всей цепочки атаки (kill chain).
  • Правила аномалий (Anomaly rules): базовые профили пользователей/сущностей с динамическими порогами. Обеспечивают быстрые результаты при обнаружении необычных геолокаций, объемов или шаблонов процессов; ведите списки исключений для разрешенных аномалий (например, во время окон обслуживания).
  • Правила безопасности Microsoft (Microsoft security rules): автоматически создают инциденты из оповещений Defender. Держите их включенными и настраивайте правила автоматизации для маршрутизации/изменения серьезности; они предоставляют сигналы с высокой степенью достоверности при низких затратах на настройку.

• Сопоставление сущностей и инциденты

  • Сопоставляйте выходные столбцы KQL с сущностями (Account, Host, IP, URL, File) в конфигурации правила для работы графов инцидентов и UEBA. Некорректное сопоставление снижает точность расследования.
  • Политика группировки оповещений влияет на объем инцидентов и их контекст. Группируйте по сущностям/временному окну, чтобы объединять связанные оповещения, уменьшая шум и сохраняя последовательность событий.

• Расследование и UEBA

  • Инциденты представляют временную шкалу, доказательства и связанные сущности; граф расследования автоматически строит связи на основе сопоставления сущностей и поиска данных.
  • Включите UEBA для обогащения сущностей базовыми профилями аналогов (peer baselines), ролями устройств и сигналами риска. Обоснование: контекст сокращает время на первичный анализ (triage) и определяет масштаб реагирования.

• Основы KQL для инженерии обнаружения

  • Фильтрация и проекция

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Парсинг и нормализация

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Объединение (Joining)

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Агрегирование и анализ по временным окнам

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

Охота на угрозы, автоматизация, аналитика угроз, отчетность и настройка SOC

• Рабочий процесс охоты на угрозы

  • Поисковые запросы для охоты: начните с шаблонов Sentinel; развивайте их, добавляя белые списки для конкретной среды. Сохраняйте перспективные зацепки как пользовательские запросы для повторного использования.
  • Закладки: фиксируйте доказательства и ключевые точки во время охоты; позже прикрепляйте их к инцидентам, чтобы сохранить контекст для аналитика.
  • Livestream: непрерывно выполняйте фильтр KQL для отслеживания событий по мере их поступления; идеально подходит во время активных инцидентов для подтверждения сдерживания.
  • Списки отслеживания: загружайте наборы разрешений/запретов/приоритетов в формате CSV (VIP-пользователи, разрешенные IP-адреса, уровни активов). Обращайтесь к ним с помощью функции _GetWatchlist для обогащения данных и подавления оповещений.

• Правила автоматизации и плейбуки

  • Правила автоматизации выполняют триаж при создании инцидента/оповещения: устанавливают серьезность, назначают владельца, добавляют теги, закрывают с классификацией или запускают плейбуки на основе условий (имя правила, тактики, сущности).
  • Плейбуки (Logic Apps) реализуют SOAR: обогащают данные с помощью VirusTotal/MDTI, отправляют уведомления в Teams, открывают заявки (ServiceNow/Jira), изолируют конечные точки (MDE) или отключают учетные записи (Entra). Используйте управляемые удостоверения и RBAC с минимальными привилегиями (роль Sentinel Responder для рабочей области; роли с ограниченной областью действия для целевых систем). Обоснование: формализованные, повторяемые действия сокращают MTTR и уменьшают количество ошибок, совершаемых вручную.

• Аналитика угроз (TI)

  • Получайте индикаторы TI с помощью встроенных поставщиков, ручной загрузки, автоматизации через GitHub или сборщиков TAXII (STIX 2.0/2.1). Нормализуйте поля (тип индикатора, шаблон, уровень достоверности, TLP) и устанавливайте срок действия, чтобы предотвратить устаревшие совпадения.
  • Сопоставление индикаторов: включите аналитические правила на основе TI для сопоставления IP/доменов/URL/хешей с телеметрией (CommonSecurityLog, DNS, Proxy, SignInLogs). Используйте пороги достоверности и исключения из списков отслеживания для снижения шума. Обоснование: TI сужает область поиска до известных угроз, но требует тщательного отбора для предотвращения ложных срабатываний.

• Книги и отчетность

  • Создавайте операционные дашборды с помощью Azure Monitor Workbooks. Параметризуйте их по подписке, рабочей области или временному диапазону; агрегируйте данные на раннем этапе (summarize, make-series), чтобы поддерживать эффективность запросов.
  • Предоставляйте многоуровневые представления: общая картина для руководства (инциденты по серьезности/SLA), операции SOC (открытые/закрытые, старение очереди, нагрузка на аналитиков), состояние обнаружений (статус коннекторов, задержка данных) и покрытие контролей (сопоставление с MITRE). Обоснование: представления для конкретных ролей поддерживают принятие решений, не перегружая пользователей необработанными событиями.

• Настройка SOC и процедуры

  • Снижение числа ложных срабатываний: уточняйте предикаты KQL, добавляйте базовые показатели (динамические пороги), используйте белые списки сущностей (списки отслеживания) и исключайте безопасные источники. Подтверждайте каждое подавление компенсирующим контролем.
  • Нормализация уровней серьезности: сопоставляйте серьезность правила с влиянием и достоверностью, а не с частотой. High должен означать немедленное вмешательство дежурного специалиста; Medium — оперативный триаж; Low — анализ в фоновом режиме.
  • Эскалация и передача ответственности: определите состояния инцидентов, владельцев и SLA; автоматически обогащайте данные и направляйте в нужную очередь; открывайте заявки в ITSM через плейбуки с двусторонним обновлением. Документируйте шаги по сдерживанию для каждой тактики (отключить пользователя, изолировать конечную точку, отозвать токены, заблокировать индикаторы).

Практический сценарий

Компания Contoso Ltd. сталкивается с усталостью от оповещений и медленным реагированием после подключения нескольких источников данных к Microsoft Sentinel. Инцидентов много, они плохо сгруппированы, и им не хватает автоматизации. Директор по информационной безопасности (CISO) требует сократить среднее время реагирования (MTTR) на 50% без потери точности обнаружения.

1. Перестроить прием данных с помощью фильтрации DCR и планов таблиц

• Действие: Перевести Windows Security Events на AMA+DCR с предустановкой “Common” на контроллерах домена; переключить подробные диагностические таблицы на Basic Logs; включить 90-дневное хранение на горячем уровне и 1-годичный архив.
• Обоснование: Сокращает шум и стоимость хранения на горячем уровне, сохраняя при этом пригодные для действий данные безопасности, что высвобождает аналитические циклы и бюджет для более точных обнаружений.

2. Включить коннекторы Microsoft Defender и Fusion

• Действие: Подключить MDE, MDI, MDO, MDC и Cloud Apps; убедиться, что аналитика безопасности Microsoft и Fusion включены.
• Обоснование: Оповещения с высоким уровнем достоверности и корреляция на основе ML объединяют дублирующиеся оповещения в один обогащенный инцидент, снижая нагрузку по триажу.

3. Стандартизировать сопоставление сущностей и группировку оповещений

• Действие: Обновить запланированные правила для сопоставления сущностей Account, Host, IP и URL; настроить группировку по сущности Account и 4-часовому окну для связанных оповещений.
• Обоснование: Правильное сопоставление обеспечивает работу графов расследований и UEBA; группировка снижает количество инцидентов, сохраняя контекст для цепочек атак.

4. Внедрить правила автоматизации для триажа и целевые плейбуки

• Действие: Создать правила автоматизации для автоматического добавления тегов по тактикам, установки серьезности на основе достоверности, назначения в очереди и запуска плейбуков: обогащение индикаторов (MDTI), открытие заявок в ServiceNow, изоляция устройств (MDE) и приостановка рискованных пользователей (Entra) с подтверждением.
• Обоснование: Детерминированный триаж в сочетании с действиями SOAR сокращает MTTR и стандартизирует реагирование; подтверждения обеспечивают защитные механизмы для действий с высоким уровнем влияния.

5. Внедрить списки отслеживания и сопоставление TI с тщательным отбором

• Действие: Создать списки отслеживания для VIP-пользователей и разрешенных сервисов; добавить отобранный канал TAXII с уровнем достоверности >= 70 и сроком действия 7 дней; включить правила сопоставления TI для данных proxy/DNS.
• Обоснование: Приоритизирует высокоценные цели и использует свежую, достоверную аналитику угроз (TI) для фокусировки расследований и снижения числа ложных срабатываний.

6. Опубликовать книги на основе ролей и SLA

• Действие: Создать книги для руководства, операций SOC и состояния обнаружений; установить SLA для инцидентов (High — 4 ч, Medium — 24 ч, Low — 3 д) и сообщать о нарушениях.
• Обоснование: Прозрачность и подотчетность стимулируют операционную дисциплину; целевые дашборды предотвращают переключение контекста и потерю времени.

7. Установить ритм непрерывной настройки

• Действие: Еженедельно пересматривать инциденты, закрытые как ложные срабатывания; корректировать правила, подавления и исключения с документированным обоснованием; отслеживать аномалии приема данных и производительность запросов.
• Обоснование: Без петель обратной связи операционная безопасность деградирует; постоянное совершенствование поддерживает качество сигнала по мере развития среды.

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

← Управление состоянием безопасности и корпоративное управление · Все домены · Безопасность приложений и DevSecOps →

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

Просмотреть Microsoft →