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 mit der Google Cloud -Ressourcenhierarchie.

Hintergrund

Das folgende Diagramm zeigt ein Beispiel für eine Google Cloud -Ressourcenhierarchie.

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. 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 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 das Thema topic_a. Wenn Sie eine „Zulassen“-Richtlinie für project_1 festlegen, durch die Kalani die Rolle „Bearbeiter“ zugewiesen wird, und eine „Zulassen“-Richtlinie für topic_a, durch die Nur die Rolle „Publisher“ zugewiesen wird, weisen Sie effektiv Kalani die Rolle „Bearbeiter“ und Nur die Rolle „Publisher“ für topic_a zu.

Das folgende Diagramm veranschaulicht das vorherige Beispiel.

Wenn ein Hauptkonto durch eine übernommene Rolle bereits alle erforderlichen Berechtigungen hat, müssen Sie ihm keine zusätzlichen Rollen für die Ressource selbst zuweisen. Die Zuweisung einer anderen Rolle mit denselben oder weniger Berechtigungen ist redundant und hat keine Auswirkungen.

Denken Sie beispielsweise an die einfachen Rollen „Inhaber“, „Bearbeiter“ und „Betrachter“. Diese Rollen sind konzentrisch, was bedeutet, dass die Inhaberrolle die Berechtigungen der Bearbeiterrolle und die Bearbeiterrolle die Berechtigungen der Betrachterrolle beinhaltet. Wenn Sie Kalani also die Rolle „Bearbeiter“ auf Projektebene zuweisen, ist es redundant, ihm die Rolle „Betrachter“ für topic_a zuzuweisen. Das liegt daran, dass Kalani bereits alle Berechtigungen der Rolle „Betrachter“ über die Rolle „Bearbeiter“ hat, die von der „Zulassen“-Richtlinie des Projekts übernommen wird.

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 Nur die Rolle Storage Object Admin (roles/storage.objectAdmin) zu. Mit dieser Rolle können Objekte in allen Buckets im Projekt nur gelesen, hinzugefügt und gelöscht werden.
• Weisen Sie der Gruppe data-uploaders die Rolle Storage-Objekt-Ersteller (roles/storage.objectCreator) zu. Mit dieser Rolle können Gruppenmitglieder Dateien in den Bucket hochladen, 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.

In einem solchen Fall könnten Sie Ihre Zulassungsrichtlinien so konfigurieren:

• Weisen Sie Ihrem Netzwerk- und Sicherheitsadministrator Kalani die Rolle Compute-Netzwerkadministrator (roles/compute.networkAdmin) auf Organisationsebene zu. Mit dieser Rolle kann Kalani Änderungen an den Netzwerkressourcen in der Organisation und an allen Projekten unter dieser Organisation vornehmen.
• Weisen Sie der Entwicklungsteamleiterin Nur die Rolle Compute-Instanzadministrator (roles/compute.instanceAdmin) für ihr Projekt project_2 zu. Mit dieser Rolle kann Nur Aktionen für seine Instanzen ausführen, aber keine Änderungen an den Netzwerkressourcen vornehmen, die mit seinem Projekt verknüpft sind. Sie können jedoch keine Änderungen an Netzwerkressourcen in anderen Projekten 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 auf Projekte, Ordner und Organisationen 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 Gruppe anstelle von einzelnen Nutzern zu. Es ist einfacher, Mitglieder in einer Gruppe zu verwalten als eine Zulassungsliste zu aktualisieren. Bestimmen Sie die Inhaberschaft der Gruppe, die in „Zulassen“-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 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 „Zulassen“-Richtlinien verwendeten 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.