Best Practices für die Planung von Konten und Organisationen

Last reviewed 2023-02-27 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 keinem Nutzer Administratorzugriff auf diese Systeme, dem Sie auch keine Super Admin-Berechtigungen in Cloud Identity oder in Google Workspace gewähren würden.
  • 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 keinem Nutzer Administratorzugriff auf Ihren DNS-Server, dem Sie nicht auch Super Admin-Berechtigungen in Cloud Identity oder Google Workspace gewähren würden.

  • 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, können Sie trotzdem Exporte nach BigQuery durchführen. 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 una