Best Practices für die Planung von Konten und Organisationen

Last reviewed 2024-06-26 UTC

In diesem Dokument werden Best Practices für die Entscheidung vorgestellt, wie viele Cloud Identity- oder Google Workspace-Konten, Google Cloud-Organisationen und Rechnungskonten Sie verwenden müssen. Das Dokument enthält Anleitungen zum Ermitteln eines Gestaltungsplans, der Ihren Sicherheits- und Organisationsanforderungen entspricht.

In Google Cloud basiert die Identitäts- und Zugriffsverwaltung auf zwei Säulen:

  • Cloud Identity- und Google Workspace-Konten sind Container für Nutzer und Gruppen. Diese Konten sind daher der Schlüssel zur Authentifizierung Ihrer Unternehmensnutzer und zur Verwaltung des Zugriffs auf Ihre Google Cloud-Ressourcen. Ein Cloud Identity- oder Google Workspace-Konto bezeichnet ein Verzeichnis von Nutzern, kein einzelnes Nutzerkonto. Einzelne Nutzerkonten werden als Nutzer oder Nutzerkonten bezeichnet.

  • Organisationen sind Container für Projekte und Ressourcen in Google Cloud. Organisationen ermöglichen die hierarchische Strukturierung von Ressourcen und sind der Schlüssel für eine zentrale und effiziente Ressourcenverwaltung.

Dieses Dokument richtet sich hauptsächlich an Kunden, die Unternehmensumgebungen einrichten.

Cloud Identity- und Google Workspace-Konten

Google Workspace ist eine eingebundene Suite von cloudnativen Anwendungen für Zusammenarbeit und Produktivität. Sie umfasst Tools, mit denen Sie Nutzer, Gruppen und Authentifizierung verwalten können.

Cloud Identity bietet einen Teil der Features von Google Workspace. Wie bei Google Workspace lassen sich mit Cloud Identity Nutzer, Gruppen und Authentifizierung verwalten. Cloud Identity umfasst jedoch nicht alle Google Workspace-Features für Zusammenarbeit und Produktivität.

Cloud Identity und Google Workspace haben eine gemeinsame technische Plattform und nutzen dieselben APIs und Verwaltungstools. Die Produkte haben dasselbe Konzept eines Kontos als Container für Nutzer und Gruppen. Die Identifizierung dieses Containers erfolgt anhand eines Domainnamens wie example.com. Für die Verwaltung von Nutzern, Gruppen und Authentifizierung können die beiden Produkte als gleichwertig betrachtet werden.

Cloud Identity und Google Workspace in einem einzigen Konto kombinieren

Da Cloud Identity und Google Workspace eine gemeinsame Plattform haben, können Sie über ein einziges Konto auf beide Produkte zugreifen.

Wenn Sie bereits ein Google Workspace-Konto verwalten und mehr Nutzern die Verwendung von Google Cloud ermöglichen möchten, sollten Sie nicht allen Nutzern eine Google Workspace-Lizenz zuweisen. Fügen Sie in diesem Fall Ihrem bestehenden Konto die Cloud Identity Gratisversion hinzu. Sie können dann ohne zusätzliche Kosten weitere Nutzer aufnehmen und entscheiden, welche Nutzer Zugriff auf Google Workspace haben sollen, indem Sie ihnen eine Google Workspace-Lizenz zuweisen.

Wenn Sie bereits ein Konto der Gratisversion oder ein Premium-Konto von Cloud Identity verwalten, möchten Sie bestimmten Nutzern möglicherweise die Berechtigung erteilen, Google Workspace zu verwenden. Anstatt für diese Nutzer separate Google Workspace-Konten zu erstellen, können Sie Google Workspace einem vorhandenen Cloud Identity-Konto hinzufügen. Nachdem Sie den ausgewählten Nutzern die Google Workspace-Lizenz zugewiesen haben, können sie die Anwendungen für Produktivität und Zusammenarbeit nutzen.

So wenige Konten wie möglich, aber so viele wie nötig verwenden

Damit Ihre Nutzer über Google Workspace zusammenarbeiten können und der Verwaltungsaufwand möglichst gering ausfällt, sollten Sie alle Nutzer über ein einziges Cloud Identity- oder Google Workspace-Konto verwalten und jedem einzelnen Nutzer ein eigenes Nutzerkonto bereitstellen. So wird sichergestellt, dass Einstellungen wie Passwortrichtlinien, die Einmalanmeldung (SSO) und die Bestätigung in zwei Schritten einheitlich auf alle Nutzer angewendet werden.

Trotz der Vorteile eines einzigen Cloud Identity- oder Google Workspace-Kontos können Sie durch die Verwendung mehrerer Konten die Flexibilität und die administrative Autonomie erhalten. Berücksichtigen Sie bei der Entscheidung, wie viele Cloud Identity- oder Google Workspace-Konten verwendet werden sollen, alle Anforderungen, die eine Verwendung mehrerer Konten nahelegen. Verwenden Sie dann die kleinstmögliche Anzahl von Cloud Identity- oder Google Workspace-Konten, die Ihren Anforderungen gerecht wird.

Separate Konten für Staging und Produktion verwenden

Bei den meisten Einstellungen, die Sie in Cloud Identity und in Google Workspace konfigurieren können, lässt sich der Bereich auswählen, für den die jeweilige Einstellung gelten soll. Sie können beispielsweise den geografischen Standort für Ihre Daten nach Nutzer, Gruppe oder Organisationseinheit angeben. Wenn Sie eine neue Konfiguration übernehmen möchten, können Sie zuerst einen kleinen Bereich (z. B. nach Nutzer) auswählen und überprüfen, ob die Konfiguration Ihren Erwartungen entspricht. Nachdem Sie die Konfiguration überprüft haben, können Sie dieselbe Einstellung für eine größere Anzahl von Gruppen oder Organisationseinheiten übernehmen.

Im Gegensatz zu den meisten Einstellungen hat das Einbinden eines Cloud Identity- oder Google Workspace-Kontos bei einem externen Identitätsanbieter (IdP) globale Auswirkungen:

  • Das Aktivieren der Einmalanmeldung (SSO) ist eine globale Einstellung, die für alle Nutzer außer Super Admins gilt.
  • Je nach externem IdP kann das Einrichten der Nutzerbereitstellung ebenfalls globale Auswirkungen haben. Eine versehentliche fehlerhafte Konfiguration beim externen IdP kann dazu führen, dass Nutzer unbeabsichtigt geändert, gesperrt oder sogar gelöscht werden.

Um diese Risiken zu vermindern, sollten Sie für Staging und Produktion separate Cloud Identity- oder Google Workspace-Konten haben:

  • Verwenden Sie das Staging-Konto, um mögliche risikoreiche Konfigurationsänderungen zu überprüfen, bevor Sie eine Änderung für Ihr Produktionskonto übernehmen.
  • Erstellen Sie in den Staging-Konten einige Testnutzer, die Sie und andere Administratoren zum Überprüfen von Konfigurationsänderungen verwenden können. Gewähren Sie Ihren Nutzern jedoch keinen Zugriff auf das Staging-Konto.

Wenn Sie separate Staging- und Produktionsinstanzen des externen IdP haben, gehen Sie so vor:

  • Binden Sie Ihr Cloud Identity- oder Google Workspace-Staging-Konto in die IdP-Staging-Instanz ein.
  • Binden Sie Ihr Cloud Identity- oder Google Workspace-Produktionskonto in die IdP-Produktionsinstanz ein.

Angenommen, Sie möchten beispielsweise eine Föderation mit Active Directory einrichten und zu Testzwecken eine separate Active Directory-Gesamtstruktur haben. In diesem Fall binden Sie Ihr Cloud Identity- oder Google Workspace-Staging-Konto in die Staging-Gesamtstruktur und das Cloud Identity- oder Google Workspace-Produktionskonto in Ihre Hauptgesamtstruktur ein. Wenden Sie wie im folgenden Diagramm dargestellt für DNS-Domains, Nutzer und Gruppen auf beide Gesamtstruktur/Konto-Paare denselben Zuordnungsansatz an:

Zuordnungsansatz für DNS-Domains, Nutzer und Gruppen in Active Directory

In Ihren Active Directory-Gesamtstrukturen und -Domains für Produktion und Staging werden möglicherweise DNS-Domains verwendet, bei denen Sie für Staging und Produktion nicht denselben Ansatz zur Domainzuordnung anwenden können. Erwägen Sie in diesem Fall die Registrierung weiterer User Principal Name-Suffixdomains (UPN) in Ihrer Staging-Gesamtstruktur.

Wenn Sie eine Föderation mit Azure Active Directory einrichten möchten, gehen Sie am besten entsprechend so vor:

  • Binden Sie das Cloud Identity- oder Google Workspace-Konto für das Staging in einen Staging-Mandanten von Azure Active Directory ein.
  • Binden Sie das Cloud Identity- oder Google Workspace-Konto für die Produktion in den Hauptmandanten von Azure Active Directory ein.

Wenden Sie denselben Zuordnungsansatz für DNS-Domains, Nutzer und Gruppen auf beide Mandanten/Konto-Paare an:

Zuordnungsansatz für DNS-Domains, Nutzer und Gruppen in Azure Active Directory

In Ihren Produktions- und Staging-Mandanten von Azure Active Directory werden möglicherweise DNS-Domains verwendet, bei denen Sie für Staging und Produktion nicht denselben Ansatz zur Domainzuordnung anwenden können. Erwägen Sie in diesem Fall, Ihrem Staging-Mandanten eine zusätzliche Domain hinzuzufügen.

Unterschiedliche DNS-Domains für Cloud Identity- und Google Workspace-Konten verwenden

Wenn Sie Ihrem Cloud Identity- oder Google Workspace-Konto zum ersten Mal eine Domain wie example.com hinzufügen, müssen Sie bestätigen, dass Sie der Inhaber der Domain sind. Nachdem Sie eine Domain hinzugefügt und bestätigt haben, können Sie Subdomains wie marketing.example.com und finance.example.com hinzufügen, ohne jede Subdomain einzeln bestätigen zu müssen.

Wenn Sie jedoch Subdomains hinzufügen, ohne sie zu bestätigen, können Konflikte auftreten, falls Sie ein anderes Cloud Identity- oder Google Workspace-Konto haben, das diese Subdomain bereits verwendet. Um solche Konflikte zu vermeiden, sollten Sie für jedes Konto separate Domains verwenden. Wenn Sie beispielsweise zwei Cloud Identity- oder Google Workspace-Konten benötigen, sollten Sie die Verwendung von zwei Domains vermeiden, bei denen eine Domain eine Subdomain der anderen ist. Verwenden Sie stattdessen zwei Domains, die keine Subdomains voneinander sind. Diese Vorgehensweise gilt für die primäre Domain und für sekundäre Domains.

Google Workspace und Google Cloud nicht voneinander trennen

Wenn Sie Google Workspace bereits verwenden, haben einige Nutzer in Ihrem Google Workspace-Konto möglicherweise Super Admin-Berechtigungen erhalten, damit sie Verwaltungsaufgaben übernehmen können.

Nutzer mit Super Admin-Berechtigungen erhalten implizit die Berechtigung, die IAM-Richtlinie (Cloud Identity and Access Management) des Organisationsknotens anzupassen. Mit dieser Berechtigung können sich Super Admins selbst die Rolle "Organisationsadministrator" oder eine andere Rolle in der Google Cloud-Organisation zuweisen. Hat ein Nutzer Super Admin-Zugriff auf ein Cloud Identity- oder Google Workspace-Konto haben, kann er auch das Konto, die zugehörige Google Cloud-Organisation und alle zugehörigen Ressourcen löschen. Sie müssen daher davon ausgehen, dass Super Admins uneingeschränkten Zugriff auf alle Ressourcen innerhalb einer Organisation haben.

Die Tatsache, dass Super Admins auch Organisationsadministratoren sind, kann ein Sicherheitsrisiko darstellen, wenn sich Ihre bestehenden Google Workspace-Administratoren von den Nutzern unterscheiden, die für die Verwaltung Ihrer Google Cloud-Organisation zuständig sein werden. In diesem Fall können Sie ein separates Cloud Identity-Konto für Google Cloud erstellen, um den Zugriff auf Google Cloud-Ressourcen auf Google Workspace-Super Admins zu beschränken. Die Trennung von Google Workspace und Google Cloud kann mehrere unbeabsichtigte Folgen haben.

Sie können beispielsweise versuchen, separate Nutzer im Cloud Identity-Konto zu erstellen und dann den Zugriff auf das Cloud Identity-Konto auf Nutzer der Google Cloud-Organisation zu beschränken. Dadurch wird sichergestellt, dass Ihre Google Cloud-Bereitstellung und Google Workspace vollständig isoliert sind. Das Duplizieren von Nutzern beeinträchtigt jedoch sowohl die Nutzererfahrung als auch den Verwaltungsaufwand. Außerdem könnten Sie keine von Google Cloud gesendeten Benachrichtigungs-E-Mails empfangen, da sich die von Cloud Identity verwendete Domain von der für Google Workspace verwendeten Domain unterscheiden muss und somit nicht für die Weiterleitung von E-Mails geeignet ist.

Wenn in Ihrer Google Cloud-Organisation stattdessen ein Verweis auf die Nutzer aus dem Google Workspace-Konto besteht, gefährdet dies die Isolation zwischen Google Workspace und Google Cloud:

Verweise auf Nutzer aus dem Google Workspace-Konto in Ihrer Google Cloud-Organisation

Google Workspace-Super Admins haben die Möglichkeit, eine domainweite Bevollmächtigung zu verwenden, um die Identität eines beliebigen Nutzers im gleichen Google Workspace-Konto anzunehmen. Ein Super Admin kann seine erweiterten Berechtigungen nutzen, um wieder Zugriff auf Google Cloud zu erhalten.

Ein wirksamerer Ansatz als die Verwendung separater Konten ist die Aufteilung der Zuständigkeiten zwischen Google Workspace- und Google Cloud-Administratoren, um die Anzahl der Super Admins zu reduzieren:

Externen IdP bei Verwendung der Einmalanmeldung (SSO) sichern

Mit Cloud Identity und Google Workspace können Sie die Einmalanmeldung (SSO) bei Ihrem externen IdP einrichten, z. B. Active Directory, Azure Active Directory oder Okta, um nur ein paar zu nennen. Wenn die Einmalanmeldung (SSO) aktiviert ist, vertrauen Cloud Identity und Google Workspace darauf, dass der externe IdP Nutzer im Namen von Google authentifiziert.

Das Aktivieren der Einmalanmeldung bietet mehrere Vorteile:

  • Nutzer können sich mit ihren vorhandenen Anmeldedaten bei Google-Diensten anmelden.
  • Nutzer müssen ihre Passwörter nicht noch einmal eingeben, wenn sie sich bereits für eine Sitzung angemeldet haben.
  • Sie können für alle Anwendungen und alle Google-Dienste konsistente Richtlinien für die Multi-Faktor-Authentifizierung anwenden.

Das Aktivieren der Einmalanmeldung (SSO) ist jedoch auch mit Risiken verbunden. Wenn die Einmalanmeldung (SSO) aktiviert ist und ein Nutzer authentifiziert werden muss, leitet Cloud Identity oder Google Workspace ihn an Ihren externen IdP weiter. Nach der Authentifizierung des Nutzers gibt der IdP eine SAML-Assertion an Google zurück, mit der die Identität des Nutzers angegeben wird. Die SAML-Assertion ist signiert. Daher kann Google die Authentizität der SAML-Assertion überprüfen und bestätigen, dass der richtige Identitätsanbieter verwendet wurde. Mit Cloud Identity oder Google Workspace lässt sich jedoch nicht prüfen, ob der IdP die richtige Authentifizierungsentscheidung getroffen und die Identität des Nutzers korrekt angegeben hat.

Wenn die Einmalanmeldung (SSO) aktiviert ist, hängt die allgemeine Sicherheit und Integrität Ihrer Google-Bereitstellung von der Sicherheit und Integrität Ihres IdP ab. Ihr Cloud Identity- oder Google Workspace-Konto und alle Ressourcen, die von den Nutzern abhängig sind, die vom Konto verwaltet werden, sind einem Risiko ausgesetzt, wenn für eine der folgenden Ressourcen eine unsichere Konfiguration besteht:

  • Der IdP selbst
  • Die Maschinen, auf denen der Anbieter ausgeführt wird
  • Die Nutzerdatenbank, von der der Anbieter Nutzerinformationen abruft
  • Jedes andere System, von dem der Anbieter abhängig ist

Um zu verhindern, dass die Einmalanmeldung (SSO) zu einem schwachen Glied in Ihrer Sicherheitsstruktur wird, müssen der IdP und alle davon abhängigen Systeme sicher konfiguriert sein:

  • Schränken Sie die Anzahl der Nutzer mit Administratorzugriff auf den IdP oder auf eines der Systeme, von denen der Anbieter abhängig ist, ein.
  • Gewähren Sie Nutzer, denen Sie keine Super Admin-Berechtigungen in Cloud Identity oder in Google Workspace gewähren würden, keinerlei Administratorzugriff auf diese Systeme.
  • Verwenden Sie die Einmalanmeldung nicht, wenn Sie nicht sicher sind, welche Sicherheitskontrollen für Ihren externen IdP vorhanden sind.

Zugriff auf die DNS-Zonen sichern

Cloud Identity- und Google Workspace-Konten werden anhand eines primären DNS-Domainnamens identifiziert. Wenn Sie ein neues Cloud Identity- oder Google Workspace-Konto erstellen, müssen Sie die Inhaberschaft der DNS-Domain bestätigen, indem Sie in der entsprechenden DNS-Zone einen speziellen DNS-Eintrag erstellen.

Die Wichtigkeit des DNS und die Auswirkungen auf die Gesamtsicherheit Ihrer Google-Bereitstellung reichen über den Anmeldevorgang hinaus:

  • Google Workspace verwendet DNS-MX-Einträge zum Weiterleiten von E-Mails. Durch Ändern dieser MX-Einträge kann ein Angreifer E-Mails an einen anderen Server weiterleiten und auf vertrauliche Informationen zugreifen.

  • Wenn ein Angreifer der DNS-Zone Einträge hinzufügen kann, ist es ihm dann unter Umständen möglich, das Passwort eines Super Admin-Nutzers zurücksetzen und auf das Konto zugreifen.

Damit DNS nicht zu einem schwachen Glied in Ihrer Sicherheitsstruktur wird, muss der DNS-Server sicher konfiguriert sein:

  • Begrenzen Sie die Anzahl der Nutzer mit Administratorzugriff auf den DNS-Server, der zum Verwalten der für Cloud Identity oder Google Workspace verwendeten primären Domain dient.

  • Gewähren Sie Nutzern, denen Sie keine Super Admin-Berechtigungen in Cloud Identity oder Google Workspace gewähren würden, keinerlei Administratorzugriff auf Ihren DNS-Server.

  • Wenn Sie in Google Cloud eine Arbeitslast mit Sicherheitsanforderungen bereitstellen möchten, die von Ihrer vorhandenen DNS-Infrastruktur nicht erfüllt werden, sollten Sie für diese Arbeitslast eine neue DNS-Domain registrieren, die separate DNS-Server oder einen verwalteten DNS-Dienst verwendet.

Audit-Logs nach BigQuery exportieren

Cloud Identity und Google Workspace bieten mehrere Audit-Logs, um Änderungen an der Konfiguration und andere Aktivitäten nachzuverfolgen, die für die Sicherheit Ihres Cloud Identity- oder Google Workspace-Kontos relevant sein könnten. In der folgenden Tabelle finden Sie eine Zusammenfassung zu diesen Audit-Logs.

Log Erfasste Aktivitäten
Administrator In der Google Admin-Konsole durchgeführte Aktionen
Anmelden Erfolgreiche, fehlgeschlagene und verdächtige Anmeldeversuche bei Ihrer Domain
Token Instanzen zum Autorisieren oder Widerrufen des Zugriffs auf mobile Anwendungen oder Webanwendungen von Drittanbietern
Gruppen Änderungen an Gruppen und Gruppenmitgliedschaften

Sie können auf diese Audit-Logs entweder über die Admin-Konsole oder über die Reports API zugreifen. Bei den meisten Audit-Logs werden die Daten sechs Monate lang aufbewahrt.

Wenn Sie in einer regulierten Branche tätig sind, reicht die Aufbewahrung von Audit-Daten für sechs Monate möglicherweise nicht aus. Um Daten für einen längeren Zeitraum aufzubewahren, konfigurieren Sie Audit-Logs für den Export nach BigQuery.

Verwenden Sie ein dediziertes Google Cloud-Projekt für das BigQuery-Dataset, um das Risiko eines unbefugten Zugriffs auf die exportierten Audit-Logs einzuschränken. Damit die Audit-Daten nicht manipuliert oder gelöscht werden können, gewähren Sie den Zugriff auf das Projekt und das Dataset auf Grundlage der geringsten Berechtigung.

Die Audit-Logs von Cloud Identity und Google Workspace dienen als Ergänzung zu den Logs von Cloud-Audit-Logging. Wenn Sie auch BigQuery zum Erfassen von Logs aus Cloud-Audit-Logging und anderen anwendungsspezifischen Audit-Logs verwenden, können Sie Anmeldeereignisse mit Aktivitäten in Beziehung setzen, die ein Nutzer in Google Cloud oder in Ihren Anwendungen ausgeführt hat. Audit-Daten aus mehreren Quellen zueinander in Beziehung zu setzen, hilft Ihnen dabei, verdächtige Aktivitäten zu erkennen und zu analysieren.

Für das Einrichten von BigQuery-Exporten ist eine Google Workspace Enterprise-Lizenz erforderlich. Nachdem Sie die Haupt-Audit-Logs eingerichtet haben, werden diese für alle Nutzer exportiert, einschließlich der Nutzer ohne Google Workspace-Lizenz. Bestimmte Logs wie die Audit-Logs von Drive und Mobile werden für Nutzer exportiert, die mindestens eine Google Workspace Business-Lizenz haben.

Wenn Sie für die meisten Ihrer Nutzer die Cloud Identity Gratisversion verwenden, sind Exporte nach BigQuery trotzdem möglich. Fügen Sie Ihrem vorhandenen Cloud Identity-Konto dazu Google Workspace Enterprise hinzu und erwerben Sie Google Workspace-Lizenzen für eine ausgewählte Gruppe von Administratoren.

Organisationen

Mithilfe von Organisationen lassen sich Ressourcen in einer Hierarchie von Projekten und Ordnern organisieren, wobei der Organisationsknoten der Stamm ist. Organisationen sind mit einem Cloud Identity- oder Google Workspace-Konto verknüpft und ihr Name wird aus dem primären Domainnamen des zugehörigen Kontos abgeleitet. Die Erstellung einer Organisation erfolgt automatisch, wenn ein Nutzer des Cloud Identity- oder Google Workspace-Kontos ein erstes Projekt erstellt.

Jedes Cloud Identity- oder Google Workspace-Konto kann nur eine Organisation haben. Tatsächlich ist es nicht möglich, eine Organisation ohne entsprechendes Konto zu erstellen. Trotz dieser Abhängigkeit können Sie Nutzern aus mehreren verschiedenen Konten Zugriff auf Ressourcen in einer einzelnen Organisation gewähren:

Nutzern aus mehreren Konten Zugriff auf Ressourcen gewähren

Dank der Flexibilität, für Nutzer aus verschiedenen Cloud Identity- oder Google Workspace-Konten Verweise einzurichten, lassen sich Konten und Organisationen separat behandeln. Sie können die Entscheidung, wie viele Cloud Identity- oder Google Workspace-Konten Sie zur Verwaltung Ihrer Nutzer benötigen, getrennt von der Entscheidung treffen, wie viele Organisationen Sie benötigen, um Ihre Ressourcen zu verwalten.

Die Anzahl der Organisationen, die Sie erstellen, und deren jeweiliger Zweck können sich erheblich auf Ihren Sicherheitsstatus, die Autonomie Ihrer Teams und Abteilungen sowie die Konsistenz und Effizienz Ihrer Verwaltung auswirken.

In den folgenden Abschnitten werden Best Practices zur Entscheidung beschrieben, wie viele Organisationen verwendet werden sollten.

So wenige Organisationen wie möglich, aber so viele wie nötig verwenden

Mithilfe der Ressourcenhierarchie einer Organisation lässt sich der Aufwand für die Verwaltung von IAM-Richtlinien und Organisationsrichtlinien verringern. Dazu werden die Vorteile der Richtlinienübernahme genutzt. Durch das Konfigurieren von Richtlinien auf Ordner- oder Organisationsebene stellen Sie sicher, dass Richtlinien konsistent auf eine untergeordnete Ressourcenhierarchie angewendet werden, und vermeiden wiederkehrende Konfigurationsarbeiten. Verwenden Sie möglichst wenige Organisationen, um Ihren Verwaltungsaufwand so gering wie möglich zu halten.

Im Gegensatz dazu können Sie durch die Verwendung mehrerer Organisationen für zusätzliche Flexibilität und administrative Autonomie sorgen. In den folgenden Abschnitten wird beschrieben, wann Sie eine solche zusätzliche Flexibilität oder Autonomie benötigen könnten.

In jedem Fall sollten Sie bei der Entscheidung, wie viele Organisationen Sie verwenden möchten, alle Anforderungen berücksichtigen, die die Verwendung mehrerer Organisationen nahelegen. Verwenden Sie dann die kleinstmögliche Anzahl Organisationen, die Ihren Anforderungen gerecht wird.

Organisationen verwenden, um Verwaltungsbefugnisse abzugrenzen

Innerhalb einer Ressourcenhierarchie können Sie Berechtigungen auf Ressourcen-, Projekt- oder Ordnerebene erteilen. Die oberste Ebene, auf der Sie einem Nutzer Berechtigungen erteilen können, ist die Organisation.

Ein Nutzer, dem die Rolle "Organisationsadministrator" auf Organisationsebene zugewiesen wurde, hat volle Kontrolle über die Organisation, ihre Ressourcen und ihre IAM-Richtlinien. Ein Organisationsadministrator kann die Kontrolle über jede Ressource innerhalb der Organisation übernehmen und den Administratorzugriff auf jeden anderen Nutzer übertragen.

Die Möglichkeiten eines Organisationsadministrators sind jedoch auf die Organisation beschränkt, wodurch die Organisation zum übergeordneten Bereich für Verwaltungsbefugnisse wird:

  • Ein Organisationsadministrator kann nur dann auf Ressourcen in anderen Organisationen zugreifen, wenn er ausdrücklich die Berechtigung dazu erhalten hat.
  • Kein Nutzer außerhalb der Organisation kann einem Organisationsadministrator dieser Organisation die Kontrolle entziehen.

Die richtige Anzahl von Organisationen hängt von der Anzahl unabhängiger Gruppen von Administratoren in Ihrem Unternehmen ab:

  • Wenn Ihr Unternehmen nach Funktionen organisiert ist, werden möglicherweise alle Google Cloud-Bereitstellungen von einer einzigen Abteilung betreut.
  • Wenn Ihr Unternehmen nach Geschäftsbereichen organisiert ist oder mehrere selbstständige Tochtergesellschaften besitzt, ist möglicherweise mehr als eine Abteilung zuständig.

Wenn eine einzige Abteilung für die Betreuung von Google Cloud-Bereitstellungen zuständig ist, empfiehlt es sich, einen einzelnen Google Cloud-Organisationsknoten zu verwenden. Verwenden Sie innerhalb der Organisation Ordner, um Ressourcen zu strukturieren und anderen Teams und Abteilungen unterschiedliche Zugriffsmöglichkeiten zu gewähren.

Wenn Sie mit mehreren unabhängigen Abteilungen arbeiten, kann der Versuch, die Verwaltung mithilfe einer einzigen Organisation zu zentralisieren, zu Problemen führen:

  • Wenn Sie die Zuständigkeit für die Verwaltung der Organisation einer einzelnen Abteilung übertragen, stoßen Sie möglicherweise auf Widerstände anderer Abteilungen.
  • Wenn Sie mehrere Teams oder Abteilungen eine Organisation gemeinsam verwalten lassen, kann es schwierig sein, eine konsistente Ressourcenhierarchie beizubehalten und dafür zu sorgen, dass IAM-Richtlinien und Organisationsrichtlinien für alle Ressourcen einheitlich verwendet werden.

Um solche Probleme zu vermeiden, sollten Sie mehrere Organisationen verwenden und in jeder Organisation separate Ordnerstrukturen erstellen. Durch die Verwendung separater Organisationen legen Sie Grenzen zwischen verschiedenen Gruppen von Administratoren fest und grenzen so deren Verwaltungsbefugnisse ein.

Separate Staging-Organisation verwenden

Um die Konsistenz sicherzustellen und sich wiederholende Konfigurationsarbeiten zu vermeiden sollten Sie Ihre Projekte in einer Ordnerhierarchie organisieren sowie IAM-Richtlinien und Organisationsrichtlinien auf Ordner- oder Organisationsebene anwenden.

Es gibt einen Nachteil, wenn Richtlinien für viele Projekte und Ressourcen gelten. Jede Änderung an der Richtlinie selbst oder an der Ressourcenhierarchie, für die die Richtlinie gilt, kann weitreichende und unbeabsichtigte Folgen haben. Um dieses Risiko zu vermindern, sollten Sie Änderungen an Richtlinien testen, bevor Sie sie in Ihrer Hauptorganisation übernehmen.

Wir empfehlen Ihnen, eine separate Staging-Organisation zu erstellen. Mit dieser Organisation können Sie Änderungen in der Ressourcenhierarchie, an IAM-Richtlinien, an Organisationsrichtlinien oder andere Konfigurationen testen, die sich möglicherweise auf die gesamte Organisation auswirken, z. B. auf Zugriffsebenen und Richtlinien.

Damit die Ergebnisse der Tests oder Versuche, die in der Staging-Organisation durchgeführt werden, auch für die Produktionsorganisation gelten, müssen Sie die Staging-Organisation so konfigurieren, dass sie dieselbe Ordnerstruktur wie Ihre Hauptorganisation hat, jedoch nur mit einer kleinen Anzahl von Projekten. Die IAM- und Organisationsrichtlinien in der Staging-Organisation sollten jederzeit den Richtlinien Ihrer Produktionsorganisation oder der nächsten Version der Richtlinien entsprechen, die Sie auf Ihre Produktionsorganisation anwenden möchten.

Wie das folgende Diagramm zeigt, verwenden Sie Ihr Cloud Identity- oder Google Workspace-Staging-Konto als Grundlage für die Staging-Organisation. Sie verwenden das Staging-Konto (oder den externen IdP, in den Ihr Staging-Konto eingebunden ist), um dedizierte Testnutzer und eine Gruppenstruktur zu erstellen, die die Gruppen widerspiegelt, die Sie in Ihrem Cloud Identity- oder Google Workspace-Produktionskonto verwenden. Sie können diese dedizierten Testnutzer und Gruppen dann verwenden, um IAM-Richtlinien ohne Beeinträchtigung der vorhandenen Nutzer zu testen.

Konto als Grundlage für das Staging verwenden

Verwendung einer separaten Testorganisation vermeiden

Für jede Produktionsarbeitslast, die Sie in Google Cloud bereitstellen möchten, benötigen Sie wahrscheinlich eine oder mehrere Testumgebungen, die Ihre Entwickler- und DevOps-Teams nutzen können, um neue Releases zu validieren.

Aus Sicherheitsgründen sollten Sie Ihre Testumgebungen sauber von Ihren Produktionsumgebungen trennen. So lässt sich verhindern, dass nicht getestete Releases versehentlich Produktionsarbeitslasten beeinträchtigen. Ebenso bestehen für beide Arten von Umgebungen unterschiedliche Anforderungen an die IAM-Richtlinien. Damit Sie beispielsweise Entwicklern und Testern die erforderliche Flexibilität gewähren können, sind die Sicherheitsanforderungen für Ihre Testumgebungen möglicherweise wesentlich geringer als für Ihre Produktionsumgebungen.

Wie das folgende Diagramm zeigt, sollen die Testumgebungen Ihren Produktionsumgebungen aus Sicht der Konfiguration so ähnlich wie möglich sein. Mit jeder Abweichung erhöht sich das Risiko, dass eine Bereitstellung, die in der Testumgebung ordnungsgemäß funktioniert hat, in der Produktionsumgebung fehlschlägt.

Testumgebungen ähnlich wie Produktionsumgebungen gestalten

Verwenden Sie zum Verwalten der Test- und Produktionsumgebungen Ordner innerhalb derselben Organisation. So erreichen Sie ein Gleichgewicht zwischen Isolation und Einheitlichkeit der Umgebungen:

  • Wenden Sie alle IAM-Richtlinien oder Organisationsrichtlinien an, die gleichermaßen in allen Umgebungen auf Organisationsebene gelten, oder verwenden Sie dazu einen gemeinsamen übergeordneten Ordner.
  • Verwenden Sie die einzelnen Ordner, um IAM-Richtlinien und Organisationsrichtlinien zu verwalten, die sich je nach Art der Umgebung voneinander unterscheiden.

Verwenden Sie Ihre Staging-Organisation nie zum Verwalten von Testumgebungen. Testumgebungen sind entscheidend für die Produktivität von Entwickler- und DevOps-Teams. Durch die Verwaltung solcher Umgebungen in der Staging-Umgebung würde Ihre Fähigkeit eingeschränkt, die Staging-Organisation für Tests und Versuche mit den Richtlinienänderungen zu verwenden. Eine solche Änderung könnte die Arbeit dieser Teams beeinträchtigen. Kurz gesagt, wenn Sie eine Staging-Organisation zum Verwalten von Testumgebungen verwenden, gefährden Sie den Zweck Ihrer Staging-Organisation.

Separate Organisation zum Testen verwenden

Damit Sie Google Cloud optimal nutzen können, sollten sich Ihre Entwickler-, DevOps- und Betriebsteams mit der Plattform vertraut machen und durch das Lesen von Anleitungen Erfahrung sammeln. Bestärken Sie sie darin, neue Features und Dienste auszuprobieren.

Verwenden Sie eine separate Organisation als Sandbox-Umgebung, um diese Arten von experimentellen Aktivitäten zu unterstützen. Durch Verwenden einer separaten Organisation können Sie dafür sorgen, dass Tests nicht durch Richtlinien, Konfigurationen oder Automatisierungen beeinflusst werden, die Sie in Ihrer Produktionsorganisation verwenden.

Verwenden Sie für Tests nicht Ihre Staging-Organisation. Ihre Staging-Umgebung sollte IAM- und Organisationsrichtlinien haben, die den Richtlinien der Produktionsorganisation gleichen. Daher unterliegt die Staging-Umgebung wahrscheinlich denselben Einschränkungen wie Ihre Produktionsumgebung. Gleichzeitig würde eine Lockerung der Richtlinien zur Ermöglichung von Tests den Zweck Ihrer Staging-Organisation untergraben.

Damit die Ordnung in Ihrer Testorganisation nicht verloren geht, übermäßige Kosten anfallen oder ein Sicherheitsrisiko entsteht, sollten Sie Richtlinien vorgeben, mit denen festgelegt wird, wie Teams die Organisation verwenden dürfen und wer für die Pflege der Organisation zuständig ist. Darüber hinaus sollten Sie die Automatisierung so einrichten, dass Ressourcen oder sogar ganze Projekte nach einer bestimmten Anzahl von Tagen automatisch gelöscht werden.

Wie das folgende Diagramm zeigt, wird beim Erstellen einer Organisation für Tests zuerst ein dediziertes Cloud Identity-Konto eingerichtet. Anschließend verwenden Sie die vorhandenen Nutzer aus Ihrem Cloud Identity- oder Google Workspace-Hauptkonto, um Nutzern Zugriff auf die Testorganisation zu gewähren.

Testorganisation

Zum Verwalten des zusätzlichen Cloud Identity-Kontos benötigen Sie mindestens ein Super Admin-Nutzerkonto im Cloud Identity-Konto. Informationen zum Sichern dieser Super Admin-Nutzerkonten finden Sie unter Best Practices für Super Admin-Konten.

Vertrauensstellungen mithilfe von domaineingeschränkter Freigabe erzwingen

Mit IAM-Richtlinien können Sie jede gültige Google-Identität als Mitglied hinzufügen. Wenn Sie also die IAM-Richtlinie einer Ressource, eines Projekts, eines Ordners oder einer Organisation bearbeiten, können Sie Mitglieder aus verschiedenen Quellen hinzufügen. Dazu gehören:

  • Nutzer aus dem Cloud Identity- oder Google Workspace-Konto, mit dem die Organisation verknüpft ist, sowie aus Dienstkonten derselben Organisation
  • Nutzer aus anderen Cloud Identity- oder Google Workspace-Konten
  • Dienstkonten von anderen Organisationen
  • Privatnutzerkonten, einschließlich gmail.com-Nutzer- und -Privatnutzerkonten, die eine geschäftliche E-Mail-Adresse verwenden

Die Möglichkeit, Verweise auf Nutzer aus verschiedenen Quellen zu verwenden, ist für Szenarien und Projekte hilfreich, bei denen Sie mit Tochtergesellschaften oder anderen Unternehmen zusammenarbeiten müssen. In den meisten anderen Fällen ist es am besten, IAM-Richtlinien so einzuschränken, dass nur Mitglieder aus vertrauenswürdigen Quellen zugelassen werden.

Verwenden Sie die domaineingeschränkte Freigabe, um eine Reihe von vertrauenswürdigen Cloud Identity- oder Google Workspace-Konten zu definieren, aus denen Sie das Hinzufügen von Mitgliedern zu IAM-Richtlinien zulassen möchten. Definieren Sie diese Organisationsrichtlinie entweder auf Organisationsebene, sodass sie für alle Projekte gilt, oder auf Ebene eines Ordners am oberen Ende der Ressourcenhierarchie, damit bestimmte Projekte ausgeschlossen werden können.

Wenn Sie separate Cloud Identity- oder Google Workspace-Konten und Organisationen verwenden, um Staging-, Produktions- und Testumgebungen voneinander zu trennen, verwenden Sie Richtlinien für die domaineingeschränkte Freigabe, um die in der folgenden Tabelle aufgeführte Trennung zu erzwingen:

Organisation Vertrauenswürdiges Cloud Identity- oder Google Workspace-Konto
Phase Staging
Produktion Produktion
Tests Produktion

Neutrale Domainnamen für Organisationen verwenden

Organisationen lassen sich anhand eines DNS-Domainnamens wie example.com identifizieren. Der Domainname wird vom primären Domainnamen des verknüpften Cloud Identity- oder Google Workspace-Kontos abgeleitet.

Wenn im gesamten Unternehmen ein kanonischer DNS-Domainname verwendet wird, sollten Sie diese Domain in Ihrem Cloud Identity- oder Google Workspace-Produktionskonto als primäre Domain verwenden. Durch Verwendung des kanonischen DNS-Namens stellen Sie sicher, dass die Mitarbeiter den Namen des Organisationsknotens leicht erkennen können.

Wenn Ihr Unternehmen mehrere Tochtergesellschaften hat oder verschiedene Marken besitzt, gibt es unter Umständen keinen kanonischen Domainnamen. Anstatt eine der vorhandenen Domains willkürlich auszuwählen, sollten Sie die Registrierung einer neuen DNS-Domain in Erwägung ziehen, die neutral und für die Verwendung durch Google Cloud bestimmt ist. Durch Verwendung eines neutralen DNS-Namens vermeiden Sie, dass eine bestimmte Marke, Tochtergesellschaft oder Abteilung in Ihrem Unternehmen bevorzugt wird, denn dies könnte sich negativ auf die Akzeptanz der Cloud auswirken. Fügen Sie Ihre anderen markenspezifischen Domains als sekundäre Domains hinzu, damit sie in Nutzer-IDs und für die Einmalanmeldung (SSO) verwendet werden können.

Rechnungskonten in allen Google Cloud-Organisationen verwenden

Über Rechnungskonten wird festgelegt, wer für eine bestimmte Gruppe von Google Cloud-Ressourcen bezahlt. Rechnungskonten können zwar außerhalb einer Google Cloud-Organisation vorhanden sein, sind aber meistens einer Organisation zugeordnet.

Wenn Rechnungskonten mit einer Organisation verknüpft sind, werden sie als Unterressource der Organisation betrachtet und unterliegen den in der Organisation definierten IAM-Richtlinien. Am wichtigsten ist, dass Sie mithilfe der IAM-Abrechnungsrollen festlegen können, welche Nutzer oder Gruppen ein Konto verwalten oder verwenden dürfen.

Ein Nutzer mit der Rolle Billing Account User kann ein Projekt mit einem Rechnungskonto verknüpfen, wodurch die Ressourcen diesem Konto in Rechnung gestellt werden. Das Verknüpfen eines Projekts mit einem Rechnungskonto funktioniert innerhalb derselben Organisation, aber auch organisationsübergreifend.

Wenn Sie mehrere Organisationen verwenden, können Sie die Tatsache zu Ihrem Vorteil nutzen, dass Rechnungskonten organisationsübergreifend verwendet werden können. So können Sie unabhängig von der erforderlichen Anzahl der Organisationen entscheiden, wie viele Rechnungskonten Sie benötigen.

Die richtige Anzahl von Rechnungskonten hängt ausschließlich von Ihren kommerziellen oder vertraglichen Anforderungen wie Währung, Zahlungsprofil und der Anzahl der erforderlichen separaten Rechnungen ab. Wie bei Konten und Organisationen möchten Sie die kleinstmögliche Anzahl von Rechnungskonten verwenden, die Ihren Anforderungen gerecht wird, um die Komplexität so gering wie möglich zu halten.

Wenn Sie die Gesamtkosten auf mehrere Organisationen aufteilen möchten, müssen Sie Ihr Rechnungskonto so konfigurieren, dass Abrechnungsdaten nach BigQuery exportiert werden. Jeder nach BigQuery exportierte Datensatz enthält nicht nur den Projektnamen und die ID, sondern auch die ID der Organisation, mit der das Projekt verknüpft ist (im Feld project.ancestry_numbers).

Nächste Schritte