In diesem Abschnitt wird erläutert, wie Sie mit Cloud Identity die Identitäten verwalten, die Ihre Mitarbeiter für den Zugriff auf Google Cloud-Dienste verwenden.
Externer Identitätsanbieter als „Source of Truth“
Wir empfehlen, Ihr Cloud Identity-Konto mit Ihrem vorhandenen Identitätsanbieter zu föderieren. Dank Föderation können Sie sicherstellen, dass Ihre vorhandenen Prozesse zur Kontoverwaltung für Google Cloud und andere Google-Dienste gelten.
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 den Identitä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, um Identitäten in Cloud Identity bereitzustellen.
- Nutzer, die versuchen, sich bei Google-Diensten anzumelden, werden für die Einmalanmeldung (SSO) mit SAML zum externen Identitätsanbieter weitergeleitet. Dabei werden ihre vorhandenen Anmeldedaten zur Authentifizierung verwendet. 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. Die empfohlenen Sicherheitseinstellungen, die Sie zusätzlich zur Bereitstellung des Terraform-Codes konfigurieren müssen, finden Sie unter Verwaltungsfunktionen für Cloud Identity.
Gruppen für die Zugriffssteuerung
Ein Hauptkonto ist eine Identität, der Zugriff auf eine Ressource gewährt werden kann. Hauptkonten umfassen Google-Konten für Nutzer, Google-Gruppen, Google Workspace-Konten, Cloud Identity-Domains und Dienstkonten. Mit 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.
Zum Verwalten einer großen Anzahl von IAM-Rollen empfehlen wir, dass Sie Nutzer anhand ihrer Jobfunktionen und Zugriffsanforderungen Gruppen zuweisen und dann diesen Gruppen IAM-Rollen zuweisen. Sie sollten Nutzer mithilfe der Prozesse in Ihrem vorhandenen Identitätsanbieter zur Gruppenerstellung und -mitgliedschaft hinzufügen.
Wir empfehlen, den einzelnen Nutzern keine IAM-Rollen zuzuweisen, da einzelne Zuweisungen die Komplexität der Verwaltung und Prüfung von Rollen erhöhen können.
Der Blueprint konfiguriert Gruppen und Rollen für den Lesezugriff auf Grundlagenressourcen. Wir empfehlen, alle Ressourcen im Blueprint über die Grundlagenpipeline bereitzustellen und Nutzern keine Rollen zuzuweisen, um Grundlagenressourcen außerhalb der Pipeline zu ändern.
Die folgende Tabelle zeigt die Gruppen, die vom Blueprint zum Aufrufen von Grundlagenressourcen konfiguriert werden.
| Name | Beschreibung | Rollen | Geltungsbereich |
|---|---|---|---|
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 wird für die tägliche Verwendung nicht empfohlen. | Administrator der Organisation | Organisation |
grp-gcp-billing-admin@example.com |
Administratoren mit umfangreichen Berechtigungen, die das Cloud-Rechnungskonto ändern können. Diese Berechtigung wird für die tägliche Nutzung nicht 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 sicherheitsbezogener Logs verantwortlich ist. | Logging-Projekt | |
grp-gcp-monitoring-users@example.com |
Das Team, das für das Monitoring der Leistungsmesswerte von Anwendungen verantwortlich ist. | Monitoring-Betrachter | Monitoring-Projekt |
grp-gcp-security-reviewer@example.com |
Das Team, das für die Prüfung der Cloud-Sicherheit verantwortlich ist. | Sicherheitsprüfer | Organisation |
grp-gcp-network-viewer@example.com |
Das Team, das für die Anzeige und Verwaltung der Netzwerkkonfigurationen zuständig ist. | Compute-Netzwerkbetrachter | Organisation |
grp-gcp-scc-admin@example.com |
Das Team, das für die Konfiguration von Security Command Center zuständig 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 zuständig 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 finden Sie unter 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 weiterhin auf die Cloud Identity-Konsole zugreifen kann, wenn eine SSO-Fehlkonfiguration oder ein Ausfall auftritt. Dies bedeutet jedoch, dass Sie zusätzlichen Schutz für Super Admin-Konten berücksichtigen 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, im Rahmen der Einrichtung von Google Cloud vorhandene Privatnutzerkonten zu konsolidieren. Wenn Sie Google Workspace nicht bereits für alle Ihre 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 Ihnen, jede dieser Best Practice-Sicherheitskontrollen früh beim Aufbau Ihrer Grundlagen zu erzwingen.
| Steuerelement | 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 abzuwehren. 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 | Persistente OAuth-Tokens auf Entwickler-Workstations können ein Sicherheitsrisiko darstellen, wenn sie offengelegt werden. Wir empfehlen, eine Richtlinie zur erneuten Authentifizierung so festzulegen, dass eine Authentifizierung alle 16 Stunden mithilfe eines Sicherheitsschlüssels erforderlich ist. |
| 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. |
| Daten aus Cloud Identity für Google Cloud-Dienste freigeben | 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, Cloud Identity-Audit-Logs für Ihre Google Cloud-Umgebung freizugeben, damit Logs aus allen Quellen zentral verwaltet werden können. |
| 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 zu aktivieren, die auf der Risikoanalyse von Google für die Anmeldung basiert. 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 Privatnutzerkonten 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 Ihren Prozessen zur Verwaltung des Kontolebenszyklus gesteuert. Wir empfehlen Ihnen, sicherzustellen, dass alle Nutzerkonten verwaltete Konten sind. |
| Kontowiederherstellung für Super Admin-Konten deaktivieren | Die Selbstwiederherstellung für Super Admin-Konten ist für alle Neukunden standardmäßig deaktiviert. Für bestehende Kunden 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 ein Passwort für die Anmeldung in Cloud Identity verwenden. Dies gilt insbesondere für Super Admin-Konten. |
| Organisationsweite Richtlinien für die Verwendung von Gruppen festlegen | Standardmäßig können externe Nutzerkonten den Gruppen in Cloud Identity hinzugefügt werden. Wir empfehlen, Freigabeeinstellungen so zu konfigurieren, dass Gruppeninhaber keine externen Mitglieder hinzufügen können. Beachten Sie, dass diese Einschränkung nicht für das Super Admin-Konto oder andere delegierte Administratoren mit Administratorberechtigungen für Google Groups gilt. Da die Föderation von Ihrem Identitätsanbieter mit Administratorberechtigungen ausgeführt wird, gelten die Gruppenfreigabeeinstellungen nicht für diese Gruppensynchronisierung. Wir empfehlen Ihnen, die Steuerelemente im 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
- Mehr über die Organisationsstruktur erfahren (nächstes Dokument in dieser Reihe).