Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Zugriffskontrolllisten (ACL) – Übersicht Mit Amazon S3 S3-Zugriffskontrolllisten (ACLs) können Sie den Zugriff auf Buckets und Objekte verwalten. Jedem Bucket und jedem Objekt ist eine ACL als Subressource zugeordnet. Sie definiert, welchen AWS-Konten Gruppen Zugriff gewährt wird und welche Art von Zugriff gewährt wird. 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 Einstellung auf Amazon S3 S3-Bucket-Ebene, mit der Sie sowohl das Eigentum an den Objekten kontrollieren können, die in Ihren Bucket hochgeladen werden, als auch um sie zu deaktivieren oder zu aktivieren. ACLs Standardmäßig ist für Object Ownership die erzwungene Einstellung des Bucket-Besitzers festgelegt, und alle sind ACLs deaktiviert. Wenn ACLs diese Option deaktiviert ist, besitzt der Bucket-Besitzer alle Objekte im Bucket und verwaltet den Zugriff darauf ausschließlich mithilfe von Zugriffsverwaltungsrichtlinien. Für die meisten modernen Anwendungsfälle in Amazon S3 ist die Verwendung von nicht mehr erforderlich ACLs. Wir empfehlen, die ACLs Option deaktiviert zu lassen, außer in Fällen, in denen Sie den Zugriff für jedes Objekt einzeln steuern müssen. Wenn diese ACLs Option deaktiviert ist, 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 [Kontrolle des Besitzes von Objekten und Deaktivierung ACLs für Ihren Bucket](about-object-ownership.md). **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 „Bucket Owner erforced“ aktiviert ist, schlagen Anfragen zur Einrichtung von Zugriffskontrolllisten (ACLs) oder zur Aktualisierung ACLs fehl und geben den `AccessControlListNotSupported` Fehlercode zurück. Leseanfragen 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): **Example** ``` 1. 2. 3. 4. *** Owner-Canonical-User-ID *** 5. 6. 7. 8. 10. *** Owner-Canonical-User-ID *** 11. 12. FULL_CONTROL 13. 14. 15. ``` 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 AWS-Konto kanonische Benutzer-ID finden](#finding-canonical-id). Das `Grant` Element identifiziert den Empfänger (entweder eine 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. **Topics** + [Wer ist ein Empfänger?](#specifying-grantee) + [Welche Berechtigungen kann ich erteilen?](#permissions) + [`aclRequired`-Werte für allgemeine Amazon-S3-Anfragen](#aclrequired-s3) + [Beispiel-ACL](#sample-acl) + [Vordefinierte ACL](#canned-acl) ## Wer ist ein Empfänger? Wenn Sie Zugriffsrechte erteilen, geben Sie jeden Empfänger als `type="value"`-Paar an, wobei `type` einer der folgenden ist: + `id`— Wenn der angegebene Wert die kanonische Benutzer-ID eines AWS-Konto + `uri` – Wenn Sie einer vordefinierten Gruppe Berechtigungen erteilen **Warnung** Wenn Sie anderen Personen AWS-Konten Zugriff auf Ihre Ressourcen gewähren, sollten Sie sich bewusst sein, dass diese ihre Berechtigungen an Benutzer unter ihren Konten delegieren AWS-Konten 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*. ### Eine AWS-Konto kanonische Benutzer-ID finden Die kanonische Benutzer-ID ist Ihrem AWS-Konto zugeordnet. 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](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) im *AWS -Referenzhandbuch zur Kontoverwaltung*. Sie können die kanonische Benutzer-ID eines auch nachschlagen, AWS-Konto indem Sie die ACL eines Buckets oder eines Objekts lesen, für das AWS-Konto er Zugriffsberechtigungen besitzt. Wenn einer Person AWS-Konto durch eine Erteilungsanfrage Berechtigungen erteilt werden, wird der ACL ein Grant-Eintrag mit der kanonischen Benutzer-ID des Accounts 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](access-policy-language-overview.md#about-resource-owner). ### Vordefinierte Gruppen in Amazon S3 Amazon S3 besitzt mehrere vordefinierte Gruppen. Wenn Sie einer Gruppe Kontozugriff gewähren, geben Sie eine der Amazon S3 URIs anstelle 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 steht für alles. AWS-Konten**Die Zugriffsberechtigung für diese Gruppe ermöglicht es jedem AWS-Konto , auf die Ressource zuzugreifen.** Alle Anfragen müssen jedoch signiert (authentifiziert) sein. **Warnung** Wenn Sie der **Gruppe Authentifizierte Benutzer** Zugriff gewähren, kann jeder AWS authentifizierte Benutzer auf der Welt auf Ihre Ressource zugreifen. + ****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`- oder `FULL_CONTROL`-Berechtigungen erteilen. Obwohl `WRITE`-Berechtigungen Nicht-Besitzern das Überschreiben oder Löschen bestehender Objekte verwehren, erlauben `WRITE`-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?](#permissions). + ****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](ServerLogs.md)) in den Bucket zu schreiben. **Anmerkung** Bei der Nutzung kann ACLs es sich bei einem Empfänger um eine AWS-Konto oder eine der vordefinierten Amazon S3 S3-Gruppen handeln. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## 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 [Konfiguration ACLs](managing-acls.md). | 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\$1ACP | Gestattet dem Empfänger, die Bucket-ACL zu lesen | Gestattet dem Empfänger, die Objekt-ACL zu lesen | | WRITE\$1ACP | 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\$1CONTROL | Gewährt dem Berechtigungsempfänger die READ-, WRITE-, READ\$1ACP- und WRITE\$1ACP- Berechtigungen für den Bucket | Gewährt dem Berechtigungsempfänger die READ-, READ\$1ACP- und WRITE\$1ACP-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](#acl-overview) 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](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)). 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 werden ACLs hauptsächlich verwendet, um grundlegende read/write Berechtigungen zu gewähren, ähnlich wie Dateisystemberechtigungen. Weitere Informationen dazu, wann Sie eine ACL verwenden sollten, finden Sie unter [Identitäts- und Zugriffsverwaltung für Amazon S3](security-iam.md). Weitere Informationen zu ACL-Berechtigungen in der Amazon-S3-Konsole finden Sie unter [Konfiguration ACLs](managing-acls.md). | 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 und s3:GetObjectVersion | | WRITE | `s3:PutObject` Der Bucket-Eigentümer kann jedes Objekt im Bucket erstellen, überschreiben und löschen, und der Objekteigentümer hat `FULL_CONTROL` über sein Objekt. Wenn der Empfänger der Bucket-Eigentümer ist, gestattet die Erteilung der `WRITE`-Berechtigung in einer Bucket-ACL außerdem, dass die `s3:DeleteObjectVersion`-Aktion für jede Version in diesem Bucket ausgeführt wird. | Nicht zutreffend | | READ\$1ACP | s3:GetBucketAcl | s3:GetObjectAcl und s3:GetObjectVersionAcl | | WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl und s3:PutObjectVersionAcl | | FULL\$1CONTROL | Dies ist gleichbedeutend mit der Erteilung der READ-, WRITE-, READ\$1ACP- und WRITE\$1ACP-ACL-Berechtigungen. Dementsprechend wird diese ACL-Berechtigung auf eine Kombination entsprechender Zugriffsrichtlinienberechtigungen abgebildet. | Dies ist gleichbedeutend mit der Erteilung der READ-, READ\$1ACP- und WRITE\$1ACP-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](#canned-acl). Beispielrichtlinien, die ACL-spezifische Header enthalten, finden Sie unter [Gewährung von s3: PutObject Genehmigung mit einer Bedingung, nach der der Bucket-Besitzer die volle Kontrolle erlangen muss](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1). Eine vollständige Liste der Amazon-S3-spezifischen Bedingungsschlüssel finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Amazon S3](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html) 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](using-with-s3-policy-actions.md). ## `aclRequired`-Werte für allgemeine Amazon-S3-Anfragen Um Amazon S3 S3-Anfragen zu identifizieren, die ACLs für eine Autorisierung erforderlich sind, können Sie den `aclRequired` Wert in den Amazon S3 S3-Serverzugriffsprotokollen oder verwenden AWS CloudTrail. Der `aclRequired` Wert, der in CloudTrail unseren 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 erforderlich ACLs waren oder wenn Sie die gespeicherte ACL festlegen oder wenn die `bucket-owner-full-control` Anfragen gemäß Ihrer Bucket-Richtlinie zulässig sind, lautet die `aclRequired` Wertzeichenfolge in den Amazon S3 S3-Serverzugriffsprotokollen `-` "" und fehlt in CloudTrail. In den folgenden Tabellen sind die erwarteten `aclRequired` Werte in CloudTrail unseren Amazon S3 S3-Serverzugriffsprotokollen für die verschiedenen Amazon S3 S3-API-Operationen aufgeführt. Sie können diese Informationen verwenden, um zu verstehen, von welchen Amazon S3 S3-Vorgängen ACLs die Autorisierung abhängt. 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 (\$1) 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 dieser `aclRequired` Wert in den 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` 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) | \$1 | Nicht zutreffend | \$1 | 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 | \$1 | \$1 | \$1 | Sie können zwischen Yes und No wählen | Ja | Anforderung gewährt ACL | | PutBucketAcl | \$1 | Nicht zutreffend | \$1 | 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` 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) | \$1 | Nicht zutreffend | \$1 | 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 | \$1 | \$1 | \$1 | 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 zwei der vordefinierten Amazon S3 S3-Gruppen AWS-Konten, die im vorherigen Abschnitt beschrieben wurden, Berechtigungen für eine Ressource gewährt werden, die anhand einer kanonischen Benutzer-ID identifiziert werden. **Example** ``` 1. 2. 3. 4. Owner-canonical-user-ID 5. 6. 7. 8. 9. Owner-canonical-user-ID 10. 11. FULL_CONTROL 12. 13. 14. 15. 16. user1-canonical-user-ID 17. 18. WRITE 19. 20. 21. 22. 23. user2-canonical-user-ID 24. 25. READ 26. 27. 28. 29. 30. http://acs.amazonaws.com/groups/global/AllUsers 31. 32. READ 33. 34. 35. 36. http://acs.amazonaws.com/groups/s3/LogDelivery 37. 38. WRITE 39. 40. 41. 42. ``` ## Vordefinierte ACL Amazon S3 unterstützt eine Reihe vordefinierter Zuschüsse, die als *vorgefertigte* Zuschüsse bezeichnet ACLs werden. Jede vordefinierte ACL hat eine vordefinierte Menge aus Empfängern und Berechtigungen. In der folgenden Tabelle sind die vordefinierten Zuschüsse ACLs und die zugehörigen vordefinierten Zuschüsse aufgeführt. | Vordefinierte ACL | Gilt für | Der ACL hinzugefügte Berechtigungen | | --- | --- | --- | | private | Bucket und Objekt | Der Eigentümer erhält FULL\$1CONTROL. Niemand anderer hat Zugriffsrechte (Standard). | | public-read | Bucket und Objekt | Der Eigentümer erhält FULL\$1CONTROL. Die AllUsers-Gruppe (siehe [Wer ist ein Empfänger?](#specifying-grantee)) erhält READ-Zugriff. | | public-read-write | Bucket und Objekt | Der Eigentümer erhält FULL\$1CONTROL. 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\$1CONTROL. Amazon EC2; erhält GET-Zugriff auf ein READ, ein Amazon Machine Image (AMI)-Paket von Amazon S3. | | authenticated-read | Bucket und Objekt | Der Eigentümer erhält FULL\$1CONTROL. Die AuthenticatedUsers-Gruppe erhält READ-Zugriff. | | bucket-owner-read | Objekt | Der Objekt-Eigentümer erhält FULL\$1CONTROL. 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 | Objekt | Sowohl der Objekt-Eigentümer, als auch der Bucket-Eigentümer erhalten FULL\$1CONTROL 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\$1ACP-Berechtigungen für den Bucket. Weitere Informationen über Protokolle finden Sie unter ([Protokollieren von Anfragen mit Server-Zugriffsprotokollierung](ServerLogs.md)). | **Anmerkung** Sie können ACLs in Ihrer Anfrage nur eines dieser vorgefertigten Pakete 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.