Une base d'accès conditionnel gratuite pour M365

Microsoft rapporte que 99,9 % des comptes compromis dans sa télémétrie n'avaient pas d'authentification multifacteur, et l'accès conditionnel est le moteur de politiques qui l'impose. Pourtant, la plupart des locataires de PME que nous auditons fonctionnent encore avec les paramètres par défaut, ou pire, avec un projet pilote inachevé de 2021. Cet écart est la principale raison pour laquelle les groupes de rançongiciels entrent encore dans les environnements Microsoft 365 par des mots de passe volés.

Voici donc la décision à prendre : bâtir votre propre cadre d'accès conditionnel à partir de zéro (des semaines de travail, risque réel de vous bloquer hors du locataire), payer un consultant cinq chiffres pour livrer du sur mesure, ou déployer une base éprouvée et l'ajuster à votre entreprise. Nous venons de publier l'option trois gratuitement. Le dépôt ConditionalAccessBaseline-Hardened sur GitHub contient l'ensemble exact de politiques que nos ingénieurs déploient pour les clients en production, nettoyé et prêt à importer.

Cet article passe en revue ce qu'il y a dans la base, à qui elle s'adresse, ce que ça vous coûte de l'ignorer, et comment la déployer sans casser les connexions du lundi matin.

Points clés à retenir

• Notre base d'accès conditionnel gratuite est publiée sur GitHub et déployable en un seul après-midi.
• L'ensemble de politiques bloque l'authentification héritée, impose la MFA et isole les comptes administrateurs par défaut.
• Les comptes de secours (« break-glass ») sont préconfigurés afin que vous ne puissiez pas vous bloquer hors du locataire.
• Le mode rapport seul vous permet de valider chaque règle contre les connexions réelles avant l'application.
• La base suppose au minimum Entra ID P1; certaines politiques bénéficient des signaux de risque P2.

Ce que fait réellement l'« accès conditionnel »

L'accès conditionnel est le portier qui se trouve entre la tentative de connexion d'un utilisateur et la ressource qu'il essaie d'atteindre. Il évalue des signaux (utilisateur, appareil, emplacement, application, niveau de risque) et décide : autoriser, autoriser avec MFA, exiger un appareil conforme ou bloquer. Pensez-y comme à un pare-feu pour l'identité plutôt que pour le trafic réseau.

Sans lui, Microsoft 365 fait confiance à un nom d'utilisateur et un mot de passe valides depuis n'importe où sur la planète. Avec un ensemble de politiques sensé, un attaquant qui hameçonne des identifiants se heurte tout de même à un mur : appareil inconnu, pays inconnu, application inconnue. Ce mur est ce qui empêche les attaques par pulvérisation de mots de passe de se transformer en prises de contrôle complètes du locataire.

Le hic? L'accès conditionnel est suffisamment puissant pour bloquer chaque utilisateur hors de chaque application en environ trente secondes si vous le configurez mal. C'est pourquoi la plupart des équipes TI l'évitent ou déploient quelque chose de si permissif qu'il n'offre aucune protection réelle.

Pourquoi nous avons publié la base gratuitement

Trois raisons, en termes simples.

Premièrement, le paysage des menaces ne se soucie pas de votre budget. Un cabinet d'avocats de 12 personnes à Lévis se fait frapper par les mêmes trousses d'hameçonnage Evilginx qui visent les Fortune 500. Cacher un ensemble de politiques fonctionnel derrière un mur payant ralentit les défenseurs, pas les attaquants.

Deuxièmement, la révision par les pairs améliore la sécurité. Publier sur GitHub signifie que tout ingénieur à Montréal, Toronto ou Berlin peut lire le JSON, ouvrir un ticket et soumettre une demande de tirage. Nous avons déjà accepté des correctifs qui ont amélioré la logique d'accès des invités. Une base privée ne reçoit jamais ce niveau d'examen.

Troisièmement, c'est de bonnes affaires. Beaucoup d'organisations déploieront la base elles-mêmes et ne nous appelleront jamais. Certaines la déploieront, buteront sur une question d'ajustement et nous contacteront pour quelques heures d'aide. Une poignée lira le dépôt, décidera qu'elle veut un partenaire géré et nous demandera des services en cybersécurité. Les trois résultats sont très bien.

Ce que contient le dépôt

La base est un ensemble structuré de politiques d'accès conditionnel exportées en JSON, plus un fichier README qui explique chaque décision. La version actuelle couvre sept catégories de politiques (Source) :

1. Protection de base pour tous les utilisateurs, exigeant la MFA pour toute application infonuagique depuis tout emplacement.
2. Renforcement des administrateurs, appliquant des contrôles plus stricts aux neuf rôles privilégiés Entra qui comptent le plus.
3. Blocage de l'authentification héritée, supprimant les protocoles (IMAP, POP3, auth de base SMTP) qu'aiment les attaquants.
4. Barrières de conformité des appareils pour les applications sensibles, afin que le AVEC non géré ne puisse pas atteindre les données financières.
5. Politiques basées sur le risque déclenchées par les signaux Entra ID Protection (risque de connexion, risque utilisateur).
6. Contrôles des invités et utilisateurs externes, encadrant ce que les identités B2B peuvent réellement faire.
7. Protection des jetons et contrôles de session, incluant la fréquence de connexion pour les administrateurs.

Chaque politique est livrée en mode rapport seul par défaut. C'est délibéré. Vous importez l'ensemble, observez les connexions réelles y circuler pendant une semaine ou deux, corrigez ce qui vous surprend, puis basculez les politiques à « Activé » une à une.

Le modèle de compte de secours (break-glass)

Le dépôt inclut un modèle documenté pour les comptes de secours : deux identités d'administrateur uniquement infonuagiques, exclues de chaque politique d'accès conditionnel, avec des mots de passe de 24 caractères ou plus stockés hors ligne. Si quelque chose tourne mal (et à un moment donné, ça arrivera), vous vous connectez avec le compte de secours, corrigez la politique, vous déconnectez. Nous avons utilisé ce modèle pour plus d'une centaine de locataires sans un seul incident de blocage.

Si vous sautez cette étape, vous êtes à une mauvaise politique près d'appeler le soutien Microsoft à 2 h du matin. Ne le faites pas.

Le coût de l'inaction

Mettons des chiffres sur l'alternative. Le rapport 2024 « Cost of a Data Breach » d'IBM établit la violation moyenne au Canada à 6,32 M$, les intrusions basées sur les identifiants étant parmi les vecteurs les plus courants. Pour une petite entreprise, même un « petit » événement de rançongiciel coûte de 50 000 $ à 250 000 $ une fois comptés le temps d'arrêt, la récupération, le juridique et les franchises d'assurance.

L'accès conditionnel n'empêche pas chaque violation. Mais il arrête les attaques bon marché et automatisées : pulvérisation de mots de passe, bourrage d'identifiants, hameçonnage par consentement OAuth. Celles-ci représentent l'essentiel des appels d'intervention sur incident que prend notre équipe. Les bloquer avec une base gratuite est le contrôle de sécurité au meilleur rendement disponible pour un locataire Microsoft 365 en ce moment.

Comparez cela à l'investissement en temps. Un administrateur compétent peut déployer la base en mode rapport seul en environ quatre heures. L'ajustement prend une à deux semaines supplémentaires d'observation passive. Temps total écoulé jusqu'à une protection significative : environ dix jours ouvrables.

Le déployer : un parcours réaliste

Voici comment se déroule habituellement un déploiement pour un locataire de 50 utilisateurs. Traitez ceci comme une liste de vérification, pas comme un substitut à la lecture du README du dépôt.

Étape 1 : Vérification préalable (30 minutes)

Confirmez vos licences. La base suppose Entra ID P1 (inclus dans Business Premium, M365 E3 et la plupart des SKU pour l'éducation). Certaines politiques basées sur le risque nécessitent P2. Inventoriez vos comptes de service et boîtes aux lettres partagées; ceux-ci nécessitent souvent des exclusions parce qu'ils ne font pas la MFA. Documentez toute application tierce utilisant l'authentification de base, car la base les bloquera.

Étape 2 : Créer les comptes de secours (45 minutes)

Deux comptes Administrateur global uniquement infonuagiques. Mots de passe longs et aléatoires. Stockés dans une enveloppe scellée dans un coffre physique, et dans le coffre d'accès d'urgence de votre gestionnaire de mots de passe. Testez-les. Puis testez-les à nouveau.

Étape 3 : Importer les politiques en mode rapport seul (1 heure)

Le dépôt inclut un script PowerShell utilisant le SDK Microsoft Graph pour importer chaque politique avec le commutateur « Rapport seul » activé. Exécutez-le sur votre locataire. Vérifiez dans le portail Entra que toutes les politiques apparaissent et qu'aucune n'est activée en mode application.

Étape 4 : Observer pendant 7 à 14 jours

Ouvrez quotidiennement le classeur « Insights et rapports » de l'accès conditionnel. Cherchez les connexions qui auraient été bloquées. Chacune est soit un utilisateur légitime que vous devez accommoder (ajoutez une exclusion ou ajustez la politique), soit un attaquant (bien, la politique fonctionne). C'est ici que se fait le vrai travail.

Étape 5 : Appliquer graduellement

Basculez les politiques de rapport seul à « Activé » dans cet ordre : blocage de l'authentification héritée d'abord (risque le plus faible de faux positifs), puis MFA de base, puis renforcement des administrateurs, puis conformité des appareils, puis basé sur le risque. Attendez 48 heures entre chaque. Si une pointe de billets au centre d'aide survient, annulez le changement le plus récent et enquêtez.

Étape 6 : Documenter les exclusions

Chaque exclusion ajoutée est une dette de sécurité. Suivez-les dans un tableur avec une date de révision. Les comptes de service devraient migrer vers des identités gérées ou des identités de charge de travail dans les six mois. Les exclusions d'urgence pour les dirigeants deviennent permanentes à moins que quelqu'un ne s'occupe du nettoyage.

Si les étapes 4 à 6 semblent être plus que ce que votre équipe peut absorber, c'est exactement le genre de travail que notre pratique de migration et sécurité Microsoft 365 gère semaine après semaine.

Quand la base gratuite ne suffit pas

La base est un solide point de départ. Ce n'est pas une ligne d'arrivée.

Les industries avec une superposition réglementaire (santé sous PHIPA, services financiers sous BSIF, entrepreneurs de défense sous CMMC ou ITAR) ont besoin de contrôles supplémentaires : conformité d'appareils plus stricte, postes de travail dédiés aux administrateurs, postes de travail à accès privilégié, customer lockbox, et journalisation d'audit intégrée à un SIEM. La base vous donne 70 à 80 pour cent de ce qu'exigent ces cadres. Les 20 à 30 pour cent restants sont propres à l'industrie.

Les environnements multilocataires, les réseaux complexes de partenaires B2B et les organisations utilisant l'accès conditionnel pour la gouvernance d'applications (pas seulement l'identité) dépasseront la base en moins d'un an. C'est normal. Le dépôt se veut une rampe de lancement, pas un plafond.

Et bien sûr, l'accès conditionnel n'est qu'une couche. Vous avez encore besoin de détection et réponse sur les terminaux, de sécurité courriel, de gestion des correctifs et de sauvegardes testées. La protection de l'identité sans planification de sauvegarde et reprise est une défense fragile. Nous avons vu des locataires survivre à une compromission d'identifiants pour ensuite perdre des données face à un affilié rançongiciel ayant pivoté par un serveur de fichiers mal sécurisé.

Comment cela se compare aux paramètres de sécurité par défaut de Microsoft

Microsoft offre les « Paramètres de sécurité par défaut » comme paramètre de protection gratuit en un clic, et des « modèles » d'accès conditionnel pour les locataires avec Entra ID P1. Les deux sont utiles. Aucun n'est suffisant à lui seul.

Les paramètres de sécurité par défaut imposent la MFA mais n'offrent aucune personnalisation. Vous ne pouvez pas exclure un compte de service, cibler par groupe, ou appliquer des règles différentes aux administrateurs. C'est tout ou rien, ce qui explique pourquoi la plupart des entreprises en croissance les dépassent en un trimestre.

Les modèles d'accès conditionnel intégrés de Microsoft couvrent les bases mais s'arrêtent avant les décisions plus difficiles : avec quelle agressivité contrôler les sessions admin, comment gérer les exclusions de comptes de secours, quoi faire avec les invités B2B, quand exiger des appareils conformes versus jonction hybride. Notre base prend position sur chacun de ces points, documenté dans le README pour que vous puissiez en débattre et modifier.

Pensez aux paramètres par défaut comme à un casque de vélo, aux modèles comme à un casque de moto, et à une base ajustée comme à un équipement de piste complet. Le bon choix dépend de la vitesse à laquelle vous allez.

Ce que nous avons appris en la construisant

Quelques observations honnêtes tirées de déploiements en production.

Les utilisateurs remarquent la première semaine, puis oublient. Le volume au centre d'aide grimpe pendant environ cinq jours ouvrables après l'application, puis tombe sous le niveau de référence. Les gens s'adaptent aux invites MFA plus vite que les dirigeants ne s'y attendent.

Le blocage d'authentification héritée trouve toujours quelque chose. Dans chaque locataire où nous avons déployé, le blocage d'authentification héritée fait surgir au moins un appareil oublié, un numériseur, ou une application métier utilisant encore SMTP de base. Mieux vaut le découvrir un mardi que pendant un audit.

Les politiques basées sur le risque attrapent de vraies attaques en quelques semaines. Sur les locataires avec Entra ID P2, nous voyons typiquement la première connexion à risque moyen bloquée dans les 30 jours suivant l'application. Ce ne sont pas des menaces théoriques; ce sont des tentatives de bourrage d'identifiants en direct contre vos utilisateurs.

La documentation compte plus que les politiques elles-mêmes. Six mois plus tard, personne ne se souvient pourquoi une exclusion spécifique existe. Le « vous » futur remerciera le « vous » présent pour le tableur.

FAQ

Ai-je besoin d'une licence Entra ID P1 pour utiliser la base?

Oui, au minimum. L'accès conditionnel exige Entra ID P1, qui est inclus dans Microsoft 365 Business Premium, M365 E3, M365 E5, et plusieurs SKU pour l'éducation. Une poignée de politiques dans la base (risque de connexion, risque utilisateur) nécessitent Entra ID P2. Le README signale quelles politiques nécessitent quel niveau.

Le déploiement va-t-il briser l'expérience de connexion de mes utilisateurs?

Pas si vous suivez le déploiement en mode rapport seul. Chaque politique est livrée désactivée et en mode observation par défaut. Vous observez ce qui arriverait pendant une semaine ou deux, ajustez les exclusions, puis appliquez. Bien fait, les utilisateurs finaux voient une invite MFA supplémentaire pour les appareils inconnus et rien d'autre ne change.

Puis-je le déployer moi-même, ou ai-je besoin d'un consultant?

Un administrateur M365 confiant qui a travaillé avec PowerShell et le portail Entra peut le déployer seul. Prévoyez une journée complète de travail concentré plus deux semaines de surveillance passive. Si votre équipe est étirée, ou si vous voulez une seconde paire d'yeux sur les exclusions et la configuration des comptes de secours, quelques heures de consultation font beaucoup. Notre équipe de soutien TI gère ces mandats régulièrement.

La base est-elle maintenue, ou est-ce une publication unique?

Elle est maintenue. Microsoft ajoute de nouvelles conditions d'accès conditionnel et contrôles d'octroi chaque trimestre, et le paysage des menaces évolue plus vite que ça. Nous mettons à jour le dépôt à mesure que de nouveaux modèles d'attaque émergent et que Microsoft livre de nouvelles capacités. Surveillez le dépôt sur GitHub pour recevoir les notifications.

Que se passe-t-il si je trouve un bogue ou veux suggérer une amélioration?

Ouvrez un ticket ou une demande de tirage sur le dépôt GitHub. Nous examinons les soumissions chaque semaine. Les contributions passées de la communauté ont déjà façonné la politique d'accès des invités et le modèle d'exclusion des comptes de service.

Sources

• ConditionalAccessBaseline-Hardened sur GitHub

Une base gratuite enlève l'excuse de laisser Microsoft 365 grand ouvert. Tirez le dépôt, lisez le README et exécutez le script d'importation dans un locataire de test cette semaine. Si vous préférez que notre équipe gère le déploiement et l'ajustement de bout en bout, réservez une évaluation TI gratuite et nous le délimiterons lors d'un appel de 30 minutes.