Referenzarchitekturen

Last reviewed 2024-07-11 UTC

In diesem Dokument werden typische Architekturen vorgestellt, die Sie als Referenz für die Verwaltung von Unternehmensidentitäten verwenden können. Zwei Kernprinzipien der Verwaltung der Unternehmensidentität sind:

  • Eine autoritative Quelle für Identitäten, die das einzige System ist, mit dem Sie Identitäten für Ihre Mitarbeiter erstellen, verwalten und löschen. Die im autoritativen Quellsystem verwalteten Identitäten werden möglicherweise an andere Systeme weitergegeben.

  • Ein zentraler Identitätsanbieter (Identity Provider, IdP), der das einzige System für die Authentifizierung ist und Ihren Mitarbeitern eine Einmalanmeldung (SSO) bietet, die Anwendungen umfasst.

Wenn Sie Google Cloud oder andere Google-Dienste verwenden, müssen Sie entscheiden, welches System als Identitätsanbieter und welches System als autoritative Quelle verwendet werden soll.

Google als IdP verwenden

Mit der Cloud Identity Premiumversion oder mit Google Workspace können Sie Google als primären IdP festlegen. Google bietet eine große Auswahl an einsatzbereiten Integrationen für gängige Anwendungen von Drittanbietern. Sie können mit Standardprotokollen wie SAML, OAuth und OpenID Connect auch Ihre benutzerdefinierten Anwendungen einbinden.

Google als IdP und autoritative Quelle

Sie können die Cloud Identity Premiumversion oder Google Workspace wie im folgenden Diagramm dargestellt sowohl als IdP als auch als autoritative Quelle verwenden.

Google als IdP und autoritative Quelle

  • Sie verwalten Nutzer und Gruppen mit der Cloud Identity Premiumversion oder mit Google Workspace.
  • Alle Google-Dienste nutzen die Cloud Identity Premiumversion oder Google Workspace als IdP.
  • Sie konfigurieren Unternehmensanwendungen und andere SaaS-Dienste für die Verwendung von Google als IdP.

In der Praxis

In dieser Konfiguration sieht die Anmeldung für einen Mitarbeiter so aus:

  1. Wenn ein Mitarbeiter eine geschützte Ressource oder den Zugriff auf eine Unternehmensanwendung anfordert, wird er zu Google Log-in weitergeleitet, wo er zur Eingabe seiner E-Mail-Adresse und seines Passworts aufgefordert wird.
  2. Wenn die Bestätigung in zwei Schritten aktiviert ist, wird der Mitarbeiter aufgefordert, einen zweiten Faktor wie einen USB-Schlüssel oder Code anzugeben.
  3. Wenn der Mitarbeiter authentifiziert wird, wird er zur geschützten Ressource zurückgeleitet.

Vorteile

Die Verwendung von Google als IdP und autoritative Quelle hat folgende Vorteile:

Einsatzmöglichkeiten für diese Architektur

In folgenden Fällen ist die Verwendung von Google als IdP und autoritative Quelle zu empfehlen:

  • Sie nutzen Google Workspace bereits als Lösung zur Förderung von Zusammenarbeit und Produktivität.
  • Es gibt keine lokale Infrastruktur und keinen IdP, die bzw. den Sie einbinden müssen oder die bzw. den Sie von Ihren Ressourcen bei Google (in Google Cloud, in Google Ads usw.) getrennt halten möchten.
  • Für die Verwaltung von Identitäten ist keine Einbindung in ein Human Resources Information System (HRIS) erforderlich.

Google als IdP mit einem HRIS als autoritative Quelle

Auch wenn Sie ein HRIS verwenden, um den Onboarding- und Offboardingvorgang für Ihre Mitarbeiter zu verwalten, können Sie Google als IdP verwenden. Cloud Identity und Google Workspace bieten APIs, mit denen HRIS und andere Systeme die Verwaltung von Nutzern und Gruppen steuern können, wie im folgenden Diagramm dargestellt.

Google als IdP mit einem HRIS als autoritative Quelle

  • Sie verwenden Ihr vorhandenes HRIS, um Nutzer und optional Gruppen zu verwalten. Das HRIS bleibt die zentrale Datenquelle („Single Source Of Truth“) für die Identitätsverwaltung und stellt Nutzer automatisch für Cloud Identity oder Google Workspace bereit.
  • Alle Google-Dienste nutzen die Cloud Identity Premiumversion oder Google Workspace als IdP.
  • Sie konfigurieren Unternehmensanwendungen und andere SaaS-Dienste für die Verwendung von Google als IdP.

In der Praxis

Für einen Mitarbeiter entspricht die Anmeldung der Verwendung von Google als IdP und autoritative Quelle.

Vorteile

Die Verwendung von Google als IdP und autoritative Quelle hat folgende Vorteile:

  • Sie können den Verwaltungsaufwand minimieren, indem Sie Ihre vorhandenen HRIS-Workflows wiederverwenden.
  • Sie können die Multi-Faktor-Authentifizierung und die Mobilgeräteverwaltung von Google in vollem Umfang nutzen.
  • Sie benötigen keinen zusätzlichen IdP, wodurch Sie Geld sparen können.

Einsatzmöglichkeiten für diese Architektur

Ziehen Sie in den folgenden Szenarien in Betracht, Google als IdP mit einem HRIS als autoritative Quelle zu verwenden:

  • Sie verwenden ein HRIS oder ein anderes System als autoritative Quelle für Identitäten.
  • Sie nutzen Google Workspace bereits als Lösung zur Förderung von Zusammenarbeit und Produktivität.
  • Es gibt keine lokale Infrastruktur und keinen IdP, die bzw. den Sie einbinden müssen oder die bzw. den Sie von Ihrem Google-Konto getrennt halten möchten.

Externen IdP verwenden

Wenn Ihre Organisation bereits einen IdP wie Active Directory, Microsoft Entra ID (früher Azure AD), ForgeRock, Okta oder Ping Identity verwendet, können Sie Google Cloud über einen Verbund in diesen externen IdP einbinden.

Wenn Sie ein Cloud Identity- oder Google Workspace-Konto mit einem externen IdP verbinden, können sich Ihre Mitarbeiter mit ihrer vorhandenen Identität und mit ihren Anmeldedaten in Google-Diensten wie Google Cloud, Google Marketing Platform und Google Ads anmelden.

Externe IDaaS als IdP und autoritative Quelle

Wenn Sie einen IDaaS-Anbieter (Identity as a Service) wie ForgeRock, Okta oder Ping Identity verwenden, können Sie den Verbund wie im folgenden Diagramm einrichten.

Externe IDaaS als IdP und autoritative Quelle

  • Cloud Identity oder Google Workspace verwenden Ihren IDaaS-Dienst als IdP für die Einmalanmeldung (SSO).
  • IDaaS stellt automatisch Nutzer und Gruppen für Cloud Identity oder Google Workspace bereit.
  • Vorhandene Unternehmensanwendungen und andere SaaS-Dienste können weiterhin Ihren IDaaS-Dienst als IdP nutzen.

Weitere Informationen zur Föderation von Cloud Identity oder Google Workspace mit Okta finden Sie unter Okta-Nutzerverwaltung und Einmalanmeldung (SSO).

Auswirkungen für Nutzer

Für einen Mitarbeiter sieht die Anmeldung so aus:

  1. Wenn ein Mitarbeiter eine geschützte Ressource anfordert, wird er zu Google Log-in weitergeleitet, wo er seine E-Mail-Adresse und sein Passwort eingeben muss.
  2. Google Log-in leitet ihn auf die Anmeldeseite Ihres IDaaS weiter.
  3. Er authentifiziert sich bei Ihrem IDaaS. Je nach IDaaS muss er möglicherweise einen zweiten Faktor wie einen Code angeben.
  4. Nach der Authentifizierung wird er zur geschützten Ressource zurückgeleitet.

Vorteile

Die Verwendung einer externen IDaaS als IdP und autoritativer Quelle hat folgende Vorteile:

  • Sie aktivieren eine Einmalanmeldung für Ihre Mitarbeiter, die sich auf Google-Dienste und andere Anwendungen, die in Ihre IDaaS eingebunden sind, erstreckt.
  • Wenn Sie Ihren IDaaS so konfiguriert haben, dass eine Multi-Faktor-Authentifizierung erforderlich ist, gilt diese Konfiguration automatisch für Google Cloud.
  • Sie müssen Passwörter oder andere Anmeldedaten nicht mit Google synchronisieren.
  • Sie können die kostenlose Version von Cloud Identity verwenden.

Einsatzmöglichkeiten für diese Architektur

Erwägen Sie in den folgenden Szenarien die Verwendung eines externen IDaaS als IdP und autoritative Quelle:

  • Sie verwenden bereits einen IDaaS-Anbieter wie ForgeRock, Okta oder Ping Identity als IdP.

Best Practices

Sehen Sie sich unsere Best Practices für die Föderation von Google Cloud mit einem externen Identitätsanbieter an.

Active Directory als IdP und autoritative Quelle

Wenn Sie Active Directory als Quelle für die Identitätsverwaltung verwenden, können Sie den Verbund wie im folgenden Diagramm einrichten.

Active Directory als IdP und autoritative Quelle

  • Mit Google Cloud Directory Sync (GCDS) können Sie Nutzer und Gruppen aus Active Directory automatisch für Cloud Identity oder Google Workspace bereitstellen. Google Cloud Directory Sync ist ein von Google bereitgestelltes kostenloses Tool, das den Synchronisierungsvorgang implementiert und entweder in Google Cloud oder in Ihrer lokalen Umgebung ausgeführt wird. Die Synchronisierung erfolgt in eine Richtung, sodass Active Directory die zentrale Datenquelle bleibt.
  • Cloud Identity oder Google Workspace verwendet Active Directory-Verbunddienste (Active Directory Federation Services, AD FS) für die Einmalanmeldung (SSO).
  • Vorhandene Unternehmensanwendungen und andere SaaS-Dienste können Ihre AD FS weiterhin als IdP nutzen.

In einer Variante dieses Musters können Sie auch Active Directory Lightweight Directory Services (AD LDS) oder ein anderes LDAP-Verzeichnis mit AD FS oder einem anderen SAML-kompatiblen IdP verwenden.

Weitere Informationen zu diesem Ansatz finden Sie unter Google Cloud mit Active Directory verbinden.

Nutzer

  1. Wenn der Mitarbeiter die geschützte Ressource anfordert, wird er zu Google Log-in weitergeleitet, wo er seine E-Mail-Adresse eingeben muss.
  2. Google Log-in leitet den Mitarbeiter auf die Anmeldeseite von AD FS weiter.
  3. Je nach Konfiguration von AD FS wird dem Mitarbeiter möglicherweise ein Anmeldebildschirm angezeigt, in dem er aufgefordert wird, seinen Active Directory-Nutzernamen und sein Passwort einzugeben. Alternativ kann AD FS versuchen, den Mitarbeiter anhand seiner Windows-Anmeldung automatisch anzumelden.
  4. Nachdem AD FS den Mitarbeiter authentifiziert hat, wird er zur geschützten Ressource zurückgeleitet.

Vorteile

Die Verwendung von Active Directory als IdP und autoritative Quelle hat folgende Vorteile:

  • Sie aktivieren eine Einmalanmeldung (SSO) für Ihre Mitarbeiter, die sich über Google-Dienste und Ihre lokale Umgebung erstreckt.
  • Wenn Sie AD FS so konfiguriert haben, dass eine Multi-Faktor-Authentifizierung erforderlich ist, gilt diese Konfiguration automatisch für Google Cloud.
  • Sie müssen Passwörter oder andere Anmeldedaten nicht mit Google synchronisieren.
  • Sie können die kostenlose Version von Cloud Identity verwenden.
  • Da die von GCDS verwendeten APIs öffentlich zugänglich sind, müssen Sie keine Hybridkonnektivität zwischen Ihrem lokalen Netzwerk und Google Cloudeinrichten.

Einsatzmöglichkeiten für diese Architektur

Ziehen Sie in den folgenden Szenarien Active Directory als IdP und autoritative Quelle in Betracht:

  • Sie haben eine Active Directory-Infrastruktur.
  • Sie möchten eine nahtlose Anmeldung für Windows-Nutzer ermöglichen.

Best Practices

Beachten Sie die folgenden Best Practices:

  • Active Directory und Cloud Identity verwenden unterschiedliche logische Strukturen. Machen Sie sich mit den Unterschieden vertraut und entscheiden Sie, welche Methode zur Zuordnung von Domains, Identitäten und Gruppen für Ihre Situation am besten geeignet ist. Weitere Informationen finden Sie in unserem Leitfaden zum Verbinden von Google Cloud mit Active Directory.
  • Synchronisieren Sie nicht nur Nutzer, sondern auch Gruppen. Bei diesem Ansatz können Sie IAM so einrichten, dass sich der Zugriff auf Ressourcen inGoogle Cloudmithilfe von Gruppenmitgliedschaften in Active Directory steuern lässt.
  • Stellen Sie AD FS so bereit, dass Unternehmensnutzer darauf zugreifen können, aber nur im erforderlichen Umfang. Unternehmensnutzer müssen auf AD FS zugreifen können. Es ist aber nicht nötig, dass AD FS über Cloud Identity oder Google Workspace oder jede in Google Cloudbereitgestellte Anwendung aufgerufen werden kann.
  • Prüfen Sie die Nutzung der integrierten Windows-Authentifizierung (IWA) in AD FS, damit Nutzer sich anhand ihrer Windows-Anmeldung automatisch anmelden können.
  • Wenn AD FS nicht verfügbar ist, können Nutzer dieGoogle Cloud Console oder andere Ressourcen, für die Google als IdP fungiert, unter Umständen nicht verwenden. Sorgen Sie deshalb dafür, dass AD FS und die Domaincontroller, die von AD FS benötigt werden, gemäß Ihren Verfügbarkeitszielen bereitgestellt und dimensioniert werden.
  • Wenn Sie Google Cloud aus Gründen der Geschäftskontinuität nutzen, besteht die Möglichkeit, dass mit der Verwendung von lokalem AD FSGoogle Cloud unter Umständen nicht mehr als eigenständige Kopie Ihrer Bereitstellung genutzt wird. In diesem Fall können Sie Replikate aller relevanten Systeme in Google Cloudauf eine der folgenden Arten bereitstellen:

    • Erweitern Sie Ihre vorhandene Active Directory-Domain auf Google Cloud und stellen Sie GCDS für die Ausführung inGoogle Cloudbereit.
    • Führen Sie dedizierte AD FS-Server in Google Cloudaus. Diese Server verwenden die Active Directory-Domaincontroller, die aufGoogle Cloudausgeführt werden.
    • Konfigurieren Sie Cloud Identity so, dass die auf Google Cloud bereitgestellten AD FS-Server für die Einmalanmeldung verwendet werden.

Weitere Informationen finden Sie unter Best Practices für die Verbindung von Google Cloud mit einem externen Identitätsanbieter.

Entra ID als IdP mit Active Directory als autoritative Quelle

Wenn Sie Microsoft 365- oder Azure-Kunde sind, haben Sie Ihr lokales Active Directory möglicherweise mit Entra ID verbunden. Wenn alle Nutzerkonten, die möglicherweise Zugriff auf Google Cloud benötigen, bereits mit Entra ID synchronisiert werden, können Sie diese Integration wiederverwenden, indem Sie Cloud Identity mit Entra ID verbinden, wie im folgenden Diagramm dargestellt.

Entra ID als IdP mit Active Directory als autoritative Quelle

  • Sie verwenden Entra ID, um Nutzer und Gruppen automatisch in Cloud Identity oder Google Workspace bereitzustellen. Entra ID selbst kann in ein lokales Active Directory eingebunden sein.
  • Cloud Identity oder Google Workspace verwenden Entra ID für die Einmalanmeldung (SSO).
  • Vorhandene Unternehmensanwendungen und andere SaaS-Dienste können Entra ID weiterhin als IdP nutzen.

Weitere Informationen zu diesem Ansatz finden Sie unter Google Cloud mit Microsoft Entra ID verbinden.

Nutzer

  1. Wenn der Mitarbeiter die geschützte Ressource anfordert, wird er zu Google Log-in weitergeleitet, wo er seine E-Mail-Adresse eingeben muss.
  2. Google Log-in leitet ihn auf die Anmeldeseite von AD FS weiter.
  3. Je nachdem, wie ihr lokales Active Directory mit Entra ID verbunden ist, werden sie von Entra ID möglicherweise zur Eingabe eines Nutzernamens und Passworts aufgefordert oder an ein lokales AD FS weitergeleitet.
  4. Nachdem der Mitarbeiter mit Entra ID authentifiziert wurde, wird er zur geschützten Ressource zurückgeleitet.

Vorteile

Die Verwendung von Entra ID als IdP mit Active Directory als autoritative Quelle hat mehrere Vorteile:

  • Sie ermöglichen Ihren Mitarbeitern die Einmalanmeldung (SSO) für Google-Dienste, Entra und Ihre lokale Umgebung.
  • Wenn Sie Entra ID so konfiguriert haben, dass die Multi-Faktor-Authentifizierung erforderlich ist, gilt diese Konfiguration automatisch für Google Cloud.
  • Sie müssen keine zusätzliche Software in Ihrer lokalen Umgebung installieren.
  • Wenn Ihr lokales Active Directory mehrere Domains oder Gesamtstrukturen verwendet und Sie eine benutzerdefinierte Entra ID Connect-Konfiguration eingerichtet haben, um diese Struktur einem Entra ID-Mandanten zuzuordnen, können Sie diese Integrationsarbeit nutzen.
  • Sie müssen Passwörter oder andere Anmeldedaten nicht mit Google synchronisieren.
  • Sie können die kostenlose Version von Cloud Identity verwenden.
  • Sie können die Google Cloud Console als Kachel im Office 365-Portal anzeigen lassen.
  • Da die von Entra ID verwendeten APIs öffentlich zugänglich sind, müssen Sie keine Hybridkonnektivität zwischen Entra und Google Cloudeinrichten.

Einsatzmöglichkeiten für diese Architektur

In den folgenden Szenarien sollten Sie Entra ID als IdP mit Active Directory als autoritative Quelle verwenden:

  • Sie verwenden bereits Entra ID und haben es in eine vorhandene Active Directory-Infrastruktur eingebunden.
  • Sie möchten Nutzern eine nahtlose Anmeldung in Entra und Google Cloudermöglichen.

Best Practices

Wir empfehlen folgende Best Practices:

  • Da Entra ID und Cloud Identity eine andere logische Struktur verwenden, sollten Sie sich mit den Unterschieden vertraut machen. Entscheiden Sie dann, welche Methode sich für das Zuordnen von Domains, Identitäten und Gruppen am besten für Ihre Situation eignet. Weitere Informationen finden Sie unter Google Cloud mit Microsoft Entra ID verbinden.
  • Synchronisieren Sie nicht nur Nutzer, sondern auch Gruppen. Bei diesem Ansatz können Sie IAM so einrichten, dass sich der Zugriff auf Ressourcen inGoogle Cloudmithilfe von Gruppenmitgliedschaften in Entra ID steuern lässt.
  • Wenn Sie Google Cloud aus Gründen der Geschäftskontinuität nutzen, besteht die Möglichkeit, dass mit der Verwendung von Entra ID zur AuthentifizierungGoogle Cloud unter Umständen nicht mehr als eigenständige Kopie Ihrer Bereitstellung genutzt wird.

Weitere Informationen finden Sie unter Best Practices für die Verbindung von Google Cloud mit einem externen Identitätsanbieter.

Nächste Schritte