Identity and Access Management

Nutzung

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

• Wenn Sie andere Möglichkeiten zum Steuern des Zugriffs in Cloud Storage kennenlernen möchten, sehen Sie sich die Übersicht über die Zugriffssteuerung an.

• Eine ausführliche Beschreibung von IAM und seinen allgemeinen Features finden Sie unter Identity and Access Management.

Ü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.

Achtung: Sie können zwar IAM-Richtlinien für Buckets, verwaltete Ordner und Projekte festlegen, die den Zugriff auf darin enthaltene Objekte steuern, aber Sie können keine IAM-Richtlinien direkt für einzelne Objekte festlegen. Für die fein abgestufte Zugriffssteuerung einzelner Objekte verwendet Cloud Storage Access Control Lists (ACLs). Objekt-ACLs tauchen in der Hierarchie von IAM-Richtlinien nicht auf. 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.

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 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.

Achtung: Wenn Sie IAM-Richtlinien auf der Ebene von Projekten, Buckets und verwalteten Ordnern festlegen, gewähren Sie Nutzern möglicherweise Zugriff auf Objekte, auf die sie zuvor keinen Zugriff hatten. Überlegen Sie sich daher genau, wie Sie Ihre Richtlinien festlegen.

Hinweis: Wenn Sie die IAM-Richtlinie eines Projekts aufrufen, werden die IAM-Richtlinien für einzelne Buckets nicht angezeigt. Wenn Sie die IAM-Richtlinie für einen einzelnen Bucket mithilfe der Google Cloud Console aufrufen, werden Berechtigungen auf Projektebene angezeigt, die für diesen Bucket gelten. Andere Cloud Storage-Tools wie gcloud storage und die Clientbibliotheken geben jedoch nur die Richtlinie des Buckets zurück und enthalten keine Informationen, die von der Richtlinie auf Projektebene übernommen wurden. Sie müssen die Projekt- und Bucket-Richtlinien prüfen, wenn Sie den Zugriff von Hauptkonten ermitteln.

Bezug zu ACLs

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. Sie können also IAM-Rollen auf Bucket-Ebene verwenden, um allgemeinen Zugriff auf alle Objekte in einem Bucket zu gewähren, und die detailgenauen Objekt-ACLs, um den Zugriff auf bestimmte Objekte in dem Bucket anzupassen.

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: [e-mail] und [e-mail] 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 [e-mail] als auch [e-mail] 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.

Hinweis: Sie können auch doppelte Anführungszeichen in bedingten Ausdrücken verwenden. Zum Aktualisieren einer bedingten Richtlinie mit Google Cloud CLI-Befehlen und HTTP/REST-Anfragen sollten Sie jedoch entsprechende Escape-Zeichen verwenden. Beispiel: request.time < timestamp(\"2019-01-01T00:00:00Z\").

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 Nutzer benötigen, um Aktionen mit unterschiedlichen Cloud Storage-Tools auszuführen, finden Sie unter IAM-Referenzen für Cloud Storage.

Nächste Schritte

• Weitere Informationen zum Einsatz von IAM mit Cloud Storage
• IAM-Referenztabelle für Cloud Storage lesen
• Best Practices für die Verwendung von IAM
• Verwalten Sie IAM-Richtlinien für alle Ihre Google Cloud-Ressourcen.