En bref
Pour sécuriser Microsoft 365, concentrez-vous d’abord sur l’identité, car la plupart des compromissions de tenant passent par un compte. Cinq contrôles font l’essentiel du résultat : l’authentification multifacteur pour tous, des politiques d’accès conditionnel, des rôles d’administration limités et séparés, un contrôle des applications et consentements OAuth, et la surveillance des règles de messagerie et des connexions inhabituelles. Un audit en lecture seule les vérifie en quelques jours.
Pourquoi l’identité est-elle le périmètre de Microsoft 365 ?
Dans un tenant Microsoft 365, il n’y a pas de pare-feu à franchir : la messagerie, les fichiers et les applications sont atteints par Internet, avec un compte. Microsoft Entra ID : définition, l’annuaire d’identités qui gère ces comptes, devient donc le périmètre de sécurité. Un compte compromis donne accès à une boîte aux lettres, à des documents, souvent à des applications tierces connectées par le même identifiant.
Le scénario fréquent est sans exploit : un message d’hameçonnage : définition vole un mot de passe, l’attaquant se connecte, crée une règle de messagerie qui redirige ou masque certains messages, puis prépare une fraude au virement depuis la boîte légitime. Chaque étape utilise des fonctions normales du service.
Quels sont les cinq contrôles prioritaires ?
- L’authentification multifacteur pour tous les comptes, y compris les comptes de service humains et les comptes d’urgence correctement protégés. Les paramètres de sécurité par défaut d’Entra ID l’imposent sur un tenant qui n’a pas de politique plus fine ; ils constituent un minimum, pas une cible.
- L’accès conditionnel : des politiques qui décident, selon l’utilisateur, l’appareil, le lieu et le risque, d’autoriser, de bloquer ou d’exiger une authentification renforcée. Les anciens protocoles d’authentification, qui ne supportent pas le multifacteur, doivent être bloqués.
- Les rôles d’administration : peu de comptes avec le rôle d’administrateur général, des comptes d’administration distincts des comptes de travail, des droits attribués à la demande plutôt que de façon permanente, et le moindre rôle suffisant pour chaque tâche.
- Les applications et les consentements : qui peut autoriser une application tierce à lire les messages ou les fichiers, quelles applications ont déjà reçu ce droit, et lesquelles ne sont plus utilisées.
- La messagerie et la journalisation : règles de transfert externes, redirections automatiques, connexions depuis des pays inhabituels, et durée de conservation des journaux, qui doit permettre d’enquêter plusieurs semaines en arrière.
Que montre un audit Microsoft 365 qu’une console ne montre pas ?
Les consoles d’administration affichent des scores et des recommandations. Elles ne disent pas quels écarts s’enchaînent. Un audit part de la position d’un attaquant qui possède un compte ordinaire et cherche les enchaînements : un rôle délégué qui permet de se donner d’autres rôles, une application qui détient plus de droits que ses utilisateurs, un compte d’urgence exclu de toutes les politiques et sans surveillance.
Il vérifie aussi les exceptions. Une politique d’accès conditionnel exigeant le multifacteur pour « tous les utilisateurs » peut en fait exclure un groupe, une application ou un pays ajoutés pour dépanner un jour et jamais retirés. Ces exceptions sont la zone où l’on trouve ce qu’un contrôle automatique rapporte comme conforme.
Quelles erreurs reviennent le plus souvent ?
- Activer le multifacteur pour les employés et oublier les comptes de service, les boîtes partagées ou les comptes de prestataires.
- Conserver trop d’administrateurs généraux, parfois avec des comptes de travail qui lisent aussi les e-mails.
- Laisser n’importe quel utilisateur consentir à des applications tierces.
- Ne jamais relire les règles de transfert de messagerie ni les exceptions des politiques d’accès conditionnel.
- Découvrir pendant un incident que les journaux ne remontent qu’à quelques jours.
Que surveiller après le durcissement ?
Durcir un tenant ne suffit pas : la configuration dérive, et un attaquant qui obtient un compte cherchera des traces à effacer ou des accès à pérenniser. La surveillance doit donc porter sur quelques événements précis, plus utiles qu’un déluge d’alertes : création de règles de transfert ou de masquage dans une boîte, ajout d’une méthode d’authentification à un compte, octroi d’un consentement à une application, attribution d’un rôle d’administration, connexion d’un compte d’urgence.
Chaque événement doit avoir un propriétaire et une réponse prévue : qui reçoit l’alerte, qui décide de bloquer le compte, qui informe l’utilisateur. Une alerte sans réponse écrite se perd. Il faut aussi vérifier que les journaux sont conservés assez longtemps pour enquêter, car la durée de conservation par défaut peut être plus courte que le temps qu’il faut pour découvrir une compromission.
Enfin, testez la détection : créez volontairement une règle de messagerie de test, ou simulez l’ajout d’une méthode d’authentification, et mesurez le temps avant qu’une personne ne le voie. C’est le seul moyen de savoir si la surveillance existe.
À retenir
- 1Dans Microsoft 365, l’identité est le périmètre : un compte compromis suffit à ouvrir messagerie, fichiers et applications.
- 2Multifacteur, accès conditionnel, rôles limités, contrôle des applications et surveillance des règles de messagerie font l’essentiel du résultat.
- 3Les exceptions aux politiques sont l’endroit où se cachent les failles que les scores jugent conformes.
- 4Un audit en lecture seule suffit pour établir les chemins d’escalade du tenant.
Sources citées
- Configure Security Defaults for Microsoft Entra ID, Microsoft Learn
- Microsoft Entra Conditional Access: Zero Trust policy engine, Microsoft Learn
- Best practices for Microsoft Entra roles, Microsoft Learn
Comment auditer un tenant Microsoft 365 en pratique ?