Audit Sécurité Microsoft 365 | Guide Microsoft 365

L'audit sécurité Microsoft 365 guide complet que vous avez cherché sans le trouver, le voici. Je m'appelle Ayi NEDJIMI, et j'interviens sur des tenants M365 depuis que Microsoft a rebrandé Office 365 en Microsoft 365 — j'ai vu des entreprises de 50 salariés se faire compromettre intégralement en moins de 48 heures parce que leur Unified Audit Log n'était pas activé, que leur MFA ne couvrait que les administrateurs, et que leurs règles Exchange autorisaient encore l'authentification basique. Ce guide d'audit sécurité Microsoft 365 n'est pas une liste de cases à cocher : c'est une méthode de terrain pour évaluer, prioriser et corriger la posture de sécurité d'un tenant M365 en partant des risques réels. On parle de Secure Score, de Conditional Access, de Defender for Office 365, du Unified Audit Log, et de la protection email DMARC/DKIM/SPF. Pour chaque contrôle, je vous donne le risque exact si vous ne l'avez pas, et la commande PowerShell pour vérifier l'état actuel. L'objectif n'est pas la perfection théorique — c'est de réduire drastiquement la surface d'attaque exploitable par un adversaire réel en 2026.

Microsoft Secure Score — objectif ≥60% de maturité

Le Microsoft Secure Score est l'indicateur le plus rapide pour évaluer la maturité sécurité d'un tenant M365. Accessible depuis security.microsoft.com, il agrège des centaines de contrôles en un score normalisé entre 0 et 100%. Dans ma pratique, la médiane des PME françaises que j'audite tourne autour de 35 à 45% — ce qui signifie que la moitié des contrôles recommandés sont absents.

Le Secure Score se décompose en cinq catégories : Identité (Azure AD, MFA, PIM), Apps (Exchange Online, Teams, SharePoint), Données (DLP, Information Protection, Purview), Infrastructure (Defender for Cloud, Azure Security Center), et Appareils (Intune, Defender for Endpoint). Chaque action recommandée est pondérée selon son impact sur le score — un action valant 15 points mérite une attention particulière.

Les actions à fort impact que je recommande systématiquement en priorité :

• Activer le MFA pour tous les utilisateurs (pas seulement les admins)
• Bloquer l'authentification héritée via Conditional Access
• Activer le Unified Audit Log
• Activer Microsoft Defender for Office 365 Plan 1 minimum
• Configurer DMARC en policy=reject sur tous les domaines
• Activer la protection anti-phishing avec impersonation protection
• Restreindre les rôles d'administration globaux (Global Admin doit être <5 comptes)

Un score de 60% ne garantit pas l'invulnérabilité — mais il signifie que les vecteurs d'attaque les plus exploités par les groupes de ransomware et de BEC (Business Email Compromise) sont couverts. Au-dessus de 75%, on entre dans une zone de maturité réelle qui nécessite des ressources dédiées à la sécurité.

Pour accéder au Secure Score via PowerShell et automatiser le suivi :

# Connexion au Microsoft Graph pour lire le Secure Score
Connect-MgGraph -Scopes "SecurityEvents.Read.All"

# Récupérer les 10 derniers scores
Get-MgSecuritySecureScore -Top 10 | Select-Object CreatedDateTime, CurrentScore, MaxScore,
    @{N='Percentage';E={[math]::Round(($_.CurrentScore/$_.MaxScore)*100,1)}}

# Lister les actions prioritaires non implémentées
Get-MgSecuritySecureScoreControlProfile -All | Where-Object {$_.ImplementationStatus -ne 'implemented'} |
    Sort-Object MaxScore -Descending | Select-Object -First 20 Title, MaxScore, ImplementationStatus

Conditional Access — les 3 politiques essentielles à déployer en premier

Le Conditional Access (Accès Conditionnel dans Entra ID) est le contrôle le plus impactant que vous pouvez déployer sur un tenant M365. Sans lui, un attaquant qui a obtenu des identifiants valides — par phishing, credential stuffing ou brute force — accède directement à la messagerie, SharePoint et Teams sans la moindre friction. Avec trois politiques bien configurées, vous forcez chaque tentative de connexion à satisfaire des conditions supplémentaires.

Politique 1 : MFA obligatoire pour tous les utilisateurs

Pas seulement pour les admins. Pour tous. Je rencontre encore régulièrement des configurations où le MFA est activé sur les Global Admin mais pas sur les utilisateurs standards — alors que les attaques BEC ciblent en priorité les directeurs financiers et les assistants de direction, rarement les administrateurs IT. La policy doit couvrir tous les utilisateurs, toutes les applications cloud, avec comme seule exclusion les comptes break-glass (compte d'urgence sans MFA, avec mot de passe 64 caractères aléatoires, stocké dans un coffre-fort physique).

Politique 2 : Require compliant device (via Intune)

Les appareils non-enrollés dans Intune, sans chiffrement BitLocker, sans Secure Boot activé, ne doivent pas accéder aux données M365. Cette politique s'applique après le déploiement d'Intune — voir notre article sur les politiques de conformité Intune pour les paramètres recommandés.

Politique 3 : Bloquer l'authentification héritée

SMTP AUTH, POP3, IMAP4, Exchange ActiveSync avec Basic Auth — ces protocoles ne supportent pas le MFA. Un attaquant qui a des identifiants valides peut contourner entièrement votre MFA en utilisant ces protocoles anciens. Les bloquer est non-négociable.

# Vérifier l'état des policies Conditional Access existantes
Connect-MgGraph -Scopes "Policy.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy
$policies | Select-Object DisplayName, State, @{N='Users';E={$_.Conditions.Users.IncludeUsers -join ','}} |
    Format-Table -AutoSize

# Identifier les utilisateurs qui utilisent encore l'authentification héritée
$startDate = (Get-Date).AddDays(-30)
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "clientAppUsed eq 'IMAP4' or clientAppUsed eq 'POP3' or clientAppUsed eq 'SMTP'" -Top 100 |
    Select-Object UserPrincipalName, ClientAppUsed, AppDisplayName, CreatedDateTime |
    Sort-Object UserPrincipalName -Unique

Defender for Office 365 — protection multicouche contre les attaques email

Microsoft Defender for Office 365 (anciennement ATP) est la couche de sécurité email qui fait la différence entre un tenant qui se fait compromettre par phishing et un tenant qui détecte et bloque ces tentatives. Il existe en deux plans : Plan 1 (Safe Links, Safe Attachments, anti-phishing avancé) et Plan 2 (Plan 1 + Threat Explorer, Attack Simulator, SIEM integration avancée).

Les trois composants à configurer absolument :

Anti-phishing policies avec impersonation protection : configurez la protection contre l'usurpation d'identité pour les domaines que vous utilisez et pour les utilisateurs clés (PDG, DAF, DRH). Un email prétendant venir de votre PDG mais envoyé depuis un domaine externe similaire sera détecté et mis en quarantaine.

Safe Links : les URLs dans les emails et les documents Office sont réécrits et vérifiés en temps réel au moment du clic. Un lien vers un site de phishing qui était propre au moment de la livraison mais est devenu malveillant 2 heures après sera bloqué à l'ouverture. Activez aussi la protection pour les applications Microsoft Teams.

Safe Attachments : les pièces jointes sont ouvertes dans un sandbox avant d'être livrées. Le délai de livraison est de quelques minutes — acceptable pour du phishing sophistiqué. Activez le mode Dynamic Delivery pour livrer l'email sans la pièce jointe pendant l'analyse, afin de ne pas bloquer les flux critiques.

Pour vérifier l'état de vos politiques Defender for Office 365 :

# Vérifier les politiques anti-phishing
Connect-ExchangeOnline -UserPrincipalName [email protected]
Get-AntiPhishPolicy | Select-Object Name, Enabled, EnableTargetedUserProtection,
    EnableTargetedDomainsProtection, ImpersonationProtectionState | Format-List

# Vérifier Safe Attachments
Get-SafeAttachmentPolicy | Select-Object Name, Enable, Action, ScanTimeout | Format-Table

# Vérifier Safe Links
Get-SafeLinksPolicy | Select-Object Name, IsEnabled, ScanUrls, EnableForInternalSenders | Format-Table

Unified Audit Log — activer avant tout et exploiter correctement

Le Unified Audit Log (UAL) est la source de vérité pour toute investigation de sécurité M365. Sans lui, vous êtes aveugle : impossible de savoir si des emails ont été exfiltrés, si des fichiers SharePoint ont été téléchargés en masse, si des règles Inbox ont été créées pour rediriger les emails vers un compte externe. J'ai conduit des investigations post-incident où l'UAL n'était pas activé — c'est une impasse complète, on ne peut que constater les dégâts sans comprendre le vecteur d'attaque.

Par défaut, Microsoft active l'UAL pour les nouveaux tenants depuis 2019, mais des tenants anciens ou migrés peuvent l'avoir désactivé. Vérifiez et activez :

# Vérifier si l'Unified Audit Log est activé
Connect-ExchangeOnline -UserPrincipalName [email protected]
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Activer si désactivé
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

# Rechercher des événements critiques sur les 90 derniers jours
$startDate = (Get-Date).AddDays(-90)
$endDate = Get-Date

# Téléchargements de fichiers en masse
$downloads = Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate `
    -Operations "FileDownloaded","FileSyncDownloadedFull" -ResultSize 5000
$downloads | Where-Object {($_.AuditData | ConvertFrom-Json).ClientIP -notlike "10.*"} |
    Export-Csv "external_downloads.csv" -NoTypeInformation

# Connexions depuis des pays inhabituels
$mailboxLogins = Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate `
    -Operations "MailboxLogin" -ResultSize 5000
$mailboxLogins | Export-Csv "mailbox_logins.csv" -NoTypeInformation

La durée de rétention de l'UAL dépend de votre licence : 90 jours (E1), 180 jours (E3), 1 an (E5/Defender P2), jusqu'à 10 ans avec l'add-on Audit (Premium). Pour une conformité NIS 2, un an minimum est recommandé. Consultez notre guide sur l'audit avancé des journaux M365 pour les techniques d'analyse avancée.

Protection Exchange — SPF, DKIM, DMARC : la trinité anti-spoofing

L'usurpation de domaine (spoofing) est à l'origine de la majorité des attaques BEC (Business Email Compromise) réussies. Un attaquant qui peut envoyer des emails depuis votre domaine sans être détecté peut usurper l'identité de votre PDG, de votre banquier, de votre expert-comptable. La trinité SPF/DKIM/DMARC est la réponse technique à ce risque — et c'est non-négociable.

SPF (Sender Policy Framework) : liste les serveurs autorisés à envoyer des emails depuis votre domaine. Pour Exchange Online, l'enregistrement TXT standard est :

# Vérifier l'enregistrement SPF de votre domaine
nslookup -type=TXT votredomaine.fr | grep spf
# Résultat attendu pour Exchange Online :
# "v=spf1 include:spf.protection.outlook.com -all"
# Le "-all" (hard fail) est préférable au "~all" (soft fail)

# Vérifier DKIM
nslookup -type=TXT selector1._domainkey.votredomaine.fr
# Puis selector2

# Vérifier DMARC
nslookup -type=TXT _dmarc.votredomaine.fr
# Objectif final : v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100

DKIM (DomainKeys Identified Mail) : signe cryptographiquement chaque email sortant. Activez DKIM dans le portail Exchange Online Admin Center (Protection > DKIM) pour chaque domaine. Microsoft génère automatiquement les paires de clés et les enregistrements DNS à ajouter.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) : orchestre SPF et DKIM et définit la politique à appliquer en cas d'échec. Commencez avec p=none pour monitorer, passez à p=quarantine après validation, et visez p=reject comme état final. Les rapports DMARC (envoyés quotidiennement) permettent de détecter les tentatives de spoofing et les flux légitimes non-couverts par SPF.

Pour activer DKIM via PowerShell :

# Activer DKIM pour un domaine
Connect-ExchangeOnline -UserPrincipalName [email protected]
New-DkimSigningConfig -DomainName votredomaine.fr -Enabled $true

# Vérifier l'état DKIM de tous les domaines
Get-DkimSigningConfig | Select-Object Domain, Enabled, Status, Selector1CNAME, Selector2CNAME

# Activer les rapports DMARC agrégés (rua) et forensiques (ruf)
# L'enregistrement DNS à créer (exemple) :
# _dmarc.votredomaine.fr TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

External Email Warning — signaler les emails externes aux utilisateurs

Une mesure souvent négligée mais extrêmement efficace : afficher une bannière sur tous les emails provenant de l'extérieur de votre organisation. Cette simple indication visuelle réduit significativement le taux de succès des attaques de phishing par usurpation d'identité interne. Même un utilisateur non-technique hésitera à cliquer sur un lien dans un email marqué "EXTERNE" alors qu'il croit recevoir un message de son collègue.

# Configurer la bannière d'avertissement pour les emails externes
Connect-ExchangeOnline -UserPrincipalName [email protected]

# Méthode 1 : Mail Flow Rule (recommandée, visible dans Outlook Web + clients)
New-TransportRule -Name "Marquer emails externes" `
    -FromScope NotInOrganization `
    -SentToScope InOrganization `
    -PrependSubject "[EXTERNE] " `
    -ApplyHtmlDisclaimerLocation Prepend `
    -ApplyHtmlDisclaimerText '
⚠️ CET EMAIL PROVIENT DE L'EXTÉRIEUR DE VOTRE ORGANISATION. Soyez vigilant avant de cliquer sur des liens ou d'ouvrir des pièces jointes.
' `
    -ApplyHtmlDisclaimerFallbackAction Wrap

Hardening par service M365 — Teams, SharePoint, OneDrive

Les réglages de sécurité de Microsoft 365 ne se limitent pas à la messagerie. Teams, SharePoint Online et OneDrive sont devenus des vecteurs d'exfiltration de données et des points d'entrée pour les attaquants qui ont compromis un compte invité ou obtenu un partage anonyme.

Microsoft Teams — contrôler les accès externes

• Désactiver les réunions anonymes : un lien de réunion Teams sans authentification permet à n'importe qui de rejoindre. Exigez une connexion authentifiée pour toutes les réunions.
• Restreindre le partage de fichiers vers des domaines externes : configurer la liste des domaines autorisés plutôt que d'autoriser tous les domaines.
• Désactiver la messagerie directe avec des utilisateurs externes non-fédérés.
• Activer le logging des conversations dans le Compliance Center.

SharePoint Online — politiques de partage

• Passer le partage externe de "Anyone" à "Existing Guests" minimum, ou "Only people in your organization" si votre modèle d'affaires le permet.
• Configurer les DLP (Data Loss Prevention) pour détecter les documents contenant des données personnelles (numéros de carte bancaire, numéros de sécurité sociale) partagés en externe.
• Activer les alertes sur les partages anonymes (liens "Anyone can access").

OneDrive — synchronisation contrôlée

• Restreindre la synchronisation aux appareils Intune-compliant via la politique de domaine.
• Bloquer la synchronisation depuis des pays non-utilisés par votre organisation.
• Configurer les alertes sur les téléchargements massifs (>100 fichiers en moins d'une heure).

Pour une vision complète de l'automatisation de l'audit M365 via PowerShell, consultez notre guide dédié avec les scripts complets.

Comment évaluer rapidement la posture sécurité d'un tenant M365 ?

Quand j'arrive sur un nouveau tenant M365 pour un audit, voici les 10 premières vérifications que je fais systématiquement, dans cet ordre, en moins de 30 minutes :

1. Score Secure : accéder à security.microsoft.com, noter le score actuel et les 5 actions à plus fort impact.
2. UAL activé ? : Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled
3. MFA coverage : combien d'utilisateurs actifs n'ont pas de MFA configuré.
4. Authentification héritée : vérifier les logs de connexion des 30 derniers jours pour IMAP/POP3/SMTP.
5. Global Admins : combien ? Plus de 5 est un signal d'alarme.
6. DMARC policy : en reject, quarantine ou none ? SPF avec -all ?
7. Defender for Office 365 : Plan 1 ou Plan 2 ? Politiques Safe Links et Safe Attachments actives ?
8. Conditional Access policies : combien de politiques actives ? Couvrent-elles tous les utilisateurs ?
9. Guest users : combien d'invités actifs ? Dernière connexion de chacun ?
10. Règles Inbox suspectes : y a-t-il des règles de transfert automatique vers des domaines externes ?

Ces 10 points représentent 80% des vecteurs d'attaque exploités contre les PME et ETI françaises. Pour une analyse plus approfondie, consultez notre guide d'audit avancé M365 avec corrélation de logs.

Quels sont les paramètres M365 les plus souvent mal configurés ?

Sur la base de mes interventions terrain, voici les erreurs de configuration M365 que je rencontre le plus fréquemment — classées par criticité :

Criticité élevée (exploitée activement dans des incidents réels) :

1. UAL non activé — impossible d'investiguer a posteriori
2. MFA absent sur les utilisateurs non-admin (phishing + BEC)
3. Authentification héritée non-bloquée (contournement MFA)
4. DMARC en p=none ou absent — spoofing trivial
5. Règles de transfert automatique vers l'externe autorisées dans Exchange Online

Criticité moyenne (exploitable dans un second temps) :

1. Trop de Global Admins (>5) sans PIM
2. Applications OAuth tierces avec des permissions excessives (access mail, send mail)
3. Partage SharePoint anonymous links activé par défaut
4. Safe Attachments en mode "Off" au lieu de "Block" ou "Dynamic Delivery"
5. Absence de DLP sur les données sensibles

La liste complète avec les méthodes de correction est dans notre guide pratiques de sécurité M365 2025 et dans la référence CIS Microsoft 365 Benchmark que je recommande comme référentiel de base.

Tableau de bord — contrôles prioritaires M365

Intégration avec Microsoft Sentinel pour une détection continue

L'audit sécurité M365 ne doit pas être un exercice annuel — c'est une pratique continue. Microsoft Sentinel, le SIEM cloud de Microsoft, s'intègre nativement avec M365 Defender, Exchange Online Protection, Entra ID et Teams pour corréler les événements et détecter les anomalies comportementales en temps réel.

Les connecteurs Sentinel à activer en priorité :

• Microsoft 365 Defender : incidents et alertes consolidées
• Azure Active Directory : connexions risquées, changements de rôles, MFA bypass
• Office 365 : emails, SharePoint, Teams — activité utilisateur
• Microsoft Defender for Office 365 : campagnes de phishing, URL malveillantes

Pour une implémentation complète du threat hunting sur M365 avec Sentinel, nous avons un guide dédié aux requêtes KQL et aux règles de détection analytiques. La documentation officielle Microsoft 365 Security et les recommandations CISA sur M365 constituent les références normatives de cet article.

Questions fréquentes sur l'audit sécurité Microsoft 365

Comment activer le Unified Audit Log sur Microsoft 365 ?

Via PowerShell Exchange Online : Connect-ExchangeOnline puis Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true. Vérifiez avec Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled — la valeur doit être True. L'activation prend effet immédiatement mais les données passées ne sont pas récupérables. Pour les nouveaux tenants depuis 2019, c'est activé par défaut. La rétention par défaut est 90 jours (E1), 180 jours (E3) ou 1 an (E5).

Quelle est la différence entre Defender for Office 365 Plan 1 et Plan 2 ?

Plan 1 : Safe Links, Safe Attachments, anti-phishing avancé avec impersonation protection. C'est le minimum recommandé. Plan 2 ajoute : Threat Explorer (investigation manuelle des menaces), Attack Simulator (campagnes de phishing simulées en interne), Automated Investigation and Response (AIR) et l'intégration avancée avec Microsoft Sentinel. Pour les PME, le Plan 1 suffit. Pour les ETI et grandes entreprises avec un SOC, le Plan 2 apporte une valeur réelle. Le Plan 2 est inclus dans les licences E5 et Microsoft 365 Business Premium.

Comment configurer DMARC sur un domaine Office 365 ?

En trois étapes : 1) Vérifiez que SPF est configuré avec include:spf.protection.outlook.com -all. 2) Activez DKIM via le portail Exchange Online Admin ou PowerShell (New-DkimSigningConfig -DomainName votredomaine.fr -Enabled $true) et ajoutez les enregistrements CNAME indiqués. 3) Créez un enregistrement TXT _dmarc.votredomaine.fr avec v=DMARC1; p=none; rua=mailto:[email protected], attendez 2 semaines de monitoring, puis passez à p=quarantine puis p=reject.

Que couvre exactement le Microsoft Secure Score ?

Le Secure Score couvre les contrôles de sécurité configurables dans votre tenant M365 : politiques Entra ID/Azure AD (MFA, PIM, Conditional Access), paramètres Exchange Online (DMARC, transport rules, blocage auth héritée), configuration Defender for Office 365, paramètres SharePoint et OneDrive (partage, DLP), configuration Teams, et paramètres Intune/Endpoint Manager. Il ne couvre pas la sécurité de votre infrastructure on-premise ni la qualité de vos mots de passe — pour ça, il faut passer par Microsoft Entra ID Protection et les rapports d'identités à risque.

Comment bloquer l'authentification héritée dans Azure AD ?

Via Conditional Access : créer une policy avec Condition "Client apps" = "Legacy authentication clients" (IMAP, POP3, SMTP, Exchange ActiveSync, Other clients) et Action = "Block access". Appliquer à "All users". Avant d'activer, vérifiez les logs de connexion sur 30 jours pour identifier les utilisateurs et applications qui utilisent encore ces protocoles — certains scanners multifonctions ou logiciels comptables utilisent SMTP AUTH et devront être migrés vers OAuth. Consultez notre guide sur la sécurisation des accès M365 avec MFA pour la procédure complète.