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 в моделях IaaS и PaaS. Основное внимание уделяется тому, как настраивать средства защиты, почему они важны и как обеспечить их согласованное применение с помощью встроенных средств управления Azure.

Безопасность вычислительных ресурсов и конечных точек

Защита платформы виртуальных машин Azure и варианты шифрования являются основополагающими.

• Secure Boot, vTPM и Trusted Launch: Trusted Launch (доверенный запуск) усиливает защиту виртуальных машин 2-го поколения, включая безопасную загрузку UEFI (Secure Boot) и виртуальный доверенный платформенный модуль (vTPM). Secure Boot предотвращает запуск неподписанных загрузчиков/руткитов. vTPM предоставляет защищенное от несанкционированного доступа хранилище для ключей (например, для BitLocker) и поддерживает измеряемую загрузку (measured boot), чтобы платформа могла аттестовать цепочку загрузки ОС. На практике следует включать доверенный запуск при развертывании и применять его с помощью политик, чтобы все новые ВМ получали проверки целостности на аппаратном уровне без необходимости для администраторов вручную настраивать статические параметры BIOS/UEFI.

• Конфиденциальные ВМ: Используйте серии конфиденциальных ВМ на базе AMD SEV-SNP или Intel TDX (например, DCasv5/DCadsv5) для шифрования памяти ВМ и обеспечения аттестации. Это защищает рабочие нагрузки от вредоносного хоста/гипервизора и атак по сторонним каналам. На практике выбирайте конфиденциальные SKU для сценариев с особо чувствительными данными в оперативной памяти, интегрируйте аттестацию в свой конвейер развертывания и отдавайте предпочтение эфемерным дискам ОС, когда требуется быстрое повторное развертывание без сохранения данных.

• Варианты шифрования дисков:

  • Azure Disk Encryption (ADE): BitLocker (Windows) или DM-Crypt (Linux) внутри гостевой ОС, ключи в Key Vault (BEK/KEK). Полезно, когда вам нужны криптографические домены на уровне гостевой ОС, проверки соответствия требованиям внутри ОС или использование BitLocker, привязанного к vTPM. Требует наличия агента и операций по поддержанию работоспособности расширения.
  • Шифрование на стороне сервера (SSE) с помощью ключей, управляемых клиентом (CMK): Шифрование на уровне хранилища для управляемых дисков с использованием ключей в Key Vault или Managed HSM. Не требует агентов в гостевой ОС, обеспечивает полное покрытие платформы (диски, моментальные снимки, образы) и минимальные операционные издержки. Рекомендуется по умолчанию для большинства сценариев; используйте в паре с Trusted Launch или Confidential VMs для более надежной многоуровневой защиты.

• Microsoft Defender for Servers:

  • План 1: Microsoft Defender for Endpoint (MDE) для EDR/защиты конечных точек на серверах. Выбирайте этот план, если у вас уже есть зрелые инструменты для управления уязвимостями и конфигурациями, и вам в первую очередь нужен EDR.
  • План 2: Добавляет оценку уязвимостей на основе агентов или без них, JIT-доступ (Just-in-Time) к ВМ, адаптивное управление приложениями, адаптивное усиление защиты сети и мониторинг целостности файлов (FIM). Выбирайте этот план, если вы хотите уменьшить поверхность атаки средствами платформы и применять политики управления на практике без необходимости интеграции нескольких инструментов.
  • Защита конечных точек: Развертывайте MDE через расширения ВМ или Arc для серверов за пределами Azure, чтобы стандартизировать телеметрию, защиту от несанкционированного доступа и сценарии реагирования в гибридных средах.
  • Оценка уязвимостей: Используйте сигнал от модуля Threat & Vulnerability Management в MDE или интегрированный сканер (например, Qualys) для инвентаризации CVE, приоритизации по возможности эксплуатации и организации установки исправлений. На практике сначала проведите базовую оценку критически важных серверов, доступных из интернета; привяжите устранение уязвимостей к окнам обслуживания.
  • Мониторинг целостности файлов: Отслеживайте изменения в важных файлах/ключах реестра для обнаружения подозрительных несанкционированных изменений и соответствия требованиям комплаенса. Настройте отслеживание для конкретных путей, чтобы избежать излишнего шума, и перенаправляйте оповещения в вашу SIEM-систему.

• Уменьшение поверхности атаки с помощью Defender for Cloud:

  • JIT-доступ к ВМ: Закрывает входящие порты RDP/SSH. Администраторы запрашивают доступ на ограниченное время; Defender открывает правило в NSG или Azure Firewall и регистрирует активность. Результатом является значительно уменьшенная поверхность атаки с аудируемыми исключениями.
  • Адаптивное управление приложениями: Изучает нормальные процессы и создает списки разрешенных приложений (AppLocker в Windows, правила аудита для Linux). Это блокирует неутвержденные двоичные файлы и скрипты, что особенно эффективно против бесфайловых атак или атак типа LOLBin.
  • Адаптивное усиление защиты сети: Использует аналитику трафика и данные об угрозах, чтобы предлагать ужесточение правил NSG. Внедрите регулярный процесс проверки и применения, чтобы итеративно ограничивать поверхность атаки, избегая сбоев в работе.
  • Конфигурация гостевой ОС: Azure Policy для аудита/исправления внутри гостевой ОС (Windows и Linux) через агент или Azure Arc. Используйте эту функцию для принудительного применения базовых конфигураций ОС, политик паролей и настроек, соответствующих стандартам CIS, когда вам нужно доказуемое состояние конфигурации, а не просто общая оценка состояния платформы.

PaaS-вычисления: App Service и Functions

Шаблоны безопасной конфигурации по умолчанию уменьшают поверхность атаки на PaaS.

• Azure App Service:

  • Аутентификация/Авторизация: Включите App Service Authentication, чтобы переложить аутентификацию на Microsoft Entra ID или других провайдеров. Используйте Easy Auth для стандартных потоков OIDC/OAuth2, а затем принудительно требуйте вход на всех маршрутах, чтобы исключить доступ без аутентификации.
  • Ограничения доступа: Разрешайте или запрещайте трафик по IP/CIDR, тегам служб или трафику из виртуальной сети через частные конечные точки (private endpoints). Поддерживайте раздельные правила для конечной точки scm и конечной точки приложения, чтобы независимо защищать плоскость развертывания.
  • Частные конечные точки (Private Endpoints): Предоставляйте доступ к приложению по частному IP-адресу в вашей VNet и при необходимости отключайте публичный доступ. Используйте частные зоны DNS и ограничивайте исходящие зависимости с помощью VNet Integration и централизованного брандмауэра для исходящего трафика.
  • Управляемые удостоверения (Managed Identities): Предпочитайте назначаемые системой или пользователем удостоверения для доступа к Key Vault, Storage и другим службам. Это избавляет от встроенных секретов и позволяет централизованно назначать роли и ротировать ключи.

• Azure Functions:

  • Управление ключами: Functions используют ключи функций, ключи хоста и главный ключ. Регулярно ротируйте ключи и храните внешне используемые ключи в Key Vault или, если возможно, замените ключи на полноценные потоки OAuth.
  • Сетевая интеграция: Используйте частные конечные точки для входящего доступа к приложению-функции и региональную VNet Integration для контроля исходящего трафика. Ограничьте доступ к учетной записи Storage, используемой Functions, только выбранными сетями и добавьте частную конечную точку функции в список разрешенных сетей.
  • Удостоверения: Используйте управляемые удостоверения для аутентификации между службами вместо ключей или строк подключения. Реализуйте принцип наименьших привилегий с помощью назначений RBAC с узкой областью действия.
  • Контроль развертывания: Принудительно используйте только FTPS, отключите базовую аутентификацию для сайта scm, ограничьте IP-адреса для scm и используйте Run From Package для обеспечения неизменяемых развертываний. Интегрируйте CI/CD с федерацией удостоверений рабочей нагрузки (workload identity federation), чтобы избавиться от долгоживущих секретов.

Безопасность Kubernetes и контейнеров

Усиливайте защиту кластеров и цепочек поставок на всех этапах.

• Идентификация и авторизация в AKS:

  • Интеграция с Microsoft Entra: Включите управляемую интеграцию с AAD для AKS, чтобы аутентифицировать kubectl с помощью токенов и групп Entra. Это централизует жизненный цикл пользователей и применение MFA/Conditional Access.
  • Kubernetes RBAC: Сопоставляйте пользователей/группы Entra с ролями и привязками ролей Kubernetes для реализации принципа наименьших привилегий на уровне пространств имен.
  • Azure RBAC для Kubernetes: Используйте встроенные роли (например, Azure Kubernetes Service RBAC Viewer/Admin), когда вы хотите, чтобы Azure RBAC напрямую авторизовал действия с API Kubernetes. Это унифицирует авторизацию и аудит с плоскостью управления Azure.

• Сеть и конфиденциальность в AKS:

  • Сетевые политики: Управляйте трафиком между подами и между подами и службами с помощью Azure NPM или Calico. Используйте политику запрета по умолчанию и явно разрешайте необходимый исходящий трафик; подход «политика как код» предотвращает боковое перемещение (lateral movement).
  • Частные кластеры: Сделайте API-сервер частным, доступным только через частные конечные точки. Используйте это в паре с Azure Bastion/Private Link и стратегией для исходящего трафика через брандмауэр (NAT Gateway + UDR), чтобы изолировать плоскость управления от интернета.

• Безопасность Container Registry (ACR):

  • RBAC: Назначайте роль AcrPull рабочим нагрузкам, которым нужно только скачивать образы, и AcrPush — конвейерам сборки; избегайте избыточной роли Owner. Роли AcrPull и AcrPush соответствуют принципу наименьших привилегий.
  • Доверие к содержимому и подписание: Подписывайте образы с помощью cosign и принудительно проверяйте подпись через контроллер допуска (admission control) (Gatekeeper + Ratify) перед запуском подов. Это защищает от подмены образов.
  • Сканирование образов: Включите Microsoft Defender for Cloud для сканирования ACR при отправке/импорте и по расписанию. Блокируйте развертывание образов с критическими неустраненными CVE с помощью политик допуска.
  • Паттерн карантина: Направляйте новые образы в карантинный репозиторий или тег, запускайте сканирование и проверки политик, а затем «продвигайте» образ, изменяя его тег после одобрения.
  • Частный доступ: Отключите публичный доступ к сети и используйте частные конечные точки и правила брандмауэра для реестра. Привязывайте AKS к ACR, используя назначение роли на уровне ресурса, а не роль каталога.

Краткий пример привязки ACR к AKS с использованием управляемого удостоверения кластера:

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

• Microsoft Defender for Containers: Развертывает сенсор на плоскости данных в AKS, отслеживает журналы аудита Kubernetes и сигналы времени выполнения, а также сопоставляет их с результатами сканирования образов. Он обнаруживает подозрительные exec в подах, криптомайнинг, открытые панели мониторинга и рискованные операции на плоскости управления. Включите автоматическую подготовку и подключите оповещения к вашей системе SIEM/SOAR для анализа и реагирования.

Управление, политики и принудительное применение

Для последовательного контроля необходимы политики на этапе развертывания и во время выполнения.

• Azure Policy для вычислительных ресурсов и дисков:
  • Запрещать создание ВМ без доверенного запуска или без SSE с CMK.
  • Принудительно устанавливать расширения ВМ для защиты конечных точек с помощью DeployIfNotExists для автоматической установки необходимых агентов.
  • Проводить аудит соответствия гостевой конфигурации; устранять отклонения по расписанию.

Краткий фрагмент политики для развертывания необходимого расширения ВМ, если оно отсутствует:

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

• Контроллеры допуска Kubernetes:
  • Надстройка Azure Policy для AKS использует Gatekeeper (OPA) для оценки спецификаций подов при их допуске. Применяйте правила, такие как «загружать образы только из ACR», «запретить привилегированные контейнеры» и «требовать подписи образов».
  • Поддерживайте отдельные инициативы для базового (обязательного) и усиленного (для чувствительных пространств имен) уровней, чтобы обеспечить постепенное повышение безопасности.

Краткое ограничение Gatekeeper для указания разрешенных реестров:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

• Операционный ритм:
  • Обнаружение: Используйте рекомендации Defender for Cloud и оповещения о рабочих нагрузках в качестве сигналов об отклонениях и угрозах.
  • Принятие решений: Сортируйте по влиянию на бизнес и возможности эксплуатации уязвимости; назначайте владельцев с помощью тегов.
  • Принуждение: Преобразуйте успешные пилотные проекты в запрещающие политики/ограничения допуска; измеряйте количество заблокированных попыток для выявления теневых ИТ.

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

Компания Adobe Inc. переносит микросервис для обработки платежей в Azure. Требования безопасности предписывают полное отсутствие публичного доступа, использование только подписанных образов и ограниченный по времени административный доступ к устаревшим ВМ на время перехода.

1. Сделать плоскость управления AKS приватной и заблокировать исходящий трафик.

• Обоснование: Приватный API-сервер AKS убирает плоскость управления из интернета. NAT Gateway в сочетании с Azure Firewall и явными правилами для исходящего трафика гарантирует, что рабочие нагрузки могут обращаться только к одобренным конечным точкам (ACR, Key Vault, репозитории пакетов Microsoft).

2. Принудительно использовать подписанные образы и ограничить реестры.

• Обоснование: Настройте Gatekeeper с ограничениями, которые разрешают образы только из myacr.azurecr.io и требуют наличия подписей cosign, проверяемых с помощью Ratify. Это предотвращает запуск измененных или недоверенных образов, устраняя серьезный риск в цепочке поставок.

3. Защитить ACR с помощью приватных конечных точек и ролей с минимальными привилегиями.

• Обоснование: Отключите публичный доступ к сети и предоставьте доступ к ACR через приватную конечную точку в виртуальной сети AKS. Предоставьте управляемому удостоверению AKS только роль AcrPull, а конвейеру сборки — AcrPush. Это соответствует принципу наименьших привилегий и устраняет зависимость от интернета.

4. Включить Defender for Containers и сканирование образов в ACR.

• Обоснование: Непрерывное сканирование образов при отправке в реестр и обнаружение угроз во время выполнения обеспечивают многоуровневую защиту. Оповещения объединяют информацию о неверных конфигурациях, известных уязвимостях и подозрительных действиях для быстрого реагирования.

5. Защитить инструменты администрирования на базе App Service с помощью аутентификации и приватного доступа.

• Обоснование: Используйте аутентификацию App Service с Microsoft Entra ID, чтобы требовать MFA и применять политики условного доступа. Создайте приватную конечную точку для приложения администрирования и отдельно ограничьте доступ к scm. Управляемые удостоверения избавляют от необходимости хранить секреты для доступа к Key Vault.

6. Использовать JIT-доступ к ВМ для устаревших хостов на время перехода.

• Обоснование: JIT-доступ по умолчанию закрывает порты RDP/SSH и открывает их только по одобренным запросам на ограниченное время. Это строго ограничивает окна уязвимости, сохраняя при этом возможность экстренного доступа.

7. Стандартизировать выбор методов шифрования: SSE с CMK для дисков; Trusted Launch для ВМ.

• Обоснование: SSE с CMK минимизирует операционную нагрузку и централизует жизненный цикл ключей в Key Vault, в то время как Trusted Launch/vTPM добавляет целостность загрузки и защиту ключей. ADE используется только в тех случаях, когда по контракту требуется подтверждение криптографического домена на уровне гостевой ОС.

8. Применять Azure Policy и контроль допуска в качестве защитных барьеров.

• Обоснование: Инициативы Azure Policy обеспечивают принудительное использование доверенного запуска, обязательных расширений ВМ и запрещают публичный доступ к ACR/Function. Ограничения Gatekeeper реализуют проверки допуска для AKS во время выполнения. Вместе они гарантируют, что конфигурации остаются соответствующими требованиям по мере итераций команд.

9. Проверять и работать в режиме непрерывного управления.

• Обоснование: Интегрируйте оповещения Defender for Cloud и MDE в SIEM-систему Adobe, измеряйте эффект от политик (запрет в сравнении с аудитом) и ежемесячно пересматривайте исключения. Это превращает разовые меры контроля в долгосрочную операционную модель безопасности.

← Архитектура сетевой безопасности · Все домены · Безопасность данных →

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

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