Sécurité M365 : 5 réglages à vérifier en priorité

D’après la prise de parole de Bastien Le Fur, directeur technique de Business Solutions & Data.

Des angles morts plus que des failles visibles

Sur le terrain, ce qui remonte le plus souvent n’est pas de grosses failles béantes, faciles à repérer. Ce sont plutôt des angles morts, des zones où la configuration en place ne correspond pas exactement aux usages réels de l’organisation, ni au niveau d’exigence qu’elle devrait viser.

Il ne s’agit presque jamais de négligence. Les réglages par défaut de Microsoft 365 sont pensés pour convenir au plus grand nombre, pas pour épouser les spécificités de chaque organisation. Microsoft fournit d’ailleurs un indicateur utile pour objectiver cette posture de sécurité : le Secure Score. Ce n’est pas une fin en soi, mais c’est souvent un bon point de départ pour identifier où se situent les écarts entre la configuration actuelle et celle qui serait réellement adaptée.

Cinq réglages reviennent presque systématiquement dans les audits menés sur des tenants Microsoft 365, quel que soit le secteur d’activité de l’organisation.

MFA et méthodes d’authentification

Le premier sujet est celui du MFA, l’authentification multifacteur. Il s’agit aujourd’hui de l’un des réglages de base pour sécuriser un tenant Microsoft 365. Et pourtant, sur un grand nombre d’environnements, son déploiement reste partiel : activé pour certains utilisateurs, absent pour d’autres, ou mis en place avec des méthodes trop faibles pour représenter une protection réelle.

L’enjeu ne se limite pas à cocher la case « MFA activé ». Il faut vérifier pour quels utilisateurs, avec quelle méthode, et avec quel niveau de robustesse. Pour les comptes les plus sensibles, mieux vaut s’orienter vers des méthodes résistantes au phishing, comme les clés de sécurité FIDO2, plutôt que de se contenter d’un code envoyé par SMS ou d’une notification poussée qui peut être validée par erreur.

Security Defaults et accès conditionnel

Le deuxième sujet concerne l’accès conditionnel. Microsoft propose un socle simple avec les Security Defaults, utile en particulier au démarrage d’un environnement. De nombreuses organisations les désactivent ensuite pour aller vers des règles plus fines, ce qui n’a rien de problématique en soi.

Le vrai risque apparaît lorsque ce socle est désactivé sans qu’une protection équivalente ne soit reconstruite derrière. Un accès conditionnel bien configuré permet de décider précisément qui accède à quoi, depuis quel appareil, depuis quel pays, et avec quel niveau d’authentification. Sans cela, l’organisation peut avoir l’impression d’être protégée, alors que les règles réellement appliquées restent incomplètes.

Messagerie et protections anti-phishing

Le troisième sujet touche à la messagerie. Aujourd’hui encore, une grande partie des attaques commence par un e-mail, et pourtant la messagerie n’est pas toujours durcie à la hauteur de ce risque sur les tenants Microsoft 365.

On retrouve fréquemment des mécanismes hérités laissés ouverts sans réel besoin, des protections de domaine incomplètes sur SPF, DKIM ou DMARC, ou des réglages anti-phishing avancés disponibles dans la plateforme mais insuffisamment exploités. Ce sont des éléments techniques, pas toujours les plus visibles au quotidien, mais ce sont souvent eux qui font la différence le jour où une campagne malveillante cible réellement l’organisation.

Partage externe sur SharePoint et OneDrive

Le quatrième sujet est celui du partage externe dans SharePoint et OneDrive. Cette capacité est indispensable pour collaborer avec des clients, des partenaires ou des prestataires. Mais dès lors que les règles associées sont trop permissives, le risque augmente rapidement.

Les situations les plus fréquentes : des liens de partage trop ouverts, des comptes invités toujours actifs bien après la fin d’un projet, des documents sensibles partagés sans réelle maîtrise dans la durée. La bonne approche ne consiste pas à tout bloquer par principe, ce qui reviendrait à freiner la collaboration légitime. Elle consiste à définir un cadre clair : qui peut partager, avec qui, sur quels espaces, et pour combien de temps.

Comptes à privilèges

Le cinquième sujet concerne les comptes à privilèges. Ce sont les comptes les plus sensibles du tenant, et leur compromission peut avoir un impact majeur sur l’ensemble de l’environnement.

Deux problèmes reviennent régulièrement sur ce point : des droits administrateurs actifs en permanence, alors qu’ils ne devraient l’être que ponctuellement, et des rôles beaucoup trop larges par rapport au besoin réel de la personne qui les détient. La bonne pratique reste le principe du moindre privilège. Quand c’est possible, il est préférable d’aller plus loin avec une solution de type PIM (Privileged Identity Management), pour activer les droits uniquement au moment où ils sont nécessaires, avec une durée limitée, une justification et une traçabilité associées.

Un exemple qui illustre bien le sujet

Un scénario revient régulièrement lors des audits : un ancien prestataire, invité sur un espace SharePoint pour la durée d’un projet, conserve un accès actif plusieurs mois, voire plusieurs années après la fin de sa mission. Personne n’a pensé à révoquer ce droit, faute de processus de nettoyage régulier. Ce type de situation ne relève d’aucune faille technique au sens strict : les outils fonctionnent exactement comme prévu. C’est justement ce qui la rend difficile à détecter sans un audit dédié.

Notre approche : prioriser plutôt qu’alarmer

L’approche retenue par les équipes de BSD ne consiste pas à dramatiser la situation d’un tenant. Elle consiste à prioriser. L’audit commence par un regard sur la posture réelle du tenant, sur cinq dimensions : les identités, l’accès conditionnel, la messagerie, les partages externes et les comptes sensibles.

L’objectif est d’identifier les véritables angles morts, ceux qui exposent réellement l’organisation, plutôt que de multiplier des recommandations génériques applicables à n’importe quel environnement. Une fois ces angles morts identifiés, il devient possible de hiérarchiser les actions à mener, en commençant par celles qui réduisent le plus le risque pour l’effort le plus raisonnable.

Par où commencer, concrètement

Toutes les organisations n’ont pas les mêmes priorités, et un plan d’action générique a rarement du sens. Certaines actions produisent néanmoins un effet rapide et méritent d’être traitées en premier, avant même d’envisager un chantier de sécurité plus large.

Un premier passage en revue de l’activation du MFA sur l’ensemble des comptes, en particulier les comptes à privilèges, permet souvent de fermer une bonne partie du risque immédiat en quelques jours. Vient ensuite un contrôle rapide des règles de partage externe sur SharePoint et OneDrive, pour identifier les liens trop ouverts et les invités qui n’ont plus de raison d’avoir accès à l’environnement.

Les sujets liés à la messagerie et à l’accès conditionnel demandent en général un peu plus de temps, car ils touchent aux usages quotidiens des équipes et nécessitent d’être testés avant généralisation. Quant à la mise en place d’une solution de type PIM sur les comptes à privilèges, elle s’inscrit davantage dans un chantier de fond, à mener une fois les urgences traitées.

Questions fréquentes sur la sécurité Microsoft 365

Le Secure Score suffit-il à évaluer la sécurité d’un tenant M365 ? Non, il constitue un bon point de départ pour objectiver certains écarts, mais il ne remplace pas un audit qui tient compte des usages réels de l’organisation, de son secteur d’activité et de ses contraintes propres.

Faut-il désactiver les Security Defaults de Microsoft ? Pas nécessairement. Ils constituent un socle de protection utile, en particulier au démarrage. Le risque survient lorsqu’ils sont désactivés pour aller vers des règles d’accès conditionnel plus fines, sans que cette transition ne soit menée jusqu’au bout.

Quelle méthode de MFA privilégier pour les comptes sensibles ? Les méthodes résistantes au phishing, comme les clés de sécurité FIDO2, offrent un niveau de protection plus solide que les codes envoyés par SMS ou les notifications poussées, plus vulnérables à certaines techniques de contournement.

Qu’est-ce que le principe du moindre privilège appliqué aux comptes à privilèges ? Il consiste à limiter les droits d’un compte au strict nécessaire pour la mission de son titulaire, et à activer les droits administrateurs uniquement au moment où ils sont utiles, plutôt que de façon permanente.

Un tenant sécurisé ne repose pas sur les réglages par défaut

Microsoft 365 donne les outils nécessaires pour construire un environnement sécurisé. Mais ces outils ne créent pas de sécurité par leur seule présence dans la plateforme. Ils doivent être activés, configurés et adaptés à l’organisation qui les utilise.

Un tenant sécurisé n’est pas un tenant qui repose sur les réglages par défaut. C’est un tenant dont les accès, les identités, la messagerie, les partages et les comptes sensibles sont réellement maîtrisés, avec un cadre explicite plutôt qu’une configuration héritée par défaut.

Vous souhaitez évaluer la posture de sécurité réelle de votre tenant Microsoft 365 ? Contactez nos équipes pour un audit sécurité adapté à votre organisation.