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

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Управление (Governance) в Azure приводит использование облака в соответствие с бизнес-требованиями, требованиями безопасности и нормативными актами с помощью многоуровневого набора средств контроля: организационная структура, политики, стандартизированные развертывания, защита от случайных изменений и непрерывный аудит. Эти возможности работают нативно на уровне управления Azure Resource Manager и масштабируются от одной подписки до крупных многоклиентских сред. Качественное управление сокращает дрейф конфигурации, обеспечивает согласованность и предоставляет доказательства соответствия, не замедляя работу разработчиков. Соответствие требованиям зависит от точной инвентаризации и истории изменений. Azure обеспечивает видимость ресурсов по всем подпискам практически в реальном времени, предписывающие сопоставления с нормативными требованиями и обнаружение данных для поиска и классификации конфиденциальной информации. В результате создается защищенная облачная среда, где стандарты определяются один раз, применяются автоматически, их соблюдение постоянно подтверждается, а отклонения исправляются в любом масштабе.

Azure Policy: определения, инициативы, контроль расположения и исправление

Azure Policy определяет защитные механизмы (guardrails), которые оценивают конфигурации ресурсов во время их создания/обновления (и регулярно после этого) и обеспечивают соблюдение желаемых состояний. Определение политики использует условия и эффекты для оценки свойств ресурсов, предоставляемых поставщиками ресурсов. Основные эффекты включают Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists и Disabled. Политики можно назначать на уровне группы управления, подписки, группы ресурсов или отдельного ресурса, а наследование гарантирует, что более широкие назначения распространяются вниз по иерархии, если они не исключены с помощью notScopes. Инициативы группируют связанные определения политик в единый пакет с параметрами для согласованного и повторяемого назначения. Например, инициатива по базовой безопасности может включать политики, требующие настройки диагностики, ограничивающие публичные конечные точки, принудительно применяющие теги и проверяющие отсутствие резервных копий. Назначение инициативы применяет все включенные в нее политики одним действием и предоставляет единое представление о соответствии требованиям. Встроенные политики “Разрешенные расположения” (Allowed locations) ограничивают регионы, в которых можно создавать группы ресурсов и ресурсы, предотвращая развертывание в неразрешенных регионах и помогая соблюдать требования к резидентности и суверенитету данных. Когда запрос на создание нацелен на запрещенный регион, эффект Deny блокирует операцию до того, как она достигнет поставщика ресурсов, обеспечивая строгое соблюдение. При обнаружении дрейфа конфигурации задачи исправления (remediation) возвращают ресурсы в состояние соответствия в любом масштабе. Для политик DeployIfNotExists и Modify управляемое удостоверение назначения политики используется для перенастройки несоответствующих ресурсов (например, для включения настроек диагностики в учетных записях хранения или добавления обязательных тегов). Задания по исправлению могут иметь узкую область действия или выполняться для целых подписок, а результаты соответствия отображаются для каждой политики и каждого ресурса для аудита.

• Назначение
  • Определение политики: Одно правило, оценивающее свойства ресурса
  • Инициатива (набор политик): Пакет определений политик с общими параметрами
  • Область назначения: Группа управления, подписка, группа ресурсов или ресурс
  • Распространенные эффекты: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists
  • Требования к исправлению: Управляемое удостоверение в назначении; применимо к Modify/DeployIfNotExists
• Пример использования
  • Определение политики: Принудительное использование SKU, TLS, тегов, приватных конечных точек
  • Инициатива (набор политик): Применение базовых стандартов безопасности или управления
  • Область назначения: Широкое применение с наследованием и исключениями
  • Распространенные эффекты: Жесткое принуждение или аудит только для сбора данных
  • Требования к исправлению: Разрешения, достаточные для изменения целевых ресурсов

Azure Blueprints: упаковка стандартов с помощью политик, RBAC, групп ресурсов и шаблонов

Azure Blueprints упаковывают артефакты управления, чтобы организации могли последовательно создавать («штамповать») соответствующие требованиям среды. Определение «схемы» (blueprint) может включать назначения политик, назначения управления доступом на основе ролей Azure (RBAC), определения групп ресурсов и артефакты развертывания, такие как шаблоны ARM (включая Bicep), для предоставления стандартной инфраструктуры. Параметры позволяют настраивать каждое назначение, сохраняя при этом единый версионированный источник истины. Blueprints помогают отделить «что должно существовать и кто что может делать» от кода рабочей нагрузки. Например, базовая «схема» может создавать периферийные (spoke) группы ресурсов, назначать роль Reader командам аудита и Contributor командам платформы, развертывать сетевой шаблон «звезда» (hub-and-spoke) и назначать инициативы для диагностики и безопасности. Назначение «схемы» одной или нескольким подпискам применяет все артефакты в правильном порядке и записывает состояние соответствия. Версионирование поддерживает контролируемые обновления, а блокировка артефактов может защитить критически важные компоненты после развертывания.

• Основной фокус
  • Azure Policy: Защитные механизмы для конфигурации и соответствия требованиям
  • Шаблоны ARM/Bicep: Декларативное развертывание ресурсов
  • Azure Blueprints: Упаковка и управление стандартами в разных подписках
• Включает RBAC
  • Azure Policy: Нет (отдельное назначение)
  • Шаблоны ARM/Bicep: Нет (отдельное назначение)
  • Azure Blueprints: Да (назначения ролей как артефакты)
• Включает политики
  • Azure Policy: Н/П (неприменимо)
  • Шаблоны ARM/Bicep: Нет (могут развертывать ресурсы политик, но не назначать их)
  • Azure Blueprints: Да (назначения политик как артефакты)
• Создает группы ресурсов
  • Azure Policy: Может требовать/принудительно применять именование/теги
  • Шаблоны ARM/Bicep: Могут развертывать в группы или создавать их через вложенные развертывания
  • Azure Blueprints: Да (определяет артефакты RG как часть «схемы»)
• Типичное использование
  • Azure Policy: Ограничение SKU, принудительное применение диагностики, тегов
  • Шаблоны ARM/Bicep: Предоставление VNet, Key Vault, App Services
  • Azure Blueprints: Создание («штамповка») соответствующих требованиям целевых зон (landing zones) с политиками + RBAC + инфраструктурой

Организация и стандарты: группы управления, подписки, группы ресурсов, именование и теги

Иерархия управления Azure позволяет масштабировать управление. Группы управления находятся над подписками и служат для применения политик и RBAC, которые наследуются всеми дочерними подписками. Подписки определяют биллинг, квоты на службы и границу безопасности для большинства элементов управления. Группы ресурсов содержат ресурсы с общим жизненным циклом, разрешениями и логикой развертывания; каждый ресурс принадлежит ровно одной группе ресурсов и одной подписке. Стандарты именования и тегирования преобразуют цели управления в операционную ясность. Имена должны кодировать сокращения типов ресурсов, рабочую нагрузку, среду и регион (например, kv-payroll-prod-eus2) в пределах ограничений службы. Теги добавляют бизнес-контекст к ресурсам для распределения затрат, определения владельца, классификации данных и ключей автоматизации (например, costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential). Azure Policy с эффектами Modify и Append обеспечивает наличие тегов и соответствие их значений шаблонам, а также может наследовать теги от групп ресурсов к ресурсам. Последовательность в этом вопросе обеспечивает надежную отчетность по затратам, проверку доступа и автоматизацию жизненного цикла.

• Группа управления (Management Group)
  • Назначение: Управление в масштабе нескольких подписок
  • Частые сценарии использования: Применение политик, RBAC и инициатив к бизнес-подразделениям или средам
  • Может содержать: Дочерние группы управления и подписки
  • Ключевые моменты: До 6 уровней вложенности (не считая корневой); наследование происходит сверху вниз
• Подписка (Subscription)
  • Назначение: Граница для биллинга и служб
  • Частые сценарии использования: Изоляция рабочих нагрузок, разделение затрат, управление квотами
  • Может содержать: Группы ресурсов и ресурсы
  • Ключевые моменты: Назначения политик/RBAC на этом уровне влияют на все вложенные группы ресурсов
• Группа ресурсов (Resource Group)
  • Назначение: Граница жизненного цикла и разрешений для ресурсов
  • Частые сценарии использования: Совместное развертывание, обновление и удаление связанных ресурсов
  • Может содержать: Ресурсы
  • Ключевые моменты: Ресурс может существовать только в одной группе ресурсов; перемещение между группами ресурсов/подписками имеет ограничения, специфичные для каждой службы

Блокировки ресурсов и предотвращение случайного удаления

Блокировки ресурсов служат последним рубежом защиты от непреднамеренных изменений. Блокировки применяются на уровне подписки, группы ресурсов или отдельного ресурса и наследуются вниз по иерархии. Существует два типа блокировок: CanNotDelete предотвращает удаление, но разрешает операции чтения и записи, а ReadOnly запрещает все операции записи и удаления (фактически разрешая только чтение). Блокировки защищают от действий, выполняемых через портал, CLI, PowerShell, ARM/Bicep и сторонние инструменты IaC. Используйте CanNotDelete для общей или критически важной инфраструктуры — виртуальных сетей, таблиц маршрутизации, зон DNS, производственных Key Vaults — чтобы обслуживание могло продолжаться, пока удаление заблокировано. Используйте ReadOnly с осторожностью для артефактов, которые должны оставаться полностью статичными, например, для архивных учетных записей хранения или контейнеров с нормативными данными; многие службы требуют прав на запись для нормальной работы и будут давать сбой при блокировке ReadOnly. Только субъекты с достаточными разрешениями (например, Owner с правами Microsoft.Authorization/locks/*) могут снять блокировку, и само снятие блокировки является операцией, которая отслеживается в Activity Log.

• CanNotDelete
  • Чтение: Разрешено
  • Запись/Обновления: Разрешены
  • Удаление: Заблокировано
  • Типичные сценарии использования: Защита VNets, таблиц маршрутизации, производственных Key Vaults, критически важных групп ресурсов
  • Особенности: Разрешает изменения конфигурации; операции удаления завершаются ошибкой до снятия блокировки
• ReadOnly
  • Чтение: Разрешено
  • Запись/Обновления: Заблокированы
  • Удаление: Заблокировано
  • Типичные сценарии использования: Сохранение хранилищ доказательств, архивного хранилища, неизменяемых конфигураций
  • Особенности: Многие службы перестают работать с блокировкой ReadOnly; обновления и масштабирование блокируются

Аудит, инвентаризация и соответствие нормативным требованиям: Resource Graph, Activity Log, Defender for Cloud и Microsoft Purview

Azure Resource Graph обеспечивает быстрые и масштабируемые запросы для инвентаризации и оценки состояния ресурсов в подписках и группах управления с использованием Kusto Query Language (KQL). Он позволяет получать ответы на такие вопросы, как: у каких учетных записей хранения отсутствует шифрование, какие виртуальные сети (VNets) предоставляют доступ к публичным IP-адресам и какие ресурсы не соответствуют политикам. Результаты используются для заполнения панелей мониторинга, синхронизации с CMDB и в конвейерах для устранения несоответствий. В сочетании с данными Cost Management, Resource Graph также может отображать состояния соответствия политикам, распределение тегов и параметры для атрибуции затрат. Azure Activity Log записывает операции на уровне управления (control-plane) с ресурсами, включая информацию о том, кто, что и когда сделал, со сроком хранения по умолчанию 90 дней. Перенаправляйте Activity Log в Log Analytics, Azure Storage или Event Hubs для долгосрочного хранения, корреляции событий и передачи в SIEM-системы. Анализ истории изменений позволяет точно выявлять дрейф конфигурации, помогает в реагировании на инциденты и предоставляет доказательства для аудитов. Microsoft Defender for Cloud преобразует техническую оценку состояния безопасности в отчеты о соответствии нормативным требованиям, сопоставляя оценки с такими стандартами, как Azure Security Benchmark, ISO/IEC 27001, NIST SP 800-53, PCI DSS и CIS. Панель мониторинга соответствия нормативным требованиям (Regulatory compliance) отображает пройденные и непройденные проверки, затронутые ресурсы и рекомендации по устранению проблем. Включение автоматической подготовки (auto-provisioning) интегрирует агенты и политики там, где это необходимо, а показатель безопасности (secure score) помогает приоритизировать задачи. Microsoft Purview обнаруживает, классифицирует и каталогизирует данные в Azure, мультиоблачных средах и локальных источниках. Процессы сканирования выявляют конфиденциальные данные (например, финансовые, персональные (PII), медицинские) в Azure Storage, SQL, Synapse, Power BI и многих других сервисах, применяя встроенные или пользовательские классификаторы. Purview Data Map и Catalog предоставляют информацию о происхождении данных (lineage), их владельцах и метках конфиденциальности, которые интегрируются с Microsoft Information Protection, обеспечивая предотвращение потери данных (DLP) и принятие решений о политиках доступа в соответствии с нормативными обязательствами.

• Основная функция
  • Azure Resource Graph: Масштабируемая инвентаризация и запросы о состоянии ресурсов
  • Activity Log: Журнал аудита операций на уровне управления
  • Defender for Cloud (Regulatory): Сопоставление состояния безопасности со стандартами и приоритизация исправлений
  • Microsoft Purview: Обнаружение, классификация, каталогизация и отслеживание происхождения данных
• Область действия
  • Azure Resource Graph: В пределах групп управления/подписок
  • Activity Log: На уровне тенанта с маршрутизацией в LA/Storage/Event Hub
  • Defender for Cloud (Regulatory): На уровне подписки/тенанта с назначением инициатив
  • Microsoft Purview: Охватывает источники данных (Azure, M365, локальные, мультиоблачные)
• Типичные выходные данные
  • Azure Resource Graph: Результаты KQL-запросов, панели мониторинга, экспорт данных
  • Activity Log: Кто/что/когда, статус, коды ошибок
  • Defender for Cloud (Regulatory): Статус соответствия, показатель безопасности, рекомендации
  • Microsoft Purview: Ресурсы данных, метки конфиденциальности, схемы, графы происхождения данных

Практическая задача: Стандартизация совместимых целевых зон в Fabrikam Retail Group

Сценарий: Fabrikam Retail Group работает в Северной Америке и ЕС со строгими требованиями к резидентности данных и обязательствами по PCI DSS. Множество команд разработчиков ежемесячно развертывают рабочие нагрузки, и предыдущие нерегламентированные развертывания привели к непоследовательному применению тегов, размещению ресурсов в неутвержденных регионах и случайному удалению общих сетевых ресурсов. Руководство требует стандартизированных, совместимых целевых зон, непрерывного подтверждения эффективности средств контроля и обнаружения конфиденциальных данных в хранилищах и аналитических платформах.

Задача: Спроектировать и внедрить подход к управлению в Azure, который принудительно применяет ограничения по регионам, стандартизирует развертывания с помощью политик и RBAC, предотвращает случайное удаление основной инфраструктуры, ведет инвентаризацию и историю изменений, формирует отчеты на соответствие ISO 27001 и PCI DSS, а также обнаруживает и классифицирует конфиденциальные данные.

Рекомендуемый подход:

1. Создать иерархию групп управления: корневая /Fabrikam; дочерние /Corp (общие службы), /NA и /EU; под каждой из них добавить /Prod и /NonProd. Переместить подписки в соответствующие группы управления.
2. Разработать инициативы политик на уровне групп управления: (a) Разрешенные расположения для каждой географии, (b) Обязательные теги (costCenter, owner, dataSensitivity) с действиями Modify/Append, (c) Принудительное включение параметров диагностики для отправки в Log Analytics для основных служб, (d) Ограничения на SKU и доступ к публичным сетям для служб PaaS. Назначить инициативы группам /NA и /EU с параметрами, соответствующими региону, и исключить подписки для экстренного доступа через notScopes.
3. Упаковать проект (blueprint) для стандартной целевой зоны: артефакты включают создание групп ресурсов для центральной инфраструктуры (hub) и приложений, назначения RBAC (Network Contributor для команды платформы, Reader для аудита), назначения политик для диагностики и тегов, а также шаблоны ARM для развертывания vNET, пиринга, Key Vault и Log Analytics. Установить версию проекта и назначить его всем подпискам Prod и NonProd.
4. Применить блокировки ресурсов: CanNotDelete на центральные VNet, таблицы маршрутизации, общие зоны DNS и рабочие области Log Analytics; ReadOnly на архивную учетную запись хранения для экспорта данных в целях соответствия нормативным требованиям. Убедиться, что владельцы подписок с общими службами могут снимать блокировки после утверждения, когда планируются изменения.
5. Включить экспорт Журнала действий (Activity Log) из всех подписок в центральную рабочую область Log Analytics и архивировать в учетную запись хранения с неизменяемым (основанным на времени) хранением в течение семи лет. Создать дашборды в Resource Graph, которые отображают несоответствующие ресурсы, отсутствующие теги и активы по регионам и тегу dataSensitivity.
6. Включить Microsoft Defender for Cloud для всего тенанта. Выбрать ISO/IEC 27001 и PCI DSS в качестве стандартов соответствия, включить автоматическую подготовку и проанализировать рекомендации. Создать рабочие элементы на основе высокоприоритетных находок и отслеживать улучшение показателя безопасности (secure score) для каждой подписки.
7. Развернуть Microsoft Purview в подписке с общими службами /Corp. Зарегистрировать Azure SQL, Storage, Synapse и Power BI в качестве источников данных. Настроить плановое сканирование со встроенными типами конфиденциальной информации и классифицировать наборы данных. Опубликовать каталог данных и назначить владельцев данных. Экспортировать обнаруженные метки конфиденциальности для использования в политиках условного доступа и DLP.

Обоснование выбора Azure: Этот подход начинается с определения области действия на уровне групп управления, чтобы политики и RBAC наследовались предсказуемым образом, а затем применяет основные средства контроля с помощью Azure Policy и инициатив для предотвращения несоответствий на этапе развертывания. Проект (blueprint) объединяет политики, RBAC, группы ресурсов и шаблоны инфраструктуры, чтобы создавать единообразные целевые зоны, допуская при этом параметризацию по регионам и средам. Блокировки ресурсов защищают критически важные общие службы от случайного удаления, не препятствуя при этом повседневной настройке, где это необходимо. Централизованное хранение Журнала действий и Resource Graph обеспечивают надежную инвентаризацию и подтверждение изменений. Defender for Cloud предоставляет актуальную карту соответствия нормативным требованиям и приоритизированное устранение проблем, в то время как Microsoft Purview обнаруживает и классифицирует конфиденциальные данные для поддержки PCI DSS и контроля резидентности данных в аналитическом ландшафте Fabrikam.

← Управление затратами и экономика служб · Все домены · Мониторинг →

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

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