Comment imposer la MFA dans l'ensemble de votre organisation Google Workspace

L'authentification multifacteur est le contrôle de sécurité au meilleur rapport bénéfice/effort que la plupart des organisations puissent déployer, et dans Google Workspace, elle porte le nom de validation en 2 étapes (2SV). Le piège se cache dans le mot *imposer*. Rendre la MFA disponible est facile et largement inutile — les comptes les plus susceptibles d'être attaqués sont aussi les moins susceptibles de l'activer volontairement. La véritable protection vient de l'application obligatoire : l'exiger, à l'échelle de toute l'organisation, avec les bons facteurs et un déploiement qui ne bloque l'accès à personne. Cet article est ce plan de déploiement.

Pourquoi « disponible » ne veut pas dire « imposé »

Si la 2SV est optionnelle, l'adoption suit le chemin de moindre résistance : le personnel technique et sensibilisé à la sécurité s'y inscrit ; les dirigeants occupés et les comptes de type service, non. Les attaquants le savent. Les attaques par phishing d'identifiants et par réutilisation de mots de passe visent précisément les comptes qui n'ont pas activé la fonctionnalité. Un contrôle optionnel protège les personnes qui en avaient le moins besoin.

L'application obligatoire renverse cette logique. Lorsque la 2SV est exigée, un mot de passe volé ne suffit plus à prendre le contrôle d'un compte — ce qui neutralise, en une seule mesure, la voie de compromission de compte la plus courante.

Choisissez vos facteurs de manière délibérée

Tous les seconds facteurs ne se valent pas. Du plus fort au plus faible :

• Passkeys et clés de sécurité matérielles (FIDO2). Résistants au phishing : ils s'associent de manière cryptographique au site légitime, si bien qu'une page de phishing ne peut pas les relayer. La référence absolue, fortement recommandée pour les administrateurs et autres comptes à forte valeur.
• Google Prompt / application d'authentification (TOTP). Une amélioration solide par rapport aux mots de passe, mais un kit de phishing en temps réel suffisamment déterminé peut relayer un code à usage unique. Adapté à la population générale.
• Codes SMS. Mieux que rien, mais vulnérable au SIM-swapping et à l'interception. Acceptable en solution de secours, pas comme facteur principal.

Une politique saine : exiger des facteurs forts, résistants au phishing, pour les administrateurs et les groupes sensibles, autoriser les codes générés par application pour tous les autres, et limiter au maximum le SMS.

Un déploiement par étapes qui évite les blocages

La crainte qui freine l'imposition de la MFA est celle de bloquer l'accès des utilisateurs. Échelonnez le déploiement pour écarter ce risque :

1. Communiquez en premier lieu. Informez l'organisation de ce qui change, pourquoi, et d'ici quand. Fournissez des instructions d'inscription. Une application surprise génère des tickets au support et du ressentiment.
2. Ouvrez une fenêtre d'inscription. Activez la 2SV en mode optionnel et fixez une échéance. Suivez la progression des inscriptions afin de repérer qui ne s'est pas encore inscrit.
3. Relancez les retardataires. À l'approche de l'échéance, rappelez les comptes qui ne se sont pas encore inscrits. C'est à ce moment que s'inscrit la majeure partie de la traîne.
4. Imposez avec une période de grâce pour les nouveaux utilisateurs. Activez l'application obligatoire, mais configurez une période de grâce pour les comptes nouvellement créés afin que l'intégration ne soit pas bloquée dès la première connexion.
5. Distribuez des options de secours. Assurez-vous que les utilisateurs disposent de codes de secours ou d'un second facteur enregistré, afin qu'un téléphone perdu ne soit qu'un désagrément mineur, et non un blocage.
6. Traitez les exceptions au cas par cas et de manière restreinte. Certains comptes de service ou partagés peuvent réellement avoir du mal avec une 2SV interactive. Faites-les basculer vers un modèle d'authentification plus adapté (clés de compte de service, traitement dédié) plutôt que de créer de larges exemptions dans votre politique utilisateurs.

La console Admin permet d'imposer l'application au niveau de l'unité organisationnelle, ce qui vous permet de piloter d'abord avec l'informatique, puis un service, puis l'ensemble de l'organisation — réduisant encore davantage le risque du déploiement.

Pièges courants

• Exempter les dirigeants « par commodité ». Les comptes à plus forte valeur sont les pires à exempter. Il faudrait au contraire leur imposer les facteurs les *plus forts*.
• N'autoriser que le SMS. Cela coche la case tout en laissant la porte ouverte au SIM-swap. Privilégiez les facteurs basés sur application ou matériels.
• Oublier les comptes de service et partagés. Ceux-ci détiennent souvent des accès importants et échappent à l'authentification interactive. Gérez-les de manière délibérée — voir détecter les agents IA et comptes de service à risque.
• Considérer le sujet comme réglé une bonne fois pour toutes. Les nouveaux comptes, les nouvelles exceptions et la dérive des politiques impliquent que l'application obligatoire nécessite une vérification périodique, et non un simple interrupteur activé une seule fois.

Vérifiez l'application obligatoire — ne la présumez pas

Activer la politique et confirmer qu'elle est *réellement appliquée à chaque compte* sont deux choses différentes. Les comptes créés avant la mise en place de la politique, ceux qui se trouvent dans une unité organisationnelle exemptée, ou ceux pris dans une période de grâce peuvent discrètement échapper à l'application obligatoire. Une posture Google Workspace security saine — et un contrôle que les auditeurs SOC 2 examinent spécifiquement au titre de CC6.1 — consiste notamment à vérifier que l'application de la MFA tient sur l'ensemble de l'organisation, et pas seulement que l'interrupteur est activé.

C'est exactement le type de configuration qui dérive avec le temps, et le type de preuve que les auditeurs vous demandent de fournir. Un outil de posture qui vérifie les paramètres à l'échelle de l'organisation signalera les endroits où la 2SV n'est pas appliquée (lorsque la visibilité administrateur pertinente est disponible), de sorte que « nous imposons la MFA » devienne un fait vérifié plutôt qu'une supposition.

Traiter les cas difficiles

La plupart des comptes s'inscrivent sans drame. Quelques catégories nécessitent un traitement délibéré, et la façon dont vous les gérez détermine souvent si l'application obligatoire tient réellement :

• Dirigeants et VIP. Ce sont des cibles de choix pour le phishing et les plus susceptibles de demander une exception. Imposez-leur les facteurs les plus forts plutôt que de les exempter. Un compte de dirigeant compromis compte parmi les pires scénarios possibles ; le confort ne vaut pas ce compromis.
• Boîtes aux lettres partagées et comptes de rôle. La 2SV interactive convient à un individu, pas à une boîte aux lettres utilisée par cinq personnes. Reconcevez ces accès en accès délégué vers des comptes individuellement protégés, afin que la protection suive de véritables personnes.
• Comptes de service et d'automatisation. Ceux-ci ne devraient effectuer aucune connexion interactive. Authentifiez-les avec des identifiants de compte de service gérés séparément, et gouvernez-les comme les identités non humaines qu'ils sont.
• Personnel de terrain et travailleurs de première ligne. Les personnes sans smartphone ou disposant d'une connectivité limitée ont besoin d'un facteur réalisable — clés matérielles ou codes de secours — planifié avant le jour de l'application, et non improvisé au support technique.

Le principe commun à tous ces cas : ne créez pas de larges exemptions dans votre politique utilisateurs pour accommoder quelques cas particuliers. Traitez chaque cas avec le mécanisme approprié afin que la base de référence reste intacte.

Après le déploiement : maintenir l'application obligatoire

L'application obligatoire n'est pas une ligne d'arrivée. Les nouveaux comptes, les unités organisationnelles nouvellement créées et les exceptions ponctuelles créent tous des voies par lesquelles la couverture peut s'éroder. Intégrez une vérification récurrente à votre routine : confirmez que la 2SV reste imposée dans toutes les unités organisationnelles, qu'aucune exemption n'est devenue discrètement permanente, et que les facteurs forts restent exigés là où vous les avez exigés. Le contrôle le plus solide au monde se dégrade si personne ne vérifie qu'il est toujours actif — et « nous imposons la MFA » devrait être une affirmation que vous pouvez prouver, et non une chose que vous espérez encore vraie.

8200.dev audite la configuration administrateur de votre Google Workspace — y compris l'application de la validation en 2 étapes, les contrôles de partage et l'authentification des e-mails — et signale toute dérive avec des liens directs vers le paramètre concerné. Voir comment ça marche.

Vous voulez confirmer que la MFA est réellement imposée partout ? Lancez votre audit de sécurité gratuit et obtenez un état des lieux de la posture d'identité et de configuration de votre Google Workspace.