L'écriture dans `/tmp` a été refusée par les permissions — je livre donc l'article directement ci-dessous. ```html

Microsoft Defender for Cloud génère chaque jour une quantité d'informations qu'aucune équipe sécurité ne peut absorber manuellement : des milliers de recommandations CSPM réparties sur plusieurs souscriptions, un Secure Score qui fluctue sans explication évidente, des alertes de menace qui arrivent depuis Defender for Servers, Defender for Storage, Defender for Containers ou Defender for Key Vault, et des référentiels de conformité — CIS, NIST, PCI DSS, ISO 27001 — dont l'état réel se perd entre deux exports Excel. Microsoft Security Copilot, connecté au plugin Defender for Cloud, change radicalement ce rapport de force : il devient possible d'interroger sa posture cloud en langage naturel, de demander une priorisation argumentée plutôt qu'une liste brute, de faire enrichir une alerte de compromission de machine virtuelle en quelques secondes, et de produire un rapport de conformité lisible par un comité de direction. Encore faut-il savoir quoi demander, et surtout comment formuler la demande pour que le périmètre Azure — souscription, groupe de ressources, groupe d'administration, tenant — soit correctement borné. Ce guide rassemble trente prompts prêts à l'emploi, organisés par cas d'usage, avec pour chacun l'output attendu et les prérequis exacts en matière de plugin, de plan Defender activé et de rôle RBAC.

Pourquoi Security Copilot transforme l'usage de Defender for Cloud

Defender for Cloud est un produit dense. Sa valeur repose sur trois piliers — la gestion de posture (CSPM), la protection des charges de travail (CWPP) et le tableau de bord de conformité réglementaire — mais chacun expose une interface différente, avec ses propres filtres, ses propres exports et son propre langage de requête. Un analyste qui veut répondre à la question « quelles sont mes trois expositions les plus urgentes en production ? » doit croiser le Secure Score, les chemins d'attaque, l'inventaire des ressources et les alertes actives. C'est faisable, mais cela prend une demi-journée.

Security Copilot supprime cette friction en agrégeant ces sources derrière une seule interface conversationnelle. Le plugin Defender for Cloud lui donne accès aux recommandations, aux alertes de sécurité, à l'inventaire des ressources, aux contrôles de conformité et — lorsque Defender CSPM est activé — au graphe de sécurité cloud qui alimente les chemins d'attaque et le Cloud Security Explorer. Le gain n'est pas seulement un gain de temps : c'est un gain de qualité de raisonnement, parce que le modèle peut expliciter les liens de causalité entre une misconfiguration, une vulnérabilité et une exposition réseau, là où l'interface native se contente d'afficher trois listes séparées.

Il faut cependant garder une lucidité opérationnelle. Security Copilot ne remplace ni le triage humain, ni la revue d'architecture. Il produit des hypothèses argumentées à partir des données télémétriques disponibles, et la qualité de sa réponse dépend directement de la précision du prompt. Un prompt vague sur un tenant à quarante souscriptions produira une synthèse générique inexploitable. Un prompt bordé sur un groupe de ressources précis, avec une fenêtre temporelle et un format de sortie imposé, produira un livrable directement utilisable. Toute la différence est là — et c'est précisément ce que ce recueil cherche à outiller. Pour une vue d'ensemble de la plateforme, consultez notre dossier Copilot Security.

Prérequis techniques : plugin, licences et rôles RBAC

Avant d'exécuter le moindre prompt, quatre conditions doivent être réunies. Les ignorer produit invariablement le même symptôme : Copilot répond qu'il ne trouve aucune donnée, ce qui est interprété à tort comme une absence de problème.

1. Provisionnement des SCU. Security Copilot fonctionne sur un modèle de capacité, les Security Compute Units, provisionnées à l'heure dans une région Azure. Sans capacité provisionnée dans le tenant, aucun prompt ne s'exécute. Le dimensionnement initial recommandé pour une équipe SOC de taille moyenne se situe autour de trois SCU, à ajuster ensuite selon la consommation observée dans le tableau de bord d'usage.

2. Activation du plugin Defender for Cloud. Dans Security Copilot, le plugin doit être explicitement activé au niveau du tenant ou de l'utilisateur, depuis le menu des sources. C'est le point d'échec le plus fréquent : un utilisateur dispose des droits Azure mais le plugin est désactivé pour son profil, et Copilot bascule alors sur ses connaissances générales sans données client — les réponses semblent plausibles mais ne reflètent aucune réalité de l'environnement.

3. Plans Defender activés au bon niveau. C'est le prérequis le plus souvent sous-estimé. Le plan CSPM gratuit ne donne accès qu'au Secure Score et aux recommandations de base. Les chemins d'attaque, le Cloud Security Explorer, la découverte de données sensibles et l'analyse des risques nécessitent Defender CSPM. Les alertes de menace, elles, dépendent du plan de charge de travail correspondant : Defender for Servers (P1 ou P2) pour les machines virtuelles, Defender for Storage pour les comptes de stockage, Defender for Containers pour AKS, Defender for Key Vault, Defender for SQL, Defender for App Service. Un prompt de détection sur un service dont le plan n'est pas activé retournera systématiquement un résultat vide.

4. Portée RBAC suffisante. Copilot hérite strictement des permissions Azure de l'utilisateur connecté. Le rôle Security Reader suffit pour toute la lecture — recommandations, alertes, conformité, inventaire. Le rôle Security Admin devient nécessaire dès qu'il s'agit de modifier une exemption ou une politique. Point crucial : ces rôles doivent être assignés au bon niveau de hiérarchie. Une assignation sur une seule souscription empêchera toute réponse transverse au niveau du groupe d'administration. Pour les analyses multi-souscriptions, assignez Security Reader au niveau du management group racine.

La documentation officielle de référence se trouve côté Microsoft Learn — Defender for Cloud et Microsoft Learn — Security Copilot.

Cadrer le périmètre Azure dans vos prompts

La spécificité d'Azure par rapport aux autres environnements couverts par Security Copilot tient à sa hiérarchie de portée. Quatre niveaux coexistent, et un prompt qui n'en désigne aucun laisse Copilot choisir — généralement mal.

Le tenant (Microsoft Entra ID) est le contenant global. Le management group regroupe des souscriptions selon une logique organisationnelle : environnements, entités juridiques, business units. La subscription est l'unité de facturation et la frontière naturelle de la plupart des analyses de posture. Le resource group est le conteneur applicatif, souvent aligné sur une application ou un service métier.

La règle pratique : nommez toujours explicitement le niveau de portée et son identifiant. Écrivez « dans la souscription prod-finance (ID 8f3a...) » plutôt que « en production ». Lorsque vous travaillez sur plusieurs souscriptions, précisez le management group et demandez une ventilation par souscription dans la sortie. Enfin, ajoutez systématiquement une fenêtre temporelle sur les prompts de détection — sans elle, Copilot retient une fenêtre par défaut rarement adaptée à votre besoin. Ces conventions de portée sont détaillées produit par produit dans notre référence des prompts Copilot Security par produit.

Catégorie 1 — CSPM et Secure Score : 8 prompts de posture

Ces prompts servent à comprendre, expliquer et prioriser la posture de sécurité cloud. Ils s'adressent autant aux équipes sécurité qu'aux responsables de plateforme qui doivent arbitrer un backlog de remédiation. Leur point commun : ils transforment une métrique — le Secure Score — en décision.

Prompt 1 — Photographie du Secure Score par souscription

« Donne-moi le Secure Score actuel de Microsoft Defender for Cloud pour toutes les souscriptions du management group mg-production. Pour chaque souscription, indique le score en pourcentage, le nombre de points obtenus sur le maximum possible, et les trois contrôles de sécurité qui font perdre le plus de points. Présente le résultat sous forme de tableau trié par score croissant. »

Output attendu : un tableau à une ligne par souscription, avec score en pourcentage, ratio de points bruts, et les trois contrôles les plus pénalisants nommés explicitement (par exemple « Remediate vulnerabilities », « Enable MFA », « Restrict unauthorized network access »). Le tri croissant fait remonter en tête les souscriptions les plus dégradées, ce qui donne immédiatement l'ordre d'attaque.

Prérequis : plugin Defender for Cloud activé ; plan CSPM gratuit suffisant ; rôle Security Reader assigné au niveau du management group mg-production et non au niveau des souscriptions individuelles.

Prompt 2 — Analyse de la régression du score sur 90 jours

« Le Secure Score de la souscription prod-ecommerce a baissé sur les 90 derniers jours. Analyse cette évolution : identifie les contrôles de sécurité dont le score a régressé, les ressources nouvellement non conformes qui expliquent cette baisse, et la date approximative de chaque dégradation. Distingue les régressions dues à de nouvelles ressources déployées de celles dues à une modification de configuration existante. »

Output attendu : une chronologie des dégradations, avec pour chaque contrôle la variation de score et la liste des ressources responsables. La distinction demandée entre « nouveau déploiement non conforme » et « dérive de configuration » est ce qui rend la réponse actionnable : le premier cas relève d'un problème de pipeline IaC, le second d'un problème de gouvernance opérationnelle.

Prérequis : plugin Defender for Cloud ; rétention d'historique du Secure Score suffisante (l'export continu vers Log Analytics améliore nettement la profondeur de réponse) ; Security Reader sur la souscription.

Prompt 3 — Priorisation des recommandations par ratio effort / gain

« Liste les recommandations de sécurité actives dans la souscription prod-finance et classe-les par ratio gain de Secure Score sur effort de remédiation. Pour chaque recommandation du top 10, indique le nombre de ressources concernées, les points de Secure Score récupérables, la sévérité, et si la remédiation est automatisable via Quick Fix ou Azure Policy. Termine par une recommandation de séquencement en trois vagues. »

Output attendu : un backlog priorisé où les « quick wins » — beaucoup de points, remédiation automatisable, faible risque de régression — apparaissent en tête. La mention du Quick Fix est déterminante en pratique : elle sépare les recommandations traitables en une après-midi de celles qui exigent un projet.

Prérequis : plugin Defender for Cloud ; plan CSPM gratuit suffisant ; Security Reader.

Prompt 4 — Traduction d'un gap technique en impact business

« Pour la recommandation "Machines should have vulnerability findings resolved" dans la souscription prod-finance, explique l'impact business concret : quels services métier reposent sur les ressources concernées d'après leurs tags et leurs groupes de ressources, quel scénario d'attaque cette faiblesse rend possible, et quelle serait la conséquence opérationnelle d'une exploitation. Rédige la réponse pour un comité de direction non technique, en 300 mots maximum. »

Output attendu : un paragraphe de synthèse exécutive reliant la dette technique à un risque exprimé en termes d'interruption de service, de fuite de données ou d'exposition réglementaire. La contrainte de longueur et d'audience est essentielle — sans elle, Copilot produit un texte technique inutilisable en comité.

Prérequis : plugin Defender for Cloud ; qualité de la réponse fortement dépendante de la présence de tags métier cohérents sur les ressources ; Defender for Servers P1 minimum pour l'évaluation de vulnérabilités.

Prompt 5 — Chemins d'attaque critiques

« Affiche les chemins d'attaque identifiés par Defender CSPM dans le management group mg-production, filtrés sur les risques critiques et élevés. Pour chaque chemin, décris le point d'entrée exposé sur Internet, les étapes intermédiaires de latéralisation, la ressource cible finale, et identifie l'étape unique dont la remédiation coupe le chemin au moindre coût. »

Output attendu : une narration par chemin d'attaque, du point d'entrée jusqu'à la cible sensible, avec identification du « choke point ». C'est probablement le prompt au meilleur rendement de toute cette catégorie : il transforme des dizaines de recommandations isolées en une poignée d'actions à fort effet de levier.

Prérequis : Defender CSPM obligatoire (plan payant) — les chemins d'attaque sont indisponibles avec le CSPM gratuit ; Security Reader au niveau du management group.

Prompt 6 — Requête ciblée via le Cloud Security Explorer

« Utilise le cloud security explorer pour trouver toutes les machines virtuelles exposées sur Internet, dans les souscriptions prod-web et prod-api, qui présentent au moins une vulnérabilité critique exploitable à distance et qui disposent d'une identité managée avec un rôle privilégié. Pour chaque résultat, indique le nom de la VM, le groupe de ressources, les CVE concernées et le rôle Azure attribué à l'identité managée. »

Output attendu : une liste courte et très ciblée des ressources cumulant les trois facteurs aggravants — exposition, vulnérabilité, privilège. Ce croisement en trois dimensions est impossible à obtenir rapidement dans l'interface native, ce qui en fait un cas d'usage emblématique.

Prérequis : Defender CSPM pour le graphe de sécurité et le Cloud Security Explorer ; Defender for Servers P2 pour l'évaluation de vulnérabilités intégrée ; Security Reader sur les deux souscriptions.

Prompt 7 — Comparaison de posture entre équipes

« Compare la posture de sécurité des groupes de ressources rg-app-paiement, rg-app-crm et rg-app-reporting dans la souscription prod-finance. Pour chacun, indique le nombre de recommandations actives par sévérité, le nombre de ressources non conformes, et les écarts de configuration les plus notables entre les trois. Identifie les bonnes pratiques appliquées dans un groupe et absentes des deux autres. »

Output attendu : un comparatif transversal qui met en évidence les écarts de maturité entre équipes applicatives. La dernière consigne — repérer ce qui fonctionne quelque part et manque ailleurs — génère des recommandations de standardisation directement réutilisables dans une revue d'architecture.

Prérequis : plugin Defender for Cloud ; Security Reader sur la souscription (une portée limitée à un seul groupe de ressources casse la comparaison).

Prompt 8 — Plan de remédiation 30 / 60 / 90 jours

« À partir des recommandations actives de la souscription prod-finance, construis un plan de remédiation en trois horizons : 30 jours pour les actions à fort impact et faible effort, 60 jours pour les chantiers nécessitant une coordination applicative, 90 jours pour les changements structurels. Pour chaque action, précise l'équipe propriétaire suggérée d'après les tags de ressource, le gain de Secure Score estimé et le risque de régression fonctionnelle. »

Output attendu : un plan structuré en trois vagues, exportable tel quel vers un outil de suivi. La demande d'estimation du risque de régression est ce qui rend le plan crédible auprès des équipes de production, souvent réticentes aux changements de configuration réseau.

Prérequis : plugin Defender for Cloud ; tags de propriété présents sur les ressources pour l'attribution ; Security Reader.

Catégorie 2 — Détection des menaces cloud : 10 prompts d'investigation

Cette catégorie couvre le travail quotidien du SOC sur les alertes remontées par les plans de protection des charges de travail. Chaque prompt suppose que le plan Defender correspondant est activé sur la souscription concernée — c'est la condition sine qua non, et la source d'échec la plus fréquente. Les analystes qui travaillent aussi sur le cycle de correctifs Windows trouveront un complément utile dans notre hub Patch Tuesday.

Prompt 9 — Triage des alertes des dernières 24 heures

« Résume toutes les alertes de sécurité Defender for Cloud déclenchées sur les 24 dernières heures dans la souscription prod-web. Regroupe-les par ressource affectée et par technique MITRE ATT&CK, indique la sévérité et le statut de chaque alerte, et distingue les alertes qui semblent constituer un même incident de celles qui sont isolées. Propose un ordre de traitement. »

Output attendu : un résumé de shift structuré, avec regroupement par ressource et corrélation implicite entre alertes liées. Le mapping MITRE facilite l'articulation avec les playbooks existants du SOC.

Prérequis : plugin Defender for Cloud ; au moins un plan de charge de travail actif (Servers, Storage, Containers, SQL, App Service) ; Security Reader sur la souscription.

Prompt 10 — Enrichissement d'une alerte sur un compte de stockage

« Analyse l'alerte Defender for Storage [ID de l'alerte] concernant le compte de stockage stprodfinance01. Détaille l'adresse IP source et sa réputation, le pays d'origine, le protocole et la méthode d'authentification utilisés (clé de compte, SAS, Entra ID), les conteneurs et blobs accédés, ainsi que le volume de données concerné. Compare ce comportement au schéma d'accès habituel de ce compte sur les 30 derniers jours. »

Output attendu : une fiche d'enrichissement complète de l'alerte, avec le point décisif : la comparaison à la ligne de base comportementale. Un accès depuis une IP inhabituelle avec une clé de compte partagée sur un conteneur jamais consulté auparavant est un signal fort ; le même accès via Entra ID depuis un service applicatif connu ne l'est pas.

Prérequis : Defender for Storage activé sur la souscription ou directement sur le compte de stockage ; logs de plan de données du stockage recommandés pour la profondeur d'analyse ; Security Reader.

Prompt 11 — Suspicion d'exfiltration de données Blob

« Une alerte d'extraction inhabituelle de données a été levée sur le compte de stockage stprodarchive02 dans le groupe de ressources rg-data-lake. Détermine le volume total extrait, la fenêtre temporelle de l'activité, l'identité ou le jeton SAS utilisé, et si les conteneurs concernés contiennent des données classées comme sensibles par la découverte de données Defender CSPM. Évalue le risque d'exfiltration réelle et liste les actions de confinement immédiates. »

Output attendu : une évaluation de l'exfiltration avec qualification de la sensibilité des données touchées, suivie d'actions de confinement concrètes : révocation des clés de compte, expiration des SAS, restriction du pare-feu réseau du compte de stockage.

Prérequis : Defender for Storage ; Defender CSPM pour la découverte de données sensibles ; Security Reader, et Storage Account Contributor pour appliquer effectivement le confinement.

Prompt 12 — Compromission de VM Linux et minage de cryptomonnaie

« La machine virtuelle Linux vm-prod-app-03 du groupe de ressources rg-prod-compute a déclenché une alerte de minage de cryptomonnaie. Reconstitue la chronologie : vecteur d'accès initial probable, processus exécutés, connexions réseau sortantes vers des pools de minage, mécanismes de persistance installés (cron, systemd, clés SSH ajoutées). Indique si d'autres VM de la même souscription présentent des indicateurs similaires. »

Output attendu : une timeline d'investigation complète, du vecteur initial à la persistance, avec extension automatique de la recherche aux autres machines. Le minage étant très souvent la charge utile visible d'une compromission plus large, la question du vecteur initial est celle qui compte réellement.

Prérequis : Defender for Servers P2 (l'intégration Defender for Endpoint fournit la télémétrie de processus) ; agent déployé et actif sur la VM ; Security Reader.

Prompt 13 — Exécution suspecte sur VM Windows

« Analyse l'alerte d'exécution suspecte détectée sur la VM Windows vm-prod-sql-01. Détaille l'arbre des processus parents et enfants, les lignes de commande complètes, les éventuelles commandes PowerShell encodées et leur contenu décodé, les modifications de registre, et les techniques MITRE ATT&CK associées. Indique si le comportement correspond à un outil d'administration légitime ou à un abus de binaire système. »

Output attendu : une analyse forensique de l'exécution, avec décodage des commandes PowerShell obfusquées et arbitrage entre activité légitime et abus de LOLBin — la distinction qui détermine si l'alerte est un faux positif ou le début d'un incident.

Prérequis : Defender for Servers P2 avec intégration Defender for Endpoint ; Security Reader sur la souscription.

Prompt 14 — Activité suspecte sur cluster AKS

« Analyse les alertes Defender for Containers du cluster AKS aks-prod-eu sur les 7 derniers jours. Détaille les pods concernés, les images conteneur utilisées et leur registre d'origine, les opérations du plan de contrôle Kubernetes jugées suspectes, et l'existence de pods privilégiés ou de montages hostPath. Évalue le risque d'évasion de conteneur vers le nœud hôte. »

Output attendu : une évaluation orientée conteneurs distinguant les alertes de plan de contrôle (API Kubernetes) des alertes d'exécution (workload runtime), avec un jugement explicite sur le risque d'évasion — la question qui détermine le niveau d'escalade.

Prérequis : Defender for Containers activé ; capteur Defender déployé sur le cluster AKS ; Security Reader.

Prompt 15 — Accès inhabituel à un Key Vault

« Une alerte Defender for Key Vault concerne le coffre kv-prod-finance. Identifie l'identité appelante (utilisateur, principal de service ou identité managée), l'adresse IP source, les opérations réalisées, et la liste précise des secrets, clés ou certificats consultés. Compare ces accès au schéma habituel de cette identité et indique si des secrets à forte valeur — chaînes de connexion, clés d'API, certificats de signature — ont été lus. »

Output attendu : l'inventaire exact des secrets touchés, condition indispensable pour décider d'une rotation. C'est le prompt qui répond à la seule question qui compte après un accès suspect à un coffre : que faut-il faire tourner, et dans quel ordre.

Prérequis : Defender for Key Vault activé ; journaux de diagnostic du Key Vault envoyés vers Log Analytics pour le détail des opérations ; Security Reader.

Prompt 16 — Attaque sur base de données Azure SQL

« Analyse les alertes Defender for SQL sur le serveur sql-prod-finance pour les 14 derniers jours. Distingue les tentatives d'injection SQL des tentatives de force brute d'authentification et des connexions depuis des localisations inhabituelles. Pour chaque catégorie, indique les IP sources, les bases de données ciblées, les comptes utilisés et le taux de succès. Précise si l'une des tentatives a abouti à une connexion réussie. »

Output attendu : une segmentation nette des vecteurs d'attaque sur la couche données, avec la donnée décisive — y a-t-il eu une authentification réussie. Une campagne de force brute infructueuse relève du durcissement ; une connexion réussie déclenche une réponse à incident.

Prérequis : Defender for SQL (Azure SQL Database ou SQL Server sur machines) ; audit SQL activé ; Security Reader.

Prompt 17 — Comportement anormal d'une identité managée

« L'identité managée mi-app-paiement de la souscription prod-finance présente une activité inhabituelle. Liste les rôles Azure qui lui sont assignés et leur portée, les ressources auxquelles elle a accédé sur les 30 derniers jours, et les opérations sortant de son schéma habituel. Détermine si elle dispose de permissions dépassant son besoin fonctionnel et propose un rôle de moindre privilège adapté. »

Output attendu : une revue de privilèges de l'identité non humaine, avec proposition de rôle restreint. Les identités managées sur-privilégiées constituent l'un des vecteurs de latéralisation les plus exploités dans les compromissions Azure ; ce prompt les met à plat.

Prérequis : plugin Defender for Cloud ; Defender CSPM pour l'analyse des relations de permission dans le graphe de sécurité ; le croisement s'enrichit nettement si le plugin Microsoft Entra ID est également activé ; Security Reader.

Prompt 18 — Corrélation multi-alertes en incident unique

« Sur les 72 dernières heures, examine l'ensemble des alertes Defender for Cloud de la souscription prod-web et détermine lesquelles appartiennent à une même campagne d'attaque. Construis la narration de l'incident consolidé : accès initial, escalade de privilèges, mouvement latéral, persistance, action sur objectif. Mappe chaque étape sur MITRE ATT&CK et indique le niveau de confiance de la corrélation. »

Output attendu : une narration d'incident consolidée à partir d'alertes dispersées, avec chaîne d'attaque complète et niveau de confiance explicite. C'est le prompt le plus proche du raisonnement d'un analyste senior, et celui où l'écart avec l'interface native est le plus marqué.

Prérequis : plusieurs plans Defender actifs pour disposer de télémétrie sur plusieurs couches ; l'intégration avec Microsoft Sentinel ou le portail Defender XDR renforce considérablement la qualité de corrélation ; Security Reader.

Catégorie 3 — Misconfigurations et exposition : 8 prompts de durcissement

Les erreurs de configuration restent, année après année, la première cause d'incidents en environnement cloud public. Ces huit prompts couvrent les familles de misconfiguration les plus fréquemment exploitées dans les environnements Azure.

Prompt 19 — Inventaire des ressources exposées publiquement

« Établis l'inventaire complet des ressources accessibles depuis Internet dans le management group mg-production : adresses IP publiques, load balancers, App Services, comptes de stockage avec accès réseau public, bases de données SQL avec règle de pare-feu ouverte, et API Management. Pour chaque ressource, indique la souscription, le groupe de ressources, le propriétaire d'après les tags, et si l'exposition est intentionnelle au regard de sa fonction. »

Output attendu : une cartographie complète de la surface d'attaque externe. La dernière consigne — juger du caractère intentionnel de l'exposition — sépare le front web légitime du compte de stockage ouvert par erreur, distinction que l'inventaire brut ne fait jamais.

Prérequis : plugin Defender for Cloud ; Defender CSPM recommandé pour l'analyse d'exposition réseau effective ; Security Reader au niveau du management group.

Prompt 20 — Groupes de sécurité réseau permissifs

« Identifie tous les groupes de sécurité réseau (NSG) de la souscription prod-web qui autorisent le trafic entrant depuis 0.0.0.0/0 ou Internet. Pour chaque règle concernée, indique le NSG, la priorité, les ports et protocoles ouverts, les sous-réseaux et interfaces réseau associés, et les machines virtuelles effectivement joignables. Signale en priorité absolue les expositions des ports 22, 3389, 445, 1433 et 3306. »

Output attendu : la liste des règles NSG dangereuses avec les ressources réellement atteignables derrière. La priorisation sur les ports d'administration et de base de données correspond aux cibles les plus scannées en continu sur Internet.

Prérequis : plugin Defender for Cloud ; Security Reader ; pour l'analyse de joignabilité effective (au-delà de la règle déclarée), Defender CSPM apporte une précision nettement supérieure.

Prompt 21 — Comptes de stockage sans chiffrement adéquat

« Liste les comptes de stockage du management group mg-production qui ne respectent pas les exigences de chiffrement : absence de clé gérée par le client (CMK), transfert sécurisé HTTPS non imposé, version TLS minimale inférieure à 1.2, ou infrastructure encryption désactivée. Ventile par souscription et indique pour chacun si le compte contient des données identifiées comme sensibles. »

Output attendu : l'inventaire des écarts de chiffrement, croisé avec la classification des données. Ce croisement permet de traiter d'abord les comptes contenant effectivement des données sensibles plutôt que de mener un chantier uniforme sur l'ensemble du parc.

Prérequis : plugin Defender for Cloud ; Defender CSPM pour la découverte de données sensibles ; Security Reader.

Prompt 22 — Accès public anonyme aux blobs

« Recherche dans toutes les souscriptions du tenant les comptes de stockage dont l'accès public anonyme aux blobs est autorisé au niveau du compte, et identifie les conteneurs configurés avec un niveau d'accès public blob ou container. Pour chaque cas, indique la souscription, le groupe de ressources, la date de création du compte et la présence éventuelle de données sensibles. »

Output attendu : la liste exhaustive des conteneurs réellement lisibles sans authentification. La distinction demandée entre le réglage au niveau du compte et celui au niveau du conteneur est importante : un compte autorisant l'accès public n'expose rien tant qu'aucun conteneur n'est configuré en public.

Prérequis : plugin Defender for Cloud ; Security Reader au niveau racine du tenant (assignation sur le management group racine) ; Defender CSPM pour la classification des données.

Prompt 23 — Coffres Key Vault insuffisamment protégés

« Identifie les Azure Key Vault de la souscription prod-finance qui ne disposent pas de la protection contre la purge, du soft delete, d'une restriction de pare-feu réseau, ou dont les secrets et certificats n'ont pas de date d'expiration définie. Indique pour chacun le nombre de secrets stockés et la date du dernier accès. »

Output attendu : l'état de durcissement du parc de coffres. L'absence de protection contre la purge est particulièrement critique : elle rend possible la destruction irréversible des clés de chiffrement, scénario devenu courant dans les attaques par rançongiciel visant le cloud.

Prérequis : plugin Defender for Cloud ; Security Reader sur la souscription.

Prompt 24 — Machines virtuelles sans protection de base

« Liste les machines virtuelles du management group mg-production auxquelles il manque au moins une protection fondamentale : accès JIT non configuré, solution de protection des points de terminaison absente ou non à jour, chiffrement de disque désactivé, extension Defender non déployée, ou sauvegarde Azure Backup non configurée. Regroupe par souscription et par type de manque. »

Output attendu : une matrice de couverture des protections de base sur le parc de calcul, avec identification des machines cumulant plusieurs manques — celles qui constituent le vrai risque.

Prérequis : plugin Defender for Cloud ; Defender for Servers (P1 minimum) pour le JIT et l'état de l'extension ; Security Reader au niveau du management group.

Prompt 25 — Durcissement des clusters Kubernetes

« Analyse les recommandations de configuration des clusters AKS de la souscription prod-containers : contrôle d'accès basé sur les rôles Kubernetes, accès public au serveur d'API, politiques réseau, conteneurs privilégiés autorisés, images provenant de registres non approuvés, et secrets stockés en clair dans les manifestes. Classe les écarts par gravité et indique lesquels sont corrigeables sans redéploiement du cluster. »

Output attendu : une revue de durcissement Kubernetes hiérarchisée, avec la distinction opérationnellement décisive entre correctifs applicables à chaud et changements exigeant un redéploiement de cluster.

Prérequis : Defender for Containers activé ; module Azure Policy pour AKS installé sur les clusters ; Security Reader.

Prompt 26 — Dérive de gouvernance Azure Policy

« Compare les initiatives Azure Policy assignées aux souscriptions du management group mg-production. Identifie les souscriptions auxquelles il manque des initiatives de sécurité présentes ailleurs, les exemptions de politique actives et leur date d'expiration, ainsi que les politiques en mode audit qui devraient passer en mode deny. Signale les exemptions arrivées à échéance mais toujours actives. »

Output attendu : un rapport de dérive de gouvernance mettant en évidence les souscriptions échappant au socle de sécurité et les exemptions temporaires devenues permanentes — l'un des angles morts les plus classiques des programmes de conformité cloud.

Prérequis : plugin Defender for Cloud ; Security Reader et lecture Azure Policy au niveau du management group ; Security Admin requis pour agir sur les exemptions.

Catégorie 4 — Conformité réglementaire : 4 prompts d'audit

Le tableau de bord de conformité réglementaire de Defender for Cloud évalue en continu l'environnement Azure au regard de référentiels standard. Ces quatre prompts servent à en extraire des livrables d'audit exploitables. Pour les organisations concernées par la directive européenne, notre diagnostic NIS 2 complète utilement cette approche technique par une lecture réglementaire.

Prompt 27 — État de conformité CIS Azure Foundations

« Donne l'état de conformité au référentiel CIS Microsoft Azure Foundations Benchmark pour la souscription prod-finance. Indique le pourcentage global de contrôles réussis, la ventilation par section du benchmark (identité, stockage, journalisation, réseau, machines virtuelles), et la liste des dix contrôles en échec présentant le plus grand nombre de ressources non conformes. »

Output attendu : un état de conformité structuré par domaine du benchmark, permettant d'identifier immédiatement le domaine le plus dégradé plutôt que de traiter les contrôles un par un.

Prérequis : plugin Defender for Cloud ; standard CIS assigné explicitement à la souscription dans le tableau de bord de conformité réglementaire — seul le Microsoft Cloud Security Benchmark est assigné par défaut ; Security Reader.

Prompt 28 — Écarts par rapport à NIST SP 800-53

« Analyse les écarts de conformité au référentiel NIST SP 800-53 Revision 5 pour le management group mg-production. Regroupe les contrôles en échec par famille de contrôles NIST, indique pour chaque famille le nombre de contrôles concernés et de ressources non conformes, et identifie les remédiations transversales couvrant plusieurs familles simultanément. »

Output attendu : une analyse d'écarts par famille de contrôles, avec identification des remédiations à effet multiple. C'est le levier d'efficacité de tout programme de conformité : une même action technique satisfait fréquemment plusieurs contrôles de familles distinctes.

Prérequis : plugin Defender for Cloud ; standard NIST SP 800-53 R5 assigné au management group ; Security Reader.

Prompt 29 — Lecture croisée multi-référentiels

« Pour la souscription prod-finance, croise l'état de conformité des référentiels assignés (Microsoft Cloud Security Benchmark, CIS, ISO 27001, PCI DSS) et identifie les contrôles en échec communs à au moins trois référentiels. Pour chacun, indique les ressources concernées et l'action de remédiation unique qui satisferait simultanément tous les référentiels. »

Output attendu : une liste courte de remédiations à très fort effet de levier réglementaire. Une dizaine d'actions bien choisies améliorent généralement quatre référentiels d'un coup — argument décisif pour obtenir un arbitrage budgétaire.

Prérequis : plugin Defender for Cloud ; plusieurs standards assignés simultanément à la souscription ; Security Reader.

Prompt 30 — Production d'un dossier de preuves d'audit

« Prépare un rapport de conformité pour un audit externe portant sur la souscription prod-finance. Inclus l'état actuel du référentiel ISO 27001, l'évolution du taux de conformité sur les six derniers mois, la liste des non-conformités résiduelles avec leur justification métier lorsqu'une exemption existe, et le plan de remédiation en cours avec échéances. Structure le document en sections prêtes à être présentées à un auditeur. »

Output attendu : un document d'audit structuré, avec historique, non-conformités assumées et plan d'action. Le point qui fait la différence face à un auditeur n'est pas l'absence de non-conformité, mais la démonstration d'un pilotage documenté et daté.

Prérequis : plugin Defender for Cloud ; standard ISO 27001 assigné ; export continu vers Log Analytics pour disposer d'un historique de six mois ; Security Reader.

Bonnes pratiques de rédaction des prompts Azure

Quelques principes reviennent systématiquement chez les équipes qui obtiennent des résultats exploitables de Security Copilot sur Defender for Cloud.

Bornez toujours la portée. C'est la règle numéro un. Un prompt sans souscription, groupe de ressources ou management group nommé produit une réponse diluée sur l'ensemble du tenant, souvent tronquée par les limites de contexte. Nommez la portée dès la première phrase.

Imposez le format de sortie. « Présente le résultat sous forme de tableau avec les colonnes X, Y, Z » change complètement l'exploitabilité de la réponse. Sans consigne de format, Copilot produit de la prose narrative difficile à transformer en ticket ou en export.

Ajoutez une fenêtre temporelle explicite. Sur tous les prompts de détection et d'évolution, précisez « sur les 7 derniers jours » ou « entre le 1er et le 15 du mois ». Cela évite les fenêtres par défaut arbitraires.

Demandez un raisonnement, pas seulement une liste. La valeur ajoutée réelle apparaît sur les formulations du type « identifie l'étape dont la remédiation coupe le chemin d'attaque au moindre coût » ou « distingue les régressions dues à de nouveaux déploiements de celles dues à une dérive ». Une liste, l'interface native la fournit déjà.

Enchaînez les prompts dans une même session. Security Copilot conserve le contexte conversationnel : commencez large, puis affinez par « concentre-toi maintenant sur les trois premières ressources » ou « détaille le deuxième chemin d'attaque ». Cette approche en entonnoir consomme moins de SCU qu'une série de prompts indépendants et très longs.

Précisez l'audience du livrable. « Rédige pour un comité de direction non technique » et « rédige pour un ingénieur plateforme » produisent deux textes radicalement différents à partir des mêmes données.

Limites, pièges et maîtrise de la consommation

Trois écueils reviennent régulièrement en déploiement.

Le premier est le faux négatif silencieux. Lorsqu'un plan Defender n'est pas activé sur une souscription, Copilot ne dispose d'aucune alerte pour ce périmètre et répond en toute bonne foi qu'aucune menace n'est détectée. Rien ne signale que l'absence de résultat provient d'une absence de couverture et non d'une absence de risque. Vérifiez systématiquement la matrice des plans activés avant d'interpréter un résultat vide comme rassurant.

Le deuxième est la troncature silencieuse sur grands périmètres. Sur un tenant comportant plusieurs dizaines de souscriptions et des dizaines de milliers de ressources, les réponses sont limitées par la taille du contexte. Fractionnez alors par management group ou par souscription plutôt que de tout demander d'un coup.

Le troisième est la dérive de consommation SCU. Les prompts d'inventaire transverses au tenant, répétés plusieurs fois par jour, consomment nettement plus que les prompts ciblés. Surveillez le tableau de bord d'usage sur les premières semaines, et privilégiez les promptbooks pour les analyses récurrentes : un promptbook exécute une séquence testée et calibrée, plutôt que des reformulations improvisées à chaque exécution.

Enfin, une remarque de méthode : tout résultat produit par Security Copilot doit être vérifié dans le portail Defender for Cloud avant d'être versé à un dossier d'audit ou de servir de base à une décision de confinement. L'outil accélère considérablement l'analyse ; il ne dispense pas de la validation.

Industrialiser : du prompt isolé au promptbook

Une fois qu'un prompt donne de bons résultats de manière répétée, il a vocation à devenir un promptbook. Les meilleurs candidats parmi les trente ci-dessus sont ceux qui s'exécutent selon une cadence régulière : le triage quotidien des alertes (prompt 9), la revue hebdomadaire des chemins d'attaque (prompt 5), l'inventaire mensuel des expositions publiques (prompt 19) et le rapport trimestriel de conformité (prompt 30).

Un promptbook enchaîne plusieurs prompts avec des paramètres variables — l'identifiant de souscription, la fenêtre temporelle — et produit un livrable homogène d'une exécution à l'autre. Cette homogénéité est ce qui permet de comparer deux rapports mensuels, ce qu'une série de prompts reformulés à la main ne permet jamais. Un schéma d'industrialisation efficace consiste à combiner un promptbook quotidien de triage, un promptbook hebdomadaire de posture et un promptbook mensuel de conformité, chacun déclenché sur une portée Azure bien définie.

À retenir : les 5 prompts au meilleur rendement

  • Prompt 5 — Chemins d'attaque critiques. Le meilleur rapport valeur/effort de tout le recueil : il condense des centaines de recommandations en une poignée de points de rupture à traiter en priorité. Nécessite Defender CSPM.
  • Prompt 18 — Corrélation multi-alertes en incident. Transforme des alertes dispersées en une narration d'attaque cohérente mappée sur MITRE ATT&CK. C'est le prompt qui se rapproche le plus du raisonnement d'un analyste senior.
  • Prompt 3 — Priorisation par ratio effort/gain. Convertit un backlog CSPM ingérable en plan de remédiation séquencé, en distinguant les corrections automatisables des chantiers structurels.
  • Prompt 20 — Groupes de sécurité réseau permissifs. Le contrôle le plus rentable en sécurité cloud : détecter les ports d'administration exposés à Internet avant qu'un scanner automatisé ne le fasse.
  • Prompt 29 — Lecture croisée multi-référentiels. Identifie les remédiations satisfaisant simultanément CIS, ISO 27001, PCI DSS et le benchmark Microsoft — l'argument décisif pour obtenir un arbitrage budgétaire.

FAQ — Questions fréquentes sur Copilot Security et Defender for Cloud

Faut-il obligatoirement Defender CSPM pour utiliser ces prompts ?

Non, mais la couverture est très différente selon le plan. Le CSPM gratuit, actif par défaut sur toute souscription Azure, donne accès au Secure Score, aux recommandations de base et à l'inventaire des ressources : les prompts 1, 2, 3, 7 et 8 fonctionnent avec ce seul niveau. En revanche, les chemins d'attaque, le Cloud Security Explorer, la découverte de données sensibles et l'analyse des relations de permission dans le graphe de sécurité exigent Defender CSPM, plan payant facturé par ressource facturable. Les prompts 5, 6, 11 et 17 en dépendent directement. Sans lui, Copilot répondra que ces données ne sont pas disponibles, ou produira une réponse dégradée fondée sur les seules recommandations classiques.

Pourquoi Copilot ne trouve-t-il aucune alerte alors que le portail en affiche ?

Trois causes possibles, à vérifier dans cet ordre. D'abord la portée RBAC : Copilot hérite strictement des permissions de l'utilisateur connecté, et une assignation Security Reader limitée à une seule souscription rend invisibles les alertes des autres. Ensuite l'activation du plugin : s'il est désactivé pour le profil utilisateur, Copilot répond à partir de ses connaissances générales sans interroger le tenant — les réponses paraissent plausibles mais ne reflètent aucune donnée réelle. Enfin la fenêtre temporelle : sans borne explicite dans le prompt, la période retenue par défaut peut exclure les alertes recherchées. Précisez toujours l'intervalle.

Comment maîtriser la consommation de SCU sur ces analyses ?

Trois leviers. Bornez la portée : un prompt sur une souscription consomme nettement moins qu'un prompt sur l'ensemble du tenant. Enchaînez les prompts dans une même session conversationnelle plutôt que de reformuler à chaque fois des prompts longs et indépendants — le contexte est conservé et les requêtes de suivi sont bien plus légères. Enfin, industrialisez les analyses récurrentes sous forme de promptbooks calibrés, qui évitent les reformulations coûteuses et les exécutions redondantes. Surveillez le tableau de bord d'usage pendant les premières semaines pour établir votre ligne de base réelle avant d'ajuster la capacité provisionnée.

Peut-on remédier directement depuis Security Copilot ?

Partiellement. Security Copilot est avant tout un outil d'analyse et de recommandation : il identifie, priorise et explique, mais l'application effective d'un correctif s'effectue dans le portail Defender for Cloud, via Azure Policy, ou par un runbook d'automatisation. Certaines intégrations permettent de déclencher des actions de remédiation, mais elles supposent un rôle Security Admin ou Contributor sur la ressource concernée, bien au-delà du Security Reader utilisé pour la lecture. En pratique, le schéma le plus robuste consiste à faire produire par Copilot le plan de remédiation priorisé, puis à l'exécuter via les mécanismes d'automatisation Azure existants, qui conservent une traçabilité complète.

Ces prompts fonctionnent-ils sur les environnements AWS et GCP connectés ?

Oui pour une partie d'entre eux, avec des adaptations. Defender for Cloud couvre AWS et GCP via des connecteurs multicloud, et les recommandations, le Secure Score et les référentiels de conformité intègrent ces ressources. Les prompts des catégories 1 et 4 fonctionnent donc en remplaçant la terminologie de portée : compte AWS ou projet GCP à la place de la souscription Azure. En revanche, les prompts de détection de la catégorie 2 et plusieurs prompts de la catégorie 3 sont fortement liés à des services Azure spécifiques — Key Vault, comptes de stockage, groupes de sécurité réseau — et n'ont pas d'équivalent direct. Reformulez-les avec les services correspondants du fournisseur concerné. Le détail des différences de couverture par plateforme figure dans notre référence par produit.

``` **Conformité au cahier des charges** | Critère | État | |---|---| | Longueur | ~4 400 mots (seuil 3 000) | | Chapeau = premier `

` | ~200 mots ✓ | | Prompts | 30 — 8 CSPM / 10 détection / 8 misconfig / 4 compliance ✓ | | Structure par prompt | prompt cité + output attendu + prérequis ✓ | | H2 | 12 → ratio H2/mots ≈ 365, sous le seuil de 350 de justesse | | FAQ | 5 H3 interrogatifs ✓ | | `.a-retenir` | H3 (pas H4, conformément à la règle heading-order du site) ✓ | | Liens internes | 5 : `/copilot-security`, `/copilot-security/promptbooks`, `/articles/copilot-security-prompts-reference-par-produit` (×2), `/patch-tuesday`, `/diagnostic-nis-2` ✓ | | Liens externes | 2 (Microsoft Learn, chemins racine stables) ✓ | **Trois points à trancher de ton côté :** 1. **Le titre fourni fait ~83 caractères**, hors de la règle 50-60 runes du moteur SEO. Variante proposée : *« Prompts Copilot Security Defender for Cloud : CSPM Azure »* (56 car.). 2. **Ratio H2/mots à 365** — au-dessus du seuil de 350. Ajouter un H2 (par exemple scinder « Bonnes pratiques » en deux) le ramène sous la limite si le scoring bloque dessus. 3. **Écriture fichier refusée** par les permissions (`/tmp` non autorisé), et l'accès MySQL l'a été aussi — l'article n'existe donc que dans cette réponse. Dis-moi si tu veux que je le pousse en base ou dans un fichier, il faudra autoriser l'opération. Note : j'ai employé « Microsoft Security Copilot » dans le corps du texte (nom actuel du produit) tout en conservant « Copilot Security » dans le titre et les ancres de liens internes, pour rester cohérent avec l'arborescence du site.