Microsoft AZ-400: Sécurité, conformité et DevSecOps — Guide d'étude

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

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La sécurité, la conformité et le DevSecOps dans les pipelines de livraison axés sur Azure exigent de déplacer la détection des risques aux étapes les plus précoces possibles, d’appliquer les politiques en continu et d’automatiser la collecte de preuves. Les implémentations efficaces unifient les tests de sécurité des applications (SAST/DAST/SCA), la gouvernance des secrets, l’analyse de l’infrastructure-as-code (IaC) et les contrôles réglementaires dans le cycle de vie CI/CD. Dans Azure DevOps et GitHub, cela signifie exécuter des analyseurs sur chaque pull request, conditionner les fusions (merges) par des seuils de qualité, déployer avec des identités à privilèges minimum qui récupèrent des secrets à durée de vie limitée depuis Azure Key Vault, et surveiller en continu la posture avec Microsoft Defender for DevOps et Defender for Cloud. L’objectif n’est pas seulement de trouver des problèmes, mais d’empêcher les modifications non sécurisées d’atteindre les ressources protégées, de prouver la conformité grâce à des pistes d’audit et de maintenir une vélocité sécurisée.

Sécurité shift-left, atténuations du Top 10 de l’OWASP et durcissement des pipelines

La sécurité shift-left commence par des analyses SAST et SCA au moment de la PR, complétées par l’analyse des secrets et des analyses DAST ciblées avant la promotion. Le SAST révèle les vulnérabilités au niveau du code telles que les points d’injection, les désérialiseurs non sécurisés et l’encodage de sortie manquant. Intégrez SonarQube/SonarCloud ou GitHub code scanning (par ex., CodeQL) pour analyser chaque ensemble de modifications ; décorez les pull requests avec les problèmes liés à des lignes spécifiques ; et appliquez des portails de qualité (quality gates) qui font échouer le build lorsque les seuils de vulnérabilité ou de couverture ne sont pas atteints. Concentrez le SAST sur les classes du Top 10 de l’OWASP :

• Injection : imposez l’utilisation de requêtes paramétrées/ORM, validez/normalisez les entrées et bannissez le SQL dynamique/la concaténation de chaînes. Appliquez cela via des ensembles de règles SAST et des tests unitaires qui affirment l’utilisation d’assistants d’accès aux données validés.
• Cross-Site Scripting (XSS) : exigez l’encodage des sorties et une Content Security Policy. L’analyse de contamination (taint analysis) du SAST doit suivre les entrées non fiables jusqu’aux récepteurs (sinks) (innerHTML, Response.Write).
• Cross-Site Request Forgery (CSRF) : imposez les jetons anti-falsification et les cookies SameSite. Les pipelines peuvent exécuter des analyseurs de framework pour s’assurer que les middleware/paramètres sont activés.
• Désérialisation non sécurisée : interdisez les sérialiseurs binaires/XML non sécurisés, limitez les types autorisés et préférez les sérialiseurs JSON configurés avec des valeurs par défaut sûres. Les vérifications SAST et les politiques de dépendances empêchent l’utilisation de bibliothèques connues comme étant non sécurisées.

Le DAST valide les builds en cours d’exécution dans un environnement de pré-production (staging). Automatisez OWASP ZAP ou un équivalent en tant que tâche de pipeline après le déploiement en non-production, en utilisant des analyses authentifiées et un ensemble de règles adapté au profil de votre application. Conditionnez la promotion sur une ligne de base de vulnérabilités : bloquez en cas de nouvelles découvertes de niveau Élevé/Critique et persistez les exceptions acceptées avec une date d’expiration.

L’analyse de la composition logicielle (SCA) détecte les paquets tiers vulnérables avant la fusion. Utilisez Dependabot pour créer des PR de montée de version et OWASP Dependency-Check pour produire des SBOMs et des rapports CVE en CI. Appliquez la conformité des licences en définissant des listes d’autorisation/refus (par ex., refuser le copyleft pour les produits propriétaires) et en faisant échouer les builds qui incluent des licences non autorisées. L’analyse des secrets doit s’exécuter au commit et en CI : adoptez l’analyse de secrets de GitHub Advanced Security ou intégrez Gitleaks/Microsoft Security DevOps pour attraper les informations d’identification, jetons et clés codés en dur ; bloquez la fusion lorsqu’un modèle de secret est détecté et effectuez la rotation des informations d’identification affectées.

Le durcissement des pipelines n’est pas négociable. Verrouillez les protections de branche, exigez les revues de PR et imposez des vérifications de statut pour le SAST/SCA/DAST. Dans Azure Pipelines, utilisez les ressources protégées, les approbations et vérifications d’environnement, et les modèles requis pour standardiser les étapes de sécurité. Préférez les jetons à courte durée de vie et à privilèges minimum ; évitez complètement les informations d’identification statiques avec la fédération d’identité de charge de travail (workload identity federation). Restreignez les agents auto-hébergés aux réseaux privés, limitez au minimum la portée de leurs identités et désactivez l’injection de script en imposant des modèles qui interdisent les étapes de script arbitraires pour les dépôts non fiables.

Secrets, identités, Azure Key Vault et rotation des certificats

Azure Key Vault est le magasin faisant autorité pour les secrets, les clés et les certificats. Intégrez-le directement avec le CI/CD pour éliminer les secrets en texte clair :

• Secrets de pipeline : dans Azure DevOps, liez un groupe de variables à un Key Vault en utilisant une connexion de service dont la portée est limitée aux seuls noms de secrets requis. Les secrets sont récupérés à l’exécution et masqués dans les journaux. Dans GitHub Actions, utilisez azure/login avec une identité fédérée pour obtenir des jetons et appeler Key Vault ; évitez de stocker les secrets client dans les paramètres du dépôt.
• Accès par identité managée : chaque fois que possible, laissez les charges de travail et les agents de déploiement s’authentifier avec Microsoft Entra ID en utilisant une identité managée ou la fédération d’identité de charge de travail afin qu’aucun secret ne soit stocké. Définissez la portée de l’accès à Key Vault en utilisant le RBAC ou des stratégies d’accès selon le principe du moindre privilège (get/list uniquement pour des versions de secrets spécifiques ; pas de purge/delete).
• Rotation des certificats : stockez les certificats TLS/MTLS dans Key Vault Certificates avec une rotation automatique via les autorités de certification (CA) intégrées. Configurez les services consommateurs (App Service, Application Gateway, AKS Ingress via CSI Secrets Store) pour référencer Key Vault afin que les certificats renouvelés soient récupérés sans redéploiement. Utilisez Event Grid sur les événements certificateNearExpiry de Key Vault pour déclencher un runbook d’automatisation ou une Function qui valide les liaisons et préchauffe les caches. Suivez l’utilisation des versions de certificats dans les manifestes de déploiement ; épinglez les versions si nécessaire et effectuez une montée de version délibérée pendant les fenêtres de maintenance.

Durcissez Key Vault avec des points de terminaison privés, des règles de pare-feu, la protection contre la purge, la suppression réversible (soft-delete) et la journalisation vers Log Analytics ou un stockage pour l’audit. Refusez l’accès inter-locataires (cross-tenant) sauf justification explicite, et effectuez une rotation régulière de l’accès pour les comptes de secours (break-glass).

Dépendances, conteneurs, IaC et conformité en tant que code

L’analyse des dépendances doit gérer à la fois les failles de sécurité et les licences. Dependabot propose continuellement des mises à jour sécurisées ; utilisez des politiques de révision des dépendances pour bloquer les PR qui introduisent des versions vulnérables. OWASP Dependency-Check (ou des outils natifs de l’écosystème comme npm audit, pip-audit) doit s’exécuter en CI pour générer des SBOM (CycloneDX/SPDX) et faire échouer le build lorsque des seuils de sévérité ou des règles de licence sont enfreints. Pour une gouvernance avancée des licences, associez-le à une plateforme SCA capable d’appliquer des politiques juridiques et de gérer des workflows de remédiation.

La sécurité des images de conteneurs commence en CI et se poursuit dans le registre et à l’exécution :

• Trivy : exécutez-le comme une étape de pipeline pour analyser les Dockerfiles et les images construites à la recherche de CVE et de mauvaises configurations de l’OS/des paquets ; interrompez le build en cas de découvertes critiques/élevées. Imposez l’utilisation d’images de base minimales et de conteneurs sans racine (rootless).
• Analyse de vulnérabilités d’Azure Container Registry : activez Microsoft Defender for Containers pour analyser les images lors du push/de l’importation et de manière planifiée. Faites remonter les découvertes dans Defender for Cloud, exportez-les vers des éléments de travail et appliquez des portes de déploiement (deployment gates) qui bloquent les images avec des problèmes critiques/élevés non résolus.
• Defender for Containers : étendez la protection à AKS/ECS/Kubernetes avec la détection des menaces à l’exécution, des vérifications de type kube-bench et un contrôle d’admission. Utilisez une politique pour ne tirer (pull) que depuis des ACR de confiance signés avec Notation/ACR content trust et vérifiez les signatures en CI et lors de l’admission au cluster.

La sécurité de l’IaC garantit que les ressources cloud sont provisionnées de manière sécurisée par défaut :

• Checkov et tfsec : analysez les manifestes Terraform et Kubernetes à la recherche de configurations non sécurisées (stockage public, groupes de sécurité ouverts, chiffrement manquant). Faites échouer les builds sur les seuils de sévérité ; établissez une base de référence de la dette existante pour vous concentrer sur les ressources nouvelles/modifiées.
• Linting ARM/Bicep : activez le linter Bicep (bicepconfig.json) et l’ARM Template Tool Kit (arm-ttk) pour appliquer des règles pour le balisage (tagging), les points de terminaison HTTPS uniquement, les clés gérées par le client et les paramètres de diagnostic. Combinez avec des déploiements what-if pour détecter la dérive (drift) avant l’application.

La conformité en tant que code (Compliance as Code) utilise Azure Policy et Defender for Cloud pour appliquer et générer des rapports sur les contrôles en continu :

• Attribuez des initiatives Azure Policy alignées sur CIS, NIST, ISO 27001 ou des bases de référence internes ; sélectionnez des effets comme Deny pour les garde-fous critiques (par ex., les IP publiques sur les bases de données), DeployIfNotExists pour les diagnostics et Audit pour l’observabilité. Stockez les définitions de politique en tant qu’artefacts versionnés, testez avec des pipelines de politique en tant que code (policy-as-code) et promouvez via des pull requests.
• Utilisez les tableaux de bord de conformité réglementaire de Defender for Cloud pour visualiser la conformité des contrôles à travers les abonnements et les groupes d’administration. Intégrez avec Azure Monitor et exportez les preuves vers Log Analytics ou Event Hubs pour l’ingestion par un SIEM.
• Maintenez des pistes d’audit : Azure Activity Logs pour les événements et les attributions de politiques, Resource Graph pour les requêtes de conformité, les journaux d’audit d’Azure DevOps/GitHub pour les changements de repo et de pipeline, et les preuves de publication (release evidence) capturées automatiquement en tant qu’artefacts d’exécution de pipeline.

SonarQube/SonarCloud, sécurité des pipelines et Microsoft Defender for DevOps

SonarQube/SonarCloud fournit des portails de qualité (quality gates) exécutoires qui alignent la qualité de l’ingénierie sur la sécurité. Adoptez l’approche « Clean as You Code » en définissant des portails sur le nouveau code : couverture de code minimale sur les lignes nouvelles/modifiées (par ex., 80 %+), zéro nouvelle vulnérabilité critique ou « code smell » bloquant, et faible duplication. L’échec du portail doit entraîner l’échec du pipeline. Publiez la couverture à partir des frameworks de test (JaCoCo, Cobertura, VSTest) et ajustez les profils de qualité par langage pour inclure les points chauds de sécurité (security hotspots) et les règles alignées sur l’OWASP. Suivez les ratios de dette technique et les temps de remédiation ; rapportez les tendances pour responsabiliser l’équipe.

La sécurité des pipelines repose sur des connexions de service à moindre privilège, des ressources protégées et un masquage complet des secrets :

• Les connexions de service doivent utiliser la fédération d’identité de charge de travail (workload identity federation) ou des identités managées avec des portées restreintes (abonnement/groupe de ressources, ACR spécifique ou Key Vault). Activez les approbations et les vérifications sur les connexions de service et les environnements afin que les propriétaires doivent autoriser leur utilisation. Limitez les autorisations « Utiliser » aux pipelines de confiance ; désactivez « Accorder l’autorisation d’accès à tous les pipelines ».
• Les ressources protégées dans Azure DevOps protègent les connexions de service, les groupes de variables, les fichiers sécurisés et les environnements. Exigez des vérifications telles que des approbateurs, des fenêtres d’heures ouvrables, des résultats de requêtes Azure Monitor et des moteurs de politiques REST externes. Considérez-les comme des portails avant les déploiements et comme des prérequis pour les lectures sensibles (par ex., la récupération de secrets de production).
• Le masquage des secrets doit être appliqué sur tous les journaux ; restreignez l’expansion des variables dans les scripts ; évitez d’afficher les secrets en clair (echoing) ; et préférez les API à portée system.accessToken plutôt que de stocker des PAT. Analysez périodiquement les journaux de pipeline pour détecter les fuites accidentelles de secrets et effectuez une rotation dès leur détection.

Microsoft Defender for DevOps unifie la posture de sécurité des dépôts et des pipelines sur GitHub et Azure DevOps. Connectez les organisations/projets à Defender for Cloud pour ingérer les signaux de risque liés au code, aux secrets, à l’IaC et aux dépendances, et présenter des recommandations consolidées. Il corrèle les résultats avec les propriétaires, prend en charge les flux de travail de suppression avec expiration, et mesure l’adoption des protections de branche, des réviseurs requis et des vérifications de statut. Associez Defender for DevOps à la tâche/action Microsoft Security DevOps pour orchestrer plusieurs analyseurs (par ex., Semgrep, Trivy, tfsec, Gitleaks, Bandit) en une seule étape et publier les résultats SARIF vers l’analyse de code (code scanning). Utilisez Defender for Cloud pour créer des initiatives de gouvernance qui suivent et appliquent les meilleures pratiques DevOps (par ex., analyse de secrets activée, nombre de réviseurs requis ≥ 2, fusions non-administrateur désactivées), élevant l’hygiène des dépôts au niveau d’un contrôle auditable.

Scénario de problème pratique

Spotify doit standardiser la livraison sécurisée pour une nouvelle pile de microservices hébergée sur AKS, couvrant .NET et Node.js, avec des dépôts dans GitHub Enterprise Cloud et des déploiements via des pipelines YAML multi-étapes d’Azure DevOps. Le défi consiste à bloquer les dépendances vulnérables et l’infrastructure mal configurée avant la fusion, à éliminer les informations d’identification statiques et à bloquer la promotion des images contenant des CVE critiques, tout en produisant des preuves de conformité auditables.

1. Appliquer l’analyse SAST/SCA et des secrets au moment de la PR

• Choisir SonarCloud pour le SAST multi-langage avec décoration de PR et portails de qualité ; définir une couverture de code sur le nouveau code ≥ 80 % et zéro nouvelle vulnérabilité critique. Dependabot est activé pour proposer automatiquement par PR des mises à niveau sûres et la revue des dépendances GitHub bloque les PR introduisant des CVE connues. L’analyse des secrets de GitHub Advanced Security, complétée par Gitleaks en CI, assure une défense en profondeur contre l’exposition des informations d’identification.

2. Ajouter une analyse DAST authentifiée avant la promotion

• Utiliser OWASP ZAP dans une étape de pipeline ciblant l’environnement de pré-production (staging) avec des comptes de test préconfigurés. Une vérification de mise en production (release check) bloque la production si de nouveaux problèmes de niveau Élevé/Critique apparaissent. ZAP est choisi pour sa couverture alignée sur l’OWASP et sa facilité d’automatisation en CI.

3. Sécuriser les identités et les secrets avec Key Vault et la fédération d’identité de charge de travail

• Remplacer les secrets client des principaux de service par la fédération d’identité de charge de travail Microsoft Entra pour les connexions de service, supprimant ainsi les secrets stockés. Les pipelines récupèrent les secrets d’exécution et les informations d’identification de base de données depuis Azure Key Vault via des autorisations get/list à moindre privilège. Cela élimine les informations d’identification à longue durée de vie et centralise leur rotation.

4. Mettre en œuvre l’automatisation des certificats

• Stocker les certificats d’ingress et mTLS dans Key Vault avec rotation automatique. AKS récupère les certificats via le pilote Secrets Store CSI pour éviter de copier des secrets dans Kubernetes. Event Grid déclenche une fonction pour vérifier les liaisons (bindings) après le renouvellement. Cette conception minimise les temps d’arrêt et les erreurs humaines lors de la rotation.

5. Renforcer la sécurité des conteneurs et des registres

• Exécuter Trivy en CI pour analyser les Dockerfiles et les images construites ; échouer en cas de criticité Élevée/Critique. Pousser uniquement les images saines vers ACR. Activer Defender for Containers pour analyser ACR lors du push et périodiquement, en remontant les résultats à Defender for Cloud. Des vérifications de mise en production basées sur des politiques bloquent le déploiement d’images avec des CVE Élevées/Critiques non résolues. Trivy fournit un retour rapide ; Defender ajoute une assurance continue et native au registre.

6. Analyser l’IaC et valider (lint) Bicep/ARM

• Utiliser Checkov et tfsec pour analyser les charts Terraform et Helm ; imposer le balisage (tagging), le chiffrement et les contrôles réseau. Le linter Bicep et l’ARM TTK s’exécutent en CI pour les modèles natifs Azure. Les vérifications échouées bloquent les fusions ; les lignes de base (baselines) limitent le bruit aux ressources nouvelles/modifiées. Ces outils sont choisis pour leur large couverture de règles et leur solide support Azure.

7. Codifier la conformité et les preuves

• Assigner des initiatives Azure Policy pour les benchmarks CIS Azure et les lignes de base de l’entreprise ; appliquer Deny sur les garde-fous critiques et DeployIfNotExists pour les diagnostics. Envoyer les résultats aux tableaux de bord réglementaires de Defender for Cloud. Exporter les journaux d’activité (Activity Logs) et les recommandations de Defender vers Log Analytics pour des preuves immuables. La politique assure une application continue ; les tableaux de bord offrent des vues prêtes pour l’audit.

8. Verrouiller les pipelines et les ressources protégées

• Restreindre les connexions de service à des abonnements/groupes de ressources délimités ; exiger des approbations d’environnement et des vérifications par requête Azure Monitor pour la production. Protéger les groupes de variables et les fichiers sécurisés ; masquer tous les secrets. Renforcer la sécurité des agents auto-hébergés avec un réseau privé. Ces fonctionnalités réduisent le rayon d’impact (blast radius) et garantissent une intervention humaine pour les actions à haut risque.

9. Consolider la posture avec Microsoft Defender for DevOps

• Connecter l’organisation GitHub et le projet Azure DevOps à Defender for Cloud pour agréger les résultats d’analyse du code, des secrets et de l’IaC, et suivre l’adoption des protections de dépôt. Utiliser l’action/tâche Microsoft Security DevOps pour orchestrer Semgrep, Trivy, tfsec et Gitleaks avec publication SARIF, garantissant une analyse standardisée sur tous les services. Cela centralise la gestion des risques et les flux de travail de remédiation.

Chaque outil/fonctionnalité est sélectionné pour une détection la plus précoce possible, une application automatique et une auditabilité : SonarCloud et ZAP contrôlent les risques liés au code et à l’exécution ; Dependabot et Trivy accélèrent les mises à jour sûres ; Key Vault et la fédération d’identité suppriment les secrets statiques ; Checkov/tfsec et Azure Policy préviennent la dérive (drift) ; les ressources protégées et les approbations contrôlent le rayon d’impact ; Defender for DevOps et Defender for Cloud fournissent une gestion de la posture unifiée et exploitable.

← Gestion des mises en production et stratégies de déploiement · Tous les domaines · Stratégie de test et ingénierie de la qualité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →