Durcir Microsoft 365 : poser le standard, mesurer face au marché, comparer posé et souhaité

La première partie de ce dossier a suivi une compromission par device code jusqu’au confinement, et s’est arrêtée sur une phrase : ce chemin est fermé dans notre configuration standard, sauf exception documentée. Cette seconde partie explique ce que « configuration standard » veut dire concrètement, comment on vérifie qu’elle est bien posée, comment on la mesure face à ce que le marché considère comme l’état de l’art, et comment on tient dans le temps l’écart entre ce qui est posé et ce qui est souhaité.

Chez ITAIA, durcir ne commence pas par un audit. Un audit mesure, et on ne mesure pas une configuration qu’on n’a pas posée : le résultat serait une liste de deux cents écarts dont personne ne sait lesquels comptent. Durcir commence par poser le standard. La mesure vient ensuite, et le comparatif posé / souhaité la transforme en décisions.

Temps 1 : poser le standard

Le standard a deux moitiés : un jeu de politiques d’accès conditionnel, et une configuration de référence qui couvre tout ce que l’accès conditionnel ne couvre pas.

Le jeu de politiques d’accès conditionnel

L’accès conditionnel est le point de passage obligé de toute connexion à Microsoft 365 : chaque demande de jeton est évaluée contre un ensemble de politiques avant d’être accordée. C’est là que se ferme le chemin de la première partie, et c’est là que se ferment la plupart des autres. Notre jeu de politiques couvre, par famille :

• L’authentification multifacteur exigée pour tout le monde, avec des méthodes résistantes à l’hameçonnage pour les comptes qui administrent le tenant.
• Le blocage des protocoles d’authentification hérités, qui ne savent pas présenter un second facteur.
• Le blocage des flux d’authentification à risque, dont le flux device code, partout où aucun usage légitime n’a été identifié. Microsoft recommande ce blocage partout où c’est possible.
• L’exigence d’un appareil géré ou conforme pour accéder aux données depuis un poste, et des règles distinctes pour les mobiles.
• Des contrôles de session : durée des sessions, fréquence de ré-authentification, persistance limitée sur les appareils non gérés.
• Des politiques fondées sur le risque de connexion et le risque utilisateur, quand la licence du tenant les permet.
• Les comptes d’urgence traités à part, exclus par construction mais surveillés à chaque connexion.

Chaque politique est posée d’abord en mode rapport seul. Pendant quelques jours, les journaux de connexion montrent qui elle aurait bloqué. On traite les cas légitimes, on passe la politique en mode actif, et on garde la trace de la date du passage. Un blocage qui arrive sans cette étape produit un lundi matin difficile et une exclusion ajoutée dans l’urgence, c’est-à-dire exactement la dérive que la première partie décrit.

La configuration de référence

L’accès conditionnel décide qui entre. La configuration de référence décide ce qu’on peut faire une fois entré, et ce qui est tracé. Elle couvre :

• Le consentement applicatif : un utilisateur ne peut pas autoriser seul une application tierce à lire sa boîte ou ses fichiers ; la demande remonte à un administrateur qui l’examine.
• La messagerie : transfert automatique vers l’extérieur bloqué par défaut, règles de boîte surveillées, protocoles hérités fermés côté messagerie aussi, protection contre l’usurpation du domaine.
• Les méthodes d’authentification autorisées, et la surveillance de leur ajout sur un compte, décrite dans la première partie.
• Les terminaux : chiffrement, mises à jour, protection des terminaux, séparation des données professionnelles sur les mobiles.
• La journalisation : audit activé sur tout le périmètre, durée de rétention connue et documentée, export vers un stockage dédié quand la licence ne conserve pas assez longtemps.
• Les partages : liens de partage externes encadrés, invités revus périodiquement.

Cette configuration est écrite, versionnée, et validée avec le responsable du compte côté client. C’est elle qui sert de « souhaité » dans le comparatif du temps 3. Sans elle, il n’y a rien à comparer.

Le registre des exclusions

Le standard ne vaut que par ses exceptions connues. Une exclusion d’un compte ou d’une application d’une politique est acceptable si elle est documentée et horodatée : justification, responsable, date d’expiration, revue périodique. Le registre tient ces champs pour chaque exclusion, comptes d’urgence compris, avec leurs compensations. Une exclusion qui n’y figure pas est une dérive, et elle ressort au contrôle hebdomadaire.

Temps 2 : mesurer face au marché

Une fois le standard posé, on le confronte à ce que le marché considère comme l’état de l’art. Trois référentiels, chacun avec sa valeur et ses limites.

• Le benchmark CIS Microsoft 365 Foundations : une liste de contrôles publiée par un organisme indépendant, numérotée, versionnée, avec pour chaque contrôle la justification, l’impact et la procédure de vérification. Sa force : il est extérieur à nous et opposable, un auditeur sait le lire. Sa limite : il ne connaît pas le métier du client, et plusieurs contrôles ne s’appliquent pas à une société de gestion de trente postes.
• Le score de sécurité Microsoft : une mesure continue, calculée par l’éditeur à partir de la configuration réelle du tenant, avec des recommandations classées par gain. Sa force : il est gratuit, toujours à jour, et il bouge quand la configuration bouge. Sa limite : un score n’est pas une sécurité. Certaines recommandations rapportent des points et n’ont aucun sens pour le client, d’autres n’en rapportent pas et comptent énormément.
• Les recommandations de l’éditeur sur les flux d’authentification, les jetons et les méthodes, publiées dans sa documentation, datées. Elles changent plusieurs fois par an : c’est pour cela que la mesure est périodique et pas ponctuelle.

Le résultat du temps 2 n’est pas un score à afficher. C’est une liste de contrôles où le marché va plus loin que notre standard, ou autrement. Chacun entre dans le comparatif du temps 3 avec une question : est-ce que ce client le souhaite, et à quel coût d’usage ?

Temps 3 : comparer posé et souhaité

Le comparatif est un tableau, une ligne par contrôle. Trois colonnes d’état, une colonne d’écart, une colonne de décision. Il est daté, signé par le responsable du compte côté client, et il est versé au dossier d’audit. Voici à quoi ressemble un comparatif type, anonymisé, les valeurs de paramétrage volontairement absentes.

Contrôle	Posé (état réel)	Souhaité (référence)	Écart	Décision
Flux device code	Bloqué, une exclusion pour un écran de salle de réunion	Bloqué partout, exclusions avec date d’expiration	L’exclusion n’a pas de date d’expiration	Corriger : poser une date, revue trimestrielle
Authentification héritée	Bloquée	Bloquée	Aucun	Maintenir
Consentement applicatif	Autorisé par l’utilisateur pour des applications vérifiées à faibles droits	Approbation administrateur pour tout accès à la boîte ou aux fichiers	Périmètre d’auto-consentement trop large	Corriger, informer les utilisateurs du circuit de demande
Transfert automatique vers l’extérieur	Autorisé par défaut	Bloqué, exceptions nominatives pour deux boîtes partagées	Écart	Corriger, lister les exceptions au registre
Méthodes d’authentification	Application d’authentification, SMS en secours	Méthodes résistantes à l’hameçonnage pour les administrateurs, application pour tous, SMS retiré	SMS encore actif sur une partie des comptes	Planifier le retrait, accompagner les utilisateurs
Rétention des journaux	Durée par défaut de la licence	Durée couvrant le délai moyen de découverte d’un incident	Insuffisante pour un incident découvert tard	Accepter avec compensation : export vers un stockage dédié
Accès depuis les mobiles	Postes gérés, mobiles personnels non encadrés	Données professionnelles séparées sur les mobiles, accès conditionné	Mobiles personnels hors périmètre	Décision de la direction, arbitrage usage / risque

Trois décisions sont possibles pour un écart, et une seule interdite.

• Corriger : on aligne le posé sur le souhaité, avec une date.
• Accepter : on garde l’écart, avec une compensation écrite, et on le revoit à date fixe.
• Exclure : on sort le contrôle du périmètre de ce client, avec la justification, et il ne revient plus polluer le comparatif.
• Interdit : laisser l’écart sans décision. Un écart sans décision est un écart que personne ne porte, et c’est lui qu’on retrouve dans la chronologie d’un incident.

Ce qui change selon la licence

Plusieurs lignes du comparatif dépendent de l’offre Entra ID et Microsoft 365 souscrite. Les politiques fondées sur le risque de connexion ou le risque utilisateur exigent le niveau de licence supérieur. La rétention par défaut des journaux de connexion et d’audit est courte sans licence dédiée, plus longue avec, et n’atteint une durée confortable pour l’analyse d’un incident tardif qu’en exportant les journaux vers un stockage que le client contrôle. Certaines protections des terminaux et des mobiles supposent elles aussi une licence précise.

Un plan de durcissement honnête commence donc par l’inventaire des licences réellement attribuées, et non par la liste des fonctions disponibles dans la documentation. Quand une ligne du comparatif bute sur la licence, la décision est explicite : acheter, compenser, ou accepter. Elle ne reste jamais implicite.

Le contrôle hebdomadaire des dérives

Le durcissement n’est pas un projet, c’est un état à maintenir. Chaque semaine, la configuration réelle du tenant est comparée à la configuration de référence. L’historique des changements est conservé : quoi, quand, par qui. Tout écart remonte en alerte, et il est traité dans la semaine ou inscrit au registre des exclusions avec une justification.

Les dérives que nous rencontrons le plus souvent ne sont pas des attaques. Ce sont des gestes de bonne foi : une exclusion ajoutée pour un test et jamais retirée, un transfert externe activé pour un stagiaire parti depuis, une politique repassée en mode rapport seul « le temps de régler un problème », un consentement accordé par un administrateur pressé. Le contrôle hebdomadaire existe pour ces gestes-là. Nous ne promettons pas une détection en temps réel des dérives : le rythme est hebdomadaire, il est écrit, et il est tenu.

Le SOC comme couche complémentaire

Le socle ferme les chemins connus ; le SOC voit ce qui passe quand même. Pour travailler, il a besoin de trois choses, définies avant le premier incident et non pendant.

• Des journaux de connexion et d’audit conservés assez longtemps pour reconstituer une chronologie complète, ce qui renvoie à la ligne « rétention » du comparatif.
• Des droits d’action définis contractuellement avec le client : révoquer les sessions d’un compte, le désactiver, isoler un poste, retirer une méthode d’authentification ajoutée, sans attendre une validation à trois heures du matin.
• Une procédure de confinement écrite, connue du responsable du compte côté client, avec les étapes dans l’ordre et les personnes à prévenir.

Les alertes du socle et celles du SOC ne disent pas la même chose. Le socle signale qu’une configuration a bougé. Le SOC signale qu’un comportement est anormal dans une configuration qui, elle, n’a pas bougé. Les deux se lisent ensemble : une méthode d’authentification ajoutée après une connexion par device code est un signal du SOC, une exclusion apparue sans justification est un signal du socle, et le second explique souvent le premier.

Les preuves produites pour un audit DORA

Cette section ne traite pas de la conformité elle-même, qui relève du RCCI et de ses conseils. Elle liste ce que le socle produit, et qui peut être versé tel quel à un dossier.

• L’historique des changements de configuration, daté et attribué, sur la période demandée.
• Le registre des exclusions, avec justification, responsable, expiration et date de dernière revue.
• Le comparatif posé / souhaité signé, avec ses décisions, et sa version précédente pour montrer le chemin parcouru.
• Les délais de détection et de réaction mesurés sur les incidents de la période, y compris les faux positifs.

Un contrôleur qui demande « comment savez-vous que votre configuration est celle que vous décrivez ? » reçoit ces quatre documents. C’est une réponse plus courte, et plus solide, qu’une présentation.

Limites et risque résiduel

Le standard et son contrôle ne couvrent pas tout. Les identités externes invitées dans le tenant obéissent à des règles différentes. Les applications SaaS hors Microsoft 365 ont leurs propres journaux, leurs propres sessions et leurs propres dérives. Un poste non géré qui accède au webmail reste un angle mort partiel, même avec un accès conditionnel strict. Plusieurs contrôles dégradent l’expérience des utilisateurs, et chaque ligne « accepter » du comparatif est un compromis assumé entre usage et risque.

Enfin, aucune configuration ne garantit zéro compromission. Ce que la méthode garantit, c’est que la configuration est connue, qu’elle est comparée chaque semaine à ce qu’on a décidé, et que l’écart, quand il apparaît, a un nom, une date et un responsable.

Conclusion : poser, puis seulement mesurer

Gregory a terminé la première partie sur cinq verbes : prévenir, maintenir, détecter, contenir, prouver. Le durcissement, c’est les deux premiers, et il se résume en une règle d’ordre. On pose le standard d’abord, accès conditionnel et configuration de référence, avec ses exclusions au registre. On le mesure ensuite face aux référentiels du marché, pour savoir où il est en retard et où il est en avance. On compare enfin le posé au souhaité, une ligne par contrôle, une décision par écart, chaque semaine. Un tenant durci n’est pas un tenant qui a un bon score : c’est un tenant dont on peut dire, à tout moment, ce qui est posé, ce qui est souhaité, et pourquoi les deux diffèrent.

Sources

• Center for Internet Security, CIS Microsoft 365 Foundations Benchmark : le référentiel public de contrôles utilisé au temps 2.
• Microsoft Learn, Microsoft Secure Score : la mesure continue calculée par l’éditeur, et ses recommandations.
• Microsoft Learn, Authentication flows as a condition in Conditional Access policy : le blocage du flux device code et le mode rapport seul.
• Microsoft Learn, Revoke user access in an emergency in Microsoft Entra ID : les droits d’action dont le SOC a besoin.