Notre méthodologie d’audit de tenant Microsoft 365

Nos principes

Un audit de tenant ne doit jamais devenir lui-même un risque. Quatre principes encadrent chaque mandat :

• Lecture seule. Nous utilisons un compte dédié avec le rôle Lecteur général (Global Reader) et des permissions Microsoft Graph en lecture. Aucune modification n’est faite pendant l’audit.
• Consentement explicite et limité dans le temps. Le compte d’audit est créé par le client, pour la durée du mandat, puis désactivé.
• Données minimales. Nous collectons la configuration, pas le contenu des courriels ni des fichiers. Les exports restent chiffrés et sont détruits à la fin du mandat.
• Preuves reproductibles. Chaque constat est accompagné de la commande ou de l’écran qui le démontre, pour que l’équipe TI puisse le vérifier elle-même.

Le périmètre couvert

Nous regroupons les vérifications en six domaines, inspirés du CIS Microsoft 365 Foundations Benchmark et des recommandations de Microsoft :

• Identité et accès : MFA, accès conditionnel, authentification héritée, administrateurs, comptes invités.
• Messagerie et domaine : SPF, DKIM, DMARC, règles de transfert, protection contre l’hameçonnage.
• Journalisation : journal d’audit unifié, audit des boîtes aux lettres, rétention des journaux de connexion.
• Collaboration : partage externe SharePoint et OneDrive, accès invités dans Teams.
• Applications : consentement des utilisateurs, applications tierces et leurs permissions.
• Azure (si présent) : rôles Owner, ressources exposées, Defender for Cloud.

Les articles suivants de cette série détaillent les trois premiers domaines, avec les commandes que vous pouvez exécuter vous-même.

La collecte, en lecture seule

La majorité des vérifications passent par le module officiel Microsoft Graph PowerShell, complété par Exchange Online PowerShell et des requêtes DNS. La connexion demande uniquement des permissions de lecture :

# Module officiel : Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -NoWelcome -Scopes "Directory.Read.All","Policy.Read.All","AuditLog.Read.All","Reports.Read.All","SecurityEvents.Read.All"

# Confirmer le compte, le tenant et les permissions accordées (lecture seule)
Get-MgContext | Select-Object Account, TenantId, Scopes

Avant toute chose, nous relevons le Secure Score de Microsoft. Ce n’est pas une fin en soi, mais c’est un point de référence utile pour mesurer les progrès après la remédiation :

Get-MgSecuritySecureScore -Top 1 |
  Select-Object CreatedDateTime, CurrentScore, MaxScore

La priorisation des constats

Une longue liste de constats sans ordre n’aide personne. Chaque constat reçoit un niveau selon deux questions : à quel point est-ce exploitable ? et quel serait l’impact ?

• Critique : exploitable facilement et à fort impact. Exemple : un administrateur général sans MFA.
• Élevé : exploitable avec un peu d’effort, ou impact important. Exemple : authentification héritée encore permise.
• Moyen : affaiblit la défense ou la capacité d’enquête. Exemple : DMARC en mode p=none.
• Faible : bonne pratique ou hygiène. Exemple : comptes invités inactifs depuis longtemps.

Nous tenons aussi compte du contexte du client : une PME de dix personnes et une institution financière n’ont pas les mêmes priorités, ni les mêmes obligations, notamment en vertu de la Loi 25.

Les livrables

• Un sommaire pour la direction : les risques principaux en langage clair, sur une à deux pages.
• Un rapport technique : chaque constat avec sa preuve, son niveau, sa correction recommandée et l’effort estimé.
• Un plan d’action sur 30, 60 et 90 jours : les gains rapides d’abord, puis les chantiers plus structurants.
• Une séance de restitution avec l’équipe TI pour répondre aux questions et valider les priorités.