Ressourcenhierarchie für Zugriffssteuerung verwenden

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 Richtlinien für Identity and Access Management (IAM) auf verschiedenen Ebenen der Ressourcenhierarchie festlegen. Ressourcen übernehmen die Richtlinien der übergeordneten Ressource. Für eine Ressource gilt die dafür festgelegte Richtlinie zusammen mit derjenigen, die von dem übergeordneten Element übernommenen wurde.

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

Vorbereitung

Hintergrund

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

Die Hierarchie umfasst von oben nach unten: Organisationen, Ordner, Projekte und dienstspezifische Ressourcen.

Mit IAM können Sie 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. So können Sie bestimmten Nutzern die Berechtigung für eine einzelne Ressource in einem Projekt gewähren.

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

Die folgenden Beispiele zeigen, wie die Richtlinienübernahme in der Praxis funktioniert.

Beispiel: Pub/Sub

In Pub/Sub sind Themen und Abonnements die Ressourcen eines Projekts. Nehmen wir an, project_a enthält topic_a. Wenn Sie eine Richtlinie für project_a festlegen, durch die bob@gmail.com die Bearbeiterrolle zugewiesen wird, und eine Richtlinie für topic_a, durch die alice@gmail.com die Publisher-Rolle zugewiesen wird, weisen Sie effektiv die Bearbeiterrolle bob@gmail.com und die Publisher-Rolle alice@gmail.com für topic_a zu.

Das folgende Diagramm veranschaulicht das vorherige Beispiel.

Pub/Sub-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. bob@gmail.com die Bearbeiterrolle auf Projektebene zuweisen und bob@gmail.com die Betrachterrolle für topic_a zuweisen, erhält Bob die Bearbeiterrolle für topic_a. Dies liegt daran, dass Sie Bob bereits die Bearbeiterrolle für topic_a zugewiesen haben, die von der für project_a festgelegten Richtlinie übernommen wird.

Das folgende Diagramm veranschaulicht das vorherige Beispiel.

Pub/Sub-Beispiel

Beispiel: Cloud Storage

In Cloud Storage sind Buckets und Objekte Ressourcen, wobei Buckets die Container der Objekte sind. 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 Richtlinien für das Projekt so festlegen:

  • Weisen Sie Ihrer Datenverarbeitungsexpertin Alice unter alice@example.com 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, data_uploaders@example.com, die Rolle eines Storage-Objekt-Erstellers zu.
    • Diese Richtlinie bedeutet, dass jedes Mitglied von data_uploaders@example.com 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 für Cloud Storage

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 bob@example.com die Rolle Compute-Netzwerkadministrator auf Organisationsebene und alice@example.com 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 Bob kann Änderungen an den Netzwerkressourcen in der Organisation und an Projekten unter dieser Organisation vornehmen.

Beispiel für Cloud Storage

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.

  • Legen Sie Richtlinien auf Organisations- und Projektebene und nicht auf Ressourcenebene fest. Wenn neue Ressourcen hinzugefügt werden, kann es von Vorteil sein, wenn sie automatisch Richtlinien von ihrer übergeordneten Ressource übernehmen. Wenn beispielsweise neue virtuelle Maschinen durch Auto-Scaling zum Projekt hinzugefügt werden, übernehmen sie automatisch die Richtlinie für das Projekt.

    Weitere Informationen zum Festlegen von Richtlinien finden Sie unter Zugriff gewähren, ändern und widerrufen.

  • 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 IAM-Richtlinie zu aktualisieren. Bestimmen Sie die Inhaberschaft der Google-Gruppe, die in IAM-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.

  • Denken Sie daran, dass die Richtlinien für untergeordnete Ressourcen von den Richtlinien für ihre übergeordneten Ressourcen übernommen werden. Wenn beispielsweise die 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 Richtlinie verwalten, die Sie für jede VM festgelegt haben.

  • 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 Richtlinien den Vorschriften entsprechen. Audit-Logs enthalten alle Aufrufe von setIamPolicy(), damit Sie verfolgen können, wann eine Richtlinie erstellt oder geändert wurde.

  • Prüfen Sie die Inhaberschaft und die Mitgliedschaft der in den 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.