Ressourcenhierarchie für Zugriffssteuerung verwenden

Hinweis: Sie können jetzt Ablehnungsrichtlinien verwenden, um zu verhindern, dass Hauptkonten bestimmte Berechtigungen verwenden. Die Verwendung von Ablehnungsrichtlinien kann dazu führen, dass die auf dieser Seite beschriebenen Features anders funktionieren.

Google Cloud-Ressourcen sind hierarchisch organisiert, wobei der Organisationsknoten der Hauptknoten in der Hierarchie ist. Die Projekte sind der Organisation untergeordnet und die anderen Ressourcen sind Projekten untergeordnet. Sie können "allow"-Richtlinien auf verschiedenen Ebenen der Ressourcenhierarchie festlegen. Ressourcen übernehmen die "allow"-Richtlinien der übergeordneten Ressource. Die geltende "allow"-Richtlinie für eine Ressource ist die Kombination aus der für diese Ressource festgelegten "allow"-Richtlinie und der vom übergeordneten Element übernommenen "allow"-Richtlinie.

Auf dieser Seite werden einige Beispiele für die Übernahme der "allow"-Richtlinien beschrieben und die Best Practices erklärt, die berücksichtigt werden müssen, wenn bei der IAM-Bereitstellung (Identity and Access Management) Ressourcen erstellt werden.

Vorbereitung

• Machen Sie sich mit den grundlegenden Konzepten von IAM vertraut, insbesondere der Google Cloud-Ressourcenhierarchie.

Hintergrund

Im folgenden Diagramm ist ein Beispiel für eine Google Cloud-Ressourcenhierarchie dargestellt.

Mit IAM können Sie "allow"-Richtlinien auf den folgenden Ebenen der Ressourcenhierarchie festlegen:

• Organisationsebene: Die Organisationsressource steht für Ihr Unternehmen. IAM-Rollen, die auf dieser Ebene zugewiesen werden, werden von allen Ressourcen innerhalb der Organisation übernommen. Weitere Informationen finden Sie unter Zugriffssteuerung für Organisationen mit IAM.

• Ordnerebene. Ordner können Projekte, andere Ordner oder eine Kombination aus beiden enthalten. Auf der höchsten Ordnerebene zugewiesene Rollen werden von Projekten oder anderen Ordnern übernommen, die im übergeordneten Ordner enthalten sind. Weitere Informationen finden Sie unter Zugriffssteuerung für Ordner mit IAM.

• Projektebene: Projekte stellen eine Vertrauensgrenze in Ihrem Unternehmen dar. Für Dienste in einem Projekt besteht eine standardmäßige Vertrauensgrenze. Zum Beispiel können App Engine-Instanzen auf Cloud Storage-Buckets innerhalb eines Projekts zugreifen. Auf Projektebene zugewiesene IAM-Rollen werden von Ressourcen in diesem Projekt übernommen. Weitere Informationen finden Sie unter Zugriffssteuerung für Projekte mit IAM.

• Ressourcenebene: Zusätzlich zu den vorhandenen Cloud Storage- und BigQuery-ACL-Systemen werden untergeordnete Rollen durch Ressourcen wie Genomics-Datasets, Pub/Sub-Themen und Compute Engine-Instanzen unterstützt. Sie können so bestimmten Nutzern die Berechtigung für eine einzelne Ressource in einem Projekt gewähren.

"allow"-Richtlinien sind hierarchisch und gelten in der Struktur von oben nach unten. Die geltende "allow"-Richtlinie für eine Ressource ist die Kombination aus der für diese Ressource festgelegten "allow"-Richtlinie und der vom übergeordneten Element übernommenen "allow"-Richtlinie.

Die folgenden Beispiele zeigen, wie die Übernahme der "allow"-Richtlinie in der Praxis funktioniert.

Beispiel: Pub/Sub

In Pub/Sub sind Themen und Abonnements die Ressourcen eines Projekts. Nehmen wir an, project_1 enthält topic_a. Wenn Sie eine "allow"-Richtlinie für project_1 festlegen, durch die [e-mail] die Bearbeiterrolle zugewiesen wird, und eine "allow"-Richtlinie für topic_a, durch die [e-mail] die Publisher-Rolle zugewiesen wird, weisen Sie effektiv die Bearbeiterrolle [e-mail] und die Publisher-Rolle [e-mail] für topic_a zu.

Das folgende Diagramm veranschaulicht das vorherige Beispiel.

Die Inhaber-, Bearbeiter- und Betrachterrollen sind konzentrisch, was bedeutet, dass die Inhaberrolle die Berechtigungen in der Bearbeiterrolle und die Bearbeiterrolle die Berechtigungen der Betrachterrolle enthält. Wenn Sie eine weiter gefasste und eine begrenzte Rolle (zum Beispiel "Bearbeiter" und "Betrachter") der gleichen Person zuweisen, wird ihr nur die weiter gefasste Rolle zugewiesen. Wenn Sie z. B. [e-mail] die Bearbeiterrolle auf Projektebene zuweisen und [e-mail] die Betrachterrolle für topic_a zuweisen, erhält Bob die Bearbeiterrolle für topic_a. Dies liegt daran, dass Sie Andreas bereits die Bearbeiterrolle für topic_a zugewiesen haben, die von den für project_a festgelegten "allow"-Richtlinien übernommen werden.

Das folgende Diagramm veranschaulicht das vorherige Beispiel.

Beispiel: Cloud Storage

In Cloud Storage sind Buckets und Objekte Ressourcen und die Objekte befinden sich in den Buckets. Ein Beispiel für die Verwendung von IAM mit Cloud Storage ist das Gewähren von Lesezugriff auf hochgeladene Dateien.

Stellen Sie sich ein Szenario vor, in dem viele Nutzer Dateien in einen Bucket hochladen, ohne dass sie die von anderen Nutzern hochgeladenen Dateien lesen oder löschen können. Ihre Datenverarbeiterin soll hochgeladene Dateien lesen und löschen können, soll aber nicht in der Lage sein, Buckets zu löschen, weil der Bucket-Speicherort von anderen genutzt wird, um Dateien hochzuladen. In diesem Szenario würden Sie "allow"-Richtlinien für das Projekt so festlegen:

• Weisen Sie Ihrer Datenverarbeitungsexpertin Alice unter [e-mail] die Rolle Storage Object Admin zu.
  • Alice hat Objektadministrationsrechte auf Projektebene und kann Objekte in allen Buckets im Projekt lesen, hinzufügen und löschen.
• Weisen Sie einer Gruppe von Nutzern, [e-mail], die Rolle eines Storage-Objekt-Erstellers zu.
  • Diese "allow"-Richtlinie bedeutet, dass jedes Hauptkonto der Gruppe [e-mail] Dateien in den Bucket hochladen kann.
  • Ein Gruppenmitglied besitzt Dateien, die es hochlädt, kann aber keine Dateien lesen oder löschen, die von anderen Nutzern hochgeladen wurden.

Das folgende Diagramm veranschaulicht das vorherige Beispiel.

Beispiel: Compute Engine

In größeren Unternehmen erfolgt das Management von Netzwerk- und Sicherheitsressourcen wie Firewalls normalerweise durch ein spezielles Team, das sich vom Entwicklungsteam unterscheidet. Die Entwicklungsteams möchten vielleicht beim Starten von Instanzen und Ausführen anderer Aktionen flexibel sein, die sich auf Instanzen in ihren Projekten beziehen. Erhält [e-mail] die Rolle Compute-Netzwerkadministrator auf Organisationsebene und [e-mail] die Rolle Compute-Instanzadministrator für ihr Projekt "Project_2", kann Alice beliebige Aktionen in Verbindung mit Instanzen ausführen. Sie kann jedoch keine Änderungen an den Netzwerkressourcen vornehmen, die mit ihrem Projekt verbunden sind. Nur Andreas kann Änderungen an den Netzwerkressourcen in der Organisation und an Projekten unter dieser Organisation vornehmen.

Berechtigungen zum Aufrufen von übernommenen Richtlinien

Zum Aufrufen der IAM-Richtlinien, die von einer übergeordneten Ressource übernommen werden, benötigen Sie die Berechtigung, die IAM-Richtlinie der übergeordneten Ressource aufzurufen. Wenn Sie beispielsweise alle übernommenen IAM-Richtlinien für ein Projekt aufrufen möchten, benötigen Sie die Berechtigung, die IAM-Richtlinie der übergeordneten Organisation des Projekts und die IAM-Richtlinien aller übergeordneten Ordner aufzurufen.

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aufrufen von IAM-Richtlinien benötigen, die von übergeordneten Ressourcen übernommen werden:

• IAM-Richtlinie ansehen, die von einer Organisation übernommen wurde: Organisationsadministrator (roles/resourcemanager.organizationAdmin) für die Organisation
• Rufen Sie eine IAM-Richtlinie auf, die von einem Ordner übernommen wird: Ordneradministrator (roles/resourcemanager.folderAdmin) für den Ordner
• Rufen Sie eine IAM-Richtlinie auf, die von einem Projekt übernommen wird: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) für das Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Aufrufen von IAM-Richtlinien erforderlich sind, die von übergeordneten Ressourcen übernommen werden. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um IAM-Richtlinien aufzurufen, die von übergeordneten Ressourcen übernommen wurden:

• IAM-Richtlinie ansehen, die von einer Organisation übernommen wurde: resourcemanager.organizations.getIamPolicy für die Organisation
• Rufen Sie eine IAM-Richtlinie auf, die von einem Ordner übernommen wird: resourcemanager.folders.getIamPolicy für den Ordner
• Rufen Sie eine IAM-Richtlinie auf, die von einem Projekt übernommen wird: resourcemanager.projects.getIamPolicy für das Projekt

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Hinweis: In der Google Cloud Console werden auf der IAM-Seite einer Ressource nur übernommene Rollen angezeigt, wenn die Rollen für die Ressource zugewiesen werden können.

Best Practices

• Spiegeln Sie Ihre Google Cloud-Ressourcenhierarchie in Ihrer Organisationsstruktur wider. Die Google Cloud-Ressourcenhierarchie sollte die Organisation Ihres Unternehmens widerspiegeln, unabhängig davon, ob es sich um ein Start-up, ein KMU oder ein großes Unternehmen handelt. Ein Start-up kann mit einer flachen Ressourcenhierarchie ohne Organisationsressource beginnen. Wenn allmählich mehr Personen bei Projekten kooperieren und die Zahl der Projekte steigt, können Organisationsressourcen sinnvoll sein. Eine Organisationsressource wird für größere Unternehmen mit mehreren Abteilungen und Teams empfohlen, bei denen jedes Team für seine eigenen Anwendungen und Dienste zuständig ist.

• Verwenden Sie Projekte zum Gruppieren von Ressourcen mit der gleichen Vertrauensgrenze. Zum Beispiel können Ressourcen für das gleiche Projekt oder den gleichen Mikrodienst zum gleichen Projekt gehören.

• Weisen Sie Rollen nach Möglichkeit einer Google-Gruppe (in Google Groups) anstelle von einzelnen Nutzern zu. Es ist einfacher, Mitglieder in einer Google-Gruppe zu verwalten als eine "allow"-Richtlinie zu aktualisieren. Bestimmen Sie die Inhaberschaft der Google-Gruppe, die in "allow"-Richtlinien verwendet wird.

  Weitere Informationen zum Verwalten von Google Groups finden Sie in der Google Groups-Hilfe.

• Verwenden Sie das Principle of Least Privilege (Prinzip der geringsten Berechtigung) zum Zuweisen von IAM-Rollen, was bedeutet, dass Sie nur das geringste Maß an Zugriff gewähren, das für Ihre Ressourcen notwendig ist.

  Die entsprechende vordefinierte Rolle finden Sie in der Referenz zu vordefinierten Rollen. Wenn keine geeigneten vordefinierten Rollen vorhanden sind, können Sie auch eigene benutzerdefinierte Rollen erstellen.

• Weisen Sie Rollen im kleinstmöglichen Bereich zu. Wenn ein Nutzer beispielsweise nur Zugriff auf die Veröffentlichung eines Pub/Sub-Themas benötigt, weisen Sie dem Nutzer für dieses Thema die Rolle "Publisher" zu.

• Beachten Sie, dass die "allow"-Richtlinien für untergeordnete Ressourcen die "allow"-Richtlinien für ihre übergeordneten Ressourcen übernehmen. Wenn beispielsweise die "allow"-Richtlinie für ein Projekt einem Nutzer die Berechtigung erteilt, Compute Engine-VM-Instanzen zu verwalten, kann der Nutzer jede Compute Engine-VM in diesem Projekt unabhängig von der "allow"-Richtlinie verwalten, die Sie für jede VM festgelegt haben.

• Achten Sie bei jedem Projekt darauf, dass mindestens zwei Hauptkonten die Rolle „Inhaber“ (roles/owner) haben. Alternativ können Sie der Google-Gruppe, die mindestens zwei Hauptkonten enthält, die Rolle „Inhaber“ zuweisen.

  Dadurch haben Sie weiterhin die Möglichkeit, Ihr Projekt zu verwalten, wenn eines der Hauptkonten das Unternehmen verlässt.

• Wenn Sie einem Nutzer oder einer Gruppe, die sich über mehrere Projekte erstreckt, eine Rolle zuweisen müssen, legen Sie diese Rolle auf Ordner- statt auf Projektebene fest.

• Annotieren, gruppieren und filtern Sie Ressourcen mit Labels.

• Prüfen Sie, ob Ihre "allow"-Richtlinien den Vorschriften entsprechen. Audit-Logs enthalten alle Aufrufe von setIamPolicy(), damit Sie verfolgen können, wann eine "allow"-Richtlinie erstellt oder geändert wurde.

• Prüfen Sie die Inhaberschaft und die Mitgliedschaft der in den "allow"-Richtlinien verwendeten Google-Gruppen.

• Wenn Sie die Projekterstellung in Ihrer Organisation beschränken möchten, ändern Sie die Zugriffsrichtlinie für die Organisation und weisen einer von Ihnen verwalteten Gruppe die Rolle "Projektersteller" zu.