Cloud Identity and Access Management

Diese Seite bietet einen Überblick über Cloud Identity and Access Management (Cloud IAM) und dessen Verwendung zur Steuerung des Zugriffs auf Buckets und Objekte in Cloud Storage. Informationen zum Festlegen und Verwalten von Cloud IAM-Berechtigungen für Cloud Storage-Buckets und -Projekte finden Sie unter Cloud IAM-Berechtigungen verwenden. 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 Cloud IAM mit Bezug zu Cloud Storage. Detaillierte Erklärungen zu Cloud IAM und eine allgemeine Übersicht der zugehörigen Funktionen finden Sie im Entwicklerleitfaden Cloud Identity and Access Management. Interessant ist insbesondere der Abschnitt Cloud IAM-Richtlinien verwalten.

Übersicht

Mit Cloud Identity and Access Management (Cloud IAM) können Sie steuern, wer Zugriff auf die Ressourcen in Ihrem Google Cloud Platform-Projekt hat. Zu den Ressourcen gehören Cloud Storage-Buckets und -Objekte, die in Buckets gespeichert sind, sowie andere Google Cloud Platform-Entitäten wie Compute Engine-Instanzen.

Die Gruppe von Zugriffsregeln, die Sie auf eine Ressource anwenden, wird als Cloud IAM-Richtlinie bezeichnet. In der Cloud IAM-Richtlinie, die für Ihr Projekt gilt, sind die Aktionen definiert, die Nutzer für alle Objekte oder Buckets innerhalb Ihres Projekts ausführen können. Eine Cloud 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 Cloud IAM-Richtlinie für einen Ihrer Buckets erstellen, die einem Nutzer administrative Kontrolle über diesen Bucket gibt. Dann können Sie einen weiteren Nutzer zu Ihrer Cloud IAM-Richtlinie auf Projektebene hinzufügen, der berechtigt ist, Objekte in jedem Bucket Ihres Projekts anzusehen.

Mitglieder sind die Akteure bei Cloud IAM. Dies können einzelne Nutzer, Gruppen, Domains oder sogar die gesamte Öffentlichkeit sein. Den Mitgliedern werden Rollen zugewiesen, mit denen sie Aktionen in Cloud Storage und allgemein in der GCP ausführen können. Jede Rolle umfasst eine oder mehrere Berechtigungen. Berechtigungen bilden die Grundlage von Cloud 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 roles/storage.objectCreator enthalten (hier ist es die einzige Berechtigung) sowie in roles/storage.objectAdmin, wo viele Berechtigungen zusammengefasst sind. Wenn Sie einem Mitglied die Rolle roles/storage.objectCreator für einen bestimmten Bucket zuweisen, kann es nur in diesem Bucket Objekte erstellen. Weisen Sie einem anderen Mitglied die Rolle roles/storage.objectAdmin für den Bucket zu, kann dieses 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 Mitglied die Rolle roles/storage.objectAdmin für Ihr Projekt und nicht nur für einen einzelnen Bucket zuweisen, kann es auf alle Objekte in jedem Bucket Ihres Projekts zugreifen.

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

Berechtigungen

Berechtigungen gestatten es Mitgliedern, bestimmte Aktionen für Buckets oder Objekte in Cloud Storage durchzuführen. Mit der Berechtigung storage.buckets.list kann ein Mitglied beispielsweise die Buckets in Ihrem Projekt auflisten. Berechtigungen werden Mitgliedern nicht direkt gewährt. Stattdessen weisen Sie ihnen Rollen zu, die eine oder mehrere Berechtigungen umfassen.

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

Rollen

Rollen enthalten eine oder mehrere Berechtigungen. roles/storage.objectViewer umfasst beispielsweise die Berechtigungen storage.objects.get und storage.objects.list. Sie weisen den Mitgliedern Rollen zu, mit denen sie bestimmte Aktionen für die Buckets und Objekte in Ihrem Projekt ausführen können.

Eine Referenzliste der Cloud IAM-Rollen, die für Cloud Storage gelten, finden Sie unter Cloud 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 roles/storage.objectViewer auf Projektebene zu, damit er alle Objekte in allen Buckets Ihres Projekts lesen kann. Zusätzlich weisen Sie ihm die Rolle roles/storage.objectCreator 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 Objekte darin. Beispiele für solche Rollen sind roles/storage.admin, roles/storage.objectViewer und roles/storage.objectCreator.

Manche Rollen können nur auf einer Ebene zugewiesen werden. Die Rolle Viewer können Sie zum Beispiel nur auf Projektebene zuweisen, die Rolle roles/storage.legacyObjectOwner hingegen ausschließlich auf Bucket-Ebene.

Bezug zu ACLs

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

Legacy Bucket-Rolle Zugehörige ACL
roles/storage.legacyBucketReader Bucket-Leser
roles/storage.legacyBucketWriter Bucket-Autor
roles/storage.legacyBucketOwner Bucket-Inhaber

Alle anderen Cloud IAM-Rollen auf Bucket-Ebene sowie alle Cloud 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. Das bedeutet, dass Sie Cloud IAM-Rollen auf Bucket-Ebene verwenden können, um umfassenden Zugriff auf alle Objekte in einem Bucket zu gewähren und die fein abgestimmten Objekt-ACLs, um den Zugriff auf bestimmte Objekte im Bucket anzupassen.

Cloud IAM-Berechtigung zum Ändern von ACLs

Mit Cloud IAM können Sie Mitgliedern die Berechtigung zum Ändern von ACLs für Objekte 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 Mitglieder mit Objekt-ACLs arbeiten, wenn sie die storage.objects-Berechtigungen .get, .getIamPolicy, .setIamPolicy und .update haben.

Benutzerdefinierte Rollen

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

Mitgliedstypen

Es gibt verschiedene Arten von Mitgliedern. Google-Konten und Google-Gruppen sind beispielsweise zwei allgemeine Mitgliedstypen, während allAuthenticatedUsers und allUsers zwei spezielle Arten sind. Eine Liste der Mitgliedstypen in Cloud IAM finden Sie unter Identitätskonzepte. Neben den dort aufgeführten Typen unterstützt Cloud IAM die folgenden Mitgliedstypen, die speziell auf die für den Cloud Storage-Bucket geltenden Cloud IAM-Richtlinien angewendet werden können:

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

Dabei ist [PROJECT_ID] die ID eines bestimmten Projekts.

Wenn Sie einem der obigen Mitgliedstypen eine Rolle zuweisen, erhalten alle Mitglieder mit der angegebenen Berechtigung für das jeweilige Projekt die von Ihnen ausgewählte Rolle. Sie können beispielsweise allen Mitgliedern mit der Rolle Viewer für das Projekt my-example-project die Rolle roles/storage.objectCreator für einen Ihrer Buckets gewähren. Weisen Sie dazu dem Mitglied projectViewer:my-example-project die Rolle roles/storage.objectCreator für diesen Bucket zu.

Einsatz mit Cloud Storage-Tools

Obwohl Cloud IAM-Berechtigungen nicht über die XML API festgelegt werden können, können Nutzer, denen Cloud IAM-Berechtigungen erteilt wurden, weiterhin die XML API sowie ein beliebiges anderes Tool für den Zugriff auf Cloud Storage verwenden.

Informationen dazu, welche Cloud IAM-Berechtigungen Nutzer benötigen, um Aktionen mit unterschiedlichen Cloud Storage-Tools auszuführen, finden Sie in Cloud IAM mit der Cloud Console, Cloud IAM mit gsutil, Cloud IAM mit JSON und Cloud IAM mit XML.

Best Practices

Cloud 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 Cloud 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 Richtschnur für die sichere Gewährung von Berechtigungen. Nach diesem Prinzip gewähren Sie nur Berechtigungen, die absolut notwendig sind, damit ein Nutzer die ihm zugewiesene Aufgabe erfüllen kann. Wenn Sie beispielsweise eine Datei für jemanden freigeben möchten, weisen Sie die Rolle storage.objectReader und nicht die Rolle storage.admin zu.

  • 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 dann verwenden, wenn Sie die administrative Kontrolle über Objekte und Buckets delegieren möchten.

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

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

  • Informieren Sie sich genau über die Projektrollen Viewer, Editor und Owner in Cloud Storage.

    Welchen Zugriff die Viewer/Editor/Owner-Rollen auf Projektebene in Cloud Storage gewähren, lässt sich schon am Namen ablesen. Der jeweilige Zugriff wird jedoch indirekt über zusätzliche Zugriffsberechtigungen auf Bucket- und Objektebene gewährt. Dabei werden Mitgliedstypen verwendet, die nur für Cloud Storage gelten. Dieser Zugriff wird zwar standardmäßig hinzugefügt, aber Sie können ihn widerrufen.

    Die Rolle Viewer allein gewährt einem Mitglied nur die Berechtigung storage.buckets.list, aber neue Buckets weisen standardmäßig allen Mitgliedern mit der Viewer-Rolle für das Projekt auch die Rolle roles/storage.legacyBucketReader zu. Mit dieser Bucket-Rolle kann ein Viewer einen Bucket ansehen. Darüber hinaus verfügt der Bucket über eine Standard-Objekt-ACL vom Typ projectPrivate. Das bedeutet, dass Objekte, die dem Bucket hinzugefügt werden, standardmäßig die projectPrivate-ACL erhalten. Mit dieser ACL kann ein Viewer das Objekt aufrufen.

    Auch die Projektrollen Editor und Owner haben selbst nur eingeschränkten Zugriff auf Cloud Storage. Mitglieder, denen diese Rollen zugewiesen werden, erhalten jedoch roles/storage.legacyBucketOwner für neue Buckets und werden über die ACL projectPrivate Inhaber von Objekten.

    Bestimmte Zugriffsberechtigungen für Buckets und Objekte sind in den Projektrollen Viewer/Editor/Owner jedoch nicht automatisch enthalten. Daher ist es möglich, Zugriffsberechtigungen aufzuheben, die Mitglieder sonst vielleicht erwartet hätten.

  • 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 Cloud IAM-Berechtigungen entfernt werden. Bei einem Objekt ist dies dagegen möglich, wenn der Inhaber des Objekts das Projekt verlässt und es keine Cloud 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 Mitglied auf Projektebene eine entsprechende Rolle zuweisen, z. B. roles/storage.admin. 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.

    Standardmäßig haben nur Mitglieder mit der Rolle Owner auf Projektebene auch die Rolle roles/legacyBucketOwner für neu erstellte Buckets. Sie sollten immer mindestens zwei Mitglieder mit der Rolle Owner haben, damit Ihre Buckets weiterhin von einem anderen Mitglied verwaltet werden können, wenn ein Teammitglied die Gruppe verlässt.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...