Authentifizierung und Autorisierung

Last reviewed 2023-12-20 UTC

In diesem Abschnitt wird erläutert, wie Sie Cloud Identity verwenden, um die Identitäten zu verwalten, mit denen Ihre Mitarbeiter auf Google Cloud-Dienste zugreifen.

Externer Identitätsanbieter als „Source of Truth“

Wir empfehlen, Ihr Cloud Identity-Konto mit Ihrem vorhandenen Identitätsanbieter zu föderieren. Mit Föderation wird sichergestellt, dass Ihre vorhandenen Kontoverwaltungsprozesse auf Google Cloud und andere Google-Dienste angewendet werden.

Wenn Sie noch keinen Identitätsanbieter haben, können Sie Nutzerkonten direkt in Cloud Identity erstellen.

Das folgende Diagramm zeigt eine allgemeine Ansicht der Identitätsföderation und der Einmalanmeldung (SSO). Als Beispiel für einen Identitätsanbieter wird Microsoft Active Directory in der lokalen Umgebung verwendet.

Föderation mit externem Identitätsanbieter.

In diesem Diagramm werden die folgenden Best Practices beschrieben:

  • Nutzeridentitäten werden in einer Active Directory-Domain verwaltet, die sich in der lokalen Umgebung befindet und mit Cloud Identity föderiert ist. Active Directory verwendet Google Cloud Directory Sync für die Bereitstellung von Identitäten an Cloud Identity.
  • Nutzer, die versuchen, sich in Google-Diensten anzumelden, werden zum externen Identitätsanbieter für Einmalanmeldung (SSO) mit SAML weitergeleitet, wobei ihre vorhandenen Anmeldedaten zur Authentifizierung verwendet werden. Es werden keine Passwörter mit Cloud Identity synchronisiert.

Die folgende Tabelle enthält Links zu Einrichtungsanleitungen für Identitätsanbieter.

Identitätsanbieter Anleitung
Active Directory
Microsoft Entra ID (früher Azure AD)
Andere externe Identitätsanbieter (z. B. Ping oder Okta)

Wir empfehlen dringend, die Multi-Faktor-Authentifizierung bei Ihrem Identitätsanbieter zu erzwingen. Dies erfolgt über einen Phishing-resistenten Mechanismus, wie z. B. einen Titan-Sicherheitsschlüssel.

Die empfohlenen Einstellungen für Cloud Identity werden nicht durch den Terraform-Code in diesem Blueprint automatisiert. Unter Verwaltungsfunktionen für Cloud Identity finden Sie die empfohlenen Sicherheitseinstellungen, die Sie zusätzlich zum Bereitstellen des Terraform-Codes konfigurieren müssen.

Gruppen für die Zugriffssteuerung

Ein Hauptkonto ist eine Identität, der Zugriff auf eine Ressource gewährt werden kann. Hauptkonto umfassen Google-Konten für Nutzer, Google-Gruppen, Google Workspace-Konten, Cloud Identity-Domains und Dienstkonten. Bei einigen Diensten können Sie auch allen Nutzern, die sich mit einem Google-Konto authentifizieren, oder allen Nutzern im Internet Zugriff gewähren. Damit ein Hauptkonto mit Google Cloud-Diensten interagieren kann, müssen Sie ihm Rollen in Identity and Access Management (IAM) zuweisen.

Wenn Sie IAM-Rollen in großem Umfang verwalten möchten, sollten Sie Nutzer basierend auf ihren Aufgabenbereichen und Zugriffsanforderungen Gruppen zuweisen. Gewähren Sie dann IAM-Rollen für diese Gruppen. Sie sollten Nutzer mithilfe der Prozesse in Ihrem vorhandenen Identitätsanbieter zur Gruppenerstellung und -mitgliedschaft hinzufügen.

Wir empfehlen nicht, einzelnen Nutzern IAM-Rollen zu gewähren, da die Verwaltung und Prüfung von Rollen durch individuelle Zuweisungen erschwert werden kann.

Im Blueprint werden Gruppen und Rollen für den Lesezugriff auf die Foundation-Ressourcen konfiguriert. Wir empfehlen, alle Ressourcen im Blueprint über die Grundlagenpipeline bereitzustellen und Nutzern keine Rollen in Gruppen zuzuweisen, um Grundlagenressourcen außerhalb der Pipeline zu ändern.

In der folgenden Tabelle sind die Gruppen aufgeführt, die vom Blueprint für die Anzeige von Ressourcen der Foundation konfiguriert werden.

Name Beschreibung Rollen Umfang
grp-gcp-org-admin@example.com Administratoren mit umfangreichen Berechtigungen, die IAM-Rollen auf Organisationsebene zuweisen können. Sie können auf jede andere Rolle zugreifen. Dieses Berechtigung wird für die tägliche Nutzung nicht empfohlen. Administrator der Organisation Organisation
grp-gcp-billing-admin@example.com Stark privilegierte Administratoren, die das Cloud-Rechnungskonto ändern können. Dieses Berechtigung wird für die tägliche Nutzung nicht empfohlen. Rechnungskontoadministrator Organisation
grp-gcp-billing-viewer@example.com Das Team, das für die Prüfung der Ausgaben in allen Projekten verantwortlich ist. Rechnungskonto-Betrachter Organisation
BigQuery-Nutzer Abrechnungsprojekt
grp-gcp-audit-viewer@example.com Das Team, das für die Prüfung sicherheitsrelevanter Logs verantwortlich ist.

Loganzeige

BigQuery-Nutzer

 Logging-Projekt
grp-gcp-security-reviewer@example.com Das Team, das für die Prüfung der Cloudsicherheit verantwortlich ist. Sicherheitsprüfer Organisation
grp-gcp-network-viewer@example.com Das Team, das für die Anzeige und Pflege von Netzwerkkonfigurationen verantwortlich ist. Compute-Netzwerkbetrachter Organisation
grp-gcp-scc-admin@example.com Das Team, das für die Konfiguration von Security Command Center verantwortlich ist. Sicherheitscenter-Administratorbearbeiter Organisation
grp-gcp-secrets-admin@example.com Das Team, das für die Verwaltung, Speicherung und Prüfung von Anmeldedaten und anderen Geheimnissen verantwortlich ist, die von Anwendungen verwendet werden. Secret Manager-Administrator Secrets-Projekte
grp-gcp-kms-admin@example.com Das Team, das für die Erzwingung der Verwaltung des Verschlüsselungsschlüssels verantwortlich ist, um Compliance-Anforderungen zu erfüllen. Cloud KMS-Betrachter kms-Projekte

Wenn Sie Ihre eigenen Arbeitslasten auf Basis der Grundlagen erstellen, erstellen Sie zusätzliche Gruppen und weisen IAM-Rollen zu, die auf den Zugriffsanforderungen für jede Arbeitslast basieren.

Wir empfehlen dringend, einfache Rollen wie „Inhaber“, „Bearbeiter“ oder „Betrachter“ zu vermeiden und stattdessen vordefinierte Rollen zu verwenden. Einfache Rollen gewähren zu viele Berechtigungen und stellen ein potenzielles Sicherheitsrisiko dar. Die Rollen "Inhaber" und "Bearbeiter" können zu einer Rechteausweitung und seitlichen Bewegungen führen und die Rolle "Betrachter" enthält Zugriff zum Lesen aller Daten. Best Practices für IAM- Rollen, siehe IAM sicher verwenden

Super Admin-Konten

Cloud Identity-Nutzer mit dem Super Admin-Konto umgehen die SSO-Einstellungen der Organisation und authentifizieren sich direkt bei Cloud Identity. Diese Ausnahme ist bewusst so konzipiert, dass der Super Admin auch bei einer SSO-Fehlkonfiguration oder einem Ausfall weiterhin auf die Cloud Identity-Konsole zugreifen kann. Sie müssen jedoch zusätzlichen Schutz für Super Admin-Konten in Betracht ziehen.

Zum Schutz Ihrer Super Admin-Konten empfehlen wir, dass Sie in Cloud Identity immer die Bestätigung in zwei Schritten mit Sicherheitsschlüsseln erzwingen. Weitere Informationen finden Sie im Hilfeartikel Best Practices für die Sicherheit von Administratorkonten.

Probleme mit Privatnutzerkonten

Wenn Sie Cloud Identity oder Google Workspace vor der Einführung von Google Cloud nicht verwendet haben, verwenden die Mitarbeiter Ihrer Organisation möglicherweise bereits Privatnutzerkonten, die mit ihren Unternehmens-E-Mail-Identitäten verknüpft sind, um auf andere Google-Dienste wie die Google Marketing Platform oder YouTube zuzugreifen. Privatnutzerkonten sind Konten, die den Personen, die sie erstellt haben, vollständig gehören und von diesen verwaltet werden. Da diese Konten nicht von Ihrer Organisation kontrolliert werden und sowohl private als auch Unternehmensdaten enthalten können, müssen Sie entscheiden, wie Sie diese Konten mit anderen Unternehmenskonten konsolidieren.

Wir empfehlen Ihnen, Bestehende Privatnutzerkonten als Teil des Onboardings in Google Cloud zu konsolidieren. Wenn Sie Google Workspace nicht bereits alle Nutzerkonten verwenden, empfehlen wir, das Erstellen neuer Privatnutzerkonten zu blockieren.

Verwaltungsfunktionen für Cloud Identity

Cloud Identity bietet verschiedene Verwaltungsfunktionen, die nicht durch Terraform-Code im Blueprint automatisiert werden. Wir empfehlen, jede dieser Best Practices-Sicherheitskontrollen frühzeitig im Prozess des Aufbaus der Grundlagen zu erzwingen.

Steuerung Beschreibung
Bestätigung in zwei Schritten implementieren

Nutzerkonten können durch Phishing, Social Engineering, Password Spraying oder verschiedene andere Bedrohungen manipuliert werden. Die Bestätigung in zwei Schritten trägt dazu bei, diese Bedrohungen zu mindern.

Wir empfehlen, die Bestätigung in zwei Schritten für alle Nutzerkonten in Ihrer Organisation mit einem Phishing-resistenten Mechanismus wie Titan-Sicherheitsschlüsseln oder anderen Schlüsseln zu erzwingen, die auf den Phishing-resistenten FIDO-U2F-Standards (CTAP1) basieren.
Sitzungsdauer für Google Cloud-Dienste festlegen Dauerhafte OAuth-Tokens für Entwickler-Workstations können ein Sicherheitsrisiko darstellen. Wir empfehlen, dass Sie eine Richtlinie für die erneute Authentifizierung festlegen, die eine Authentifizierung alle 16 Stunden mit einem Sicherheitsschlüssel erfordert.
Sitzungsdauer für Google-Dienste festlegen (nur Google Workspace-Kunden)

Persistente Websitzungen in anderen Google-Diensten können ein Sicherheitsrisiko darstellen, wenn sie offengelegt werden. Wir empfehlen, eine maximale Websitzungsdauer zu erzwingen und diese an die Kontrollen für die Sitzungsdauer bei Ihrem SSO-Anbieter anzupassen.
Geben Sie Daten aus Cloud Identity für Google Cloud-Dienste frei.

Audit-Logs zur Administratoraktivität von Google Workspace oder Cloud Identity werden normalerweise in der Admin-Konsole verwaltet und angezeigt, separat von Ihren Logs in der Google Cloud-Umgebung. Diese Protokolle enthalten Informationen, die für Ihre Google Cloud-Umgebung relevant sind, z. B. Anmeldevorgänge von Nutzern.

Wir empfehlen, Cloud Identity-Audit-Logs für Ihre Google Cloud-Umgebung freizugeben, um Logs aus allen Quellen zentral zu verwalten.
Identitätsbestätigung nach der Einmalanmeldung einrichten

Beim Blueprint wird davon ausgegangen, dass Sie die SSO mit Ihrem externen Identitätsanbieter einrichten.

Wir empfehlen Ihnen, eine zusätzliche Kontrollebene basierend auf der Anmelderisikoanalyse von Google zu aktivieren. Nachdem Sie diese Einstellung angewendet haben, können Nutzer bei der Anmeldung zusätzliche risikoabhängige Identitätsbestätigungen sehen, wenn Google der Meinung ist, dass eine Nutzeranmeldung verdächtig ist.
Probleme mit Privatnutzernkonten beheben

Nutzer mit einer gültigen E-Mail-Adresse in Ihrer Domain, aber ohne Google-Konto, können sich für nicht verwaltete Privatnutzerkonten registrieren. Diese Konten enthalten möglicherweise Unternehmensdaten, werden aber nicht durch Ihre Prozesse zur Kontoverwaltung gesteuert.

Wir empfehlen Ihnen, dafür zu sorgen, dass alle Nutzerkonten verwaltete Konten sind.
Kontowiederherstellung für Super Admin-Konten deaktivieren

Die eigenständige Kontowiederherstellung durch Super Admins ist für alle neuen Kunden standardmäßig deaktiviert. Bei Bestandskunden ist diese Einstellung möglicherweise aktiviert. Durch das Deaktivieren dieser Einstellung verringern Sie das Risiko, dass ein manipuliertes Telefon, ein manipuliertes E-Mail-Konto oder ein Social Engineering-Angriff Angreifern in Ihrer Umgebung Super Admin-Berechtigungen gewähren kann.

Planen Sie einen internen Prozess, damit ein Super Admin einen anderen Super Admin in Ihrer Organisation kontaktieren kann, wenn er keinen Zugriff mehr auf sein Konto hat. Sorgen Sie außerdem dafür, dass alle Super Admins mit dem Prozess für die supportgestützte Wiederherstellung vertraut sind.
Passwortanforderungen für Nutzer durchsetzen und beobachten In den meisten Fällen werden Nutzerpasswörter über Ihren externen Identitätsanbieter verwaltet. Super Admin-Konten umgehen die SSO jedoch und müssen bei der Anmeldung in Cloud Identity ein Passwort verwenden. Deaktivieren Sie die Passwortwiederverwendung und überwachen Sie die Passwortstärke für alle Nutzer, die sich mit einem Passwort in Cloud Identity anmelden, insbesondere für Super Admin-Konten.
Organisationsweite Richtlinien für die Verwendung von Gruppen festlegen

Standardmäßig können Gruppen in Cloud Identity externe Nutzerkonten hinzugefügt werden. Wir empfehlen, die Freigabe-Einstellungen zu konfigurieren, sodass Gruppeninhaber keine externen Mitglieder hinzufügen können.

Hinweis: Diese Einschränkung gilt nicht für das Super Admin-Konto oder andere delegierte Administratoren mit Gruppenadministrator-Berechtigungen. Da die Föderierung über Ihren Identitätsanbieter mit Administratorberechtigungen ausgeführt wird, gelten die Einstellungen für die Gruppenfreigabe nicht für diese Gruppensynchronisierung. Wir empfehlen Ihnen, die Steuerelemente beim Identitätsanbieter und im Synchronisierungsmechanismus zu prüfen, um sicherzustellen, dass Mitglieder, die nicht zur Domain gehören, nicht zu Gruppen hinzugefügt werden, oder Gruppeneinschränkungen anzuwenden.

Nächste Schritte