Microsoft AZ-500: Безопасность приложений и DevSecOps — Руководство по подготовке

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

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

Обзор

Безопасность приложений и DevSecOps в Azure сосредоточены на предотвращении неправомерного использования удостоверений, защите входящего трафика и API, сдвиге безопасности «влево» в конвейерах, обеспечении безопасности секретов при хранении и передаче, а также на внедрении надежного управления выпусками. Эффективные архитектуры исключают использование долгоживущих секретов, применяют принцип наименьших привилегий, проверяют каждого вызывающего и внедряют непрерывное обнаружение и устранение уязвимостей в коде, зависимостях, инфраструктуре и среде выполнения.

Безопасность удостоверений приложений, входящего трафика и защита API

Безопасность удостоверений приложений в Microsoft Entra ID (Azure AD) начинается с правильно настроенной регистрации приложения и выбора корректного потока OAuth 2.0:

Делегированные разрешения применяются, когда пользователь вошел в систему, а согласие может быть ограничено только приложениями от проверенных издателей или областями, одобренными администратором. Разрешения приложения (только для приложений) всегда требуют согласия администратора, поскольку они авторизуют фоновые службы или процессы, работающие без участия пользователя.
Применяйте принцип наименьших привилегий, предоставляя только минимально необходимые области или роли приложения и требуя проверки запросов на согласие администратором. Отключите согласие конечных пользователей или разрешите его только для проверенных издателей с низким уровнем риска, чтобы снизить вероятность фишинга с использованием согласий.
Отдавайте предпочтение учетным данным на основе сертификатов или федеративным удостоверениям вместо секретов клиента. Сертификаты обеспечивают более высокий уровень гарантий и предсказуемую ротацию. Настраивайте короткие сроки действия и автоматизируйте ротацию. Блокируйте потоки общедоступных клиентов, если они не требуются.
Для служб Azure используйте управляемые удостоверения вместо секретов приложений. Назначайте роли плоскости данных, такие как Key Vault Secrets User или Storage Blob Data Reader, и при необходимости ограничивайте сетевой доступ с помощью частных конечных точек (Private Endpoints).

Application Gateway WAF v2 и Azure Front Door WAF защищают общедоступный входящий трафик от угроз из списка OWASP Top 10:

Включите последнюю версию управляемого Microsoft набора основных правил OWASP и после настройки запустите его в режиме предотвращения (Prevention). На начальном этапе используйте оценку аномалий, чтобы уменьшить количество ложных срабатываний во время обучения.
Настройте пользовательские правила для геозонирования, блокировки по репутации IP, принудительной проверки заголовков и ограничения размера запросов. Для Front Door добавьте правила ограничения частоты запросов для каждого IP-адреса клиента, чтобы противостоять атакам подстановки учетных данных (credential stuffing) и базовым DoS-атакам уровня 7 (L7).
Терминируйте TLS с использованием надежных наборов шифров и политик; используйте сквозное шифрование TLS до источника. Для сценариев, требующих mTLS, настройте проверку клиентского сертификата на прослушивателях Application Gateway.
Точно привязывайте политики WAF к прослушивателям/маршрутам; используйте исключения из правил только тогда, когда вы полностью понимаете причину ложного срабатывания. Направляйте журналы WAF в Log Analytics для инженерии обнаружения угроз и реагирования на инциденты.

API Management (APIM) обеспечивает многоуровневую систему безопасности:

Проверяйте токены OAuth на шлюзе со строгими проверками издателя (issuer), аудитории (audience) и области (scope). Требуйте использования HTTPS повсеместно и применяйте mTLS, если этого требует граница доверия клиента.
Совмещайте ключи подписки с OAuth для создания глубокоэшелонированной обороны и использования их в качестве идентификатора для регулирования. Используйте ключи подписки на уровне продукта, чтобы разделять потребителей и ротировать ключи, не затрагивая других.
Применяйте ограничение частоты запросов и квоты с гранулярностью на уровне потребителя, области или подписки. Используйте IP-фильтрацию для добавления сетей партнеров в белый список, когда это необходимо.
Защищайте внутренние службы с помощью взаимной аутентификации TLS или управляемых удостоверений. Храните секреты как именованные значения (Named Values), используя ссылки на Key Vault, чтобы избежать хранения открытого текста в конфигурации.

Пример политики APIM для принудительного применения области действия JWT и регулирования (throttling):

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Усиление безопасности конвейера DevSecOps и Defender for DevOps

Azure DevOps и GitHub Actions должны проходить аутентификацию в Azure без использования долгоживущих секретов:

Используйте федерацию удостоверений для рабочих нагрузок (OIDC) для подключений к службам. Создайте регистрацию приложения/субъект-службу в Entra ID, затем добавьте федеративные учетные данные, которые привязывают репозиторий, ветку и рабочий процесс/окружение к удостоверению. Это позволяет получать краткоживущие токены без хранения секретов и поддерживает определение области действия с наименьшими привилегиями через Azure RBAC.
Усильте разрешения конвейера: требуйте утверждения для использования подключений к службам, ограничьте запуск конвейера только для защищенных веток и отключайте опцию «Разрешить сценариям доступ к токену OAuth», если она не требуется. Используйте группы переменных и секреты с маскированием; запретите вывод секретов в лог с помощью команд журналирования. В GitHub отдавайте предпочтение секретам на уровне окружения и организации, а не секретам репозитория, для централизованного управления и используйте настройки «предотвращать попадание секретов в журналы» в размещенных средствах выполнения, где это применимо.
Применяйте правила защиты окружения: обязательные рецензенты, проверки (например, тикеты управления изменениями, прохождение тестов) и утверждения на основе времени.

Создание федеративных учетных данных с помощью Azure CLI (пример для GitHub OIDC):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps интегрируется с Azure Repos и GitHub для выявления:

Результаты анализа безопасности кода (SAST) для распространенных языков; аннотации в pull request подсвечивают новые проблемы для предотвращения регрессий.
Риски зависимостей (SCA) с использованием данных об уязвимостях для библиотек с открытым исходным кодом (OSS), с рекомендациями по устранению и указанием исправленных версий.
Обнаружение утечек секретов и рекомендации по ротации скомпрометированных токенов/ключей.
Неправильные конфигурации инфраструктуры как кода (Infrastructure-as-Code) в ARM/Bicep/Terraform (например, общедоступное хранилище, разрешающие группы безопасности сети (NSG)) с управлением на основе политик и отслеживанием отклонений. Результаты анализа сводятся в Defender for Cloud с контекстом репозитория и конвейера для приоритизации. Блокируйте выпуски на основе порогов серьезности, чтобы остановить небезопасные развертывания.

Управление секретами и интеграция с платформой

Key Vault обеспечивает централизованное управление секретами, ключами и сертификатами с комплексными средствами контроля:

Включайте защиту от очистки (purge protection) и обратимое удаление (soft delete) для предотвращения необратимой потери данных. Предпочитайте RBAC политикам доступа для унифицированной авторизации; включайте Private Endpoints и отключайте публичный доступ к сети, где это возможно; включайте ведение журналов в защищенное рабочее пространство.
App Service и Functions используют ссылки на Key Vault в настройках приложений с помощью управляемых удостоверений (managed identities); ротация секретов происходит прозрачно, без повторного развертывания.
AKS извлекает секреты во время выполнения через Secrets Store CSI Driver с провайдером Azure Key Vault, аутентифицируясь с помощью Azure AD Workload Identity (рекомендуется). Избегайте размещения секретов в виде открытого текста в объектах Kubernetes Secret.

Пример ссылки на Key Vault для App Service:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (сокращенно):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

Конвейеры (pipelines) должны получать секреты во время выполнения задания:

Azure DevOps: задача Key Vault task с подключением службы (service connection) на основе управляемого удостоверения; ограничивайте загрузку секретов минимально необходимым количеством этапов.
GitHub Actions: используйте azure/login для OIDC и azure/keyvault для получения только необходимых секретов.

Безопасный SDLC, контейнеры, логирование и релизы

Практики безопасного жизненного цикла разработки ПО (SDLC) снижают риски до развертывания:

Моделирование угроз на ранних этапах с помощью STRIDE или аналогов гарантирует, что аутентификация, авторизация и потоки данных явно проверены. Обновляйте модели по мере развития архитектуры.
SAST запускается при каждом PR; сборка должна прерываться при обнаружении проблем высокой степени серьезности с четко назначенными ответственными. DAST выполняется после развертывания в промежуточный слот/среду с безопасными тестовыми данными.
SCA непрерывно отслеживает пакеты; требует использования фиксированных версий и соблюдения лицензионных соглашений.
Строгое ревью кода с политиками ветвления: обязательные рецензенты, привязанные рабочие элементы, проверка сборки и подписанные коммиты.

Безопасность образов контейнеров — основа целостности цепочки поставок:

Генерируйте и храните SBOM (в формате SPDX или CycloneDX) во время сборок, публикуйте их вместе с образами как артефакты OCI для обеспечения прослеживаемости.
Сканируйте образы перед отправкой (pre-push) и в состоянии покоя (at-rest) в реестрах с помощью сканера контейнеров Defender for Cloud; блокируйте продвижение образов при обнаружении критических уязвимостей.
Подписывайте образы и аттестации с помощью Notary v2/артефактов OCI с использованием cosign. Принудительно проверяйте подписи при допуске (admission) (например, с помощью Gatekeeper/OPA или AKS Policy для Kubernetes).
Меры контроля в Azure Container Registry (ACR): отключите пользователя-администратора, ограничьте сетевой доступ через Private Endpoints, включите использование ключей, управляемых клиентом, используйте токены с областью действия на уровне репозитория для гранулярного доступа и применяйте шаблоны хранения и карантина. Предоставляйте средам выполнения только роль AcrPull, а CI — AcrPush. Для AKS подключайте ACR с помощью поддерживаемой команды для создания корректного назначения роли, а не настраивайте роли вручную.
Если контейнеры должны использовать конечные точки служб VNet с хоста ВМ, установите поддерживаемый плагин CNI, чтобы трафик каждого контейнера исходил из подсети.

Логирование приложений не должно приводить к утечке секретов или персональных данных (PII):

Настройте Application Insights для редактирования или удаления конфиденциальных полей с помощью Telemetry Processors; избегайте логирования необработанных заголовков, токенов или полезных данных, содержащих секреты или PII. Ограничьте поля данных только теми, что необходимы для бизнеса, и включите выборку (sampling) для уменьшения рисков.
Направляйте диагностические данные в выделенную рабочую область Log Analytics со строгим RBAC (минимально необходимая роль — Log Analytics Reader) и неизменяемым хранилищем при экспорте в Storage (блокировки хранения на основе времени).
Защищайте конечные точки приема и запроса телеметрии с помощью Private Link, где это возможно. Храните строки подключения для инструментирования в Key Vault и регулярно их ротируйте.

Практики безопасных релизов обеспечивают контролируемое продвижение по средам:

Шлюзы утверждения в средах Azure DevOps или GitHub требуют участия назначенных рецензентов, прохождения проверок качества и наличия тикетов на изменение. Автоматизируйте окна ожидания для высокорискованных развертываний.
Применяйте принцип наименьших привилегий к подключениям служб и агентам; ограничивайте их область действия группами ресурсов или подписками для каждой среды. Используйте управляемые удостоверения с узкоспециализированными ролями.
Сегрегация сред (Dev, Test, Prod) с использованием отдельных подписок, VNet, Key Vault и ACR; запретите боковое перемещение между средами и используйте разные секреты/ключи в каждой из них.

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

Компания Fabrikam, Inc. публикует в интернете мультиарендный SaaS API. Требования: блокировать атаки из списка OWASP Top 10, проверять области (scopes) OAuth для каждой операции, предотвращать попадание секретов в репозитории, ограничивать злоупотребляющих клиентов и гарантировать, что в производственной среде запускаются только подписанные образы контейнеров.

Фронтенд и WAF

Разверните Azure Front Door Standard с политикой WAF, используя последний набор управляемых правил OWASP в режиме предотвращения (Prevention), а также пользовательские правила ограничения частоты запросов и геоблокировки. Обоснование: централизованное применение политик на глобальном пограничном уровне уменьшает поверхность атаки и поглощает атаки уровня L7 до того, как они достигнут источника.

Политика шлюза API

Разместите Azure API Management за Front Door; реализуйте политику validate-jwt с проверками issuer/audience/scope для каждой операции и ключи подписки на уровне продукта с квотами. Обоснование: APIM обеспечивает применение политик с учетом удостоверений и изоляцию арендаторов; ключи в сочетании с OAuth предлагают многоуровневую защиту и точное ограничение запросов.

Удостоверения и согласия

Зарегистрируйте SPA и демон-приложения в Entra ID с делегированными областями для пользовательских потоков и ролями приложений для демона; ограничьте согласие пользователей только проверенными издателями и требуйте согласия администратора для разрешений приложений. Используйте учетные данные на основе сертификатов для демона. Обоснование: исключает слабые секреты, обеспечивает принцип наименьших привилегий и снижает риски фишинга через запросы согласия.

DevSecOps с OIDC

Настройте GitHub Actions для использования федерации OIDC с субъектом-службой Azure, область действия которого ограничена подпиской для непроизводственной среды для сборки и субъектом-службой с областью действия в производственной среде для релиза, каждый с минимальными ролями (AcrPush для сборки, Contributor с ограничением до производственной RG для релиза). Обоснование: отсутствие хранимых секретов; минимизация радиуса поражения для каждой среды.

Цепочка поставок контейнеров

Собирайте образы с помощью ACR Tasks, генерируйте SBOM (CycloneDX) и подписывайте образы с помощью cosign; храните аттестации как артефакты OCI. Настройте контроль доступа (admission) в AKS с помощью политики, требующей наличия действительных подписей. Обоснование: происхождение и целостность можно проверить во время развертывания, блокируя подделанные образы.

Контроль реестра и среды выполнения

Отключите пользователя-администратора ACR, включите Private Endpoint, назначьте роль AcrPull удостоверению kubelet в AKS через поддерживаемый процесс attach-acr и включите сканирование образов в Defender for Cloud. Обоснование: усиление защиты сети и удостоверений устраняет бэкдоры по умолчанию; сканирование выявляет известные CVE до запуска.

Секреты и конфигурация

Используйте Key Vault с Private Endpoint и RBAC; App Service и Functions используют ссылки на Key Vault, а AKS — Secret Store CSI с Workload Identity. Обоснование: секреты никогда не находятся в репозиториях или конфигурациях приложений; их ротация централизована и поддается аудиту.

Управление релизами

Защитите главную ветку GitHub обязательными ревью и проверками; требуйте утверждения для сред и прохождения шлюзов безопасности (отсутствие критических находок SAST/SCA/IaC) перед развертыванием в производственную среду. Обоснование: гарантирует, что только проверенные и безопасные сборки проходят дальше; сохраняется человеческий контроль над высокорискованными изменениями.

Гигиена наблюдаемости

Настройте Application Insights для редактирования PII с помощью пользовательских Telemetry Processors и направляйте диагностические данные WAF/APIM в защищенную рабочую область Log Analytics с доступом по принципу наименьших привилегий (роль Reader). Обоснование: сохраняет ценность данных для анализа инцидентов без раскрытия конфиденциальной информации; доступ поддается аудиту и ограничен.

← Microsoft Sentinel и операции по обеспечению безопасности · Все домены · Гибридная и мультиоблачная безопасность →

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