In diesem Dokument werden Best Practices und Anleitungen vorgestellt, die Sie bei der konsistenten und sicheren Einrichtung einer Föderation unterstützen. Diese Anleitung basiert auf den Best Practices für die Verwendung von Cloud Identity oder Google Workspace mit Google Cloud.
Alle Google-Dienste, einschließlich Google Cloud, Google Marketing Platform und Google Ads, nutzen Google Log-in zur Authentifizierung von Nutzern. Anstatt für jeden Mitarbeiter Nutzerkonten in Cloud Identity oder Google Workspace manuell zu erstellen und zu verwalten, können Sie Cloud Identity oder Google Workspace mit einem externen Identitätsanbieter (Identity Provider, IdP) verbinden. Beispiele für solche externen IdPs sind Active Directory und Azure Active Directory. Das Einrichten einer Föderation umfasst in der Regel Folgendes:
- Benötigte Nutzerkonten werden automatisch aus einer externen autoritativen Quelle in Cloud Identity oder Google Workspace bereitgestellt.
- Nutzer können sich mit einem externen IdP bei Google-Diensten authentifizieren.
Identitäten zuordnen
Die Identität eines Nutzerkontos, das von Cloud Identity oder Google Workspace verwaltet wird, wird durch seine primäre E-Mail-Adresse definiert. Die primäre E-Mail-Adresse ist auf der Google-Kontoseite als E-Mail-Adresse des Google-Kontos aufgeführt. Für eine gültige primäre E-Mail-Adresse muss eine der Domains verwendet werden, die Sie Ihrem Cloud Identity- oder Google Workspace-Konto hinzugefügt haben.
Die primäre E-Mail-Adresse dient auch diesen Zwecken:
- Die primäre E-Mail-Adresse ist der Nutzername, den ein Nutzer bei der Anmeldung angeben muss. Nutzer können ihrem Google-Nutzerkonto zwar alternative E-Mail-Adressen oder Aliasse hinzufügen, diese Adressen gelten jedoch nicht als Identitäten und können nicht zur Anmeldung verwendet werden.
- Wenn ein Administrator Benachrichtigungen an Nutzer senden muss, um beispielsweise auf ein potenzielles Sicherheitsrisiko hinzuweisen, werden diese Benachrichtigungen nur an die primäre E-Mail-Adresse gesendet.
Um die Einmalanmeldung (SSO) und die automatische Nutzerverwaltung zwischen Google und Ihrem externen IdP einzurichten, müssen Sie die Identitäten in Ihrem externen IdP den entsprechenden Identitäten in Cloud Identity oder Google Workspace zuordnen. In den folgenden Abschnitten werden Best Practices zum Einrichten dieser Zuordnung beschrieben.
Verwenden Sie für alle verbundenen Systeme dieselbe Identität
Für eine Zuordnung muss lediglich geprüft werden, ob die SAML-Assertion, die der IdP an Google übergibt, einen NameID-Anspruch mit einem Wert enthält, der der primären E-Mail-Adresse eines vorhandenen Cloud Identity- oder Google Workspace-Nutzers entspricht. Der IdP kann jede Zuordnung oder Logik verwenden, um einen geeigneten NameID-Anspruch für seine vorhandenen Nutzer abzuleiten.
Viele IdPs verwenden zur Identifizierung von Nutzern E-Mail-Adressen (oder allgemeiner RFC 822-konforme Namen). Beispiele:
- Das
userPrincipalName-Attribut in Active Directory ist ein RFC 822-konformer Name, der einen Nutzer eindeutig identifiziert und für die Anmeldung in Windows oder den Active Directory Federation Services (AD FS) verwendet werden kann. - Azure Active Directory verwendet das Attribut
UserPrincipalName, um Nutzer zu identifizieren und ihnen die Anmeldung zu ermöglichen.
Wenn die Nutzer, die Ihr externer IdP verwaltet, bereits eine E-Mail-Adresse als Identität haben, können Sie diese Identität als primäre E-Mail-Adresse in Cloud Identity oder Google Workspace verwenden. Die Verwendung derselben Nutzeridentität in föderierten Systemen hat mehrere Vorteile:
Wenn sich Nutzer in einem Google-Tool wie der Google Cloud Console anmelden, werden sie als Erstes aufgefordert, die primäre E-Mail-Adresse ihres Cloud Identity- oder Google Workspace-Nutzers einzugeben, bevor sie zu Ihrem externen IdP weitergeleitet werden. Je nach IdP wird möglicherweise ein weiterer Anmeldebildschirm angezeigt, in dem der Nutzer seinen Nutzernamen und sein Passwort eingeben muss.
Wenn sich die E-Mail-Adressen für diese Schritte unterscheiden, kann die Reihenfolge der Anmeldebildschirme einen Nutzer leicht verwirren. Wenn Nutzer dagegen eine gemeinsame Identität für alle Schritte verwenden, sind sie nicht den technischen Unterschieden zwischen den IdPs ausgesetzt, wodurch eine potenzielle Verwirrung auf ein Minimum reduziert wird.
Wenn Sie keine Zuordnung zwischen Nutzeridentitäten vornehmen müssen, ist es einfacher, Audit-Logs aus Google Cloud mit Logs aus lokalen Systemen zu verknüpfen.
Wenn Anwendungen, die lokal und in Google Cloud bereitgestellt werden, Daten mit Nutzeridentitäten austauschen müssen, vermeiden Sie die komplexe Zuordnung von Nutzeridentitäten.
Ausführliche Informationen zum Zuordnen von Active Directory-Nutzern oder Azure AD-Nutzern zu Cloud Identity oder Google Workspace finden Sie im Leitfaden zu Active Directory und zu Azure AD.
Achten Sie darauf, dass Identitäten E-Mail-Adressen verwenden, die eine Weiterleitung zulassen
Google Cloud verwendet die primäre E-Mail-Adresse eines Nutzers, um Benachrichtigungs-E-Mails zuzustellen. Beispiele für solche Benachrichtigungen:
Budgetbenachrichtigungen: Wenn Sie eine Budgetbenachrichtigung konfiguriert haben, sendet Google Cloud eine Benachrichtigung an Abrechnungsadministratoren und Abrechnungsnutzer, sobald ein Budgetgrenzwert überschritten wird.
Zahlungsbenachrichtigungen: Alle Zahlungsbenachrichtigungen werden an die E-Mail-Adressen der Nutzer des Zahlungsprofils gesendet, die für das betroffene Rechnungskonto konfiguriert sind.
Projekteinladungen: Wenn Sie einem Nutzer die Rolle „Projektadministrator“ zuweisen und dieser Nutzer nicht zu dem Cloud Identity- oder Google Workspace-Konto gehört, mit dem die Organisation des Projekts verknüpft ist, wird an den Nutzer eine Einladung gesendet. Damit die neu zugewiesene Rolle wirksam werden kann, muss der Nutzer die Einladung annehmen und dafür auf einen Link in der E-Mail klicken.
Antworten auf Supportanfragen und andere Benachrichtigungen vom Support.
Wenn Sie Google Workspace verwenden und die erforderlichen DNS-MX-Einträge ordnungsgemäß konfiguriert haben, werden alle an die primäre E-Mail-Adresse gesendeten Benachrichtigungs-E-Mails dem entsprechenden Gmail-Posteingang des Nutzers zugestellt.
Google Cloud versucht auch für Cloud Identity-Nutzer, Benachrichtigungs-E-Mails zuzustellen. Diese E-Mails müssen aber von Ihrer bestehenden E-Mail-Infrastruktur verarbeitet werden. Sorgen Sie dafür, dass Ihr bestehendes E-Mail-System Nachrichten akzeptiert, die an die primären E-Mail-Adressen von Cloud Identity-Nutzern gesendet werden, und diese E-Mails an die richtigen Postfächer weiterleitet, damit Ihre Cloud Identity-Nutzer keine Benachrichtigungen verpassen. Gehen Sie dazu so vor:
Achten Sie darauf, dass alle zu Cloud Identity hinzugefügten Domains DNS-MX-Einträge haben, die auf Ihr vorhandenes E-Mail-System verweisen.
Achten Sie darauf, dass die primäre E-Mail-Adresse eines Cloud Identity-Nutzers mit einem vorhandenen Postfach in Ihrem E-Mail-System übereinstimmt. Wenn die von Cloud Identity verwendete primäre E-Mail-Adresse nicht mit der E-Mail-Adresse des Nutzers übereinstimmt, legen Sie einen Alias in Ihrem bestehenden E-Mail-System fest, damit an jede primäre E-Mail-Adresse gesendete E-Mails an das richtige Postfach weitergeleitet werden.
Wenn diese Lösungen nicht praktikabel sind, sollten Sie Google Workspace Ihrem bestehenden Cloud Identity-Konto hinzufügen und den wichtigsten Nutzern, die für die Abrechnung oder für die Kommunikation mit dem Support zuständig sind, Google Workspace-Lizenzen zuweisen. Diese Nutzer sind am ehesten Empfänger von Benachrichtigungen.
Migrationsoptionen für bestehende Privatnutzerkonten bewerten
Wenn Ihre Mitarbeiter vor der Einführung von Cloud Identity oder Google Workspace in Ihrer Organisation bereits Google-Dienste wie Google Ad Manager, Google AdSense oder Google Analytics genutzt haben, kann es sein, dass die Mitarbeiter bereits mit Privatnutzerkonten auf diese Dienste zugegriffen haben.
Die Verwendung von Privatnutzerkonten für geschäftliche Zwecke durch Mitarbeiter kann riskant sein. Weitere Informationen zu den Risiken und dazu, wie Sie vorhandene Privatnutzerkonten erkennen können, finden Sie unter Bestehende Google-Konten bewerten.
Bestehende Privatnutzerkonten können Sie folgendermaßen handhaben:
- Sie behalten die Privatnutzerkonten so wie bisher bei und nehmen potenzielle Risiken in Kauf.
- Sie migrieren die Konten zu Cloud Identity oder Google Workspace und starten dafür eine Übertragung.
- Die Inhaber der nicht verwalteten Nutzerkonten zwingen, ihre E-Mail-Adresse auf eine andere Domain zu ändern.
Weitere Informationen zum Konsolidieren vorhandener Privatnutzerkonten finden Sie unter Optionen zur Identitätskonsolidierung bewerten.
Die Art der Handhabung von Privatnutzerkonten hat Einfluss darauf, wie und in welcher Reihenfolge eine Förderation eingerichtet wird. Prüfen Sie erst die vorhandenen Privatnutzerkonten Ihrer Nutzer, bevor Sie mit dem Erstellen von Nutzerkonten oder mit dem Einrichten der Einmalanmeldung (SSO) in Cloud Identity oder Google Workspace beginnen.
Identitätssätze zuordnen
Wenn Sie festgelegt haben, wie einzelne Identitäten zwischen Ihrem externen IdP und Cloud Identity oder Google Workspace zugeordnet werden, müssen Sie den Satz von Identitäten angeben, für den der Zugriff auf Google-Dienste aktiviert werden soll.
Der effektive Satz von Identitäten, der sich gegenüber Google-Services authentifizieren kann, ist die Schnittmenge aus zwei Sätzen:
- Externe Identitäten, die in Cloud Identity oder Google Workspace einer Identität zugeordnet sind.
Externe Identitäten, die beim externen IdP zur Einmalanmeldung (SSO) bei Cloud Identity oder Google Workspace zulässig sind.
Das Verfahren zur Kontrolle, wer die Einmalanmeldung verwenden darf, unterscheidet sich je nach verwendetem IdP. Beispielsweise benötigt Azure AD Zuweisungen, während AD FS Richtlinien zur Zugriffssteuerung verwendet.
Satz von Identitäten für die Authentifizierung bei Google-Diensten beschränken
Je nachdem, wie Sie Google Cloud, Google Workspace und andere Google-Tools anwenden möchten, müssen sich entweder alle Mitarbeiter Ihrer Organisation oder nur ein Teil davon bei Google-Diensten authentifizieren können.
Wenn nur ein Teil Ihrer Mitarbeiter auf Google-Dienste zugreifen soll, ist es am besten, die Authentifizierung auf diese Nutzergruppe zu beschränken. Indem Sie die Anzahl der Nutzer einschränken, die sich authentifizieren können, schaffen Sie eine zusätzliche Sicherheitsebene, die Ihnen hilft, versehentlich zu viele Zugriffssteuerungsregeln zu konfigurieren.
Sie können die Anzahl der Nutzer, die sich bei Google authentifizieren können, so einschränken:
- Minimieren Sie die Anzahl der Nutzerkonten in Cloud Identity oder in Google Workspace. Wenn kein Nutzerkonto zugeordnet ist, schlägt die Authentifizierung durch einen Nutzer fehl, auch wenn der IdP dem Nutzer erlaubt, sich über die Einmalanmeldung (SSO) bei Cloud Identity oder Google Workspace anzumelden.
- Minimieren Sie die Anzahl der Nutzer, die sich bei Cloud Identity oder Google Workspace anmelden können, durch entsprechende Konfiguration der Einmalanmeldung (SSO) in Ihrem IdP.
Der beste Ansatz für Ihr Szenario hängt davon ab, ob Sie Privatnutzerkonten haben, die migriert werden müssen.
Bereitgestellten Satz von Identitäten bei weiter erforderlicher Migration von Privatnutzerkonten beschränken
Sie können ein Privatnutzerkonto nur dann zu Cloud Identity oder Google Workspace migrieren, wenn Sie noch kein Nutzerkonto mit der gleichen Identität in Cloud Identity oder Google Workspace erstellt haben.
Wenn Sie bereits Nutzerkonten haben, die Sie dennoch migrieren möchten, sollten Sie darauf achten, nicht versehentlich in Konflikt stehende Nutzerkonten zu erstellen. Beachten Sie folgende Richtlinien:
- Beschränken Sie die Authentifizierung und erstellen Sie neue Cloud Identity- oder Google Workspace-Nutzerkonten nur für Nutzer, die diese tatsächlich benötigen und noch kein Privatnutzerkonto haben.
- Achten Sie darauf, dass migrierte Konten nicht ungewollt gesperrt sind. Erlauben Sie deshalb die Einmalanmeldung (SSO) nicht nur für die Nutzer, für die Sie Nutzerkonten in Cloud Identity oder Workspace erstellen, sondern auch für alle Privatnutzerkonten, die noch migriert werden müssen.
Das folgende Diagramm zeigt, wie verschiedene Arten von Identitäten sich überschneiden und miteinander in Beziehung stehen.
Im Diagramm sind Identitäten mit einem Nutzerkonto in Cloud Identity oder Google Workspace in der kleinsten (gelben) Ellipse enthalten. Diese Ellipse befindet sich in der zweiten (blauen) Ellipse mit Identitäten, die authentifiziert werden können. Die dritte und größte Ellipse (pink) enthält die anderen und besteht aus den Identitäten mit einem Nutzerkonto bei Ihrem IdP. Weitere Informationen zur Konfiguration von Active Directory, Azure AD oder Okta finden Sie in unserem separaten Leitfaden mit Best Practices.
Registrierung neuer Privatnutzerkonten verhindern
Wenn Sie eine Domain wie z. B. example.com zu Ihrem Cloud Identity- oder Google Workspace-Konto hinzufügen, können sich Mitarbeiter mit dieser Domain für neue Privatnutzerkonten registrieren. Diese neuen Privatnutzerkonten werden in Ihrem Cloud Identity- oder Google Workspace-Konto als nicht verwaltete Nutzer angezeigt. Sie können dafür aber keine Einmalanmeldung und keine andere Konfiguration anwenden, die Sie in Ihrem Cloud Identity- oder Google Workspace-Konto nutzen.
Eine Möglichkeit, das Erstellen eines neuen Privatnutzerkontos zu blockieren, besteht darin, ein Nutzerkonto in Cloud Identity oder Google Workspace mit dieser E-Mail-Adresse anzulegen. Wenn Sie beispielsweise den Nutzer alice@example.com in Ihrem Cloud Identity- oder Google Workspace-Konto erstellt haben, können Mitarbeiter kein neues Privatnutzerkonto mit dieser Identität anlegen. Ist jedoch noch kein entsprechender Nutzer in Cloud Identity oder Google Workspace vorhanden, kann damit ein neues Privatnutzerkonto registriert werden.
Wenn keine weiteren Privatnutzerkonten zu Cloud Identity migriert werden sollen, lässt sich die Registrierung neuer Privatnutzerkonten mit folgender Konfiguration verhindern:
Beschränken Sie die Authentifizierung und erlauben Sie nur den erforderlichen Nutzern die Verwendung der Einmalanmeldung (SSO) für Cloud Identity oder Google Workspace.
Stellen Sie Cloud Identity- oder Google Workspace-Nutzer für alle Mitarbeiter bereit. Achten Sie darauf, dass für die Nutzerkonten die geschäftliche E-Mail-Adresse des Mitarbeiters als primäre E-Mail-Adresse oder als Alias verwendet wird, sodass keine neuen Privatnutzerkonten mit dieser E-Mail-Adresse erstellt werden können. Wenn möglich, behalten Sie Nutzerkonten, die nicht für die Einmalanmeldung (SSO) aktiviert sind, im Sperrstatus.
Das folgende Diagramm zeigt diese Konfiguration.
Wenn Sie die Migration von Privatnutzerkonten noch läuft, können Sie die Registrierung von neuen Privatnutzerkonten vorübergehend beobachten. Erfassen Sie dazu die während der Registrierung gesendeten Bestätigungs-E-Mails. Bestätigungs-E-Mails verwenden eine Envelope-Absenderadresse, die mit *@idverification.bounces.google.com übereinstimmt.
Richten Sie in Ihrem E-Mail-System einen Filter ein, der E-Mails mit dieser Envelope-Absenderadresse identifiziert und zur internen Prüfung aufbewahrt.
Cloud Identity- oder Google Workspace-Identitäten als Teilmenge der Identitäten in Ihrem externen IdP festlegen
Ihr Cloud Identity- oder Google Workspace-Konto enthält möglicherweise Nutzerkonten mit Identitäten, die keinem Nutzer Ihres externen IdP zugeordnet sind. Solche Nutzerkonten sind in der Regel in folgenden Fällen vorhanden:
- Sie haben ein neues Nutzerkonto in Cloud Identity oder Google Workspace erstellt und dafür eine primäre E-Mail-Adresse verwendet, die keinem Nutzer in Ihrem externen IdP zugeordnet ist.
- Sie haben ein Nutzerkonto in Cloud Identity oder Google Workspace erstellt, das einer Identität in Ihrem externen IdP zugeordnet wurde. Später wurde diese Identität im externen IdP aber gelöscht. So kann z. B. eine Identität gelöscht werden, wenn der entsprechende Mitarbeiter das Unternehmen verlässt.
Wenn Sie die Einmalanmeldung (SSO) in Cloud Identity oder Google Workspace aktivieren, sind alle Nutzer mit Ausnahme von Super Admins gezwungen, die Einmalanmeldung (SSO) zu verwenden. Bei einem Cloud Identity- oder Google Workspace-Nutzerkonto, das keiner Identität in Ihrem externen IdP zugeordnet ist, schlägt die Einmalanmeldung (SSO) allerdings fehl. Ein Nutzerkonto ohne ein solches Pendant ist praktisch erloschen, kann aber dennoch ein Risiko darstellen, wie beispielsweise in folgenden Situationen:
Wenn die Einmalanmeldung (SSO) irgendwann vorübergehend oder dauerhaft deaktiviert ist, kann das Nutzerkonto wieder verwendet werden. So kann sich ein ehemaliger Mitarbeiter möglicherweise anmelden und auf Unternehmensressourcen zugreifen.
Der Name des gelöschten Nutzerkontos kann wiederverwendet werden. Beispielsweise kann ein Mitarbeiter, der dem Unternehmen beitritt, denselben Namen wie ein anderer Mitarbeiter haben, der das Unternehmen Monate oder Jahre zuvor verlassen hat. Wenn das Nutzerkonto des vorherigen Mitarbeiters inzwischen gelöscht wurde, können Sie dem neuen Mitarbeiter den Nutzernamen zuweisen, den der frühere Mitarbeiter verwendet hat.
Das Nutzerkonto des neuen Mitarbeiters hat möglicherweise eine andere interne ID als die des ehemaligen Mitarbeiters. Für die Förderation gelten die beiden Nutzerkonten jedoch als identisch, wenn sie derselben primären E-Mail-Adresse in Cloud Identity oder Google Workspace zugeordnet sind. Wenn sich der neue Mitarbeiter dann bei Google anmeldet, werden möglicherweise vorhandene Daten, Einstellungen und Berechtigungen des ehemaligen Mitarbeiters übernommen.
Cloud Identity- und Google Workspace-Super Admins sind von der erforderlichen Einmalanmeldung (SSO) ausgenommen. Sie können aber die Einmalanmeldung (SSO) weiterhin verwenden, wenn die Anmeldung vom IdP initiiert wird. Die Möglichkeit, die IdP-initiierte Einmalanmeldung (SSO) zu nutzen, macht Super Admin-Nutzer anfällig für Namensblockaden, wenn in Ihrem externen IdP kein Pendant vorhanden ist.
Beispiel: Alice hat den Super-Admin-Nutzer alice-admin@example.com in Cloud Identity oder Google Workspace und verwendet nicht die Bestätigung in zwei Schritten. Karin, die das Passwort von Alice nicht kennt, findet eine Möglichkeit, einen neuen Nutzer im externen IdP zu erstellen, der alice-admin@example.com zugeordnet wird. Obwohl dieses neu erstellte Nutzerkonto möglicherweise keine besonderen Berechtigungen und keine Beziehung zum Nutzerkonto von Alice hat, kann Karin jetzt mit der Identität des Super Admin-Kontos von Alice die IDP-initiierte Einmalanmeldung (SSO) nutzen und sich als alice-admin@example.com authentifizieren.
Um dieses Risiko zu vermeiden, sollten Sie darauf achten, dass Ihre Cloud Identity- oder Google Workspace-Identitäten eine Teilmenge der Identitäten in Ihrem externen IdP sind. Dazu ordnen Sie am besten den gesamten Lebenszyklus des Nutzerkontos, der von Ihrem externen IdP implementiert wurde, dem Lebenszyklus des Nutzerkontos in Cloud Identity oder Google Workspace zu.
Verwenden Sie dedizierte Super Admin-Nutzer
Super-Admin-Konten von Google Workspace und Cloud Identity haben weitreichende Berechtigungen, die nicht nur für das Cloud Identity- oder Google Workspace-Konto gelten, sondern auch für eine damit verknüpfte Google Cloud-Organisation. Da nur wenige Aktivitäten Super-Admin-Berechtigungen erfordern, sollten Sie nach Möglichkeit die Anzahl der Administratoren mit Super-Admin-Zugriff beschränken und für die tägliche Verwaltung Ihres Kontos oder Ihrer Google Cloud-Organisation Dienstkonten mit weniger Rechten verwenden.
Wenn Sie die Administratoren ermittelt haben, die Super Admin-Zugriff benötigen, erstellen Sie dedizierte Super Admin-Nutzerkonten. Zum Beispiel:
- Erstellen Sie ein Nutzerkonto mit der Identität
alice@example.comund weisen Sie reguläre Berechtigungen zu. Dieses Konto sollte täglich für Routineaktivitäten verwendet werden. Erstellen Sie ein zweites Nutzerkonto mit der Identität
alice-admin@example.comund weisen Sie ihm Superuser-Berechtigungen zu. Es hat sich bewährt, dieses Konto nur dann zu verwenden, wenn Super Admin-Berechtigungen erforderlich sind.Konfigurieren Sie Google Workspace oder Ihr bestehendes E-Mail-System so, dass die E-Mail-Adresse
alice-admin@example.comein Alias ist oder analice@example.comweitergeleitet wird, um zu gewährleisten, dass an diese E-Mail-Adresse gesendete Benachrichtigungs-E-Mails im Postfach des Nutzers eingehen.
Sorgen Sie dafür, dass beide Identitäten von Ihrem externen IdP erkannt werden und dass der Satz von Identitäten in Cloud Identity oder Google Workspace weiterhin eine Teilmenge der Identitäten in Ihrem externen IdP ist.
Wir empfehlen, für diese dedizierten Super Admin-Konten ein festes Benennungsschema zu verwenden, damit Sie in Audit-Logs einfacher prüfen können, wo und wie sie verwendet werden. Fügen Sie dem Nutzernamen beispielsweise wie im vorherigen Beispiel -admin hinzu.
Anzahl der Dienstnutzer in Google Workspace und Cloud Identity beschränken
Ihr externer IdP enthält möglicherweise nicht nur Nutzerkonten für Mitarbeiter, sondern auch für Computernutzer wie Anwendungen, Tools oder Hintergrundjobs.
Im Gegensatz dazu ist der bevorzugte Weg in der Google Cloud, einer Anwendung die Authentifizierung und den Zugriff auf Google APIs zu ermöglichen, die Implementierung eines der folgenden Ansätze:
Eine Webanwendung oder ein Tool, das im Namen eines Endnutzers auf Google APIs oder Dienste zugreifen muss, sollte entweder OAuth 2.0 oder OpenID Connect verwenden. Durch die Verwendung eines dieser Protokolle fordert die Anwendung zuerst die Zustimmung des Endnutzers an, um auf die Daten des Nutzers zuzugreifen, und kann dann den Zugriff im Namen des Endnutzers ausführen.
Wenn der Zugriff auf APIs oder Dienste nicht im Namen eines Endnutzers, sondern im Namen der Anwendung selbst erfolgen soll, sollten Sie Google Cloud-Dienstkonten zur Authentifizierung verwenden und dann dem Dienstkonto Zugriff auf die Ressourcen gewähren (mithilfe von IAM).
Wurden Google Cloud-Dienstkonten die entsprechenden Rollen in IAM zugewiesen, können sie für die Authentifizierung und Verwendung einer beliebigen Cloud API genutzt werden. Wenn Sie einem Dienstkonto Zugriff auf APIs außerhalb von Google Cloud gewähren möchten, z. B. auf die Directory API oder die Drive API, können Sie dafür die domainweite Delegierung von Google Workspace verwenden.
Die domainweite Delegierung von Google Workspace bietet einem Dienstkonto die Möglichkeit, im Namen eines Cloud Identity- oder Google Workspace-Nutzers zu agieren. Da die Delegierung weitreichende Berechtigungen gewährt, sollten Sie die domainweite Google Workspace-Delegierung nur dann verwenden, wenn der OAuth-Ansatz nicht praktikabel ist.
Verwenden Sie für jedes Google Cloud-Dienstkonto, das für die domainweite Google Workspace-Delegierung aktiviert ist, einen dedizierten Cloud Identity- oder Google Workspace-Nutzer. Erstellen Sie diesen Nutzer bei Ihrem externen IdP und stellen Sie ihn dann für Cloud Identity oder Google Workspace bereit, damit die Gruppe von Nutzern in Cloud Identity oder Google Workspace weiterhin eine Teilmenge der Nutzer in Ihrem externen IdP bildet.
Sie sollten dabei in Cloud Identity und Google Workspace nur Dienstnutzer anlegen, die Sie für die domainweite Google Workspace-Delegierung verwenden möchten.
Lebenszyklus von Nutzerkonten zuordnen
Die Nutzerkonten in Ihrem externen IdP unterliegen einem bestimmten Lebenszyklus. In der Regel spiegelt dieser Lebenszyklus das Beschäftigungsverhältnis zwischen dem Mitarbeiter und dem Unternehmen wider:
- Für einen Mitarbeiter, der der Organisation beitritt, wird ein neues Nutzerkonto erstellt.
- Das Nutzerkonto kann vorübergehend gesperrt und später wieder aktiviert werden, z. B. wenn der Mitarbeiter in den Urlaub geht.
- Wenn der Nutzer das Unternehmen verlässt, wird das Nutzerkonto entweder gelöscht oder für eine bestimmte Aufbewahrungsdauer gesperrt, bevor es endgültig gelöscht wird.
Das folgende Diagramm veranschaulicht diesen Lebenszyklus.
In diesem Abschnitt sind Best Practices aufgeführt, mit denen gewährleistet werden kann, dass der Lebenszyklus von Nutzerkonten in Cloud Identity oder Google Workspace dem Lebenszyklus der entsprechenden Nutzerkonten bei Ihrem externen IdP entspricht.
Externen IdP als „Source of Truth“ festlegen
Viele Personalverwaltungssysteme (HRIS), IdPs und Adapter unterstützen die Nutzerverwaltung nur in einer Richtung. Im HRIS oder IdP ausgeführte Änderungen werden nach Cloud Identity oder Google Workspace übertragen, in Cloud Identity oder Google Workspace ausgeführte Änderungen werden jedoch nicht zurückübertragen.
Um Inkonsistenzen aufgrund der unidirektionalen Bereitstellung zu vermeiden, legen Sie Ihren externen IdP als „Source of Truth“ fest. Verwenden Sie dann ausschließlich Ihren externen IdP (oder das HRIS), um Nutzer zu erstellen, zu ändern oder zu löschen, und nutzen Sie die automatische Bereitstellung, um Änderungen an Google Workspace und Cloud Identity weiterzugeben. Durch Festlegen einer „Source of Truth“ begrenzen Sie das Risiko von Inkonsistenzen und manuellen Änderungen, die vom IdP überschrieben werden.
Nutzerverwaltung für Cloud Identity oder Google Workspace automatisieren
Damit sich ein Mitarbeiter über die Einmalanmeldung (SSO) bei Google authentifizieren kann, müssen Sie für ihn ein Nutzerkonto in Cloud Identity oder Google Workspace erstellen. Damit Konsistenz mit Ihrem externen IdP gewährleistet ist, sollten Sie die Bereitstellung dieser Nutzerkonten in Cloud Identity oder Google Workspace automatisieren:
- Die Automatisierung der Bereitstellung sorgt dafür, dass Cloud Identity- oder Google Workspace-Identitäten immer eine Teilmenge der Identitäten in Ihrem externen IdP sind.
- Damit minimieren Sie das Risiko einer ungewollt auftretenden Differenz zwischen einer Identität in Cloud Identity oder Google Workspace und der entsprechenden Identität in Ihrem externen IdP. Die fehlende Übereinstimmung, z. B. aufgrund eines Tippfehlers in der E-Mail-Adresse, kann zu Problemen bei der Anmeldung führen.
- Sie minimieren damit auch den manuellen Verwaltungsaufwand.
Wenn Sie das Onboarding mit einem Personalverwaltungssystem (HRIS) ausführen, ist eine Möglichkeit, die Nutzerverwaltung zu automatisieren, die entsprechende Konfiguration von HRIS. Nutzerkonten werden damit, wie im folgenden Diagramm dargestellt, sowohl für Ihren externen IdP als auch für Cloud Identity oder Google Workspace bereitgestellt.
Damit diese Einrichtung funktioniert, müssen Sie dafür sorgen, dass Ihr Personalverwaltungssystem Nutzerkonten bereitstellt, damit diese korrekt zugeordnet werden. Außerdem muss das HRIS festlegen, welche Nutzerkonten für Cloud Identity oder Google Workspace bereitgestellt werden sollen.
Eine andere, von einem HRIS unabhängige Möglichkeit zur Automatisierung ist die Verwendung Ihres externen IdP als autoritative Quelle für die Nutzerverwaltung in Cloud Identity oder Google Workspace. Mit einer solchen Einrichtung wird die Konfiguration zum Zuordnen von Nutzerkonten und Nutzerkontosätzen vom IdP oder vom Adapter verwaltet, wie das folgende Diagramm veranschaulicht.
Wenn Sie Active Directory als IdP verwenden, können Sie diese Einrichtung mit Google Cloud Directory Sync duplizieren. Andere IdPs wie Azure AD oder Okta haben integrierte Adapter für die Nutzerverwaltung in Google Workspace. Da Google Workspace und Cloud Identity auf einer Plattform basieren und die gleichen APIs verwenden, können diese Adapter auch für Cloud Identity genutzt werden.
Sperrereignisse an Cloud Identity oder Google Workspace weitergeben
Wenn ein Mitarbeiter die Organisation vorübergehend oder dauerhaft verlässt, sollte dessen Zugriff auf Google-Dienste aufgehoben werden. Indem Sie das Nutzerkonto des Mitarbeiters in Ihrem externen IdP sperren, entziehen Sie ihm die Möglichkeit, sich bei Google mit der Einmalanmeldung (SSO) zu authentifizieren. Aber dadurch wird der Zugriff auf alle Google-Dienste möglicherweise nicht vollständig entzogen. Dennoch kann Folgendes weiter auftreten:
- Wenn für den Cloud Identity- oder Google Workspace-Nutzer eine Browsersitzung aktiv ist, läuft die Sitzung weiter. Alle bereits abgerufenen OAuth-Tokens sind weiterhin gültig.
- Wenn der Nutzer Super Admin-Berechtigungen hat oder wenn Sie Netzwerkmasken konfiguriert haben, kann sich der Mitarbeiter möglicherweise weiterhin mit einem Passwort anmelden.
- Das Nutzerkonto erhält möglicherweise weiterhin Benachrichtigungen von Google Cloud, einschließlich Budgetbenachrichtigungen.
- Wenn der Nutzer eine Google Workspace-Lizenz hat, werden seinem Postfach weiterhin E-Mails zugestellt, er ist weiterhin im Adressbuch enthalten und er wird gegebenenfalls auch weiterhin in Google Kalender als verfügbar angezeigt.
- Wenn Sie Nutzern erlauben, weniger sichere Anwendungen zu verwenden, kann der Nutzer möglicherweise weiterhin über Anwendungspasswörter auf Gmail, Google Kalender und andere Daten zugreifen.
Wenn Sie deshalb den Zugriff auf Google-Dienste vollständig widerrufen möchten, können Sie so Sperrereignisse an Cloud Identity oder Google Workspace weitergeben:
Sorgen Sie dafür, dass bei jeder Sperrung eines Nutzerkontos in Ihrem externen IdP auch das entsprechende Nutzerkonto in Cloud Identity oder Google Workspace gesperrt wird. Wenn Sie einen Nutzer in Cloud Identity oder Google Workspace sperren, werden aktive Browsersitzungen beendet, Tokens ungültig und alle anderen Zugriffsberechtigungen widerrufen.
Wenn Sie ein Nutzerkonto bei Ihrem externen IdP wieder reaktivieren, müssen Sie dann auch das entsprechende Nutzerkonto in Cloud Identity oder Google Workspace reaktivieren.
Durch das Sperren eines Nutzerkontos in Cloud Identity oder Google Workspace werden weder Daten, noch Lizenzen und Rollen gelöscht. Solange das Nutzerkonto gesperrt ist, bleiben die Daten des Nutzers erhalten, Google Workspace-Lizenzen angehängt und zugewiesene Rollen in Google Cloud unverändert.
Löschereignisse an Cloud Identity oder Google Workspace weitergeben
Wenn ein Mitarbeiter die Organisation dauerhaft verlässt, können Sie das Nutzerkonto des Mitarbeiters bei Ihrem externen IdP nicht nur sperren, sondern auch löschen.
Wenn Sie ein Nutzerkonto bei Ihrem externen IdP löschen, aber nicht den entsprechenden Cloud Identity- oder Google Workspace-Nutzer, ist die Gruppe der Nutzer in Cloud Identity und Google Workspace keine Teilmenge der Nutzer mehr in Ihrem externen IdP. Dies kann zukünftig zu einem Problem werden, z. B. wenn ein neuer Mitarbeiter in Ihre Organisation aufgenommen wird, der den gleichen Namen wie der ausscheidende Mitarbeiter hat. Wenn Sie dann in Ihrem IdP ein Nutzerkonto für den neuen Mitarbeiter erstellen, wird möglicherweise der Nutzername des ehemaligen Mitarbeiters wiederverwendet und das neue Nutzerkonto dem alten Nutzerkonto in Cloud Identity oder Google Workspace zugeordnet. Dadurch erhält der neue Mitarbeiter aber eventuell Zugriff auf die Daten und Einstellungen des alten Mitarbeiters.
Sie können die mit verwaisten Cloud Identity- oder Google Workspace-Nutzerkonten verbundenen Risiken vermeiden, wenn Sie den Cloud Identity- oder Google Workspace-Nutzer löschen, sobald das entsprechende Nutzerkonto in Ihrem IdP gelöscht wird.
Das Entfernen eines Cloud Identity- oder Google Workspace-Nutzers ist ein Vorgang mit Löscheffekt, der nur innerhalb eines bestimmten Zeitraums rückgängig gemacht werden kann. Je nach den vom Nutzer verwendeten Google-Diensten kann sein Entfernen dazu führen, dass die zugehörigen Daten endgültig gelöscht werden. Dies kollidiert möglicherweise mit Ihren Complianceanforderungen.
Wenn Sie die Einstellungen und Daten des Nutzers für einen bestimmten Zeitraum aufbewahren möchten, bevor sie endgültig gelöscht werden, führen Sie einen der folgenden Schritte aus:
Verzögern Sie das Löschen des Nutzerkontos bei Ihrem externen IdP und belassen Sie den Nutzer für eine bestimmte Aufbewahrungsdauer im gesperrten Status. Löschen Sie dann nach Ablauf der Aufbewahrungsdauer den Nutzer sowohl bei Ihrem IdP als auch in Cloud Identity oder Google Workspace.
Wenn Sie ein Nutzerkonto bei Ihrem externen IdP löschen, sollten Sie den entsprechenden Cloud Identity- oder Google Workspace-Nutzer sperren und seine primäre E-Mail-Adresse so ändern, dass ein Konflikt weitgehend ausgeschlossen ist. Benennen Sie beispielsweise
alice@example.cominobsolete-yyyymmdd-alice@example.comum, wobeiyyyymmdddas Datum des Löschvorgangs bei Ihrem externen IdP ist. Lassen Sie das umbenannte Nutzerkonto für einen Aufbewahrungszeitraum gesperrt und löschen Sie es nach Ablauf des Aufbewahrungszeitraums.
Wenn Sie Google Workspace-Daten für gesperrte Nutzer beibehalten möchten, übernehmen Sie entweder die dem Nutzer zugewiesene Google Workspace-Lizenz oder ändern sie in eine Lizenz für archivierte Nutzer, damit die Aufbewahrungsregeln für Google Workspace Vault weiterhin gültig sind und die Daten des Nutzers erhalten bleiben.
Einmalanmeldung (SSO)
Alle Google-Produkte, einschließlich Diensten wie Google Cloud, Google Ads und YouTube, verwenden Google Log-in, um Nutzer zu authentifizieren. Ein Dienst initiiert den Authentifizierungsprozess und leitet dafür den Nutzer zu accounts.google.com weiter. Der Nutzer wird dann im Google-Anmeldebildschirm nach seiner E-Mail-Adresse gefragt. Abhängig von der Domain der angegebenen E-Mail-Adresse wird das Nutzerkonto dann in Gmail, im Verzeichnis des Privatnutzerkontos oder, falls die Domain mit der primären, sekundären oder Alias-Domain übereinstimmt, in einem Cloud Identity- oder Google Workspace-Konto gesucht.
Das folgende Diagramm veranschaulicht diesen Authentifizierungsprozess.
Wenn Sie ein Cloud Identity- oder Google Workspace-Konto für die Verwendung der Einmalanmeldung (SSO) konfigurieren, werden Nutzer zur Authentifizierung an einen externen IdP weitergeleitet. Wenn der externe IdP die Authentifizierung abgeschlossen hat, wird das Ergebnis mithilfe einer SAML-Assertion an Google Log-in zurückgesendet. Diese SAML-Assertion dient als Nachweis für eine erfolgreiche Authentifizierung. Die Assertion enthält die E-Mail-Adresse des Nutzers und wird vom Zertifikat des externen Identitätsanbieters signiert, damit Google Log-in seine Authentizität prüfen kann.
Dieser Vorgang wird als vom Dienstanbieter initiierte Einmalanmeldung (SSO) bezeichnet und gilt für alle Nutzer außer Super Admins. Super Admins werden nie zu einem externen IdP weitergeleitet und werden stattdessen zur Eingabe eines Passworts aufgefordert.
Einige IdPs unterstützen auch die vom IdP initiierte Einmalanmeldung (SSO). In diesem Modell authentifiziert sich der Nutzer beim externen IdP und folgt dann einem Link, der auf einen Google-Dienst wie Google Cloud oder Google Ads verweist. Wenn die Einmalanmeldung (SSO) für ein Cloud Identity- oder Google Workspace-Konto aktiviert wurde, können alle Nutzer dieses Kontos die vom IdP initiierte Einmalanmeldung (SSO) verwenden, auch Super Admins.
Umfang der in SAML-Assertions übergebenen Attribute minimieren
Nachdem sich ein Nutzer beim externen IdP authentifiziert hat, verwenden Cloud Identity oder Google Workspace die vom externen IdP übergebene SAML-Assertion, um eine Sitzung einzurichten. Dabei wird nicht nur die Authentizität geprüft, sondern auch das Cloud Identity- oder Google Workspace-Nutzerkonto ermittelt, das dem Wert für NameID in der SAML-Assertion entspricht.
Der Wert für NameID muss die primäre E-Mail-Adresse des Nutzerkontos enthalten, das authentifiziert werden soll. Bei der E-Mail-Adresse wird zwischen Groß- und Kleinschreibung unterschieden. Aliasse und alternative E-Mail-Adressen werden nicht berücksichtigt.
Um versehentliche Rechtschreib- oder Groß- und Kleinschreibefehler zu vermeiden, sollten Sie Nutzerkonten automatisch bereitstellen.
SAML-Assertions können zusätzliche Attribute enthalten, die aber bei der Authentifizierung nicht berücksichtigt werden. Attribute, die Informationen wie den Vor- und Nachnamen oder die Gruppenmitgliedschaft eines Nutzers enthalten, werden ignoriert. Für solche Nutzerinformationen ist das Nutzerkonto in Cloud Identity oder Google Workspace die alleinige Quelle.
Konfigurieren Sie Ihren IdP so, dass keine Attribute enthalten sind, die für die Google-Anmeldung nicht erforderlich sind, um die Größe von SAML-Assertions zu minimieren.
Verwenden Sie google.com als Aussteller
Google Log-in-Sitzungen sind nicht auf ein einzelnes Tool oder eine einzelne Domain beschränkt. Stattdessen gilt die Sitzung nach der Einrichtung für alle Google-Dienste, für die dem Nutzer der Zugriff gewährt wurde. Diese Liste umfasst möglicherweise Dienste wie Google Cloud und Google Ads sowie Dienste wie die Google-Suche und YouTube.
Der globale Charakter einer Sitzung spiegelt sich im SAML-Protokollaustausch wider: Google verwendet standardmäßig google.com als Aussteller (das Issuer-Element in der SAML-Anfrage) in SAML-Anfragen und erwartet, dass SAML-Assertions google.com als Zielgruppe (das Audience-Element in der SAML-Antwort) festlegen.
Sie können diese Standardeinstellung ändern und dazu bei der Konfiguration der Einmalanmeldung (SSO) in Cloud Identity oder Google Workspace die Option Domainspezifischen Aussteller verwenden aktivieren. Aktivieren Sie die Option für domainspezifische Aussteller nur, wenn Sie mehr als ein Cloud Identity- oder Google Workspace-Konto (und somit mehrere Domains) haben und Ihr IdP in der Lage sein muss, zwischen Anmeldungen, die von einem Cloud Identity- oder Google Workspace-Konto initiiert wurden, und Anmeldungen, die von einem anderen Konto initiiert wurden, zu unterscheiden. Wenn Sie diese Option aktivieren, verwenden SAML-Anfragen google.com/a/DOMAIN als Aussteller und erwarten google.com/a/DOMAIN als Zielgruppe, wobei DOMAIN die primäre Domain des Cloud Identity- oder Google Workspace-Kontos ist.
Übernehmen Sie in allen anderen Fällen die Standardeinstellung der Verwendung von google.com als Aussteller und konfigurieren Sie Ihren externen IdP so, dass google.com als Zielgruppe in SAML-Assertions festgelegt wird. Je nach IdP wird diese Einstellung auch als Aussteller, Vertrauenskennung der vertrauenswürdigen Partei oder Entitäts-ID bezeichnet.
Länge von Google-Sitzungen und IdP-Sitzungen abstimmen
Wenn ein Nutzer die Einmalanmeldung (SSO) abgeschlossen hat und eine Sitzung eingerichtet wurde, bleibt die Google Log-in-Sitzung für einen bestimmten Zeitraum aktiv. Nach Ablauf dieses Zeitraums oder wenn sich der Nutzer abmeldet, wird dieser aufgefordert, sich noch einmal zu authentifizieren, indem er die Einmalanmeldung wiederholt.
Die Standardeinstellung für die Sitzungsdauer in Google-Diensten ist 14 Tage. Für Nutzer mit einer Cloud Identity Premium- oder Google Workspace Business-Lizenz können Sie die Standardsitzungsdauer ändern, z. B. auf 8 Stunden.
Sie können die von Google Cloud verwendete Sitzungsdauer steuern. Die Google Cloud-Sitzung gilt sowohl für die Google Cloud Console als auch für die Google Cloud CLI und andere API-Clients. Sie können die Google Cloud-Sitzungsdauer für alle Kontotypen von Cloud Identity und Google Workspace festlegen.
Die meisten externen IdPs unterhalten auch Sitzungen für authentifizierte Nutzer. Wenn die IdP-Sitzung länger als die Google-Sitzung dauert, kann die erneute Authentifizierung im Hintergrund erfolgen. Das heißt, der Nutzer wird an den IdP weitergeleitet, muss aber möglicherweise nicht noch einmal Anmeldedaten eingeben. Die stille erneute Authentifizierung untergräbt möglicherweise den Zweck, die Dauer von Google-Sitzungen zu verkürzen.
Um sicherzustellen, dass Nutzer ihre Anmeldedaten nach Ablauf einer Google-Sitzung noch einmal eingeben müssen, konfigurieren Sie die Länge der Google-Sitzung und der IdP-Sitzung so, dass die Länge der IdP-Sitzung kürzer ist als die der Google-Sitzung.
Einmalanmeldung für Super Admin-Nutzer deaktivieren
Für Super Admin-Nutzer ist SSO optional: Sie können SSO verwenden, wenn die Anmeldung vom IdP initiiert wird. Sie können sich aber auch mit Nutzername und Passwort anmelden.
Wenn Sie nicht die vom IdP initiierte Einmalanmeldung (SSO) für Super Admin-Nutzer verwenden möchten, können Sie das Risiko folgendermaßen reduzieren:
- Fügen Sie eine dedizierte Organisationseinheit für Super Admins hinzu.
- Weisen Sie der Organisationseinheit ein SSO-Profil zu, für das die Einmalanmeldung deaktiviert ist.
Wenn Sie die vom IdP initiierte Einmalanmeldung (SSO) verwenden möchten, müssen Sie andernfalls die Post-SSO-Prüfung für Super Admin-Nutzer erzwingen.
Multi-Faktor-Authentifizierung
Die Aktivierung der Einmalanmeldung (SSO) zwischen Cloud Identity oder Google Workspace und Ihrem externen IdP optimiert die Bedienung für Ihre Mitarbeiter. Nutzer müssen sich damit weniger häufig authentifizieren und keine eigenen Anmeldedaten merken, um auf Google-Dienste zuzugreifen.
Wenn sich Nutzer nahtlos über Dienste und Umgebungen hinweg authentifizieren können, erhöht dies jedoch auch die potenziellen Auswirkungen gehackter Nutzeranmeldedaten. Wenn der Nutzername und das Passwort eines Nutzers verloren gehen oder gestohlen werden, kann ein Angreifer diese Anmeldedaten verwenden, um nicht nur auf Ressourcen in Ihrer vorhandenen Umgebung, sondern auch auf einen oder mehrere Google-Dienste zuzugreifen.
Um das Risiko von Anmeldedatendiebstahl zu verringern, empfiehlt es sich, die Multi-Faktor-Authentifizierung für alle Nutzerkonten zu verwenden.
Multi-Faktor-Authentifizierung für Nutzer erzwingen
Wenn Sie die Einmalanmeldung (SSO) für Ihr Cloud Identity- oder Google Workspace-Konto konfiguriert haben, müssen sich Nutzer ohne Super-Admin-Berechtigung über Ihren externen IdP zur Authentifizierung anmelden.
Konfigurieren Sie Ihren IdP so, dass er die Verwendung eines zweiten Faktors (z. B. eines Einmal-Codes oder eines USB-Schlüssels) erfordert, um die Verwendung der Multi-Faktor-Authentifizierung zu erzwingen, sobald bei Google die Einmalanmeldung zur Anwendung kommt.
Wenn Ihr externer IdP die Multi-Faktor-Authentifizierung nicht unterstützt, sollten Sie die Post-SSO-Prüfung erwägen, damit Google eine zusätzliche Prüfung durchführt, nachdem der Nutzer von der Authentifizierung bei Ihrem externen IdP zurückkehrt.
Vermeiden Sie die Verwendung von Netzwerkmasken, da diese missbraucht werden können, um die Multi-Faktor-Authentifizierung für Nutzer zu umgehen.
Google-Authentifizierung in zwei Schritten für Super Admin erzwingen
Super Admin werden nicht an Ihren externen IdP weitergeleitet, wenn sie versuchen, sich in der Google Cloud Console oder auf anderen Google-Websites anzumelden. Stattdessen werden Super Admin dazu aufgefordert, sich über ihren Nutzernamen und ihr Passwort zu authentifizieren.
Da Super Admin sich mit Nutzername und Passwort authentifizieren können, unterliegen sie nicht den Richtlinien für die Multi-Faktor-Authentifizierung, die Ihr IdP möglicherweise erzwingt. Um Super Admin zu schützen, erzwingen Sie die Google-Authentifizierung in zwei Schritten für alle Super Admin-Nutzer.
Super-Admin-Nutzer fallen normalerweise in eine von zwei Kategorien:
Personalisierte Super-Admin-Nutzer: Diese Nutzer sind personalisiert und für die Verwendung durch einen einzelnen Administrator vorgesehen. Wir empfehlen, die Bestätigung in zwei Schritten für alle personalisierten Super-Admin-Nutzer zu erzwingen.
Computer-Super-Admin-Nutzer: Solche Nutzerkonten sollten vermieden werden. Sie sind aber manchmal notwendig, um Tools wie Cloud Directory Sync oder Azure AD Gallery App zur Verwaltung von Nutzern und Gruppen in Cloud Identity oder Google Workspace zu aktivieren.
Begrenzen Sie die Anzahl der Computer-Super-Admin-Nutzer und versuchen Sie nach Möglichkeit, die Bestätigung in zwei Schritten zu aktivieren.
Für Nutzer, die die Einmalanmeldung nicht verwenden, können Sie die zweistufige Authentifizierung global, nach Organisationseinheit oder nach Gruppe erzwingen:
Wenn Sie keine Computer-Super-Admin-Nutzer haben, die die Bestätigung in zwei Schritten nicht verwenden können, sollten Sie die Erzwingung für alle Nutzer aktivieren. Wenn Sie die Bestätigung in zwei Schritten für alle Nutzer durchsetzen, vermeiden Sie das Risiko, versehentlich Nutzer auszulassen.
Wenn Sie einige Computer-Super-Admin-Nutzer haben, die die Bestätigung in zwei Schritten nicht verwenden können, verwenden Sie eine dedizierte Gruppe, um die Bestätigung in zwei Schritten zu steuern. Erstellen Sie eine neue Gruppe, aktivieren Sie die Erzwingung für diese und fügen Sie ihr alle relevanten Superuser hinzu.
Weitere Informationen zur Verwendung der zweistufigen Authentifizierung zum Schutz von Super Admin finden Sie in unseren Best Practices für die Sicherheit von Administratorkonten.
Identitätsbestätigung nach der Einmalanmeldung für Super Admin erzwingen
Auch wenn es nicht erforderlich ist, dass Super Admins die Einmalanmeldung (SSO) verwenden, können diese die Einmalanmeldung (SSO) verwenden, wenn sie vom IdP initiiert wird. Aktivieren Sie die zusätzlichen SSO-Bestätigungen und die Bestätigung in zwei Schritten für alle Super Admins, damit diese immer der Bestätigung in zwei Schritten unterliegen, selbst wenn sie sich durch eine IdP-initiierte Anmeldung authentifizieren.
Die zusätzlichen SSO-Bestätigungen können redundant erscheinen, wenn Ihr IdP bereits eine Multi-Faktor-Authentifizierung erzwingt. Mit dieser Einstellung können Sie jedoch Super Admin schützen, falls Ihr IdP gehackt wird.
Beschränken Sie die Einmalanmeldung nicht nach Netzwerkmaske
Wenn Sie die Einmalanmeldung (SSO) für Cloud Identity oder Google Workspace konfigurieren, können Sie optional eine Netzwerkmaske angeben. Wenn Sie eine solche Maske festlegen, gilt die Einmalanmeldung (SSO) nur für Nutzer, deren IP-Adressen mit der Maske übereinstimmen. Andere Nutzer werden bei der Anmeldung zur Eingabe eines Passworts aufgefordert.
Wenn Sie Netzwerkmasken verwenden, untergraben Sie möglicherweise die Multi-Faktor-Authentifizierung, die von Ihrem externen IdP erzwungen wird. Beispielsweise kann ein Nutzer durch Ändern des Standorts oder durch Verwendung eines VPN steuern, ob die Netzwerkmaske angewendet wird oder nicht. Wenn Sie die Multi-Faktor-Authentifizierung beim externen IdP erzwingen, können Nutzer oder Angreifer mit dieser Taktik die beim externen IdP konfigurierten Multi-Faktor-Authentifizierungsrichtlinien möglicherweise umgehen.
Sie sollten die Einmalanmeldung nicht durch eine Netzwerkmaske einschränken, um sicherzustellen, dass die Multi-Faktor-Authentifizierung unabhängig vom Standort oder der IP-Adresse eines Nutzers konsistent angewendet wird.
Wenn Sie den Zugriff auf Ressourcen nach IP-Adresse einschränken möchten, konfigurieren Sie entweder eine entsprechende Liste zugelassener IP-Adressen bei Ihrem externen IdP oder verwenden Sie den kontextsensitiven Zugriff für Google Cloud und Google Workspace.
Nächste Schritte
- Mehr über Best Practices erfahren:
- Vergleichen Sie Muster für die Verbindung eines externen IdP mit Google Cloud.