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 der Regel ist Identity and Access Management (IAM) die sinnvollste Methode zur Steuerung des Zugriffs auf Ihre Ressourcen:

• IAM bietet Zugriffssteuerung überall in Google Cloud.
• IAM bietet mehr Kontrolle darüber, welche Aktionen Nutzer ausführen dürfen.
• IAM-Berechtigungen, die für übergeordnete Ressourcen wie Projekte gewährt werden, werden von untergeordneten Ressourcen wie Buckets und Objekten übernommen, sodass Sie den Zugriff auf Ressourcen einfacher verwalten können.
• IAM-Berechtigungen können auf verwaltete Ordner angewendet werden, ACLs jedoch nicht.
• ACLs können nicht ausschließlich zur Steuerung des Zugriffs auf Ihre Ressourcen verwendet werden, da ACLs nicht für das Gesamtprojekt oder andere übergeordnete Ressourcen festgelegt werden können.

Wenn Sie nur IAM verwenden und den einheitlichen Zugriff auf Bucket-Ebene aktivieren, können Sie andere Google Cloud-Sicherheitsfeatures wie domaineingeschränkte Freigabe, Mitarbeiteridentitätsföderation und IAM Conditions verwenden.

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

• Sie müssen den Zugriff auf einzelne Objekte in einem Bucket anpassen. ACLs können für einzelne Objekte festgelegt werden, während IAM-Berechtigungen nur auf Bucket-Ebene oder höher gewährt werden können.
• Sie verwenden ausschließlich die XML API oder benötigen Interoperabilität mit Amazon S3.

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.

Hinweis: 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. Ausnahmen sind ACLs, die direkt auf einen Bucket angewendet werden, sowie bestimmte IAM-Richtlinien auf Bucket-Ebene. Dies wird unter Beziehung zwischen IAM und ACLs näher erklärt. Um den Verwaltungs- und Tracking-Aufwand zu reduzieren, sollten Sie das ACL-System deaktivieren und ausschließlich IAM verwenden.

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.

Hinweis: Sie können keine separaten Berechtigungen zum Lesen oder Schreiben von ACLs oder anderen Metadaten erteilen. Wenn Sie jemandem das Lesen und Schreiben von ACLs gestatten möchten, müssen Sie dieser Person die Berechtigung OWNER zuweisen.

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	[e-mail]
E-Mail-Adresse der Google-Gruppe	Gruppe	[e-mail]
Konvergenzwerte für Projekte	Projekt	owners-123456789012
Google Workspace-Domain	Domain	USERNAME@YOUR_DOMAIN.com
Cloud Identity-Domain	Domain	USERNAME@YOUR_DOMAIN.com
Einzelne Identität im Workforce Identity-Pool	Hauptkonto	//iam.googleapis.com/locations/global/workforcePools/my-pool/subject/[e-mail]
Alle Workforce-Identitäten in einer Gruppe	Hauptkontogruppe	//iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

• 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 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 [e-mail]. 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.

• Mitarbeiteridentitäten:

  Mit der Workforce Identity-Föderation können Sie einen externen Identitätsanbieter (Identity Provider, IdP) verwenden, um eine Gruppe von Nutzern mit IAM zu authentifizieren und zu autorisieren, damit die Nutzer auf Google Cloud-Dienste zugreifen können.

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.

Achtung: Durch Anwenden einer vordefinierten ACL auf einen vorhandenen Bucket oder ein bestehendes Objekt ersetzen Sie die bisherige Bucket- oder Objekt-ACL vollständig durch die vordefinierte ACL. Dadurch können Sie in manchen Fällen den Zugriff auf die Bucket- oder Objekt-ACL verlieren. Angenommen, Sie gehören zur Gruppe der Projektinhaber, sind aber nicht der Inhaber eines Objekts mit der ACL projectPrivate. Unter diesen Umständen verlieren Sie die OWNER-Berechtigung und können nicht mehr auf die Objekt-ACL zugreifen, nachdem Sie die vordefinierte ACL publicRead auf das Objekt angewendet haben. In so einem Fall können Sie die IAM-Rolle storage.objectAdmin verwenden, damit Sie die Berechtigung haben, die ACL des Objekts zu aktualisieren und die Änderung zu korrigieren.

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. Wichtig: Wenn Sie einen Bucket auf publicReadWrite festlegen, gewähren Sie allen Internetnutzern die Möglichkeit, beliebige Inhalte in Ihren Bucket hochzuladen. Sie sind jedoch für den Inhalt verantwortlich. * 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.

Wichtig: Wenn Sie die Standardobjekt-ACL für einen Bucket ändern, dauert es möglicherweise einige Zeit, bis die Änderung übernommen wird. Neue Objekte, die im Bucket erstellt werden, erhalten möglicherweise für kurze Zeit noch die alte Standardobjekt-ACL (siehe Konsistenz). Damit neu im Bucket erstellte Objekte sicher die aktualisierte Standardobjekt-ACL erhalten, sollten Sie mindestens 30 Sekunden warten, bevor Sie nach einer Änderung der Standardobjekt-ACL neue Objekte erstellen.

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.

Hinweis: Sie können alle Inhaberschaftsattribute eines Buckets und die darin enthaltenen Objekte deaktivieren. Dazu aktivieren Sie den einheitlichen Zugriff auf Bucket-Ebene. Dadurch wird auch jede Verwendung von ACLs im Bucket deaktiviert, sodass dieser für die Zugriffssteuerung ausschließlich IAM-Richtlinien nutzt.

Nächste Schritte

• ACLs verwenden.
• So können Sie die Zugriffssteuerung durch einheitlichen Zugriff auf Bucket-Ebene vereinfachen
• Best Practices für die Verwendung von ACLs.