Identity und Access Management

Zu den Beispielen

Auf dieser Seite finden Sie eine Übersicht der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) und ihrer Verwendung zur Steuerung des Zugriffs auf Buckets und Objekte in Cloud Storage. Wenn Sie andere Möglichkeiten zur Kontrolle des Zugriffs auf Buckets und Objekte kennenlernen möchten, sehen Sie sich die Übersicht über die Zugriffssteuerung an.

Auf dieser Seite geht es um Aspekte von IAM mit Bezug zu Cloud Storage. Eine ausführliche Beschreibung von IAM und seinen allgemeinen Features finden Sie unter Identity and Access Management. Lesen Sie insbesondere den Abschnitt zur Verwaltung von IAM-Richtlinien.

Ü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, in Buckets gespeicherte Objekte sowie andere Google Cloud-Entitäten wie Compute Engine-Instanzen.

Die Gruppe von Zugriffsregeln, die Sie auf eine Ressource anwenden, wird als IAM-Richtlinie bezeichnet. In der IAM-Richtlinie für Ihr Projekt sind die Aktionen definiert, die Nutzer für alle Objekte oder Buckets innerhalb Ihres Projekts ausführen können. Eine IAM-Richtlinie für einen einzelnen Bucket legt die Aktionen fest, die Nutzer für diesen bestimmten Bucket und für die darin enthaltenen Objekte ausführen können.

Sie können beispielsweise eine IAM-Richtlinie für einen Ihrer Buckets erstellen, die einem Nutzer die administrative Kontrolle über diesen Bucket gewährt. Dann können Sie einen weiteren Nutzer zu Ihrer IAM-Richtlinie auf Projektebene hinzufügen, der berechtigt ist, Objekte in jedem Bucket Ihres Projekts anzusehen.

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 allgemein 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 enthalten (hier ist es die einzige Berechtigung) sowie in Storage-Objekt-Administrator, wo viele Berechtigungen zusammengefasst sind. Wenn Sie einem Hauptkonto für einen bestimmten Bucket die Rolle Storage-Objekt-Ersteller zuweisen, kann es nur Objekte in diesem Bucket erstellen. Wenn Sie einem anderen Hauptkonto die Rolle Storage-Objekt-Administrator für den Bucket zuweisen, kann es weitere Aufgaben ausführen (z. B. Objekte löschen), aber nur in diesem speziellen Bucket. Falls diesen beiden Nutzern nur die genannten Rollen zugewiesen sind, haben sie keinerlei Zugriff auf andere Buckets in Ihrem Projekt. Wenn Sie einem dritten Hauptkonto die Rolle Storage-Objekt-Administrator für Ihr Projekt und nicht nur für einen einzelnen Bucket zuweisen, kann es auf alle Objekte in jedem Bucket des Projekts zugreifen.

Mit IAM in Cloud Storage können Sie die Berechtigungen eines Hauptkontos einschränken, ohne jede Bucket- oder Objektberechtigung einzeln anpassen zu müssen.

Berechtigungen

Berechtigungen gestatten es Hauptkonten, bestimmte Aktionen für Buckets 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 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 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 Projektebene oder auf Bucket-Ebene

Das Zuweisen von Rollen auf Bucket-Ebene hat keine Auswirkungen auf vorhandene Rollen, die Sie auf Projektebene gewährt haben, und umgekehrt. Somit können Sie mit diesen zwei Granularitätsebenen Berechtigungen individuell anpassen. Sie können beispielsweise einem Nutzer die Berechtigung gewähren, Objekte in allen Buckets zu lesen, aber nur in einem bestimmten Bucket zu erstellen. Weisen Sie ihm dafür die Rolle Storage-Objekt-Betrachter auf Projektebene zu, damit er alle Objekte in allen Buckets Ihres Projekts lesen kann. Zusätzlich weisen Sie ihm die Rolle Storage-Objekt-Ersteller auf Bucket-Ebene für einen bestimmten Bucket zu, sodass er nur darin Objekte erstellen kann.

Manche Rollen können sowohl auf Projekt- als auch auf Bucket-Ebene verwendet werden. Auf Projektebene gelten die enthaltenen Berechtigungen für alle Buckets und Objekte im Projekt. Auf Bucket-Ebene dagegen gelten sie nur für einen bestimmten Bucket und die enthaltenen Objekte. Beispiele für solche Rollen sind Storage-Administrator, Storage-Objekt-Betrachter und Storage-Objekt-Ersteller.

Manche Rollen können nur auf einer Ebene zugewiesen werden. Beispielsweise können Sie die Rolle Inhaber alter Storage-Objekte nur auf Bucket-Ebene anwenden.

Bezug zu ACLs

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

Legacy Bucket-Rolle Zugehörige ACL
Leser von Legacy-Storage-Buckets Bucket-Leser
Autor von Legacy-Storage-Buckets Bucket-Autor
Inhaber von Legacy-Storage-Buckets Bucket-Inhaber

Alle anderen IAM-Rollen auf Bucket-Ebene sowie alle IAM-Rollen auf Projektebene sind unabhängig von ACLs. Wenn Sie beispielsweise einem Nutzer die Rolle Storage-Objekt-Betrachter 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-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 typischen Hauptkontotypen in IAM 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 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 Storage-Objekt-Ersteller für my-bucket zuweisen, erhalten sowohl jane@example.com als auch john@example.com die mit 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 werden. Cloud Storage unterstützt die folgenden Arten von Bedingungsattributen:

  • resource.name: Zugriff auf Buckets und Objekte basierend auf dem Bucket- oder Objektnamen. 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: Legt 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.
  • Der Befehl gsutil iam ch funktioniert nicht mit Richtlinien, die Bedingungen enthalten. Zum Ändern einer Richtlinie mit Bedingungen verwenden Sie gsutil iam get. Damit können Sie die Richtlinie für den entsprechenden Bucket abrufen, sie lokal bearbeiten und anschließend gsutil iam set auf den Bucket anwenden.
  • Für die Anwendung von Bedingungen benötigen Sie gsutil in der Version 4.38 oder höher.
  • 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. Bei Nutzern ohne die Berechtigung storage.objects.list auf Bucket-Ebene kann eine Beeinträchtigung der Funktionen der Console und von gsutil bestehen.
  • 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 in IAM mit der Cloud Console, IAM mit gsutil, IAM mit JSON und IAM mit XML.

Best Practices

IAM erfordert ebenso wie andere administrative Einstellungen eine aktive Verwaltung, um wirksam zu sein. Bevor Sie Nutzern Zugriff auf einen Bucket oder ein Objekt gewähren, sollten Sie wissen, für wen Sie den Bucket oder das Objekt freigeben möchten und welche Rolle diese Personen spielen sollen. Veränderungen im Projektmanagement, den Nutzungsmustern sowie den Verantwortungsbereichen im Unternehmen können es im Lauf der Zeit erforderlich machen, die IAM-Einstellungen für Buckets und Projekte anzupassen, insbesondere wenn Sie Cloud Storage in einer großen Organisation oder für eine große Gruppe von Nutzern verwalten. Berücksichtigen Sie die folgenden Best Practices bei der Bewertung und Planung Ihrer Zugriffssteuerungseinstellungen:

  • Gewähren Sie Zugriff nach dem Prinzip der geringsten Berechtigung.

    Das Prinzip der geringsten Berechtigung ist eine Sicherheitsrichtlinie zum Gewähren von Zugriff auf Ihre Ressourcen. Wenn Sie Zugriff anhand des Prinzips der geringsten Berechtigung gewähren, erteilen Sie einem Nutzer nur den Zugriff, den er für die zugewiesene Aufgabe benötigt. Wenn Sie beispielsweise Dateien mit jemandem teilen möchten, sollten Sie ihm die Rolle storage.objectReader und nicht die Rolle storage.admin zuweisen.

  • Weisen Sie Personen, die Sie nicht kennen, keine Rollen mit der Berechtigung setIamPolicy zu.

    Mit der Berechtigung setIamPolicy können Nutzer Berechtigungen ändern und die Kontrolle über Daten übernehmen. Sie sollten Rollen mit der Berechtigung setIamPolicy nur verwenden, wenn Sie die administrative Kontrolle über Objekte und Buckets delegieren möchten.

  • Seien Sie vorsichtig, wenn Sie anonymen Nutzern Berechtigungen gewähren.

    Die Hauptkontotypen allUsers und allAuthenticatedUsers sollten Sie nur verwenden, wenn jeder über das Internet Ihre Daten lesen und analysieren darf. Ein solch großer Nutzungsumfang ist für einige Anwendungen und Szenarien sicher hilfreich, aber es ist normalerweise nicht sinnvoll, allen Nutzern Berechtigungen wie setIamPolicy, update, create oder delete zu gewähren.

  • Legen Sie keine Berechtigungen fest, die dazu führen, dass Buckets und Objekte nicht mehr zugänglich sind.

    Auf einen Bucket oder ein Objekt kann nicht mehr zugegriffen werden, wenn niemand eine Leseberechtigung hat. Bei einem Bucket kann das passieren, wenn für ihn alle IAM-Berechtigungen entfernt werden. Bei einem Objekt ist dies dagegen möglich, wenn der Inhaber des Objekts das Projekt verlässt und es keine IAM-Richtlinien auf Bucket- oder Projektebene gibt, die den Zugriff auf Objekte gewähren. In beiden Fällen können Sie den Zugriff wiedererlangen, wenn Sie sich selbst oder einem anderen Hauptkonto auf Projektebene eine entsprechende Rolle zuweisen, z. B. Storage-Administrator. Beachten Sie, dass Sie dadurch Zugriff auf alle Buckets und Objekte im Projekt gewähren. Daher sollten Sie die Rolle widerrufen, nachdem der Zugriff auf den betroffenen Bucket oder das Objekt wiederhergestellt wurde.

  • Achten Sie darauf, die administrative Kontrolle Ihrer Buckets zu delegieren.

    Achten Sie darauf, dass Ihre Buckets und Ressourcen weiterhin von anderen Teammitgliedern verwaltet werden können, falls eine Person mit Administratorzugriff die Gruppe verlässt. Dazu gibt es zwei gängige Methoden:

    • Weisen Sie die Rolle Storage-Administrator für Ihr Projekt einer Gruppe statt einer einzelnen Person zu.

    • Weisen Sie mindestens zwei Personen die Rolle Storage-Administrator für Ihr Projekt zu.

Nächste Schritte