Posture de sécurité Zero Trust avec Copilot Security et Defender for Cloud

En 2026, la question n'est plus de savoir si votre organisation applique le Zero Trust, mais de savoir où elle ne l'applique plus. Un tenant Azure de taille moyenne génère aujourd'hui plusieurs milliers de recommandations de posture actives, réparties sur des centaines d'abonnements, de comptes AWS et de projets GCP, avec un delta quotidien que plus aucune équipe ne lit intégralement. Le résultat est connu de tous les RSSI : un Secure Score qui stagne autour de 55-65 %, des campagnes de remédiation qui traitent les recommandations les plus nombreuses plutôt que les plus dangereuses, et une dérive de configuration qui réintroduit silencieusement des chemins d'attaque que l'on croyait fermés. C'est exactement l'espace que vient occuper l'association copilot security zero trust defender cloud : Microsoft Security Copilot ne produit pas de nouvelles données de posture, il rend exploitable celles que Microsoft Defender for Cloud collecte déjà, en traduisant un graphe de sécurité cloud de plusieurs millions d'arêtes en décisions de remédiation ordonnées par exposition réelle. Cet article détaille l'architecture, les prérequis, les requêtes et les limites opérationnelles de cette combinaison, telles qu'on les rencontre sur des environnements de production réels.

Zero Trust et CSPM : le rôle de Copilot Security dans la posture cloud

Le Zero Trust n'est pas un produit mais un modèle de contrôle : vérification explicite, privilège minimum, présomption de compromission. Sa traduction opérationnelle dans le cloud passe par une mesure continue de la conformité des ressources aux six piliers — identités, points de terminaison, applications, données, infrastructure, réseau. Cette mesure, c'est le CSPM (Cloud Security Posture Management), et dans l'écosystème Microsoft c'est Defender for Cloud qui l'assure.

Du contrôle périmétrique à la vérification continue

Un contrôle Zero Trust n'a de valeur que s'il est évalué en continu. Une machine virtuelle conforme au moment du déploiement peut devenir non conforme quinze minutes plus tard : ouverture d'un groupe de sécurité réseau sur 0.0.0.0/0:3389, désactivation de l'accès juste-à-temps, attribution d'un rôle Contributor à un principal de service applicatif. Defender for Cloud réévalue ses évaluations à intervalle court (de quelques minutes à 24 heures selon le type d'évaluation) et matérialise chaque écart sous la forme d'une ressource Microsoft.Security/assessments interrogeable.

Pourquoi le CSPM classique sature

Le problème n'est pas la détection, il est cognitif. Le Microsoft Cloud Security Benchmark (MCSB) compte plus de 250 contrôles répartis sur douze familles (NS, IM, PA, DP, AM, LT, IR, PV, ES, BR, DS, GS). Multiplié par le nombre de ressources, cela produit un volume de recommandations que la hiérarchisation native — impact sur le score, sévérité Haute/Moyenne/Faible — ne suffit plus à discriminer. Deux recommandations « Haute » sur une même souscription peuvent avoir des conséquences radicalement différentes : l'une porte sur une VM de test isolée, l'autre sur un jump host exposé qui détient une identité managée avec droits sur le coffre de clés de production. La sévérité ne le dit pas ; le graphe, si.

Ce que l'IA générative change dans la boucle de posture

Microsoft Security Copilot intervient à trois endroits précis de cette boucle. D'abord la traduction : convertir une intention formulée en langage naturel (« quelles ressources exposées sur Internet détiennent une identité avec des droits d'écriture sur un compte de stockage contenant des données classifiées ? ») en requête sur le graphe de sécurité cloud. Ensuite la synthèse : agréger 400 recommandations en cinq thèmes de dérive avec leur cause racine probable. Enfin la génération : produire le correctif — commande az, module Bicep, ressource Terraform — plutôt que de décrire la procédure. La documentation officielle décrit ce mécanisme de grounding, où l'invite utilisateur est enrichie par les plug-ins avant d'atteindre le modèle de langage, puis post-traitée avec le contexte organisationnel (documentation Microsoft Security Copilot). C'est ce double passage par les plug-ins qui distingue l'outil d'un assistant généraliste : les réponses sont fondées sur vos données de tenant, pas sur une connaissance générique d'Azure.

Copilot Security dans Defender for Cloud : fonctionnalités et prérequis

L'intégration se déploie sur deux plans distincts qu'il faut provisionner séparément : le plan de données côté Defender for Cloud, et le plan de calcul côté Security Copilot.

Plan Defender CSPM et graphe de sécurité cloud

Le socle fonctionnel s'appelle Defender CSPM, plan payant à activer par abonnement ou par connecteur multicloud. Le CSPM fondamental (gratuit) fournit le Secure Score et les recommandations MCSB, mais pas le graphe. Or l'essentiel de la valeur analytique se trouve dans les capacités du plan payant : analyse sans agent des machines virtuelles (agentless scanning, via snapshot du disque, sans impact sur la charge de production), analyse des chemins d'attaque (attack path analysis), graphe de sécurité cloud interrogeable par l'explorateur de sécurité cloud, analyse sans agent des conteneurs et découverte des secrets machine. Sans Defender CSPM, Security Copilot n'aura accès qu'à la couche recommandations, ce qui réduit son intérêt d'environ deux tiers. Vérifiez l'état du plan avec az security pricing show --name CloudPosture sur chaque abonnement concerné.

Provisionnement des SCU et rôles requis

Security Copilot se facture en SCU (Security Compute Units), unités de calcul provisionnées à l'heure et rattachées à une capacité déployée dans une région Azure. La capacité est une ressource ARM classique : elle se crée, se redimensionne et se supprime, et elle porte un paramètre de géographie de traitement des données qu'il faut aligner avec vos contraintes de résidence — point systématiquement soulevé en comité de sécurité par les organisations soumises au RGPD ou à la doctrine « cloud de confiance ». Le dimensionnement se pilote après coup : commencez bas, observez le tableau de bord d'utilisation pendant deux à trois semaines, ajustez. Une équipe qui n'utilise l'outil que pour la posture consomme structurellement moins qu'une équipe SOC qui l'exécute sur chaque incident. Nous avons détaillé ce modèle de capacité et son dimensionnement dans notre analyse de l'architecture de Copilot Security.

Côté RBAC, deux couches se superposent et c'est la source d'erreur la plus fréquente. Security Copilot possède ses propres rôles (propriétaire et contributeur de la plateforme), mais l'accès aux données reste gouverné par vos permissions Azure existantes : le flux d'authentification est de type on-behalf-of. Un analyste titulaire du rôle Security Reader sur un seul groupe d'administration ne verra jamais les recommandations des autres, quelle que soit la formulation de son invite. Corollaire opérationnel : Security Copilot n'élargit pas la surface d'exposition des données, mais il rend immédiatement visible toute sur-attribution de rôle existante.

Plug-ins et expériences incorporées

L'accès aux données de posture passe par le plug-in Microsoft Defender for Cloud, activable depuis l'expérience autonome. Les plug-ins sont décrits comme des collections d'outils (aussi appelés compétences) que le modèle peut invoquer pour atteindre son résultat (vue d'ensemble des plug-ins). Pour un usage posture, activez conjointement les plug-ins Defender XDR, Microsoft Entra, Microsoft Purview et Threat Intelligence : c'est leur combinaison qui permet le raisonnement transversal identité-données-exposition. Comptez également sur les guides d'invite (promptbooks) : une séquence d'invites versionnée et rejouable, bien plus fiable qu'une invite ad hoc reformulée à chaque comité mensuel de sécurité. Un guide d'invite « revue de posture mensuelle » typique enchaîne : delta de Secure Score, nouveaux chemins d'attaque critiques, ressources non conformes créées dans les 30 derniers jours, top 5 des remédiations par gain de score.

Secure Score automatisé : interprétation et priorisation intelligente

Le Secure Score est un indicateur utile et abondamment mal interprété. Sa mécanique de calcul explique pourquoi.

Anatomie du calcul MCSB

Le score se calcule par contrôle de sécurité, pas par recommandation. Chaque contrôle porte un poids maximal et n'octroie de points qu'au prorata des ressources saines qu'il couvre : un contrôle valant 4 points appliqué à 100 ressources dont 40 sont conformes rapporte 1,6 point. Deux conséquences pratiques. Premièrement, corriger 40 ressources triviales d'un contrôle à faible poids déplace le score davantage que de corriger la seule ressource critique d'un contrôle à poids élevé — d'où des campagnes de remédiation optimisées pour le tableau de bord et non pour le risque. Deuxièmement, le score est un pourcentage : la mise en service d'un nouvel abonnement mal configuré fait mécaniquement chuter la moyenne sans qu'aucune régression réelle ne se soit produite sur le périmètre existant. Toute lecture du score déconnectée de sa décomposition par contrôle est une lecture fausse.

Interroger le score avec Azure Resource Graph

Avant toute invite, il faut savoir ce que l'on interroge. Les données de posture sont exposées dans Azure Resource Graph, table securityresources. Une requête de base pour extraire les évaluations en échec avec leur criticité :

securityresources | where type =~ 'microsoft.security/assessments' | extend statusCode = properties.status.code, sev = properties.metadata.severity, resId = properties.resourceDetails.Id | where statusCode == 'Unhealthy' and sev == 'High' | project subscriptionId, resId, name, displayName = properties.displayName | order by subscriptionId asc

Et pour la décomposition du score par contrôle, la table microsoft.security/securescores/securescorecontrols renvoie current, max et healthyResourceCount. Security Copilot génère ce type de requête à partir d'une intention exprimée en français, ce qui supprime la barrière KQL pour les architectes qui ne pratiquent pas Resource Graph au quotidien — mais relisez systématiquement la requête produite avant de fonder un plan trimestriel dessus.

Invites de priorisation et guides d'invite

Une invite de priorisation efficace contient toujours trois éléments : un périmètre, un critère de risque explicite, un format de sortie. Exemple applicable tel quel : « Sur les abonnements portant l'étiquette env=prod, liste les dix recommandations Defender for Cloud non conformes qui affectent des ressources accessibles depuis Internet et associées à une identité disposant de droits d'écriture. Pour chacune, indique le contrôle MCSB, le nombre de ressources touchées, le gain de Secure Score attendu et l'effort de remédiation estimé. Format tableau. » La différence de qualité entre cette formulation et un « améliore mon Secure Score » est considérable : la seconde produit une paraphrase du portail, la première produit un plan de sprint.

Gap analysis Zero Trust : identifier et corriger les dérives de configuration

Le Secure Score mesure la conformité à un référentiel technique. Le Zero Trust est un modèle de contrôle. Passer de l'un à l'autre demande un travail de mise en correspondance que Security Copilot accélère considérablement.

Mapper MCSB sur les piliers Zero Trust

Les familles MCSB se projettent naturellement sur les piliers : IM (Identity Management) et PA (Privileged Access) sur le pilier identités, NS (Network Security) sur les piliers réseau et infrastructure, DP (Data Protection) sur le pilier données, ES (Endpoint Security) sur les points de terminaison, PV (Posture and Vulnerability Management) transversalement. Demander à Security Copilot de regrouper les recommandations non conformes selon cette projection produit une vue de maturité par pilier bien plus lisible qu'un score global — et directement présentable en comité. C'est aussi cette vue qui révèle les déséquilibres typiques : un pilier infrastructure à 85 % et un pilier données à 30 %, configuration extrêmement fréquente parce que le chiffrement au repos est activé par défaut alors que la classification des données ne l'est jamais.

Détecter la dérive de configuration

La dérive s'attrape par le temps, pas par l'état. Les évaluations portent un horodatage de première détection : isoler les ressources devenues non conformes dans les sept derniers jours permet de distinguer la dette historique de la régression active. Une dérive récente sur un contrôle précédemment conforme signale presque toujours l'une de ces trois causes : un pipeline IaC modifié sans revue, une exception manuelle posée en incident et jamais retirée, ou un nouveau souscripteur hors gouvernance. Security Copilot est bon pour poser cette question de corrélation — « quelles ressources devenues non conformes cette semaine partagent le même groupe de ressources ou le même créateur ? » — en croisant recommandations et journaux d'activité Azure.

Le pilier identité, angle mort du CSPM

C'est la limite structurelle à connaître : Defender for Cloud évalue les permissions sur les ressources cloud (via CIEM, avec des recommandations sur les identités sur-privilégiées et les identités inactives), mais il n'évalue ni les stratégies d'accès conditionnel, ni les méthodes d'authentification, ni les rôles Entra ID privilégiés hors périmètre Azure. Or le pilier identités est celui où le Zero Trust se gagne ou se perd. La couverture complète exige d'activer conjointement le plug-in Microsoft Entra et de croiser les deux sources — démarche que nous détaillons pour la partie détection dans notre article sur l'investigation des identités avec Entra. Point d'attention supplémentaire pour les environnements hybrides : la posture Entra ID ne dit rien de votre Active Directory on-premises, dont les délégations et les chemins de contrôle restent invisibles au CSPM. Un pentest Active Directory demeure la seule méthode fiable pour cartographier cette moitié du pilier identités, en particulier sur les tenants synchronisés où un compte de service AD compromis ouvre l'accès au cloud.

Remédiation priorisée par criticité et exposition réelle

Une liste de recommandations triée par sévérité est un backlog. Une liste triée par exposition réelle est un plan d'action. Le passage de l'une à l'autre est la contribution la plus tangible de l'outillage.

L'analyse des chemins d'attaque plutôt que la liste plate

L'analyse des chemins d'attaque construit, à partir du graphe de sécurité cloud, des séquences exploitables du type : machine virtuelle exposée sur Internet → vulnérabilité critique à exécution de code à distance non corrigée → identité managée attachée → rôle avec droits d'écriture sur un compte de stockage → données étiquetées « Confidentiel ». Chaque chemin porte un point d'entrée, une cible et une liste de nœuds intermédiaires. L'intérêt opérationnel est immédiat : rompre un chemin ne demande pas de corriger tous ses nœuds, mais un seul — généralement le maillon dont la remédiation coûte le moins. Sur les environnements que nous auditons, le rapport typique est de l'ordre de quelques dizaines de chemins critiques pour plusieurs milliers de recommandations non conformes. Ces chemins constituent le vrai backlog Zero Trust ; le reste est de l'hygiène planifiable.

Générer le correctif, pas seulement la procédure

Sur les recommandations à correction déterministe, la génération de code fonctionne bien : bloc network_security_rule Terraform pour refermer un port de gestion, module Bicep pour imposer publicNetworkAccess: 'Disabled' sur un compte de stockage, boucle PowerShell pour activer le chiffrement des disques sur un ensemble de VM, définition Azure Policy en mode DeployIfNotExists pour empêcher la réapparition. La règle que nous imposons en mission est simple : le code généré part en pull request sur le dépôt IaC, jamais en exécution directe sur le portail. Corriger dans le portail une ressource gérée par Terraform garantit la réapparition de l'écart au prochain apply — la remédiation « en un clic » est un piège en environnement IaC.

Gouverner la remédiation dans la durée

Les règles de gouvernance de Defender for Cloud attribuent automatiquement un propriétaire et une échéance aux recommandations selon leur périmètre et leur sévérité, avec notification par courriel et suivi des dépassements. Couplées à un guide d'invite hebdomadaire résumant les échéances dépassées par équipe, elles transforment le CSPM en processus mesurable plutôt qu'en tableau de bord consulté après incident. C'est peu spectaculaire et c'est, dans les faits, ce qui fait bouger le score de manière durable.

Surveiller la posture multi-cloud (Azure, AWS, GCP) avec Copilot

Le multicloud n'est plus une exception : la majorité des organisations que nous accompagnons exploitent au moins deux fournisseurs, généralement Azure et AWS, avec des équipes et des référentiels distincts. C'est précisément la configuration où la posture se dégrade sans que personne ne le voie.

Mécanique des connecteurs

Defender for Cloud s'intègre à AWS et GCP sans agent. Côté AWS, le connecteur repose sur un modèle CloudFormation déployé dans le compte cible (ou sur une StackSet pour les organisations multi-comptes), qui crée les rôles IAM permettant à Defender for Cloud d'assumer un accès en lecture et de déclencher l'analyse sans agent. Côté GCP, l'authentification passe par la fédération d'identité de charge de travail (workload identity federation), sans clé de compte de service à stocker. Dans les deux cas, l'activation du CSPM apporte l'évaluation des référentiels CIS AWS Foundations et CIS GCP Foundations, tandis que le plan Defender CSPM étend le graphe et l'analyse des chemins d'attaque aux ressources de ces clouds. Vérification préalable indispensable : le connecteur doit couvrir l'ensemble des comptes de l'organisation AWS, pas seulement le compte de gestion — l'onboarding partiel est l'erreur la plus commune et il produit un faux sentiment de couverture.

Normaliser le langage entre fournisseurs

La difficulté de la revue multicloud n'est pas technique, elle est sémantique. Un groupe de sécurité réseau Azure, un security group AWS et une règle de pare-feu VPC GCP répondent au même contrôle Zero Trust avec trois vocabulaires et trois modèles d'évaluation. Interroger le graphe en langage naturel — « liste toutes les ressources de calcul, tous clouds confondus, exposant un port d'administration à Internet, groupées par fournisseur et par propriétaire » — supprime cette friction de traduction. C'est, en pratique, le cas d'usage qui rentabilise le plus vite les SCU consommés : la même question posée manuellement demande trois consoles, trois syntaxes et une journée d'analyste.

Étendre au-delà du périmètre connu

Le CSPM ne voit que ce qui est rattaché à un abonnement ou à un connecteur. Les actifs oubliés — sous-domaines d'une campagne marketing, environnement de recette d'un prestataire, compte cloud ouvert par une filiale — échappent par construction à cette visibilité, alors qu'ils constituent une part disproportionnée des points d'entrée réels. La complémentarité se fait avec Defender EASM, qui part des domaines et adresses IP connus pour découvrir l'inventaire exposé par inférence ; nous détaillons cette approche dans notre article dédié à la gestion de la surface d'attaque externe. Croiser inventaire EASM et inventaire CSPM révèle systématiquement des actifs exposés qui ne figurent dans aucun connecteur : c'est l'un des exercices les plus rentables d'un audit de posture.

Intégration avec Microsoft Purview : données sensibles et conformité

Un modèle Zero Trust dont le pilier données repose uniquement sur le chiffrement au repos est incomplet. L'apport de Purview est de qualifier ce que contiennent les ressources, et donc de pondérer leur criticité.

DSPM et étiquettes de sensibilité

La découverte de données sensibles de Defender for Cloud analyse sans agent les comptes de stockage, bases de données managées et buckets S3 pour y détecter des types d'informations sensibles, en s'appuyant sur les classifieurs et les étiquettes de sensibilité définis dans Microsoft Purview. Une fois cette découverte activée, les ressources concernées portent un attribut de sensibilité qui remonte dans le graphe de sécurité cloud. Conséquence directe sur la priorisation : un chemin d'attaque aboutissant à un conteneur étiqueté « Hautement confidentiel » remonte au-dessus d'un chemin fonctionnellement identique mais aboutissant à des journaux applicatifs. La criticité cesse d'être une propriété de l'infrastructure pour devenir une propriété de la donnée — ce qui est exactement la promesse du pilier données.

Enrichir le contexte d'exposition

C'est ici que la combinaison des plug-ins prend tout son sens. Avec les plug-ins Defender for Cloud, Entra et Purview activés simultanément, une invite unique peut chaîner trois domaines : identifier les magasins de données classifiés, déterminer quelles identités y accèdent effectivement, et vérifier si ces identités sont couvertes par une stratégie d'accès conditionnel exigeant une authentification résistante à l'hameçonnage. Cette question est parfaitement légitime en revue Zero Trust ; elle demandait jusqu'ici trois extractions et un tableur de rapprochement. Attention toutefois à une limite qu'il faut annoncer aux équipes : les résultats dépendent entièrement de la qualité de la classification. Un tenant où les étiquettes ne sont ni publiées ni appliquées automatiquement produira des réponses confiantes et vides de sens.

Conformité réglementaire et reporting

Le tableau de bord de conformité réglementaire de Defender for Cloud permet d'ajouter des référentiels au-delà du MCSB : ISO/IEC 27001, PCI DSS, SOC 2, CIS, ainsi que des initiatives personnalisées pour couvrir les exigences NIS2 ou DORA. Chaque contrôle réglementaire s'y trouve mis en correspondance avec les évaluations techniques sous-jacentes, ce qui rend l'écart auditable ressource par ressource. La génération de rapports destinés au comité de direction ou à l'auditeur externe est l'un des usages les plus immédiatement adoptés de Security Copilot : produire une synthèse d'écart par article réglementaire, avec plan de remédiation daté, prend quelques minutes au lieu d'une semaine de consolidation manuelle. Le rapport reste bien entendu à relire et à assumer par le RSSI — il constitue une base de travail, pas une preuve de conformité.

Questions fréquentes

Le plan Defender CSPM est-il vraiment indispensable pour exploiter Security Copilot ?

Techniquement non, fonctionnellement oui. Sans le plan payant, Security Copilot n'accède qu'aux recommandations du CSPM fondamental : il saura les résumer, les grouper et générer des correctifs, mais il ne pourra ni raisonner sur les chemins d'attaque, ni exploiter le graphe de sécurité cloud, ni croiser exposition Internet et sensibilité des données. Or c'est précisément ce raisonnement transversal qui justifie l'investissement en SCU. Activer Security Copilot sur un périmètre en CSPM fondamental revient à payer un moteur d'analyse pour lui donner accès à une liste plate.

Combien de SCU faut-il provisionner pour un usage centré sur la posture ?

Aucun dimensionnement générique n'est honnête, car la consommation dépend du nombre d'utilisateurs, de la fréquence des invites et surtout du volume de données parcouru par chaque requête. La méthode fiable consiste à provisionner une capacité minimale, à instrumenter l'usage réel pendant deux à trois semaines via le tableau de bord d'utilisation, puis à ajuster. Un usage posture pur — revue mensuelle, gap analysis trimestrielle, rapports de conformité — consomme structurellement beaucoup moins qu'un usage SOC exécutant l'outil sur chaque incident. Les capacités étant redimensionnables, sur-provisionner par précaution est une erreur coûteuse.

Security Copilot peut-il appliquer les remédiations automatiquement en production ?

Il peut générer le correctif et, via les expériences incorporées, déclencher certaines actions dans le périmètre de vos permissions. Nous déconseillons formellement l'application automatique en production. Deux raisons : le modèle raisonne sur l'état de posture, pas sur les dépendances applicatives — fermer un port de gestion peut couper une chaîne d'exploitation légitime ; et toute correction appliquée hors du dépôt IaC sera écrasée au prochain déploiement. Le bon modèle opérationnel est la génération de code partant en pull request, avec revue humaine et traçabilité Git.

Comment gérer la résidence des données et les exigences réglementaires européennes ?

La capacité SCU se déploie dans une région Azure donnée et porte un paramètre de géographie de traitement des données à définir explicitement à la création. Ce point doit être arbitré avant tout déploiement, avec le DPO et le responsable conformité, et documenté dans l'analyse d'impact. Précision importante pour le secteur public : la documentation Microsoft indique que Security Copilot est destiné aux clients des clouds commerciaux et n'est pas conçu pour les clouds gouvernementaux souverains. Les organisations soumises à des exigences de souveraineté strictes doivent valider ce point en amont plutôt qu'en phase pilote.

Quelle est la principale limite de cette approche en environnement hybride ?

La cécité au périmètre on-premises. Defender for Cloud et son graphe couvrent les ressources cloud et les serveurs connectés via Azure Arc, mais n'évaluent pas les chemins de contrôle Active Directory : délégations, ACL malveillantes, relations d'approbation, comptes de service à SPN. Sur un tenant synchronisé, la compromission d'un compte à privilèges AD reste l'un des chemins les plus courts vers le cloud, et il n'apparaîtra dans aucune analyse de chemin d'attaque Defender for Cloud. La couverture Zero Trust du pilier identités impose donc de compléter le CSPM par une évaluation offensive de l'annuaire et par le déploiement de Defender for Identity sur les contrôleurs de domaine.