Microsoft AZ-400: Безопасность, соответствие требованиям и DevSecOps — Руководство по подготовке

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

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

Зависимости, контейнеры, IaC и соответствие требованиям как код

Сканирование зависимостей должно охватывать как дефекты безопасности, так и лицензирование. Dependabot постоянно предлагает безопасные обновления; используйте политики проверки зависимостей, чтобы блокировать PR, которые добавляют уязвимые версии. OWASP Dependency-Check (или нативные для экосистемы инструменты, такие как npm audit, pip-audit) должен запускаться в CI для генерации SBOM (CycloneDX/SPDX) и прерывать сборку при нарушении пороговых значений серьезности или правил лицензирования. Для расширенного управления лицензиями используйте его в паре с SCA-платформой, способной применять юридические политики и реализовывать рабочие процессы по устранению нарушений.

Безопасность образов контейнеров начинается в CI и продолжается в реестре и в среде выполнения:

• Trivy: запускайте как шаг конвейера для сканирования Dockerfile и собранных образов на наличие CVE в ОС/пакетах и ошибок конфигурации; прерывайте сборку при обнаружении находок уровня Critical/High. Обеспечьте использование минимальных базовых образов и rootless-контейнеров.
• Сканирование уязвимостей в Azure Container Registry: включите Microsoft Defender for Containers для сканирования образов при отправке/импорте и по расписанию. Отображайте находки в Defender for Cloud, экспортируйте их в рабочие элементы и применяйте шлюзы развертывания, которые блокируют образы с нерешенными проблемами уровня Critical/High.
• Defender for Containers: расширьте защиту на AKS/ECS/Kubernetes с помощью обнаружения угроз во время выполнения, проверок в стиле kube-bench и admission control. Используйте политику, чтобы разрешить загрузку образов только из доверенных ACR, подписанных с помощью Notation/ACR content trust, и проверяйте подписи в CI и при допуске в кластер.

Безопасность IaC обеспечивает, что облачные ресурсы по умолчанию развертываются безопасно:

• Checkov и tfsec: сканируйте манифесты Terraform и Kubernetes на наличие небезопасных конфигураций (публичное хранилище, открытые группы безопасности, отсутствующее шифрование). Прерывайте сборки при превышении пороговых значений серьезности; зафиксируйте текущий технический долг, чтобы сосредоточиться на новых/измененных ресурсах.
• Линтинг ARM/Bicep: включите линтер Bicep (bicepconfig.json) и ARM Template Tool Kit (arm-ttk) для принудительного применения правил тегирования, конечных точек только с HTTPS, ключей, управляемых клиентом, и настроек диагностики. Комбинируйте с what-if развертываниями для обнаружения дрейфа конфигурации перед применением.

Соответствие требованиям как код (Compliance as Code) использует Azure Policy и Defender for Cloud для непрерывного применения контролей и отчетности по ним:

• Назначайте инициативы Azure Policy, соответствующие стандартам CIS, NIST, ISO 27001 или внутренним базовым конфигурациям; выбирайте эффекты, такие как Deny для критически важных ограничений (например, публичные IP-адреса у баз данных), DeployIfNotExists для настроек диагностики и Audit для наблюдаемости. Храните определения политик как версионируемые артефакты, тестируйте с помощью конвейеров policy-as-code и продвигайте изменения через pull-реквесты.
• Используйте панели мониторинга соответствия нормативным требованиям в Defender for Cloud для визуализации соответствия контролям в подписках и группах управления. Интегрируйте с Azure Monitor и экспортируйте свидетельства в Log Analytics или Event Hubs для передачи в SIEM.
• Ведите журналы аудита: Azure Activity Logs для событий и назначений политик, Resource Graph для запросов о соответствии, журналы аудита Azure DevOps/GitHub для изменений в репозиториях и конвейерах, а также свидетельства о релизах, автоматически сохраняемые как артефакты запуска конвейера.

SonarQube/SonarCloud, безопасность конвейера и Microsoft Defender for DevOps

SonarQube/SonarCloud предоставляет принудительно применяемые критерии качества (quality gates), которые согласовывают качество разработки с требованиями безопасности. Применяйте подход «Clean as You Code» (Чистый код по мере написания), устанавливая критерии для нового кода: минимальное покрытие кода для новых/измененных строк (например, 80%+), ноль новых критических уязвимостей (Critical) или блокирующих запахов кода (blocker code smells) и низкий уровень дублирования. Непрохождение критерия должно приводить к сбою конвейера. Публикуйте данные о покрытии из фреймворков для тестирования (JaCoCo, Cobertura, VSTest) и настраивайте профили качества для каждого языка, чтобы включить в них потенциально небезопасные участки кода (security hotspots) и правила, согласованные с OWASP. Отслеживайте коэффициент технического долга и время на его устранение; сообщайте о тенденциях для повышения ответственности команды.

Безопасность конвейера основывается на подключениях к службам с минимальными привилегиями, защищенных ресурсах и полном маскировании секретов:

• Подключения к службам должны использовать федерацию удостоверений рабочих нагрузок или управляемые удостоверения с узкими областями действия (подписка/группа ресурсов, конкретный ACR или Key Vault). Включите утверждения и проверки для подключений к службам и сред, чтобы владельцы должны были авторизовать их использование. Ограничьте разрешения на использование («Use») только доверенными конвейерами; отключите опцию «Grant access permission to all pipelines» (Предоставить разрешение на доступ всем конвейерам).
• Защищенные ресурсы в Azure DevOps охраняют подключения к службам, группы переменных, защищенные файлы и среды. Требуйте проверок, таких как наличие утверждающих, окна в рабочее время, результаты запросов Azure Monitor и внешние механизмы политик REST. Рассматривайте их как критерии перед развертыванием и как предварительные условия для чтения конфиденциальных данных (например, получение секретов производственной среды).
• Маскирование секретов должно принудительно применяться во всех журналах; ограничивайте раскрытие переменных в скриптах; избегайте вывода секретов в лог; и предпочитайте API, использующие токен system.accessToken, хранению PAT. Периодически сканируйте журналы конвейера на предмет случайных утечек секретов и меняйте их при обнаружении.

Microsoft Defender for DevOps объединяет состояние безопасности репозиториев и конвейеров в GitHub и Azure DevOps. Подключите организации/проекты к Defender for Cloud, чтобы получать сигналы о рисках в коде, секретах, IaC и зависимостях и представлять сводные рекомендации. Он сопоставляет находки с владельцами, поддерживает рабочие процессы для подавления оповещений с указанием срока действия и измеряет внедрение защит веток, обязательных рецензентов и проверок статуса. Используйте Defender for DevOps в паре с задачей/действием Microsoft Security DevOps, чтобы организовать запуск нескольких анализаторов (например, Semgrep, Trivy, tfsec, Gitleaks, Bandit) за один шаг и публиковать результаты в формате SARIF в code scanning. Используйте Defender for Cloud для создания инициатив управления, которые отслеживают и принудительно применяют лучшие практики DevOps (например, сканирование секретов включено, требуемое количество рецензентов ≥ 2, слияния не от имени администратора отключены), повышая гигиену репозитория до уровня контролируемого и проверяемого элемента.

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

Компании Spotify необходимо стандартизировать безопасную доставку для нового стека микросервисов на базе AKS, охватывающего .NET и Node.js, с репозиториями в GitHub Enterprise Cloud и развертываниями через многоэтапные YAML-конвейеры Azure DevOps. Задача состоит в том, чтобы остановить уязвимые зависимости и неправильно настроенную инфраструктуру до слияния, устранить статические учетные данные и блокировать продвижение образов с критическими CVE, и при этом создавать проверяемые доказательства соответствия требованиям.

1. Принудительное сканирование SAST/SCA и секретов во время PR

• Выбор SonarCloud для многоязычного SAST с декорированием PR и критериями качества; установка покрытия нового кода ≥ 80% и ноль новых критических уязвимостей. Включен Dependabot для автоматического создания PR с безопасными обновлениями, а GitHub dependency review блокирует PR, добавляющие известные CVE. Сканирование секретов GitHub Advanced Security вместе с Gitleaks в CI обеспечивает эшелонированную защиту от раскрытия учетных данных.

2. Добавление аутентифицированного DAST перед продвижением в следующую среду

• Использование OWASP ZAP на этапе конвейера, нацеленного на промежуточную среду (staging) с предварительно настроенными тестовыми учетными записями. Проверка в выпуске блокирует развертывание в производственную среду при появлении новых проблем уровня High/Critical. ZAP выбран за покрытие, соответствующее OWASP, и простую автоматизацию в CI.

3. Защита удостоверений и секретов с помощью Key Vault и федерации удостоверений рабочих нагрузок

• Замена секретов клиента service principal на федерацию удостоверений рабочих нагрузок Microsoft Entra для подключений к службам, что устраняет сохраненные секреты. Конвейеры извлекают секреты времени выполнения и учетные данные БД из Azure Key Vault, используя разрешения get/list с минимальными привилегиями. Это устраняет долгоживущие учетные данные и централизует их ротацию.

4. Реализация автоматизации сертификатов

• Хранение сертификатов для ingress и mTLS в Key Vault с автоматической ротацией. AKS получает сертификаты через драйвер Secrets Store CSI, чтобы избежать копирования секретов в Kubernetes. Event Grid запускает функцию для проверки привязок после обновления. Такая архитектура минимизирует время простоя и человеческие ошибки при ротации.

5. Усиление безопасности контейнеров и реестров

• Запуск Trivy в CI для сканирования Dockerfile и собранных образов; сбой при наличии уязвимостей уровня Critical/High. Отправка в ACR только чистых образов. Включение Defender for Containers для сканирования ACR при отправке и периодически, с передачей результатов в Defender for Cloud. Проверки в выпуске, основанные на политиках, блокируют развертывание образов с нерешенными CVE уровня Critical/High. Trivy обеспечивает быструю обратную связь; Defender добавляет непрерывную, встроенную в реестр гарантию безопасности.

6. Сканирование IaC и линтинг Bicep/ARM

• Использование Checkov и tfsec для сканирования Terraform и Helm-чартов; принудительное применение тегирования, шифрования и сетевых контролей. Линтер Bicep и ARM TTK запускаются в CI для нативных шаблонов Azure. Непройденные проверки блокируют слияния; базовые конфигурации (baselines) ограничивают шум только новыми/измененными ресурсами. Эти инструменты выбраны за широкое покрытие правил и сильную поддержку Azure.

7. Кодификация соответствия требованиям и сбор доказательств

• Назначение инициатив Azure Policy для базовых конфигураций CIS Azure и корпоративных стандартов; применение эффекта Deny для критических барьеров безопасности и DeployIfNotExists для диагностики. Передача результатов на панели мониторинга соответствия нормативным требованиям в Defender for Cloud. Экспорт журналов Activity Logs и рекомендаций Defender в Log Analytics для получения неизменяемых доказательств. Политики обеспечивают непрерывное принуждение; панели мониторинга предоставляют готовые к аудиту представления.

8. Блокировка конвейеров и защищенных ресурсов

• Ограничение подключений к службам областями действия подписок/групп ресурсов; требование утверждений для сред и проверок запросами Azure Monitor для производственной среды. Защита групп переменных и защищенных файлов; маскирование всех секретов. Усиление безопасности self-hosted агентов с помощью частных сетей. Эти функции уменьшают радиус поражения и обеспечивают участие человека в высокорисковых действиях.

9. Консолидация состояния безопасности с помощью Microsoft Defender for DevOps

• Подключение организации GitHub и проекта Azure DevOps к Defender for Cloud для агрегирования находок в коде, секретах и IaC, а также для отслеживания внедрения защит репозитория. Использование действия/задачи Microsoft Security DevOps для организации запуска Semgrep, Trivy, tfsec и Gitleaks с публикацией в формате SARIF, обеспечивая стандартизированное сканирование для всех сервисов. Это централизует управление рисками и рабочие процессы по их устранению.

Каждый инструмент/функция выбраны для максимально раннего обнаружения, автоматического принуждения и возможности аудита: SonarCloud и ZAP контролируют риски в коде и во время выполнения; Dependabot и Trivy ускоряют безопасные обновления; Key Vault и федерация удостоверений устраняют статические секреты; Checkov/tfsec и Azure Policy предотвращают дрейф конфигурации; защищенные ресурсы и утверждения контролируют радиус поражения; Defender for DevOps и Defender for Cloud обеспечивают единое, действенное управление состоянием безопасности.

← Управление релизами и стратегии развертывания · Все домены · Стратегия тестирования и инженерия качества →

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

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