Microsoft AZ-500: Управление состоянием безопасности и корпоративное управление — Руководство по подготовке

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

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

Обзор

Управление состоянием безопасности и контроль в Azure — это дисциплина непрерывной оценки, приоритизации и принудительного применения конфигураций, которые снижают риски в подписках и облаках, обеспечивая при этом доказуемое соответствие требованиям. Эффективная архитектура сочетает в себе Microsoft Defender for Cloud для наглядности состояния безопасности и защиты, Azure Policy для превентивных и корректирующих барьеров, управление целевыми зонами для масштабируемого наследования и ведение журналов аудиторского уровня для подтверждения контроля. Операционная цель — обоснованное снижение рисков: решения принимаются на основе уязвимости и влияния, применяются с помощью кода, наследуются по архитектуре и подтверждаются неизменяемыми журналами.

Microsoft Defender for Cloud: архитектура, планы и рекомендации

Defender for Cloud (MDC) собирает сигналы из Azure, гибридных и мультиоблачных сред, коррелирует их для формирования Secure Score, рекомендаций и оповещений, а также может организовывать исправление. Проектируйте его на уровне корневой группы управления (MG), чтобы планы и политики наследовались всеми подписками; используйте подписки только для определения исключений. Для мультиоблачных сред развертывайте нативные коннекторы MDC для AWS и GCP на корневом уровне тенанта (или в выделенной подписке «Security»), используя учетные записи с минимальными привилегиями и централизованную автоматическую подготовку для стандартизации развертывания агентов и сбора данных.

Выбор плана зависит от рисков:

Defender for Servers: Plan 1 обеспечивает оценку уязвимостей и базовое усиление защиты; Plan 2 добавляет Microsoft Defender for Endpoint (MDE), JIT-доступ (just-in-time) к виртуальным машинам, аналитику угроз и поведения, а также мониторинг целостности файлов. Используйте Plan 2 для хостов, доступных из интернета или имеющих привилегированный доступ; Plan 1 для пулов серверов с низким уровнем уязвимости.
Defender for Storage: Обнаруживает аномальный доступ и вредоносное ПО в больших двоичных объектах (blobs), файлах и ADLS Gen2. Включайте для каждой учетной записи, нацеливая сканирование на контейнеры с высоким риском (например, для публичного приема данных), чтобы управлять затратами, покрывая при этом точки входа.
Defender for SQL: Для Azure SQL включает обнаружение угроз и оценку уязвимостей с отклонениями от базовых показателей; для SQL на машинах (включая Arc-enabled) добавляет защиту на основе агента. Включайте повсеместно для производственных баз данных; определите базовые показатели нормального поведения, чтобы уменьшить количество ложных срабатываний.
Defender for Containers: Защищает AKS и Kubernetes с поддержкой Arc с помощью сканирования уязвимостей образов (в ACR и во время выполнения), аналитики аудита Kubernetes и обнаружения угроз во время выполнения. Применяйте политики Kubernetes (Gatekeeper/OPA) через надстройку Azure Policy. Интегрируйте сканирование в CI/CD, чтобы блокировать критические CVE до развертывания.
Defender for Key Vault: Обнаруживает аномальный доступ к секретам и попытки их хищения. Используйте Azure RBAC для администрирования хранилища и политики доступа к плоскости данных (или действия с данными RBAC) для операций с секретами по принципу наименьших привилегий.
Defender for DNS: Обнаруживает хищение данных и командно-контрольные каналы (C&C) через DNS. Приоритетно включайте в периферийных VNet с выходом в интернет; агент не требуется.
Defender for DevOps: Подключите организации Azure DevOps и GitHub для оценки репозиториев, секретов, ошибок конфигурации IaC и усиления защиты конвейеров. Используйте блокирующие политики для pull-запросов при обнаружении высококритичных ошибок конфигурации, чтобы сместить снижение рисков на более ранние этапы (shift-left).

Рекомендации по безопасности объединяют результаты планов и оценки Azure Policy. Внедряйте их в эксплуатацию следующим образом:

Включив автоматическую подготовку планов на уровне MG.
Рассматривая рекомендации «высокой критичности, доступные из интернета» как рабочие элементы с контролем изменений и SLO.
Документируя исключения из правил как исключения из политик с указанием срока действия и обоснования.

Secure Score, соответствие требованиям и автоматизация рабочих процессов

Secure Score агрегирует «элементы управления» (группы связанных требований безопасности) в нормализованный процентный показатель. Каждый элемент управления имеет определенное количество баллов, которые распределяются по его «действиям по улучшению». Влияние на оценку отражает потенциал снижения риска и охват затронутых ресурсов. Приоритизируйте по:

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

Используйте действия по улучшению с руководствами по исправлению, быстрыми исправлениями и автоматизацией через Logic App. Отслеживайте остаточный риск через исключения «не может быть исправлено» или «смягчено архитектурой» с указанием срока действия для принудительной периодической перепроверки.

Соответствие нормативным требованиям в MDC сопоставляет конфигурации и рекомендации со стандартами (например, Azure Security Benchmark, CIS, NIST). Выбирайте необходимые стандарты на уровне MG; избегайте расхождений между подписками. Рассматривайте панель соответствия как отчет «политика как код»: каждый «зеленый» элемент управления должен быть отслеживаемым до политики, инициативы или автоматизированной конфигурации. Для семейств элементов управления, требующих подтверждения процессов (например, реагирование на инциденты), привязывайте визуализации из книг (workbooks) и идентификаторы заявок для поддержки аудита.

Автоматизация рабочих процессов связывает состояние безопасности с действиями. Типичные сценарии:

Триггер: Рекомендация становится неработоспособной в критически важной для бизнеса подписке → Действие: открыть заявку P1, уведомить SecOps и автоматически создать задачу на исправление.
Триггер: Новое оповещение высокой критичности на производственном ресурсе → Действие: изолировать конечную точку (MDE), поместить объект хранилища в карантин или отключить публичный доступ через исправление политики.

Управление на основе политик и целевые зоны

Azure Policy — это система превентивных и корректирующих барьеров для предотвращения дрейфа облачной конфигурации. Ключевые элементы:

Определение: Правило с условиями и эффектом. Распространенные эффекты: Deny (запрет), Audit (аудит), Append (добавление), Modify (изменение), DeployIfNotExists (развертывание, если не существует), AuditIfNotExists (аудит, если не существует) и Disabled (отключено). Используйте Deny для строгих ограничений (например, запрет публичных IP-адресов на сетевых картах). Используйте DeployIfNotExists для автоматической установки необходимых агентов или расширений (например, для защиты от вредоносных программ или MDE).
Инициатива: Специально подобранный набор определений политик, параметризованный для согласованного назначения (например, инициатива Azure Security Benchmark).
Назначение: Область применения — в первую очередь группы управления, а затем подписки или группы ресурсов для целевых переопределений. Включайте «режим принуждения» (enforcement mode) для строго обязательных политик после завершения мониторинга.
Исключения: Используйте категории Waiver (принятый риск) или Mitigated (компенсирующая мера контроля). Всегда устанавливайте срок действия, чтобы обеспечить повторную оценку.
Задачи по исправлению: Требуются для эффектов DeployIfNotExists и Modify, чтобы настроить существующие ресурсы. Предоставьте управляемому удостоверению назначения политики роль Contributor (и, при необходимости, роли на уровне плоскости данных) в целевых областях.

Пример каркаса политики для принудительной установки расширения для защиты от вредоносных программ на ВМ Windows:

{
  "properties": {
    "displayName": "Deploy antimalware on Windows VMs",
    "policyType": "Custom",
    "mode": "Indexed",
    "parameters": {},
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
          { "field": "Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration", "exists": "true" }
        ]
      },
      "then": {
        "effect": "DeployIfNotExists",
        "details": {
          "type": "Microsoft.Compute/virtualMachines/extensions",
          "name": "IaaSAntimalware",
          "roleDefinitionIds": ["/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"],
          "deploymentScope": "resourceGroup",
          "existenceCondition": { "field": "name", "equals": "IaaSAntimalware" },
          "deployment": { "properties": { "mode": "incremental", "template": { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "resources": [] } } }
        }
      }
    }
  }
}

Управление в целевых зонах организует наследование и разделение обязанностей:

Группы управления: Постройте четкую иерархию (Корневая группа клиента → Платформа → Корпоративные/Онлайн-ресурсы → Среды, такие как Prod/NonProd). Назначайте инициативы и роли RBAC на уровнях групп управления, чтобы максимизировать наследование и минимизировать расхождения на уровне отдельных подписок. Обнаруживайте и подключайте привилегированные роли к PIM; для настройки PIM требуется роль Global Administrator.
Организация подписок: Разделяйте подписки по средам и критичности рабочих нагрузок, чтобы изолировать радиус поражения и бюджеты. Используйте архетипы (например, «Mission-Critical AKS», «Data Platform») с предварительно назначенными инициативами и ролями RBAC.
Теги: Стандартизируйте обязательные теги (Owner, CostCenter, DataSensitivity, Environment) и принудительно применяйте их с помощью эффектов Modify/Append для нормализации; запрещайте создание ресурсов в производственной среде при отсутствии обязательных тегов.
Блокировки ресурсов: Блокировка CanNotDelete защищает критически важные общие службы; ReadOnly предотвращает любые операции PUT. Используйте их экономно и только после отладки политик. Обратите внимание, что блокировка ReadOnly на виртуальной машине или ее группе ресурсов не позволяет запускать освобожденные ВМ и блокирует изменения конфигурации.

Для задач, ранее решавшихся с помощью Blueprints, используйте подход «политики как код» (policy-as-code) с помощью ARM/Bicep, Template Specs и назначений инициатив, чтобы достичь согласованных развертываний в масштабе, аналогичных Blueprints.

Инвентаризация безопасности, облачные приложения, управление данными и аудит

Инвентаризация и обеспечение соответствия в масштабе используют Azure Resource Graph (ARG) и отчеты о соответствии Policy. Запросы ARG предоставляют практически в реальном времени представления о состоянии миллионов ресурсов:

securityresources
| where type =~ 'microsoft.security/assessments'
| where properties.status.code == 'Unhealthy'
| summarize unhealthy=count() by tostring(properties.displayName)
| order by unhealthy desc

Объедините состояние ресурсов с тегами для сортировки по чувствительности данных:

resources
| where type == 'microsoft.compute/virtualmachines'
| project id, name, resourceGroup, subscriptionId, dataSensitivity = tostring(tags['DataSensitivity'])
| join kind=leftouter (
  securityresources
  | where type =~ 'microsoft.security/assessments'
  | where properties.status.code == 'Unhealthy'
  | summarize issues=count() by tolower(tostring(properties.resourceDetails.Id))
) on $left.id == $right['tolower_tostring_properties_resourceDetails_Id']
| project name, dataSensitivity, issues = coalesce(issues, 0)
| order by issues desc

Defender for Cloud Apps (MDCA) управляет рисками SaaS:

Обнаружение приложений: принимайте журналы брандмауэра/прокси через Cloud Discovery или интегрируйтесь с Defender for Endpoint для обнаружения на конечных точках. Классифицируйте приложения по оценке риска и использованию; отмечайте разрешенные/неразрешенные для применения условного доступа и блокировок прокси.
Управление сеансами: используйте Conditional Access App Control для проксирования сеансов при выполнении чувствительных действий. Применяйте политики в реальном времени для блокировки загрузок, мониторинга выгрузок, редактирования содержимого или нанесения водяных знаков для рискованных сеансов или неуправляемых устройств.
Действия по управлению: помещайте в карантин или помечайте файлы в Microsoft 365, отзывайте согласие для приложений OAuth, удаляйте внешний доступ, приостанавливайте рискованных пользователей и уведомляйте владельцев приложений. Автоматизируйте регулярное применение политик для предотвращения отклонений.

Microsoft Purview расширяет управление на данные:

Карта данных и сканирование: регистрируйте и сканируйте Azure Storage, SQL, Synapse и мультиоблачные хранилища для обнаружения активов и происхождения данных. Классифицируйте с помощью встроенных и пользовательских классификаторов.
Метки чувствительности и защита: применяйте метки с шифрованием и правами использования; автоматически присваивайте метки на основе содержимого и контекста. Применяйте доступ на основе меток в Microsoft 365 и интегрируйте с DLP для предотвращения утечки данных.
Согласование политик: сопоставляйте чувствительность Purview с тегами (например, DataSensitivity) и применяйте компенсирующие меры контроля через Azure Policy (например, требование Private Endpoints для хранилищ с меткой HighlyConfidential).

Журналы аудита должны быть защищены от несанкционированного доступа и полными:

Azure Activity Log: записывает операции уровня управления в области подписки. Направляйте в Log Analytics и архивируйте в Storage с помощью параметров диагностики. Храните долгосрочные копии вне подписки в центральной подписке «Security-Logs» для минимизации угрозы со стороны инсайдеров.
Параметры диагностики ресурсов: включите для критически важных поставщиков (Key Vault, Storage, SQL, AKS, Network Security Groups) для сбора журналов уровня данных и сервисных журналов. Направляйте в Log Analytics для обнаружения и в Storage для хранения.
Неизменяемое хранилище для журналов: используйте Blob Storage с хранением на основе времени или legal hold (WORM). Включите allowProtectedAppendWritesAll, чтобы диагностика могла продолжать добавлять данные при включенной неизменяемости. Настройте политики жизненного цикла для контроля затрат, но никогда не удаляйте данные в течение обязательного периода хранения. Это является основой для доказательств при аудите и расследовании инцидентов.

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

Contoso, глобальный ритейлер, подключает две новые производственные подписки и должна стандартизировать состояние безопасности, достичь соответствия Azure Security Benchmark и хранить неизменяемые журналы в течение семи лет, минимизируя операционные сложности.

Установить управление на уровне группы управления

Создайте группу управления Prod и поместите обе подписки под нее.
Обоснование: Наследование обеспечивает согласованность политик, планов Defender и RBAC без отклонений для каждой подписки и сокращает долг по конфигурации.

Назначить инициативы безопасности и планы Defender for Cloud

Назначьте инициативу Azure Security Benchmark с Deny для публичных IP-адресов для хранилищ и SQL; включите Defender for Servers Plan 2, Storage, SQL, Containers, Key Vault и DNS на уровне группы управления Prod.
Обоснование: Планы открывают доступ к расширенным возможностям обнаружения; инициатива кодирует меры контроля в виде защитных барьеров. Назначение на уровне группы управления гарантирует единообразное применение и последовательный расчет Secure Score.

Внедрить автоматизацию на основе политик и исключения

Добавьте политики DeployIfNotExists для автоматической установки MDE и агента Log Analytics там, где это необходимо; создайте задачи по исправлению для существующих ресурсов. Используйте исключения со сроком действия для устаревших ВМ, которые не могут быть немедленно подключены.
Обоснование: DeployIfNotExists превращает рекомендации в действия; ограниченные по времени исключения поддерживают динамику соответствия, не блокируя критически важные операции.

Настроить рабочий процесс исправления на основе Secure Score

Создайте рабочий процесс Logic App в Defender for Cloud для открытия тикетов P1 для любого действия по улучшению с влиянием на оценку >3%, которое становится неработоспособным в среде Prod, и автоматически уведомляйте владельцев ресурсов.
Обоснование: Влияние на оценку увязывает исправление с измеримым снижением риска, а автоматизация обеспечивает соблюдение SLO без ручной сортировки.

Централизовать журналы аудита с неизменяемостью

Из Azure Activity Log каждой подписки и от критически важных ресурсов (Key Vault, Storage, SQL, AKS) создайте параметры диагностики для отправки в центральное рабочее пространство Log Analytics и учетную запись Storage с политикой хранения на семь лет и включенным параметром allowProtectedAppendWritesAll.
Обоснование: Централизация упрощает обнаружение и соответствие требованиям; неизменяемое хранилище обеспечивает неотрекаемость, необходимую для аудитов и расследований.

Управлять использованием SaaS и риском исходящего трафика

Подключите Defender for Cloud Apps к Defender for Endpoint для обнаружения приложений; отметьте неразрешенные высокорискованные приложения и примените Conditional Access App Control для неуправляемых устройств, получающих доступ к разрешенным приложениям.
Обоснование: Снижает риск теневых ИТ и обеспечивает управление сеансами в реальном времени, не нарушая работу на управляемых устройствах.

Встроить управление данными с помощью Purview

Зарегистрируйте хранилища Storage и SQL Contoso в Purview, запустите сканирование и автоматически примените метки чувствительности. Сопоставьте метки с политикой тегов Environment и DataSensitivity, которая требует использования Private Endpoints для хранилищ с меткой HighlyConfidential.
Обоснование: Политики, учитывающие данные, обеспечивают автоматическое усиление сетевой безопасности там, где обнаружены чувствительные данные, замыкая цикл между управлением данными и безопасностью инфраструктуры.

← Управление ключами · Все домены · Microsoft Sentinel и операции по обеспечению безопасности →

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