Muster zum Authentifizieren von Belegschaftsnutzern in einer Hybridumgebung

Dieses Dokument ist der zweite Teil einer mehrteiligen Reihe, in der beschrieben wird, wie Sie Ihre Identitätsverwaltungslösung in Google Cloud erweitern, damit Ihre Mitarbeiter Dienste in einer Hybrid-Computing-Umgebung authentifizieren und nutzen können.

Die Reihe besteht aus folgenden Dokumenten:

• Belegschaftsnutzern in einer Hybridumgebung authentifizieren
• Muster zum Authentifizieren von Belegschaftsnutzern in einer Hybridumgebung (dieses Dokument)

Einleitung

Wenn Sie Ihre IT-Landschaft im Rahmen einer Hybridstrategie in Google Cloud erweitern, empfehlen wir einen einheitlichen Ansatz für die Verwaltung von Identitäten für alle Umgebungen. Bei der Entwicklung und Anpassung Ihrer Architektur an diese Einschränkungen und Anforderungen können Sie auf verschiedene gängige Muster zurückgreifen. Diese Muster gehören einer von zwei Kategorien an:

• Muster für die Verbindung eines externen Identitätsanbieters (Identity Provider, IdP) mit Google Cloud Ziel dieser Muster ist es, Google die Rolle eines IdP für Ihre Belegschaftsnutzer zu ermöglichen, sodass Google-Identitäten automatisch verwaltet werden und Ihr IdP die zentrale Informationsquelle bleibt.
• Muster für die Erweiterung eines IdP in Google Cloud: Muster für die Erweiterung eines IdP in Google Cloud: In diesen Mustern lassen Sie auf der GCP bereitgestellte Anwendungen Ihren IdP wiederverwenden. Stellen Sie dazu entweder eine direkte Verbindung damit her oder verwalten Sie ein Replikat des IdP in Google Cloud.

Muster für die Verbindung eines externen IdP mit Google Cloud

Für den Zugriff auf die Google Cloud Console, das Google Cloud CLI oder eine beliebige andere Ressource, die Google als IdP verwendet, benötigt ein Belegschaftsnutzer eine Google-Identität. Die Verwaltung von Google-Identitäten für jeden Mitarbeiter wäre umständlich, wenn alle Mitarbeiter bereits ein Konto bei einem IdP haben. Wenn Sie aber Nutzeridentitäten bei Ihrem IdP und in Google Cloud miteinander verbinden, können Sie die Verwaltung von Google-Konten automatisieren und deren Lebenszyklen an vorhandene Konten binden. Durch den Verbund wird Folgendes gewährleistet:

• Ihr IdP bleibt die einzige Datenquelle für die Identitätsverwaltung.
• Für alle von Ihrem IdP verwalteten Nutzerkonten oder eine ausgewählte Teilmenge dieser Konten wird automatisch ein Google-Konto erstellt.
• Bei Deaktivierung oder Löschung eines Kontos bei Ihrem IdP wird das entsprechende Google-Konto gesperrt oder gelöscht.
• Die Authentifizierung eines Nutzers wird an Ihren IdP delegiert, damit Passwörter und andere Anmeldedaten nicht kopiert werden können.

Active Directory über Google Cloud Directory Sync und AD FS mit Cloud Identity verbinden

Wenn Sie Active Directory als IdP verwenden, können Sie Active Directory mit Cloud Identity verbinden. Dazu verwenden Sie Google Cloud Directory Sync (GCDS) und Active Directory Federation Services (AD FS):

• GCDS ist ein von Google bereitgestelltes kostenloses Tool, mit dem der Synchronisierungsprozess implementiert wird. GCDS kommuniziert per Secure Socket Layer (SSL) mit der Identity Platform und wird normalerweise in der vorhandenen Computing-Umgebung ausgeführt.
• AD FS wird von Microsoft als Teil von Windows Server bereitgestellt. Mit AD FS können Sie Active Directory für die Föderationsauthentifizierung verwenden. AD FS wird normalerweise in der vorhandenen Computing-Umgebung ausgeführt.

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

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.

In der Praxis

1. Wenn Sie die geschützte Ressource anfordern, werden Sie zum Google-Anmeldebildschirm weitergeleitet und dort dazu aufgefordert, Ihre E-Mail-Adresse einzugeben.
2. Wenn ermittelt wird, dass die E-Mail-Adresse mit einem über Active Directory synchronisierten Konto verknüpft ist, werden Sie an AD FS weitergeleitet.
3. Abhängig von der Konfiguration von AD FS wird möglicherweise ein Anmeldebildschirm geöffnet, in dem Sie dazu aufgefordert werden, Ihren Nutzernamen und Ihr Passwort für Active Directory einzugeben. AD FS kann auch versuchen, Sie basierend auf Ihrer Windows-Anmeldung (IWA) automatisch anzumelden.
4. Nach der Authentifizierung durch AD FS werden Sie zur geschützten Ressource zurückgeleitet.

Vorteile

• Dieser Ansatz ermöglicht die Einmalanmeldung (SSO) für lokale Anwendungen und Ressourcen in Google Cloud.
• Wenn Sie in der Konfiguration festgelegt haben, dass für AD FS die Multi-Faktor-Authentifizierung erforderlich ist, wird diese Konfiguration automatisch für Google Cloud übernommen.
• Sie müssen Passwörter oder andere Anmeldedaten nicht mit Google synchronisieren.
• Da die Cloud Identity API öffentlich verfügbar ist, müssen Sie keine Hybridkonnektivität zwischen Ihrem lokalen Netzwerk und Google Cloud einrichten.

Best Practices

• Active Directory und Cloud Identity verwenden unterschiedliche logische Strukturen. Informieren Sie sich über die Unterschiede und entscheiden Sie dann, welche Methode für das Zuordnen von Domains, Identitäten und Gruppen sich am besten für Ihre Situation eignet. Weitere Informationen finden Sie im Leitfaden zum Föderieren von Google Cloud mit Active Directory.
• Synchronisieren Sie nicht nur Nutzer, sondern auch Gruppen. Bei diesem Ansatz können Sie IAM so einrichten, dass Sie den Zugriff auf Ressourcen in Google Cloud mithilfe von Gruppenmitgliedschaften in Active Directory steuern können.
• Stellen Sie AD FS so bereit, dass Belegschaftsnutzer darauf zugreifen können, aber nur im erforderlichen Umfang. Belegschaftsnutzer müssen auf AD FS zugreifen können. Es ist aber nicht nötig, dass AD FS über Google oder jede in Google Cloud bereitgestellte Anwendung aufgerufen werden kann.
• Erwägen Sie die Aktivierung der integrierten Windows-Authentifizierung (IWA) in AD FS, damit Nutzer sich basierend auf ihrer Windows-Anmeldung automatisch anmelden können.
• Wenn AD FS nicht mehr verfügbar ist, können Nutzer die Google Cloud Console oder eine andere Ressource, die Google als IdP verwendet, möglicherweise 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 für die Sicherstellung der Geschäftskontinuität einsetzen, schaden Sie mit der Verwendung von lokalen AD FS unter Umständen Ihrer eigenen Absicht, Google Cloud als eigenständige Kopie Ihrer Bereitstellung zu nutzen. Eine gute Maßnahme könnte in diesem Fall die Bereitstellung von Replikaten aller relevanten Systeme in Google Cloud sein:
  • Replizieren Sie Active Directory in Google Cloud und stellen Sie GCDS für die Ausführung in Google Cloud bereit.
  • Führen Sie dedizierte AD FS-Server in Google Cloud aus. Diese Server verwenden die in Google Cloud ausgeführten Active Directory-Domaincontroller.
  • Konfigurieren Sie in Cloud Identity die Verwendung der AD FS-Server, die für die Einmalanmeldung (SSO) in Google Cloud bereitgestellt werden.

Azure AD mit Cloud Identity verbinden

Als Microsoft Office 365- oder Azure-Kunde haben Sie Ihr lokales Active Directory unter Umständen mit Azure AD verbunden. Wenn alle Nutzerkonten, die Zugriff in Google Cloud benötigen, bereits mit Azure AD synchronisiert sind, können Sie diese Integration wiederverwenden. Verbinden Sie dazu Cloud Identity mit Azure AD. Dies wird im folgenden Diagramm dargestellt:

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

Nutzer

1. Wenn Sie die geschützte Ressource anfordern, werden Sie zum Google-Anmeldebildschirm weitergeleitet und dort dazu aufgefordert, Ihre E-Mail-Adresse einzugeben.
2. Wenn die E-Mail-Adresse mit einem über Azure AD synchronisierten Konto verknüpft ist, werden Sie an Azure AD weitergeleitet.
3. Abhängig von der Art der Verbindung zwischen dem lokalen Active Directory und Azure AD werden Sie möglicherweise von Azure AD dazu aufgefordert, einen Nutzernamen und ein Passwort einzugeben. Alternativ werden Sie zu lokalen AD FS weitergeleitet.
4. Nachdem Sie sich erfolgreich bei Azure AD authentifiziert haben, werden Sie zur geschützten Ressource zurückgeleitet.

Vorteile

• Sie müssen keine zusätzliche Software in Ihrer lokalen Umgebung installieren.
• Dieser Ansatz ermöglicht die Einmalanmeldung (SSO) für Office 365, Azure und Ressourcen in Google Cloud.
• Wenn Sie in der Konfiguration festgelegt haben, dass für Azure AD die Multi-Faktor-Authentifizierung (MFA) erforderlich ist, wird MFA automatisch für Google Cloud übernommen.
• Wenn vom lokalen Active Directory mehrere Domains oder Gesamtstrukturen verwendet werden und Sie eine benutzerdefinierte Azure AD Connect-Konfiguration eingerichtet haben, um diese Struktur einem Azure AD-Mandanten zuzuordnen, können Sie die Vorteile dieser Integration nutzen.
• Sie müssen Passwörter oder andere Anmeldedaten nicht mit Google synchronisieren.
• Da die Cloud Identity API öffentlich verfügbar ist, müssen Sie keine Hybridkonnektivität zwischen Ihrem lokalen Netzwerk und Google Cloud oder zwischen Azure und Google Cloud einrichten.
• Sie können die Google Cloud Console als Kachel im Office 365-Portal anzeigen lassen.

Best Practices

• Informieren Sie sich über die Unterschiede, die zwischen den logischen Strukturen von Azure AD und Cloud Identity bestehen. Entscheiden Sie dann, welche Methode für das Zuordnen von Domains, Identitäten und Gruppen sich am besten für Ihre Situation eignet. Weitere Informationen finden Sie unter Google Cloud mit Azure AD verbinden.
• Synchronisieren Sie nicht nur Nutzer, sondern auch Gruppen. Bei diesem Ansatz können Sie IAM so einrichten, dass sich der Zugriff auf Ressourcen in Google Cloud mithilfe von Gruppenmitgliedschaften in Azure AD steuern lässt.
• Wenn Sie Google Cloud für die Sicherstellung der Geschäftskontinuität einsetzen, schaden Sie mit der Verwendung von Azure AD zu Authentifizierungszwecken unter Umständen Ihrer eigenen Absicht, Google Cloud als eigenständige Kopie Ihrer Bereitstellung zu nutzen.

Muster für die Erweiterung eines externen IdP in Google Cloud

Für einige der Anwendungen, die Sie in Google Cloud bereitstellen möchten, werden unter Umständen Authentifizierungsprotokolle benötigt, die in Cloud Identity nicht verfügbar sind. Sie müssen zulassen, dass diese Anwendungen Ihren IdP in Google Cloud verwenden, damit diese Arbeitslasten unterstützt werden.

In den folgenden Bereichen werden gängige Muster beschrieben, die die Verwendung des IdP durch Arbeitslasten, die in Google Cloud bereitgestellt werden, zulassen.

Lokale AD FS für Google Cloud verfügbar machen

Wenn für eine Anwendung die Verwendung von WS-Trust oder WS-Federation erforderlich ist oder sie AD FS-spezifische Funktionen oder Anforderungen bei der Verwendung von OpenID Connect benötigt, können Sie zulassen, dass die Anwendung sich direkt über AD FS authentifiziert.

Mit AD FS kann eine Anwendung einen Nutzer authentifizieren. Da die Authentifizierung jedoch nicht auf einer Google-Identität basiert, können von der Anwendung keine API-Aufrufe ausgeführt werden, die mit Nutzeranmeldedaten authentifiziert werden. Stattdessen müssen alle Aufrufe von Google Cloud APIs mit einem Dienstkonto authentifiziert werden.

Nutzer

1. Wenn Sie die geschützte Ressource anfordern, werden Sie zum AD FS-Anmeldebildschirm weitergeleitet und dort dazu aufgefordert, Ihre E-Mail-Adresse einzugeben. Wenn AD FS nicht öffentlich über das Internet verfügbar ist, müssen Sie für den Zugriff auf AD FS möglicherweise mit dem Unternehmensnetzwerk oder Unternehmens-VPN verbunden sein.
2. Abhängig von der Konfiguration von AD FS wird möglicherweise ein Anmeldebildschirm geöffnet, in dem Sie dazu aufgefordert werden, Ihren Nutzernamen und Ihr Passwort für Active Directory einzugeben. AD FS kann auch versuchen, Sie basierend auf Ihrer Windows-Anmeldung automatisch anzumelden.
3. Nach der Authentifizierung durch AD FS werden Sie zur geschützten Ressource zurückgeleitet.

Vorteile

• Sie können Authentifizierungsprotokolle verwenden, die nicht von Cloud Identity unterstützt werden, z. B. WS-Trust und WS-Federation.
• Wenn die Anwendung mit Sicht auf AD FS entwickelt und getestet wurde, können Sie Risiken vermeiden, die sich ergeben, wenn Sie mit der Anwendung zu Cloud Identity wechseln.
• Sie müssen keine Hybridkonnektivität zwischen dem lokalen Netzwerk und Google Cloud einrichten.

Best Practices

• Stellen Sie AD FS so bereit, dass Belegschaftsnutzer darauf zugreifen können, aber nur im erforderlichen Umfang. Belegschaftsnutzer müssen auf AD FS zugreifen können. Es ist aber nicht nötig, dass AD FS über Google oder jede in Google Cloud bereitgestellte Anwendung aufgerufen werden kann.
• Wenn AD FS nicht mehr verfügbar ist, können Nutzer die Anwendung möglicherweise nicht mehr verwenden. Achten Sie darauf, dass AD FS und die Domaincontroller, die von AD FS benötigt werden, gemäß Ihren Verfügbarkeitszielen bereitgestellt und dimensioniert werden.
• Erwägen Sie eine Refaktorierung der Anwendungen, die auf WS-Trust und WS-Federation basieren, sodass stattdessen SAML oder OpenID Connect verwendet wird.
• Wenn die Anwendung Gruppeninformationen benötigt, die in von AD FS als Anforderungen ausgegebenen IdTokens verfügbar gemacht werden, prüfen Sie die Möglichkeit, die Gruppeninformationen von einer anderen Quelle (z. B. der Directory API) abzurufen. Die Abfrage der Directory API ist ein privilegierter Vorgang, der ein Dienstkonto erfordert, das für die domainweite Delegierung von Google Workspace aktiviert ist.

Lokales LDAP-Verzeichnis für Google Cloud verfügbar machen

Bei einigen Anwendungen müssen Nutzer möglicherweise ihren Nutzernamen und ihr Passwort angeben und mit diesen Anmeldedaten versuchen, eine LDAP-Bindung zu erstellen. Wenn Sie diese Anwendungen nicht so ändern können, dass die Authentifizierung auf andere Weise ausgeführt wird (etwa über SAML), können Sie ihnen Zugriff auf ein lokales LDAP-Verzeichnis gewähren.

Vorteile

• Sie müssen die Anwendung nicht ändern.

Best Practices

• Verwenden Sie Cloud VPN oder Cloud Interconnect, um eine Hybridverbindung zwischen Google Cloud und Ihrem lokalen Netzwerk herzustellen, damit Sie das LDAP-Verzeichnis nicht über das Internet freigeben müssen.
• Achten Sie darauf, dass die zusätzliche Latenz durch die Abfrage eines lokalen LDAP-Verzeichnisses keine negativen Auswirkungen auf die Nutzerumgebung hat.
• Sorgen Sie dafür, dass die Kommunikation zwischen der Anwendung und dem LDAP-Verzeichnis verschlüsselt ist. Die Verschlüsselung kann über Cloud VPN oder Cloud Interconnect mit LDAP/S erfolgen.
• Wenn das LDAP-Verzeichnis oder die private Verbindung zwischen Google Cloud und dem lokalen Netzwerk nicht mehr verfügbar ist, können Nutzer LDAP-basierte Anwendungen unter Umständen nicht mehr verwenden. Sorgen Sie deshalb dafür, dass die entsprechenden Server gemäß Ihren Verfügbarkeitszielen bereitgestellt und dimensioniert werden, und ziehen Sie die Verwendung redundanter VPN-Tunnel oder von Interconnect-Verbindungen in Betracht.
• Wenn Sie Google Cloud für die Gewährleistung der Geschäftskontinuität einsetzen, schaden Sie mit der Verwendung eines lokalen LDAP-Verzeichnisses unter Umständen Ihrer eigenen Absicht, Google Cloud als eigenständige Kopie Ihrer Bereitstellung zu nutzen. Erwägen Sie in diesem Fall, stattdessen das LDAP-Verzeichnis in Google Cloud zu replizieren.
• Wenn Sie Active Directory verwenden, ist eine sinnvolle Alternative die Ausführung eines Replikats in Google Cloud, vor allem, wenn Sie in Google Cloud ausgeführte Windows-Maschinen in Active Directory-Domains aufnehmen möchten.

Lokales LDAP-Verzeichnis in Google Cloud replizieren

Das Replizieren eines lokalen LDAP-Verzeichnisses in Google Cloud unterscheidet sich nur unwesentlich vom Muster Lokales LDAP-Verzeichnis für Google Cloud verfügbar machen. Anwendungen, die Nutzernamen und Passwörter über LDAP prüfen, lassen sich auf diese Weise in Google Cloud ausführen. Sie können ein Replikat des lokalen Verzeichnisses in Google Cloud beibehalten anstatt es solchen Anwendungen zu erlauben, Ihr lokales LDAP-Verzeichnis abzufragen.

Vorteile

• Sie müssen die Anwendung nicht ändern.
• Die Verfügbarkeit von LDAP-basierten Anwendungen, die in Google Cloud ausgeführt werden, hängt nicht von der Verfügbarkeit des lokalen Verzeichnisses oder einer Verbindung mit dem lokalen Netzwerk ab. Dieses Muster eignet sich besonders für hybride Szenarien zur Beibehaltung der Geschäftskontinuität.

Best Practices

• Verwenden Sie Cloud VPN oder Cloud Interconnect, um eine Hybridverbindung zwischen Google Cloud und Ihrem lokalen Netzwerk herzustellen, damit Sie das LDAP-Verzeichnis nicht über das Internet freigeben müssen.
• Achten Sie darauf, dass die Replikation zwischen dem lokalen LDAP-Verzeichnis über einen sicheren Kanal stattfindet.
• Stellen Sie mehrere Replikate des LDAP-Verzeichnisses in mehreren Zonen oder Regionen bereit, um Ihre Verfügbarkeitsziele zu erreichen. Sie können die LDAP-Verbindungen mit einem internen Load-Balancer auf mehrere Replikate aufteilen, die in derselben Region bereitgestellt werden.
• Verwenden Sie ein separates Google Cloud-Projekt mit einer freigegebenen VPC, um LDAP-Replikate bereitzustellen und Zugriff auf dieses Projekt auf der Grundlage der geringsten Berechtigung zu gewähren.

Lokales Active Directory in Google Cloud erweitern

Einige der Arbeitslasten, die Sie in Google Cloud bereitstellen möchten, sind unter Umständen von Active Directory Domain Services abhängig. Beispiele hierfür sind:

• Windows-Computer, die Teil einer Domain sein müssen
• Anwendungen, die über Kerberos oder NTLM authentifiziert werden
• Anwendungen, die Active Directory als LDAP-Verzeichnis für die Überprüfung von Nutzernamen und Passwörtern verwenden

Sie können Ihre lokale Active Directory-Gesamtstruktur in Google Cloud erweitern, um diese Arbeitslasten zu unterstützen. Stellen Sie dazu etwa eine Ressourcen-Gesamtstruktur für Google Cloud bereit und verbinden Sie diese mit der lokalen Active Directory-Gesamtstruktur, wie im folgenden Diagramm gezeigt.

Weitere Informationen zu diesem Ansatz und weitere Möglichkeiten für die Bereitstellung von Active Directory in einer Hybridumgebung finden Sie unter Muster für die Verwendung von Active Directory in einer Hybridumgebung.

Vorteile

• Ihre Arbeitslasten können alle Vorteile von Active Directory nutzen, z. B. die Möglichkeit, Windows-Computer in die Active Directory-Domain aufzunehmen.
• Die Verfügbarkeit von Active Directory-basierten Anwendungen, die in Google Cloud ausgeführt werden, hängt nicht von der Verfügbarkeit lokaler Ressourcen oder der Verbindung mit dem lokalen Netzwerk ab. Dieses Muster eignet sich besonders für hybride Szenarien zur Beibehaltung der Geschäftskontinuität.

Best Practices

• Verwenden Sie Cloud VPN oder Cloud Interconnect, um eine Hybridverbindung zwischen Google Cloud und Ihrem lokalen Netzwerk herzustellen.
• Erstellen Sie einen separate Active Directory-Standort für Google Cloud-Bereitstellungen, um die Kommunikation zwischen der Google Cloud und dem lokalen Netzwerk auf ein Mindestmaß zu begrenzen. Sie können einen einzigen Standort pro freigegebene VPC verwenden oder einen Standort pro freigegebene VPC und Region, um die Kommunikation zwischen Regionen so gering wie möglich zu halten.
• Erstellen Sie eine separate Active Directory-Domain nur für Ressourcen, die in Google Cloud bereitgestellt werden, und fügen Sie die Domain der vorhandenen Gesamtstruktur hinzu. Die Verwendung einer separaten Domain führt zu einem geringeren Replikationsaufwand und kleineren Partitionen.
• Stellen Sie mindestens zwei Domaincontroller bereit und verteilen Sie diese auf mehrere Zonen, um die Verfügbarkeit zu erhöhen. Wenn Sie mehrere Regionen verwenden, erwägen Sie, Domaincontroller in jeder Region bereitzustellen.
• Verwenden Sie ein separates Google Cloud-Projekt mit einer freigegebenen VPC, um Domaincontroller bereitzustellen und Zugriff auf dieses Projekt auf der Grundlage der geringsten Berechtigung zu gewähren. Andernfalls könnten unbefugte Projektmitglieder Zugriff auf die Domain erhalten, wenn Sie ein Passwort generieren oder auf die serielle Konsole von Domaincontroller-Instanzen zugreifen.
• Prüfen Sie, ob die Bereitstellung einer AD FS-Serverfarm und von GCDS in Google Cloud sinnvoll wäre. Auf diese Weise können Sie Active Directory mit Cloud Identity verbinden, ohne von der Verfügbarkeit von Ressourcen oder der Verbindung mit dem lokalen Netzwerk abhängig zu sein.

Nächste Schritte

• Google Cloud mit Active Directory verbinden
• Muster für die Verwendung von Active Directory in einer Hybridumgebung
• Google Cloud mit Azure Active Directory verbinden
• Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.