Access Control Lists (ACLs)

Nutzung

Diese Seite bietet einen Überblick über Zugriffssteuerungslisten (Access Control Lists, ACLs). Weitere Möglichkeiten, den Zugriff auf Buckets und Objekte zu kontrollieren, werden in der Übersicht über die Zugriffssteuerung erläutert.

Sollte ich ACLs verwenden?

In den meisten Fällen sollten Sie ACLs vermeiden und den einheitlichen Zugriff auf Bucket-Ebene für Ihre Buckets aktivieren. Dadurch wird die Verwendung von ACLs verhindert:

  • ACLs können nicht ausschließlich zur Steuerung des Zugriffs auf Ihre Google Cloud-Ressourcen verwendet werden, da ACLs nicht für das Gesamtprojekt oder Ressourcen außerhalb von Cloud Storage festgelegt werden können.
  • Wenn Sie den einheitlichen Zugriff auf Bucket-Ebene aktivieren, wird die Zugriffssteuerung vereinfacht und Sie können zusätzliche Google Cloud-Funktionen verwenden. Weitere Informationen finden Sie unter Sollten Sie einen einheitlichen Zugriff auf Bucket-Ebene verwenden?
  • Die Organisationsrichtlinie Domaineingeschränkte Freigabe und benutzerdefinierte Organisationsrichtlinien verhindern nicht den Zugriff, der über ACLs gewährt wird, was zu unbeabsichtigtem Zugriff führen kann.
  • Bei der Verwendung von ACLs in Projekten, für die IAM-Bedingungen auf Projektebene oder darüber festgelegt sind, kann es zu unerwartetem Verhalten und Zugriff kommen.

Sie möchten ACLs wahrscheinlich in den folgenden Fällen verwenden:

  • Sie müssen den Zugriff auf einzelne Objekte in einem Bucket anpassen, z. B. wenn der Uploader eines Objekts vollständige Kontrolle über das Objekt, aber eingeschränkten Zugriff auf andere Objekte in Ihrem Bucket haben soll.
  • Sie verwenden ausschließlich die XML API oder benötigen Interoperabilität mit Amazon S3.

Identity and Access Management (IAM) und ACLs gewähren gemeinsam Zugriff auf Ihre Buckets und Objekte. Das bedeutet, dass ein Nutzer nur die relevante Berechtigung von einem dieser Systeme benötigt, um auf einen Bucket oder ein Objekt zuzugreifen. Allgemein gilt, dass Berechtigungen, die durch IAM-Richtlinien gewährt werden, nicht in ACLs angegeben sind, und durch ACLs gewährte Berechtigungen nicht in IAM-Richtlinien. Weitere Informationen finden Sie unter IAM-Bezug zu ACLs.

Was ist eine ACL?

Eine ACL ist ein Mechanismus, mit dem Sie festlegen können, wer auf Ihre Buckets und Objekte welche Art von Zugriff haben soll. In Cloud Storage wenden Sie ACLs auf einzelne Buckets und Objekte an. Jede ACL umfasst einen oder mehrere Einträge. Ein Eintrag gibt einem Nutzer (oder einer Gruppe) die Möglichkeit, bestimmte Aktionen durchzuführen. Jeder Eintrag besteht aus zwei Informationen:

  • Einer Berechtigung, die definiert, welche Aktionen durchgeführt werden können (z. B. Lesen oder Schreiben)

  • Einem Bereich (manchmal auch als Empfänger bezeichnet), der definiert, wer die angegebenen Aktionen ausführen kann (z. B. ein bestimmter Nutzer oder eine Gruppe von Nutzern)

Nehmen wir als Beispiel einen Bucket, auf dessen Objekte jeder zugreifen können soll. Außerdem möchten Sie, dass Ihr Mitbearbeiter Objekte zu dem Bucket hinzufügen oder daraus entfernen kann. In diesem Fall besteht die ACL aus zwei Einträgen:

  • In dem einen gewähren Sie dem Bereich allUsers die Berechtigung READER.

  • In dem anderen gewähren Sie dem Bereich Ihres Mitbearbeiters die Berechtigung WRITER. Es gibt mehrere Möglichkeiten, diese Person anzugeben, zum Beispiel durch ihre E-Mail-Adresse.

Für einen Bucket oder ein Objekt können Sie maximal 100 ACL-Einträge erstellen. Wenn der Eintragsbereich eine Gruppe oder Domain ist, zählt dies als ein ACL-Eintrag, unabhängig davon, wie viele Nutzer zu der Gruppe oder Domain gehören.

Wenn ein Nutzer Zugriff auf einen Bucket oder ein Objekt anfordert, liest das Cloud Storage-System die Bucket- oder Objekt-ACL und ermittelt, ob die Zugriffsanfrage genehmigt oder abgelehnt werden soll. Falls die ACL dem Nutzer die Berechtigung für den angeforderten Vorgang gewährt, wird die Anfrage genehmigt. Gewährt die ACL dagegen dem Nutzer keine Berechtigung für den angeforderten Vorgang, schlägt die Anfrage fehl und der Fehler 403 Forbidden wird ausgegeben.

Zwar können Sie mit ACLs die meisten Aktionen in Verbindung mit Buckets und Objekten verwalten, die Fähigkeit zum Erstellen eines Buckets hängt jedoch von der entsprechenden Projektberechtigung ab.

Berechtigungen

Berechtigungen legen fest, was mit einem bestimmten Objekt oder Bucket getan werden kann.

In Cloud Storage können Sie die in der folgenden Tabelle aufgeführten konzentrischen Berechtigungen für Ihre Buckets und Objekte zuweisen:

Buckets Objekte
READER Der Nutzer kann den Inhalt eines Buckets auflisten. Außerdem kann er Bucket-Metadaten ohne ACLs lesen. Der Nutzer kann die Daten eines Objekts herunterladen.
WRITER Gewährt einem Nutzer alle Zugriffsrechte, die durch die Berechtigung READER gewährt werden. Darüber hinaus kann ein Nutzer Objekte in einem Bucket erstellen, ersetzen und löschen, einschließlich der Erstellung von Objekten mit mehrteiligen Uploads. Nicht verfügbar. Diese Berechtigung kann nicht auf Objekte angewendet werden.
OWNER Gewährt einem Nutzer alle Zugriffsrechte, die durch die Berechtigung WRITER gewährt werden. Außerdem kann ein Nutzer Bucket-Metadaten einschließlich ACLs lesen und schreiben und mit Tags für den Bucket arbeiten. Gewährt einem Nutzer alle Zugriffsrechte, die durch die Berechtigung READER gewährt werden. Außerdem kann ein Nutzer Objektmetadaten einschließlich ACLs lesen und schreiben.
Standard Auf Buckets wird beim Erstellen die vordefinierte ACL project-private angewendet. Buckets gehören immer der Gruppe project-owners. Auf Objekte wird beim Hochladen die vordefinierte ACL project-private angewendet. Objekte gehören immer dem ursprünglichen Antragsteller, der das Objekt hochgeladen hat.

Auf dieser Seite werden die Berechtigungen als READER, WRITER und OWNER bezeichnet. Dies entspricht ihrer Festlegung in der JSON API und der Google Cloud Platform Console. Wenn Sie die XML API verwenden, lauten die entsprechenden Berechtigungen READ, WRITE und FULL_CONTROL.

Bereiche

Bereiche geben an, wer eine bestimmte Berechtigung hat.

Eine ACL umfasst einen oder mehrere Einträge, die jeweils Berechtigungen für einen Bereich gewähren. Mit den folgenden Entitäten können Sie einen ACL-Bereich angeben:

Bereich ("Empfänger") Entitätstyp(en) Beispiel
Spezielle Kennung für alle Entitäten Nutzer allUsers
Spezielle Kennung für alle gültigen Konten Nutzer allAuthenticatedUsers
E-Mail-Adresse des Nutzerkontos Nutzer collaborator@gmail.com
E-Mail-Adresse des Dienstkontos Nutzer my-service-account@my-project.iam.gserviceaccount.com
E-Mail-Adresse der Google-Gruppe Gruppe work-group@googlegroups.com
Konvergenzwerte für Projekte Projekt owners-123456789012
Google Workspace-Domain Domain dana@example.com
Cloud Identity-Domain Domain dana@example.com

  • Spezielle Kennung für alle Entitäten:

    Die spezielle Bereichskennung allUsers steht für jede Entität im Internet. Diese Kennung gehört zwar zum Entitätstyp User, aber bei Verwendung der Google Cloud Console wird sie als Entitätstyp Public angegeben.

  • Spezielle Kennung für alle gültigen Konten:

    Die spezielle Bereichskennung allAuthenticatedUsers steht für die meisten authentifizierten Konten, einschließlich Dienstkonten. Weitere Informationen finden Sie in der IAM-Übersicht. Diese Kennung gehört zwar zum Entitätstyp User, aber bei Verwendung der Google Cloud Console wird sie als Entitätstyp Public angegeben.

  • E-Mail-Adresse des Nutzerkontos:

    Jeder Nutzer, der ein Nutzerkonto hat, braucht eine eindeutige E-Mail-Adresse, die mit diesem Konto verknüpft ist. Einen Bereich können Sie mit einer beliebigen E-Mail-Adresse festlegen, die mit einem Nutzerkonto verknüpft ist.

    Cloud Storage merkt sich die E-Mail-Adressen, da diese in ACLs enthalten sind, bis die Einträge gelöscht oder ersetzt werden. Wenn ein Nutzer seine E-Mail-Adresse ändert, müssen Sie die ACL-Einträge entsprechend aktualisieren.

  • E-Mail-Adresse des Dienstkontos:

    Jedem Dienstkonto ist eine eindeutige E-Mail-Adresse zugewiesen. Einen Bereich können Sie mit der E-Mail-Adresse festlegen, die mit dem Dienstkonto verknüpft ist.

  • E-Mail-Adresse der Google-Gruppe:

    Jede Google-Gruppe hat eine eindeutige E-Mail-Adresse, die mit der Gruppe verbunden ist. Die Gruppe Google Cloud Storage – Announce hat zum Beispiel die E-Mail-Adresse gs-announce@googlegroups.com. Sie finden die mit einer Google-Gruppe verbundene E-Mail-Adresse, indem Sie auf der Startseite einer Google-Gruppe auf Info klicken.

    Genau wie bei E-Mail-Adressen von Nutzerkonten merkt sich Cloud Storage auch die E-Mail-Adressen von Gruppen, da sie in ACLs enthalten sind, bis die Einträge gelöscht werden. E-Mail-Adressen von Google-Gruppen müssen Sie nicht aktualisieren, da diese dauerhaft sind und sich in der Regel nicht ändern.

  • Konvergenzwerte für Projekte:

    Mit Konvergenzwertenkönnen Sie den Betrachtern, Bearbeitern und Inhabern Ihres Projekts Bulk-Zugriff gewähren. Konvergenzwerte kombinieren eine Projektrolle und eine zugehörige Projektnummer. Beispielsweise werden Bearbeiter im Projekt 867489160491 mit editors-867489160491 bezeichnet. Sie finden Ihre Projektnummer auf der Startseite der Google Cloud Console.

    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.

  • Google Workspace oder Cloud Identity:

    Google Workspace- und Cloud Identity-Kunden können ihre E-Mail-Konten mit dem Namen einer Internetdomain verknüpfen. In diesem Fall hat jedes E-Mail-Konto die Form USERNAME@YOUR_DOMAIN.com. Sie können einen Bereich festlegen, wenn Sie einen mit Google Workspace oder Cloud Identity verknüpften Internetdomainnamen verwenden.

Konzentrische Berechtigungen und Bereiche

Beim Angeben von ACLs in Cloud Storage müssen Sie nicht mehrere Bereiche auflisten, um mehrere Berechtigungen zu gewähren. Cloud Storage verwendet konzentrische Berechtigungen. Wenn Sie also die Berechtigung WRITER erteilen, gewähren Sie auch die Berechtigung READER, und mit der Berechtigung OWNER werden automatisch auch die Berechtigungen READER und WRITER zugewiesen.

Beim Angeben einer ACL können Sie mit den meisten Tools mehrere Bereiche für denselben Eintrag festlegen. Die umfangreichste Berechtigung bestimmt den Zugriff für den Bereich. Wenn Sie beispielsweise zwei Einträge für einen Nutzer anlegen – einmal mit der Berechtigung READER und einmal mit der Berechtigung WRITER für einen Bucket –, hat der Nutzer die Berechtigung WRITER für den Bucket.

In der XML API ist es nicht möglich, zwei ACL-Einträge für denselben Bereich anzugeben. Wenn Sie einem Nutzer die Berechtigungen READ und WRITE für einen Bucket gewähren, wird ein Fehler ausgegeben. Erteilen Sie dem Nutzer stattdessen die Berechtigung WRITE, womit automatisch auch die Berechtigung READ gewährt wird.

Vordefinierte ACLs

Eine vordefinierte ACL, auch als vordefinierte ACL bezeichnet, ist ein Alias für einen Satz von ACL-Einträgen, den Sie verwenden können, um schnell viele ACL-Einträge gleichzeitig auf einen Bucket oder ein Objekt anzuwenden.

In der unten stehenden Tabelle sind vordefinierte ACLs aufgeführt. Außerdem können Sie sehen, welche Einträge jeweils angewendet werden. Beachten Sie bei der Verwendung der Tabelle Folgendes:

  • Die Projektinhabergruppe ist der Inhaber der Buckets in einem Projekt und der Nutzer, der ein Objekt erstellt, ist Inhaber dieses Objekts. Wenn ein Objekt von einem anonymen Nutzer erstellt wurde, ist die Projektinhabergruppe der Inhaber des Objekts.

  • In der Tabelle werden die JSON API-Bezeichnungen für die Berechtigungen (OWNER, WRITER und READER) verwendet. Die entsprechenden XML API-Bereiche sind FULL_CONTROL, WRITE und READ.

    JSON API/gcloud storage XML API Beschreibung
    private private Gewährt dem Bucket- oder Objektinhaber die Berechtigung OWNER für einen Bucket oder ein Objekt.
    bucketOwnerRead bucket-owner-read Gewährt dem Inhaber eines Objekts die Berechtigung OWNER und dem Inhaber eines Buckets die Berechtigung READER. Dies wird nur bei Objekten verwendet.
    bucketOwnerFullControl bucket-owner-full-control Gewährt den Inhabern von Objekten und Buckets die Berechtigung OWNER. Dies wird nur bei Objekten verwendet.
    projectPrivate project-private Gewährt dem Projektteam Berechtigungen basierend auf der jeweiligen Rolle. Alle Teammitglieder haben die Berechtigung READER. Projektinhaber und -bearbeiter haben außerdem die Berechtigung OWNER. Dies ist die Standard-ACL für neu erstellte Buckets. Außerdem ist dies auch die Standard-ACL für neu erstellte Objekte, es sei denn, die Standardobjekt-ACL für den Bucket wurde geändert.
    authenticatedRead authenticated-read Gewährt dem Inhaber eines Buckets oder Objekts die Berechtigung OWNER und allen authentifizierten Nutzerkontoinhabern die Berechtigung READER.
    publicRead public-read Gewährt dem Inhaber eines Buckets oder Objekts die Berechtigung OWNER und allen Nutzern, ob authentifiziert oder anonym, die Berechtigung READER. Wenn Sie diese ACL auf ein Objekt anwenden, kann jeder im Internet das Objekt ohne Authentifizierung lesen. Wenn Sie diese ACL auf einen Bucket anwenden, kann jeder im Internet Objekte ohne Authentifizierung auflisten.

    * Lesen Sie auch den Hinweis am Ende der Tabelle zum Caching.
    publicReadWrite public-read-write Gewährt dem Inhaber eines Buckets die Berechtigung OWNER und allen Nutzern, ob authentifiziert oder anonym, die Berechtigungen READER und WRITER. Diese ACL gilt nur für Buckets. Wenn Sie diese ACL auf einen Bucket anwenden, kann jeder im Internet ohne Authentifizierung Objekte auflisten, erstellen, ersetzen und löschen.

    * Lesen Sie auch den Hinweis am Ende der Tabelle zum Caching.

* Standardmäßig werden öffentlich lesbare Objekte mit dem Header Cache-Control bereitgestellt, wodurch die Objekte 3.600 Sekunden im Cache gespeichert werden können. Wenn Sie möchten, dass Aktualisierungen sofort sichtbar sind, sollten Sie die Cache-Control-Metadaten der Objekte auf Cache-Control:private, max-age=0, no-transform festlegen.

Standard-ACLs

Wenn Sie beim Erstellen eines Buckets oder Hochladen eines Objekts nicht explizit eine ACL zuweisen, wird die Standard-ACL verwendet. Die Standard-ACL eines Objekts können Sie jedoch ändern. Die Vorgehensweise dazu wird unter Standardobjekt-ACLs ändern beschrieben. Beachten Sie, dass beim Ändern der Standard-ACL die ACLs von Objekten, die bereits im Bucket vorhanden sind, oder von Buckets, die bereits im Projekt existieren, unverändert bleiben.

Standard-Bucket-ACLs

Alle Buckets sind Eigentum der Projektinhabergruppe. Außerdem erhalten Projektinhaber die Berechtigung OWNER für alle Buckets in ihrem Projekt, die eine vordefinierte ACL verwenden.

Wenn Sie einen Bucket mit der Standard-Bucket-ACL erstellen, also keine vordefinierte ACL angeben, wird auf den Bucket die vordefinierte ACL projectPrivate angewendet.

Standardobjekt-ACLs

Standardmäßig kann jeder, der die Berechtigung OWNER oder WRITER für einen Bucket hat, Objekte in diesen hochladen. Beim Hochladen eines Objekts können Sie eine vordefinierte ACL oder keine ACL angeben. Wenn Sie keine ACL festlegen, wendet Cloud Storage die Standardobjekt-ACL des Buckets auf das Objekt an. Jeder Bucket hat eine Standardobjekt-ACL. Diese wird auf alle Objekte angewendet, die in den Bucket hochgeladen werden, wenn sie keine vordefinierte ACL oder ACL-Angabe in der Anfrage (nur JSON API) haben. Der Ausgangswert für die Standardobjekt-ACL jedes Buckets ist projectPrivate.

Objekt-ACLs werden abhängig von der Uploadmethode angewendet:

  • Authentifizierte Uploads

    Wenn Sie eine authentifizierte Anfrage zum Hochladen eines Objekts stellen und dabei keine Objekt-ACLs angeben, werden Sie beim Hochladen als Inhaber des Objekts aufgeführt und die vordefinierte ACL projectPrivate wird standardmäßig auf das Objekt angewendet. Das heißt:

    • Sie (die Person, die das Objekt hochgeladen hat) werden als Objektinhaber aufgeführt. Die Objektinhaberschaft kann durch das Bearbeiten von ACLs nicht geändert werden. Dazu müssten Sie das Objekt ersetzen.

    • Ihnen (dem Objektinhaber) wird die Berechtigung OWNER für das Objekt gewährt. Wenn Sie versuchen, dem Inhaber eine geringere Berechtigung als OWNER zu gewähren, ändert Cloud Storage diese automatisch in OWNER.

    • Die Projektinhaber- und Projektbearbeitergruppen haben die Berechtigung OWNER für das Objekt.

    • Die Gruppe der Projektteammitglieder hat die Berechtigung READER für das Objekt.

  • Anonyme Uploads

    Lädt ein nicht authentifizierter (anonymer) Nutzer ein Objekt hoch – was möglich ist, wenn ein Bucket der Gruppe allUsers die Berechtigung WRITER oder OWNER gewährt –, werden, wie oben beschrieben, die Standard-Bucket-ACLs auf das Objekt angewendet.

    Anonyme Nutzer können beim Hochladen eines Objekts keine vordefinierte ACL angeben.

ACL-Verhalten

Cloud Storage unterstützt Sie bei der Einhaltung dieser Best Practices durch einige Regeln für die Änderung von ACLs, die Sie daran hindern, ACLs einzurichten, die Daten unzugänglich machen würden:

  • Sie können keine ACL anwenden, in der ein anderer Bucket- oder Objektinhaber angegeben ist.

    Die Bucket- und Objektinhaberschaft kann durch das Bearbeiten von ACLs nicht geändert werden. Achten Sie beim Anwenden einer neuen ACL auf einen Bucket oder ein Objekt darauf, dass der Bucket- oder Objektinhaber unverändert bleibt.

  • Der Bucket- oder Objektinhaber hat immer die Berechtigung OWNER für den Bucket oder das Objekt.

    Inhaber eines Buckets ist die Projektinhabergruppe, Inhaber eines Objekts ist entweder der Nutzer, der es hochgeladen hat, oder die Projektinhabergruppe, falls das Objekt von einem anonymen Nutzer hochgeladen wurde.

    Wenn Sie eine neue ACL auf einen Bucket oder ein Objekt anwenden, gewährt Cloud Storage dem Bucket- oder Objektinhaber die Berechtigung OWNER, falls Sie dies nicht selbst tun. Der Projektinhabergruppe wird für ein Objekt nicht die Berechtigung OWNER erteilt, es sei denn, das Objekt wurde von einem anonymen Nutzer erstellt. Sie müssen die Gruppe also explizit einschließen.

Sie können keine ACLs anwenden, durch welche die Inhaberschaft eines Buckets oder Objekts geändert wird (nicht zu verwechseln mit der Berechtigung OWNER). Nach der Erstellung eines Buckets oder Objekts in Cloud Storage ist die Inhaberschaft dauerhaft. Sie können jedoch die Inhaber von Objekten (nicht von Buckets) ändern, wenn Sie die Objekte ersetzen. Das Ersetzen ist im Grunde ein Löschvorgang, auf den unmittelbar ein Uploadvorgang folgt. Während des Hochladens wird die Person, die den Upload durchführt, zum Inhaber des Objekts. Die Person, die ein Objekt ersetzt (und damit Inhaber des Objekts wird), muss die Berechtigung WRITER oder OWNER für den Bucket haben, in den das Objekt hochgeladen wird.

Nächste Schritte