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 Beispielidentitätsanbieter wird Microsoft Active Directory in der lokalen Umgebung verwendet.
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 zur Einrichtungsanleitung 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 über den Terraform-Code in diesem Blueprint automatisiert. Unter Verwaltungsfunktionen für Cloud Identity finden Sie die empfohlenen Sicherheitseinstellungen, die Sie zusätzlich zur Bereitstellung 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 raten davon ab, einzelnen Nutzern IAM-Rollen zuzuweisen, da individuelle Zuweisungen die Komplexität der Verwaltung und Prüfung von Rollen erhöhen können.
Mit dem Blueprint werden Gruppen und Rollen für den Lesezugriff auf Grundlagenressourcen 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.
Die folgende Tabelle zeigt die Gruppen, die vom Blueprint zum Aufrufen von Grundlagenressourcen konfiguriert wurden.
| 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. Diese Berechtigung ist nicht für den täglichen Gebrauch empfohlen. | Administrator der Organisation | Organisation |
grp-gcp-billing-admin@example.com |
Stark privilegierte Administratoren, die das Cloud-Rechnungskonto ändern können. Diese Berechtigung wird nicht für die tägliche Verwendung empfohlen. | Rechnungskontoadministrator | Organisation |
grp-gcp-billing-viewer@example.com |
Das Team, das für die Anzeige und Analyse 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. | Logging-Projekt | |
grp-gcp-security-reviewer@example.com |
Das Team, das für die Überprüfung der Cloud-Sicherheit verantwortlich ist. | Sicherheitsprüfer | Organisation |
grp-gcp-network-viewer@example.com |
Das Team, das für das Aufrufen und Verwalten der 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 Secrets 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.
Es wird dringend empfohlen, einfache Rollen wie Inhaber, Bearbeiter oder Betrachter zu vermeiden und stattdessen vordefinierte Rollen zu verwenden. Einfache Rollen sind zu weit gefasst 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. Dies bedeutet jedoch, dass Sie einen zusätzlichen Schutz für Super Admin-Konten in Betracht ziehen müssen.
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 für 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 Logs enthalten Informationen, die für Ihre Google Cloud-Umgebung relevant sind, z. B. Nutzeranmeldungsereignisse. Wir empfehlen, Audit-Logs von Cloud Identity 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 auf Grundlage 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 können Unternehmensdaten enthalten, werden aber nicht von den Verwaltungsprozessen für den Kontolebenszyklus gesteuert. Wir empfehlen, Maßnahmen zu ergreifen, um sicherzustellen, dass alle Nutzerkonten verwaltete Konten sind. |
| Kontowiederherstellung für Super Admin-Konten deaktivieren | Die Selbstwiederherstellung für Super Admin-Konten ist standardmäßig für alle Neukunden deaktiviert. Für 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 Wiederverwendung von Passwörtern und überwachen Sie die Passwortstärke für alle Nutzer, die sich mit einem Passwort in Cloud Identity anmelden, insbesondere Super Admin-Konten. |
| Organisationsweite Richtlinien für die Verwendung von Gruppen festlegen | Standardmäßig lassen sich externe Nutzerkonten zu Gruppen in Cloud Identity hinzufügen. 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öderation Ihres Identitätsanbieters 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
- Lesen Sie die Informationen zur Organisationsstruktur (nächstes Dokument in dieser Reihe).