Votre tenant Microsoft 365 est une infrastructure cloud : des centaines de paramètres de sécurité répartis entre Entra ID, Exchange Online, SharePoint et Teams, et ils dérivent exactement comme un compte AWS non géré. Un admin bascule un paramètre pendant un incident et ne le remet jamais en place. Microsoft change une valeur par défaut lors d'une mise à jour de service. Un prestataire obtient un accès invité pour un pilote terminé depuis deux trimestres. Personne ne revoit rien de tout cela, parce que le tenant est « un sujet IT », pas « un sujet infrastructure ». Le scan de posture est le correctif ennuyeux et efficace : comparer en continu la configuration réelle du tenant à un référentiel de sécurité publié et signaler les écarts. Et en 2026, la façon pratique de faire tourner ce scanner est en SaaS, ce qui revient à vérifier le cloud avec le cloud. Ce billet est le 101, avec Aether365 comme exemple. Transparence totale : Aether365 est mon produit.

Un principe avant de commencer : le read-only est le mode par défaut. Rien n'obtient d'accès en écriture sur votre tenant sans un consentement séparé et explicite.

Traitez le tenant comme un compte de production

Si quelqu'un exploitait un AWS de production sans audit de configuration, sans détection de dérive et sans historique des changements, vous parleriez de négligence. La plupart des organisations exploitent Microsoft 365 exactement ainsi, alors qu'il héberge leur fournisseur d'identité, tous leurs e-mails et la majorité de leurs fichiers. Le tenant est le plan d'identité de tout le reste de votre système ; une mauvaise configuration de Conditional Access y vaut plus pour un attaquant qu'un bucket S3 public.

L'état d'esprit infrastructure se transfère directement. Vous voulez un référentiel déclaré, une comparaison planifiée de la réalité avec ce référentiel, et une alerte quand les deux divergent. Côté AWS, vous prendriez des règles Config ou des standards Security Hub. Pour Microsoft 365, les équivalents sont les référentiels de posture.

Les trois référentiels à connaître

Trois référentiels couvrent l'essentiel de ce qui compte, et tout scanner sérieux se rattache à au moins l'un d'eux :

  • CIS Microsoft 365 Foundations Benchmark : le plus large, plus de 800 contrôles sur toute la suite, de l'application du MFA à l'audit des boîtes aux lettres en passant par les politiques de partage. La réponse par défaut à « audité par rapport à quoi ? »
  • EIDSCA (Entra ID Security Configuration Analyzer) : entièrement centré sur Entra ID, les paramètres qui décident qui peut s'authentifier, consentir et enregistrer des applications. Petite surface, rayon d'impact maximal.
  • CISA ScuBA (Secure Cloud Business Applications) : le référentiel du gouvernement fédéral américain pour M365. Plus strict et plus tranché ; utile même hors du secteur public comme référence « que ferait une cible endurcie ».

Les référentiels se recoupent, et ce n'est pas un problème. Le recoupement sur les contrôles d'identité vous montre où se trouve le consensus, et les constats consensuels sont ceux à corriger en premier.

Scripts ou SaaS : le vrai compromis

Vous pouvez tout à fait exécuter ces contrôles vous-même. L'API Graph est à portée de main, l'outillage communautaire comme Maester en enveloppe une bonne partie, et une exécution PowerShell planifiée contre un tenant est un projet de week-end. J'aime cette approche pour apprendre ce que les contrôles font réellement.

Elle cesse de passer à l'échelle sur trois axes. La maintenance : les référentiels changent de version, les endpoints Graph évoluent, et votre collection de scripts devient discrètement un produit dont vous êtes propriétaire. L'historique : un script à un instant donné vous dit l'état du jour, mais les questions de posture sont des questions de tendance, quand ce contrôle a-t-il régressé et qu'est-ce qui a changé autour. La multi-tenance : dès que vous gérez plus d'un tenant, un MSP avec trente clients par exemple, les scripts et identifiants par tenant deviennent le risque.

Un scanner SaaS inverse le compromis : vous lui accordez un consentement Microsoft Graph en lecture seule, il exécute des scans de conformité et d'exposition selon un calendrier, quotidien, hebdomadaire ou mensuel, et il conserve l'historique. Le modèle de consentement est la partie à examiner de près, parce que vous branchez un service externe sur votre plan d'identité. La lecture seule doit être le comportement par défaut et tout ce qui va au-delà doit être un consentement séparé et explicite que vous pouvez refuser. Cette seule propriété est ce qui rend le cloud-qui-vérifie-le-cloud acceptable pour un tenant européen réglementé.

Ce que couvre Aether365

Aether365 est ma version de ce scanner. Le cœur, c'est le scan de conformité contre les trois référentiels ci-dessus plus le scan d'exposition, planifié par tenant, avec la gestion multi-tenant pour les MSP, des notifications Teams et e-mail, et une REST API plus un serveur MCP intégré si vous voulez que votre assistant IA interroge les résultats de scan. C'est basé dans l'UE et conforme au RGPD, vous choisissez votre région de données à l'inscription, et les données de scan ne servent jamais à entraîner un quelconque modèle.

Deux capacités dépassent la vue interne du tenant. External Attack Surface vérifie ce que le tenant expose depuis l'extérieur : les enregistrements SPF, DKIM et DMARC, structurels pour le mail M365, l'expiration des certificats avec alertes à 90 jours, le DNS orphelin et le risque de prise de contrôle de sous-domaine, les endpoints d'authentification héritée laissés ouverts, et les partages SharePoint et OneDrive publics. Et AI Pilot, optionnel et réservé aux offres Pro et Enterprise, transforme les constats en corrections Microsoft Graph concrètes que vous approuvez élément par élément avant toute application, avec une piste d'audit vérifiée. La lecture seule reste le défaut ; le chemin d'écriture est un consentement Microsoft séparé que vous n'activez que si vous le voulez. Il existe une offre Free avec des scans mensuels sur un tenant, suffisante pour voir votre premier score CIS, et ce premier score est généralement le déclencheur.

Ce qu'il faut retenir

Le 101 est simple : votre tenant Microsoft 365 mérite la même discipline de posture que vos comptes cloud, les référentiels pour mesurer existent déjà, et la question opérationnelle est seulement de savoir si vous exécutez le scanner vous-même ou si vous consentez à un SaaS pour le faire en lecture seule selon un calendrier. Les scripts vous apprennent les contrôles ; un service vous garde honnête dans la durée. Dans les deux cas, le mode de défaillance à éviter est le défaut actuel : personne ne vérifie rien du tout.

À lire ensuite

Pour le versant IA de la même plateforme, pourquoi la remédiation exige une validation humaine et à quoi sert vraiment le reporting généré par IA, voir M365 Security 101: AI Pilot and Business Impact Reports sur ercan.ai. Pour du conseil en cloud, posture de sécurité et travail de plateforme, ou simplement pour dire bonjour, commencez par ercanermis.com.