Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Das ewige GCP-Problem: Unverwaltete Nutzer

By Zvi RogelNov 16, 20219 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Nehmen wir an, die E-Mail-Dienste Ihres Unternehmens laufen über einen On-Premise-Exchange-Server, Microsoft 365 oder einen GoDaddy-Mailservice.

Jemand in Ihrem Unternehmen – [email protected] – möchte Google-Dienste nutzen, für die ein Google-Konto erforderlich ist. Das kann die Anmeldung bei YouTube zum Erstellen eines Kanals sein, das Lesen eines geteilten Google-Dokuments, der Zugriff auf Google Analytics und dessen Verwaltung, das Schalten von Google-Ad-Kampagnen oder vielleicht sogar das Anlegen eines GCP-Projekts zu Testzwecken.

Diese Person legt ein neues persönliches, unverwaltetes oder Consumer-Google-Konto mit ihrer aktuellen E-Mail-Adresse an ([email protected]). Es folgt die Bestätigungs-E-Mail – und schon ist es geschehen. Diese Person verfügt nun über ein unverwaltetes Google-Konto bzw. eine unverwaltete Identität, die an ihre E-Mail-Adresse mit dem Domain-Suffix Ihres Unternehmens gekoppelt ist.

Diese Google-Identität ist für Ihre Organisation komplett unsichtbar! Als Admin haben Sie keinen Zugriff auf das Passwort und können das Konto auch nicht deaktivieren. Selbst die Aktivitätsprotokolle bleiben Ihnen verborgen. Setzen Sie das Passwort über Ihr eigenes System zurück (Office 365, Exchange, Hosting, HR-System usw.), bleibt das auf der Google-Seite ohne jede Wirkung.

Die größere Überraschung – und ein potenzielles Sicherheitsrisiko – ist: Selbst wenn Sie Ihren Unternehmens-Domainnamen bereits über ein Corporate- oder Managed-Google-Services-Abo (etwa Google Workspace oder CloudIdentity) registriert haben und keinen anderen E-Mail-Anbieter für diese Domain einsetzen, kann eine Mitarbeiterin oder ein Mitarbeiter trotzdem ein unverwaltetes Konto mit Ihrem Unternehmens-Domainnamen als Suffix anlegen.

Kurz gesagt: Sie haben keinerlei Möglichkeit, dieses Konto zu verwalten!

Bevor wir tiefer einsteigen, sollten Sie für die genannten Szenarien drei Grundprinzipien verinnerlicht haben:

  1. E-Mail-Adressen sind eindeutig. Punkt.
  2. In Cloud-Diensten ist die E-Mail-Adresse der Benutzername (die Identität), mit dem Sie auf Dienste zugreifen, sich anmelden und authentifizieren.
  3. Es gibt drei Arten von Google-Konten:

\* gmail.com-Konto,

\* persönliches\ individuelles\ Consumer-\ unverwaltetes Konto,

\* Managed-Konto.

Wie legen Sie die jeweiligen Konten an?

Legen Sie eine gmail.com-Adresse an und nutzen Sie damit die persönlichen Dienste für E-Mail, Drive, Kontakte und Kalender – inklusive der Identität zur Authentifizierung bei weiteren Diensten wie YouTube, Google Analytics und mehr.

Geben Sie Ihr persönliches, Consumer- oder unverwaltetes Konto mit einer bereits bestehenden E-Mail-Adresse an (etwa Yahoo.com, Outlook.com oder Ihrer Unternehmensdomain), um eine Bestätigungs-E-Mail zu erhalten. In diesem Fall erstellen Sie eine Google-Identität, kein vollwertiges End-to-End-Konto mit E-Mail- oder Kalenderzugriff. Drive-Zugriff erhalten Sie aber.

Sie gehen über denselben Link, klicken diesmal jedoch auf "Stattdessen meine aktuelle E-Mail-Adresse verwenden". Anschließend erscheint ein Bildschirm, auf dem Sie die E-Mail-Adresse eingeben und ein Passwort festlegen (es muss nicht das Passwort Ihres E-Mail-Kontos sein). Sie legen damit eine neue Identität bei Google an und müssen anschließend bestätigen, dass diese Adresse Ihnen gehört.

Diese Konten lassen sich von Google authentifizieren, wenn auf Dienste zugegriffen oder GCP-Projekte angelegt werden. So erhalten weitere persönliche, Consumer- oder unverwaltete Konten (mit dem Domain-Suffix Ihrer Firma) Zugriff auf GCP-Projekte oder Google Analytics. Für Letzteres müssen Sie Ihre Geschäfts- oder Unternehmensdomain über ein Corporate- oder Managed-Google-Services-Abo (etwa Google Workspace oder CloudIdentity) registrieren.

Eine Admin-Person, die dieses Abo verwaltet, kann ein Konto für Sie einrichten. Solche Konten heißen "Managed"-Konten bzw. -Identitäten.

Moment – da gibt es einen Haken

Spielen wir das erste Szenario noch einmal von vorn durch. Die E-Mails Ihres Unternehmens laufen über einen On-Premise-Exchange-Server, Microsoft 365 oder einen GoDaddy-Mailservice. Jetzt entsteht aber der Wunsch, alle Google-Konten zentral zu verwalten – für mehr Kontrolle und Transparenz.

Vielleicht möchten Sie auch unternehmensweite Google-Analytics- oder YouTube-Konten betreiben und SSO einsetzen, sodass beim Deaktivieren oder Löschen eines Nutzers in Ihrem System dieser auch bei Google entfernt wird. Also registrieren Sie Ihre Domain über ein Corporate- oder Managed-Google-Services-Abo – etwa Google Workspace (früher G-Suite) oder CloudIdentity.

Sie weisen nach, dass die Domain Ihnen gehört, und nehmen das Abo-Konto in Betrieb. Sie wollen [email protected] anlegen. Doch beim Erstellen meldet das System, dass diese Adresse bereits vergeben ist. Erinnern Sie sich an die erste Regel: Es kann nur eine E-Mail-Adresse geben.

Sie haben jetzt ein Problem mit duplizierten\ kollidierenden unverwalteten Konten!

Nehmen wir nun an, Sie sind Super-Admin Ihres Unternehmens für ein vollständig verwaltetes Google-Workspace-Konto. Angenommen, ein Admin richtet über die Google-Admin-Konsole für Ihr Google-Workspace-Abo eine Standard-Routing-Regel oder ein Recipient Address Map ein, mit dem alle E-Mails an [email protected] (private E-Mail-Adresse) weitergeleitet werden.

Nun ruft derselbe Admin den Registrierungs-Link für unverwaltete Konten auf und meldet die E-Mail-Adresse an. Eine Bestätigungs-E-Mail landet im Firmenpostfach, wo sie verifiziert werden muss.

Damit existiert ein unverwaltetes Google-Konto, das sich theoretisch bei Google Analytics anmelden, YouTube-Kanäle unter Ihrem Unternehmens-Domainnamen erstellen und sogar unautorisierten GCP-Zugriff erhalten kann. Erschwerend kommt hinzu: Als Admin wissen Sie nichts von diesem Nutzer, können das Passwort nicht zurücksetzen und so weiter.

Aktuell verhindert Google das Anlegen persönlicher oder Consumer-Konten unter einem registrierten Domain-Suffix nicht. Auch in der Admin-Konsole gibt es keine Funktion, um dies zu unterbinden. Wenn Sie sich an den Google-Support wenden und ausdrücklich darum bitten, diese Möglichkeit für Ihr Corporate-G-Suite- oder Google-Workspace-Konto zu sperren, wird er das nicht umsetzen – und auch nicht versuchen.

Erst eindämmen, dann lösen

Die Lösung

Wenn Sie ein Google-Workspace- (G-Suite-) Konto haben, können Sie über folgenden Link eine Catch-All-Adresse einrichten.

Eine Catch-All-Adresse sorgt dafür, dass Nachrichten an eine falsche E-Mail-Adresse trotzdem jemanden in der Organisation erreichen, der sie sichten und über das weitere Vorgehen entscheiden kann. So lassen sich Personen identifizieren, die versuchen, ein unverwaltetes Google-Konto zu aktivieren. Richtet jedoch ein Admin eine Routing-Regel ein – etwa über ein "Recipient Address Map" –, hilft eine Catch-All-Adresse nicht weiter.

Die beste Lösung, die als Workaround für jedes E-Mail-System taugt, besteht daher darin, schlicht die Kommunikation zwischen Verifizierungsprozess und Nutzer zu unterbrechen. Erstellen Sie eine Content Compliance Rule mit folgenden Bedingungen (alle müssen erfüllt sein – UND, nicht ODER):

Eingangsrichtung UND Body-Match-Regex `^[0–9]{6}$` UND Body enthält den Text "Verify this email is yours" UND Betreff enthält den Text "Verify your email address" UND Sender-Header enthält "[email protected]".

Solange Google diese Metadaten nicht verändert, sind Sie auf der sicheren Seite. Ich empfehle außerdem, die Verifizierungs-E-Mails nicht zu verwerfen. Leiten Sie sie stattdessen an einen Admin um – analog zur Catch-All-Adresse –, sodass Sie sie überwachen können, anstatt Nachrichten zu blockieren, die zwar den Kriterien entsprechen, aber nicht zu diesem Szenario passen.

Bei Bedarf können Sie zusätzlichen Schutz aufsetzen. In GCP lässt sich eine Sharing-Restriction-Policy nach Domain festlegen – hier erfahren Sie, wie das geht.

Damit können Nutzer außerhalb der Domain im IAM nicht mehr für Organisationsprojekte zugelassen werden. Beachten Sie: Diese Einstellung wirkt nicht rückwirkend, und Sie können auch keine gmail.com-Nutzer mehr zu Ihren Projekten hinzufügen. Nur Managed-Nutzer in Ihrem Google-Workspace- oder CloudIdentity-Konto erhalten künftig IAM-Berechtigungen.

Umgang mit unverwalteten Konten

Zunächst benötigen Sie die Rolle "Super Admin" in Ihrem Google-Workspace- oder CloudIdentity-Abo, um die folgenden Schritte auszuführen. Nach dem Login in der Admin-Konsole können Sie das "Übertragungstool für unverwaltete Nutzer" öffnen.

Oder im Bereich "Nutzer" über einen Klick auf "Mehr":

Im Übertragungstool sehen Sie unter Umständen eine Liste aller unverwalteten Nutzer mit duplizierten und kollidierenden Konten. Für jeden dieser Nutzer können Sie eine Einladung versenden, das unverwaltete Konto in Ihr Unternehmen zu übertragen. Nach dem Versand liegt es an der jeweiligen Person (sofern die Einladung tatsächlich ankommt), die Übertragung anzunehmen oder abzulehnen.

Bei Annahme wird der Benutzername Ihrem Unternehmenskonto zugeordnet und in der Nutzerliste angezeigt. Die Person kann sich weiterhin wie gewohnt authentifizieren – mit dem Unterschied, dass das Konto nun Ihren Unternehmensrichtlinien unterliegt (2FA, erlaubte oder gesperrte Dienste, Sitzungs-Timeout usw.). Bestehender Zugriff auf GCP-Projekte bleibt erhalten.

Bleibt eine Antwort aus oder wird die Anfrage abgelehnt, können Sie Vorkehrungen treffen (Routing-Regeln einrichten, die Nachrichten an diese Konten an ein Admin-Postfach umleiten), die Einladung erneut senden und sie im Namen der Person annehmen (Sie sind Inhaber der Domain, und die MX-Einträge zeigen auf Ihr Unternehmenskonto).

Ich empfehle, dabei mit Bedacht vorzugehen und zu versuchen, die Person ausfindig zu machen. Vielleicht handelt es sich um eine ehemalige Mitarbeiterin oder einen ehemaligen Mitarbeiter, die oder der schlicht vergessen hat, das Konto zu schließen, oder davon nichts wusste. Sie können den Nutzer aber auch direkt anlegen.

Beim Anlegen über die Admin-Konsole erscheint ein Bildschirm mit der Frage, ob Sie eine "Übertragungseinladung" senden oder den Nutzer trotzdem anlegen möchten. Letzteres erstellt eine neue Managed-Identität in Ihrem Unternehmens-Abo – und benennt den ursprünglichen Nutzer in etwas wie "username%[email protected]" um.

Möchte die Person mit ihrem Konto auf einen Google-Dienst zugreifen, hat sie die Wahl zwischen "Geschäftskonto" – dem von Ihnen erstellten Konto – und "Privates Konto", also "username%[email protected]".

Die Daten der Person bleiben im ursprünglichen Konto, ebenso alle damit verbundenen Daten wie Google Analytics oder YouTube-Kanäle – sie verbleiben unter dem privaten Konto. Über den neu angelegten Benutzernamen sind diese Daten nicht zugänglich.

Beachten Sie: Bei der Nutzung von GCDS (Google Cloud Directory Sync) aus On-Premise-MS-AD nach Google, beim Auto-Provisioning aus MS-AAD (Microsoft Azure Active Directory) oder bei Drittanbieter-Lösungen wie Okta kommt die API zum Einsatz. Diese API kennt persönliche, Consumer- und unverwaltete Konten nicht. Sie legt die Nutzer einfach automatisch an, und die persönliche, unverwaltete Identität wird umbenannt – ohne den Admin vorher zur Übertragung aufzufordern.

Google erlaubt es jedem, unverwaltete Nutzer mit dem E-Mail-Suffix Ihrer Unternehmensdomain anzulegen. Über diese Nutzer haben Sie keinerlei Kontrolle – sie können Zugriff auf Projekte der Google Cloud Platform (GCP) erhalten, YouTube-Kanäle erstellen, Google Analytics nutzen und vieles mehr. Diese Realität müssen Sie kennen und als potenzielles Problem ernst nehmen.

Die gute Nachricht: Sie als Admin können dem entgegenwirken, das Anlegen solcher Nutzer unterbinden und bereits bestehende Konten zurückholen.

Bleiben Sie mit uns in Kontakt – im DoiT Engineering Blog, auf dem DoiT LinkedIn-Kanal und dem DoiT Twitter-Kanal. Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com.