- Das Google-Cloud-Konto von SSLMate wurde zum dritten Mal ohne Vorankündigung gesperrt, wodurch Integrationsfunktionen des Dienstes wiederholt ausfielen
- Für die Integration von Cloud DNS und Cloud Domains der Kunden wurde gemäß der Google-Dokumentation eine Struktur mit Service Accounts und Delegation verwendet, doch genau dieser Ansatz geriet wiederholt ins Visier von Sperrungen
- Die erste Sperrung (2024) führte wegen des ineffizienten Wiederherstellungsprozesses und unklarer Ursachen zu großer Verwirrung; auch bei den beiden späteren Sperrungen gab es keine Vorabbenachrichtigung, sondern nur wiederholte automatisierte E-Mails
- Als Alternativen sind Authentifizierung mit langlebigen Schlüsseln sicherheitstechnisch schwach, und OIDC (OpenID Connect) ist in der Einrichtung übermäßig komplex
- Insgesamt zeigt sich bei Google-Cloud-Integrationen eine strukturelle Grenze, bei der sich nur zwei von Sicherheit, Komfort und Stabilität zugleich wählen lassen
Wiederholte Sperrungen eines Google-Cloud-Kontos
- Das Google-Cloud-Konto von SSLMate wurde 2024 sowie 2025 an zwei aufeinanderfolgenden Freitagen ohne Vorankündigung gesperrt
- Zuvor hatte es bereits 2024 dieselbe Sperrung gegeben; bei allen drei Fällen wurden weder klare Gründe noch Maßnahmen zur Vermeidung künftiger Vorfälle genannt
- SSLMate verwendet zur Integration mit den Google-Cloud-Konten seiner Kunden delegierte Service Accounts
- Für jeden Kunden wird innerhalb eines SSLMate-Projekts ein Service Account erstellt, dem der Kunde Zugriffsrechte auf Cloud DNS und Cloud Domains gewährt
- SSLMate kann bei Bedarf diesen Service Account virtuell impersonate und so zugreifen
- Dieser Aufbau basiert auf der von Google offiziell empfohlenen Vorgehensweise und ist ohne langlebige Zugangsdaten sicher und einfach einzurichten
Erste Sperrung (2024)
- Bei der ersten Sperrung scheiterten alle Kundenintegrationen, und der Zugriff auf die Konsole war blockiert
- Das Google-Support-Team reagierte zwar, doch der Wiederherstellungsprozess war ineffizient, unter anderem weil E-Mails wegen des deaktivierten Kontos zurückgewiesen wurden
- Es wurde nach der Projekt-ID gefragt, die wegen des fehlenden Konsolenzugriffs nicht bereitgestellt werden konnte
- Nach Verifizierung per Telefonnummer wurden nur einige Projekte wiederhergestellt; am nächsten Tag folgte erneut eine automatische E-Mail mit Zugriffsbeschränkungen
- Nach mehreren weiteren automatisierten E-Mails erfolgte die vollständige Wiederherstellung nach etwa 19 Stunden
- Google nannte keinen Grund für die Sperrung und hatte auch vorher keine Benachrichtigung per E-Mail gesendet
- SSLMate ergänzte danach Health Checks zur Überwachung der Fehlerrate von Integrationen, um Probleme früher zu erkennen
Zweite Sperrung (etwa Oktober 2025)
- Die Health Checks schlugen fehl, und die meisten Integrationen lieferten den Fehler "Invalid grant: account not found" zurück
- Die Anmeldung an der Konsole war möglich, aber für jedes Projekt gingen nur E-Mails mit dem Hinweis ein, es sei „anhand der bereitgestellten Informationen wiederhergestellt“ worden
- Eine Benachrichtigungs-E-Mail über die Sperrung ging weiterhin nicht ein
- Später funktionierten die Integrationen wieder normal
Dritte Sperrung (November 2025)
- Nach einem erneuten Fehlschlag der Health Checks erschien beim Zugriff auf die Konsole eine neue Art von Fehlermeldung
- Die meisten Projekte waren gesperrt, darunter auch die Projekte für Kundenintegrationen
- Am Freitag wurde Einspruch eingelegt; am Sonntag folgte dann eine E-Mail über die Sperrung des gesamten Kontos
- Am Montag, kurz nachdem der Beitrag auf Hacker News erschienen war, wurden die meisten Projekte wiederhergestellt; einige Stunden später war der vollständige Zugriff zurück
- Auch diesmal wurden weder die Ursache der Sperrung noch Präventionsmaßnahmen genannt
Sonderfall bei einem Kunden
- Während aller Sperrungszeiträume funktionierte nur die Integration eines Kunden weiterhin normal
- Obwohl derselbe Service Account innerhalb desselben Projekts verwendet wurde, war diese Integration nicht betroffen
- Eine weitere Erklärung für die Ursache gibt es nicht
Probleme der Abhängigkeit von Google Cloud und Alternativen
- SSLMate kam zu dem Schluss, dass man sich in Produktionsumgebungen nicht auf ein Google-Konto verlassen kann
- Das Google-System ist so aufgebaut, dass Konten, Projekte oder sogar GCP insgesamt willkürlich gesperrt werden können
- Alternative 1: Der Kunde erstellt selbst einen Service Account und stellt SSLMate die Authentifizierung über einen langlebigen Schlüssel (long-lived key) bereit
- Die Einrichtung ist einfach, aber wegen des Risikos eines Schlüssellecks und der fehlenden Rotierbarkeit sicherheitstechnisch schwach
- Alternative 2: Einsatz von OpenID Connect (OIDC)
- Dies ist der Standardansatz bei GitHub Actions oder Azure-Integrationen und ermöglicht sicheren Zugriff ohne langlebige Zugangsdaten
- In Google Cloud ist die Einrichtung jedoch mit einem 7-stufigen Verfahren übermäßig kompliziert
Die Komplexität der OIDC-Einrichtung
- Für OIDC sind die folgenden Schritte erforderlich
- IAM Service Account Credentials API aktivieren
- Service Account erstellen
- Workload Identity Pool erstellen
- Innerhalb des Pools einen Workload Identity Provider erstellen
- SSLMate die Berechtigung erteilen, den Service Account zu impersonate
- Dem Service Account eine Rolle (Role) zuweisen
- Den erstellten Service Account und die Provider-ID an SSLMate übermitteln
- Jeder Schritt benötigt die Ressourcen-ID aus dem vorherigen Schritt, was es für Kunden schwer nachvollziehbar macht
- Der Autor bezeichnet die folgenden Punkte als unnötige Verfahrensschritte
- Rollen sollten auch ohne das Anlegen eines Service Accounts direkt zugewiesen werden können
- In den meisten Fällen enthält ein Pool nur einen einzigen Provider, daher ist das Erstellen des Pools selbst unnötige Doppelarbeit
- Auch ohne das Erstellen eines Providers sollte es möglich sein, Rollen direkt einer OIDC-Issuer-URL und einem Subject zuzuweisen
Strukturelles Problem und Fazit
- Bei der aktuellen Google-Cloud-Integration lassen sich von den folgenden drei Punkten nur zwei zugleich erreichen
- Keine langlebigen Zugangsdaten
- Einfache Einrichtung für Kunden
- Sicherheit vor willkürlichen Sperrungen
- Der service-account-basierte Ansatz von SSLMate bietet Sicherheit und Komfort, birgt aber das Risiko einer Sperrung
- Der Ansatz mit Service Account plus Schlüssel ist einfach einzurichten und weniger anfällig für Sperrungen, aber sicherheitstechnisch schwächer
- Der OIDC-Ansatz bietet Sicherheit und Schutz vor Sperrungen, ist aber kompliziert einzurichten
- Das Fazit lautet: Solange Google OIDC nicht als erstklassigen Integrationsweg vereinfacht, sind sichere und stabile Integrationen nur schwer zu erreichen
Zusammenfassung der Leserkommentare
- Ein Leser schrieb: „Nutzt einen anderen Cloud-Anbieter, GCP ist der schlechteste“
- Der Autor antwortete, dass dies wegen der Nutzung von GCP durch die Kunden für Integrationen dennoch erforderlich sei
- Ein anderer Leser meinte: „Sicherheit und Zuverlässigkeit stehen im Konflikt mit Einfachheit“, und Kunden, die Einfachheit priorisieren, seien dafür womöglich nicht geeignet
2 Kommentare
„Android-Entwicklerverifizierung würde am Ende genau so laufen. Viele Leute würden vom Entwickeln für Android ausgeschlossen werden.“
Das ist wohl der Hacker-News-Kommentar, der mir am meisten im Gedächtnis geblieben ist. Ich denke, das ist nicht mehr fern.
Hacker-News-Kommentare
Viele halten Google für einen vertrauenswürdigen Partner, aber in Wirklichkeit ist es ein System, das wie eine riesige Einzelhandelsfabrik aufgebaut ist.
Es ist auf Hunderte Millionen Menschen ausgelegt, und schon eine einzige falsche automatische Schutzmaßnahme kann das Leben Tausender ruinieren.
Fehlender Kundensupport oder automatisierte inhaltsleere Antworten wirken nicht wie bloße Kostensenkung, sondern wie eine Strategie zur Minimierung rechtlicher Haftung.
Die meisten wissen, dass ein Google-Konto jederzeit ohne Begründung gesperrt werden kann.
Fast jeder kennt tatsächlich ein oder zwei Personen, die den Zugriff auf ihr Konto verloren haben.
Außer bei Verträgen in Millionenhöhe gibt es wohl kaum jemanden, der Google wirklich als Partner betrachtet.
Alle Plattformen priorisieren Skalierung.
Es ist unmöglich, eine menschliche Beziehung zu einzelnen Nutzern aufrechtzuerhalten und zugleich die Rentabilität eines Drogenhändlers zu bewahren.
Wenn dabei ein unschuldiger Mensch hängen bleibt, gilt das als „notwendiger Preis“.
Gestern war es Wise, davor wurden GitHub-Konten auf diese Weise blockiert.
Unternehmen funktionieren nicht wie Demokratien, sondern eher wie feudale Herrschaftsgebiete.
Wenn ein automatisiertes System dich für einen Kriminellen hält, wirst du sofort bestraft — ohne Verfahren.
Dort kann man mit echten Menschen sprechen und nicht nur mit simplen Chatbots.
Ich nutze derzeit Tuta Mail und mag die quantenresistente Verschlüsselung sowie die werbefreie Umgebung.
Mit meiner eigenen Domain kann ich außerdem so viele Alias-Adressen anlegen, wie ich will.
Vor ein paar Jahren wurde mein YouTube-Premium-Konto wegen angeblichen Spams gesperrt.
Ich hatte einfach nur Videos angesehen, trotzdem wurde das Konto gelöscht und sogar der Zugang zur Zahlungsseite blockiert.
Während ich das robotische Einspruchsverfahren durchlief, das nur einmal alle drei Wochen möglich war, wurden weiter Gebühren abgebucht.
Selbst der bezahlte Support von Google One war nutzlos und erklärte nur, ein anderes Team sei zuständig und könne nicht helfen.
Am Ende konnte ich es nur durch die Sperrung meiner Karte lösen; Monate später bekam ich dann die Nachricht, es sei „ein Fehler“ gewesen.
Ironischerweise konnte WeChat das Problem innerhalb eines Tages durch ein Gespräch mit einem Menschen lösen — da kam mir der Gedanke, dass der Kundensupport eines Zensurstaats besser ist.
Das Problem ist nicht nur Google, sondern die gesamte Struktur großer, algorithmusabhängiger Konzerne.
Auch auf Reddit wurde mein 20 Jahre altes Konto ohne Grund shadowgebannt.
Einsprüche wurden ignoriert, und alle meine Beiträge und Kommentare wurden gefiltert.
Das Fediverse zeigt ein besseres alternatives Modell — entscheidend sind kleine Communities und ein hoher Anteil an Moderatoren.
Eine einzige #fediblock-Markierung führt dazu, dass man auf Hunderten von Servern automatisch blockiert wird; damit wiederholt sich nur verantwortungslose Zensur.
Tatsächlich ist der Mastodon-Server unserer Stadt genau daran zugrunde gegangen, und alle sind zu Bluesky gewechselt.
Es wäre nicht schwer, etwa 100 Leute einzustellen, die sich um solche Edge Cases kümmern.
Aber weil das die Margen senken würde, macht man es nicht.
Es liegt nicht daran, dass das Geld fehlt, sondern daran, dass man sich bewusst dagegen entscheidet, es auszugeben.
Solche Probleme wird es künftig wohl auch bei der Gemini API geben.
Wenn ein Kunde ein Bild erzeugt, das gegen Regeln verstößt, könnten sofort sogar das geschäftliche Gmail-Konto oder das private Gmail zur Wiederherstellung dauerhaft gesperrt werden.
Mit der Verifizierung von Android-Entwicklern dürfte es ähnlich laufen.
Viele Entwickler könnten ohne nachvollziehbaren Grund ihre Entwicklerberechtigung verlieren.
Ich habe einmal einen Fall gesehen, in dem die privaten Konten von Mitarbeitern eines kleinen Unternehmens gleich mit blockiert wurden, weil sie „mit einem zuvor gesperrten Entwicklerkonto in Verbindung standen“.
Ich glaube, unter einer so starken Abhängigkeit von der Plattform ist es schwer, echte Fachkompetenz langfristig aufrechtzuerhalten.
Unser Dienst nutzte auch nur schlicht den Button „Login with Google“, und plötzlich wurde das Konto gesperrt.
Als Begründung gab es nur den vagen Hinweis auf einen „Verstoß gegen die Nutzungsbedingungen“.
Während wir Einspruch einlegten und hastig Alternativen für den Nutzer-Login vorbereiteten, kam am nächsten Tag plötzlich eine Mail: „Einspruch genehmigt“.
Am Ende wurde alles wiederhergestellt, aber das Misstrauen blieb.
Mein AdSense-Konto wurde dreimal gesperrt, weil ich in einer Anzeige ein einziges Ausrufezeichen verwendet hatte.
Am Ende habe ich das Konto geschlossen, aber ich habe das Gefühl, dass ich immer noch als „potenziell betrügerisches Konto“ verfolgt werde.
Wenn neue Nutzer schon nach einer Stunde gesperrt werden, fragt man sich, warum der Anmeldeprozess überhaupt so niedrigschwellig gestaltet ist.
In so einer Situation fragt man sich, ob man Google verklagen oder strengere Regulierung fordern sollte.
Ich habe gehört, dass Google dort oft gar nicht erscheint oder mit Verweisen auf die TOS argumentiert und damit beim Richter eher das Gegenteil erreicht.
Ich frage mich, was mit Konten passiert, die nur über Passkey-Login laufen und mit einer gesperrten E-Mail-Adresse registriert wurden.
Ob ein in Google Password Manager synchronisierter Passkey nach einer Kontosperrung weiter funktioniert
oder ob die Wiederherstellung unmöglich wird, weil der Zugriff auf die E-Mail blockiert ist, dürfte kaum jemand tatsächlich getestet haben.