Zugriffskontrolllisten (ACL) – Übersicht
Amazon-S3-Zugriffskontrolllisten (ACLs) ermöglichen Ihnen die Verwaltung des Bucket- und Objektzugriffs. Jedem Bucket und jedem Objekt ist eine ACL als Subressource zugeordnet. Eine ACL definiert, welche AWS-Konten oder -Gruppen Zugriff erhalten, und den Zugriffstyp. Wenn eine Anfrage für eine Ressource eingeht, überprüft Amazon S3 die entsprechende ACL,um sicherzustellen, dass der Anforderer die erforderlichen Zugriffsberechtigungen besitzt.
S3 Object Ownership ist eine Amazon-S3-Einstellung auf Bucket-Ebene, mit der Sie sowohl die Eigentümerschaft von den Objekten steuern können, die in Ihre Buckets hochgeladen werden, als auch ACLs deaktivieren oder aktivieren können. Standardmäßig ist Object Ownership auf die Einstellung „Bucket-Eigentümer erzwungen“ festgelegt und alle ACLs sind deaktiviert. Wenn ACLs deaktiviert sind, besitzt der Bucket-Eigentümer alle Objekte im Bucket und verwaltet den Zugriff darauf ausschließlich mithilfe von Zugriffsverwaltungsrichtlinien.
Die meisten modernen Anwendungsfälle in Amazon S3 erfordern keine ACLs mehr. Wir empfehlen Ihnen, ACLs deaktiviert zu lassen, außer unter ungewöhnlichen Umständen, in denen Sie den Zugriff für jedes Objekt einzeln steuern müssen. Wenn ACLs deaktiviert sind, können Sie mithilfe von Richtlinien den Zugriff auf alle Objekte in Ihrem Bucket steuern, unabhängig davon, wer die Objekte in Ihren Bucket hochgeladen hat. Weitere Informationen finden Sie unter Weitere Informationen finden Sie unter Steuern des Eigentums an Objekten und Deaktivieren von ACLs für Ihren Bucket..
Wichtig
Wenn Ihr Allzweck-Bucket die Einstellung „Vom Bucket-Besitzer erzwungen“ für S3 Object Ownership verwendet, müssen Sie Richtlinien für die Gewährung des Zugriffs auf Ihren Allzweck-Bucket und die enthaltenen Objekte verwenden. Wenn die Einstellung „Vom Bucket-Eigentümer erzwungen“ aktiviert ist, schlagen Anforderungen zum Festlegen von Zugriffssteuerungslisten (ACLs) oder zum Aktualisieren von ACLs fehl und geben den Fehlercode AccessControlListNotSupported zurück. Anfragen zum Lesen von ACLs werden weiterhin unterstützt.
Wenn Sie einen Bucket oder ein Objekt erstellen, erstellt Amazon S3 eine Standard-ACL, die dem Ressourcen-Eigentümer die volle Kontrolle über die Ressource erteilt. Dies ist in der folgenden Beispiel-Bucket-ACL gezeigt (die Standard-Objekt-ACL hat denselben Aufbau):
<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>*** Owner-Canonical-User-ID ***</ID> <DisplayName>owner-display-name</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Canonical User"> <ID>*** Owner-Canonical-User-ID ***</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> </AccessControlList> </AccessControlPolicy>
Die Beispiel-ACL enthält ein Owner-Element, das den Eigentümer über die kanonische Benutzer-ID des AWS-Konto identifiziert. Anweisungen zum Auffinden Ihrer kanonischen Benutzer-ID finden Sie unter Eine kanonische Benutzer-ID für ein AWS-Konto ermitteln. Das Grant-Element identifiziert den Empfänger (ein AWS-Konto oder eine vordefinierte Gruppe) und die erteilte Berechtigung. Diese Standard-ACL hat ein Grant-Element für den Eigentümer. Sie erteilen Berechtigungen, indem Sie Grant-Elemente hinzufügen, wobei jedes Recht den Empfänger und die Berechtigung identifiziert.
Anmerkung
Eine ACL kann bis zu 100 Rechte haben.
Themen
Wer ist ein Empfänger?
Wichtig
Hinweis zum Ende des Supports: Ab dem 1. Oktober 2025 wird Amazon S3 die Unterstützung für die Erstellung neuer Zugriffssteuerungslisten (ACL) für E-Mail-Empfänger einstellen. E-Mail-Zuschuss-ACLs, die vor diesem Datum erstellt wurden, funktionieren weiterhin und sind weiterhin über die AWS-Managementkonsole, die Befehlszeilenschnittstelle (CLI), SDKs und die REST-API zugänglich. Sie werden jedoch nicht mehr in der Lage sein, neue Email Grantee ACLs zu erstellen.
Zwischen dem 15. Juli 2025 und dem 1. Oktober 2025 werden Sie eine zunehmende Anzahl von HTTP 405 Fehlern bei Anfragen an Amazon S3 sehen, wenn Sie versuchen, neue Email Grantee ACLs zu erstellen.
Diese Änderung betrifft folgende AWS-Regionen: USA Ost (Nord-Virginia), USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Europa (Irland) und Südamerika (São Paulo).
Ein Empfänger kann ein AWS-Konto sein, oder eine der vordefinierten Amazon-S3-Gruppen. Sie erteilen einem AWS-Konto eine Berechtigung über die kanonische Benutzer-ID oder die E-Mail-Adresse Wenn Sie jedoch eine E-Mail-Adresse in Ihre Rechteerteilungsanfrage eintragen, findet Amazon S3 die kanonische Benutzer-ID für dieses Konto und fügt sie der ACL hinzu. Die resultierenden ACLs enthalten immer die kanonische Benutzer-ID für das AWS-Konto, nicht die E-Mail-Adresse des AWS-Konto.
Wenn Sie Zugriffsrechte erteilen, geben Sie jeden Empfänger als -Paar an, wobei type="value" einer der folgenden ist:type
id– Wenn der angegebene Wert die kanonische Benutzer-ID eines AWS-Konto isturi– Wenn Sie einer vordefinierten Gruppe Berechtigungen erteilenemailAddress– Wenn der angegebene Wert die E-Mail-Adresse eines AWS-Konto ist
Wichtig
Die Verwendung von E-Mail-Adressen zur Angabe eines Berechtigungsempfängers wird ausschließlich in den folgenden AWS-Regionen unterstützt:
-
USA Ost (Nord-Virginia)
-
USA West (Nordkalifornien)
-
USA West (Oregon)
-
Asien-Pazifik (Singapur)
-
Asien-Pazifik (Sydney)
-
Asien-Pazifik (Tokio)
-
Europa (Irland)
-
Südamerika (São Paulo)
Eine Liste aller unterstützten Amazon-S3-Regionen und -Endpunkte finden Sie unter Regionen und Endpunkte in der Allgemeine Amazon Web Services-Referenz.
Beispiel: E-Mail-Adresse
Der folgende x-amz-grant-read-Header gewährt beispielsweise den durch E-Mail-Adressen angegebenen AWS-Konten Berechtigungen zum Lesen von Objektdaten und ihren Metadaten:
x-amz-grant-read: emailAddress="xyz@example.com", emailAddress="abc@example.com"
Warnung
Wenn Sie anderen AWS-Konten Zugriff auf Ihre Ressourcen erteilen, müssen Sie beachten, dass die AWS-Konten ihre Berechtigungen an Benutzer unterhalb der Konten delegieren können. Man spricht auch von einem kontenübergreifenden Zugriff. Weitere Informationen zum kontenübergreifenden Zugriff finden Sie unter Erstellen einer Rolle, um Berechtigungen an einen IAM-Benutzer zu delegieren im IAM-Benutzerhandbuch.
Eine kanonische Benutzer-ID für ein AWS-Konto ermitteln
Die kanonische Benutzer-ID ist Ihrem zugeordnet AWS-Konto. Diese ID besteht aus einer langen Zeichenfolge, wie z. B.:
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be
Informationen dazu, wie Sie die kanonische Benutzer-ID für Ihr Konto finden, finden Sie unter Die kanonische Benutzer-ID für Ihr AWS-Konto finden im AWS-Referenzhandbuch zur Kontoverwaltung.
Sie können die kanonische Benutzer-IDs eines AWS-Konto auch ermitteln, indem Sie die ACL eines Buckets oder eines Objekts lesen, für den bzw. das das AWS-Konto Zugriffsberechtigungen besitzt. Wenn ein einzelnes AWS-Konto Berechtigungen durch eine Rechteerteilungsanfrage erhält, wird der ACL ein Rechteerteilungseintrag mit der kanonischen Benutzer-ID des Kontos hinzugefügt.
Anmerkung
Falls Sie Ihren Bucket öffentlich machen (nicht empfohlen), können beliebige, nicht authentifizierte Benutzer Objekte in den Bucket hochladen. Diese anonymen Benutzer haben kein AWS-Konto. Wenn ein anonymer Benutzer ein Objekt in Ihren Bucket hochlädt, fügt Amazon S3 eine spezielle kanonische Benutzer-ID (65a011a29cdf8ec533ec3d1ccaae921c) als Objekt-Eigentümer in der ACL hinzu. Weitere Informationen finden Sie unter Amazon-S3-Bucket- und Objekt-Eigentümerschaft.
Vordefinierte Gruppen in Amazon S3
Amazon S3 besitzt mehrere vordefinierte Gruppen. Wenn Sie einem Konto Zugriff auf eine Gruppe erteilen, geben Sie eine der Amazon-S3-URIs statt einer kanonischen Benutzer-ID an. Amazon S3 stellt die folgenden vordefinierten Gruppen bereit:
-
Gruppe „Authentifizierte Benutzer“ – Repräsentiert durch
http://acs.amazonaws.com/groups/global/AuthenticatedUsers.Diese Gruppe stellt alle dar AWS-Konten. Die Zugriffsberechtigung für diese Gruppe gestattet jedem AWS-Konto, auf die Ressource zuzugreifen. Alle Anfragen müssen jedoch signiert (authentifiziert) sein.
Warnung
Wenn Sie einen Zugriff auf die Gruppe „Authentifizierte Benutzer“ erteilen, hat jeder AWS-authentifizierte Benutzer weltweit Zugriff auf Ihre Ressource.
-
Gruppe „Alle Benutzer“ – Repräsentiert durch
http://acs.amazonaws.com/groups/global/AllUsers.Die Zugriffsberechtigung für diese Gruppe gestattet jedem, auf die Ressource zuzugreifen. Die Anfragen können signiert (authentifiziert) oder nicht signiert (anonym) sein. Nicht signierte Anfragen lassen den Authentifizierungs-Header in der Anfrage weg.
Warnung
Wir empfehlen dringend, dass Sie nie der Gruppe Alle Benutzer
WRITE-,WRITE_ACP- oderFULL_CONTROL-Berechtigungen erteilen. ObwohlWRITE-Berechtigungen Nicht-Besitzern das Überschreiben oder Löschen bestehender Objekte verwehren, erlaubenWRITE-Berechtigungen beispielsweise jedem, Objekte in Ihrem Bucket zu speichern, wofür Sie eine Rechnung erhalten. Weitere Informationen zu diesen Berechtigungen finden Sie im folgenden Abschnitt Welche Berechtigungen kann ich erteilen?. -
Gruppe „Protokollbereitstellung“ – Repräsentiert durch
http://acs.amazonaws.com/groups/s3/LogDelivery.Die
WRITE-Berechtigung für einen Bucket gestattet dieser Gruppe, Serverzugriff-Protokolle (siehe Protokollieren von Anfragen mit Server-Zugriffsprotokollierung) in den Bucket zu schreiben.
Anmerkung
Bei Verwendung von ACLs kann ein Empfänger ein AWS-Konto sein, oder eine der vordefinierten Amazon-S3-Gruppen. Der Empfänger kann jedoch kein IAM-Benutzer sein. Weitere Informationen zu AWS-Benutzern und Berechtigungen in IAM finden Sie unter Verwendung von AWS Identity and Access Management.
Welche Berechtigungen kann ich erteilen?
Die folgende Tabelle listet die Berechtigungen auf, die Amazon S3 in einer ACL unterstützt. Die Menge der ACL-Berechtigungen ist für eine Objekt-ACL und eine Bucket-ACL gleich. Abhängig vom Kontext (Bucket-ACL oder Objekt-ACL) erteilen jedoch diese ACL-Berechtigungen die Berechtigungen für spezifische Buckets oder Objekt-Vorgänge. Die Tabelle listet die Berechtigungen auf und beschreibt, was sie im Kontext der Objekte und Buckets bedeuten.
Weitere Informationen zu ACL-Berechtigungen in der Amazon-S3-Konsole finden Sie unter Konfigurieren von ACLs.
| Berechtigung | Bei Rechteerteilung für einen Bucket | Bei Rechteerteilung für ein Objekt |
|---|---|---|
READ |
Gestattet dem Empfänger, die Objekte im Bucket aufzulisten | Gestattet dem Empfänger, die Objektedaten und seine Metadaten zu lesen |
WRITE |
Gestattet dem Empfänger, neue Objekte im Bucket zu erstellen. Für die Bucket- und Objekteigentümer vorhandener Objekte können auch Löschungen und Überschreibungen dieser Objekte ermöglicht werden. | Nicht zutreffend |
READ_ACP |
Gestattet dem Empfänger, die Bucket-ACL zu lesen | Gestattet dem Empfänger, die Objekt-ACL zu lesen |
WRITE_ACP |
Gestattet dem Empfänger, die ACL für den relevanten Bucket zu schreiben | Gestattet dem Empfänger, die ACL für das relevante Objekt zu schreiben |
FULL_CONTROL |
Gewährt dem Berechtigungsempfänger die READ-, WRITE-, READ_ACP- und WRITE_ACP- Berechtigungen für den Bucket |
Gewährt dem Berechtigungsempfänger die READ-, READ_ACP- und WRITE_ACP-Berechtigungen für das Objekt |
Warnung
Seien Sie beim Gewähren von Zugriffsberechtigungen auf Ihre S3-Buckets und -Objekte vorsichtig. Beispielsweise kann der Berechtigungsempfänger nach dem Gewähren des WRITE-Zugriffs auf einen Bucket Objekte im Bucket erstellen. Wir empfehlen dringend, dass Sie vor dem Erteilen von Berechtigungen den gesamten Abschnitt zu Zugriffskontrolllisten (ACL) – Übersicht lesen.
Mapping der ACL-Berechtigungen und Zugriffsrichtlinienberechtigungen
Wie in der obigen Tabelle gezeigt, erteilt eine ACL nur eine endliche Menge an Berechtigungen im Vergleich zu der Anzahl an Berechtigungen, die Sie in einer Zugriffsrichtlinie festlegen können (siehe Richtlinienaktionen für Amazon S3). Jede dieser Berechtigungen erlaubt einen oder mehrere Amazon-S3-Vorgänge.
Die folgende Tabelle zeigt, wie die verschiedenen ACL-Berechtigungen auf die entsprechenden Zugriffsrichtlinienberechtigungen abgebildet werden. Wie Sie sehen, erteilt die Zugriffsrichtlinie mehr Berechtigungen als eine ACL. Sie verwenden ACLs in erster Linie, um grundlegende Lese-/Schreibberechtigungen zu erteilen, ähnlich den Berechtigungen in einem Dateisystem. Weitere Informationen dazu, wann Sie eine ACL verwenden sollten, finden Sie unter Identitäts- und Zugriffsverwaltung für Amazon S3.
Weitere Informationen zu ACL-Berechtigungen in der Amazon-S3-Konsole finden Sie unter Konfigurieren von ACLs.
| ACL-Berechtigung | Entsprechende Zugriffsrichtlinienberechtigungen, wenn einem Bucket die ACL-Berechtigung erteilt wurde | Entsprechende Zugriffsrichtlinienberechtigungen, wenn einem Objekt die ACL-Berechtigung erteilt wurde |
|---|---|---|
READ |
s3:ListBucket, s3:ListBucketVersions, und s3:ListBucketMultipartUploads |
s3:GetObject and s3:GetObjectVersion |
WRITE |
Der Bucket-Eigentümer kann jedes Objekt im Bucket erstellen, überschreiben und löschen, und der Objekteigentümer hat Wenn der Empfänger der Bucket-Eigentümer ist, gestattet die Erteilung der |
Nicht zutreffend |
READ_ACP |
s3:GetBucketAcl
|
s3:GetObjectAcl and s3:GetObjectVersionAcl |
WRITE_ACP |
s3:PutBucketAcl |
s3:PutObjectAcl and s3:PutObjectVersionAcl |
FULL_CONTROL |
Dies ist gleichbedeutend mit der Erteilung der READ-, WRITE-, READ_ACP- und WRITE_ACP-ACL-Berechtigungen. Dementsprechend wird diese ACL-Berechtigung auf eine Kombination entsprechender Zugriffsrichtlinienberechtigungen abgebildet. |
Dies ist gleichbedeutend mit der Erteilung der READ-, READ_ACP- und WRITE_ACP-ACL-Berechtigungen. Dementsprechend wird diese ACL-Berechtigung auf eine Kombination entsprechender Zugriffsrichtlinienberechtigungen abgebildet. |
Bedingungsschlüssel
Wenn Sie Zugriffsrichtlinienberechtigungen erteilen, können Sie Bedingungsschlüssel verwenden, um den Wert für die ACL für ein Objekt mithilfe einer Bucket-Richtlinie einzuschränken. Die folgenden Kontextschlüssel entsprechen ACLs. Sie können diese Kontextschlüssel verwenden, um die Verwendung einer bestimmten ACL in einer Anforderung durchzusetzen:
s3:x-amz-grant-read- Erfordert Lesezugriff.s3:x-amz-grant-write- Erfordert Schreibzugriff.s3:x-amz-grant-read-acp- Erfordert Lesezugriff auf die Bucket-ACL.s3:x-amz-grant-write-acp- Erfordert Schreibzugriff auf die Bucket-ACL.s3:x-amz-grant-full-control- Erfordert vollständige Kontrolle.s3:x-amz-acl‐ Erfordert eine Vordefinierte ACL.
Beispielrichtlinien, die ACL-spezifische Header enthalten, finden Sie unter Erteilen der s3:PutObject-Berechtigung mit einer Bedingung, die erfordert, dass der Bucket-Eigentümer die vollständige Kontrolle erhält. Eine vollständige Liste der Amazon-S3-spezifischen Bedingungsschlüssel finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für Amazon S3 in der Service-Authorization-Referenz.
Weitere Informationen zu den Berechtigungen für S3-API-Operationen nach S3-Ressourcentypen finden Sie unter Erforderliche Berechtigungen für Amazon-S3-API-Operationen.
aclRequired-Werte für allgemeine Amazon-S3-Anfragen
Wenn Sie Amazon-S3-Anforderungen identifizieren möchten, für die ACLs zur Autorisierung erforderlich waren, können Sie den Wert aclRequired in den Amazon-S3-Serverzugriffsprotokollen oder AWS CloudTrail verwenden. Der aclRequired-Wert, der in den CloudTrail- oder Amazon S3-Serverzugriffsprotokollen erscheint, hängt davon ab, welche Operationen aufgerufen wurden, und von bestimmten Informationen über den Anforderer, Objekteigentümer und Bucket-Besitzer. Wenn keine ACLs erforderlich waren oder Sie die vordefinierte bucket-owner-full-control-ACL einrichten oder die Anfragen von Ihrer Bucket-Richtlinie zugelassen werden, lautet die aclRequired-Wertzeichenfolge in den Amazon S3-Serverzugriffsprotokollen „-“ und in CloudTrail fehlt sie.
In den folgenden Tabellen sind die erwarteten aclRequired-Werte in den CloudTrail- oder Amazon-S3-Serverzugriffsprotokollen für die verschiedenen Amazon-S3-API-Operationen aufgeführt. Sie können diese Informationen verwenden, um zu verstehen, welche Amazon-S3-Operationen für die Autorisierung von ACLs abhängig sind. In den folgenden Tabellen stellen A, B und C die verschiedenen Konten dar, die dem Anforderer, Objekteigentümer und Bucket-Besitzer zugeordnet sind. Einträge mit einem Sternchen (*) geben eines der Konten A, B oder C an.
Anmerkung
PutObject-Operationen in der folgenden Tabelle geben, sofern nicht anders spezifiziert, Anfragen an, die keine ACL festlegen, es sei denn, die ACL ist eine bucket-owner-full-control-ACL. Ein Nullwert für aclRequired gibt an, dass aclRequired in AWS CloudTrail-Protokollen fehlt.
Die folgende Tabelle zeigt die aclRequired-Werte für CloudTrail.
| Vorgangsname | Auftraggeber | Objekteigentümer | Bucket-Eigentümer | Bucket-Richtlinie gewährt Zugriff | aclRequired value (Wert) |
Grund |
|---|---|---|---|---|---|---|
GetObject |
A | A | A | Sie können zwischen Yes und No wählen | Null | Zugriff auf dasselbe Konto |
GetObject |
A | B | A | Sie können zwischen Yes und No wählen | Null | Zugriff auf dasselbe Konto mit erzwungenem Bucket-Eigentümer |
GetObject |
A | A | B | Ja | Null | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
GetObject |
A | A | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
GetObject |
A | A | B | Ja | Null | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
GetObject |
A | B | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
GetObject |
A | B | C | Ja | Null | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
GetObject |
A | B | C | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
PutObject |
A | Nicht zutreffend | A | Sie können zwischen Yes und No wählen | Null | Zugriff auf dasselbe Konto |
PutObject |
A | Nicht zutreffend | B | Ja | Null | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
PutObject |
A | Nicht zutreffend | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
PutObject mit einer ACL (außer bucket-owner-full-control) |
* | Nicht zutreffend | * | Sie können zwischen Yes und No wählen | Ja | Anforderung gewährt ACL |
ListObjects |
A | Nicht zutreffend | A | Sie können zwischen Yes und No wählen | Null | Zugriff auf dasselbe Konto |
ListObjects |
A | Nicht zutreffend | B | Ja | Null | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
ListObjects |
A | Nicht zutreffend | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
DeleteObject |
A | Nicht zutreffend | A | Sie können zwischen Yes und No wählen | Null | Zugriff auf dasselbe Konto |
DeleteObject |
A | Nicht zutreffend | B | Ja | Null | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
DeleteObject |
A | Nicht zutreffend | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
PutObjectAcl |
* | * | * | Sie können zwischen Yes und No wählen | Ja | Anforderung gewährt ACL |
PutBucketAcl |
* | Nicht zutreffend | * | Sie können zwischen Yes und No wählen | Ja | Anforderung gewährt ACL |
Anmerkung
REST.PUT.OBJECT-Operationen in der folgenden Tabelle geben, sofern nicht anders spezifiziert, Anfragen an, die keine ACL festlegen, es sei denn, die ACL ist eine bucket-owner-full-control-ACL. Eine aclRequired-Wertzeichenfolge von „-“ gibt einen Nullwert in den Amazon-S3-Serverzugriffsprotokollen an.
Die folgende Tabelle zeigt die aclRequired-Werte für Amazon-S3-Serverzugriffsprotokolle.
| Vorgangsname | Auftraggeber | Objekteigentümer | Bucket-Eigentümer | Bucket-Richtlinie gewährt Zugriff | aclRequired value (Wert) |
Grund |
|---|---|---|---|---|---|---|
REST.GET.OBJECT |
A | A | A | Sie können zwischen Yes und No wählen | - | Zugriff auf dasselbe Konto |
REST.GET.OBJECT |
A | B | A | Sie können zwischen Yes und No wählen | - | Zugriff auf dasselbe Konto mit erzwungenem Bucket-Eigentümer |
REST.GET.OBJECT |
A | A | B | Ja | - | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
REST.GET.OBJECT |
A | A | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
REST.GET.OBJECT |
A | B | B | Ja | - | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
REST.GET.OBJECT |
A | B | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
REST.GET.OBJECT |
A | B | C | Ja | - | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
REST.GET.OBJECT |
A | B | C | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
REST.PUT.OBJECT |
A | Nicht zutreffend | A | Sie können zwischen Yes und No wählen | - | Zugriff auf dasselbe Konto |
REST.PUT.OBJECT |
A | Nicht zutreffend | B | Ja | - | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
REST.PUT.OBJECT |
A | Nicht zutreffend | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
REST.PUT.OBJECT mit einer ACL (außer bucket-owner-full-control) |
* | Nicht zutreffend | * | Sie können zwischen Yes und No wählen | Ja | Anforderung gewährt ACL |
REST.GET.BUCKET |
A | Nicht zutreffend | A | Sie können zwischen Yes und No wählen | - | Zugriff auf dasselbe Konto |
REST.GET.BUCKET |
A | Nicht zutreffend | B | Ja | - | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
REST.GET.BUCKET |
A | Nicht zutreffend | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
REST.DELETE.OBJECT |
A | Nicht zutreffend | A | Sie können zwischen Yes und No wählen | - | Zugriff auf dasselbe Konto |
REST.DELETE.OBJECT |
A | Nicht zutreffend | B | Ja | - | Von Bucket-Richtlinie gewährter kontoübergreifender Zugriff |
REST.DELETE.OBJECT |
A | Nicht zutreffend | B | Nein | Ja | Kontoübergreifender Zugriff ist auf ACL angewiesen |
REST.PUT.ACL |
* | * | * | Sie können zwischen Yes und No wählen | Ja | Anforderung gewährt ACL |
Beispiel-ACL
Die folgende Beispiel-ACL für einen Bucket identifiziert den Ressourcen-Eigentümer und eine Menge von Rechten. Das Format ist die XML-Darstellung einer ACL in der Amazon-S3-REST-API. Der Bucket-Eigentümer hat die FULL_CONTROL über die Ressource. Darüber hinaus zeigt die ACL, wie Berechtigungen für eine Ressource an zwei AWS-Konten erteilt werden, identifiziert durch eine kanonische Benutzer-ID, und an zwei der vordefinierten Amazon-S3-Gruppen, wie im vorigen Abschnitt beschrieben.
<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>Owner-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>Owner-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>user1-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>WRITE</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>user2-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>READ</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> </Grantee> <Permission>READ</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI> </Grantee> <Permission>WRITE</Permission> </Grant> </AccessControlList> </AccessControlPolicy>
Vordefinierte ACL
Amazon S3 unterstützt einen Satz vordefinierter Rechte, auch als vordefinierte ACLs bezeichnet. Jede vordefinierte ACL hat eine vordefinierte Menge aus Empfängern und Berechtigungen. Die folgende Tabelle listet die Menge der vordefinierten ACLs und der zugehörigen vordefinierten Rechte auf.
| Vordefinierte ACL | Gilt für | Der ACL hinzugefügte Berechtigungen |
|---|---|---|
private |
Bucket und Objekt | Der Eigentümer erhält FULL_CONTROL. Niemand anderer hat Zugriffsrechte (Standard). |
public-read |
Bucket und Objekt | Der Eigentümer erhält FULL_CONTROL. Die AllUsers-Gruppe (siehe Wer ist ein Empfänger?) erhält READ-Zugriff. |
public-read-write |
Bucket und Objekt | Der Eigentümer erhält FULL_CONTROL. Die AllUsers-Gruppe erhält READ- und WRITE-Zugriff. Eine solche Erteilung von Rechten für einen Bucket wird im Allgemeinen nicht empfohlen. |
aws-exec-read |
Bucket und Objekt | Der Eigentümer erhält FULL_CONTROL. Amazon EC2; erhält READ-Zugriff auf ein GET, ein Amazon Machine Image (AMI)-Paket von Amazon S3. |
authenticated-read |
Bucket und Objekt | Der Eigentümer erhält FULL_CONTROL. Die AuthenticatedUsers-Gruppe erhält READ-Zugriff. |
bucket-owner-read |
Object | Der Objekt-Eigentümer erhält FULL_CONTROL. Der Bucket-Eigentümer erhält READ-Zugriff. Wenn Sie diese vordefinierte ACL beim Erstellen eines Buckets angeben, ignoriert Amazon S3 sie. |
bucket-owner-full-control |
Object | Sowohl der Objekt-Eigentümer, als auch der Bucket-Eigentümer erhalten FULL_CONTROL für das Objekt. Wenn Sie diese vordefinierte ACL beim Erstellen eines Buckets angeben, ignoriert Amazon S3 sie. |
log-delivery-write |
Bucket | Die LogDelivery-Gruppe erhält WRITE- und READ_ACP-Berechtigungen für den Bucket. Weitere Informationen über Protokolle finden Sie unter (Protokollieren von Anfragen mit Server-Zugriffsprotokollierung). |
Anmerkung
Sie können auch in Ihrer Anfrage nur eine dieser vordefinierten ACLs angeben.
Sie geben mit dem Anfrage-Header x-amz-acl eine vordefinierte ACL in Ihrer Anfrage an. Wenn Amazon S3 eine Anfrage mit einer vordefinierten ACL erhält, fügt es die vordefinierten Rechte der ACL der Ressource hinzu.