Déployer la 2SV obligatoire dans Google Workspace : tutoriel pas-à-pas

📍 Article principal : Google Workspace pour PME : architecture et gouvernance
Ce tutoriel détaille le déploiement de la 2-Step Verification dans une organisation Workspace : audit, sécurisation des super-administrateurs, opt-in puis enforcement gradué, codes de secours.

Objectif

Activer la 2-Step Verification pour l’ensemble des comptes d’une organisation Workspace en respectant le calendrier d’enforcement Google et en limitant les blocages. Sécuriser les comptes super-administrateurs avec clés FIDO2.

Calendrier d’enforcement Google (référence officielle)

Source : About 2SV enforcement for admins.

• Notification 90 jours avant l’enforcement pour les super-administrateurs.
• Notification 60 jours avant pour les autres administrateurs.
• J+7 après échéance : rappels persistants dans la console.
• J+15 : blocage de l’accès aux applications mobiles Workspace.
• J+30 : blocage de l’accès aux applications web.
• Aucun contournement possible. Un administrateur qui ne peut pas activer la 2SV doit voir ses droits administrateur retirés.

Premières organisations concernées : Workspace for Education, Workspace for Nonprofits, Cloud Identity, Android Enterprise. Extension progressive aux autres clients.

Prérequis

• Tenant Workspace fonctionnel, rôle super-administrateur disponible.
• Liste des utilisateurs organisée en OU et groupes.
• Au moins deux clés FIDO2 par compte super-admin (Yubikey, Titan Security Key, ou équivalent).
• Canal de communication interne (mail, messagerie d’équipe, intranet).
• Niveau : intermédiaire à avancé.
• Calendrier : 30 jours.

Étape 1 — Audit initial

Dans la console admin.google.com : Sécurité → Authentification → Validation en deux étapes. Le panneau affiche le pourcentage de comptes ayant activé la 2SV par OU et par groupe.

Dans Rapports → Rapports utilisateur → Sécurité, filtrer sur le statut 2SV pour exporter la liste des comptes non conformes. Identifier en priorité les super-administrateurs et administrateurs délégués (premiers soumis à l’enforcement Google).

Étape 2 — Sécurisation des super-administrateurs avec clés FIDO2

Pour les comptes super-admin, le SMS est à proscrire (vulnérabilité au SIM swapping documentée par NIST). La méthode robuste documentée est la clé FIDO2 hardware (résistante au phishing par design).

Acheter deux clés par super-admin (une opérationnelle, une de secours en coffre). Sur le compte super-admin, dans Mon compte → Sécurité → Validation en deux étapes :

1. Cliquer Commencer, suivre l’assistant avec le numéro de téléphone comme méthode initiale (étape obligatoire).
2. Section Clés de sécurité : enregistrer les deux clés en suivant les instructions de connexion physique sur port USB ou NFC.
3. Une fois les deux clés enregistrées, retirer le numéro de téléphone et toutes les autres méthodes — la connexion super-admin nécessite désormais une clé physique.

Test : se déconnecter, se reconnecter — seule la clé doit fonctionner. Configurer en parallèle l’email de récupération externe au tenant et un numéro de téléphone secondaire dans Mon compte → Informations personnelles, qui servent en dernier recours.

Étape 3 — Annonce du déploiement

Diffuser un message d’annonce couvrant : raison (enforcement Google obligatoire), effet pratique (un code à saisir une fois par appareil, pas tous les jours), procédure d’activation (lien direct), date butoir d’opt-in volontaire (J+15), date d’enforcement (J+30).

Diffuser sur trois canaux distincts : mail à tous, signature mail des administrateurs, canal général de la messagerie d’équipe.

Étape 4 — Phase opt-in (J+1 à J+15)

Dans la console : Sécurité → Authentification → Validation en deux étapes → Modifier les paramètres. Sur l’OU racine :

• Autoriser les utilisateurs à activer la validation en deux étapes : oui.
• Application : désactivée pour cette phase.
• Méthodes autorisées : toutes pour les utilisateurs standards. Pour les administrateurs, restreindre à clé physique, application TOTP et Google Prompt (exclure SMS et appels vocaux).

Surveiller la progression de l’adoption tous les 3 jours dans le rapport. Contacter individuellement les utilisateurs en blocage technique.

Étape 5 — Provisioning des codes de secours

Avant le forçage, demander à chaque utilisateur de générer ses codes de secours via Mon compte → Sécurité → Validation en deux étapes → Codes de secours → Afficher les codes. Google génère 10 codes à usage unique. Stocker dans un gestionnaire de mots de passe ou imprimer.

Pour les administrateurs : configurer en plus l’email de récupération externe au tenant et un numéro de téléphone secondaire (cf. étape 2).

Étape 6 — Activation de l’enforcement (J+15)

Dans Sécurité → Authentification → Validation en deux étapes → Modifier les paramètres sur l’OU racine :

• Application : activée.
• Date d’application : J+30.
• Période d’inscription : 15 jours (la fenêtre durant laquelle un nouvel utilisateur a le temps de s’enrôler avant blocage).

Pour les comptes service (intégrations, scanners, scripts) : créer une OU dédiée Comptes service avec la 2SV désactivée pour cette OU. Tout autre compte non humain doit migrer vers OAuth2 ou Service Account avec clé d’API gérée plutôt que mot de passe + 2SV.

Étape 7 — Context-Aware Access (éditions éligibles uniquement)

Disponible sur Frontline Standard et Plus, Enterprise Standard et Plus, Enterprise Essentials Plus, Education Standard et Plus, Cloud Identity Premium. Non disponible sur Business Starter, Standard, Plus.

Sur ces éditions : Sécurité → Context-Aware Access → Créer un niveau d’accès. Définir des niveaux par sensibilité :

• Strict : appareil chiffré + OS à jour + pays = liste explicite (par exemple Sénégal, Mali, Côte d’Ivoire, France).
• Standard : moins restrictif, sans condition pays.

Dans Sécurité → Context-Aware Access → Affecter les niveaux : Gmail et Drive avec niveau Standard pour l’organisation, Admin Console et Vault avec niveau Strict pour les groupes administrateurs.

Étape 8 — Vérification au J+30

Dans Rapports → Rapports utilisateur → Sécurité, conformité 2SV doit afficher 100 % sur les OU concernées (à l’exception des OU Comptes service explicitement exclues).

Dans Rapports → Audit → Connexion, filtrer sur les événements Échec de connexion par défaut de 2SV — ce nombre doit tendre vers zéro. Identifier les utilisateurs encore en échec et finaliser leur enrôlement.

Mettre en place un déclencheur dans le processus d’arrivée RH : tout nouveau salarié doit avoir activé sa 2SV avant le 7e jour de présence.

Erreurs fréquentes

Tutoriels associés

• Configurer Google Workspace pour une PME — la 2SV s’enchaîne après le setup initial.
• Mettre en place les Drive partagés Google Workspace.

Références officielles

• 🔝 Retour au guide de référence
• 2SV enforcement for admins
• Déployer la validation en deux étapes
• Éviter les verrouillages pendant l’application 2SV
• Context-Aware Access — éditions supportées
• Yubikey pour Google Workspace

FAQ

Coût de mise en place ?
La 2SV elle-même est gratuite, incluse dans tous les plans Workspace. Coût matériel pour les administrateurs : compter 25 à 50 EUR par clé Yubikey, deux clés par super-admin.

Désactivation possible pour un utilisateur en difficulté ?
Oui pour un utilisateur standard, en sortie temporaire avant réenrôlement. Non pour un administrateur soumis à l’enforcement Google — la seule option est le retrait de ses droits administrateur.

SMS vraiment moins sûr ?
Oui. Le SIM swapping est un vecteur documenté (NIST SP 800-63B déconseille SMS comme out-of-band authenticator depuis 2017). Pour les administrateurs : à proscrire. Pour les utilisateurs standards : acceptable comme méthode de secours.

Perte de codes de secours et téléphone ?
L’administrateur peut désactiver temporairement la 2SV pour un utilisateur standard depuis la console. L’utilisateur génère de nouveaux codes après reconnexion, puis réactive la 2SV.

Context-Aware Access sur Business Plus ?
Non. Disponible uniquement sur les éditions listées par Google : Frontline Standard/Plus, Enterprise Standard/Plus, Enterprise Essentials Plus, Education Standard/Plus, Cloud Identity Premium.

Durée totale du déploiement ?
30 jours calendaires en suivant la séquence opt-in puis enforcement. Imposer en moins de 15 jours est techniquement possible mais provoque mécaniquement de la résistance et des appels au support.