Best Practices für die Föderation von Google Cloud mit einem externen Identitätsanbieter

In diesem Dokument werden Best Practices und Anleitungen vorgestellt, die Sie bei der konsistenten und sicheren Einrichtung einer Föderation unterstützen. Die Anleitung basiert auf den Best Practices für die Verwendung von Cloud Identity oder der G Suite mit Google Cloud.

Alle Google-Dienste, einschließlich Google Cloud, Google Marketing Platform und Google Ads, basieren auf dem Google Log-in zur Authentifizierung von Nutzern. Anstatt für jeden Mitarbeiter Nutzerkonten in Cloud Identity oder G Suite manuell zu erstellen und zu verwalten, können Sie Cloud Identity oder die G Suite mit Ihrem externen Identitätsanbieter (IdP) wie Active Directory oder Azure Active Directory verbinden. Das Einrichten einer Föderation umfasst in der Regel Folgendes:

  • Automatische Bereitstellung relevanter Nutzerkonten aus einer externen, verbindlichen Quelle für Cloud Identity oder die G Suite.
  • Nutzer können sich mit einem externen IdP bei Google-Diensten authentifizieren.

Zuordnen von Identitäten

Die Identität eines Nutzerkontos, das von Cloud Identity oder der G Suite verwaltet wird, wird durch seine primäre E-Mail-Adresse definiert. Die primäre E-Mail-Adresse wird auf der Google-Kontoseite als E-Mail-Adresse des Google-Kontos aufgeführt. Um als gültig zu gelten, muss die primäre E-Mail-Adresse eine der Domains verwenden, die Sie Ihrem Cloud Identity- oder G Suite-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 ein potenzielles Sicherheitsrisiko anzukündigen, 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 Identitäten in Ihrem externen IdP den entsprechenden Identitäten in Cloud Identity oder der G Suite zuordnen. In den folgenden Abschnitten werden Best Practices zum Einrichten dieser Zuordnung beschrieben.

Verwenden Sie für alle föderierten Systeme dieselbe Identität

Um eine Zuordnung herzustellen, muss lediglich überprüft werden, ob die SAML-Assertion, die der IdP an Google liefert, einen NameID-Anspruch mit einem Wert enthält, der mit der primären E-Mail-Adresse eines vorhandenen Cloud Identity- oder G Suite-Nutzers übereinstimmt. 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 verwenden, können Sie dieselbe Identität als primäre E-Mail-Adresse in Cloud Identity oder der G Suite verwenden. Die Verwendung derselben Nutzeridentität in föderierten Systemen hat mehrere Vorteile:

  • Wenn sich Nutzer in einem Google-Tool wie der Cloud Console anmelden, werden sie zuerst aufgefordert, die primäre E-Mail-Adresse ihres Cloud Identity- oder G Suite-Nutzers anzugeben, bevor sie zu Ihrem externen IdP weitergeleitet werden. Je nach IdP wird dem Nutzer möglicherweise ein weiterer Anmeldebildschirm angezeigt, in dem er 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.

Weitere Informationen zum Zuordnen von Active Directory-Nutzern oder Azure AD-Nutzern zu Cloud Identity oder der G Suite finden Sie im Leitfaden zu Active Directory oder 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, der zu einem anderen Cloud Identity- oder G Suite-Konto gehört als das, mit dem die Organisation des Projekts verknüpft ist, wird eine Einladung an den Nutzer gesendet. Bevor die neu zugeteilte Rolle wirksam werden kann, muss der Nutzer die Einladung annehmen, indem er auf einen Link in der E-Mail klickt.

  • Antworten auf Supportanfragen und andere Benachrichtigungen vom Support.

Wenn Sie die G Suite verwenden und die erforderlichen DNS-MX-Einträge ordnungsgemäß konfiguriert haben, werden alle an die primäre E-Mail-Adresse gesendeten Benachrichtigungs-E-Mails an den Gmail-Posteingang des entsprechenden Nutzers zugestellt.

Auch für Cloud Identity-Nutzer versucht Google Cloud, Benachrichtigungs-E-Mails zuzustellen, aber die E-Mails müssen von Ihrer vorhandenen 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 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 Ihrem bestehenden Cloud Identity-Konto die G Suite hinzufügen und den wichtigsten Nutzern, die für die Abrechnung oder Interaktion mit dem Support zuständig sind, G Suite-Lizenzen zuweisen. Diese Nutzer erhalten am ehesten Benachrichtigungen.

Migrationsoptionen für bestehende Privatnutzerkonten bewerten

Wenn Ihre Mitarbeiter Google-Dienste wie Google Ad Manager, Google AdSense oder Google Analytics genutzt haben, bevor sich Ihre Organisation für Cloud Identity oder die G Suite entschieden hat, haben Ihre Mitarbeiter möglicherweise bereits mit Privatnutzerkonten auf diese Dienste zugegriffen.

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:

  • Die Privatnutzerkonten so behalten, wie sie sind, und potenzielle Risiken in Kauf nehmen.
  • Die Konten durch eine Übertragung zu Cloud Identity oder zur G Suite migrieren.
  • 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 Entscheidung für den Umgang mit Privatnutzerkonten hat Einfluss darauf, wie und in welcher Reihenfolge Sie eine Verbindung erstellen. Bewerten Sie vorhandene Nutzerkonten, bevor Sie mit der Erstellung von Nutzerkonten oder der Einrichtung der Einmalanmeldung (SSO) in Cloud Identity oder der G Suite beginnen.

Identitätssätze zuordnen

Wenn Sie festgelegt haben, wie einzelne Identitäten zwischen Ihrem externen IdP und Cloud Identity oder der G Suite zugeordnet werden, müssen Sie den Satz von Identitäten festlegen, 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:

  1. Externe Identitäten, die einer Identität in Cloud Identity oder der G Suite zugeordnet sind.
  2. Externe Identitäten, die Ihr externer IdP für die Einmalanmeldung (SSO) in Cloud Identity oder in der G Suite zulässt.

    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.

Beschränken Sie den Satz von Identitäten, die sich bei Google-Diensten authentifizieren können

Je nachdem, wie Sie Google Cloud, die G Suite und andere Google-Tools verwenden möchten, müssen sich entweder alle Mitarbeiter Ihrer Organisation oder nur ein Teil davon bei Google-Diensten authentifizieren können.

Wenn Sie nur einem Teil der Mitarbeiter Ihrer Organisation Zugriff auf Google-Dienste gewähren möchten, sollten Sie die Authentifizierung auf diese Nutzergruppe 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 der G Suite. Wenn kein zugeordnetes Nutzerkonto vorhanden ist, schlägt jeder Authentifizierungsversuch eines Nutzers fehl, auch wenn der IdP dem Nutzer die Anmeldung in Cloud Identity oder der G Suite über die Einmalanmeldung (SSO) erlaubt.
  • Konfigurieren Sie die Einmalanmeldung (SSO) bei Ihrem IdP, um die Anzahl der Nutzer zu minimieren, die sich in Cloud Identity oder der G Suite anmelden dürfen.

Der beste Ansatz für Ihr Szenario hängt davon ab, ob Sie Privatnutzerkonten haben, die migriert werden müssen.

Schränken Sie den bereitzustellenden Identitätssatz ein, wenn Sie noch Privatnutzerkonten migrieren müssen

Sie können ein Privatnutzerkonto nur dann zu Cloud Identity oder der G Suite migrieren, wenn Sie noch kein Nutzerkonto mit derselben Identität in Cloud Identity oder der G Suite 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. Befolgen Sie diese Richtlinien:

  • Schränken Sie die Authentifizierung ein, indem Sie neue Cloud Identity- oder G Suite-Nutzerkonten nur für Nutzer erstellen, die diese benötigen und bekanntermaßen kein Privatnutzerkonto haben.
  • Vermeiden Sie das versehentliche Sperren migrierter Konten, indem Sie die Einmalanmeldung nicht nur für die Nutzer zulassen, für die Sie Nutzerkonten in Cloud Identity oder der G Suite 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.

Wie sich verschiedene Arten von Identitäten überschneiden und in Beziehung zueinander stehen.

Im Diagramm befinden sich Identitäten mit einem Nutzerkonto in Cloud Identity oder der G Suite in der kleinsten (gelben) Ellipse. Diese Ellipse befindet sich in der zweiten (blauen) Ellipse, die Identitäten enthält, 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.

Verhindern Sie die Registrierung neuer Privatnutzerkonten

Das Hinzufügen einer Domain wie example.com zu Ihrem Cloud Identity- oder G Suite-Konto verhindert nicht, dass sich Mitarbeiter mit derselben Domain für neue Privatnutzerkonten registrieren. Diese neuen Privatnutzerkonten werden in Ihrem Cloud Identity- oder G Suite-Konto als nicht verwaltete Nutzer angezeigt. Sie dürfen jedoch keine Einmalanmeldung (SSO) oder eine andere Konfiguration verwenden, die Sie in Ihrem Cloud Identity- oder G Suite-Konto angewendet haben.

Eine Möglichkeit, die Erstellung eines neuen Privatnutzerkontos zu blockieren, besteht darin, ein Nutzerkonto in Cloud Identity oder der G Suite mit derselben E-Mail-Adresse zu erstellen. Wenn Sie beispielsweise den Nutzer alice@example.com in Ihrem Cloud Identity- oder G Suite-Konto erstellt haben, schlagen alle Versuche eines Mitarbeiters fehl, ein neues Privatnutzerkonto mit derselben Identität zu erstellen. Wenn jedoch noch kein entsprechender Nutzer in Cloud Identity oder der G Suite vorhanden ist, kann ein neues Privatnutzerkonto erstellt werden.

Wenn keine weiteren Privatnutzerkonten zu Cloud Identity migriert werden sollen, können Sie die Anmeldung neuer Privatnutzerkonten durch Anwendung der folgenden Konfiguration verhindern:

  • Schränken Sie die Authentifizierung ein, indem Sie nur relevanten Nutzern die Verwendung der Einmalanmeldung (SSO) in Cloud Identity oder der G Suite erlauben.

  • Stellen Sie Cloud Identity- oder G Suite-Nutzer für alle Mitarbeiter bereit. Achten Sie darauf, dass die Nutzerkonten die geschäftliche E-Mail-Adresse des Mitarbeiters als primäre E-Mail-Adresse oder als Alias verwenden, damit keine neuen Privatnutzerkonten mit derselben 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.

Registrierung neuer Privatnutzerkonten verhindern

Wenn Sie die Migration von Privatnutzerkonten noch läuft, können Sie die Registrierungen neuer Privatnutzerkonten vorübergehend überwachen. Erfassen Sie dazu die während der Registrierung gesendeten Bestätigungs-E-Mails. Richten Sie in Ihrem E-Mail-System einen Filter für die Adressen von Absendern ein, die mit *@idverification.bounces.google.com übereinstimmen, und speichern Sie übereinstimmende E-Mails für die interne Überprüfung.

Machen Sie Cloud Identity- oder G Suite-Identitäten zu einer Teilmenge der Identitäten in Ihrem externen IdP

Ihr Cloud Identity- oder G Suite-Konto enthält möglicherweise Nutzerkonten mit Identitäten, die keinem Nutzer Ihres externen Identitätsanbieters zugeordnet sind. Es gibt zwei typische Szenarien, die zu diesen Nutzerkonten führen können:

  • Sie erstellen ein neues Nutzerkonto in Cloud Identity oder der G Suite und verwenden eine primäre E-Mail-Adresse, die keinem Nutzer in Ihrem externen IdP zugeordnet ist.
  • Sie haben ein Nutzerkonto in Cloud Identity oder der G Suite, das einer Identität in Ihrem externen IdP zugeordnet ist. Anschließend löschen Sie die Identität im externen IdP. Sie können die Identität beispielsweise löschen, wenn der Mitarbeiter das Unternehmen verlässt.

Wenn Sie die Einmalanmeldung (SSO) in Cloud Identity oder in der G Suite aktivieren, müssen alle Nutzer mit Ausnahme von Super Admins die Einmalanmeldung (SSO) verwenden. Bei einem Cloud Identity- oder G Suite-Nutzerkonto, das keiner Identität in Ihrem externen IdP zugeordnet ist, schlägt die Einmalanmeldung (SSO) fehl. Ein Nutzerkonto ohne ein solches Konto ist praktisch veraltet, kann aber dennoch ein Risiko darstellen, wie in den 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. Aus Sicht der Föderation gelten die beiden Nutzerkonten jedoch als identisch, wenn sie derselben primären E-Mail-Adresse in Cloud Identity oder der G Suite zugeordnet werden. Wenn sich der neue Mitarbeiter in Google anmeldet, werden daher möglicherweise vorhandene Daten, Einstellungen und Berechtigungen des ehemaligen Mitarbeiters "übernommen".

Cloud Identity- und G Suite-Super Admins sind von der Anforderung der Einmalanmeldung (SSO) ausgenommen. Sie können die Einmalanmeldung (SSO) jedoch weiterhin verwenden, wenn die Anmeldung vom IdP initiiert wird. Die Möglichkeit, die vom IdP initiierte Einmalanmeldung (SSO) zu verwenden, macht Super Admin-Nutzer anfällig für die Namensbesetzung, wenn sie kein Gegenstück bei Ihrem externen IdP haben.

Betrachten Sie das folgende Beispiel: Anne hat einen Super Admin-Nutzer alice-admin@example.com in Cloud Identity oder der G Suite und verwendet keine Bestätigung in zwei Schritten. Karin, die das Passwort von Anne nicht kennt, findet im externen IdP einen neuen Nutzer, der alice-admin@example.com zugeordnet ist. Obwohl dieses neu erstellte Nutzerkonto möglicherweise keine besonderen Berechtigungen und keine Beziehung zu Annes Nutzerkonto hat, kann Karin jetzt mit der Identität des Super Admin-Kontos von Anne die vom Identitätsanbieter initiierte Einmalanmeldung verwenden und sich als alice-admin@example.com authentifizieren.

Sorgen Sie dafür, dass Ihre Cloud Identity- oder G Suite-Identitäten eine Teilmenge der Identitäten in Ihrem externen IdP sind, um dieses Risiko zu vermeiden. Dies erreichen Sie am besten, indem Sie den gesamten Lebenszyklus des Nutzerkontos, der von Ihrem externen IdP implementiert wurde, dem Lebenszyklus des Nutzerkontos in Cloud Identity oder der G Suite zuordnen.

Verwenden Sie dedizierte Super Admin-Nutzer

G Suite- und Cloud Identity-Super Admin-Konten haben leistungsstarke Berechtigungen, die nicht nur für das Cloud Identity- oder G Suite-Konto gelten, sondern auch für eine 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 einschränken und für die tägliche Verwaltung Ihres Kontos oder Ihrer Google Cloud-Organisation weniger Berechtigungen 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.com und 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.com und 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 die G Suite oder Ihr bestehendes E-Mail-System so, dass die E-Mail-Adresse alice-admin@example.com ein Alias ist oder an alice@example.com weitergeleitet wird, um sicherzustellen, dass an diese E-Mail-Adresse gesendete Benachrichtigungs-E-Mails im Postfach des Nutzers eingehen.

Achten Sie darauf, dass beide Identitäten von Ihrem externen IdP erkannt werden, sodass der Identitätssatz in Cloud Identity oder der G Suite weiterhin eine Teilmenge der Identitäten in Ihrem externen IdP ist.

Wir empfehlen, für diese dedizierten Super Admin-Konten ein Benennungsschema zu verwenden, damit Sie in Audit-Logs 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 der G Suite und in Cloud Identity beschränken

Ihr externer IdP enthält möglicherweise nicht nur Nutzerkonten für Mitarbeiter, sondern auch Nutzerkonten 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 erfolgen soll, verwenden Sie am besten Google Cloud-Dienstkonten für die Authentifizierung und gewähren Sie dem Dienstkonto dann Zugriff Zugriff auf die Ressourcen mit IAM.

Wenn Google Cloud-Dienstkonten die entsprechenden Rollen in IAM zugewiesen sind, können sie zur Authentifizierung und Verwendung einer beliebigen Cloud API verwendet werden. Wenn Sie einem Dienstkonto Zugriff auf APIs außerhalb von Google Cloud gewähren müssen, z. B. auf die Directory API oder die Drive API, können Sie die domainweite G Suite-Delegierung verwenden.

Mit der domainweiten G Suite-Delegierung ermöglichen Sie einem Dienstkonto, im Namen eines Cloud Identity- oder G Suite-Nutzers zu agieren. Da die Delegierung eine leistungsstarke Berechtigung ist, sollten Sie die domainweite G Suite-Delegierung nur dann verwenden, wenn der OAuth-Ansatz nicht praktikabel ist.

Verwenden Sie für jedes Google Cloud-Dienstkonto, das für die domainweite G Suite-Delegierung aktiviert ist, einen dedizierten Cloud Identity- oder G Suite-Nutzer. Erstellen Sie diesen Nutzer in Ihrem externen IdP und stellen Sie ihn für Cloud Identity oder die G Suite bereit, sodass die Gruppe von Nutzern in Cloud Identity oder der G Suite weiterhin eine Teilmenge der Nutzer in Ihrem externen IdP ist.

Erstellen Sie in Cloud Identity und der G Suite keine Dienstnutzer, die Sie nicht für die domainweite G Suite-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:

  1. Für einen Mitarbeiter, der der Organisation beitritt, wird ein neues Nutzerkonto erstellt.
  2. Das Nutzerkonto kann vorübergehend gesperrt und später wieder aktiviert werden, z. B. wenn der Mitarbeiter in den Urlaub geht.
  3. 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.

Lebenszyklus von Nutzerkonten zuordnen

In diesem Abschnitt werden Best Practices aufgeführt, um sicherzustellen, dass der Lebenszyklus von Nutzerkonten in Cloud Identity oder der G Suite dem Lebenszyklus der entsprechenden Nutzerkonten in 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. Das bedeutet, dass Änderungen, die im HRIS oder IdP durchgeführt werden, auf Cloud Identity oder die G Suite übertragen werden, aber Änderungen, die in Cloud Identity oder der G Suite durchgeführt werden, nicht zurückübertragen werden.

Legen Sie Ihren externen IdP als "Source of Truth" fest, um Inkonsistenzen aufgrund der unidirektionalen Bereitstellung zu vermeiden. Verwenden Sie ausschließlich Ihren externen IdP (oder HRIS), um Nutzer zu erstellen, zu ändern oder zu löschen, und verlassen Sie sich auf die automatische Bereitstellung, damit Änderungen an die G Suite und Cloud Identity weitergegeben werden. Indem Sie Ihren externen IdP als "Source of Truth" festlegen, begrenzen Sie das Risiko von Inkonsistenzen und manuellen Änderungen, die vom IdP überschrieben werden.

Nutzerverwaltung für Cloud Identity oder die G Suite automatisieren

Damit sich ein Mitarbeiter über die Einmalanmeldung (SSO) bei Google authentifizieren kann, müssen Sie zuerst ein Nutzerkonto für den Mitarbeiter in Cloud Identity oder der G Suite erstellen. Um die Konsistenz mit Ihrem externen IdP zu gewährleisten, sollten Sie die Bereitstellung dieser Nutzerkonten in Cloud Identity oder der G Suite automatisieren:

  • Durch die automatische Bereitstellung können Sie sicherstellen, dass Cloud Identity- oder G Suite-Identitäten immer eine Teilmenge der Identitäten in Ihrem externen IdP sind.
  • So minimieren Sie das Risiko, versehentlich eine Nichtübereinstimmung zwischen einer Identität in Cloud Identity oder der G Suite und der entsprechenden Identität in Ihrem externen IdP einzuführen. Nichtübereinstimmungen, wie z. B. ein versehentlicher Tippfehler in der E-Mail-Adresse, können zu Problemen bei der Anmeldung führen.
  • Sie minimieren den manuellen Verwaltungsaufwand.

Wenn Sie die Personaleinstellung mit einem Personalverwaltungssystem (HRIS) begleiten, besteht eine Möglichkeit zur Automatisierung der Nutzerverwaltung mit HRIS darin, Nutzerkonten wie im folgenden Diagramm sowohl für Ihren externen IdP als auch für Cloud Identity oder die G Suite bereitzustellen.

Stellen Sie Nutzerkonten sowohl für Ihren externen IdP als auch für Cloud Identity oder die G Suite bereit.

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 entscheiden, welche Nutzerkonten für Cloud Identity oder die G Suite bereitgestellt werden sollen.

Eine weitere Möglichkeit zur Automatisierung der Nutzerverwaltung, die unabhängig von einem Personalverwaltungssystem funktioniert, besteht darin, Ihren externen IdP als verbindliche Quelle für die Nutzerverwaltung in Cloud Identity oder der G Suite zu verwenden. Mit dieser Einrichtung wird die Konfiguration zum Zuordnen von Nutzerkonten und Nutzerkontosätzen vom IdP oder vom Adapter verwaltet, wie das folgende Diagramm zeigt.

Externen IdP als verbindliche Quelle für die Nutzerverwaltung in Cloud Identity oder der G Suite verwenden.

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 der G Suite. Da die G Suite und Cloud Identity auf derselben Plattform basieren und dieselben APIs verwenden, können diese Adapter auch für Cloud Identity verwendet werden.

Sperrungsereignisse an Cloud Identity oder die G Suite weitergeben

Wenn ein Mitarbeiter die Organisation vorübergehend oder dauerhaft verlässt, sollten Sie ihm den Zugriff auf Google-Dienste entziehen. 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. Folgendes kann dennoch auftreten:

  • Wenn der Cloud Identity- oder G Suite-Nutzer eine aktive Browsersitzung hat, 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 G Suite-Lizenz hat, werden E-Mails weiterhin an das Postfach des Nutzers zugestellt, der Nutzer wird weiterhin im Adressbuch angezeigt und der Nutzer wird möglicherweise 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 den Zugriff auf Google-Dienste vollständig widerrufen möchten, können Sie Sperrungsereignisse so an Cloud Identity oder die G Suite weiterleiten:

  • Achten Sie darauf, dass bei jeder Sperrung eines Nutzerkontos bei Ihrem externen IdP auch das entsprechende Nutzerkonto in Cloud Identity oder der G Suite gesperrt wird. Wenn Sie einen Nutzer in Cloud Identity oder der G Suite sperren, werden aktive Browsersitzungen beendet, Tokens werden ungültig und alle anderen Zugriffe werden widerrufen.

  • Wenn Sie ein Nutzerkonto bei Ihrem externen IdP reaktivieren, müssen Sie auch das entsprechende Nutzerkonto in Cloud Identity oder der G Suite reaktivieren.

Das Sperren eines Nutzerkontos in Cloud Identity oder der G Suite ist ein nichtlöschender Vorgang. Solange das Nutzerkonto gesperrt ist, bleiben die Daten des Nutzers erhalten, G Suite-Lizenzen bleiben angehängt und zugewiesene Rollen in Google Cloud bleiben unverändert.

Löschereignisse an Cloud Identity oder die G Suite 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 G Suite-Nutzer, ist die Gruppe von Nutzern in Cloud Identity und der G Suite keine Teilmenge der Nutzer mehr in Ihrem externen IdP. Dies kann in Zukunft zu einem Problem werden, wenn ein neuer Mitarbeiter in Ihre Organisation aufgenommen wird, der denselben Namen wie der ausscheidende Mitarbeiter hat. Wenn Sie in Ihrem IdP ein Nutzerkonto für den neuen Mitarbeiter erstellen, können Sie den Nutzernamen des alten Mitarbeiters wiederverwenden, wodurch das neue Nutzerkonto dem alten Nutzerkonto in Cloud Identity oder der G Suite zugeordnet wird. Dadurch erhält der neue Mitarbeiter möglicherweise Zugriff auf die Daten und Einstellungen des alten Mitarbeiters.

Sie können die mit verwaisten Cloud Identity- oder G Suite-Nutzerkonten verbundenen Risiken vermeiden, indem Sie einen Cloud Identity- oder G Suite-Nutzer löschen, sobald das entsprechende Nutzerkonto in Ihrem IdP gelöscht wird.

Das Entfernen eines Cloud Identity- oder G Suite-Nutzers ist ein löschender Vorgang, der nur innerhalb eines bestimmten Zeitraums rückgängig gemacht werden kann. Je nach den vom Nutzer genutzten Google-Diensten kann das Entfernen des Nutzers dazu führen, dass die zugehörigen Daten endgültig gelöscht werden. Dies erfüllt möglicherweise nicht Ihre Compliance-Anforderungen.

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:

  • Sie können das Löschen des Nutzerkontos bei Ihrem externen IdP verzögern, indem Sie den Nutzer für einen bestimmten Aufbewahrungszeitraum in einem gesperrten Zustand belassen. Löschen Sie den Nutzer nach Ablauf des Aufbewahrungszeitraums sowohl bei Ihrem IdP als auch in Cloud Identity/G Suite.

  • Wenn Sie ein Nutzerkonto bei Ihrem externen IdP löschen, sperren Sie den entsprechenden Cloud Identity- oder G Suite-Nutzer und ändern Sie seine primäre E-Mail-Adresse in einen Namen, der mit hoher Wahrscheinlichkeit keinen Konflikt verursachen wird. Benennen Sie beispielsweise alice@example.com in obsolete-yyyymmdd-alice@example.com um, wobei yyyymmdd das Datum des Löschvorgangs bei Ihrem externen IdP widerspiegelt. Lassen Sie das umbenannte Nutzerkonto für einen Aufbewahrungszeitraum gesperrt und löschen Sie es nach Ablauf des Aufbewahrungszeitraums.

Wenn Sie G Suite-Daten für gesperrte Nutzer zurückhalten möchten, behalten Sie entweder die dem Nutzer zugewiesene G Suite-Lizenz bei oder ändern Sie sie in eine Lizenz für archivierte Nutzer, damit die Aufbewahrungsregeln für G Suite Vault weiterhin angewendet werden 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, indem er einen Nutzer zu accounts.google.com weiterleitet, wo der Nutzer den Google-Anmeldebildschirm sieht und nach seiner E-Mail-Adresse gefragt wird. Je nach Domain der angegebenen E-Mail-Adresse wird das Nutzerkonto dann in Gmail, dem Verzeichnis des Privatnutzerkontos oder, falls die Domain mit ihrer primären, sekundären oder Alias-Domain übereinstimmt, in einem Cloud Identity- oder G Suite-Konto gesucht.

Das folgende Diagramm veranschaulicht diesen Authentifizierungsprozess.

Google-Authentifizierungsprozess.

Wenn Sie ein Cloud Identity- oder G Suite-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 G Suite-Konto aktiviert wurde, können alle Nutzer dieses Kontos die vom IdP initiierte Einmalanmeldung (SSO) verwenden, auch Super Admins.

Minimieren Sie die Menge der in SAML-Assertions übergebenen Attribute

Nachdem sich ein Nutzer beim externen IdP authentifiziert hat, verwenden Cloud Identity oder die G Suite die vom externen IdP übergebene SAML-Assertion, um eine Sitzung einzurichten. Dabei wird nicht nur die Authentizität überprüft, sondern auch das Cloud Identity- oder G Suite-Nutzerkonto, das dem Wert NameID in der SAML-Assertion entspricht.

Der Wert NameID muss die primäre E-Mail-Adresse des zu authentifizierenden Nutzerkontos enthalten. 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 dürfen zusätzliche Attribute enthalten, werden aber bei der Authentifizierung nicht berücksichtigt. Attribute, die Informationen wie den Vor- und Nachnamen oder die Gruppenmitgliedschaft eines Nutzers enthalten, werden ignoriert, da das Nutzerkonto in Cloud Identity oder der G Suite als einzige Quelle für diese Nutzerinformationen gilt.

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.

Die globale Art 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 angeben (das Audience-Element in der SAML-Antwort).

Sie können diese Standardeinstellung ändern, indem Sie bei der Konfiguration der Einmalanmeldung (SSO) in Cloud Identity oder der G Suite die Option Domainspezifischen Aussteller verwenden aktivieren. Aktivieren Sie die Option für domainspezifische Aussteller nur, wenn Sie mehr als ein Cloud Identity- oder G Suite-Konto (und somit mehrere Domains) haben und Ihr IdP in der Lage sein muss, zwischen Anmeldungen, die von einem Cloud Identity- oder G Suite-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 G Suite-Kontos ist.

Behalten Sie in allen anderen Fällen die Standardeinstellung für die Verwendung von google.com als Aussteller bei und konfigurieren Sie Ihren externen IdP so, dass google.com als Zielgruppe in SAML-Assertions angegeben 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 G Suite Business-Lizenz können Sie die Standardsitzungsdauer ändern, z. B. auf acht Stunden.

Sie können die von Google Cloud verwendete Sitzungsdauer steuern. Die Google Cloud-Sitzung gilt sowohl für die Cloud Console als auch für das gcloud-Befehlszeilentool und andere API-Clients. Sie können die Google Cloud-Sitzungsdauer in allen Cloud Identity- und G Suite-Kontotypen 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.

Multi-Faktor-Authentifizierung

Wenn Sie die Einmalanmeldung (SSO) zwischen Cloud Identity oder der G Suite und Ihrem externen IdP aktivieren, verbessern Sie die Nutzerfreundlichkeit für Ihre Mitarbeiter. Nutzer müssen sich weniger häufig authentifizieren und müssen sich keine separaten Anmeldedaten merken, um auf Google-Dienste zugreifen zu können.

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 G Suite-Konto konfiguriert haben, müssen sich Nutzer ohne Super Admin-Berechtigung zur Authentifizierung über Ihren externen IdP 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.

Zweistufige Google-Authentifizierung für Super Admins erzwingen

G Suite- und Cloud Identity-Super-Admin-Konten sind von der Einmalanmeldung (SSO) ausgenommen und haben leistungsstarke Berechtigungen, die sie zu einem attraktiven Ziel für Angreifer machen. Standardmäßig ist die zweistufige Authentifizierung für Google-Konten optional, einschließlich Super-Admin-Konten. Nutzer können diese Funktion aktivieren, aber sie sind nicht dazu verpflichtet, es sei denn, Sie erzwingen die zweistufige Authentifizierung.

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: Obwohl es am besten ist, diese Nutzerkonten zu vermeiden, sind sie manchmal notwendig, um Tools wie Cloud Directory Sync oder die Azure AD Gallery App zur Verwaltung von Nutzern und Gruppen in Cloud Identity oder G Suite 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-Nutzern finden Sie in unseren Best Practices für die Sicherheit von Administratorkonten.

Beschränken Sie die Einmalanmeldung nicht nach Netzwerkmaske

Wenn Sie die Einmalanmeldung in Cloud Identity oder der G Suite konfigurieren, können Sie optional eine Netzwerkmaske angeben. Wenn Sie eine Maske angeben, unterliegen nur Nutzer, deren IP-Adressen mit der Maske übereinstimmen, der Einmalanmeldung. 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.

Konfigurieren Sie entweder eine entsprechende Liste zugelassener IP-Adressen bei Ihrem externen IdP oder verwenden Sie den kontextsensitiven Zugriff für Google Cloud und die G Suite, wenn Sie den Zugriff auf Ressourcen nach IP-Adresse einschränken möchten.

Weitere Informationen