Microsoft AZ-500: Sécurité des applications et DevSecOps — Guide d'étude

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

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — 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é des applications et le DevSecOps dans Azure se concentrent sur la prévention de l’utilisation abusive des identités, la protection des points d’entrée (ingress) et des API, le décalage de la sécurité vers la gauche (shift left) dans les pipelines, la sécurisation des secrets au repos et en transit, et l’application d’une gouvernance de mise en production robuste. Les conceptions efficaces éliminent les secrets à longue durée de vie, appliquent le moindre privilège, valident chaque appelant et institutionnalisent la détection et la remédiation continues à travers le code, les dépendances, l’infrastructure et l’environnement d’exécution (runtime).

Sécurisation de l’identité des applications, des points d’entrée et protection des API

La sécurisation de l’identité des applications dans Microsoft Entra ID (Azure AD) commence par une inscription d’application bien délimitée et le flux OAuth 2.0 approprié :

Les autorisations déléguées s’appliquent lorsqu’un utilisateur est connecté et le consentement peut être limité aux seules applications d’éditeurs vérifiés ou aux étendues (scopes) approuvées par un administrateur. Les autorisations d’application (application seule) nécessitent toujours le consentement de l’administrateur car elles autorisent des démons ou des services d’arrière-plan qui agissent sans utilisateur.
Appliquez le principe du moindre privilège en n’accordant que les étendues (scopes) ou les rôles d’application minimaux nécessaires et en exigeant un examen par l’administrateur des demandes de consentement. Désactivez le consentement de l’utilisateur final ou ne l’autorisez que pour les éditeurs vérifiés à faible risque afin de réduire le hameçonnage par consentement (consent phishing).
Préférez les informations d’identification par certificat ou les identités fédérées aux secrets client. Les certificats offrent une assurance plus forte et une rotation prévisible. Configurez des durées de vie courtes et automatisez la rotation. Bloquez les flux de clients publics sauf si nécessaire.
Pour les services Azure, utilisez des identités managées au lieu de secrets d’application. Attribuez des rôles de plan de données tels que Key Vault Secrets User ou Storage Blob Data Reader, et restreignez l’accès réseau à l’aide de Private Endpoints le cas échéant.

Application Gateway WAF v2 et Azure Front Door WAF protègent les points d’entrée (ingress) publics contre les menaces du Top 10 de l’OWASP :

Activez le dernier ensemble de règles de base (Core Rule Set) OWASP géré par Microsoft et exécutez-le en mode Prévention après l’avoir ajusté. Utilisez initialement le score d’anomalie pour réduire les faux positifs pendant la phase d’apprentissage.
Configurez des règles personnalisées pour le géorepérage (geofencing), le blocage par réputation d’IP, l’application de règles sur les en-têtes et les limites de taille des requêtes. Pour Front Door, ajoutez des règles de limitation de débit (rate-limit) par IP client pour contrer le bourrage d’identifiants (credential stuffing) et les attaques DoS de base sur la couche 7.
Terminez la connexion TLS avec des suites de chiffrement (cipher suites) et des politiques robustes ; utilisez le TLS de bout en bout jusqu’à l’origine. Pour les scénarios nécessitant le mTLS, configurez la validation des certificats clients sur les écouteurs (listeners) de l’Application Gateway.
Attachez les politiques WAF aux écouteurs/routes de manière précise ; n’utilisez les exclusions de règles que lorsque vous comprenez parfaitement le faux positif. Diffusez les journaux WAF vers Log Analytics pour l’ingénierie de détection et la réponse aux incidents.

API Management (APIM) applique une posture de sécurité multicouche :

Validez les jetons OAuth au niveau de la passerelle avec des vérifications strictes de l’émetteur (issuer), de l’audience et de l’étendue (scope). Exigez le HTTPS partout et imposez le mTLS lorsque la limite de confiance du client le requiert.
Combinez les clés d’abonnement avec OAuth pour une défense en profondeur et pour la limitation par identité. Utilisez des clés d’abonnement au niveau du produit pour partitionner les consommateurs et effectuer la rotation des clés sans impacter les autres.
Appliquez une limitation de débit et des quotas avec une granularité par consommateur, par étendue ou par abonnement. Utilisez le filtrage IP pour inscrire sur liste blanche (allowlist) les réseaux partenaires lorsque cela est approprié.
Protégez les services backend à l’aide du TLS mutuel ou d’identités managées. Stockez les secrets en tant que Valeurs Nommées (Named Values) s’appuyant sur des références Key Vault pour éviter le texte en clair dans la configuration.

Exemple de politique APIM pour l’application de l’étendue (scope) JWT et la limitation de débit :

<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>

Durcissement des pipelines DevSecOps et Defender for DevOps

Azure DevOps et GitHub Actions doivent s’authentifier auprès d’Azure sans secrets à longue durée de vie :

Utilisez la fédération d’identité de charge de travail (workload identity federation - OIDC) pour les connexions de service. Créez une inscription d’application/un principal de service dans Entra ID, puis ajoutez une information d’identification fédérée qui lie le dépôt, la branche et le workflow/environnement à l’identité. Cela produit des jetons à courte durée de vie sans secrets stockés et prend en charge la délimitation du moindre privilège via Azure RBAC.
Verrouillez les autorisations du pipeline : exigez des approbations pour utiliser les connexions de service, restreignez le pipeline aux branches protégées et désactivez « Autoriser les scripts à accéder au jeton OAuth » sauf si nécessaire. Utilisez des groupes de variables et des secrets avec masquage ; interdisez l’affichage des secrets en clair (secret echo) via les commandes de journalisation. Dans GitHub, préférez les secrets d’environnement et d’organisation aux secrets de dépôt pour un contrôle centralisé et utilisez les paramètres « prevent secrets in logs » dans les exécuteurs (runners) hébergés le cas échéant.
Appliquez des règles de protection d’environnement : réviseurs requis, vérifications (par ex., tickets de gestion du changement, réussite des tests) et approbations basées sur le temps.

Créer une information d’identification fédérée avec Azure CLI (exemple OIDC pour GitHub) :

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 s’intègre avec Azure Repos et GitHub pour faire remonter :

Les résultats de sécurité du code (SAST) dans les langages courants ; les annotations de pull request mettent en évidence les nouveaux problèmes pour éviter les régressions.
Le risque lié aux dépendances (SCA) en utilisant les renseignements sur les vulnérabilités pour les bibliothèques OSS avec des conseils de remédiation et les versions corrigées.
La détection de l’exposition de secrets et les rotations recommandées pour les jetons/clés divulgués.
Les mauvaises configurations de l’Infrastructure-as-Code sur ARM/Bicep/Terraform (par ex., stockage public, NSG permissifs) avec une gouvernance basée sur des politiques et un suivi de la dérive (drift). Les résultats sont consolidés dans Defender for Cloud avec le contexte du dépôt et du pipeline pour la priorisation. Bloquez les mises en production (gate releases) en fonction de seuils de gravité pour arrêter les déploiements non sécurisés.

Gestion des secrets et intégration à la plateforme

Key Vault fournit une gestion centralisée des secrets, des clés et des certificats avec des contrôles complets :

Appliquez la protection contre la purge et la suppression réversible (soft delete) pour éviter toute perte destructive. Préférez le RBAC aux stratégies d’accès pour une autorisation unifiée ; activez les Private Endpoints et désactivez l’accès au réseau public lorsque cela est possible ; activez la journalisation vers un espace de travail sécurisé.
App Service et Functions utilisent des références Key Vault dans les paramètres d’application avec des identités managées ; effectuez la rotation des secrets de manière transparente sans redéploiement.
AKS récupère les secrets à l’exécution via le Secrets Store CSI Driver avec le fournisseur Azure Key Vault, authentifié par Azure AD Workload Identity (recommandé). Évitez de placer des secrets en texte clair dans les objets Secret de Kubernetes.

Exemple de référence Key Vault pour App Service :

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

SecretProviderClass pour AKS (abrégé) :

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

Les pipelines doivent récupérer les secrets lors de l’exécution de la tâche (job) :

Azure DevOps : Tâche Key Vault avec une connexion de service basée sur une identité managée ; limitez le téléchargement des secrets au nombre minimal d’étapes (stages).
GitHub Actions : azure/login pour OIDC et azure/keyvault pour ne récupérer que les noms requis.

SDLC sécurisé, conteneurs, journalisation et publications

Les pratiques de SDLC (cycle de vie du développement logiciel) sécurisé réduisent les risques avant le déploiement :

La modélisation des menaces précoce avec STRIDE ou un équivalent garantit que l’authentification, l’autorisation et les flux de données sont explicitement validés. Mettez à jour les modèles à mesure que l’architecture évolue.
Le SAST s’exécute sur chaque PR ; interrompez les builds en cas de problèmes de haute gravité avec une responsabilité claire. Le DAST s’exécute après le déploiement dans un emplacement/environnement de préproduction avec des données de test sécurisées.
Le SCA surveille en continu les paquets ; impose des versions figées et la conformité des licences.
Une revue de code rigoureuse avec des stratégies de branche : réviseurs requis, éléments de travail liés, validation du build et commits signés.

La sécurité des images de conteneurs est fondamentale pour l’intégrité de la chaîne d’approvisionnement :

Générez et stockez des nomenclatures logicielles (SBOMs au format SPDX ou CycloneDX) pendant les builds, publiez-les aux côtés des images en tant qu’artefacts OCI pour la traçabilité.
Analysez les images avant le push et au repos dans les registres à l’aide de l’analyse de conteneurs de Defender for Cloud ; bloquez la promotion en cas de découvertes critiques.
Signez les images et les attestations à l’aide d’artefacts Notary v2/OCI avec cosign. Appliquez la vérification de la signature à l’admission (par exemple, Gatekeeper/OPA ou AKS Policy pour Kubernetes).
Contrôles du registre dans Azure Container Registry (ACR) : désactivez l’utilisateur administrateur, restreignez le réseau via des points de terminaison privés (Private Endpoints), activez les clés gérées par le client, utilisez des jetons à portée de dépôt pour un accès affiné, et appliquez des modèles de rétention et de quarantaine. N’accordez que le rôle AcrPull aux environnements d’exécution et AcrPush à la CI. Pour AKS, attachez ACR avec la commande prise en charge pour créer l’attribution correcte plutôt que de configurer manuellement le rôle.
Si les conteneurs doivent utiliser des points de terminaison de service de VNet depuis un hôte de machine virtuelle, installez un plugin CNI pris en charge afin que le trafic de chaque conteneur provienne du sous-réseau.

La journalisation des applications ne doit pas divulguer de secrets ou de PII (informations d’identification personnelle) :

Configurez Application Insights pour expurger ou supprimer les champs sensibles avec des processeurs de télémétrie (Telemetry Processors) ; évitez de journaliser les en-têtes bruts, les jetons ou les charges utiles contenant des secrets ou des PII. Limitez les champs de données au besoin métier et activez l’échantillonnage pour réduire l’exposition.
Acheminez les diagnostics vers un espace de travail Log Analytics dédié avec un RBAC strict (lecteur Log Analytics comme privilège minimum) et un stockage immuable lors de l’exportation vers un compte de stockage (verrous de rétention temporels).
Protégez les points de terminaison d’ingestion et de requête de télémétrie avec Private Link là où il est disponible. Stockez les chaînes de connexion d’instrumentation dans Key Vault et effectuez leur rotation régulièrement.

Les pratiques de publication sécurisées imposent une promotion contrôlée :

Les portes d’approbation dans les environnements Azure DevOps ou GitHub exigent des réviseurs désignés, la réussite des contrôles de qualité et des tickets de changement. Automatisez les fenêtres de suspension pour les déploiements à haut risque.
Appliquez le moindre privilège aux connexions de service et aux agents ; limitez leur portée aux groupes de ressources ou aux abonnements par environnement. Utilisez des identités managées avec des rôles à portée restreinte.
Ségrégation des environnements Dev, Test et Prod avec des abonnements, des VNets, des Key Vaults et des ACRs distincts ; interdisez les mouvements latéraux entre environnements et utilisez des secrets/clés différents dans chaque environnement.

Scénario de problème pratique

Fabrikam, Inc. publie une API SaaS multi-locataire sur Internet. Exigences : bloquer les attaques du Top 10 de l’OWASP, valider les portées OAuth pour chaque opération, empêcher la présence de secrets dans les dépôts, limiter le débit des clients abusifs et s’assurer que seules les images de conteneurs signées s’exécutent en production.

Exposition frontale et WAF

Déployez Azure Front Door Standard avec une stratégie WAF utilisant le dernier ensemble de règles managées OWASP en mode Prévention, ainsi que des règles personnalisées de limitation de débit et de blocage géographique. Justification : l’application centralisée en périphérie mondiale réduit la surface d’attaque et absorbe les attaques de couche 7 avant qu’elles n’atteignent l’origine.

Stratégie de passerelle d’API

Placez Azure API Management derrière Front Door ; implémentez la stratégie validate-jwt avec des vérifications de l’émetteur/audience/portée par opération et des clés d’abonnement au niveau du produit avec des quotas. Justification : APIM fournit une application des stratégies basée sur l’identité et une isolation des locataires ; les clés associées à OAuth offrent une défense en couches et une limitation de débit précise.

Identité et consentement

Enregistrez les applications SPA et démon dans Entra ID avec des portées déléguées pour les flux utilisateur et des rôles d’application pour le démon ; limitez le consentement utilisateur aux éditeurs vérifiés et exigez le consentement de l’administrateur pour les permissions d’application. Utilisez des informations d’identification par certificat pour le démon. Justification : élimine les secrets faibles, applique le moindre privilège et réduit l’exposition au hameçonnage au consentement.

DevSecOps avec OIDC

Configurez GitHub Actions pour utiliser la fédération OIDC vers un principal de service Azure dont la portée est limitée à un abonnement de non-production pour le build, et vers un principal dont la portée est limitée à la production pour la publication, chacun avec des rôles minimaux (AcrPush pour le build, Contributeur limité à un groupe de ressources de production pour la publication). Justification : aucun secret stocké ; le rayon d’impact est minimisé par environnement.

Chaîne d’approvisionnement des conteneurs

Construisez les images via ACR Tasks, générez des SBOMs (CycloneDX) et signez les images avec cosign ; stockez les attestations en tant qu’artefacts OCI. Configurez l’admission AKS avec une stratégie pour exiger des signatures valides. Justification : la provenance et l’intégrité sont vérifiables au moment du déploiement, bloquant ainsi les images falsifiées.

Contrôles du registre et de l’exécution

Désactivez l’utilisateur administrateur d’ACR, activez le point de terminaison privé (Private Endpoint), assignez le rôle AcrPull à l’identité kubelet d’AKS via le flux attach-acr pris en charge, et activez l’analyse d’images de Defender for Cloud. Justification : le durcissement du réseau et de l’identité supprime les portes dérobées par défaut ; l’analyse détecte les CVE connues avant l’exécution.

Secrets et configuration

Utilisez Key Vault avec un point de terminaison privé (Private Endpoint) et le RBAC ; App Service et Functions consomment des références Key Vault, et AKS utilise le pilote CSI Secret Store avec Workload Identity. Justification : les secrets ne résident jamais dans les dépôts ou les configurations d’application ; la rotation est centralisée et auditable.

Gouvernance des publications

Protégez la branche principale de GitHub avec des revues et des vérifications requises ; exigez des approbations d’environnement et la réussite des portes de sécurité (aucune découverte critique SAST/SCA/IaC) avant le déploiement en production. Justification : garantit que seuls les builds validés et sécurisés progressent ; une supervision humaine est maintenue pour les changements à haut risque.

Hygiène de l’observabilité

Configurez Application Insights pour expurger les PII avec des processeurs de télémétrie (Telemetry Processors) personnalisés et acheminez les diagnostics WAF/APIM vers un espace de travail Log Analytics sécurisé avec un accès Lecteur au privilège minimum. Justification : préserve la valeur forensique sans exposer de données sensibles ; l’accès est auditable et restreint.

← Microsoft Sentinel et opérations de sécurité · Tous les domaines · Sécurité hybride et multi-cloud →

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