Identity and Access Management

Nutzung

Diese Seite bietet einen Überblick über Identity and Access Management (IAM) und dessen Verwendung zur Steuerung des Zugriffs auf Buckets, verwaltete Ordner und Objekte in Cloud Storage.

Übersicht

Mit IAM können Sie steuern, wer Zugriff auf die Ressourcen in Ihrem Google Cloud-Projekt hat. Zu den Ressourcen gehören Cloud Storage-Buckets, die verwalteten Ordner in Buckets und in Buckets gespeicherte Objekte sowie andere Google Cloud-Entitäten wie Compute Engine-Instanzen.

Hauptkonten sind die Akteure bei IAM. Hauptkonten können einzelne Nutzer, Gruppen, Domains oder sogar die gesamte Öffentlichkeit sein. Hauptkonten erhalten Rollen, mit denen sie Aktionen in Cloud Storage und allgemeiner in Google Cloud ausführen können. Jede Rolle umfasst eine oder mehrere Berechtigungen. Berechtigungen bilden die Grundlage von IAM: Jede Berechtigung gestattet es Ihnen, eine bestimmte Aktion auszuführen.

Mit der Berechtigung storage.objects.create können Sie zum Beispiel Objekte erstellen. Diese Berechtigung ist in Rollen wie Storage-Objekt-Ersteller (roles/storage.objectCreator) enthalten, die Berechtigungen zum Erstellen von Objekten in einem Bucket gewährt, sowie in Storage-Objekt-Administrator (roles/storage.objectAdmin), die eine Vielzahl von Berechtigungen für die Arbeit mit Objekten gewährt.

Die Sammlung von IAM-Rollen, die Sie für eine Ressource festlegen, wird als IAM-Richtlinie bezeichnet. Der durch diese Rollen gewährte Zugriff gilt sowohl für die Ressource, für die die Richtlinie festgelegt ist, als auch für alle in dieser Ressource enthaltenen Ressourcen. Sie können beispielsweise eine IAM-Richtlinie für einen Bucket festlegen, die einem Nutzer administrative Kontrolle über diesen Bucket und seine Objekte gewährt. Sie können auch eine IAM-Richtlinie für das Gesamtprojekt festlegen, die einem anderen Nutzer die Möglichkeit gibt, Objekte in jedem Bucket innerhalb dieses Projekts anzusehen.

Wenn Sie eine Google Cloud-Organisationsressource haben, können Sie auch IAM-Ablehnungsrichtlinien verwenden, um den Zugriff auf Ressourcen zu verweigern. Wird eine Ablehnungsrichtlinie an eine Ressource angehängt, kann das Hauptkonto in der Richtlinie unabhängig von den ihm zugewiesenen Rollen die angegebene Berechtigung nicht nutzen, um auf die Ressource oder eine untergeordnete Ressource zuzugreifen. Ablehnungsrichtlinien überschreiben alle IAM-Zulassungsrichtlinien.

Berechtigungen

Berechtigungen gestatten es Hauptkonten, bestimmte Aktionen für Buckets, verwaltete Ordner oder Objekte in Cloud Storage durchzuführen. Mit der Berechtigung storage.buckets.list kann ein Hauptkonto beispielsweise die Buckets in Ihrem Projekt auflisten. Sie erteilen Hauptkonten keine Berechtigungen direkt. Stattdessen erteilen Sie Rollen, die eine oder mehrere Berechtigungen enthalten.

Eine Referenzliste der IAM-Berechtigungen, die für Cloud Storage gelten, finden Sie unter IAM-Berechtigungen für Cloud Storage.

Rollen

Rollen enthalten eine oder mehrere Berechtigungen. Beispiel: Die Rolle Storage-Objekt-Betrachter (roles/storage.objectViewer) enthält die Berechtigungen storage.objects.get und storage.objects.list. Sie weisen den Hauptkonten Rollen zu, mit denen sie Aktionen für die Buckets, verwaltete Ordner und Objekte in Ihrem Projekt ausführen können.

Eine Referenzliste der IAM-Rollen, die für Cloud Storage gelten, finden Sie unter IAM-Rollen für Cloud Storage.

Rollen auf Ebene des Projekts, des Buckets oder des verwalteten Ordners zuweisen

Sie können Hauptkonten auf Ebene des Projekts, des Buckets oder des verwalteten Ordners Rollen zuweisen. Die durch diese Rollen gewährten Berechtigungen gelten additiv für die gesamte Ressourcenhierarchie. Sie können Rollen auf verschiedenen Ebenen der Ressourcenhierarchie gewähren, um Ihr Berechtigungsmodell detaillierter zu gestalten.

Sie können beispielsweise einem Nutzer die Berechtigung gewähren, Objekte in allen Buckets innerhalb eines Projekts zu lesen, aber nur in Bucket A zu erstellen. Weisen Sie dazu dem Nutzer die Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) für das Projekt zu, damit er alle in jedem Bucket innerhalb Ihres Projekts gespeicherten Objekte lesen kann. Mit der Rolle „Storage-Objekt-Ersteller“ (roles/storage.objectCreator) für Bucket A kann der Nutzer Objekte in nur diesem Bucket erstellen.

Einige Rollen können auf allen Ebenen der Ressourcenhierarchie verwendet werden. Auf Projektebene gelten die enthaltenen Berechtigungen für alle Buckets, verwaltete Ordner und Objekte im Projekt. Auf Bucket-Ebene dagegen gelten sie nur für einen bestimmten Bucket und die enthaltenen Ordner und Objekte. Beispiele für solche Rollen sind die Rollen „Storage-Administrator“ (roles/storage.admin), „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) und „Storage-Objekt-Ersteller“ (roles/storage.objectCreator).

Manche Rollen können nur auf einer Ebene zugewiesen werden. Beispielsweise können Sie die Rolle „Inhaber alter Storage-Objekte“ (roles/storage.legacyObjectOwner) nur auf Bucket-Ebene oder auf der Ebene des verwalteten Ordners anwenden. Die IAM-Rollen, mit denen Sie IAM-Ablehnungsrichtlinien steuern können, können nur auf Organisationsebene angewendet werden.

Bezug zu ACLs

Neben IAM können für Ihre Buckets und Objekte auch Legacy-Zugriffssteuerungssysteme wie Access Control Lists (ACLs) verwendet werden, wenn die Funktion einheitlicher Zugriff auf Bucket-Ebene für Ihren Bucket nicht aktiviert ist. Im Allgemeinen sollten Sie ACLs vermeiden und den einheitlichen Zugriff auf Bucket-Ebene für Ihren Bucket aktivieren. In diesem Abschnitt erfahren Sie, was Sie beachten sollten, wenn Sie die Verwendung von ACLs für einen Bucket und die darin enthaltenen Objekte zulassen.

Legacy-Bucket-IAM-Rollen arbeiten mit Bucket-ACLs zusammen: Wenn Sie eine Legacy-Bucket-Rolle einfügen oder entfernen, werden diese Änderungen von den mit dem Bucket verknüpften ACLs übernommen. Genauso wird durch Änderungen an einer Bucket-spezifischen ACL auch die entsprechende Legacy-Bucket-IAM-Rolle für den Bucket geändert.

Legacy Bucket-Rolle Zugehörige ACL
Leser von Legacy-Storage-Buckets (roles/storage.legacyBucketReader) Bucket-Leser
Autor alter Storage-Buckets (roles/storage.legacyBucketWriter) Bucket-Autor
Inhaber von Legacy-Storage-Buckets (roles/storage.legacyBucketOwner) Bucket-Inhaber

Alle anderen IAM-Rollen auf Bucket-Ebene, einschließlich der Legacyobjekte-IAM-Rollen, funktionieren unabhängig von ACLs. Ebenso funktionieren alle IAM-Rollen auf Projektebene unabhängig von ACLs. Wenn Sie beispielsweise einem Nutzer die Rolle Storage-Objekt-Betrachter (roles/storage.objectViewer) gewähren, bleiben die Zugriffssteuerungslisten unverändert.

Da Objekt-ACLs unabhängig von IAM-Rollen funktionieren, werden sie nicht in der Hierarchie der IAM-Richtlinien aufgeführt. Wenn Sie herausfinden möchten, wer Zugriff auf ein bestimmtes Objekt hat, müssen Sie nicht nur die IAM-Richtlinien auf Projekt- und Bucket-Ebene, sondern auch die jeweiligen ACLs prüfen.

IAM-Ablehnungsrichtlinien im Vergleich zu ACLs

Zugriffsrichtlinien für IAM gelten für Zugriff, der über ACLs gewährt wird. Beispiel: Wenn Sie eine Ablehnungsrichtlinie erstellen, die einem Hauptkonto die storage.objects.get-Berechtigung für ein Projekt verweigert, kann das Hauptkonto keine Objekte in diesem Projekt anzeigen, auch wenn ihm die READER-Berechtigung für einzelne Objekte übertragen wurde.

IAM-Berechtigung zum Ändern von ACLs

Sie können IAM verwenden, um Hauptkonten die Berechtigung zum Ändern von ACLs für Objekte zu erteilen. Wenn ein Nutzer alle folgenden storage.buckets-Berechtigungen hat, kann er mit Bucket-ACLs und Standardobjekt-ACLs arbeiten: .get, .getIamPolicy, .setIamPolicy und .update.

Ebenso können Nutzer mit Objekt-ACLs arbeiten, wenn sie die storage.objects-Berechtigungen .get, .getIamPolicy, .setIamPolicy und .update haben.

Benutzerdefinierte Rollen

IAM umfasst viele vordefinierte Rollen, die häufige Anwendungsfälle abdecken. Sie können aber auch eigene Rollen definieren, die von Ihnen festgelegte Berechtigungen enthalten. Dafür bietet IAM benutzerdefinierte Rollen.

Hauptkontotypen

Es gibt verschiedene Arten von Hauptkonten. Google-Konten und Google-Gruppen sind beispielsweise zwei allgemeine Hauptkontotypen, während allAuthenticatedUsers und allUsers zwei spezielle Arten sind. Eine Liste der Hauptkontotypen in IAM finden Sie unter Hauptkonto-Kennungen. Weitere Informationen zu Hauptkonten finden Sie unter Identitätskonzepte.

Konvergenzwerte

Cloud Storage unterstützt Konvergenzwerte. Diese sind besondere Hauptkonten, die speziell auf Ihre IAM-Bucket-Richtlinien angewendet werden können. Sie sollten in der Regel keine Konvergenzwerte in Produktionsumgebungen verwenden, da sie das Zuweisen von einfachen Rollen erfordern. Die Zuweisung von einfachen Rollen in Produktionsumgebungen wird jedoch nicht empfohlen.

Ein Konvergenzwert ist eine zweiteilige Kennung, die aus einer einfachen Rolle und einer Projekt-ID besteht:

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

Ein Konvergenzwert dient als Brücke zwischen den Hauptkonten, denen die einfache Rolle und eine IAM-Rolle zugewiesen wurde: Die IAM-Rolle, die dem Konvergenzwert zugewiesen ist, wird auch allen Hauptkonten der angegebenen einfachen Rolle für die angegebene Projekt-ID gewährt.

Beispiel: jane@example.com und john@example.com haben die einfache Rolle Betrachter (roles/viewer) für ein Projekt mit dem Namen my-example-project und Sie haben einen Bucket in diesem Projekt mit dem Namen my-bucket. Wenn Sie dem Konvergenzwert projectViewer:my-example-project die Rolle roles/storage.objectCreator (Storage-Objekt-Ersteller) für my-bucket zuweisen, erhalten sowohl jane@example.com als auch john@example.com die mit dem Storage-Objekt-Ersteller verknüpften Berechtigungen für my-bucket.

Sie können den Zugriff auf Konvergenzwerte für Ihre Buckets gewähren und entziehen. Cloud Storage wendet sie jedoch unter bestimmten Umständen automatisch an. Weitere Informationen finden Sie unter Modifizierbares Verhalten für einfache Rollen in Cloud Storage.

Bedingungen

Mit IAM Conditions können Sie Bedingungen festlegen, die steuern, wie Berechtigungen an Hauptkonten gewährt oder verweigert werden. Cloud Storage unterstützt die folgenden Arten von Bedingungsattributen:

  • resource.name: Zugriff auf Buckets und Objekte basierend auf dem Bucket- oder Objektnamen gewähren oder ablehnen. Sie können auch resource.type verwenden, um Zugriff auf Buckets oder Objekte zu gewähren. Dies ist bei Verwendung von resource.name aber in der Regel redundant. Mit der folgenden Beispielbedingung wird eine IAM-Einstellung auf alle Objekte mit demselben Präfix angewendet: 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • Datum/Uhrzeit: Legen Sie ein Ablaufdatum für die Berechtigung fest.

    request.time < timestamp('2019-01-01T00:00:00Z')

Diese bedingten Ausdrücke sind logische Anweisungen, die eine Teilmenge der Common Ausdruck Language (CEL) verwenden. Sie geben Bedingungen in den Rollenbindungen der IAM-Richtlinie eines Buckets an.

Beachten Sie die folgenden Einschränkungen:

  • Bevor Sie Bedingungen auf Bucket-Ebene hinzufügen, müssen Sie den einheitlichen Bucket-Zugriff für den Bucket aktivieren. Obwohl Bedingungen auf Projektebene zulässig sind, sollten Sie alle Buckets im Projekt zu einem einheitlichen Zugriff auf Bucket-Ebene migrieren, um zu verhindern, dass Cloud Storage-ACLs IAM-Bedingungen auf Projektebene überschreiben. Sie können eine einheitliche Zugriffsbeschränkung auf Bucket-Ebene anwenden, um einen einheitlichen Zugriff auf Bucket-Ebene für alle neuen Buckets in Ihrem Projekt zu ermöglichen.
  • Wenn Sie die JSON API für den Aufruf von getIamPolicy und setIamPolicy für Buckets mit Bedingungen verwenden, müssen Sie die IAM-Richtlinienversion auf 3 festlegen.
  • Da die Berechtigung storage.objects.list auf Bucket-Ebene gewährt wird, können Sie den Zugriff auf die Objektliste mit dem Bedingungsattribut resource.name nicht auf eine Teilmenge von Objekten im Bucket beschränken.
  • Abgelaufene Bedingungen bleiben in Ihrer IAM-Richtlinie, bis Sie sie entfernen.

Einsatz mit Cloud Storage-Tools

Obwohl IAM-Berechtigungen nicht über die XML API festgelegt werden können, können Nutzer, die IAM-Berechtigungen erhalten, weiterhin die XML API und andere Tools für den Zugriff auf Cloud Storage verwenden.

Informationen dazu, welche IAM-Berechtigungen Nutzern ermöglichen, Aktionen mit verschiedenen Cloud Storage-Tools auszuführen, finden Sie unter IAM-Referenzen für Cloud Storage.

Nächste Schritte