Alle Google-Dienste, einschließlich Google Cloud, Google Marketing Platform und Google Ads, nutzen Google Log-in zur Authentifizierung von Nutzern. In diesem Dokument wird das Domainmodell erläutert, das Google Log-in für die Authentifizierung und Identitätsverwaltung verwendet. Das Domainmodell zeigt Ihnen, wie Google Log-in im Unternehmenskontext funktioniert, wie Identitäten verwaltet werden und wie Sie die Integration mit einem externen Identitätsanbieter (Identity Provider, IdP) vereinfachen können. Das folgende Diagramm zeigt die Interaktion dieser Entitäten.
Wie dieses Diagramm zeigt, befindet sich im Zentrum des Modells die Google-Identität, die von Google Log-in verwendet wird. Die Google-Identität bezieht sich auf eine Reihe anderer Entitäten, die alle im Kontext der Identitätsverwaltung relevant sind:
- Google für Privatnutzer enthält die Entitäten, die für die nutzerorientierte Nutzung von Google-Diensten wie Gmail relevant sind.
- Google für Organisationen enthält Entitäten, die von Cloud Identity oder Google Workspace verwaltet werden. Diese Entitäten sind für die Verwaltung von Unternehmensidentitäten die wichtigsten.
- Google Cloud enthält die Entitäten, die für Google Cloud spezifisch sind.
- Extern enthält Entitäten, die relevant sind, wenn Sie Google mit einem externen IdP einbinden.
Durchgezogene Pfeile im Diagramm geben an, dass Entitäten aufeinander verweisen oder sich gegenseitig enthalten. Im Gegensatz dazu kennzeichnen gestrichelte Pfeile eine Verbundsbeziehung.
Google-Identitäten
Identitäten, Nutzer und Nutzerkonten spielen bei der Identitätsverwaltung eine entscheidende Rolle. Die drei Begriffe sind eng miteinander verbunden und werden manchmal sogar gleichbedeutend verwendet. Im Kontext der Identitätsverwaltung lohnt es sich jedoch, zwischen den Konzepten zu unterscheiden:
Eine Identität ist ein Name, der die Person, die mit einem Google-Dienst interagiert, eindeutig identifiziert. Google verwendet zu diesem Zweck E-Mail-Adressen. Die E-Mail-Adresse einer Person wird als Google-Identität dieser Person betrachtet.
Der Prozess zur Überprüfung der Verknüpfung zwischen einer Person und einer Identität wird als Authentifizierung oder Anmeldung bezeichnet. Die Person muss dann beweisen, dass dies tatsächlich ihre Identität ist.
Eine Person kann mehrere E-Mail-Adressen haben. Da Google-Dienste eine E-Mail-Adresse als Identität verwenden, wird davon ausgegangen, dass eine solche Person mehrere Identitäten hat.
Ein Nutzerkonto ist eine Datenstruktur, die Attribute, Aktivitäten und Konfigurationen protokolliert, die angewendet werden sollten, wenn eine bestimmte Identität mit einem Google-Dienst interagiert. Nutzerkonten werden nicht direkt erstellt, sondern müssen vor der ersten Anmeldung bereitgestellt werden.
Nutzerkonten werden durch eine ID identifiziert, die nicht extern verfügbar gemacht wird. Benutzeroberflächen oder APIs erfordern daher, dass Sie das Nutzerkonto indirekt über die zugehörige Identität referenzieren, z. B. über
alice@gmail.com. Trotz dieser Dereferenzierung sind alle Daten und Konfigurationsdetails mit dem Nutzerkonto verknüpft, nicht mit der Identität.
In den meisten Fällen besteht eine 1:1-Beziehung zwischen Nutzerkonten und Identitäten, die eine einfache Verknüpfung ermöglichen. Dies ist jedoch nicht immer der Fall, wie die folgenden Sonderfälle veranschaulichen:
Die Beziehung zwischen Nutzerkonten und Identitäten ist nicht festgelegt. Sie können die primäre E-Mail-Adresse eines Nutzerkontos ändern und so dem Nutzer eine andere Identität zuordnen.
Als Cloud Identity- oder Google Workspace-Administrator haben Sie auch die Möglichkeit, die primären E-Mail-Adressen von zwei Nutzern zu tauschen. Wenn Sie beispielsweise die primären E-Mail-Adressen von Alice (
alice@example.com) und Bob (bob@example.com) tauschen, verwendet Alice das vorherige Nutzerkonto von Bob und Bob das vorherige Nutzerkonto von Alice. Da Daten und Konfiguration dem Nutzerkonto und nicht der Identität zugeordnet sind, würde Alice jetzt auch Bobs vorhandene Konfiguration und Daten verwenden (und Bob die von Alice). Die folgende Abbildung zeigt diese Beziehung:
Bei einer nicht verbundenen Einrichtung müssen Sie außerdem Passwörter zurücksetzen, damit Alice und Bob Nutzerkonten tauschen können. In einer verbundenen Einrichtung, in der Alice und Bob einen externen IdP zur Authentifizierung verwenden, ist das Zurücksetzen von Passwörtern nicht erforderlich.
Die Beziehung zwischen Identität und Nutzern ist möglicherweise nicht identisch. Ein Privatnutzerkonto kann absichtlich mit mehreren Identitäten verknüpft werden, wie im folgenden Diagramm dargestellt.
Es ist auch möglich, dass sich eine Identität auf zwei verschiedene Nutzerkonten bezieht. Diese Situation sollte vermieden werden. Sie kann jedoch im Falle eines in Konflikt stehenden Nutzerkontos auftreten. In diesem Fall wird einem Nutzer während der Authentifizierung ein Auswahlbildschirm angezeigt, in dem er das zu verwendende Nutzerkonto auswählt.
Google unterscheidet zwischen zwei Arten von Nutzerkonten: Privatnutzerkonten und verwalteten Nutzerkonten. In den folgenden Abschnitten werden beide Arten von Nutzerkonten und die zugehörigen Entitäten ausführlicher behandelt.
Google für Privatnutzer
Wenn Sie eine Gmail-E-Mail-Adresse wie alice@gmail.com haben, ist Ihr Gmail-Konto ein Privatnutzerkonto. Wenn Sie den Link Konto erstellen auf der Google Log-in-Seite verwenden und während der Registrierung eine benutzerdefinierte E-Mail-Adresse angeben, z. B. alice@example.com, dann ist das daraus entstehende Konto auch ein Privatnutzerkonto.
Privatnutzerkonto
Privatnutzerkonten werden durch Self-Service erstellt und hauptsächlich für private Zwecke genutzt. Die Person, die das Privatnutzerkonto erstellt hat, hat die vollständige Kontrolle über das Konto und alle Daten, die mithilfe des Kontos erstellt werden. Die E-Mail-Adresse, die diese Person bei der Registrierung verwendet hat, wird zur primären E-Mail-Adresse des Privatnutzerkontos und dient als Identität. Diese Person kann dem Privatnutzerkonto E-Mail-Adressen hinzufügen. Diese E-Mail-Adressen dienen als zusätzliche Identitäten und können auch für die Anmeldung verwendet werden.
Wenn ein Privatnutzerkonto eine primäre E-Mail-Adresse verwendet, die der primären oder sekundären Domain eines Cloud Identity- oder Google Workspace-Kontos entspricht, wird das Privatnutzerkonto auch als nicht verwaltetes Nutzerkonto bezeichnet.
Ein Privatnutzerkonto kann bei einer beliebigen Anzahl von Gruppen Mitglied sein.
Google für Organisationen
Wenn Ihre Organisation Google-Dienste verwendet, sollten Sie verwaltete Nutzerkonten verwenden. Diese Konten werden als verwaltet bezeichnet, da ihr Lebenszyklus und ihre Konfiguration vollständig von der Organisation gesteuert werden können.
Verwaltete Nutzerkonten sind ein Feature von Cloud Identity und Google Workspace.
Cloud Identity- oder Google Workspace-Konto
Ein Cloud Identity- oder Google Workspace-Konto ist der Container der obersten Ebene für Nutzer, Gruppen, Konfiguration und Daten. Ein solches Konto wird erstellt, wenn sich ein Unternehmen für Cloud Identity oder Google Workspace anmeldet und dem Konzept eines Mandanten entspricht.
Cloud Identity und Google Workspace haben eine gemeinsame technische Grundlage. Beide Produkte verwenden die gleichen APIs und Verwaltungstools sowie ein Konto als Container für Nutzer und Gruppen. Dieser Container wird durch einen Domainnamen identifiziert. Zur Verwaltung von Nutzern, Gruppen und Authentifizierung können die beiden Produkte weitgehend als äquivalent betrachtet werden.
Ein Konto enthält Gruppen und eine oder mehrere Organisationseinheiten.
Organisationseinheit
Eine Organisationseinheit (OE) ist ein Untercontainer für Nutzerkonten, mit dem Sie die im Cloud Identity- oder Google Workspace-Konto definierten Nutzerkonten in voneinander getrennte Gruppen aufteilen können, um sie einfacher zu verwalten.
Organisationseinheiten sind hierarchisch organisiert. Jedes Cloud Identity- oder Google Workspace-Konto hat eine Stamm-OE, unter der Sie nach Bedarf weitere OEs erstellen können. Sie können Ihre OEs auch verschachteln.
Mit Cloud Identity und Google Workspace können Sie bestimmte Konfigurationen nach OEs anwenden, z. B. die Lizenzzuweisung oder die Bestätigung in zwei Schritten. Diese Einstellungen gelten automatisch für alle Nutzer in der OE und werden auch von untergeordneten OEs übernommen. Organisationseinheiten spielen daher eine wichtige Rolle bei der Verwaltung der Cloud Identity- und Google Workspace-Konfiguration.
Ein Nutzerkonto kann nicht mehreren OEs angehören. Dadurch unterscheiden sich diese von Gruppen. OEs sind zwar nützlich, um Konfigurationen auf Nutzerkonten anzuwenden, sie sind jedoch nicht für die Verwaltung des Zugriffs vorgesehen. Um den Zugriff zu verwalten, empfehlen wir die Verwendung von Gruppen.
Obwohl OEs Google Cloud-Ordnern ähneln, dienen die beiden Entitäten unterschiedlichen Zwecken und sind unabhängig voneinander.
Verwaltetes Nutzerkonto
Verwaltete Nutzerkonten funktionieren ähnlich wie private Nutzerkonten, können aber vollständig von den Administratoren des Cloud Identity- oder Google Workspace-Kontos verwaltet werden.
Die Identität eines verwalteten Nutzerkontos wird durch seine primäre E-Mail-Adresse definiert.
Die primäre E-Mail-Adresse muss eine Domain verwenden, die einer primären, sekundären oder Alias-Domain entspricht, die dem Cloud Identity- oder Google Workspace-Konto hinzugefügt wurde. Verwaltete Nutzerkonten können zusätzliche Alias-E-Mail-Adressen und eine E-Mail-Adresse zur Kontowiederherstellung haben. Diese Adressen gelten jedoch nicht als Identitäten und können auch nicht für die Anmeldung verwendet werden. Beispiel: Alice hat alice@example.com als ihre primäre E-Mail-Adresse verwendet und ally@example.com als eine Alias-E-Mail-Adresse sowie alice@gmail.com als eine E-Mail-Adresse zur Kontowiederherstellung konfiguriert. In diesem Fall kann sie sich nur mit der E-Mail-Adresse alice@example.com anmelden.
Verwaltete Nutzerkonten sind in einer Organisationseinheit enthalten und können in einer beliebigen Anzahl von Gruppen Mitglied sein.
Verwaltete Nutzerkonten sind für die Verwendung durch menschliche Nutzer und nicht durch Computernutzer gedacht. Ein Computernutzerkonto ist eine spezielle Art von Konto, das von einer Anwendung oder einer VM-Instanz verwendet wird, nicht von einer Person. Für Computernutzer bietet Google Cloud Dienstkonten. Dienstkonten werden weiter unten in diesem Dokument noch ausführlicher erläutert.
Group
Mit Google Groups können Sie mehrere Nutzer gruppieren. Sie können mit Gruppen eine Mailingliste verwalten oder eine Zugriffssteuerung oder Konfiguration auf mehrere Nutzer anwenden.
Cloud Identity und Google Workspace identifizieren Gruppen anhand ihrer E-Mail-Adresse, z. B. billing-admins@example.com. Ähnlich wie die primäre E-Mail-Adresse eines Nutzers muss die Gruppen-E-Mail-Adresse eine primäre, sekundäre oder Alias-Domain des Cloud Identity- oder Google Workspace-Kontos verwenden. Die E-Mail-Adresse muss keinem Postfach entsprechen, es sei denn, die Gruppe wird als Mailingliste verwendet. Die Authentifizierung erfolgt weiterhin über die E-Mail-Adresse des Nutzers und nicht über die Gruppen-E-Mail-Adresse, sodass sich ein Nutzer nicht mit einer Gruppen-E-Mail-Adresse anmelden kann.
Eine Gruppe kann die folgenden Entitäten als Mitglieder haben:
- Nutzer (verwaltete Nutzer- oder Privatnutzerkonten)
- Andere Gruppen
- Dienstkonten
Im Gegensatz zu einer Organisationseinheit werden Gruppen nicht als Container verwendet:
- Ein Nutzer oder eine Gruppe kann Mitglied einer beliebigen Anzahl von Gruppen sein.
- Durch das Löschen einer Gruppe werden weder die Nutzer noch die Gruppen gelöscht.
Gruppen können Mitglieder aus einem beliebigen Cloud Identity- oder Google Workspace-Konto sowie aus Privatnutzerkonten enthalten. Die Einstellung Mitglieder außerhalb Ihrer Organisation nicht zulassen bietet die Möglichkeit, Mitglieder auf Nutzerkonten eines einzigen Cloud Identity- oder Google Workspace-Kontos zu beschränken.
Externe Identitäten
Wenn Sie ein Cloud Identity- oder Google Workspace-Konto mit einem externen IdP verbinden, können Sie Ihren Mitarbeitern die Möglichkeit einräumen, sich mit ihrer vorhandenen Identität und ihren Anmeldedaten bei Google-Diensten anzumelden.
Grundsätzlich ermöglicht eine solche Föderation das Einrichten der Einmalanmeldung (SSO) mithilfe von SAML. Damit werden Identitäten in Cloud Identity oder Google Workspace mit Identitäten verknüpft, die von Ihrem externen IdP verwaltet werden. Für das Verknüpfen einer Identität wie z. B. alice@example.com und das Aktivieren der Einmalanmeldung (SSO) bei Google müssen zwei Voraussetzungen erfüllt sein:
- Ihr externer IdP muss die Identität
alice@example.comerkennen und dafür die Einmalanmeldung (SSO) zulassen. - Ihr Cloud Identity- oder Google Workspace-Konto muss ein Nutzerkonto enthalten, das
alice@example.comals Identität verwendet. Dieses Nutzerkonto ist Voraussetzung für die Einmalanmeldung (SSO).
Anstatt Nutzerkonten in Cloud Identity oder Google Workspace manuell zu erstellen und zu verwalten, können Sie den Vorgang automatisieren. Dazu kombinieren Sie die SAML-basierte Einmalanmeldung (SSO) mit der automatischen Nutzerverwaltung. Über die automatische Nutzerverwaltung werden alle oder ein Teil der Nutzer und Gruppen aus einer externen autoritativen Quelle mit Cloud Identity oder Google Workspace synchronisiert.
Je nach IdP können die SAML-basierte Einmalanmeldung (SSO) und die automatische Nutzerverwaltung von einer einzigen Softwarekomponente oder von separaten Komponenten verarbeitet werden. Das Domainmodell unterscheidet daher zwischen einem SAML-Identitätsanbieter und einer externen autoritativen Quelle.
Externer SAML-Identitätsanbieter
Der externe IdP ist das einzige System für die Authentifizierung und bietet Ihren Mitarbeitern eine Einmalanmeldung, die Anwendungen umfasst. Er liegt außerhalb von Google und wird daher als externer Identitätsanbieter bezeichnet.
Wenn Sie die Einmalanmeldung (SSO) aktivieren, leitet Cloud Identity oder Google Workspace Authentifizierungsanfragen an den SAML-IdP weiter. Bei Verwendung von SAML ist Cloud Identity oder Google Workspace ein Dienstanbieter, der dem SAML-IdP für die Bestätigung der Identität eines Nutzers in seinem Namen vertraut.
Jedes Cloud Identity- oder Google Workspace-Konto kann sich nur auf einen externen IdP beziehen. Mehrere Cloud Identity- oder Google Workspace-Konten können sich dagegen auf verschiedene SAML-IdPs beziehen. Es ist aber nicht möglich, mehrere SAML-IdPs für ein einzelnes Cloud Identity- oder Google Workspace-Konto zu verwenden.
Häufig verwendete externe IdPs sind Active Directory Federation Services (AD FS), Azure AD, Okta und Ping Identity.
Externe autoritative Quelle
Die autoritative Quelle für Identitäten ist das einzige System, mit dem Sie Identitäten für Ihre Mitarbeiter erstellen, verwalten und löschen können. Sie befindet sich außerhalb von Google und wird daher als externe autoritative Quelle bezeichnet.
Nutzerkonten und Gruppen lassen sich von der externen autoritativen Quelle automatisch für Cloud Identity oder Google Workspace bereitstellen. Die Bereitstellung kann von der autoritativen Quelle selbst oder über Middleware erfolgen.
Für eine effektive automatische Nutzerverwaltung müssen Nutzer eine Identität haben, die Ihr SAML-IdP erkennt. Wenn Sie eine Zuordnung zwischen Identitäten vornehmen, z. B. wenn Sie die Identität alice@example.com in Cloud Identity oder Google Workspace mit u12345@corp.example.com in Ihrem SAML-IdP verknüpfen, müssen sowohl der SAML-IdP als auch die Bereitstellungs-Middleware die gleiche Zuordnung ausführen.
Externes Nutzerkonto
Externe Identitätsanbieter orientieren sich in der Regel am Konzept eines Nutzerkontos, das den Namen, Attribute und die Konfiguration enthält.
Die autoritative Quelle oder die Bereitstellungs-Middleware soll dabei alle oder einen Teil der externen Nutzerkonten für Cloud Identity oder Google Workspace bereitstellen, um die Anmeldung zu vereinfachen. In vielen Fällen reicht es aus, nur einen Teil der Nutzerattribute (z. B. E-Mail-Adresse, Vorname und Nachname) an Cloud Identity oder Google Workspace weiterzugeben. Damit kann die Datenredundanz minimiert werden.
Externe Gruppe
Wenn Ihr externer IdP das Konzept einer Gruppe unterstützt, können Sie dessen Gruppen bei Bedarf Gruppen in Cloud Identity oder Google Workspace zuordnen.
Das Zuordnen und automatische Bereitstellen von Gruppen ist optional und für die Einmalanmeldung (SSO) nicht erforderlich. Beide Schritte können jedoch hilfreich sein, wenn Sie vorhandene Gruppen wiederverwenden möchten, um den Zugriff in Google Workspace oder Google Cloud zu steuern.
Google Cloud
Wie andere Google-Dienste nutzt Google Cloud für das Authentifizieren von Nutzern Google Log-in. Google Cloud ist außerdem eng in Google Workspace und Cloud Identity eingebunden, sodass Sie Ressourcen effizient verwalten können.
Google Cloud orientiert sich am Konzept von Organisationsknoten, Ordnern und Projekten. Diese Entitäten werden hauptsächlich dazu verwendet, um den Zugriff und die Konfiguration zu verwalten, und sind daher nur im Kontext der Identitätsverwaltung relevant. Google Cloud umfasst jedoch auch einen zusätzlichen Nutzerkontentyp: Dienstkonten. Dienstkonten gehören zu Projekten und spielen bei der Identitätsverwaltung eine entscheidende Rolle.
Organisationsknoten
Eine Organisation ist der Stammknoten in der Google Cloud-Ressourcenhierarchie und ein Container für Projekte und Ordner. Mit Organisationen können Sie Ressourcen hierarchisch strukturieren. Sie sind der Schlüssel für die zentrale und effiziente Verwaltung von Ressourcen.
Jede Organisation gehört zu einem einzelnen Cloud Identity- oder Google Workspace-Konto. Der Name der Organisation wird vom primären Domainnamen des entsprechenden Cloud Identity- oder Google Workspace-Kontos abgeleitet.
Ordner
Ordner sind Knoten in der Google Cloud-Ressourcenhierarchie und können Projekte, andere Ordner oder eine Kombination aus beiden enthalten. Mithilfe von Ordnern gruppieren Sie Ressourcen, die gemeinsame IAM-Richtlinien (Identity and Access Management) oder Organisationsrichtlinien haben. Diese Richtlinien gelten automatisch für alle Projekte im Ordner und werden auch von untergeordneten Ordnern übernommen.
Ordner ähneln Organisationseinheiten, sind aber nicht miteinander verknüpft. Mit Organisationseinheiten können Sie Nutzer verwalten und allgemeine Konfigurationen oder Richtlinien auf Nutzer anwenden. Mit Ordnern können Sie Google Cloud-Projekte verwalten und allgemeine Konfigurationen oder Richtlinien auf Projekte anwenden.
Projekt
Ein Projekt ist ein Container für Ressourcen. Projekte spielen eine entscheidende Rolle bei der Verwaltung von APIs, der Abrechnung und der Zugriffsverwaltung auf Ressourcen.
Im Kontext der Identitätsverwaltung sind Projekte relevant, da sie die Container für Dienstkonten sind.
Dienstkonto
Ein Dienstkonto (oder Google Cloud-Dienstkonto) ist eine spezielle Art von Nutzerkonto, das von Anwendungen und anderen Arten von Computernutzern verwendet werden soll.
Jedes Dienstkonto gehört zu einem Google Cloud-Projekt. Wie bei verwalteten Nutzerkonten können Administratoren den Lebenszyklus und die Konfiguration eines Dienstkontos vollständig steuern.
Dienstkonten verwenden auch eine E-Mail-Adresse als Identität, aber im Gegensatz zu verwalteten Nutzerkonten verwendet die E-Mail-Adresse immer eine Google-Domain wie beispielsweise developer.gserviceaccount.com.
Dienstkonten nehmen nicht an einem Verbund teil und haben auch kein Passwort. In Google Cloud verwenden Sie IAM zum Steuern der Berechtigung, die ein Dienstkonto für eine Compute-Ressource wie eine virtuelle Maschine (VM) oder Cloud Functions-Funktion hat, sodass Sie Anmeldedaten nicht verwalten müssen. Außerhalb von Google Cloud können Sie mit Dienstkontoschlüsseln eine Anwendung über ein Dienstkonto authentifizieren.
Kubernetes-Dienstkonto
Kubernetes-Dienstkonten sind ein Konzept von Kubernetes und relevant, wenn Sie Google Kubernetes Engine (GKE) verwenden. Ähnlich wie bei Google Cloud-Dienstkonten sind Kubernetes-Dienstkonten für Anwendungen und nicht für Personen vorgesehen.
Kubernetes-Dienstkonten können zur Authentifizierung verwendet werden, wenn eine Anwendung die Kubernetes API eines Kubernetes-Clusters aufruft. Sie können jedoch nicht außerhalb des Clusters verwendet werden. Sie werden von keiner der Google APIs erkannt und sind daher kein Ersatz für ein Google Cloud-Dienstkonto.
Wenn Sie eine Anwendung als Kubernetes-Pod bereitstellen, können Sie den Pod mit einem Dienstkonto verknüpfen. Durch diese Zuordnung kann die Anwendung die Kubernetes API verwenden, ohne Zertifikate oder andere Anmeldedaten konfigurieren oder verwalten zu müssen.
Mit Workload Identity können Sie ein Kubernetes-Dienstkonto mit einem Google Cloud-Dienstkonto verknüpfen. Über diesen Link kann sich eine Anwendung auch bei Google APIs authentifizieren, ohne dass Zertifikate oder andere Anmeldedaten verwaltet werden müssen.
Nächste Schritte
- Sehen Sie sich unsere Referenzarchitekturen für die Identitätsverwaltung an.