10 · Gérer la posture de sécurité avec Microsoft Defender for Cloud

Version : 1.2 · Date : 2026-10-21 · Domaine 4 de l'examen : Gérer et surveiller la posture de sécurité (20 à 25 %)

En une phrase : Defender for Cloud évalue en continu la configuration de tout ce qui est connecté (Azure, AWS, GCP, serveurs locaux, dépôts de code), classe les faiblesses par le risque réel qu'elles font courir, protège chaque charge de travail par un plan dédié, et vous laisse réagir automatiquement ou exporter vers le SOC ; Defender EASM complète cette vue « de l'intérieur » par une vue « de l'extérieur », celle de l'attaquant.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500 en anglais :

La DevOps security (section 6) n'est pas une compétence à part, mais elle fait partie de la CSPM et revient dans les questions sur les attack paths et l'IaC.

Lien avec les autres chapitres : la conformité réglementaire, les normes, les recommandations et les exemptions sont détaillées au chapitre 03 (section 3) ; ici on rappelle l'essentiel puis on va plus loin. Chaque plan de protection est détaillé dans le chapitre de sa ressource (tableau en 4.1).

1. Les bases à maîtriser avant tout#

1.1 Une CNAPP : trois piliers, plus la sécurité de l'IA#

Defender for Cloud est une CNAPP (Cloud Native Application Protection Platform) qui réunit trois composants :

S'y ajoutent l'AI security posture management (AI-SPM, dans Defender CSPM) et la protection contre les menaces pour l'IA (plan AI services), traitées au chapitre 07.

Règle d'or : activer Defender for Cloud sur un abonnement donne gratuitement la Foundational CSPM. Tout le reste (Defender CSPM, plans CWPP) s'active plan par plan et se paie.

1.2 Deux portails#

Defender for Cloud s'étend progressivement au portail Microsoft Defender (security.microsoft.com) : certaines fonctionnalités y sont déjà, d'autres arrivent. La documentation indique en haut de chaque article à quel portail elle s'applique.

1.3 Qui peut faire quoi#

Defender for Cloud s'appuie sur Azure RBAC. Deux rôles lui sont propres : Security Reader (lecture seule) et Security Admin (lecture + modifier les stratégies, ignorer les alertes et les recommandations).

Piège : Security Admin, Contributor et Owner peuvent tous activer un plan, mais il faut Owner pour activer toutes les fonctionnalités d'un plan (certains composants déploient des extensions et créent des managed identities qui reçoivent des rôles).

Pour configurer automatiquement les agents et extensions, Defender for Cloud utilise la correction Azure Policy (DeployIfNotExists) et crée des managed identities qui reçoivent des rôles au niveau de l'abonnement (par exemple pour Defender pour les conteneurs : Kubernetes Extension Contributor, Azure Kubernetes Service Contributor Role, Log Analytics Contributor).

1.4 Comment les données sont collectées#

À savoir : le Log Analytics agent (MMA) a été retiré en août 2024. Les fonctionnalités qui en dépendaient passent par l'intégration de MDE ou par l'agentless scanning.

2. Identifier les risques avec Defender CSPM#

2.1 Foundational CSPM ou Defender CSPM#

Facturation de Defender CSPM : sur des ressources précises seulement. Dans Azure : VM et Virtual Machine Scale Sets (sauf désallouées et VM Databricks), storage accounts (avec conteneurs blob ou partages de fichiers), serveurs SQL, PostgreSQL et MySQL serveurs flexibles, workspaces Synapse ; depuis 2026, Function Apps et Web Apps (protection sans serveur, 1er avril 2026) et Container Apps / Container Instances (conteneurs sans serveur, 1er juillet 2026), une fois ces composants activés. Dans AWS : EC2, S3, RDS (et Lambda, ECS sur Fargate) ; dans GCP : instances de calcul, compartiments de stockage, Cloud SQL.

2.2 Le Secure Score classique (portail Azure)#

Le Secure Score (Secure Score) résume la posture en un pourcentage : plus il est haut, plus le risque identifié est faible.

• Seules les recommandations intégrées du MCSB comptent ; les recommandations en préversion ne comptent pas (elles compteront à leur disponibilité générale).
• La risk prioritization n'affecte pas le Secure Score.
• Depuis le 30 juin 2026, plus de 200 recommandations AWS et GCP comptent aussi : un changement de score peut venir d'un périmètre évalué plus large, pas d'une dégradation.
• Les recommandations sont regroupées en security controls ; chaque contrôle est calculé toutes les 8 heures par abonnement ou connecteur.

flowchart LR
    A["Recommandations MCSB (GA)"] --> B["Regroupées en contrôles<br/>score maximal fixe par contrôle"]
    B --> C["Score d'un contrôle =<br/>score max ÷ (saines + non saines) × saines"]
    C --> D["Score de l'abonnement =<br/>somme des contrôles ÷ somme des max"]
    D --> E["Plusieurs abonnements :<br/>moyenne pondérée par le nombre de ressources"]

Exemple de la documentation : un contrôle à 6 points, 78 ressources évaluées dont 4 saines → 6 ÷ 78 × 4 ≈ 0,31 point. On n'obtient tous les points d'un contrôle qu'en corrigeant toutes ses recommandations sur toutes les ressources.

Les contrôles à connaître (score maximal) :

Améliorer le score : Fix les recommandations, ou Enforce (stratégie DeployIfNotExists) et Deny pour que les nouvelles ressources naissent conformes (chapitre 03).

Suivre le score : tuile de la vue d'ensemble, page dédiée (par abonnement et par management group), API Secure Scores et Secure Score Controls, workbook « Secure score over time », Power BI, et Azure Resource Graph :

// Degré de sécurisation de chaque abonnement
SecurityResources
| where type == 'microsoft.security/securescores'
| extend current = properties.score.current, max = todouble(properties.score.max)
| project subscriptionId, current, max, percentage = ((current / max)*100)

// État de chaque contrôle : ressources non saines, score actuel et maximal
SecurityResources
| where type == 'microsoft.security/securescores/securescorecontrols'
| extend SecureControl = properties.displayName, unhealthy = properties.unhealthyResourceCount,
         currentscore = properties.score.current, maxscore = properties.score.max
| project SecureControl, unhealthy, currentscore, maxscore

2.3 Le Cloud Secure Score fondé sur le risque (portail Defender)#

Un second modèle, totalement différent (autre calcul, autres valeurs) : le Cloud Secure Score de 0 à 100, dans le portail Defender (Exposure management > Initiatives > Cloud Security). Pour chaque ressource, il fait une moyenne pondérée du niveau de risque de ses recommandations ouvertes, en tenant compte de ses facteurs de risque (exposition à Internet, sensibilité des données…) et de sa criticité pour l'organisation. Pour l'améliorer : corriger d'abord les recommandations à risque élevé ou critique.

2.4 La risk prioritization et les critical assets#

Avec Defender CSPM, chaque recommandation reçoit un niveau de risque calculé à partir du contexte : Critique, Élevé, Moyen, Faible, ou Non évalué (ressource non couverte par Defender CSPM). Les facteurs de risque :

• Exposition à Internet : la ressource est-elle accessible depuis Internet ?
• Sensibilité des données : contient-elle des données sensibles ?
• Mouvement latéral : peut-on rebondir d'elle vers d'autres ressources ?
• Attack paths : le problème fait-il partie d'un attack path ?

Sans Defender CSPM, les colonnes de risque apparaissent floutées.

La critical assets protection (Defender CSPM, disponibilité générale) marque automatiquement les « joyaux de la couronne » par des classification rules prédéfinies ou personnalisées ; ces règles sont synchronisées dans les deux sens avec Microsoft Security Exposure Management. Rôles Entra : Security Operator ou plus pour créer ou modifier les règles, Global Reader ou Security Reader pour les lire.

2.5 Le cloud security graph et les attack paths#

Le cloud security graph est le moteur de contexte de Defender for Cloud : inventaire, connexions réseau, possibilités de mouvement latéral, exposition à Internet, autorisations, vulnérabilités, données… de tout l'environnement multicloud.

Un attack path est une suite d'étapes qu'un attaquant pourrait suivre : il part d'un point d'entrée externe (ressource vulnérable exposée à Internet), suit le mouvement latéral (identités avec des autorisations sur d'autres ressources) et atteint une cible critique (base de données sensible…). L'analyse ne retient que des faiblesses réelles et exploitables, vérifiées par des analyses d'accessibilité depuis l'extérieur, pour réduire les faux positifs. Chaque client voit ses propres chemins.

Prérequis : Defender CSPM, plus l'agentless scanning des VM ou l'évaluation des vulnérabilités de Defender for Servers. Accès : Defender for Cloud > Attack path analysis. L'analyse couvre aussi stockage, conteneurs, sans serveur, dépôts non protégés, API non gérées et agents d'IA.

2.6 Le Cloud Security Explorer#

Le Cloud Security Explorer permet d'interroger soi-même le graphe (requêtes de recherche de chemins) pour chasser les risques propres à l'organisation : « VM exposées à Internet avec une vulnérabilité critique et une identité qui a accès à un compte de stockage », etc.

• Générateur de requêtes multicloud et multiressource (listes déroulantes, filtres, sous-filtres), modèles de requêtes prêts à l'emploi, lien de partage, export CSV.
• Données publiées en instantanés actualisés chaque jour.
• Prérequis : Defender CSPM et l'agentless scanning (plus Accès à l'API K8S et Accès au registre pour la posture des conteneurs). Avec seulement Defender for Servers Plan 2, on peut interroger les clés et secrets, mais l'explorateur complet exige Defender CSPM.
• Rôles : Security Reader, Security Admin, Reader, Contributor ou Owner.

2.7 L'Internet exposure analysis#

• Internet Exposure Width : pour les VM Azure, EC2 et instances GCP, Defender for Cloud classe l'exposition en large ou étroite selon les règles réseau ; les attack paths l'indiquent dans leur titre et l'explorateur peut la filtrer.
• Trusted Exposure (préversion) : déclarer par Azure Policy des plages d'IP de confiance (scanners internes, VPN…) ; une VM exposée seulement à ces IP n'est plus considérée comme exposée : pas d'attack path, recommandation dépriorisée.
• Validation de l'extérieur grâce à l'intégration Defender EASM (incluse dans Defender CSPM, sans licence EASM) : découverte de toutes les ressources cloud accessibles depuis Internet, attack paths partant des IP exposées, et dans l'explorateur la condition DEASM Findings (8).

2.8 L'agentless scanning et la secrets scanning#

L'agentless machine scanning n'installe rien, ne demande aucune connectivité réseau et n'affecte pas les performances :

1. Defender for Cloud prend un instantané des disques (OS et données), qui reste dans la même région que la VM.
2. Il analyse la configuration du système et le système de fichiers dans un environnement régional, isolé, volatil et sécurisé.
3. Il supprime l'instantané dès les métadonnées extraites (en général quelques minutes) et envoie les métadonnées aux moteurs : Defender Vulnerability Management (vulnérabilités, software inventory), secrets scanning en clair, antivirus Microsoft Defender (malwares), vérification de l'EDR.
4. Les résultats sans agent et avec agent sont consolidés.

La secrets scanning sans agent repère les identifiants en clair sur les disques ; les secrets trouvés alimentent les recommandations (Secrets exposés) et les attack paths (un secret sur une VM exposée qui ouvre l'accès à une autre ressource).

2.9 La gouvernance : un propriétaire et une échéance pour chaque recommandation#

Les governance rules (Defender CSPM) attribuent automatiquement un propriétaire et une date d'échéance aux recommandations, pour créer un engagement de correction (SLA).

Le governance report (workbook) montre, par règle et par propriétaire, ce qui est dans les délais, en retard ou non attribué.

sequenceDiagram
    participant R as Governance rule (priorité 1)
    participant D as Defender for Cloud
    actor P as propriétaire (étiquette Owner)
    actor M as Son responsable
    D->>R: Nouvelle recommandation de gravité élevée
    R->>D: Owner = étiquette Owner · échéance J+14 · période de grâce
    D->>P: E-mail hebdomadaire : tâches ouvertes et en retard
    Note over D: À J+14, la recommandation passe « en retard »<br/>et compte de nouveau dans le score
    D->>M: E-mail : recommandations en retard

2.10 Réagir et exporter : automatisation, continuous export, portail Defender#

Workflow automation : déclenche une Logic App de type Consumption (Azure Logic Apps) sur trois déclencheurs :

• une recommandation Defender for Cloud est créée ou déclenchée ;
• une alerte est créée ou déclenchée (filtrable par gravité) ;
• une regulatory compliance assessment est créée ou déclenchée.

Continuous export : vers un Log Analytics workspace ou un Event Hubs (puis SIEM tiers), y compris dans un autre abonnement ou un autre locataire.

// Vérifier que l'export continu arrive dans l'espace de travail
SecurityAlert
| where TimeGenerated > ago(1d)
| summarize count() by AlertSeverity

Intégration au portail Defender (XDR) : toutes les alertes et tous les incidents Defender for Cloud (y compris multicloud) arrivent dans le portail Defender, corrélés avec les points de terminaison, identités, e-mails, sans doublon. La chasse avancée dispose des tables CloudAuditEvents (plan de contrôle ARM et Kubernetes), CloudProcessEvents, CloudStorageAggregatedEvents, et l'API Defender XDR exporte tout par une seule API.

Pièges : les alertes informatives ne remontent pas dans le portail Defender ; la visibilité y est à l'échelle du locataire (filtrer par ID d'abonnement) ; il faut un rôle Defender XDR Unified RBAC pour Defender for Cloud, sinon Global Administrator ou Security Administrator Entra.

flowchart TD
    Q{"Besoin ?"} -->|"Réagir à un événement :<br/>e-mail, Teams, ticket, correction"| W["Workflow automation<br/>(Logic App (Consumption))"]
    Q -->|"Analyser, corréler, alerter<br/>dans Azure Monitor ou Sentinel"| L["Continuous export<br/>vers Log Analytics"]
    Q -->|"Envoyer vers un SIEM tiers"| E["Continuous export vers Event Hubs<br/>ou API Defender XDR"]
    Q -->|"Enquêter avec les autres signaux<br/>(postes, identités, e-mails)"| X["Portail Defender (XDR)"]
    Q -->|"Rapport ponctuel"| C["Téléchargement CSV"]

3. Évaluer la conformité aux frameworks de sécurité#

3.1 L'essentiel (détails au chapitre 03)#

Rappel du chapitre 03 : une security policy contient des normes ; une norme est faite de contrôles, qui regroupent des recommandations. Le Microsoft Cloud Security Benchmark (MCSB) est activé par défaut. Les regulatory standards (ISO 27001:2022, PCI DSS v4.0.1, NIST SP 800-53, NIST CSF v2.0, CIS, RGPD, NIS2, SOC 2, HITRUST…) :

• exigent n'importe quel plan Defender payant, sauf Defender for Servers Plan 1 et Defender for APIs Plan 1 (page « Affecter des normes de conformité réglementaire », même formulation qu'au chapitre 03) ; Defender CSPM, par exemple, convient pour Azure, AWS et GCP ;
• s'ajoutent avec le rôle Owner ou Policy Contributor ;
• se consultent avec le rôle Reader de l'abonnement : le Security Reader n'a pas accès aux données de conformité des stratégies (piège d'examen).

Une norme sans ressource évaluée n'apparaît pas dans le tableau de bord ; pour AWS et GCP, les données de conformité sont rafraîchies toutes les 4 heures.

3.2 Aller plus loin : multicloud, normes personnalisées, rapports#

• Multicloud : on affecte les normes au compte AWS ou au projet GCP (via le connecteur), comme à un abonnement. Choisir l'étendue la plus haute possible pour agréger.
• Custom standards : regroupent des recommandations intégrées ou personnalisées. Les custom recommendations en KQL sont disponibles pour tous les clouds avec Defender CSPM ; elles apparaissent avec les intégrées dans le tableau de bord de conformité (créer une norme : Owner ; une recommandation : Security Admin).
• Rapports : téléchargement de rapports d'audit par norme, workbook de conformité dans le temps, workbook de couverture (quels plans sont activés où), remontée dans Microsoft Purview Compliance Manager.
• Automatiser : déclencheur « regulatory compliance assessment » du workflow automation, continuous export du type Conformité réglementaire.
• Conformité ≠ score : le Secure Score ne repose que sur le MCSB ; une norme réglementaire n'y ajoute pas de points.

4. Activer et configurer les plans de protection des charges de travail#

4.1 La carte de tous les plans#

Alertes : seuls les plans CWPP produisent des alertes de sécurité ; la CSPM (même Defender CSPM) produit des recommandations et des attack paths, pas d'alertes.

4.2 Activer un plan#

Portail : Defender for Cloud > Environment settings > choisir l'abonnement (ou le connecteur AWS / GCP) > Defender plans > passer le plan à On > Settings du plan pour ses composants > Save.

PowerShell (exemples tirés de la documentation) :

# Defender pour serveurs Plan 2 sur l'abonnement courant
Set-AzSecurityPricing -Name "VirtualMachines" -PricingTier "Standard" -SubPlan P2

# Defender CSPM avec certains composants
Set-AzSecurityPricing -Name "CloudPosture" -PricingTier "Standard" -Extension '[{"name":"SensitiveDataDiscovery","isEnabled":"True","additionalExtensionProperties":null},{"name":"AgentlessVmScanning","isEnabled":"True","additionalExtensionProperties":null}]'

Azure CLI (exemples de la référence az security pricing) :

# Activer un plan par son nom (VirtualMachines, StorageAccounts, CloudPosture, KeyVaults, Containers…)
az security pricing create -n VirtualMachines --tier standard --subplan P2
# Repasser un plan en gratuit, puis lister l'état de tous les plans
az security pricing create -n StorageAccounts --tier free
az security pricing list

API REST, par machine (Defender for Servers Plan 1 seulement) :

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{machineName}/providers/Microsoft.Security/pricings/virtualMachines?api-version=2024-01-01

{ "properties": { "pricingTier": "Standard", "subPlan": "P1" } }

Terraform (fournisseur azurerm) :

# Defender pour serveurs Plan 2 sur l'abonnement du fournisseur
resource "azurerm_security_center_subscription_pricing" "defender_serveurs" {
  tier          = "Standard"
  resource_type = "VirtualMachines"
  subplan       = "P2"
}

Avec Terraform, resource_type prend les mêmes noms (CloudPosture, KeyVaults, Containers, AI…) et des blocs extension activent les composants ; supprimer la ressource remet le plan en gratuit, et passer en Standard touche toutes les ressources du type dans l'abonnement.

À grande échelle : Azure Policy (initiatives de configuration de Defender for Cloud) affectée au management group.

4.3 Paramètres et surveillance : les composants#

Dans Settings d'un plan (Settings & monitoring, Monitoring coverage), on active ses composants ; Defender for Cloud les déploie sur les ressources existantes et futures par des stratégies DeployIfNotExists.

4.4 Defender for Servers : Plan 1 ou Plan 2#

Après activation : essai de 30 jours (impossible à arrêter, suspendre ou prolonger), MDE installé automatiquement, MDVM activé par défaut, agentless scanning activée par défaut avec P2. Microsoft Defender Experts for Servers (service managé de détection et réponse) est vendu à part et demande P1 ou P2.

4.5 Les alertes et les incidents de sécurité#

• Les alertes restent visibles 90 jours (même si la ressource est supprimée), sont associées à la matrice MITRE ATT&CK, exportables en CSV, par continuous export ou par le connecteur Microsoft Sentinel.
• Un incident regroupe des alertes liées (corrélation par IA) pour montrer une attaque en entier.
• Suppression rules : rejettent automatiquement (état Dismissed) les alertes attendues ou non pertinentes. Création et suppression : Security Admin ou Owner ; lecture : Security Reader ou Reader. Conditions sur le type d'alerte et les entités, date d'expiration, bouton Simulate. Supprimer une règle ne change pas l'état des alertes déjà ignorées.
• Alertes d'exemple : page Security alerts > Sample alerts (rôle Contributor de l'abonnement) pour valider la chaîne (SIEM, automatisation, e-mails) ; elles portent sur des ressources simulées. On peut aussi simuler de vraies détections (fichier EICAR sur une VM, URL /This_Will_Generate_ASC_Alert sur App Service, outil de simulation Kubernetes).

5. Connecter AWS, GCP et les machines locales#

5.1 Le principe d'un connecteur#

Un security connector est une ressource Azure créée dans un abonnement, un resource group et un emplacement choisis. Il s'authentifie auprès d'AWS ou de GCP par identity federation avec une application Microsoft Entra gérée par Microsoft : aucun secret de longue durée n'est stocké, seulement des identifiants temporaires.

• Intervalle d'analyse : 4, 6, 12 ou 24 heures (certains collecteurs ont un intervalle fixe, par exemple 1 heure pour les instances de calcul GCP).
• Type d'accès : Default access (autorisations des fonctionnalités actuelles et futures) ou Least privilege access (seulement ce qui est requis aujourd'hui).
• Prérequis communs : Defender for Cloud activé sur l'abonnement, rôle Contributor sur l'abonnement Azure ; pour la CIEM dans Defender CSPM, Security Administrator (Entra) et l'autorisation Application.ReadWrite.All sur le locataire.
• Les recommandations apparaissent au bout de quelques heures ; la Foundational CSPM s'applique tout de suite (gratuite), les autres plans se choisissent à l'étape Select plans.
• État du connecteur : Environment settings > colonne Connectivity status (problèmes et étapes de correction).
• Bonne pratique : pas plus de 10 000 ressources par vue du portail Azure : répartir les grands environnements sur plusieurs abonnements (ne s'applique pas au portail Defender).

5.2 AWS#

sequenceDiagram
    participant C as Connecteur Defender for Cloud
    participant E as Microsoft Entra ID<br/>(application gérée par Microsoft)
    participant S as AWS STS
    participant R as Rôle IAM (ex. CspmMonitorAws)
    C->>E: Demande un jeton
    E-->>C: Jeton signé par Entra ID
    C->>S: AssumeRoleWithWebIdentity (jeton Entra)
    Note over S: Vérifie l'audience, la signature,<br/>l'empreinte du certificat, les conditions du rôle
    S-->>C: Identifiants temporaires
    C->>R: Appels d'API en lecture seule (posture)

Les serveurs Arc correspondant à des instances EC2 ou VM GCP qui n'existent plus (ou déconnectés, expirés) sont supprimés après 7 jours.

5.3 GCP#

5.4 Les machines locales et les autres clouds : Azure Arc#

Les serveurs locaux (et ceux d'autres clouds) se connectent par Azure Arc : une fois Arc installé, la machine est une ressource Azure ; la Foundational CSPM l'évalue (inventaire, recommandations, Secure Score, automatisation) et Defender for Servers la protège comme une VM Azure (MDE, vulnérabilités, mises à jour, bases de référence). Le JIT, lui, n'existe que pour Azure et AWS.

5.5 Voir la couverture#

Le coverage workbook montre quels plans sont activés sur quels abonnements, comptes et projets ; la page Security posture filtre par environnement (Azure, AWS, GCP, Azure DevOps) et descend jusqu'au compte ou au projet.

6. La DevOps security : du code au cloud#

7. Defender Vulnerability Management pour les VM Azure#

7.1 Le scanner intégré#

L'analyse des vulnérabilités de Defender for Servers utilise Microsoft Defender Vulnerability Management (MDVM), intégré en natif avec Microsoft Defender for Endpoint. Elle couvre les VM Azure, les machines AWS et GCP connectées et les machines locales Arc, avec deux méthodes :

flowchart TD
    A["Agentless scanning activée ?"] -->|Non| B["Résultats de l'agent MDE<br/>(si présent)"]
    A -->|Oui| C{"Quelle solution sur la VM ?"}
    C -->|"Aucune solution avec agent"| D["Agentless scanning automatique<br/>avec MDVM"]
    C -->|"Capteur MDE présent"| E["Vue unifiée : une seule méthode → ses résultats<br/>les deux → résultats de l'agent (plus frais)"]
    C -->|"Solution BYOL partenaire"| F["Résultats du partenaire par défaut<br/>sans agent pour les machines non couvertes"]

7.2 Configurer les paramètres#

1. Defender for Cloud > Environment settings > l'abonnement.
2. Offre Defender for Servers > Monitoring coverage > Settings.
3. Activer Vulnerability assessment for machines, puis Edit configuration pour choisir la solution (Microsoft Defender Vulnerability Management).
4. Apply > Save.

L'analyse est activée par défaut avec Defender for Servers ; cette procédure sert quand on doit l'activer soi-même ou forcer l'affichage des résultats MDVM à la place d'une solution partenaire.

Activer ou désactiver par l'API REST, pour une VM :

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Compute/virtualMachines/{vmName}/providers/Microsoft.Security/serverVulnerabilityAssessments/mdetvm?api-version=2015-06-01-preview

(DELETE sur la même URL pour désactiver.)

7.3 Lire et exploiter les résultats#

• Recommandations individuelles : depuis le 31 juillet 2026, les anciennes recommandations groupées (« Les machines doivent avoir des résultats de vulnérabilités résolus », avec des sous-évaluations) sont retirées. Chaque résultat est une recommandation individuelle (une par mise à jour logicielle), rangée dans une catégorie : SoftwareUpdate (vulnérabilités), SystemUpdate, HostMisconfigurations (bases de référence), ExposedSecrets. Les governance rules, les exemptions et le continuous export ciblent désormais une catégorie ; les requêtes Resource Graph lisent microsoft.security/assessments filtré sur properties.metadata.recommendationCategory. Software inventory dans l'asset inventory.
• Portail Defender : Exposure management > Vulnerability management > Vue d'ensemble > Cloud (principales CVE, recommandations, ressources vulnérables), hiérarchisation selon le contexte et les attack paths.
• Fonctionnalités Premium (incluses dans Servers P2, visibles dans le portail Defender) : évaluation des certificats, évaluation des bases de référence de sécurité, blocage des applications vulnérables…
• Fréquences : interprétation des mises à jour système toutes les 12 heures ; nouvelles données recherchées environ toutes les heures. « Données d'analyse manquantes » : machine arrêtée ou données pas encore remontées (environ une heure après l'activation).
• MDVM trouve les vulnérabilités de la machine elle-même, pas les vulnérabilités réseau.

7.4 Les scanners tiers (BYOL)#

Qualys et Rapid7 sont pris en charge en BYOL (votre propre licence, VM Azure seulement, aucun plan payant requis, un seul scanner BYOL à la fois, rôle Owner de la ressource pour déployer). Cette capacité est en dépréciation : la page annonce l'arrêt des nouveaux ajouts au 3 février et la fin complète au 1er mai (sans préciser l'année). Remplacement : MDVM ou un data connector de Microsoft Security Exposure Management (Tenable, Qualys, Rapid7…).

8. Defender EASM : la surface d'attaque vue de l'extérieur#

8.1 Deux façons d'utiliser EASM#

EASM ne prend pas en charge l'accès inter-locataires, même par Azure Lighthouse : il faut s'authentifier dans le locataire de la ressource. Les données client sont stockées dans la région choisie.

8.2 La découverte#

EASM part d'actifs connus (seeds) et cherche récursivement l'infrastructure qui leur est liée :

• Seeds acceptées : noms d'organisation, domaines, blocs d'IP, hôtes, contacts e-mail, ASN, organisations Whois ; pas d'IP privée (EASM regarde de l'extérieur).
• Relations suivies : enregistrements Whois (même contact, même organisation, même serveur de noms), DNS (hôtes, IP, serveurs de messagerie), certificats SSL partagés, ASN des blocs d'IP.
• Démarrage : Getting Started > rechercher son organisation dans les prebuilt attack surfaces > Build my Attack Surface (recommandé avant toute découverte personnalisée).
• Discovery groups : un ensemble de seeds, avec une récurrence (hebdomadaire par défaut, recommandée ; Jamais pour une exécution unique) et des exclusions (filiales non détenues, par exemple). On les organise par équipe, marque ou filiale.

8.3 L'inventaire et les états des actifs#

Types d'actifs : ASN, contact, domaine, hôte, adresse IP, bloc d'IP, page, certificat SSL, classés récents ou historiques.

flowchart LR
    A["Actif découvert"] --> B{"Lien fort avec une seed ?"}
    B -->|Oui| C["Approved"]
    B -->|"Lien faible"| D["Candidate"]
    B -->|"Confiance faible"| E["Requires Investigation"]
    D --> F{"Revue manuelle"}
    E --> F
    F -->|"Il nous appartient"| C
    F -->|"Tiers qui nous sert"| G["Dependency"]
    F -->|"Lié, non contrôlé"| H["Monitor Only"]
    F -->|"Sans rapport"| I["Ignoré ou archivé"]

Actions sur l'inventaire : changer l'état, poser des étiquettes (fusion-acquisition, conformité, unité métier…), un ID externe, marquer une observation (CVE) comme non applicable. Par défaut, l'inventaire n'affiche que l'état Approved.

Facturation : seuls les actifs Approved comptent : combinaisons hôte:IP (résolues dans les 30 derniers jours, sans doublons), domaines (hors ceux déjà comptés via un hôte), adresses IP actives (port ouvert ou certificat SSL récent, hors celles déjà comptées via un hôte). Tableau de bord Billable assets dans la ressource.

8.4 Les tableaux de bord et l'export#

Huit tableaux de bord, calculés sur l'inventaire Approved :

Data connections : envoi des données d'actifs et/ou des insights vers Log Analytics (même locataire, pour Microsoft Sentinel) ou Azure Data Explorer ; seuls les actifs Approved sont exportés ; coût selon la plateforme cible. EASM s'intègre aussi à Security Copilot (résumé de la surface, priorités, curation en langage naturel) et à Security Exposure Management (initiative EASM).

9. Compléments AZ-500 et culture#

9.1 Microsoft Security Exposure Management#

Security Exposure Management (portail Defender, cloud public uniquement) unifie la posture des points de terminaison, du cloud (Azure, AWS, GCP via Defender for Cloud), des identités et de la surface externe :

• exposure graph de l'entreprise et attack surface map, interrogeables ;
• critical assets sur tous les domaines ;
• attack paths, y compris hybrides (du local vers le cloud), choke points, rayon d'action ;
• initiatives et métriques (Code, Endpoint, Cloud, Identity, SaaS), tableau Resolve Now / Monitor Exposure ;
• data connectors tiers (ServiceNow CMDB, Tenable, Qualys, Rapid7, Wiz, Prisma…), qui remplacent les scanners BYOL.

9.2 Defender for Resource Manager et Defender for DNS#

• Defender for Resource Manager surveille automatiquement les opérations de gestion (plan de contrôle ARM) et alerte sur les activités inhabituelles ou dangereuses.
• Defender for DNS surveille les requêtes vers les résolveurs DNS par défaut d'Azure ; pour les nouveaux abonnements depuis le 1er août 2023, ses alertes sont incluses dans Servers P2.

9.3 Questions d'architecture fréquentes#

• Un ou plusieurs workspaces pour l'export ? Le continuous export accepte une cible dans un autre abonnement, voire un autre locataire : un workspace central du SOC est le schéma habituel.
• Où mettre les connecteurs AWS et GCP ? Dans un abonnement dédié à la sécurité, en répartissant au-delà de 10 000 ressources.

10. Labs conseillés#

Dans un abonnement de test (les plans payants ont un essai de 30 jours ; les désactiver à la fin).

Lab 1 · Secure Score et correction

1. Activer Defender for Cloud (Foundational CSPM) sur l'abonnement, créer une VM avec le RDP ouvert à Internet et un storage account avec l'accès public.
2. Attendre l'évaluation (quelques heures), ouvrir Recommendations et repérer celles de la VM et du stockage.
3. Corriger une recommandation avec Fix, puis une autre en affectant une stratégie Deny (chapitre 03).
4. Résultat attendu : le contrôle concerné remonte dans le Secure Score au recalcul suivant (8 h).

Lab 2 · Defender CSPM, attack path et explorateur

1. Activer Defender CSPM (en Owner, sinon l'agentless scanning n'est pas activée).
2. Garder la VM exposée de l'étape 1, lui donner une managed identity avec un rôle sur le storage account.
3. Le lendemain, ouvrir Attack path analysis et le Cloud Security Explorer (modèle « VM exposées à Internet »).
4. Résultat attendu : un chemin « VM exposée → stockage » ou, à défaut, la VM dans le résultat de la requête.

Lab 3 · Plans, alertes et réaction

1. Activer Defender for Servers P2 et Defender for Storage sur l'abonnement.
2. Créer une workflow automation (alerte de gravité élevée → Logic App qui envoie un e-mail) et un continuous export vers un Log Analytics workspace.
3. Générer des sample alerts (page Security alerts).
4. Résultat attendu : l'e-mail arrive et SecurityAlert | take 10 renvoie les alertes d'exemple ; créer ensuite une règle de suppression sur l'une d'elles et la simuler.

Lab 4 · Conformité et gouvernance

1. Ajouter la norme ISO 27001:2022 (Environment settings > Security policies).
2. Ouvrir Regulatory compliance et télécharger le rapport.
3. Créer une governance rule : gravité élevée, propriétaire par étiquette Owner, échéance 14 jours.
4. Résultat attendu : la norme apparaît avec ses contrôles, et les recommandations élevées portent un propriétaire et une échéance.

Lab 5 · EASM (facultatif)

1. Créer une ressource Defender EASM (essai de 30 jours) et lancer Build my Attack Surface sur un domaine que vous possédez.
2. Résultat attendu : des actifs Candidate à valider, puis les tableaux de bord sur l'inventaire Approved.

11. Les pièges d'examen#

12. Scénarios d'entraînement#

1. Le RSSI veut savoir quelles VM exposées à Internet pourraient mener à un storage account contenant des données sensibles, et quoi corriger en premier. Que mettre en place ?

Activer Defender CSPM avec l'agentless scanning (et la découverte des données sensibles), puis consulter l'analyse du attack path ; les recommandations du chemin sont classées par niveau de risque. Pour une recherche libre : Cloud Security Explorer (modèles de requêtes).

2. Contoso a 40 comptes AWS dans une organisation AWS et en crée de nouveaux chaque mois. Comment les évaluer avec le MCSB sans gérer de clé d'accès ?

Créer un connecteur AWS sur le management account (déploiement par StackSet CloudFormation) : les member accounts, actuels et futurs, sont connectés automatiquement. L'authentification passe par OIDC et STS (identifiants temporaires). La CSPM de base applique gratuitement MCSB et AWS Foundational Security Best Practices.

3. L'équipe sécurité veut que chaque recommandation de gravité élevée soit attribuée au propriétaire de la ressource (étiquette Owner), avec 14 jours pour corriger et des rappels. Solution ?

Une governance rule (Defender CSPM) : condition par gravité = élevée, propriétaire par étiquette de ressource Owner, délai 14 jours, notifications hebdomadaires actives (le responsable reçoit les retards). Rôle : Contributor, Administrateur de la sécurité ou Owner.

4. Le SOC utilise Splunk et veut recevoir en temps réel uniquement les alertes de gravité élevée de tous les abonnements. Que configurer ?

Continuous export vers un Event Hubs central (autre abonnement possible), type Security alerts filtré sur la gravité élevée, fréquence diffusion en continu ; à grande échelle par Azure Policy DeployIfNotExists. Alternative : l'API Defender XDR.

5. Une PME veut Defender for Servers sur trois VM de production seulement, sans payer pour les 50 autres de l'abonnement. Possible ?

Oui avec le Plan 1 : l'activer au niveau de la ressource (API Microsoft.Security/pricings/virtualMachines, pricingTier: Standard, subPlan: P1). Le Plan 2 ne s'active qu'au niveau de l'abonnement ; on peut seulement l'y désactiver par ressource.

6. Sur une VM avec Defender for Servers Plan 2, MDE est installé et l'agentless scanning est active. Les deux méthodes trouvent des vulnérabilités. Lesquelles sont affichées ?

Les résultats de l'agent (MDE), plus frais. Une machine qui n'a qu'une seule méthode affiche les résultats de cette méthode ; sans aucun agent, l'agentless scanning MDVM prend le relais automatiquement.

7. Fabrikam a racheté une société et craint des sites web et des IP oubliés. Comment les trouver depuis l'extérieur ?

Defender EASM : partir de la prebuilt attack surface (Build my Attack Surface), puis un discovery group avec les seeds de la société rachetée (domaines, blocs d'IP, ASN, organisations Whois), récurrence hebdomadaire, exclusions pour les entités sans rapport. Revoir d'abord les actifs Requires Investigation et Candidates, les passer en Approved s'ils appartiennent au groupe, puis suivre les tableaux de bord (résumé, OWASP, CISA).

8. Les développeurs introduisent des erreurs de configuration Terraform qui arrivent en production. Comment les leur signaler avant la fusion ?

Connecter GitHub (ou Azure DevOps) à Defender for Cloud (Contributor sur l'abonnement, propriétaire de l'organisation GitHub, installation de l'application), analyser l'IaC, puis activer les pull request annotations (Defender CSPM). Le code-to-cloud mapping relie ensuite une charge de travail exposée à son dépôt.

9. Une alerte « activité suspecte » se déclenche chaque nuit à cause d'un outil d'administration connu. Comment l'arrêter sans désactiver le plan ?

Une suppression rule (Security Admin ou Owner) depuis l'alerte : type d'alerte + condition sur l'entité (machine, processus), raison, date d'expiration, test avec Simulate. Les alertes correspondantes passent à l'état Dismissed.

10. Après avoir branché le continuous export et une Logic App, l'équipe veut vérifier la chaîne sans attendre une vraie attaque. Comment ?

Générer des sample alerts (page Security alerts > Sample alerts, rôle Contributor de l'abonnement, choix des plans) : elles apparaissent en quelques minutes partout où les alertes sont envoyées.

11. Un analyste du SOC doit voir les incidents Defender for Cloud dans le portail Defender, corrélés avec les postes de travail, sans être Global Administrator. Que lui donner ?

Un rôle Defender XDR Unified RBAC couvrant Defender for Cloud (à défaut, Security Administrator Entra). Les alertes y sont visibles à l'échelle du locataire ; filtrer par ID d'abonnement pour un périmètre.

12. Le score de sécurité de l'entreprise baisse le 30 juin 2026 sans aucune modification de l'infrastructure. Pourquoi ?

Depuis cette date, plus de 200 recommandations AWS et GCP comptent dans le Secure Score : le périmètre évalué est plus large. Consulter Afficher les mises à jour sur la carte du score et l'étiquette Nouveau des recommandations.

13. Pour aller plus loin (au-delà de l'examen)#

• Data security posture management (DSPM) de Defender CSPM : découverte automatique des magasins de données sensibles (stockage, bases, S3, RDS…) qui alimente les facteurs de risque « données sensibles ».
• CIEM (Cloud Infrastructure Entitlement Management) : analyse des droits dans Azure, AWS et GCP, enrichie par CloudTrail et Cloud Logging, pour détecter les identités sur-privilégiées (lien avec le chapitre 03).
• Intégration ServiceNow (préversion) : tickets automatiques pour les recommandations.
• Cost calculator Defender for Cloud pour estimer un déploiement multicloud avant de l'activer.
• Defender Experts for Servers : détection et réponse managées par Microsoft, chasse proactive, Ask Defender Experts.
• Workbooks : couverture, conformité dans le temps, gouvernance, DevOps security ; à brancher sur un tableau de bord de direction.

14. Fiche à retenir#

• CNAPP = CSPM (posture) + CWPP (menaces, alertes) + DevSecOps (code) ; la Foundational CSPM est gratuite et automatique.
• Defender CSPM : graphe, attack paths, explorateur, risque, gouvernance, sans agent, conformité réglementaire, recommandations KQL, EASM intégrée, DSPM, IA, API.
• Secure Score classique : MCSB GA uniquement, préversions exclues, contrôles recalculés toutes les 8 h, le risque ne compte pas ; AWS et GCP comptent depuis le 30/06/2026.
• Contrôles phares : MFA = 10 points, ports de gestion = 8.
• Cloud Secure Score (portail Defender) : 0 à 100, intègre facteurs de risque et criticité.
• Attack path : point d'entrée externe → mouvement latéral → cible critique ; prérequis Defender CSPM + sans agent ou évaluation des vulnérabilités.
• Sans agent : instantané dans la même région, analysé puis supprimé ; rôle VM Scanner Operator ; malwares = Servers P2.
• Gouvernance : priorité 1 à 1000, échéances 7/14/30/90 jours, période de grâce, e-mails hebdomadaires.
• Normes réglementaires : un plan payant hors Servers P1 / API P1 seuls ; ajout par Owner ou Policy Contributor ; lecture par Reader (pas Security Reader).
• Recommandations individuelles depuis le 31/07/2026 : gouvernance, exemptions et export ciblent une catégorie (SoftwareUpdate, SystemUpdate, HostMisconfigurations, ExposedSecrets).
• Automatisation = Logic App (Consumption) (alerte, recommandation, conformité) ; continuous export = Log Analytics (SecurityAlert, SecurityRecommendation) ou Event Hubs, diffusion ou instantanés hebdomadaires.
• Rôles : Security Reader (voir), Security Admin (stratégies, ignorer, exempter) ; activer un plan : Security Admin, Contributor, Owner ; toutes les fonctionnalités : Owner.
• Serveurs : P1 = MDE, EDR, vulnérabilités avec agent, activable par ressource ; P2 = + sans agent, FIM, JIT, DNS, Premium MDVM, 500 Mo gratuits ; essai 30 jours.
• Alertes : Élevée, Moyenne, Faible, Informative ; 90 jours ; suppression rules ; sample alerts.
• AWS : compte unique ou management account ; CloudFormation/StackSet ou Terraform ; OIDC + STS ; serveurs = Arc + SSM.
• GCP : projet ou organisation ; script gcloud ; workload identity pool.
• Intervalle d'analyse des connecteurs : 4, 6, 12 ou 24 h ; accès par défaut ou privilège minimum.
• DevOps : GitHub, Azure DevOps, GitLab ; annotations de PR et code au cloud = Defender CSPM.
• MDVM : intégré à Defender for Servers ; avec agent (P1/P2) ou sans agent (P2) ; les deux → résultats de l'agent ; configurer dans Environment settings > Defender for Servers > Settings ; pas de vulnérabilités réseau ; BYOL en dépréciation.
• EASM : seeds → découverte récursive → Approved / Candidate / Requires Investigation / Dependency / Monitor Only ; seul l'approuvé est analysé chaque jour et facturé ; 8 tableaux de bord ; export Log Analytics ou Data Explorer ; essai 30 jours ; pas d'inter-locataires.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Qu'est-ce que Microsoft Defender for Cloud ?
• Qu'est-ce que la gestion de la posture de sécurité cloud (CSPM)
• Secure Score de Defender for Cloud
• Hiérarchisation des risques
• Recommandations de sécurité : niveaux et facteurs de risque
• Critical assets protection
• Explorateur de sécurité et attack paths
• Créer des requêtes avec l'explorateur de sécurité du cloud
• Internet exposure analysis
• Détecter les adresses IP exposées à Internet
• Agentless machine scanning
• Governance rules
• Automatiser les réponses (workflow automation)
• Configurer le continuous export
• Continuous export : types de données et tables
• Alertes et incidents Defender for Cloud dans Microsoft Defender XDR
• Rôles d'utilisateur et autorisations
• Comment Defender for Cloud collecte des données (composants de surveillance)
• Defender for Servers : plans et fonctionnalités
• Alertes et incidents de sécurité
• Supprimer des alertes (suppression rules)
• Valider les alertes (sample alerts)
• Connecter des comptes AWS
• Architecture d'authentification des connecteurs AWS
• Connecter un projet GCP
• Vue d'ensemble de la DevOps security
• Connecter un environnement GitHub
• Intégration de GitHub Advanced Security
• Configurer l'analyse des vulnérabilités des machines
• Activer l'analyse des vulnérabilités avec Defender Vulnerability Management
• Analyse des vulnérabilités BYOL (dépréciation)
• Questions fréquentes sur Defender for Servers
• Gestion de la surface d'attaque externe dans Defender for Cloud
• Vue d'ensemble de Defender EASM
• Qu'est-ce que la découverte ? (EASM)
• Utiliser et gérer la découverte (EASM)
• Comprendre les actifs de l'inventaire (EASM)
• Comprendre les tableaux de bord (EASM)
• Billable assets (EASM)
• Data connections (EASM)
• Qu'est-ce que Microsoft Security Exposure Management ?
• Data connectors de Security Exposure Management
• Set-AzSecurityPricing (Az.Security)
• az security pricing (Azure CLI)
• Affecter des normes de conformité réglementaire
• Améliorer la conformité réglementaire (tableau de bord)
• Passer des recommandations groupées aux recommandations individuelles
• Protéger les bases de données avec Defender for Databases
• Nouveautés de Defender for Cloud
• Registre Terraform : azurerm_security_center_subscription_pricing (azurerm 5.10.0)