Audit Avancé Microsoft 365 : Guide Audit Sécurité 2026

L'audit avancé Microsoft 365 sécurité 2026 n'est pas une liste de réglages à vérifier dans une interface graphique — c'est une capacité d'investigation que vous devez développer avant d'en avoir besoin. J'ai eu à conduire des investigations post-incident sur des tenants M365 compromis : à chaque fois, les attaquants avaient suivi le même schéma — compromission d'un compte utilisateur standard, élévation de privilèges via une application OAuth malveillante ou des règles de délégation, exfiltration silencieuse de données sur plusieurs semaines avant que quiconque ne remarque. Ce guide d'audit avancé Microsoft 365 vous donne les outils et les scripts PowerShell pour détecter ces scénarios d'attaque, analyser les journaux de sécurité avec les bonnes requêtes, appliquer le CIS Microsoft 365 Benchmark, et identifier les indicateurs de compromission dans votre Unified Audit Log. On est en 2026 : les attaquants connaissent M365 aussi bien que vos administrateurs — voire mieux. Il est temps que vos capacités d'audit avancé soient à la hauteur.

Script PowerShell d'audit complet Microsoft 365

Voici le script que j'utilise comme point de départ sur chaque audit M365. Il couvre les 4 axes fondamentaux en moins de 15 minutes d'exécution : export du Unified Audit Log, vérification du coverage MFA, audit des permissions OAuth et analyse des connexions risquées. Adaptez les paramètres à votre environnement — notamment le UserPrincipalName du compte admin et les chemins d'export.

# ============================================================
# Script Audit Avancé Microsoft 365 — Ayi NEDJIMI Consultants
# Version 2026 — Requiert ExchangeOnlineManagement + Microsoft.Graph
# ============================================================

# PRÉREQUIS : Installer les modules si nécessaire
# Install-Module ExchangeOnlineManagement -Force
# Install-Module Microsoft.Graph -Force

# Connexion M365 — Exchange Online et Microsoft Graph
$adminUPN = "[email protected]"
Connect-ExchangeOnline -UserPrincipalName $adminUPN -ShowBanner:$false
Connect-MgGraph -Scopes "AuditLog.Read.All","Policy.Read.All","User.Read.All",
    "DeviceManagementManagedDevices.Read.All","Application.Read.All" -NoWelcome

Write-Host "=== AUDIT M365 EN COURS ===" -ForegroundColor Cyan
$exportPath = "C:\\AuditM365_$(Get-Date -Format 'yyyyMMdd')"
New-Item -ItemType Directory -Path $exportPath -Force | Out-Null

# ---- 1. EXPORT UNIFIED AUDIT LOG (30 derniers jours) ----
Write-Host "[1/4] Export Unified Audit Log..." -ForegroundColor Yellow
$startDate = (Get-Date).AddDays(-30)
$endDate = Get-Date

# Vérifier que l'UAL est activé
$ualStatus = Get-AdminAuditLogConfig | Select-Object -ExpandProperty UnifiedAuditLogIngestionEnabled
if (-not $ualStatus) {
    Write-Warning "CRITIQUE: Unified Audit Log NON ACTIVÉ. Activation..."
    Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
}

# Export des opérations critiques
$criticalOps = @(
    "MailboxLogin","FileDownloaded","FileSyncDownloadedFull",
    "Add member to role.","Update user.","Reset user password.",
    "Set delegation entry.","New-InboxRule","Set-InboxRule",
    "Add app role assignment to service principal.",
    "UpdatedDelegateInfo","SendAs","SendOnBehalf"
)
$auditLog = Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate `
    -Operations $criticalOps -ResultSize 5000
$auditLog | Export-Csv -Path "$exportPath\\unified_audit_log.csv" -NoTypeInformation
Write-Host "  → $($auditLog.Count) événements exportés" -ForegroundColor Green

# ---- 2. VÉRIFICATION MFA PAR UTILISATEUR ----
Write-Host "[2/4] Audit coverage MFA..." -ForegroundColor Yellow
$allUsers = Get-MgUser -All -Filter "accountEnabled eq true" `
    -Property DisplayName,UserPrincipalName,Id,SignInActivity
$mfaReport = foreach ($user in $allUsers) {
    $authMethods = Get-MgUserAuthenticationMethod -UserId $user.Id
    # Exclure les méthodes password seul
    $mfaMethods = $authMethods | Where-Object {
        $_.'@odata.type' -ne '#microsoft.graph.passwordAuthenticationMethod'
    }
    [PSCustomObject]@{
        DisplayName       = $user.DisplayName
        UPN               = $user.UserPrincipalName
        MFAMethodCount    = $mfaMethods.Count
        MFAConfigured     = ($mfaMethods.Count -gt 0)
        LastSignIn        = $user.SignInActivity.LastSignInDateTime
    }
}
# Exporter les utilisateurs SANS MFA
$noMFA = $mfaReport | Where-Object {-not $_.MFAConfigured}
$noMFA | Export-Csv -Path "$exportPath\\users_no_mfa.csv" -NoTypeInformation
Write-Host "  → $($noMFA.Count) utilisateurs sans MFA sur $($allUsers.Count) actifs" -ForegroundColor $(if($noMFA.Count -gt 0){'Red'}else{'Green'})

# ---- 3. AUDIT PERMISSIONS OAUTH APPLICATIONS ----
Write-Host "[3/4] Audit permissions OAuth..." -ForegroundColor Yellow
$oauthGrants = Get-MgOauth2PermissionGrant -All
$dangerousScopes = @("Mail.ReadWrite","Mail.Read","Files.ReadWrite.All","User.ReadWrite.All","Directory.ReadWrite.All")
$riskyApps = $oauthGrants | Where-Object {
    $scope = $_.Scope
    $dangerousScopes | Where-Object { $scope -like "*$_*" }
}
$riskyApps | Select-Object ClientId, ConsentType, Scope, PrincipalId |
    Export-Csv -Path "$exportPath\\oauth_risky_permissions.csv" -NoTypeInformation
Write-Host "  → $($riskyApps.Count) applications avec permissions à risque élevé" -ForegroundColor $(if($riskyApps.Count -gt 0){'Red'}else{'Green'})

# ---- 4. CONNEXIONS RISQUÉES (Entra ID Identity Protection) ----
Write-Host "[4/4] Analyse connexions risquées..." -ForegroundColor Yellow
$riskySignIns = Get-MgAuditLogSignIn `
    -Filter "riskLevelDuringSignIn ne 'none' or riskLevelAggregated ne 'none'" -All
$riskySignIns | Select-Object UserPrincipalName, RiskLevelDuringSignIn,
    RiskLevelAggregated, RiskState, AppDisplayName, IPAddress, Location, CreatedDateTime |
    Export-Csv -Path "$exportPath\risky_signins.csv" -NoTypeInformation
Write-Host "  → $($riskySignIns.Count) connexions risquées détectées" -ForegroundColor $(if($riskySignIns.Count -gt 10){'Red'}elseif($riskySignIns.Count -gt 0){'Yellow'}else{'Green'})

Write-Host "`n=== AUDIT TERMINÉ ===" -ForegroundColor Cyan
Write-Host "Rapports exportés dans : $exportPath" -ForegroundColor White
Disconnect-ExchangeOnline -Confirm:$false
Disconnect-MgGraph

Microsoft 365 Security Center — navigation avancée pour les investigations

Le portail security.microsoft.com est la console centrale pour l'investigation M365. Les fonctionnalités avancées que peu d'administrateurs exploitent réellement :

Incidents consolidés : M365 Defender corrèle automatiquement les alertes de différents composants (Exchange, Teams, Entra ID, Defender for Endpoint) en incidents. Un incident peut regrouper un email de phishing, la connexion depuis un IP suspect, et le téléchargement massif de fichiers SharePoint — trois alertes distinctes qui racontent une seule histoire d'attaque.

Advanced Hunting (KQL) : le moteur de recherche sur les données des 30 derniers jours. Pour les utilisateurs avec Defender Plan 2, c'est l'outil d'investigation le plus puissant de l'écosystème M365. Exemple de requête pour détecter les connexions depuis de nouveaux pays :

# Requête KQL — Advanced Hunting (dans security.microsoft.com)
# Détecter les connexions depuis des localisations inhabituelle pour un utilisateur
# (à exécuter dans l'interface Advanced Hunting, pas en PowerShell)

# AADSignInEventsBeta
# | where Timestamp > ago(30d)
# | where AccountUpn endswith "@votredomaine.fr"
# | summarize Countries = make_set(Country) by AccountUpn
# | where array_length(Countries) > 2
# | project AccountUpn, Countries

# Pour les règles de détection automatique :
# Créer une Custom Detection Rule qui alerte dès qu'un utilisateur
# se connecte depuis plus de 2 pays différents en 24h

Threat Analytics : rapports des équipes de Threat Intelligence Microsoft sur les campagnes actives ciblant M365. Je consulte cette section en priorité lors de chaque audit — elle signale les groupes APT actuellement actifs contre les tenants O365/M365 français.

CIS Microsoft 365 Benchmark — Level 1 vs Level 2

Le CIS Microsoft 365 Benchmark (disponible gratuitement sur cisecurity.org) est la référence normative que j'utilise dans tous mes audits M365 comme base de comparaison. Il se décline en deux niveaux :

Level 1 (Basique, applicable immédiatement) : contrôles à fort rapport bénéfice/risque, sans impact sur la productivité. Les 5 contrôles Level 1 les plus impactants :

• CIS 1.1.1 : Activer MFA pour tous les utilisateurs — implémentable en 30 minutes via Security Defaults ou Conditional Access
• CIS 1.1.3 : Bloquer l'authentification héritée — après identification des apps impactées, déploiement en une policy CA
• CIS 2.1.9 : Activer DMARC avec p=reject — processus DNS sur 2-4 semaines de validation
• CIS 3.1.1 : Activer le Unified Audit Log — 30 secondes de PowerShell
• CIS 5.1.2 : Limiter les Global Admins à moins de 5 et activer PIM — réorganisation des rôles administratifs

Level 2 (Strict, impact potentiel sur la productivité) : contrôles plus restrictifs adaptés aux environnements à forte sensibilité. Exemples : désactiver complètement le partage externe SharePoint, exiger des MFA hardware token pour les admins, activer le chiffrement de bout en bout Teams uniquement. À réserver aux environnements réglementés (RGPD renforcé, données de santé, secteur financier).

L'écart moyen entre un tenant non-optimisé et un tenant Level 1 CIS représente environ 25 points de Secure Score. Consultez notre article M365 conformité et outils d'audit pour les outils d'évaluation automatique du CIS Benchmark.

Entra ID — audit avancé des privilèges avec PIM

La gestion des identités privilegiées (PIM — Privileged Identity Management) est la fonctionnalité Entra ID P2 qui transforme radicalement votre exposition aux attaques par vol de compte admin. Sans PIM, vos Global Admins ont leurs privilèges en permanence — si leur compte est compromis à 2h du matin, l'attaquant dispose immédiatement de tous les droits d'administration. Avec PIM, les rôles privilégiés sont inactifs par défaut et s'activent à la demande pour une durée limitée, avec justification obligatoire et approbation possible.

L'audit PIM que je conduis sur chaque tenant :

# Audit des rôles privilégiés permanents (sans PIM)
Connect-MgGraph -Scopes "RoleManagement.Read.All","User.Read.All"

# Lister tous les rôles actifs permanents (pas via PIM)
$directoryRoles = Get-MgDirectoryRole
foreach ($role in $directoryRoles) {
    $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
    if ($members.Count -gt 0) {
        Write-Host "Rôle: $($role.DisplayName) ($($members.Count) membres)" -ForegroundColor Yellow
        $members | ForEach-Object {
            $user = Get-MgUser -UserId $_.Id -ErrorAction SilentlyContinue
            if ($user) { Write-Host "  - $($user.UserPrincipalName)" }
        }
    }
}

# Identifier les guest users inactifs depuis >90 jours
$guestUsers = Get-MgUser -Filter "userType eq 'Guest'" -All `
    -Property DisplayName,UserPrincipalName,Id,SignInActivity,CreatedDateTime
$inactiveGuests = $guestUsers | Where-Object {
    $_.SignInActivity.LastSignInDateTime -lt (Get-Date).AddDays(-90) -or
    $null -eq $_.SignInActivity.LastSignInDateTime
}
Write-Host "`nGuests inactifs depuis +90j : $($inactiveGuests.Count)"
$inactiveGuests | Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N='LastSignIn';E={$_.SignInActivity.LastSignInDateTime}} |
    Export-Csv "inactive_guests.csv" -NoTypeInformation

Les Access Reviews (révisions d'accès) permettent d'automatiser ce nettoyage : Entra ID envoie périodiquement aux propriétaires de groupes et d'applications une liste d'utilisateurs à valider. Les invités non-validés sont automatiquement supprimés au bout de 30 jours.

OAuth app permissions — l'angle mort le plus dangereux de M365

Les applications OAuth tierces connectées à votre tenant M365 représentent un angle mort que la majorité des organisations ne surveille pas. Un utilisateur peut consentir à une application tierce (add-in Outlook, extension Chrome, outil de productivité) qui obtient des permissions Mail.ReadWrite ou Files.ReadWrite.All — ce qui donne à cette application un accès complet à la messagerie et aux fichiers de l'utilisateur, sans que l'équipe IT en soit informée.

Les attaquants exploitent ce vecteur via des techniques de "consent phishing" : envoyer un email invitant l'utilisateur à authoriser une application malveillante qui semble légitime. Une fois le consentement accordé, l'application peut exfiltrer les données M365 de manière indépendante de l'authentification de l'utilisateur — le token OAuth reste valide même si le mot de passe est changé.

# Audit complet des permissions OAuth dans Azure AD / Entra ID
Connect-MgGraph -Scopes "Application.Read.All","DelegatedPermissionGrant.Read.All"

# 1. Lister toutes les applications avec des permissions déléguées
$allGrants = Get-MgOauth2PermissionGrant -All
$serviceprincipals = Get-MgServicePrincipal -All

$appReport = foreach ($grant in $allGrants) {
    $sp = $serviceprincipals | Where-Object {$_.Id -eq $grant.ClientId}
    [PSCustomObject]@{
        AppName     = $sp.DisplayName
        AppId       = $sp.AppId
        ConsentType = $grant.ConsentType  # "AllPrincipals" = admin consent (danger)
        Scopes      = $grant.Scope
        PrincipalId = $grant.PrincipalId
        IsHighRisk  = ($grant.Scope -match "Mail.ReadWrite|Files.ReadWrite.All|User.ReadWrite.All|Directory.ReadWrite.All")
    }
}

# Apps avec permissions admin (toute l'organisation)
$adminConsentApps = $appReport | Where-Object {$_.ConsentType -eq "AllPrincipals"}
Write-Host "Apps avec consentement admin : $($adminConsentApps.Count)"
$adminConsentApps | Where-Object {$_.IsHighRisk} | Format-Table AppName, Scopes, IsHighRisk

# 2. Révoquer une permission OAuth suspecte (à adapter avec le bon ID)
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "ID_DU_GRANT"

Ma recommandation : activer la politique "Require admin approval for user consent" dans Entra ID. Tous les nouveaux consentements d'applications passeront par une approbation administrative avant d'être accordés. C'est la mesure la plus efficace contre le consent phishing.

Détection des règles Inbox malveillantes — technique d'attaque silencieuse

Une fois qu'un attaquant a compromis un compte M365, l'une de ses premières actions est de créer une règle Inbox qui transfère automatiquement les emails vers une adresse externe ou qui supprime les alertes de sécurité. Cette technique est simple, silencieuse et souvent non-détectée pendant des semaines — voire des mois.

Dans une investigation réelle sur un incident BEC, j'ai découvert qu'une directrice financière avait une règle Inbox créée 47 jours avant que l'attaque soit découverte. La règle transférait tous les emails contenant les mots "virement", "facture" et "IBAN" vers une adresse Gmail externe. Pendant 47 jours, l'attaquant avait intercepté les communications avec les fournisseurs et modifié les coordonnées bancaires.

# Auditer les règles Inbox sur toutes les boites aux lettres
Connect-ExchangeOnline -UserPrincipalName [email protected] -ShowBanner:$false

# Récupérer toutes les boîtes aux lettres
$mailboxes = Get-Mailbox -ResultSize Unlimited | Select-Object PrimarySmtpAddress

$suspiciousRules = foreach ($mb in $mailboxes) {
    $rules = Get-InboxRule -Mailbox $mb.PrimarySmtpAddress -ErrorAction SilentlyContinue
    foreach ($rule in $rules) {
        # Détecter les règles avec forwarding, redirection ou suppression automatique
        if ($rule.ForwardTo -or $rule.RedirectTo -or $rule.ForwardAsAttachmentTo -or
            $rule.DeleteMessage -eq $true -or $rule.MoveToFolder -eq "Deleted Items") {
            [PSCustomObject]@{
                Mailbox          = $mb.PrimarySmtpAddress
                RuleName         = $rule.Name
                Enabled          = $rule.Enabled
                ForwardTo        = $rule.ForwardTo -join "; "
                RedirectTo       = $rule.RedirectTo -join "; "
                DeleteMessage    = $rule.DeleteMessage
                CreatedDate      = $rule.WhenCreated
                Priority         = $rule.Priority
            }
        }
    }
}

if ($suspiciousRules) {
    Write-Warning "RÈGLES SUSPECTES DÉTECTÉES :"
    $suspiciousRules | Format-Table -AutoSize
    $suspiciousRules | Export-Csv "suspicious_inbox_rules.csv" -NoTypeInformation
} else {
    Write-Host "Aucune règle de forwarding/redirection détectée." -ForegroundColor Green
}

# Vérifier aussi les règles créées récemment (30 derniers jours via UAL)
$recentRules = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -Operations "New-InboxRule","Set-InboxRule","UpdateInboxRules" -ResultSize 1000
$recentRules | Export-Csv "recent_inbox_rules_changes.csv" -NoTypeInformation
Write-Host "Modifications de règles Inbox (30j) : $($recentRules.Count)"

Comment détecter une compromission de compte M365 avec les logs ?

Un compte M365 compromis laisse des traces caractéristiques dans les logs — à condition de savoir où chercher et quoi chercher. Voici les indicateurs de compromission que je recherche en priorité lors d'une investigation :

Connexions depuis des localisations impossibles : connexion depuis Paris à 09h00 et connexion depuis une IP russe à 09h15 — impossible pour un même utilisateur physique. Ce pattern "impossible travel" est automatiquement détecté par Entra ID Identity Protection si la licence l'inclut.

Volume anormal de lectures d'email : un utilisateur qui lit soudainement 2000 emails en 30 minutes n'est probablement pas un utilisateur humain — c'est un script automatisé d'exfiltration. Cherchez dans le UAL les opérations MailItemsAccessed avec des volumes inhabituels.

Création de règles Inbox suspectes : comme détaillé ci-dessus, cherchez les opérations New-InboxRule et Set-InboxRule dans le UAL, surtout si elles contiennent des adresses externes dans les champs ForwardTo ou RedirectTo.

Ajout de délégations ou d'autorisations SendAs : l'opération Add-MailboxPermission ou Set-MailboxPermission accordant un accès "FullAccess" ou "SendAs" à un compte externe est un indicateur fort de compromission.

Enregistrement d'un nouveau device MFA : si un attaquant a accès au compte, il peut enregistrer son propre authenticator. Chercher UserRegisteredSecurityInfo dans le UAL.

Pour une approche structured de la détection d'attaques, consultez notre article sur la détection d'attaques M365 et Azure AD.

Quels sont les indicateurs de compromission dans le Unified Audit Log ?

Les Indicateurs de Compromission (IoC) dans le contexte M365 sont des événements spécifiques du Unified Audit Log qui signalent avec une haute probabilité qu'un compte ou un tenant a été compromis. Voici les principaux :

• MailItemsAccessed avec ResultStatus=Failed puis réussi depuis une IP différente — pattern de credential stuffing
• FileDownloaded + FileSyncDownloadedFull en volume élevé (>500 fichiers/heure) depuis une IP externe
• Add-MailboxPermission accordant FullAccess à un compte non-reconnu
• New-InboxRule avec ForwardTo vers un domaine externe
• Add app role assignment to service principal — application OAuth ajoutée
• Reset user password depuis une IP inconnue, surtout si suivi d'une connexion depuis un pays différent
• Update user modifiant le numéro de téléphone MFA ou l'email de récupération
• UserRegisteredSecurityInfo — enregistrement d'un nouveau device MFA

# Script de chasse aux IoC — recherche des indicateurs de compromission courants
Connect-ExchangeOnline -UserPrincipalName [email protected]

$startDate = (Get-Date).AddDays(-30)
$endDate = Get-Date

# Regrouper les IoC critiques
$iocOps = @(
    "Add-MailboxPermission",
    "Set-MailboxPermission",
    "New-InboxRule",
    "Set-InboxRule",
    "UserRegisteredSecurityInfo",
    "Add app role assignment to service principal."
)

foreach ($op in $iocOps) {
    $results = Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate `
        -Operations $op -ResultSize 200
    if ($results.Count -gt 0) {
        Write-Host "[$op] : $($results.Count) événements" -ForegroundColor Red
        $results | Select-Object CreationDate, UserIds, Operations |
            Export-Csv "ioc_$($op.Replace('/','_').Replace(' ','_')).csv" -NoTypeInformation
    }
}

Tableau — Types d'attaques M365 et méthodes de détection

Sentinel et la corrélation avancée des logs M365

Microsoft Sentinel transforme l'audit ponctuel en surveillance continue. Pour les organisations avec un volume d'événements M365 significatif, les règles d'analyse intégrées de Sentinel détectent automatiquement les patterns d'attaque documentés ci-dessus. Notre article sur le Threat Hunting M365 avec Sentinel couvre les règles KQL avancées et les playbooks d'automatisation.

La documentation de référence pour l'audit avancé : Microsoft Purview Audit Log Search et les recommandations CISA sur la sécurité cloud. Pour les corrélations avancées, voir également notre guide audit avancé M365 corrélation journaux.

Questions fréquentes sur l'audit avancé Microsoft 365

Comment exporter le Unified Audit Log sur 90 jours en PowerShell ?

La cmdlet Search-UnifiedAuditLog accepte des plages de dates allant jusqu'à 90 jours en arrière (licence E3) ou 180 jours (E5). Limitation importante : elle retourne au maximum 5000 résultats par requête. Pour exporter l'intégralité des événements sur 90 jours, il faut paginer par intervalles de temps (exemple : 1 jour à la fois) et utiliser le paramètre SessionCommand avec ReturnLargeSet. Pour les volumes très importants, privilégiez l'API Graph ou l'export direct depuis Microsoft Purview Compliance Portal (Content Search > Export).

Qu'est-ce que le CIS M365 Benchmark Level 1 et comment l'appliquer ?

Le CIS M365 Benchmark Level 1 comprend 36 contrôles prioritaires couvrant : les politiques d'authentification (MFA, auth héritée), la configuration Exchange Online (DMARC, transport rules, Safe Attachments), les paramètres SharePoint/OneDrive (partage externe, DLP), la configuration Teams, et les paramètres Entra ID (PIM, access reviews). Pour l'appliquer : téléchargez le document CIS sur cisecurity.org (gratuit avec inscription), passez chaque contrôle en revue avec les scripts PowerShell associés, et utilisez le CIS-CAT Pro ou l'outil Secure Score pour mesurer votre conformité actuelle. Un audit M365 par rapport au CIS L1 prend typiquement 2 jours de travail initial.

Comment détecter des règles Inbox malveillantes dans Exchange Online ?

Deux approches complémentaires : 1) Scan direct via Get-InboxRule -Mailbox "*" sur toutes les boîtes aux lettres — rechercher les propriétés ForwardTo, RedirectTo, DeleteMessage et MoveToFolder = "Deleted Items". 2) Recherche dans le UAL des opérations New-InboxRule et Set-InboxRule sur les 30-90 derniers jours. La deuxième approche permet de détecter des règles créées puis supprimées après exfiltration. Voir le script complet dans la section dédiée de cet article.

Comment auditer les applications OAuth dans Azure AD / Entra ID ?

Via PowerShell avec le module Microsoft.Graph : Connect-MgGraph -Scopes "Application.Read.All" puis Get-MgOauth2PermissionGrant -All. Filtrez les permissions dangereuses : Mail.ReadWrite, Files.ReadWrite.All, User.ReadWrite.All, Directory.ReadWrite.All. Portez une attention particulière aux grants de type "AllPrincipals" (consentement admin donné pour toute l'organisation) — ces applications ont accès aux données de tous les utilisateurs. La mesure préventive la plus efficace est d'activer "Require admin approval for user consent" dans Entra ID > Enterprise Applications > Consent and permissions.