Identités compromises et Copilot Security : investigation avec Microsoft Entra

En 2026, la compromission d'identité n'est plus un incident parmi d'autres : c'est le vecteur d'entrée dominant dans les environnements Microsoft 365, devant l'exploitation de vulnérabilités applicatives. Les campagnes d'adversary-in-the-middle industrialisées, la revente de cookies de session sur les marchés d'infostealers et le contournement systématique de l'authentification multifacteur par vol de jeton ont déplacé le champ de bataille : l'attaquant ne casse plus le mot de passe, il emprunte la session. Face à ce déplacement, les équipes SOC héritent d'un volume de signaux Entra ID — SigninLogs, AADUserRiskEvents, AuditLogs, journaux de consentement d'application — que peu d'analystes savent corréler sous pression, à 3 heures du matin, sur un compte Global Administrator suspect. Microsoft Security Copilot, souvent désigné Copilot Security dans les documentations francophones et les appels d'offres, s'insère précisément à cet endroit : il ne remplace pas l'investigation, il compresse le temps de mise en contexte. Cet article détaille, pour des administrateurs IAM, analystes SOC et RSSI, comment exploiter concrètement la brique Entra de Copilot Security pour qualifier une identité compromise, reconstituer la chaîne d'attaque et exécuter une remédiation qui tienne réellement l'attaquant hors du tenant.

Prérequis : provisionnement des SCU et activation des plugins Entra

Avant toute investigation, il faut cadrer la mécanique de consommation. Microsoft Security Copilot fonctionne sur un modèle de capacité provisionnée exprimé en SCU (Security Compute Units), facturées à l'heure et allouées par tranche depuis le portail Azure. Une SCU correspond à une unité de calcul dédiée : sous-provisionner conduit à des throttlings visibles en pleine investigation, sur-provisionner grève le budget SOC sans gain de latence. La règle empirique observée sur des tenants de 5 000 à 20 000 identités : démarrer à 2 ou 3 SCU pour un usage d'investigation réactive, monter à 4 ou 6 dès que les promptbooks sont industrialisés ou que Copilot est embarqué dans des flux Logic Apps. La capacité est ajustable à la hausse comme à la baisse en cours de mois, ce qui autorise un pilotage fin — mais le compteur tourne dès l'allocation, pas dès la première requête.

Rattacher explicitement le plugin Microsoft Entra

Copilot Security s'appuie sur une architecture de plugins : chaque source de données est branchée via un connecteur activé au niveau du tenant ou de l'utilisateur. Le plugin Microsoft Entra n'est pas systématiquement actif par défaut selon la séquence d'onboarding ; il faut le vérifier dans les paramètres de sources, sous la section des plugins Microsoft. La documentation officielle décrit la logique d'activation et les niveaux de permission requis dans sa vue d'ensemble des plugins. Point critique souvent négligé : Copilot n'élève jamais les privilèges de l'utilisateur qui le pilote. Un analyste disposant du seul rôle Security Reader obtiendra des réponses tronquées sur les assignations de rôles PIM, sans message d'erreur explicite — la réponse paraîtra simplement incomplète. Sur un incident d'identité, provisionnez a minima les rôles Security Operator et Global Reader pour l'équipe d'astreinte, et documentez le delta de visibilité induit par chaque rôle.

Vérifier la fenêtre de rétention des données interrogées

Copilot interroge les API sous-jacentes, pas un index propriétaire. Les journaux d'audit et de connexion Entra ID sont conservés 7 jours en licence gratuite, 30 jours en Entra ID P1/P2 ; les événements de risque d'ID Protection suivent la même contrainte. Toute investigation portant sur une compromission antérieure à 30 jours nécessite un export préalable vers un espace de travail Log Analytics, sans quoi Copilot répondra en toute bonne foi qu'aucun événement ne correspond. C'est la première cause de faux négatif rencontrée en production, et elle n'a rien d'algorithmique : c'est un défaut d'architecture de journalisation. Configurez les paramètres de diagnostic Entra ID vers Log Analytics avec une rétention de 12 mois minimum si vous opérez sous contrainte NIS2 ou DORA.

Copilot Security dans Microsoft Entra : fonctionnalités natives activées

Deux modes d'usage coexistent et se confondent souvent dans les discussions d'avant-vente. Le premier est l'expérience standalone, sur le portail dédié : une console conversationnelle où l'analyste formule ses requêtes en langage naturel et où Copilot orchestre les plugins. Le second est l'expérience embedded, directement intégrée dans le centre d'administration Microsoft Entra et dans le portail Defender. C'est ce second mode qui change réellement les habitudes de travail des équipes IAM.

Le résumé de risque contextualisé dans ID Protection

Dans le centre d'administration Entra, la fiche d'un utilisateur à risque expose un bouton de synthèse Copilot. Le résultat n'est pas une paraphrase du niveau de risque : c'est une agrégation croisée des détections ID Protection, de l'historique de connexions récentes, des appareils utilisés, des changements d'attributs sensibles et des consentements d'application accordés sur la période. Sur un cas typique de compromission par AitM, la synthèse restitue en une dizaine de lignes ce qu'un analyste met vingt à trente minutes à assembler manuellement : détection anomalousToken à 02h14 depuis une plage AS hébergeur, connexion réussie depuis un agent utilisateur incohérent avec le parc, ajout d'une méthode d'authentification MFA six minutes plus tard, puis création d'une règle de boîte aux lettres. La valeur n'est pas dans la détection — ID Protection l'avait déjà produite — mais dans la reconstitution de séquence.

L'explication des détections en langage clair

Chaque détection ID Protection dispose d'une explication générée à la demande : pourquoi ce déplacement est-il jugé atypique, quelle est la référence comportementale, quel poids a été accordé au renseignement sur les menaces. Cette fonction a un effet organisationnel mesurable : elle rend les décisions d'ID Protection auditables par un analyste de niveau 1, ce qui réduit l'escalade systématique vers le niveau 2 sur les alertes de risque moyen. Sur les SOC que nous accompagnons, c'est le gain le plus tangible des trois premiers mois, avant même l'automatisation.

La génération et l'explication de requêtes KQL

Copilot traduit une intention formulée en français vers une requête de chasse avancée exploitable dans Defender XDR ou Sentinel. Demander « liste les connexions réussies sur les comptes à rôle privilégié depuis des adresses IP jamais vues dans les 90 derniers jours » produit une requête structurée sur SigninLogs et IdentityLogonEvents, avec les jointures et les fenêtres temporelles. La requête doit être relue — nous y reviendrons — mais elle constitue un point de départ correct dans la grande majorité des cas. La fonction inverse, l'explication d'une KQL existante, est sous-utilisée : elle sert efficacement à documenter un patrimoine de règles de détection hérité et non commenté.

Analyser les connexions risquées avec Entra ID Protection et Copilot

Entra ID Protection classe le risque sur deux axes : le risque utilisateur, cumulatif et persistant, et le risque de connexion, évalué en temps réel pour chaque tentative d'authentification. Chaque axe est gradué en niveaux faible, moyen et élevé, et repose sur un catalogue de détections de risque documentées. L'état d'un utilisateur à risque évolue entre atRisk, confirmedCompromised, dismissed et remediated — cette machine à états est le socle sur lequel Copilot raisonne. Un analyste qui ne renseigne jamais ces états dégrade mécaniquement la pertinence des futures analyses, puisqu'il prive le modèle de la vérité terrain.

Trier le bruit : le cas des voyages impossibles

La détection de déplacement atypique génère un volume de faux positifs élevé dans les organisations à forte mobilité ou à usage massif de VPN d'entreprise. Copilot aide à trancher rapidement en croisant, pour chaque alerte, la localisation revendiquée, l'ASN, l'empreinte d'appareil et la conformité Intune. Un prompt efficace en production : « Pour l'utilisateur [email protected], liste toutes les détections de risque des 14 derniers jours, indique pour chacune l'adresse IP, l'ASN, le pays, l'ID d'appareil et son état de conformité, et signale si l'appareil était déjà connu de ce compte. » La réponse tabulaire permet d'éliminer en quelques secondes les alertes générées par des passerelles VPN mal géolocalisées — cause d'environ un tiers des faux positifs observés sur les tenants multi-pays.

Reconstituer la chronologie d'une session frauduleuse

Une fois le risque confirmé, l'enjeu devient la chronologie. Copilot excelle à produire une timeline unifiée mêlant journaux de connexion, journaux d'audit et alertes Defender. C'est aussi le point de jonction naturel avec la corrélation avec Defender XDR : l'identité compromise n'est presque jamais l'objectif final, elle est le pivot vers la messagerie, SharePoint ou les ressources Azure. La chronologie doit donc systématiquement s'étendre au-delà d'Entra ID, sous peine de clore un incident dont la persistance vit ailleurs.

Exploiter les détections différées dans le bon ordre

Certaines détections ID Protection sont produites en temps réel, d'autres en différé, parfois plusieurs heures après l'événement. Une détection leakedCredentials peut ainsi remonter longtemps après la connexion frauduleuse qu'elle explique. Demandez explicitement à Copilot d'ordonner les événements par horodatage d'occurrence et non par horodatage de détection : c'est une précision qui change l'interprétation d'un incident, et que le modèle n'applique pas spontanément.

Détecter le vol de tokens et les attaques Pass-the-Cookie avec Copilot

Le vol de jeton est le mode opératoire qui rend l'authentification multifacteur insuffisante à elle seule. Le principe est simple : l'attaquant ne cherche pas à s'authentifier, il capte l'artefact prouvant qu'une authentification a déjà eu lieu — cookie de session, jeton d'actualisation, ou Primary Refresh Token sur un poste joint à Entra ID.

Les trois chemins d'exfiltration à distinguer

Le premier chemin est le proxy adversary-in-the-middle : l'utilisateur s'authentifie sur une page relayée par un reverse proxy de type Evilginx, l'attaquant récupère le cookie de session en sortie de flux MFA. Le deuxième est l'infostealer : un malware sur le poste extrait les cookies du navigateur et les revend en lot ; le délai entre l'infection et l'exploitation dépasse fréquemment plusieurs semaines, ce qui casse la corrélation temporelle naïve. Le troisième est le vol de PRT, plus rare mais bien plus grave : le PRT porte les revendications MFA et reste valide 14 jours avec renouvellement toutes les 4 heures, offrant un accès SSO durable à l'ensemble du tenant. Ces trois chemins imposent des remédiations différentes — révocation de session pour le premier, remédiation complète du poste pour les deux autres.

Les détections Entra à interroger nommément

Deux détections ID Protection sont directement pertinentes : anomalousToken, qui signale des caractéristiques de durée de vie ou de rejeu anormales sur un jeton, et tokenIssuerAnomaly, qui vise les jetons SAML émis par un fournisseur d'identité potentiellement compromis. S'y ajoute anomalousUserActivity côté comportemental. Un prompt de chasse directement exploitable : « Recherche dans les 30 derniers jours toutes les détections anomalousToken et tokenIssuerAnomaly du tenant, groupe par utilisateur, et pour chaque utilisateur indique si une méthode d'authentification a été ajoutée ou modifiée dans les 24 heures suivant la détection. » Cette corrélation entre anomalie de jeton et modification de méthode MFA est le signal à haute valeur : elle distingue le bruit de la prise de contrôle effective.

Le contrôle : token protection et liaison à l'appareil

La contre-mesure structurelle est la protection de jeton (token protection) dans l'accès conditionnel, qui lie cryptographiquement le jeton d'actualisation à l'appareil sur lequel il a été émis. Un cookie exfiltré devient alors inutilisable depuis une machine tierce. La couverture reste partielle selon les clients et les services ciblés : elle est effective sur les clients lourds Office et Teams sur Windows joint à Entra ID, et s'étend progressivement. Déployez-la en mode rapport d'abord, sur le périmètre privilégié en priorité. C'est un chantier qui s'inscrit dans une trajectoire plus large de posture Zero Trust et CSPM, où la liaison appareil-identité devient le pivot de la confiance.

Conditional Access et Copilot Security : corriger les gaps de politique

Dans la quasi-totalité des compromissions post-mortem que nous analysons, l'accès conditionnel comportait un trou exploitable. Rarement une politique absente : plus souvent une exclusion oubliée, un périmètre d'application incomplet, ou un contrôle laissé en mode rapport et jamais basculé en application.

Cartographier les exclusions réellement en vigueur

Le premier réflexe post-incident consiste à demander à Copilot l'inventaire des politiques applicables au compte compromis, en distinguant celles qui se sont appliquées, celles qui ont été satisfaites, et celles qui ont été contournées par une exclusion. Formulation efficace : « Liste toutes les politiques d'accès conditionnel qui s'appliquent à l'utilisateur X, indique leur état (activée, rapport seul, désactivée), et détaille les exclusions d'utilisateurs, de groupes, d'applications et d'emplacements qui le concernent. » Le résultat révèle régulièrement des groupes d'exclusion historiques — un « CA-Exclusions-Temporaire » créé pour une migration close depuis dix-huit mois et comptant quarante membres. Les comptes bris de glace doivent rester exclus, mais ils doivent être au nombre de deux, surveillés par une règle d'alerte dédiée, et jamais synchronisés depuis l'annuaire local.

Fréquence de connexion et évaluation continue de l'accès

Sans CAE (Continuous Access Evaluation), la révocation d'une session n'est effective qu'au renouvellement du jeton d'accès, dont la durée de vie par défaut oscille entre 60 et 90 minutes : un attaquant conserve donc jusqu'à une heure et demie d'accès après votre action de remédiation. Avec CAE, les services compatibles — Exchange Online, SharePoint Online, Teams, Microsoft Graph — révoquent quasiment en temps réel sur événement critique. Vérifier que CAE est actif sur le périmètre privilégié n'est pas une optimisation, c'est un prérequis de crédibilité de toute procédure de réponse à incident sur identité.

Utiliser What If avant de durcir

L'outil What If d'Entra simule l'effet d'une politique sur un utilisateur, une application et un contexte donnés, sans impact de production. Copilot en facilite l'exploitation en langage naturel et permet de tester rapidement des hypothèses de durcissement : imposer un appareil conforme sur les rôles privilégiés, exiger une force d'authentification résistante au hameçonnage sur les administrateurs. La force d'authentification phishing-resistant MFA — FIDO2, Windows Hello Entreprise, certificats — est le seul contrôle qui neutralise structurellement le proxy AitM. Toute autre méthode, y compris les notifications push avec correspondance de nombre, reste relayable.

Investigation d'un compte administrateur compromis : protocole en 7 étapes

La compromission d'un compte à rôle privilégié impose une séquence stricte. L'erreur classique consiste à réinitialiser le mot de passe immédiatement : l'attaquant est alerté, bascule sur sa persistance secondaire, et l'équipe perd la visibilité sur son périmètre réel.

Étapes 1 à 3 : contenir sans alerter, puis qualifier

Étape 1 — Geler le périmètre d'observation. Exportez immédiatement les journaux de connexion et d'audit du compte sur une fenêtre de 30 jours vers un stockage hors du tenant compromis, avant toute action. Si l'attaquant dispose d'un rôle permettant de modifier les paramètres de diagnostic, la preuve peut disparaître.

Étape 2 — Qualifier la portée du rôle. Demandez à Copilot l'inventaire complet des rôles Entra ID actifs et éligibles du compte, des groupes assignables à un rôle dont il est membre, et des applications d'entreprise sur lesquelles il détient un rôle propriétaire. Un Global Administrator n'a pas le même rayon de souffle qu'un Application Administrator — mais le second peut, en ajoutant des identifiants à un principal de service surprivilégié, atteindre le premier.

Étape 3 — Établir la chronologie complète. Timeline unifiée connexions, audit et alertes Defender, ordonnée par horodatage d'occurrence, avec identification du premier accès frauduleux avéré. C'est ce point de départ qui déterminera l'étendue de la remédiation.

Étapes 4 à 7 : chasser la persistance, puis éradiquer

Étape 4 — Inventorier les modifications d'authentification. Toute méthode MFA ajoutée, tout numéro de téléphone modifié, tout appareil enregistré depuis le premier accès frauduleux est suspect par défaut. Le journal d'audit expose ces opérations sous les catégories UserManagement et AuthenticationMethods.

Étape 5 — Chasser la persistance applicative. C'est l'étape la plus souvent bâclée. Recherchez les consentements OAuth accordés, les inscriptions d'applications créées, et surtout les secrets et certificats ajoutés à des principaux de service existants. Un secret ajouté à une application disposant de permissions Graph élevées survit à toute réinitialisation de mot de passe et à toute révocation de session. Le prompt à systématiser : « Liste toutes les opérations d'ajout de credential sur des applications ou principaux de service dans les 30 derniers jours, avec l'acteur, l'application cible et ses permissions Graph applicatives. »

Étape 6 — Vérifier les délégations et redirections. Règles de transport Exchange, règles de boîte aux lettres masquées, délégations de boîte, redirections externes, partages SharePoint anonymes créés sur la période.

Étape 7 — Éradiquer et rétablir. Seulement à ce stade : révocation, réinitialisation, suppression des artefacts de persistance identifiés, puis réhabilitation contrôlée. La méthodologie recoupe largement celle d'un pentest Active Directory côté défensif : on cartographie les chemins d'élévation avant de couper, jamais l'inverse.

Privilege escalation et Entra Privileged Identity Management (PIM)

PIM transforme les rôles permanents en rôles éligibles, activables à la demande pour une durée limitée avec justification, MFA et, si configuré, approbation d'un pair. L'exposition passe ainsi d'un privilège permanent à une fenêtre de quelques heures — le modèle just-in-time appliqué à l'IAM.

Les signaux d'élévation à surveiller dans les journaux PIM

Trois signaux méritent une alerte dédiée. D'abord l'assignation de rôle en dehors de PIM : PIM dispose nativement d'une alerte pour cela, et c'est le premier geste d'un attaquant qui a obtenu un rôle d'administration temporaire et cherche à le pérenniser. Ensuite l'activation de rôle hors horaires habituels, en particulier sur Global Administrator, Privileged Role Administrator et Privileged Authentication Administrator — ce dernier permettant de réinitialiser les méthodes d'authentification d'un Global Administrator, il constitue un chemin d'élévation direct trop souvent absent des inventaires. Enfin l'ajout de membres à un groupe assignable à un rôle, qui contourne l'inventaire classique des attributions directes.

Interroger la surface privilégiée avec Copilot

Un prompt de revue périodique qui tient en une requête : « Liste tous les comptes disposant d'une assignation active permanente à un rôle privilégié Entra ID, indique pour chacun la date de dernière connexion, l'état MFA, si le compte est synchronisé depuis Active Directory, et s'il possède une licence. » Les comptes privilégiés synchronisés depuis l'AD local constituent un pont d'escalade hybride majeur : une compromission du domaine local devient une compromission du tenant. La règle est connue et rarement appliquée — les comptes à rôle privilégié Entra doivent être natifs cloud, sans correspondance locale.

Configurer PIM pour résister à l'abus

Quatre paramètres font la différence en pratique : durée d'activation maximale ramenée à 4 heures sur les rôles les plus sensibles, MFA exigée à l'activation, justification textuelle obligatoire, et approbation requise par un approbateur distinct sur Global Administrator et Privileged Role Administrator. L'approbation est le contrôle que les organisations retirent en premier « pour ne pas bloquer l'exploitation » — c'est pourtant celui qui coupe l'escalade automatisée. Prévoyez un groupe d'approbateurs d'au moins trois personnes pour garantir la disponibilité en astreinte.

Remédiation guidée : réinitialisation sécurisée et révocation de sessions

La remédiation d'une identité compromise n'est pas un changement de mot de passe. C'est une séquence ordonnée dont chaque étape omise laisse un chemin de retour à l'attaquant.

La séquence de révocation, dans l'ordre

Le mot de passe se réinitialise en premier, obligatoirement via une méthode hors bande si l'attaquant contrôle la messagerie. Vient ensuite la révocation des jetons d'actualisation avec Revoke-MgUserSignInSession -UserId [email protected], qui invalide les sessions en cours. Ordre inverse, et l'attaquant réutilise son jeton pour se réauthentifier avant votre action. Puis viennent la suppression des méthodes MFA illégitimes, le retrait des appareils enregistrés non reconnus, et la révocation des consentements OAuth suspects. Sans CAE actif, comptez jusqu'à 60 à 90 minutes de persistance résiduelle sur les jetons d'accès déjà émis — d'où l'intérêt de désactiver temporairement le compte avec Update-MgUser -UserId [email protected] -AccountEnabled:$false lorsque l'enjeu le justifie.

Clore proprement l'état de risque

Une fois la remédiation exécutée, l'état ID Protection doit être renseigné : Confirm-MgRiskyUserCompromised pour marquer explicitement la compromission, ou une action de rejet lorsque l'analyse conclut au faux positif. Get-MgRiskyUser permet de vérifier l'état résultant. Ce renseignement n'est pas cosmétique : il alimente la vérité terrain des modèles de détection et conditionne la qualité des futures évaluations de risque sur l'ensemble du tenant. Un SOC qui laisse des centaines d'utilisateurs en état atRisk non traités dégrade son propre outillage.

Reconstruire la confiance sur le compte réhabilité

Avant réactivation, réenrôlez les méthodes d'authentification depuis un poste sain et administré, imposez une méthode résistante au hameçonnage sur le compte privilégié, et placez le compte sous surveillance renforcée pendant 30 jours via une règle de détection dédiée. Les campagnes observées comportent fréquemment une tentative de reprise dans les deux semaines suivant l'éradication, exploitant un artefact de persistance non identifié lors du premier passage.

Promptbooks d'investigation d'identité réutilisables

L'usage conversationnel ponctuel de Copilot Security ne passe pas l'épreuve de l'astreinte : la qualité de la réponse dépend trop de la formulation, donc de l'analyste. La réponse industrielle s'appelle promptbook : une séquence de prompts ordonnée, paramétrée par une variable d'entrée, exécutable à l'identique par n'importe quel membre de l'équipe.

Structurer un promptbook « identité compromise »

Un promptbook opérationnel comporte typiquement sept à neuf prompts enchaînés, chacun consommant le contexte du précédent : synthèse du risque utilisateur, chronologie des connexions sur 30 jours avec IP, ASN et appareils, inventaire des rôles actifs et éligibles, modifications de méthodes d'authentification, consentements et credentials applicatifs ajoutés, politiques d'accès conditionnel appliquées et contournées, corrélation avec les alertes Defender XDR, puis synthèse exécutive destinée au RSSI. Le gain n'est pas seulement le temps : c'est la reproductibilité, donc la comparabilité entre incidents et la capacité à tenir un dossier probatoire cohérent en cas de notification CNIL sous 72 heures.

Mapper les prompts sur MITRE ATT&CK

Ancrer chaque prompt sur une technique documentée — T1078 comptes valides, T1550.004 vol de cookie de session web, T1098 manipulation de compte, T1556 modification du processus d'authentification — évite les angles morts et facilite la revue de couverture. Cette démarche prolonge les pratiques décrites dans notre article sur le threat hunting avec Copilot Security, où le référentiel sert de grille de complétude et non de simple étiquetage a posteriori.

Limites et faux positifs : ce que Copilot Security ne fait pas

Un article honnête doit énoncer les limites de l'outil. La documentation officielle Microsoft est explicite : les réponses peuvent être incomplètes ou inexactes et doivent être vérifiées. Trois modes de défaillance reviennent en production.

Silence sur données absentes, KQL fausse, synthèse trop assurée

Le premier est le silence sur données absentes : Copilot répond qu'aucun événement ne correspond, sans distinguer « absence d'événement » de « absence de droits » ou « hors fenêtre de rétention ». Un analyste pressé lira une innocence là où il y a un angle mort. Le deuxième est la KQL syntaxiquement valide mais sémantiquement fausse : jointure sur un champ homonyme, fenêtre temporelle mal ancrée, filtre sur un statut de connexion qui exclut silencieusement les échecs. Toute requête destinée à une règle de détection doit être relue ligne à ligne et validée sur un jeu de données connu. Le troisième est la synthèse trop assurée : le ton affirmatif de la restitution incite à clore l'incident sans vérifier les journaux sources, ce qui est précisément le comportement à proscrire sur un compte privilégié.

Gouvernance, audit et responsabilité de la décision

Les interactions Copilot sont journalisées dans le journal d'audit unifié et doivent être intégrées au périmètre de supervision au même titre que les autres actions d'administration. Deux règles simples s'imposent : ne jamais coller de données personnelles hors périmètre dans un prompt, et conserver la trace des requêtes ayant fondé une décision de remédiation. Sur le plan de la responsabilité, la position à tenir devant un comité de sécurité est nette : Copilot accélère la mise en contexte, il ne transfère pas la responsabilité de la décision. La qualification finale d'une compromission reste un acte d'analyste, engageant l'organisation.

Questions fréquentes

Quelles licences Entra ID sont nécessaires pour exploiter Copilot Security sur les identités ?

Microsoft Security Copilot se souscrit indépendamment, sous forme de capacité provisionnée en SCU facturées à l'heure, sans dépendance à une licence Microsoft 365 particulière. En revanche, la valeur de la brique Entra dépend directement des données disponibles : Entra ID P2 est indispensable pour bénéficier des détections ID Protection détaillées, des politiques de risque et de PIM. En P1, vous conservez l'accès conditionnel et les journaux, mais perdez la granularité des événements de risque qui fait l'essentiel de l'analyse décrite ici. Ajoutez une rétention étendue via Log Analytics si vos investigations dépassent la fenêtre native de 30 jours.

Copilot Security peut-il détecter un vol de token que Entra ID Protection n'a pas signalé ?

Non, et cette distinction est structurante. Copilot n'exécute pas de moteur de détection propre : il interroge les données produites par ID Protection, Defender XDR et les journaux Entra. Si aucune détection anomalousToken n'a été générée, Copilot ne l'inventera pas. Sa valeur ajoutée est la corrélation transversale : rapprocher un signal faible non alertant — connexion depuis un ASN inhabituel — d'un second signal faible — ajout d'une méthode MFA — pour faire émerger un motif qu'aucune règle unitaire n'aurait déclenché. La couverture de détection reste déterminée par vos licences et votre instrumentation, pas par Copilot.

Combien de SCU faut-il provisionner pour un SOC qui traite des incidents d'identité au quotidien ?

Il n'existe pas de règle universelle, la consommation dépendant de la longueur des prompts, du nombre de plugins sollicités et du volume de données parcourues. Le retour terrain sur des tenants de 5 000 à 20 000 identités converge vers 2 à 3 SCU pour un usage réactif d'investigation, et 4 à 6 SCU dès que les promptbooks sont exécutés systématiquement à l'ouverture d'incident ou déclenchés par automatisation. Provisionnez bas, mesurez la consommation réelle sur un mois via le tableau de bord d'utilisation, puis ajustez : la capacité est modifiable en cours de mois dans les deux sens.

Comment révoquer efficacement toutes les sessions d'un compte administrateur compromis ?

La séquence est impérative : réinitialiser le mot de passe d'abord — hors bande si la messagerie est compromise — puis exécuter Revoke-MgUserSignInSession pour invalider les jetons d'actualisation. Sans CAE, les jetons d'accès déjà émis restent valides jusqu'à 60 à 90 minutes ; désactivez temporairement le compte avec Update-MgUser -AccountEnabled:$false si ce délai est inacceptable. Poursuivez impérativement par la suppression des méthodes MFA ajoutées par l'attaquant, le retrait des appareils enregistrés inconnus, et surtout l'audit des credentials ajoutés aux principaux de service : cette persistance-là survit intégralement à la révocation de sessions.

Faut-il faire confiance aux requêtes KQL générées par Copilot Security ?

Comme point de départ, oui ; comme livrable de détection, jamais sans relecture. Les erreurs observées ne sont presque jamais syntaxiques — la requête s'exécute — mais sémantiques : jointure sur un champ homonyme, filtre excluant silencieusement les échecs d'authentification, fenêtre temporelle ancrée sur l'horodatage de détection plutôt que d'occurrence. Le protocole raisonnable consiste à faire expliquer la requête par Copilot lui-même, à la valider sur un jeu de données dont vous connaissez le résultat attendu, puis à la versionner dans votre dépôt de règles avec un commentaire d'intention. Le gain de temps reste considérable, à condition que la validation ne soit pas optionnelle.