Microsoft AZ-500: Реагирование на инциденты, восстановление и устойчивость — Руководство по подготовке
Часть Microsoft Azure Security Engineer Associate AZ-500 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.
Обзор
Реагирование на инциденты, восстановление и отказоустойчивость в Azure — это непрерывный процесс, который сочетает в себе отработанные операционные процедуры и встроенные в платформу средства контроля. Эффективная программа предполагает прогнозирование сбоев или компрометации, быстрое обнаружение и сортировку, ограничение радиуса поражения с помощью автоматизации, восстановление сервисов в соответствии с заданными целями, сохранение неизменяемых доказательств и последующее усиление защиты среды на основе полученного опыта. Встроенные сервисы Azure — Microsoft Sentinel, Defender for Cloud, Logic Apps, Azure Backup, Azure Site Recovery (ASR), DDoS Protection, Web Application Firewall (WAF), Traffic Manager/Front Door и Microsoft Entra — предоставляют для этого все необходимые компоненты. Ключевое требование при проектировании — это предварительная подготовка нужной телеметрии, путей для экстренного доступа к удостоверениям и автоматизированных средств принудительного применения политик, чтобы команды могли реагировать за минуты, а не за часы.
Жизненный цикл реагирования на инциденты и операции в Sentinel
Подготовка
- Определите, кто, что, когда и с помощью каких инструментов делает. Заранее подготовьте рабочие области Microsoft Sentinel, подключите источники данных (журнал действий, журналы ресурсов, журналы потоков NSG, журналы входа/аудита Microsoft Entra, сигналы Defender) и внедрите средства контроля доступа и RBAC для аналитиков, специалистов по реагированию и руководителей по инцидентам.
- Создайте сборники сценариев (playbooks в Logic Apps) для стандартных действий по сдерживанию, таких как изоляция ВМ, отзыв токена пользователя или ротация ключей. Заранее подготовьте карантинные NSG и выделенные подписки для «криминалистического анализа».
- Настройте хранение неизменяемых журналов через Diagnostic Settings в Log Analytics и в учетной записи Azure Storage с политикой неизменяемости (WORM).
Обнаружение
- В Sentinel включите правила аналитики для обнаружения кражи учетных данных, редких шаблонов входа, подозрительного выполнения процессов, неправомерного использования Key Vault и эксфильтрации данных. Дополните их правилами UEBA и fusion для корреляции безвредных событий в значимые инциденты. Откалибруйте пороговые значения и подавление правил, чтобы минимизировать усталость от оповещений.
Сдерживание
- Выполняйте заранее утвержденные действия: помещайте сетевые интерфейсы в карантин с помощью NSG, отключайте скомпрометированные субъекты-службы, отзывайте токены обновления Entra, ротируйте секреты, отключайте входящие публичные конечные точки или переводите WAF в режим предотвращения. Используйте правила автоматизации Sentinel для маршрутизации по степени серьезности, добавления тегов, назначения ответственных и запуска сборников сценариев (playbooks).
Ликвидация
- Устраните механизмы закрепления (задачи автозапуска, запланированные задания, скрипты cloud-init, вредоносные расширения), ротируйте учетные данные, повторно развертывайте «золотые образы» и устраняйте уязвимости, обнаруженные Defender for Cloud. При инцидентах, связанных с удостоверениями, требуйте сброса паролей и усиливайте политики условного доступа (Conditional Access).
Восстановление
- Восстанавливайте данные из Azure Backup в «чистые» виртуальные сети; выполняйте отработку отказа с помощью планов восстановления ASR; проверяйте целостность и восстанавливайте секреты и конфигурации из заведомо надежных источников (шаблоны IaC, Key Vault с включенной защитой от обратимого удаления и очистки). Убедитесь, что целевые показатели времени и точки восстановления (RTO и RPO) соблюдены.
Извлеченные уроки
- Проведите разбор инцидента без поиска виновных. Обновите правила и сборники сценариев (playbooks) Sentinel, назначения Azure Policy, базовые образы и модули runbook. Кодифицируйте исправления в виде IaC и применяйте их через группы управления.
Сортировка инцидентов в Sentinel, сбор доказательств, расследование и управление делами
Сортировка (Triage)
- Приоритизируйте инциденты по степени серьезности, критичности актива и радиусу поражения, используя обогащение сущностей (хост, пользователь, IP) и списки отслеживания (watchlists). Используйте группировку инцидентов для уменьшения дубликатов и представление временной шкалы для понимания последовательности событий.
Сбор доказательств
- Добавляйте в закладки значимые события, экспортируйте необработанные журналы в неизменяемое хранилище, создавайте снимки дисков затронутых ВМ для офлайн-анализа и фиксируйте деревья процессов через интеграцию с Defender for Endpoint. Обеспечивайте сохранность доказательств (chain-of-custody), сохраняя хеши и ограничивая доступ к группе ресурсов для криминалистического анализа.
Расследование
- Используйте графы расследований и страницы сущностей (история входов пользователя, дерево процессов хоста). Выполняйте проактивный поиск угроз (hunting) с помощью KQL по журналам SigninLogs, AuditLogs, SecurityEvent и AzureDiagnostics. Фиксируйте результаты, прикрепляйте артефакты и помечайте индикаторы компрометации (IOC) для будущего обнаружения.
Управление делами (Case management)
- Стандартизируйте статусы (New, Active, In Progress, Resolved), ответственных и таймеры SLA. Интегрируйте Sentinel с ITSM-системами (ServiceNow/Azure DevOps) для управления заявками и изменениями. Правила автоматизации могут автоматически закрывать известные безвредные оповещения или эскалировать инциденты с определенными тактиками на второй уровень поддержки (Tier 2).
Автоматизированное сдерживание и оркестрация рабочих процессов
Правила автоматизации Sentinel
- Срабатывают при создании/обновлении инцидента. Динамически назначают ответственного, устанавливают степень серьезности, добавляют теги (например, QuarantineCandidate) и вызывают один или несколько сборников сценариев (playbooks). Обоснование: переход от обнаружения к действию за секунды, в соответствии с принципом наименьших привилегий и с использованием заранее утвержденных сборников сценариев.
Сборники сценариев (playbooks) в Logic Apps
- Типичные действия: применить карантинную NSG к сетевому интерфейсу ВМ, отключить пользователя, отозвать токены, заблокировать IP-адрес в WAF или создать заявку в ITSM-системе с полным контекстом. Используйте управляемые удостоверения и Azure RBAC, чтобы ограничить разрешения каждого сборника сценариев (playbook) точным набором ресурсов.
Автоматизация рабочих процессов в Defender for Cloud
- При появлении рекомендаций или оповещений (например, «Открыт доступ по RDP из Интернета») автоматически запускайте сборники сценариев (playbooks) для исправления (ужесточения правил NSG), пометки ресурсов для последующей проверки или уведомления владельцев. Обоснование: быстрое устранение уязвимости, улучшение показателя Secure Score и сокращение времени присутствия злоумышленника.
Пример: помещение сетевого интерфейса ВМ в карантин за секунды
# Create a high-priority deny-all inbound NSG rule and associate a quarantine NSG to the NIC
az network nsg rule create -g rg-prod -n QuarantineDenyAll --nsg-name nsg-quarantine \
--priority 100 --access Deny --direction Inbound --protocol '*' --source-address-prefixes '*' \
--source-port-ranges '*' --destination-address-prefixes '*' --destination-port-ranges '*'
az network nic update -g rg-prod -n vm1-nic --network-security-group nsg-quarantine
Отзыв токена для скомпрометированного пользователя
az rest --method POST \
--uri "https://graph.microsoft.com/v1.0/users/user@contoso.com/revokeSignInSessions"
Резервное копирование, репликация, RTO/RPO и отказоустойчивость
Безопасность Azure Backup
Хранилища Recovery Services и хранилища Backup
- Используйте хранилища для каждой границы рабочей нагрузки и региона. Включите обратимое удаление (soft delete) для защиты от случайного или злонамеренного удаления элементов резервного копирования; установите подходящий период хранения в соответствии с нормативными требованиями. Включите защиту от очистки (purge protection), где это поддерживается, чтобы предотвратить необратимое удаление.
Неизменяемость
- Настройте неизменяемость хранилища. Используйте разблокированный режим (unlocked mode) во время начальной настройки, а затем переключитесь в заблокированный режим (locked mode), чтобы предотвратить сокращение срока хранения или изменение политик. Обоснование: обеспечивает однократную запись и защиту от изменений для резервных копий, что является ключевым средством защиты от программ-вымогателей.
Многопользовательская авторизация (MUA)
- Защитите критически важные операции резервного копирования (например, остановку защиты с удалением данных, изменение настроек хранилища) с помощью Azure Backup Resource Guard в отдельной подписке/группе ресурсов, принадлежащей другой команде. Обоснование: обеспечивает разделение обязанностей; злоумышленникам для уничтожения возможности восстановления потребуется скомпрометировать две учетные записи в разных областях.
Межрегиональные возможности
- Для RSV, использующих GRS, включите межрегиональное восстановление (cross-region restore), чтобы обеспечить восстановление даже при недоступности основного региона. Убедитесь, что криптографические ключи, используемые рабочими нагрузками, также отказоустойчивы (обратимое удаление/защита от очистки в Key Vault и, при необходимости, планирование геоизбыточного восстановления).
Azure Site Recovery (ASR)
Репликация
- Из Azure в Azure, из VMware/Hyper-V в Azure и с физических серверов. Определите политики репликации (порог RPO, хранение точек восстановления, частота создания согласованных с приложениями снимков). Разверните службу Mobility service там, где это необходимо.
Планы восстановления
- Организуйте отработку отказа многоуровневых приложений с помощью порядка загрузки, ручных шагов и runbooks (например, обновление DNS, переключение строк подключения). Храните учетные данные и скрипты в Key Vault.
Тестовая отработка отказа
- Регулярно проводите неразрушающие тесты в изолированной VNet со скрытыми IP-адресами. Используйте «Очистку тестовой отработки отказа» (Cleanup test failover) для сброса состояния. Обоснование: проверяет сквозное восстановление без влияния на производственную среду.
Восстановление на основной сайт (Failback)
- После восстановления основного сайта повторно защитите его и выполните failback, ресинхронизируя изменения. Планируйте окна пропускной способности и технического обслуживания для соблюдения бизнес-SLA.
Выбор архитектуры для соответствия RTO/RPO
Жесткий RPO (секунды-минуты) и низкий RTO (минуты)
- Предпочитайте ASR или нативную репликацию приложений (например, SQL Always On, многорегиональный Cosmos DB) резервному копированию; поддерживайте горячий или теплый резерв; используйте Front Door/Traffic Manager для региональной отработки отказа.
Умеренный RPO (часы) и RTO (часы)
- Сочетайте частое резервное копирование с ASR для критически важных уровней; используйте функции ускорения резервного копирования (снимки для мгновенного восстановления), чтобы сократить время восстановления.
Длительный RPO (дни) и RTO (дни)
- Только резервное копирование с более длительным хранением; оптимизированные по стоимости архивные уровни.
Операционное обоснование: репликация обеспечивает малый RPO при более высоких текущих затратах; резервное копирование обеспечивает более дешевое долгосрочное хранение, но с более медленными RTO/RPO. Комбинируйте подходы для каждого уровня в соответствии с анализом влияния на бизнес.
← Гибридная и мультиоблачная безопасность · Все домены
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →