Cas de paralysie opérationnelle causée par la suspension d’un compte Google Workspace

• Incident où un compte Google Workspace a été suspendu pour suspicion de piratage, bloquant l’accès aux e-mails et aux services ; malgré une preuve de propriété du domaine via authentification DNS, la restauration a été retardée
• Un compte administrateur unique faisait office de hub d’authentification pour tous les systèmes de travail : e-mail, Drive, Calendar, paie, CRM, etc., provoquant une impossibilité d’accès à l’échelle de l’entreprise dès la suspension
• Après la suppression du numéro de téléphone de récupération pendant une connexion depuis l’étranger, une fausse alerte de sécurité s’est déclenchée, menant à une impossibilité totale de se connecter, même avec les codes de secours et les passkeys
• En raison de la procédure d’attente de 30 jours et de tickets d’assistance confus et répétés côté Google, la restauration a été retardée ; même via la communauté et les réseaux sociaux, la seule réponse a été « attendez »
• Après plus de 40 heures d’interruption, l’accès a été restauré grâce à l’intervention d’un employé de Google, révélant que la dépendance à un compte unique constitue un risque critique pour la continuité d’activité

---

Cas de paralysie opérationnelle causée par la suspension d’un compte Google Workspace

• Cas où l’accès aux e-mails a été bloqué après la suspension d’un compte Google Workspace pour « suspicion de piratage »

  • En réalité, il s’agissait de la connexion du propriétaire lui-même pendant un voyage d’affaires à l’étranger, mais Google l’a interprétée à tort comme une compromission du compte
  • Bien que la propriété du domaine ait été prouvée via authentification DNS, l’envoi et la réception des e-mails ont été entièrement interrompus

• Un compte administrateur unique servait de hub d’authentification pour tous les services

  • L’e-mail, Drive, Calendar, le système de paie, le CRM (Pipedrive), l’application de gestion des tâches et les systèmes internes dépendaient tous de Google OAuth
  • Dès la suspension du compte, l’accès à tous les services a été bloqué, entraînant un arrêt généralisé de l’activité

• Déroulement de l’incident

  • Le 4 avril vers 5 h du matin, pendant un voyage d’affaires à l’étranger, le numéro de téléphone de récupération a été supprimé afin d’éviter l’authentification par SMS
  • Juste après, une fausse alerte de sécurité indiquant que « l’application d’authentification a été supprimée » s’est déclenchée, faisant basculer le compte dans un état d’impossibilité de connexion
  • Les codes de secours, les passkeys et même les appareils déjà connectés n’ont pas pu être utilisés comme moyens d’authentification

• Tentatives de restauration et confusion du support Google

  • La vérification via enregistrements DNS CNAME/TXT a été effectuée, mais la procédure de récupération par e-mail imposait une attente de 30 jours
  • Une demande d’assistance a été faite via un autre compte Workspace, mais seul un lien nécessitant une connexion a été fourni, empêchant toute avancée
  • La confusion s’est répétée entre plusieurs agents du support, avec des tickets dupliqués, fermés puis rouverts
  • Même via le forum communautaire et X.com, la réponse répétée a été « attendez »

• Impact opérationnel et durée

  • En raison d’un retard de restauration de plus de 40 heures, le traitement de la paie, les réunions Google Meet et le calendrier des négociations commerciales ont tous été interrompus
  • Une partie du travail a été basculée sur une adresse e-mail personnelle, mais cette solution restait limitée en raison de la nécessité de maintenir la séparation avec le compte professionnel

• Mises à jour supplémentaires

  • Update 1: il était possible de basculer les enregistrements MX vers un autre service de messagerie, mais les anciens e-mails et calendriers restaient irrécupérables
  • Update 2: la promesse du support Google d’une « mise à jour dans 1 à 2 heures » a été répétée, mais la résolution a continué à être retardée
  • Update 3: la restauration finale de la connexion a réussi grâce à l’intervention directe d’un employé de Google

Leçons tirées après l’incident et réactions de la communauté

• Les utilisateurs de Hacker News ont souligné que plusieurs signaux de risque s’étaient produits simultanément : changement de pays, suppression du numéro de récupération, absence de modification des enregistrements MX, etc.
• L’auteur a expliqué qu’après le changement de pays, le compte avait été utilisé normalement pendant 6 jours depuis la même IP, et que la suppression du numéro de téléphone avait joué un rôle direct dans l’incident
• Les enregistrements MX auraient pu être basculés vers Fastmail ou Protonmail, mais cela n’aurait pas constitué une alternative réelle en raison des problèmes liés aux anciens e-mails, au calendrier et aux connexions OAuth
• Malgré la possession de l’authentification à deux facteurs, des passkeys, des codes de secours, d’une adresse e-mail de récupération et de l’accès au même appareil, la récupération a échoué
• Ce cas a montré que la dépendance excessive à un unique compte Google Workspace constitue un risque grave pour la continuité d’activité