Access Control Lists (ACLs)

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

Sollte ich Zugriffssteuerungslisten verwenden?

In der Regel ist die Identitäts- und Zugriffsverwaltung (IAM) die sinnvollste Methode zur Steuerung des Zugriffs auf Ihre Ressourcen. IAM und ACLs gewähren beide Zugriff auf Ihre Buckets und Objekte. Ein Nutzer benötigt nur eine Berechtigung über IAM oder eine ACL, um auf einen Bucket oder ein Objekt zugreifen zu können.

ACLs sind zu empfehlen, wenn Sie den Zugriff auf einzelne Objekte innerhalb eines Buckets anpassen müssen, da Cloud-IAM-Berechtigungen für alle Objekte in einem Bucket gelten. Verwenden Sie aber Cloud IAM für Zugriffsmöglichkeiten auf alle Objekte in einem Bucket, da dies den Verwaltungsaufwand reduziert.

Was ist eine Zugriffssteuerungsliste?

Eine Zugriffssteuerungsliste (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 Eintrag gewähren Sie dem Bereich allUsers die Berechtigung READER.

  • In dem anderen Eintrag 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 die angeforderte Operation, 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 Der Nutzer kann Objekte in einem Bucket auflisten, erstellen, überschreiben und löschen1. Nicht verfügbar. Diese Berechtigung kann nicht auf Objekte angewendet werden.
OWNER Der Nutzer erhält READER- und WRITER-Berechtigungen für den Bucket. Außerdem kann er Bucket-Metadaten einschließlich ACLs lesen und schreiben. Der Nutzer erhält READER-Zugriff. Außerdem kann er 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.

1 Die folgenden Metadatenattribute eines Buckets können nicht geändert werden: acl, cors, defaultObjectAcl, lifecycle, logging, versioning und website.

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. Falls Sie die OAuth 2.0-Authentifizierung zum Authentifizieren von Tools und Anwendungen (für das Zuweisen von Berechtigungen) verwenden, damit diese in Ihrem Namen auf die Google Cloud Storage API zugreifen können, wird der Zugriff durch die OAuth-Bereiche devstorage.read_only, devstorage.read_write und devstorage.full_control eingeschränkt. In der folgenden Tabelle sind die gängigen Berechtigungsbezeichnungen zusammengefasst:

JSON API XML API OAuth2-Bereich
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

Bereiche

Bereiche geben an, wer eine bestimmte Berechtigung hat.

Eine Zugriffssteuerungsliste 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
E-Mail-Adresse des Google-Kontos User collaborator@gmail.com
E-Mail-Adresse der Google-Gruppe Gruppe work-group@googlegroups.com
Konvergenzwerte für Projekte Projekt owners-123456789012
G Suite-Domain Domain [NUTZERNAME]@[IHRE_DOMAIN].com
Cloud Identity-Domain Domain [NUTZERNAME]@[IHRE_DOMAIN].com
Spezielle Kennung für alle Google-Kontoinhaber User allAuthenticatedUsers
Spezielle Kennung für alle Nutzer User allUsers
  • E-Mail-Adresse des Google-Kontos:

    Jeder Nutzer, der ein Google-Konto 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 zu einem Google-Konto gehört, z. B. mit einer gmail.com-Adresse.

    Cloud Storage merkt sich die E-Mail-Adressen, da diese in ACLs enthalten sind, bis die Einträge gelöscht oder überschrieben 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 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. Weitere Informationen zu Google-Gruppen finden Sie auf der Startseite von Google Groups.

    Genau wie bei E-Mail-Adressen von Google-Konten merkt sich Cloud Storage auch die E-Mail-Adressen von Gruppen, da sie in ACLs enthalten sind, bis die Einträge gelöscht oder überschrieben 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:

    Die Konvergenzwerte owners-<project-number>, editors-<project-number> und viewers-<project-number> stellen die Listen von Inhabern, Bearbeitern und Betrachtern des Projekts dar, dessen Projektnummer <project-number> lautet.

  • G Suite oder Cloud Identity:

    G Suite- 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 [NUTZERNAME]@[IHRE_DOMAIN].com. Sie können einen Bereich festlegen, indem Sie einen mit der G Suite oder Cloud Identity verknüpften Webdomain-Namen verwenden.

  • Spezielle Kennung für alle Google-Kontoinhaber:

    Diese spezielle Bereichskennung steht für alle, die mit einem Google-Konto authentifiziert wurden. Die spezielle Bereichskennung für alle Google-Kontoinhaber ist allAuthenticatedUsers.

  • Spezielle Kennung für alle Nutzer:

    Diese spezielle Bereichskennung steht für alle Nutzer im Internet, ob mit oder ohne Google-Konto. Die spezielle Bereichskennung für alle Nutzer ist allUsers.

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 Zugriffssteuerungsliste mit der Google Cloud Platform Console, JSON API oder gsutil können Sie 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 oder "gespeicherte" Zugriffssteuerungsliste 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. Vordefinierte ACLs gibt es für gängige Szenarien wie das Aufheben aller Zugriffsberechtigungen außer der des Inhabers (vordefinierte ACL private) oder das Umwandeln eines Objekts in ein öffentlich lesbares (vordefinierte ACL publicRead).

In der unten stehenden Tabelle sind die verfügbaren vordefinierten ACLs aufgelistet. 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 XML API/gsutil Beschreibung
    private private Gewährt dem Inhaber eines Buckets oder Objekts die Berechtigung OWNER für einen Bucket oder ein Objekt und entfernt alle anderen Zugriffsberechtigungen.
    bucketOwnerRead bucket-owner-read Gewährt dem Inhaber eines Objekts die Berechtigung OWNER und dem Inhaber eines Buckets die Berechtigung READER. Alle anderen Berechtigungen werden entfernt. Dies wird nur bei Objekten verwendet.
    bucketOwnerFullControl bucket-owner-full-control Gewährt den Inhabern von Objekten und Buckets die Berechtigung OWNER. Alle anderen Berechtigungen werden entfernt. 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 Google-Kontoinhabern die Berechtigung READER. Alle anderen Berechtigungen werden entfernt.
    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, überschreiben 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 Zugriffssteuerungsliste 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 Zugriffssteuerungslisten 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. Projektinhabern wird automatisch die Berechtigung OWNER für alle Buckets in ihrem Projekt gewährt. Wenn Sie ein Projekt erstellen, werden Sie als Projektinhaber hinzugefügt.

Wenn Sie einen Bucket mit der Standard-Bucket-ACL erstellen, also keine vordefinierte ACL angeben, wird auf den Bucket die vordefinierte ACL projectPrivate angewendet. Die ACL projectPrivate gewährt den Projektteammitgliedern basierend auf ihrer Rolle zusätzliche Berechtigungen. Diese sind wie folgt definiert:

  • Projektbetrachter

    Die ACL projectPrivate gewährt Projektbetrachtern den Zugriff READER auf Buckets in einem Projekt. Alle Projektteammitglieder können Objekte in Buckets auflisten. Außerdem können alle Projektteammitglieder Buckets innerhalb eines Projekts unabhängig von Bucket-ACLs auflisten.

  • Projektbearbeiter

    Die ACL projectPrivate gewährt Projektbearbeitern die Berechtigung OWNER für Buckets in einem Projekt. Projektbearbeiter können den Inhalt eines Buckets auflisten sowie Objekte in einem Bucket erstellen, überschreiben oder löschen. Außerdem können Projektbearbeiter auch Buckets unabhängig von Bucket-ACLs auflisten, erstellen und löschen.

  • Projektinhaber

    Die ACL projectPrivate gewährt Projektinhabern die Berechtigung OWNER. Neben administrativen Aufgaben wie dem Hinzufügen und Entfernen von Teammitgliedern oder dem Ändern von Zahlungsinformationen können Projektinhaber auch alle Aufgaben von Projektbearbeitern ausführen.

Projektbetrachter, -bearbeiter und -inhaber werden durch eine Kombination aus ihrer Rolle und der zugehörigen Projektnummer identifiziert. Beispielsweise werden Bearbeiter im Projekt 867489160491 mit project-editors-867489160491 bezeichnet. Ihre Projektnummer finden Sie auf der Startseite der Google Cloud Platform Console.

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 Zugriffssteuerungsliste 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. Dies bedeutet:

    • 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 überschreiben.

    • Ihnen (dem Objektinhaber) wird die Berechtigung OWNER für das Objekt gewährt. Wenn Sie versuchen, dem Inhaber weniger als die Berechtigung 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.

Best Practices

ACLs erfordern ebenso wie andere administrative Einstellungen eine aktive Verwaltung, um effektiv 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 ACL-Einstellungen für Buckets und Objekte anzupassen, insbesondere wenn Sie Buckets und Objekte 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 auf Buckets und Objekte nach dem Prinzip der geringsten Berechtigung.

    Das Prinzip der geringsten Berechtigung ist eine Richtschnur für die sichere Gewährung von Berechtigungen oder Rechten. Wenn Sie danach vorgehen, gewähren Sie nur die Berechtigung, die absolut notwendig ist, damit ein Nutzer die ihm zugewiesene Aufgabe erfüllen kann. Um beispielsweise eine Datei für jemanden freizugeben, gewähren Sie die Berechtigung READER und nicht OWNER.

  • Weisen Sie Personen, die Sie nicht kennen, nicht die Berechtigung OWNER zu.

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

  • Gehen Sie beim Gewähren von Berechtigungen für anonyme Nutzer vorsichtig vor.

    Die Bereiche 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 die Berechtigung OWNER zu gewähren.

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

    Ein nicht zugängliches Objekt kann nicht heruntergeladen (gelesen), sondern nur gelöscht werden. Dies kann passieren, wenn der Inhaber eines Objekts ein Projekt verlässt und niemandem die Berechtigung OWNER oder READER für das Objekt gewährt. Um dieses Problem zu umgehen, können Sie die vordefinierten ACLs bucket-owner-read oder bucket-owner-full- control nutzen, wenn Sie oder jemand anderes Objekte in Ihre Buckets hochlädt.

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

    Standardmäßig ist die Projektinhabergruppe die einzige Entität, die beim Erstellen eines Buckets die Berechtigung OWNER dafür hat. Ihre Projektinhabergruppe sollte immer mindestens zwei Mitglieder haben, damit Ihre Buckets weiterhin von einem anderen Projektinhaber verwaltet werden können, wenn ein Teammitglied die Gruppe verlässt.

  • Berücksichtigen Sie das interoperable Verhalten von Cloud Storage.

    Wenn die XML API für den interoperablen Zugriff mit anderen Speicherdiensten wie Amazon S3 verwendet wird, bestimmt der Signaturbezeichner die ACL-Syntax. Beispiel: Das von Ihnen verwendete Tool oder die Bibliothek sendet an Cloud Storage eine Anfrage zum Abrufen von ACLs. Dabei wird der Signaturbezeichner eines anderen Storage-Anbieters verwendet. Cloud Storage gibt in diesem Fall ein XML-Dokument mit der ACL-Syntax dieses Storage-Anbieters zurück. Weiteres Beispiel: Das von Ihnen verwendete Tool oder die Bibliothek sendet an Cloud Storage eine Anfrage zum Anwenden von ACLs. Dabei wird der Signaturbezeichner eines anderen Storage-Anbieters verwendet. Cloud Storage erwartet in diesem Fall den Empfang eines XML-Dokuments mit der Syntax dieses Storage-Anbieters.

    Weitere Informationen über die Verwendung der XML API für den interoperablen Zugriff mit Amazon S3 finden Sie unter Von Amazon S3 zu Google Cloud Storage migrieren.

Cloud Storage unterstützt Sie bei der Einhaltung dieser Best Practices durch einige Regeln für die Änderung von Zugriffssteuerungslisten, 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 Zugriffssteuerungsliste 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 die 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, indem Sie sie überschreiben. Das Überschreiben ist im Grunde eine Löschoperation, auf die 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 überschreibt (und damit Inhaber des Objekts wird), muss die Berechtigung WRITER oder OWNER für den Bucket haben, in den das Objekt hochgeladen wird.

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

Feedback geben zu...