Fall einer Betriebsblockade durch die Sperrung eines Google-Workspace-Kontos
(zencapital.substack.com)- Ein Vorfall, bei dem ein Google-Workspace-Konto wegen mutmaßlicher Kompromittierung gesperrt wurde und dadurch E-Mail- und Servicezugänge blockiert waren; obwohl der Domainbesitz per DNS-Verifizierung nachgewiesen wurde, verzögerte sich die Wiederherstellung
- Ein einzelnes Administratorkonto fungierte als Authentifizierungs-Hub für alle geschäftskritischen Systeme wie E-Mail, Drive, Calendar, Gehaltsabrechnung und CRM, sodass die Sperrung sofort zu einem unternehmensweiten Zugriffsverlust führte
- Nach dem Löschen der Wiederherstellungs-Telefonnummer während eines Logins im Ausland wurde ein falscher Sicherheitsalarm ausgelöst, was zu einem kompletten Login-Ausfall führte, bei dem selbst Backup-Codes und Passkeys unbrauchbar wurden
- Wegen des 30-Tage-Warteverfahrens des Google-Supports und wiederholter Verwirrung durch Tickets verzögerte sich die Wiederherstellung; auch über Community und soziale Netzwerke kam nur die Antwort, man solle „warten“
- Nach mehr als 40 Stunden Arbeitsausfall wurde der Zugang durch das Eingreifen eines Google-Mitarbeiters wiederhergestellt; der Fall zeigte, dass die Abhängigkeit von einem einzelnen Konto ein gravierendes Risiko für die Business Continuity darstellt
Fall einer Betriebsblockade durch die Sperrung eines Google-Workspace-Kontos
-
Fall, in dem ein Google-Workspace-Konto wegen „mutmaßlicher Kompromittierung“ gesperrt wurde und der E-Mail-Zugang blockiert war
- Tatsächlich hatte sich der Betroffene während einer Auslandsreise selbst eingeloggt, doch Google interpretierte dies fälschlich als Kontoübernahme
- Obwohl der Domainbesitz per DNS-Verifizierung nachgewiesen wurde, wurden sowohl eingehende als auch ausgehende E-Mails vollständig unterbrochen
-
Ein einzelnes Administratorkonto fungierte als Authentifizierungs-Hub für alle Dienste
- E-Mail, Drive, Calendar, Gehaltssystem, CRM (Pipedrive), Aufgabenverwaltungs-App und interne Systeme waren sämtlich von Google OAuth abhängig
- Mit der Kontosperrung wurde der Zugriff auf alle Dienste sofort blockiert, was zu einem unternehmensweiten Arbeitsstillstand führte
-
Ablauf des Vorfalls
- Am 4. April gegen 5 Uhr morgens wurde während einer Auslandsreise die Wiederherstellungs-Telefonnummer gelöscht, um SMS-Authentifizierung zu vermeiden
- Unmittelbar danach erschien eine falsche Sicherheitswarnung, dass die Authenticator-App entfernt worden sei, und der Zustand wechselte zu „Login nicht möglich“
- Backup-Codes, Passkeys und bereits eingeloggte Geräte funktionierten sämtlich nicht mehr als Authentifizierungsmittel
-
Wiederherstellungsversuche und Verwirrung durch den Google-Support
- Die Verifizierung per DNS-CNAME-/TXT-Record wurde abgeschlossen, doch das Verfahren über die Wiederherstellungs-E-Mail erforderte eine Wartezeit von 30 Tagen
- Es wurde über ein anderes Workspace-Konto Support angefragt, doch es wurden nur Links bereitgestellt, die einen Login erforderten, sodass kein Fortschritt möglich war
- Wiederholt kam es zu Verwirrung, weil Tickets zwischen verschiedenen Support-Mitarbeitern dupliziert, geschlossen und wieder geöffnet wurden
- Auch bei Anfragen über das Community-Forum und X.com kam wiederholt nur die Antwort, man solle „warten“
-
Geschäftliche Auswirkungen und verstrichene Zeit
- Durch die um mehr als 40 Stunden verzögerte Wiederherstellung kamen Gehaltsabrechnung, Google-Meet-Besprechungen und Termine für Geschäftsverhandlungen vollständig zum Erliegen
- Teilweise wurde auf eine private E-Mail-Adresse ausgewichen, doch wegen der nötigen Trennung vom geschäftlichen Konto war dies nur begrenzt praktikabel
-
Weitere Updates
- Update 1: MX-Records können auf einen anderen Maildienst umgestellt werden, aber bestehende E-Mails und Kalender lassen sich dadurch nicht wiederherstellen
- Update 2: Die Zusage des Google-Supports „Update in 1–2 Stunden“ wurde wiederholt, doch die Lösung verzögerte sich weiter
- Update 3: Durch das direkte Eingreifen eines Google-Mitarbeiters gelang schließlich die Wiederherstellung des Logins
Lehren aus dem Vorfall und Reaktionen der Community
- Hacker-News-Nutzer wiesen darauf hin, dass mehrere Risikosignale gleichzeitig auftraten, darunter Länderwechsel, das Löschen der Wiederherstellungs-Telefonnummer und unveränderte MX-Records
- Der Autor erklärte, dass das Konto nach dem Länderwechsel sechs Tage lang unter derselben IP normal genutzt worden war und das Löschen der Telefonnummer den direkten Auslöser darstellte
- Die MX-Records hätten auf Fastmail oder Protonmail umgestellt werden können, doch wegen bestehender Probleme mit E-Mails, Kalendern und OAuth-Logins war das keine praktikable Alternative
- Obwohl Zwei-Faktor-Authentifizierung, Passkeys, Backup-Codes, Wiederherstellungs-E-Mail und Zugriff über dasselbe Gerät sämtlich vorhanden waren, scheiterte die Wiederherstellung
- Der Fall zeigt, dass eine übermäßige Abhängigkeit von einem einzelnen Google-Workspace-Konto ein schwerwiegendes Risiko für die Business Continuity darstellt
1 Kommentare
Hacker-News-Meinungen
Google wirkte früher wie das „weniger böse Big Tech“, aber die tatsächliche Erfahrung mit dem Kundensupport war furchtbar
Ich habe ein Pixel gekauft, aber das versprochene einjährige Gemini AI Pro-Abo nicht erhalten, und der Support hat überhaupt nichts gelöst
Ein Freund hatte dasselbe Problem, und auch bei einer Tarifänderung von Google One machte er ähnliche Erfahrungen mit völliger Untätigkeit
Inzwischen sehe ich keinen Grund mehr, Google-Dienste zu wählen, wenn man nicht Millionen von Dollar ausgibt
Als ich um 2008 wegen eines Blogspot-Bugs nachfragte, wurde ich von einem „Diamond“-Freiwilligen ignoriert. Es gab keinen Weg, an das echte Support-Team heranzukommen
Laut dem Artikel Google’s broken privacy promise wurde die Klausel entfernt, keine aus Diensten wie Gmail gewonnenen Informationen mit Werbedaten zu kombinieren
Schon wieder ist ein Artikel erschienen nach dem Muster: „Ein Cloud-Anbieter hat mein Konto gesperrt und ich habe alles verloren“
Nicht nur bei Google, sondern bei Amazon, Microsoft, Apple und anderen Cloud-Diensten sollten Menschen, die davon abhängen, einen Plan für Kontosperrungen haben
Wenn man dort wichtige Daten anvertraut, sind Backups oder Alternativen zwingend notwendig
Ein wiederherstellbares „external backup“ außerhalb des SaaS-Dienstes zu haben, ist schwieriger als gedacht, aber absolut notwendig
Die Funktion „Login with Google/Apple/Facebook“ sollte man möglichst nicht verwenden
Denn damit schafft man einen Single Point of Failure. Wenn möglich, ist ein eigenes Login-System sicherer
Als ehemaliger Googler habe ich Gmail nur genutzt, solange ich internen Zugriff hatte, und nach meinem Weggang habe ich auch Gmail aufgegeben
Ich bin ehrenamtlicher Systemadministrator des Buildhub-Forums
Es war 10 Jahre lang weit oben in der Google-Suche, ist aber am 28. Dezember 2025 plötzlich aus dem Index verschwunden
Die Google-Foren sind leer, und es gibt niemanden, den man kontaktieren könnte. Als zahlender Workspace-Kunde denke ich ernsthaft über einen Backup-Plan nach
Einige scheinen das System gamifizieren zu wollen, in der Hoffnung auf eine Einladung ins Google-HQ
Ich war 2013 ein früher Google-Glass-Nutzer. Ich wurde direkt im New Yorker HQ geschult und hatte sogar eine dedizierte Support-Nummer mit 24-Stunden-Erreichbarkeit
Ich habe das Gerät zweimal zerstört und jedes Mal kostenlos Ersatz bekommen. Früher war so ein Kundensupport möglich
Die Qualität des Google-Kundensupports ist je nach Produktabteilung extrem unterschiedlich. Workspace ist dabei besonders schlimm
Diese Situation ist nahe an Illegalität. Je mehr Lebensbereiche große Konzerne kontrollieren, desto machtloser werden normale Menschen
Wer essenzielle Dienste anbietet, muss auch die entsprechende Verantwortung tragen
Wie bei Telekommunikationsanbietern sollte in jeder Filiale Personal sein, und Google könnte sich das problemlos leisten
Ich habe den Wiederherstellungsprozess für ein Administratorkonto durchlaufen, und die Sicherheitsrichtlinie war widersprüchlich
Das Konto wurde zwar manuell entsperrt, aber trotzdem wurde weiterhin eine SMS-Verifizierung an eine gelöschte Nummer verlangt
Selbst nach dem Hinzufügen von Sicherheitsschlüssel oder TOTP blieb SMS verpflichtend. Wenn die Nummer kompromittiert ist, ist alles vorbei
Obwohl ich Benutzername, Passwort und Wiederherstellungs-E-Mail hatte, verlangte es eine SMS-Verifizierung an eine nicht mehr vorhandene Nummer, sodass ich mich nicht einloggen konnte
Bei Meta gibt es wenigstens Leute, die gegen Geld helfen, bei Google überhaupt nicht
Wenn man Google Workspace ohne ein Betriebsteam auf Enterprise-Niveau nutzt, wird ein einziges Administratorkonto zum Single Point of Failure
Ich geriet in eine Authentifizierungsschleife, in der alle Wege blockiert waren, und erst nachdem ich mehrfach mit rechtlichen Schritten gedroht hatte, konnte ich mit einem Menschen sprechen und das Problem lösen
Es ist auch möglich, dass der Autor gehackt wurde. Vielleicht wurden das OTP-Gerät oder der DNS-Zugriff übernommen, aber die Telefonnummer nicht
In so einer Situation gibt es keine Möglichkeit zu beweisen, dass man wirklich der Eigentümer ist. Es wäre gut, wenn es ein Büro gäbe, in dem man persönlich mit Reisepass vorsprechen und sich verifizieren könnte
Ein Modell wie bei den USA mit login.gov und Identitätsprüfung auf der Post ist interessant
Kommerziell ist das allerdings schwer umzusetzen, und der Trend zu verpflichtender Online-Identifikation stößt auf Widerstand
Google blockiert das Konto lieber, statt zu entscheiden, wer recht hat
Kaum zu glauben, aber Microsoft (Office365) hat tatsächlich einen telefonisch erreichbaren Support
Die UI ist schrecklich, aber das Problem wurde am Ende gelöst
Das hat aber auch den Vorteil, dass es tatsächlich viele Menschen gibt, die reale Probleme lösen können
Zugehöriger Artikel: HN discussion