Microsoft Sentinel dans le portail Defender : ce qu’il faut préparer avant le 31 mars 2027

Après le 31 mars 2027, Microsoft Sentinel ne sera plus pris en charge dans le portail Azure et ne sera disponible que dans le portail Microsoft Defender. Microsoft écrit que tous les clients qui l’utilisent encore dans le portail Azure seront redirigés vers le portail Defender. Le produit y est en disponibilité générale, y compris pour les clients qui n’ont ni Microsoft Defender XDR ni licence E5, et Microsoft indique que le passage n’entraîne aucun coût supplémentaire, la consommation de Microsoft Sentinel restant facturée comme avant.

En revanche, le fonctionnement change : les incidents passent par le moteur de corrélation de Defender XDR, plusieurs conditions des règles d’automatisation cessent de s’appliquer, et la connexion d’un espace de travail demande des rôles précis sur l’abonnement et dans Microsoft Entra ID.

Relevé le 29 septembre 2026 sur la documentation Microsoft.

Connecter un espace de travail : les rôles demandés

Quand la connexion au portail Defender n’est pas automatique, elle se fait sous System > Settings > Microsoft Sentinel > Connect a workspace, en choisissant les espaces puis l’espace principal. Un client qui utilise Microsoft Sentinel sans Defender XDR doit effectuer une étape de plus pour déclencher la connexion.

La connexion demande un rôle Owner attribué sans condition au niveau de l’abonnement, ou la combinaison User Access Administrator et Microsoft Sentinel Contributor. Le tableau de Microsoft cite aussi le rôle Microsoft Entra Security Administrator, au niveau du tenant, et sa note précise qu’il est exigé dès que le tenant compte plus d’un espace de travail avec Microsoft Sentinel.

Une fois l’espace connecté, les permissions Azure RBAC existantes continuent de s’appliquer. Microsoft demande de gérer les rôles des utilisateurs de Microsoft Sentinel depuis le portail Azure, et chaque modification se reflète dans le portail Defender. La connexion attribue aussi le rôle Microsoft Sentinel Contributor aux applications Microsoft Threat Protection et WindowsDefenderATP dans l’abonnement.

Pour les données Microsoft Sentinel dans le portail Defender, Microsoft ne prend pas en charge GDAP avec Azure Lighthouse et renvoie à l’authentification Microsoft Entra B2B. La table IdentityInfo devient une table native de Defender, sans contrôle d’accès au niveau de la table : une restriction posée à ce niveau dans le portail Azure disparaît au passage. Pour cloisonner les données sans séparer les espaces, Microsoft propose le scoping, un RBAC au niveau des lignes en preview, configuré dans le portail Defender avec Unified RBAC.

Sans les capacités Defender activées, Microsoft liste trois capacités limitées ou indisponibles

Avec Defender XDR, les pages Home, Incidents et Advanced hunting combinent les données de Microsoft Sentinel et de Defender XDR ; sans Defender XDR, elles n’affichent que celles de Microsoft Sentinel. Quand Microsoft Sentinel est connecté au portail Defender sans les capacités Defender ni d’autres services, Microsoft indique que trois capacités sont limitées ou indisponibles : Microsoft Security Exposure Management, les custom detection rules et l’Action center, ces deux dernières étant fournies par Microsoft Defender.

Les politiques de données changent aussi. Dans le portail Defender, ce sont celles de Microsoft Defender XDR qui régissent le stockage, le traitement, la rétention et le partage, y compris pour les données de Microsoft Sentinel. Pour un espace chiffré par clé gérée par le client (CMK), les journaux et les règles restent chiffrés par CMK, mais les alertes et les incidents ne le sont plus après la connexion.

Règles d’analyse : le moteur de corrélation de Defender XDR remplace Fusion

Les règles d’analyse se créent et se gèrent comme avant, par l’assistant, les repositories ou l’API Microsoft Sentinel. Mais dans le portail Defender, tous les incidents, y compris ceux des règles de Microsoft Sentinel, sont générés par le moteur de Defender XDR. La règle Fusion est désactivée à la connexion, et ce moteur reprend la corrélation qu’elle assurait. Plusieurs comportements changent :

• le regroupement des alertes et la fusion des incidents sont pilotés par le moteur de Defender XDR, même si le réglage reste visible dans la règle : des règles qui créent un incident par alerte peuvent produire des incidents fusionnés ;
• les alertes d’une règle configurée pour générer des alertes seulement, sans incident, ne sont pas visibles dans le portail Defender ;
• les règles actives de création d’incidents Microsoft sont désactivées pour éviter les doublons ;
• le regroupement des alertes ne peut plus être réglé pour rouvrir un incident fermé : les nouvelles alertes créent de nouveaux incidents.

Règles d’automatisation : la condition Incident provider disparaît, et trois autres changent

Les playbooks restent des workflows Azure Logic Apps. Ce sont les règles d’automatisation qui les lancent qui changent : dans le portail Defender, une règle avec un déclencheur d’alerte n’agit que sur les alertes de Microsoft Sentinel, et Microsoft renvoie à l’Enhanced Alert Trigger pour les alertes Defender XDR.

La condition Incident provider disparaît, dans le portail Azure comme dans le portail Defender, parce que tous les incidents portent Microsoft XDR dans le champ ProviderName. Les règles existantes s’exécutent alors sur les incidents de Microsoft Sentinel comme sur ceux de Defender XDR, y compris celles qui visaient un seul fournisseur. Pour limiter une règle aux incidents de Microsoft Sentinel, Microsoft conseille la condition Analytic rule name, avec une règle d’analyse qui n’existe que dans Microsoft Sentinel. D’autres conditions sont touchées :

• la table SecurityIncident ne contient plus de champ Description : une règle qui s’en sert comme condition ne fonctionne plus, et un outil de ticketing comme ServiceNow ne reçoit plus la description ;
• les titres des incidents peuvent changer quand la corrélation s’applique, et Microsoft recommande de ne pas les employer comme condition, au profit du nom de la règle d’analyse et des tags ;
• dans le champ Updated by, la valeur Microsoft 365 Defender devient Other.

Les délais changent aussi. Une règle d’automatisation peut s’exécuter jusqu’à 10 minutes après le déclenchement de l’alerte, parce que l’incident naît dans le portail Defender avant d’être transmis à Microsoft Sentinel. Si plusieurs modifications touchent le même incident en 5 à 10 minutes, une seule mise à jour part, avec la dernière modification, et les états intermédiaires sont perdus.

Lancer un playbook à la main sur une alerte ou une entité n’est actuellement pas pris en charge dans le portail Defender, et une règle d’automatisation ne s’y crée pas depuis un incident, mais depuis la page Automation. Les incidents créés par l’API, par un playbook Logic Apps ou manuellement dans le portail Azure ne sont pas synchronisés vers le portail Defender.

Workbooks, hunting et API : bookmarks, Workspace manager et providerName

Les workbooks restent l’outil principal de visualisation et fonctionnent comme dans le portail Azure ; pour y afficher des données d’Advanced hunting, les journaux doivent être ingérés dans Microsoft Sentinel. Les tables, requêtes KQL et fonctions existantes restent utilisables dans Advanced hunting, mais les bookmarks n’y sont pas disponibles : ils restent sous Microsoft Sentinel > Threat management > Hunting. La table IdentityInfo d’Advanced hunting renomme ou ne prend pas en charge certains champs, et les requêtes qui tournent dans Microsoft Defender, notamment les custom detections, sont à revoir. Le Workspace manager n’est pas disponible dans le portail Defender ; Microsoft propose le déploiement de contenu depuis un repository, en preview, ou le portail multitenant.

Côté API, le corps de réponse de SecurityInsights change : providerName passe de « Azure Sentinel » à « Microsoft XDR », et un champ providerIncidentUrl s’ajoute. Pour les incidents et alertes unifiés, Microsoft recommande l’API Microsoft Graph ; l’API Microsoft Sentinel reste prise en charge pour les règles et les autres ressources.

Plusieurs espaces de travail : le connecteur Defender XDR ne se connecte qu’à l’espace principal

Le portail Defender accepte un espace principal et plusieurs espaces secondaires par tenant. Le connecteur Defender XDR n’est relié qu’à l’espace principal, et la connexion déconnecte automatiquement, dans les espaces secondaires, les connecteurs autonomes de Microsoft Defender for Office 365, Microsoft Entra ID Protection, Microsoft Defender for Cloud Apps, Microsoft Defender for Endpoint et Microsoft Defender for Identity. Les alertes de ces produits ne sont alors disponibles que dans l’espace principal, et seules les alertes de cet espace sont corrélées avec Defender XDR. Microsoft demande de transférer les règles d’automatisation vers l’espace concerné pour qu’elles continuent de tourner. L’espace principal se change sous System > Settings > Microsoft Sentinel > Workspaces, avec Set as primary.

Clients gérés par un MSSP : l’onboarding automatique annoncé pour septembre 2026

Le 9 septembre 2026, Microsoft a annoncé aux partenaires qu’elle commencerait, à partir de septembre 2026, à connecter automatiquement au portail Defender les clients gérés qui n’y sont pas passés. Microsoft gère le calendrier, les notifications et la connexion technique ; les administrateurs du tenant reçoivent un bandeau dans le portail et un e-mail environ 30 jours avant. Les connecteurs tiers, le contenu et les données restent en place.

Pour un client à plusieurs espaces, c’est Microsoft qui choisit l’espace principal, et le contenu qui dépend de Defender XDR dans les espaces secondaires peut cesser de fonctionner. Microsoft conseille de migrer vers l’espace principal les règles d’analyse, les règles d’automatisation, les playbooks et les workbooks concernés. Pour demander un autre espace principal, l’annonce indique d’écrire à [email protected] avec l’identifiant du tenant et l’identifiant de ressource de l’espace souhaité.

Onboarding après le 23 septembre 2026 : le data lake ne demande aucun onboarding séparé

Pour les clients qui font leur onboarding après le 23 septembre 2026, le Microsoft Sentinel data lake est intégré à Microsoft Sentinel comme niveau d’ingestion et de stockage à bas coût pour la rétention longue, sans onboarding ni configuration de facturation séparés. On termine l’onboarding de Microsoft Sentinel, on vérifie que l’espace est connecté au portail Defender, puis on active le niveau data lake dans Table management, en choisissant une table puis ses réglages Retention.

Pour un client existant qui n’avait pas fait l’onboarding du data lake, la rétention passe d’un modèle fondé sur l’archive à la rétention dans le data lake, que l’on interroge directement dans Advanced hunting, sans restauration. La page de Microsoft consacrée à l’onboarding du data lake signale un effet sur les coûts : pour une organisation qui utilise déjà le SIEM, la facturation de fonctions telles que les search jobs, les auxiliary logs et la rétention longue passe sur les compteurs du data lake, ce qui peut augmenter les coûts.

Notre lecture

Nous ne traiterions pas le 31 mars 2027 comme un changement d’interface. La connexion déplace la création des incidents vers le moteur de Defender XDR, et c’est là que se logent les régressions : une règle d’automatisation qui filtre sur la description ou le fournisseur de l’incident ne se comporte plus comme avant, et celle qui filtre sur le titre peut cesser de s’appliquer quand la corrélation renomme l’incident. Nous commencerions donc par l’inventaire des règles d’automatisation et des playbooks.

Dans un tenant à plusieurs espaces, nous choisirions l’espace principal avant la connexion et y déplacerions le contenu qui dépend de Defender XDR. Pour un client géré, cette décision vaut d’être prise avant que Microsoft ne la prenne lors de l’onboarding automatique. Nous vérifierions enfin le chiffrement des alertes et des incidents, qui ne relève plus de CMK après la connexion, puis les accès à IdentityInfo. Les procédures de réponse aux incidents, y compris celles qui préparent l’annonce d’une cyberattaque à l’OFCS quand l’organisation y est soumise, s’appuient sur la file d’incidents du portail Defender : elles sont à relire une fois l’espace connecté.

Ce qu’il faut vérifier

• Les rôles de la personne qui fera la connexion : Owner sans condition sur l’abonnement, ou User Access Administrator et Microsoft Sentinel Contributor, ainsi que Security Administrator dans Microsoft Entra ID, que le tableau de Microsoft cite pour la connexion et que sa note exige dès que le tenant compte plus d’un espace.
• Sans Defender XDR, l’étape supplémentaire de connexion, et l’usage éventuel d’Exposure Management, des custom detection rules ou de l’Action center.
• Le choix de l’espace principal, et le contenu des espaces secondaires qui dépend de Defender XDR.
• Les règles d’automatisation qui utilisent Incident provider, le champ Description, le titre de l’incident ou la valeur Microsoft 365 Defender dans Updated by.
• Les règles d’analyse en mode alertes seulement, et celles qui rouvrent des incidents fermés.
• Les intégrations qui lisent providerName ou la description des incidents par l’API SecurityInsights.
• Le chiffrement CMK des alertes et des incidents, les restrictions sur IdentityInfo et les accès par GDAP avec Azure Lighthouse.
• Pour un onboarding postérieur au 23 septembre 2026, l’activation du data lake dans Table management et son effet sur la facturation.

Les sources Microsoft

• Microsoft Sentinel in the Microsoft Defender portal
• Transition your Microsoft Sentinel environment to the Defender portal
• Connect Microsoft Sentinel to the Microsoft Defender portal
• What is Microsoft Sentinel security information and event management (SIEM)?
• What’s new in Microsoft Sentinel
• Partner Center announcements, September 2026
• Roles and permissions in the Microsoft Sentinel platform
• Onboard to Microsoft Sentinel data lake and Microsoft Sentinel graph
• Onboard Microsoft Sentinel to a Log Analytics workspace