Workforce-Nutzer in einer Hybridumgebung authentifizieren

Last reviewed 2024-06-26 UTC

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

Die Reihe besteht aus folgenden Teilen:

Einführung

Eine wichtige Aufgabe der IT-Abteilungen von Unternehmen besteht darin, Nutzerkonten zu verwalten und den Mitarbeiterzugriff auf Anwendungen und Rechenressourcen zu steuern. Weil eine konsistente Datenhaltung und administrative Effizienz hohe Priorität hat, wird die Identitätsverwaltung in den meisten Unternehmen als zentrale Funktion erachtet und ein einheitliches System zum Verwalten von Identitäten eingesetzt. Meistens verwenden Unternehmen dafür Microsoft Active Directory Domain Services (AD DS).

Wenn Sie eine IT-Umgebung im Rahmen einer Hybridstrategie auf Google Cloud erweitern, sind Sie wahrscheinlich daran interessiert, einen zentralen Punkt beizubehalten, an dem Identitäten verwaltet werden. Ein einheitliches Identitätsverwaltungssystem bedeutet auch einen geringeren administrativen Aufwand für das Verwalten von Konten und die Zugriffssteuerung. Mit diesem System können Sie dafür sorgen, dass Nutzer und Anwendungen sich in einer Hybridumgebung sicher authentifizieren können.

In diesem Dokument werden die verschiedenen Möglichkeiten aufgezeigt, Google Cloud in Ihr Identitätsverwaltungssystem einzubinden. So können Sie sich für den Ansatz entscheiden, der sich am besten für Sie eignet.

Obwohl fast alle Informationen in diesem Dokument auch für Google Workspace gelten, liegt der Fokus ausschließlich auf Cloud Identity.

Anforderungen im Hinblick auf die hybride Identitätsverwaltung prüfen

Die beste Methode für die Erweiterung Ihres Identitätsverwaltungssystems auf Google Cloud hängt von mehreren Faktoren ab:

  • Die Identitätspools in der Organisation
  • Die verwendeten Identitätsanbieter für die Authentifizierungsdienste für Mitarbeiteridentitäten
  • Die Ressourcen und Anwendungen, auf die Ihre Nutzer auf Google Cloud zugreifen können sollen
  • Ihre Anforderungen bezüglich der Geschäftskontinuität

In den folgenden Abschnitten wird individuell auf diese Faktoren eingegangen.

Identitäten

Der erste Faktor, den Sie beim Einbinden von Google Cloud und Ihres Identitätsverwaltungssystems berücksichtigen sollten, ist die Verwaltung und Unterscheidung von Identitätstypen. Die meisten Organisationen verwenden die folgenden Identitätstypen:

  1. Mitarbeiteridentitäten sind die Identitäten, die Sie für Mitarbeiter Ihrer Organisation verwalten. Diese Identitäten werden für die Anmeldung bei Workstations, den Zugriff auf E-Mails oder die Nutzung von Unternehmensanwendungen verwendet.
  2. Externe Identitäten sind die Identitäten, die Sie für Nichtmitarbeiter verwalten, z. B. für Auftragnehmer oder Partner, die Zugriff auf Unternehmensressourcen benötigen.
  3. Gastidentitäten sind Identitäten, die von Externen verwaltet werden, z. B. einem Kunden oder Partner, der Zugriff auf die Unternehmensressourcen benötigt.
  4. Kundenidentitäten sind die Identitäten, die Sie für Nutzer verwalten, damit diese Ihre Website und kundenseitigen Anwendungen verwenden können.
  5. Workload Identities sind die Identitäten, die Sie verwalten, um Anwendungen die Interaktion mit anderen Anwendungen oder der zugrunde liegenden Plattform zu ermöglichen.

Oft befinden sich Mitarbeiteridentitäten in einem einzigen Identitätspool, in dem jeder Mitarbeiter über eine einzelne Identität verfügt und alle Identitäten auf die gleiche Weise mit denselben Systemen verwaltet werden. Das muss jedoch nicht so sein. Nach Unternehmenszusammenschlüssen oder -übernahmen etwa gibt es möglicherweise mehrere Pools mit Mitarbeiteridentitäten, die auf unterschiedliche Weise mit unterschiedlichen Systemen verwaltet werden. In technischer Hinsicht bedeutet dies, dass Sie gegebenenfalls mehrere LDAP-Quellen, Active Directory-Gesamtstrukturen oder Azure AD-Mandanten mit Google Cloud integrieren müssen.

Die Einbindung mehrerer Pools erhöht die Komplexität der Integration mit Google Cloud. Daher sollten Sie sich folgende Fragen stellen:

  • Benötigen alle Identitätspools Zugriff auf Google Cloud oder nur eine ausgewählte Teilmenge?
  • Sollen alle Identitätspools Zugriff auf dieselbe Organisation in Google Cloud haben oder jeder auf eine jeweils andere Organisation?
  • Kann die Anzahl der Pools reduziert werden, indem z. B. gesamtstrukturübergreifende Vertrauensstellungen zwischen Active Directory-Gesamtstrukturen erstellt werden?

Externe Identitäten werden oft ähnlich wie Mitarbeiteridentitäten behandelt. Es gibt jedoch folgende Ausnahmen:

  • Die Identitäten sind möglicherweise nur eine bestimmte Zeit lang gültig.
  • Möglicherweise haben die Identitäten standardmäßig weniger Rechte.
  • Die Identitäten werden möglicherweise von einem separaten LDAP-Verzeichnis oder Azure AD-Mandanten oder einer separaten Active Directory-Gesamtstruktur verwaltet.

Gastidentitäten dagegen werden nicht wie externe Identitäten von Ihnen verwaltet, sondern von jemand anderem. In SaaS-Anwendungen wie Google Workspace können Gastidentitäten nicht mehr erforderlich sein, um externe Identitäten für Kunden oder Partner zu verwalten. In lokalen Umgebungen gibt es kaum Gastidentitäten.

Des Schwerpunkt dieses Dokuments liegt auf Mitarbeiteridentitäten und externen Identitäten.

Wenn Sie Dienste wie Google Ads verwenden, verfügen einige Ihrer Mitarbeiter möglicherweise bereits über ein Google-Konto, das nicht mit ihrer Mitarbeiteridentität verknüpft ist, sodass sie zwei Identitäten haben. Falls ja, sollten Sie diese Identitäten konsolidieren.

Identitätsanbieter

Der zweite Faktor, der eine Rolle spielt, sind Ihre Identitätsanbieter. Bei einem Identitätsanbieter (IdP) handelt es sich um ein System, das Authentifizierungsdienste für Ihre Arbeitslasten bereitstellt und entscheidet, ob ein Nutzer authentifiziert wird.

IdPs bieten nicht nur Authentifizierungsdienste an, sondern verwalten oft auch den Lebenszyklus von Identitäten. Das muss jedoch nicht so sein, da Identitäten auch über ein separates HR-System bereitgestellt werden können.

Häufig werden folgende Identitätsanbieter verwendet:

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • IDaaS-Anbieter wie ForgeRock, Okta oder Ping Identity
  • Andere LDAP-Verzeichnisse, z. B. Active Directory Lightweight Directory Services (AD LDS)

Anstelle eines einzigen Systems können Sie auch mehrere Systeme verwenden, um etwa verschiedene Nutzerpools und externe Konten zu verwalten oder verschiedene Authentifizierungsdienste für dieselben Nutzerpools bereitzustellen. In den folgenden Beispielen werden mehrere IdPs zur Verwaltung derselben Pools verwendet:

  • Mit Azure AD verbundenes Active Directory
  • Mit einem IDaaS-Anbieter verbundenes Active Directory, z. B. ForgeRock, Okta oder Ping Identity
  • Active Directory mit AD LDS-Replikaten

Es gibt zwei grundlegende Methoden für die Verwendung Ihres IdP auf Google Cloud:

  • Identitätsanbieter mit Cloud Identity verknüpfen: Durch die Verknüpfung mit Cloud Identity ermöglichen Sie es Google, zu einem weiteren IdP zu werden, der von Ihren Belegschaftsnutzern verwendet werden kann und den auf Google Cloud bereitgestellte Anwendungen nutzen können. Sie verwalten somit keine Google-Identitäten für alle Ihre Nutzer, da dies automatisch über die Verbundbeziehung geschieht. Diese Beziehung führt auch dazu, dass Ihr IdP die einzige Datenquelle bleibt.
  • Identitätsanbieter auf Google Cloud erweitern: Sie können auf Google Cloud bereitgestellten Anwendungen die Wiederverwendung Ihres IdP gestatten, indem Sie entweder eine direkte Verbindung dazu herstellen oder ein Replikat des IdP auf Google Cloud verwalten.

Abhängig von den anderen Faktoren im Zusammenhang mit der Identitätsverwaltung müssen Sie möglicherweise beide Ansätze kombinieren, damit hybride Nutzungsszenarien unterstützt werden.

Ressourcen

Der dritte zu berücksichtigende Faktor ist die Überlegung, auf welche Google Cloud-Ressourcen Sie Ihren Belegschaftsnutzern Zugriff gewähren möchten. Dieser Faktor umfasst auch Google Cloud selbst. Sie müssen den verantwortlichen Teams die Möglichkeit geben, Google Cloud über die Google Cloud Console, die gcloud CLI oder die APIs zu verwalten.

Es gibt u. a. die folgenden zusätzlichen Ressourcen:

Diese Ressourcen unterscheiden sich dadurch, dass sie Google als Identitätsanbieter verwenden müssen oder können oder dies für sie nicht möglich ist. In den folgenden Abschnitten werden diese drei Fälle behandelt.

Resourcen, die Google als IdP verwenden müssen

Zu den Ressourcen, die Google als IdP verwenden müssen, gehören die Google Cloud Console, die gcloud CLI, mit Cloud IAP geschützte Anwendungen und andere Google-Tools und -Dienste. Sie müssen eine Google-Identität für jeden Nutzer bereitstellen, um Belegschaftsnutzern Zugriff auf diese Ressourcen zu gewähren.

Die Verwaltung separater Google-Identitäten ist nicht im Sinne einer einheitlichen Identitätsverwaltung. Wenn Sie Nutzern Zugriff auf eine dieser Ressourcen gewähren, bedeutet dies also, dass Sie Ihren IdP mit Google Cloud verbinden müssen.

Nachdem Sie den IdP mit Google Cloud verbunden haben, empfiehlt sich die Verwendung von Google als IdP für weitere Ressourcen, z. B. Anwendungen, die andere Methoden für die Nutzerauthentifizierung verwenden können.

Ressourcen, die Google als IdP verwenden können

Zu den Ressourcen, die Google als IdP verwenden können, das aber aktuell nicht tun, zählen:

  • Neue Anwendungen für Belegschaftsnutzer, die auf Google Cloud bereitgestellt werden sollen
  • Vorhandene Anwendungen für Belegschaftsnutzer, die per Lift-and-Shift oder Move-and-Improve nach Google Cloud migriert werden sollen.

Ob diese Anwendungen Google als IdP verwenden können, hängt davon ab, welche Protokolle für die Authentifizierung und Autorisierung zum Einsatz kommen.

Webprotokolle für die Einmalanmeldung

Google unterstützt mehrere branchenübliche Protokolle für die Authentifizierung, Autorisierung und Einmalanmeldung. Es werden u. a. folgende Protokolle unterstützt:

  • OAuth 2.0 für mobile Clients, Fat Clients und andere nicht browserbasierte Anwendungen
  • OpenID Connect 1.0 (OIDC) für browserbasierte Anwendungen
  • SAML 2.0 für die Einbindung von Drittanbieteranwendungen

Für Anwendungen, deren Bereitstellung Sie planen, empfiehlt sich die Verwendung von OAuth 2.0 oder OIDC. Diese Protokolle haben sich allgemein durchgesetzt, sodass Sie viele gut getestete Bibliotheken und Tools nutzen können. Außerdem können Sie bei diesen Protokollen optional Google als IdP verwenden und sich gleichzeitig die Möglichkeit offenhalten, den Identitätsanbieter gegebenenfalls flexibel zu ändern.

Wenn Sie über Anwendungen verfügen, die SAML, OAuth 2.0 oder OIDC verwenden, ist ein Wechsel zu Google als Identitätsanbieter mit keinen oder nur geringfügigen Codeänderungen möglich.

LDAP

Eines der vielseitigsten und zuverlässigsten Protokolle für die Authentifizierung und Autorisierung ist das Lightweight Directory Access Protocol (LDAP). Anwendungen können LDAP auf verschiedene Weise für die Authentifizierung und Autorisierung verwenden. Die folgenden beiden Szenarien kommen am häufigsten vor:

  1. LDAP zur Authentifizierung und Abfrage von Nutzerinformationen verwenden: In diesem Szenario verwendet eine Anwendung keine Einmalanmeldung. Stattdessen sieht der Nutzer ein Anmeldeformular, in dem er nach dem Nutzernamen und Passwort gefragt wird. Mit den angegebenen Anmeldedaten wird versucht, eine LDAP-bind-Operation auszuführen. Wenn der Versuch erfolgreich ist, gelten die Anmeldedaten als gültig. Möglicherweise werden weitere Informationen zum Nutzer aus dem Verzeichnis abgefragt und für die Autorisierung des Zugriffs verwendet, z. B. der Name und Gruppenmitgliedschaften.

  2. SAML zur Authentifizierung und LDAP zur Abfrage von Nutzerinformationen verwenden: In diesem Szenario authentifiziert die Anwendung den Nutzer über ein Protokoll für die Einmalanmeldung. Anwendungen verwenden oft SAML zu diesem Zweck. Nachdem der Nutzer authentifiziert wurde, verwendet die Anwendung den LDAP-Server, um weitere Informationen zum Nutzer abzufragen, z. B. den Namen und Gruppenmitgliedschaften.

Der entscheidende Unterschied zwischen den beiden Szenarien besteht darin, dass im ersten Szenario die Anwendung und der LDAP-Server Zugriff auf das Nutzerpasswort benötigen, um die Anmeldedaten überprüfen zu können. Im zweiten Szenario benötigen die Anwendung und der Server keinen Zugriff auf das Nutzerpasswort; die Anwendung kann die LDAP-Abfragen über einen dedizierten Dienstnutzer ausführen.

Mit Secure LDAP können Sie über das LDAP-Protokoll auf Nutzer- und Gruppeninformationen in Cloud Identity zugreifen. Wenn Google der primäre IdP ist, können Sie über Secure LDAP beide Szenarien unterstützen. Integrieren Sie Cloud Identity jedoch mit einem externen IdP, arbeitet Cloud Identity nicht mit einer Kopie der Nutzerpasswörter. Entsprechend ist nur das zweite Szenario mit Secure LDAP möglich.

Kerberos und NTLM

Wenn Sie planen, Windows-basierte Arbeitslasten zu Google Cloud zu migrieren, hängen einige dieser Anwendungen möglicherweise von der integrierten Windows-Authentifizierung (IWA) und nicht von der Verwendung von Standardprotokollen ab. IWA wird häufig für ASP.NET-basierte Anwendungen verwendet, die in Microsoft IIS ausgeführt werden. IWA ist beliebt, da damit eine nahtlose Einmalanmeldung für Nutzer möglich ist, die sich mit Domainanmeldedaten auf ihrer Windows-Workstation angemeldet haben.

IWA basiert auf NTLM oder Kerberos. Deren Verwendung setzt voraus, dass die Workstation des Nutzers und der Server, auf dem die Anwendung ausgeführt wird, mit derselben Active Directory-Domain oder mit Domains mit entsprechender Vertrauensstellung verbunden sind.

Bei Verwendung von NTLM und Kerberos bedeutet dies entsprechend, dass eine Anwendung, die IWA verwendet, Google nicht als IdP verwenden kann. Sie haben gegebenenfalls dennoch die Möglichkeit, die Anwendung für die Verwendung von OIDC zu refaktorieren. Bei OIDC muss die Workstation oder der Server des Nutzers nicht mit der Domain verbunden sein. Eine Refaktorierung kann deshalb die Bereitstellung vereinfachen und Ihnen helfen, alternative Bereitstellungsoptionen zu verfolgen.

In Anbetracht der nahtlosen Einmalanmeldung mit IWA kann die Verwendung von OIDC anstelle von IWA wie ein Rückschritt in puncto Nutzerfreundlichkeit wirken. Das muss jedoch nicht so sein, wenn Sie dafür sorgen, dass Nutzer sich nahtlos bei AD FS oder Azure AD anmelden können:

  • Wenn Sie Google Cloud mit Active Directory und AD FS verbinden, können alle in AD FS konfigurierten Authentifizierungsmethoden verwendet werden. Wenn Sie AD FS so konfigurieren, dass IWA zugelassen wird, können bei ihrer Windows-Workstation angemeldete Nutzer sich über Domainanmeldedaten nahtlos bei jeder beliebigen Anwendung anmelden, die Google als IdP verwendet.
  • Wenn Sie Google Cloud mit Azure AD verbinden, können Sie ebenso eine nahtlose Einmalanmeldung mit Azure AD ermöglichen.

Im folgenden Diagramm wird ein vereinfachtes Beispiel dafür gezeigt, wie Sie mit Cloud Identity, AD FS und IWA eine nahtlose Einmalanmeldung für eine Webanwendung implementieren:

Mit Cloud Identity, AD FS und IWA eine nahtlose Einmalanmeldung für eine Webanwendung implementieren

  1. Der Browser fordert über einen Webbrowser eine geschützte Seite an.
  2. Die Webanwendung initiiert eine Anmeldung über OIDC (OIDC-Authentifizierungsablauf). Bei diesem Ablauf wird der Browser an den Google-Anmeldeendpunkt weitergeleitet.
  3. Der Google-Anmeldeendpunkt gibt die Google-Anmeldeseite an den Nutzer zurück und fordert ihn zur Eingabe einer E-Mail-Adresse auf.
  4. Der Nutzer gibt seine E-Mail-Adresse ein.
  5. Der Google-Anmeldeendpunkt identifiziert das Cloud Identity-Konto anhand der E-Mail-Adresse und erkennt, dass dafür die Verwendung der Einmalanmeldung konfiguriert ist. Der Anmeldeendpunkt initiiert dann eine SAML-Anmeldung mit AD FS.
  6. In AD FS wurde die Verwendung von IWA konfiguriert, sodass ein Kerberos-Ticket vom Browser angefordert wird. Daraufhin weist der Browser das zugrunde liegende Windows-Betriebssystem an, ein entsprechendes Ticket abzurufen.
  7. Falls kein geeignetes Ticket im Cache gespeichert wurde, fordert Windows vom Active Directory-Schlüsselverteilungscenter ein entsprechendes Dienstticket an. Es wird basierend auf dem Ticket Granting Ticket (TGT) ausgestellt, das bei der Nutzeranmeldung bei Windows abgerufen wurde.
  8. Der Browser stellt das neu abgerufene Ticket für AD FS bereit.
  9. AD FS validiert das Ticket, indem die kryptografische Signatur überprüft, die Nutzeridentität aus dem Ticket extrahiert und ein SAML-Token für den Google-Anmeldeendpunkt ausgestellt wird.
  10. Der Google-Anmeldeendpunkt vervollständigt die OIDC-Anmeldung mit den Authentifizierungsinformationen aus dem SAML-Token und stellt OpenID Connect-Token für die Webanwendung aus.
  11. Wenn der Nutzer authentifiziert ist, kann die geschützte Seite an ihn zurückgegeben werden.

Authentifizierung mit einem öffentlichen SSH-Schlüssel

Wenn Sie virtuelle Linux-Maschinen (VMs) auf Google Cloud ausführen möchten, benötigen Sie mit ziemlicher Sicherheit SSH-Zugriff auf diese Maschinen. Die gängigste Authentifizierungsmethode für SSH ist die Authentifizierung mit einem öffentlichen Schlüssel.

Im Gegensatz zu den zuvor behandelten Protokollen für die Einmalanmeldung ist die Authentifizierung mit einem öffentlichen SSH-Schlüssel beim Treffen von Authentifizierungsentscheidungen nicht von einem zentralisierten IdP abhängig. Stattdessen werden Authentifizierungsentscheidungen dezentralisiert getroffen; auf jeder Maschine erfolgt die Authentifizierung anhand eines lokalen Satzes von autorisierten öffentlichen Schlüsseln.

Mit OS Login können Sie die Lücke zwischen der dezentralisierten Authentifizierung mit einem öffentlichen SSH-Schlüssel und der zentralisierten Identitätsverwaltung schließen. OS Login verknüpft den Lebenszyklus von SSH-Schlüsseln mit dem Lebenszyklus von Nutzerkonten so:

  • Veröffentlichen eines öffentlichen SSH-Schlüssels, wenn ein Nutzer erstellt wird oder versucht, zum ersten Mal SSH zu verwenden
  • Den öffentlichen Schlüssel des Nutzers für Maschinen bereitstellen, für die der Nutzer über eine Zugriffsberechtigung verfügt
  • Bereitstellung des öffentlichen Schlüssels des Nutzers aufheben, wenn der Zugriff auf das Konto aufgehoben wird oder das Konto deaktiviert oder gelöscht wird

Bei Verwendung von OS Login wird Cloud Identity effektiv zum IdP für Ihre Linux-Instanzen.

Ressourcen, die Google nicht als IdP verwenden können

Einige Ressourcen können Google nicht direkt als IdP verwenden. Sie können diese Ressourcen dennoch auf Google Cloud bereitstellen, indem Sie zwei Methoden zusammenführen:

  • Externen IdP mit Google Cloud verbinden, um zuzulassen, dass Unternehmensnutzer die Google Cloud Console, die gcloud CLI und andere Ressourcen einsetzen, die Google als IdP verwenden müssen oder können.
  • IdP auf Google Cloud erweitern, um Ressourcen zu aktivieren, die Google nicht als IdP verwenden können, der auf Google Cloud ausgeführt wird.

Wenn eine Ressource auf Protokollen basiert, die vom Google-IdP nicht unterstützt werden, kann diese Ressource Google nicht als IdP verwenden. Dazu zählen die folgenden Protokolle:

  • LDAP zur Authentifizierung: Sie können Secure LDAP verwenden, um die Abfrage von Nutzerinformationen aus Cloud Identity über LDAP zu vereinfachen. Cloud Identity unterstützt LDAP jedoch nicht für die Authentifizierung, wenn eine Verbindung mit einem externen IdP besteht.

    Damit LDAP für die Authentifizierung von Anwendungen zulässig ist, können Sie ein lokales LDAP-Verzeichnis bereitstellen oder replizieren oder Active Directory auf Google Cloud erweitern.

  • WS-Trust, WS-Federation: Besonders bei der Verwendung von AD FS übernimmt WS-Trust oder WS-Federation möglicherweise auch weiterhin die tokenbasierte Authentifizierung für Sie. Wenn Sie die betroffenen Anwendungen nicht auf die Verwendung von SAML oder OpenID Connect umstellen können, empfiehlt es sich, das lokale AD FS für Google Cloud verfügbar zu machen und Anwendungen die direkte Nutzung von AD FS zu erlauben.

  • OpenID Connect mit AD FS-spezifischen Anforderungen: AD FS und Google unterstützen OpenID Connect. Wenn Sie AD FS als OpenID Connect-Anbieter verwendet haben, benötigen Sie möglicherweise bestimmte AD FS-spezifische Anforderungen, die von Google nicht unterstützt werden. In diesem Fall ist vielleicht zu empfehlen, das lokale AD FS für Google Cloud verfügbar zu machen und den betroffenen Anwendungen die direkte Nutzung von AD FS zu ermöglichen.

  • Kerberos, NTLM: Wenn einige Ihrer Anwendungen Kerberos oder NTLM für die Authentifizierung verwenden, können Sie diese gegebenenfalls so bearbeiten, dass sie stattdessen OpenID Connect oder SAML verwenden. Ist dies nicht möglich, können Sie diese Anwendungen auf mit der Domain verbundenen Windows-Servern bereitstellen und das lokale Active Directory für Google Cloud verfügbar machen oder replizieren.

  • Virtuelle Windows-Maschinen: Wenn Sie Windows-Arbeitslasten auf Google Cloud ausführen, müssen Sie sich über RDP (Remote Desktop Protocol), ein Remote Desktop-Gateway oder eine andere Methode bei diesen VMs anmelden können. Verfügt ein Nutzer über Schreibzugriff auf das Google Cloud-Projekt, in dem die VM erstellt wurde, ermöglicht es Google Cloud dem Nutzer, einen Nutzer und ein Passwort zu erstellen. Daraufhin wird ein Konto in der lokalen SAM-Datenbank (Security Account Manager) erstellt. Entscheidend ist, dass das resultierende Windows-SAM-Konto nicht mit dem Google-Konto des Nutzers verknüpft ist und nicht denselben Kontolebenszyklus hat. Wenn Sie das Google-Konto des Nutzers sperren oder löschen, hat dies keine Auswirkungen auf das Windows-SAM-Konto, das auch weiterhin Zugriff auf die VM bereitstellen kann.

    Wenn Sie über eine moderate Anzahl von Windows-VMs und Nutzern verfügen, die sich bei diesen Maschinen anmelden müssen, können Sie es Nutzern erlauben, Windows-Nutzerkonten und -passwörter zu generieren. Wenn Sie dagegen eine höhere Zahl von Windows-Servern verwenden, empfiehlt es sich, stattdessen ein lokales Active Directory auf Google Cloud zu erweitern und die entsprechenden Server in die Domain aufzunehmen. Die Aufnahme der Server in die Domain ist auch eine Grundvoraussetzung, wenn Sie die Authentifizierung auf Netzwerkebene nutzen.

Verfügbarkeit

Der letzte Faktor ist die Verfügbarkeit. Die Möglichkeit, Nutzer zu authentifizieren, ist wahrscheinlich ein wichtiger Punkt bei vielen Ihrer Arbeitslasten und ein IdP-Ausfall kann weitreichende Konsequenzen haben. Wie Sie am besten für die notwendige Verfügbarkeit sorgen, hängt davon ab, auf welche Weise Sie Google Cloud verwenden möchten und wie sich dies mit Ihrer Hybridstrategie vereinbaren lässt.

Verteilte Arbeitslasten

Sie können Arbeitslasten über eine hybride Methode mit mehreren Clouds auf einzelne Computing-Umgebungen verteilen, um von den besonderen Funktionen dieser Computing-Umgebungen zu profitieren. Diese Umgebungen haben möglicherweise wechselseitige Abhängigkeiten, die kritisch für die Verfügbarkeit Ihrer Arbeitslasten sind. Abhängigkeiten können u. a. VPN oder Interconnect-Verbindungen, miteinander kommunizierende Anwendungen oder Systeme sein, die auf Daten in verschiedenen Computing-Umgebungen zugreifen.

Achten Sie beim Verbinden des externen IdP mit Google Cloud oder beim Erweitern auf Google Cloud darauf, dass die Verfügbarkeit des externen IdP und der anderen Systeme, die für die Authentifizierung benötigt werden, der Verfügbarkeit anderer kritischer Abhängigkeiten entspricht oder sie übersteigt. Das bedeutet, dass Sie den externen IdP und seine Abhängigkeiten möglicherweise redundant bereitstellen und für eine redundante Netzwerkkonnektivität sorgen müssen.

Redundante Arbeitslasten

Wenn Sie Google Cloud zum Sicherstellen der Geschäftskontinuität einsetzen, spiegeln Ihre Arbeitslasten auf Google Cloud auch einige der Arbeitslasten in Ihrer Computing-Umgebung. Diese Konfiguration ermöglicht es der einen Umgebung, die Rolle der anderen Umgebung zu übernehmen, wenn ein Fehler auftritt. Sie müssen also jede Abhängigkeit zwischen diesen Umgebungen untersuchen.

Eine Abhängigkeit ergibt sich dadurch, dass Google Cloud einen lokal ausgeführten IdP benötigt. Diese Abhängigkeit verhindert möglicherweise, dass Google Cloud als unabhängige Kopie der Computing-Umgebung genutzt werden kann.

Versuchen Sie, den IdP auf Google Cloud zu replizieren, sodass keine der Arbeitslasten auf Google Cloud von einem Ausfall der lokalen Computing-Umgebung oder der Verbindung zwischen Google Cloud und dem lokalen Netzwerk betroffen sind.

Nächste Schritte