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. # Zugriff verwalten mit ACLs Zugriffskontrolllisten (ACLs) sind eine der ressourcenbasierten Optionen, mit denen Sie den Zugriff auf Ihre Buckets und Objekte verwalten können. Sie können sie verwenden ACLs , um anderen grundlegende Lese-/Schreibberechtigungen zu gewähren. AWS-Konten Es gibt Einschränkungen bei der Verwaltung von Berechtigungen mithilfe von. ACLs Sie können beispielsweise nur anderen Benutzern Berechtigungen gewähren. AWS-Konten Sie können Benutzern in Ihrem Konto keine Berechtigungen gewähren. Sie können weder bedingte Berechtigungen gewähren noch Berechtigungen explizit verweigern. ACLs sind für bestimmte Szenarien geeignet. Wenn ein Bucket-Besitzer beispielsweise anderen AWS-Konten erlaubt, Objekte hochzuladen, können die Berechtigungen für diese Objekte nur von demjenigen, dem das Objekt gehört AWS-Konto , über die Objekt-ACL verwaltet werden. 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. Weitere Informationen zu ACLs finden Sie in den folgenden Themen. **Topics** + [Zugriffskontrolllisten (ACL) – Übersicht](acl-overview.md) + [Konfiguration ACLs](managing-acls.md) + [Beispiele für Richtlinien für ACLs](example-bucket-policies-condition-keys.md) # 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. # Konfiguration ACLs In diesem Abschnitt wird erklärt, wie Sie Zugriffsberechtigungen für S3-Buckets und Objekte mithilfe von Zugriffskontrolllisten (ACLs) verwalten. Sie können Ihrer Ressourcen-ACL mithilfe der AWS-Managementkonsole, AWS Command Line Interface (CLI), REST-API oder Grants hinzufügen AWS SDKs. Bucket- und Objekt-Berechtigungen sind voneinander unabhängig. Ein Objekt erbt nicht die Berechtigungen von seinem Bucket. Wenn Sie beispielsweise einen Bucket erstellen und einem Benutzer Schreibzugriff erteilen, können Sie auf die Objekte dieses Benutzers nicht zugreifen, wenn Ihnen der Benutzer nicht explizit Zugriff erteilt. Sie können anderen AWS-Konto Benutzern oder vordefinierten Gruppen Berechtigungen gewähren. Der Benutzer oder die Gruppe, dem bzw. der Sie Berechtigungen erteilen, wird als der *Berechtigungsempfänger* bezeichnet. Standardmäßig hat der Besitzer, der den AWS-Konto Bucket erstellt hat, volle Berechtigungen. Für jede Berechtigung, die Sie für einen Benutzer oder eine Gruppe erteilen, wird der dem Bucket zugeordneten ACL ein Eintrag hinzugefügt. Die ACL listet die erteilten Berechtigungen auf, die den Berechtigungsempfänger und die erteilte Berechtigung identifizieren. 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. **Warnung** Es wird dringend empfohlen, den **Gruppen **Jeder (öffentlicher Zugriff) oder Authentifizierte Benutzer (**alle AWS authentifizierten Benutzer)** keinen Schreibzugriff zu gewähren. Weitere Informationen zu den Auswirkungen eines Schreibzugriffs für diese Gruppen finden Sie unter [Vordefinierte Gruppen in Amazon S3](acl-overview.md#specifying-grantee-predefined-groups). ## Festlegen von ACL-Berechtigungen für einen Bucket mit der S3-Konsole Die Konsole zeigt kombinierte Zugriffsberechtigungen für doppelte Berechtigungsempfänger an. Um die vollständige Liste von zu sehen ACLs, verwenden Sie die Amazon S3 S3-REST-API AWS CLI,, oder AWS SDKs. Die folgende Tabelle zeigt die ACL-Berechtigungen, die Sie für Buckets in der Amazon-S3-Konsole konfigurieren können. **Amazon-S3-Konsolen-ACL-Berechtigungen für Buckets** | Konsolenberechtigung | ACL-Berechtigung | Zugriff | | --- | --- | --- | | Objekte – Auflisten | READ | Gestattet dem Empfänger, die Objekte im Bucket aufzulisten. | | Objekte – Schreiben | 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. | | Bucket-ACL – Lesen | READ\$1ACP | Gestattet dem Empfänger, die Bucket-ACL zu lesen. | | Bucket-ACL – Schreiben | WRITE\$1ACP | Gestattet dem Empfänger, die ACL für den relevanten Bucket zu schreiben. | | Jeder (öffentlicher Zugang): Objekte – Auflisten | READ | Gewährt öffentlichen Lesezugriff für die Objekte im Bucket. Wenn Sie jedem (öffentlichen Zugriff) Listenzugriff gewähren, kann jeder Benutzer auf der Welt auf die Objekte im Bucket zugreifen. | | Jeder (öffentlicher Zugriff): Bucket-ACL – Lesen | READ\$1ACP | Gewährt öffentlichen Lesezugriff für die Bucket-ACL. Wenn Sie jedem (öffentlicher Zugriff) Lesezugriff gewähren, kann jeder Benutzer auf der Welt auf die Bucket-ACL zugreifen. | Weitere Informationen zu ACL-Berechtigungen finden Sie unter [Zugriffskontrolllisten (ACL) – Übersicht](acl-overview.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. **Festlegen von ACL-Berechtigungen für einen Bucket** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Wählen Sie im linken Navigationsbereich **Allzweck-Buckets** aus. 1. Wählen Sie in der Liste **Buckets** den Namen des Buckets aus, für den Sie Berechtigungen festlegen möchten. 1. Wählen Sie **Permissions (Berechtigungen)**. 1. Wählen Sie unter **Access Control List** **Bearbeiten**. Sie können die folgenden ACL-Berechtigungen für den Bucket bearbeiten: **Objekte** + **Auflisten** – Gestattet einem Empfänger, die Objekte im Bucket aufzulisten. + **Schreiben** — Ermöglicht es dem Berechtigungsempfä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. In der S3-Konsole können Sie nur der S3-Protokollzustellungsgruppe und dem Bucket-Besitzer (Ihrem AWS-Konto) Schreibzugriff gewähren. Wir empfehlen dringend, anderen Empfängern keinen Schreibzugriff zu gewähren. Wenn Sie jedoch Schreibzugriff gewähren müssen, können Sie die AWS CLI AWS SDKs, oder die REST-API verwenden. **Bucket-ACL** + **Lesen** – Gestattet dem Empfänger, die Bucket-ACL zu lesen. + **Schreiben** – Gestattet dem Empfänger, die ACL für den relevanten Bucket zu schreiben. 1. Um die Berechtigungen des Bucket-Besitzers zu ändern, deaktivieren Sie neben **Bucket-Besitzer (Ihre AWS-Konto)** die folgenden ACL-Berechtigungen oder wählen Sie eine der folgenden ACL-Berechtigungen aus: + **Objekte** – **Auflisten** oder **Schreiben** + **Bucket-ACL** – **Lesen** oder **Schreiben** Der *Besitzer* bezieht sich auf den Root-Benutzer des AWS-Kontos, nicht auf einen AWS Identity and Access Management IAM-Benutzer. Weitere Informationen zum Root-Benutzer finden Sie unter [Der Root-Benutzer des AWS-Kontos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) im *IAM-Benutzerhandbuch*. 1. Um Berechtigungen für die Allgemeinheit (alle im Internet) zu erteilen oder rückgängig zu machen, deaktivieren oder wählen Sie neben **Jeder (öffentlicher Zugriff)** die folgenden ACL-Berechtigungen aus: + **Objekte** – **Auflisten** + **Bucket-ACL** – **Lesen** **Warnung** Seien Sie vorsichtig, wenn Sie der Gruppe **Everyone (Jeder)** öffentlichen Zugriff auf Ihren S3-Bucket gewähren. Wenn Sie dieser Gruppe anonymen Zugriff gewähren, kann jeder auf der ganzen Welt auf Ihren Bucket zugreifen. Wir empfehlen dringend, nie einen öffentlichen Schreibzugriff auf Ihren S3-Bucket zu gewähren. 1. Um einer Person, die neben der Gruppe „**Authentifizierte Benutzer“ noch eine AWS-Konto weitere Gruppe besitzt, Berechtigungen zu gewähren oder rückgängig zu machen (jeder, der eine besitzt AWS-Konto)**, deaktivieren Sie die folgenden ACL-Berechtigungen oder wählen Sie eine aus: + **Objekte** – **Auflisten** + **Bucket-ACL** – **Lesen** 1. Um Amazon S3 Berechtigungen zum Schreiben von Server-Zugriffsprotokollen in den Bucket zu erteilen oder rückgängig zu machen, deaktivieren oder wählen Sie unter der **S3-Protokoll-Bereitstellungsgruppe** die folgenden ACL-Berechtigungen aus: + **Objekte** – **Auflisten** oder **Schreiben** + **Bucket-ACL** – **Lesen** oder **Schreiben** Wenn ein Bucket als Ziel-Bucket für Zugriffsprotokolle eingerichtet ist, müssen die Bucket-Berechtigungen der Gruppe **Log Delivery (Protokollbereitstellung)** Schreibzugriff auf den Bucket erteilen. Wenn Sie die Server-Zugriffsprotokollierung für einen Bucket aktivieren, erteilt die Amazon-S3-Konsole der Gruppe **Log Delivery (Protokollbereitstellung)** Schreibzugriff auf den Ziel-Bucket, den Sie für den Empfang der Protokolle ausgewählt haben. Weitere Informationen zu Server-Zugriffsprotokollen finden Sie unter [Aktivieren Sie die Amazon-S3-Server-Zugriffsprotokollierung](enable-server-access-logging.md). 1. Gehen Sie wie folgt vor AWS-Konto, um einer anderen Person Zugriff zu gewähren: 1. Wählen Sie **Empfänger hinzufügen**. 1. Geben Sie im Feld **Empfänger** die kanonische ID des anderen AWS-Konto ein. 1. Wählen Sie aus den folgenden ACL-Berechtigungen aus: + **Objekte** – **Auflisten** oder **Schreiben** + **Bucket-ACL** – **Lesen** oder **Schreiben** **Warnung** Wenn Sie anderen Personen AWS-Konten Zugriff auf Ihre Ressourcen gewähren, sollten Sie sich bewusst sein, dass sie 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*. 1. Um den Zugriff auf eine andere Person zu entfernen AWS-Konto, wählen Sie unter **Zugriff für andere AWS-Konten die** Option **Entfernen** aus. 1. Klicken Sie auf **Save changes (Änderungen speichern)**, um die Änderungen zu speichern. ## Festlegen von ACL-Berechtigungen für ein Objekt mit der S3-Konsole Die Konsole zeigt kombinierte Zugriffsberechtigungen für doppelte Berechtigungsempfänger an. Um die vollständige Liste von zu sehen ACLs, verwenden Sie die Amazon S3 S3-REST-API AWS CLI,, oder AWS SDKs. Die folgende Tabelle zeigt die ACL-Berechtigungen, die Sie für Objekte in der Amazon-S3-Konsole konfigurieren können. **Amazon-S3-Konsolen-ACL-Berechtigungen für Objekte** | Konsolenberechtigung | ACL-Berechtigung | Zugriff | | --- | --- | --- | | Objekt – Lesen | READ | Gestattet dem Empfänger, die Objektedaten und seine Metadaten zu lesen. | | Objekt-ACL – Lesen | READ\$1ACP | Gestattet dem Empfänger, die Objekt-ACL zu lesen. | | Objekt-ACL – Schreiben | WRITE\$1ACP | Gestattet dem Empfänger, die ACL für das relevante Objekt zu schreiben | Weitere Informationen zu ACL-Berechtigungen finden Sie unter [Zugriffskontrolllisten (ACL) – Übersicht](acl-overview.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. **ACL-Berechtigungen für ein Objekt festlegen** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Wählen Sie in der Liste **Buckets** den Namen des Buckets aus, der das Objekt enthält. 1. Wählen Sie in der Liste **Objekte** den Namen des Objekts aus, für das Sie Berechtigungen festlegen möchten. 1. Wählen Sie **Permissions (Berechtigungen)**. 1. Wählen Sie unter Access Control List (ACL) die Option **Bearbeiten**. Sie können die folgenden ACL-Berechtigungen für das Objekt bearbeiten: **Objekt** + **Lesen** – Gestattet dem Empfänger, die Objektedaten und seine Metadaten zu lesen. **Objekt-ACL** + **Lesen** – Gestattet dem Empfänger, die Objekt-ACL zu lesen. + **Schreiben** – Gestattet dem Empfänger, die ACL für das relevante Objekt zu schreiben. In der S3-Konsole können Sie nur dem Bucket-Besitzer (Ihrem AWS-Konto) Schreibzugriff gewähren. Wir empfehlen dringend, anderen Empfängern keinen Schreibzugriff zu gewähren. Wenn Sie jedoch Schreibzugriff gewähren müssen, können Sie die AWS CLI AWS SDKs, oder die REST-API verwenden. 1. Sie können Zugriffsberechtigungen von Objekten für Folgendes verwalten: 1. **Zugriff für den Besitzer des Objekts** Der *Besitzer* bezieht sich auf den Root-Benutzer des AWS-Kontos und nicht auf einen AWS Identity and Access Management IAM-Benutzer. Weitere Informationen zum Root-Benutzer finden Sie unter [Der Root-Benutzer des AWS-Kontos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) im *IAM-Benutzerhandbuch*. Um die Objektzugriffsberechtigungen des Besitzers zu ändern, wählen Sie unter **Zugriff für Objekteigentümer** die Option **Ihr AWS Konto (Besitzer)** aus. Aktivieren Sie die Kontrollkästchen für die Berechtigungen, die geändert werden sollen. Wählen Sie dann **Save (Speichern)** aus. 1. **Zugriff für andere AWS-Konten** Um einem AWS Benutzer von einem anderen Benutzer Berechtigungen zu gewähren AWS-Konto, wählen Sie unter **Zugriff für andere AWS-Konten** die Option **Konto hinzufügen** aus. **Geben Sie im Feld Geben Sie eine ID** ein die kanonische ID des AWS Benutzers ein, dem Sie Objektberechtigungen erteilen möchten. Informationen zum Auffinden einer kanonischen ID finden Sie unter [Ihre AWS-Konto](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) Identifikatoren in der. *Allgemeine Amazon Web Services-Referenz* Sie können bis zu 99 Benutzer hinzufügen. Aktivieren Sie die Kontrollkästchen für die Berechtigungen, die dem Benutzer gewährt werden sollen. Wählen Sie dann **Save (Speichern)** aus. Um Informationen über die Berechtigungen anzuzeigen, wählen Sie die Hilfesymbole aus. 1. **Öffentlicher Zugriff** Um der allgemeinen Öffentlichkeit (jedem Benutzer auf der ganzen Welt) Zugriff auf Ihr Objekt zu gewähren, wählen Sie unter **Public access (Öffentlicher Zugriff)** **Everyone (Jeder)** aus. Die Erteilung öffentlicher Zugriffsberechtigungen bedeutet, dass jeder Benutzer auf der ganzen Welt auf das Objekt zugreifen kann. Aktivieren Sie die Kontrollkästchen für die Berechtigungen, die erteilt werden sollen. Wählen Sie dann **Save (Speichern)** aus. **Warnung** Seien Sie vorsichtig, wenn Sie der Gruppe **Everyone (Jeder)** anonymen Zugriff auf Ihre Amazon-S3-Objekte gewähren. Wenn Sie dieser Gruppe Zugriff gewähren, kann jeder auf der ganzen Welt auf Ihr Objekt zugreifen. Wenn Sie jedem Zugriff gewähren müssen, wird nachdrücklich empfohlen, dass Sie nur Berechtigungen für **Read objects (Objekte lesen)** gewähren. Wir empfehlen nachdrücklich, der Gruppe **Everyone (Jeder)** *keine* Schreibberechtigungen für Objekte zu erteilen. Dadurch können alle Benutzer die ACL-Berechtigungen für das Objekt überschreiben. ## Mit dem AWS SDKs Dieser Abschnitt enthält Beispiele, wie Access-Control-List(ACL)-Berechtigungen für Buckets und Objekte konfiguriert werden. **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 zum Einrichten von Zugriffskontrolllisten (ACLs) oder zur Aktualisierung ACLs fehl und geben den `AccessControlListNotSupported` Fehlercode zurück. Leseanfragen ACLs werden weiterhin unterstützt. ------ #### [ Java ] Dieser Abschnitt enthält Beispiele, wie Access-Control-List(ACL)-Berechtigungen für Buckets und Objekte konfiguriert werden. Das erste Beispiel erstellt einen Bucket mit einer vorgefertigten ACL (siehe [Vordefinierte ACL](acl-overview.md#canned-acl)), erstellt eine Liste benutzerdefinierter Berechtigungen und ersetzt die vorgefertigte ACL durch eine ACL mit den benutzerdefinierten Berechtigungen. Das zweite Beispiel veranschaulicht, wie Sie eine ACL mit der Methode `AccessControlList.grantPermission()` abändern. **Example Erstellen Sie einen Bucket und geben Sie eine vordefinierte ACL an, die der S3-Protokoll-Bereitstellungsgruppe die Berechtigung erteilt** Dieses Beispiel erstellt einen Bucket. In der Anfrage gibt das Beispiel eine vorgefertigte ACL an, die die Protokoll-Bereitstellungsgruppe zum Schreiben von Protokollen in den Bucket berechtigt. ``` import com.amazonaws.AmazonServiceException; import com.amazonaws.SdkClientException; import com.amazonaws.regions.Regions; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import com.amazonaws.services.s3.model.*; import java.io.IOException; import java.util.ArrayList; public class CreateBucketWithACL { public static void main(String[] args) throws IOException { Regions clientRegion = Regions.DEFAULT_REGION; String bucketName = "*** Bucket name ***"; String userEmailForReadPermission = "*** user@example.com ***"; try { AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withRegion(clientRegion) .build(); // Create a bucket with a canned ACL. This ACL will be replaced by the // setBucketAcl() // calls below. It is included here for demonstration purposes. CreateBucketRequest createBucketRequest = new CreateBucketRequest(bucketName, clientRegion.getName()) .withCannedAcl(CannedAccessControlList.LogDeliveryWrite); s3Client.createBucket(createBucketRequest); // Create a collection of grants to add to the bucket. ArrayList grantCollection = new ArrayList(); // Grant the account owner full control. Grant grant1 = new Grant(new CanonicalGrantee(s3Client.getS3AccountOwner().getId()), Permission.FullControl); grantCollection.add(grant1); // Grant the LogDelivery group permission to write to the bucket. Grant grant2 = new Grant(GroupGrantee.LogDelivery, Permission.Write); grantCollection.add(grant2); // Save grants by replacing all current ACL grants with the two we just created. AccessControlList bucketAcl = new AccessControlList(); bucketAcl.grantAllPermissions(grantCollection.toArray(new Grant[0])); s3Client.setBucketAcl(bucketName, bucketAcl); // Retrieve the bucket's ACL, add another grant, and then save the new ACL. AccessControlList newBucketAcl = s3Client.getBucketAcl(bucketName); Grant grant3 = new Grant(new EmailAddressGrantee(userEmailForReadPermission), Permission.Read); newBucketAcl.grantAllPermissions(grant3); s3Client.setBucketAcl(bucketName, newBucketAcl); } catch (AmazonServiceException e) { // The call was transmitted successfully, but Amazon S3 couldn't process // it and returned an error response. e.printStackTrace(); } catch (SdkClientException e) { // Amazon S3 couldn't be contacted for a response, or the client // couldn't parse the response from Amazon S3. e.printStackTrace(); } } } ``` **Example Aktualisieren der ACL für ein bestehendes Objekt** Dieses Beispiel aktualisiert die ACL für ein Objekt. Das Beispiel führt die folgenden Aufgaben durch: + Ruft die ACL eines Objekts ab + Löscht die ACL durch Entfernen aller vorhandenen Berechtigungen + Fügt zwei Berechtigungen hinzu: Vollzugriff für den Eigentümer und WRITE\$1ACP (siehe [Welche Berechtigungen kann ich erteilen?](acl-overview.md#permissions)) für einen anhand einer E-Mail-Adresse identifizierten Benutzer + Speichert die ACL im Objekt ``` import com.amazonaws.AmazonServiceException; import com.amazonaws.SdkClientException; import com.amazonaws.auth.profile.ProfileCredentialsProvider; import com.amazonaws.regions.Regions; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import com.amazonaws.services.s3.model.AccessControlList; import com.amazonaws.services.s3.model.CanonicalGrantee; import com.amazonaws.services.s3.model.EmailAddressGrantee; import com.amazonaws.services.s3.model.Permission; import java.io.IOException; public class ModifyACLExistingObject { public static void main(String[] args) throws IOException { Regions clientRegion = Regions.DEFAULT_REGION; String bucketName = "*** Bucket name ***"; String keyName = "*** Key name ***"; String emailGrantee = "*** user@example.com ***"; try { AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withCredentials(new ProfileCredentialsProvider()) .withRegion(clientRegion) .build(); // Get the existing object ACL that we want to modify. AccessControlList acl = s3Client.getObjectAcl(bucketName, keyName); // Clear the existing list of grants. acl.getGrantsAsList().clear(); // Grant a sample set of permissions, using the existing ACL owner for Full // Control permissions. acl.grantPermission(new CanonicalGrantee(acl.getOwner().getId()), Permission.FullControl); acl.grantPermission(new EmailAddressGrantee(emailGrantee), Permission.WriteAcp); // Save the modified ACL back to the object. s3Client.setObjectAcl(bucketName, keyName, acl); } catch (AmazonServiceException e) { // The call was transmitted successfully, but Amazon S3 couldn't process // it, so it returned an error response. e.printStackTrace(); } catch (SdkClientException e) { // Amazon S3 couldn't be contacted for a response, or the client // couldn't parse the response from Amazon S3. e.printStackTrace(); } } } ``` ------ #### [ .NET ] **Example Erstellen Sie einen Bucket und geben Sie eine vordefinierte ACL an, die der S3-Protokoll-Bereitstellungsgruppe die Berechtigung erteilt** Dieses C\$1-Beispiel erstellt einen Bucket. In der Anfrage gibt der Code auch eine vorgefertigte ACL an, die die Protokoll-Bereitstellungsgruppe zum Schreiben der Protokolle in den Bucket berechtigt. Informationen zum Einrichten und Ausführen der Codebeispiele finden Sie unter [Getting Started with the AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html) im *AWS SDK for .NET Developer Guide*. ``` using Amazon; using Amazon.S3; using Amazon.S3.Model; using System; using System.Threading.Tasks; namespace Amazon.DocSamples.S3 { class ManagingBucketACLTest { private const string newBucketName = "*** bucket name ***"; // Specify your bucket region (an example region is shown). private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; private static IAmazonS3 client; public static void Main() { client = new AmazonS3Client(bucketRegion); CreateBucketUseCannedACLAsync().Wait(); } private static async Task CreateBucketUseCannedACLAsync() { try { // Add bucket (specify canned ACL). PutBucketRequest putBucketRequest = new PutBucketRequest() { BucketName = newBucketName, BucketRegion = S3Region.EUW1, // S3Region.US, // Add canned ACL. CannedACL = S3CannedACL.LogDeliveryWrite }; PutBucketResponse putBucketResponse = await client.PutBucketAsync(putBucketRequest); // Retrieve bucket ACL. GetACLResponse getACLResponse = await client.GetACLAsync(new GetACLRequest { BucketName = newBucketName }); } catch (AmazonS3Exception amazonS3Exception) { Console.WriteLine("S3 error occurred. Exception: " + amazonS3Exception.ToString()); } catch (Exception e) { Console.WriteLine("Exception: " + e.ToString()); } } } } ``` **Example Aktualisieren der ACL für ein bestehendes Objekt** Dieses C\$1-Beispiel aktualisiert die ACL für ein vorhandenes Objekt. Das Beispiel führt die folgenden Aufgaben durch: + Ruft die ACL eines Objekts ab. + Löscht die ACL durch Entfernen aller vorhandenen Berechtigungen. + Fügt zwei Berechtigungen hinzu: Vollzugriff für den Eigentümer und WRITE\$1ACP für einen anhand einer E-Mail-Adresse identifizierten Benutzer. + Speichert die ACL durch Senden einer `PutAcl`-Anfrage. Informationen zum Einrichten und Ausführen der Codebeispiele finden Sie unter [Getting Started with the AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html) im *AWS SDK for .NET Developer Guide*. ``` using Amazon; using Amazon.S3; using Amazon.S3.Model; using System; using System.Collections.Generic; using System.Threading.Tasks; namespace Amazon.DocSamples.S3 { class ManagingObjectACLTest { private const string bucketName = "*** bucket name ***"; private const string keyName = "*** object key name ***"; private const string emailAddress = "*** email address ***"; // Specify your bucket region (an example region is shown). private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; private static IAmazonS3 client; public static void Main() { client = new AmazonS3Client(bucketRegion); TestObjectACLTestAsync().Wait(); } private static async Task TestObjectACLTestAsync() { try { // Retrieve the ACL for the object. GetACLResponse aclResponse = await client.GetACLAsync(new GetACLRequest { BucketName = bucketName, Key = keyName }); S3AccessControlList acl = aclResponse.AccessControlList; // Retrieve the owner (we use this to re-add permissions after we clear the ACL). Owner owner = acl.Owner; // Clear existing grants. acl.Grants.Clear(); // Add a grant to reset the owner's full permission (the previous clear statement removed all permissions). S3Grant fullControlGrant = new S3Grant { Grantee = new S3Grantee { CanonicalUser = owner.Id }, Permission = S3Permission.FULL_CONTROL }; // Describe the grant for the permission using an email address. S3Grant grantUsingEmail = new S3Grant { Grantee = new S3Grantee { EmailAddress = emailAddress }, Permission = S3Permission.WRITE_ACP }; acl.Grants.AddRange(new List { fullControlGrant, grantUsingEmail }); // Set a new ACL. PutACLResponse response = await client.PutACLAsync(new PutACLRequest { BucketName = bucketName, Key = keyName, AccessControlList = acl }); } catch (AmazonS3Exception amazonS3Exception) { Console.WriteLine("An AmazonS3Exception was thrown. Exception: " + amazonS3Exception.ToString()); } catch (Exception e) { Console.WriteLine("Exception: " + e.ToString()); } } } } ``` ------ ## Verwenden der REST-API Mit Amazon S3 APIs können Sie eine ACL festlegen, wenn Sie einen Bucket oder ein Objekt erstellen. Amazon S3 bietet auch eine API für die Einrichtung einer ACL für einen vorhandenen Bucket oder ein Objekt. Diese APIs bieten die folgenden Methoden zum Einrichten einer ACL: + **Einrichten von ACL mit Anfrageheadern** – Wenn Sie eine Anfrage senden, um eine Ressource zu erstellen (Bucket oder Objekt), richten Sie eine ACL über die Anfrage-Header ein. Mit Hilfe dieser Header können Sie entweder eine vordefinierte ACL angeben, oder explizit Rechte erteilen (mit expliziter Identifizierung von Empfänger und Berechtigungen). + **Einrichtung von ACL mithilfe des Anfragetextes** – Wenn Sie eine Anfrage senden, um ACL für eine vorhandene Ressource einzurichten, können Sie die ACL im Header oder im Text der Anfrage einrichten. Informationen zur REST-API-Unterstützung für die Verwaltung ACLs finden Sie in den folgenden Abschnitten der *Amazon Simple Storage Service API-Referenz*: + [GetBucketAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETacl.html) + [PutBucketAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTacl.html) + [GetObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGETacl.html) + [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUTacl.html) + [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) + [CreateBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUT.html) + [CopyObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html) + [CreateMultipartUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadInitiate.html) **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. ### Spezifische Anforderungs-Header für Access Control List (ACL) Sie können Header verwenden, um Berechtigungen auf der Basis von Access Control List (ACL) zu erteilen. Standardmäßig sind alle Objekte privat. Nur der Besitzer hat die vollständige Zugriffssteuerung. Wenn Sie ein neues Objekt hinzufügen, können Sie einzelnen AWS-Konten oder vordefinierten Gruppen, die von Amazon S3 definiert wurden, Berechtigungen gewähren. Diese Berechtigungen werden anschließend der Zugriffskontrollliste (Access Control List, ACL) für das Objekt hinzugefügt. Weitere Informationen finden Sie unter [Zugriffskontrolllisten (ACL) – Übersicht](acl-overview.md). Mit dieser Operation können Sie Zugriffsberechtigungen mit einer der folgenden beiden Methoden erteilen: + **Canned ACL (`x-amz-acl`)** — Amazon S3 unterstützt eine Reihe vordefinierter ACLs, sogenannter Canned ACL ACLs. Jede vordefinierte ACL hat eine vordefinierte Menge aus Empfängern und Berechtigungen. Weitere Informationen finden Sie unter [Vordefinierte ACL](acl-overview.md#canned-acl). + **Zugriffsberechtigungen** — Um bestimmten Gruppen AWS-Konten oder Gruppen explizit Zugriffsberechtigungen zu gewähren, verwenden Sie die folgenden Header. Jeder Header ist bestimmten Berechtigungen zugeordnet, die Amazon S3 in einer ACL unterstützt. Weitere Informationen finden Sie unter [Zugriffskontrolllisten (ACL) – Übersicht](acl-overview.md). Im Header geben Sie eine Liste der Empfänger an, die die jeweilige Berechtigung erhalten. + x-amz-grant-read + x-amz-grant-write + x-amz-grant-read-acp + x-amz-grant-write-acp + x-amz-grant-full-kontrollieren ## Mit dem AWS CLI Weitere Informationen zur Verwaltung ACLs mit dem AWS CLI finden Sie [put-bucket-acl](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-acl.html)in der *AWS CLI Befehlsreferenz*. **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. # Beispiele für Richtlinien für ACLs Sie können den Zugriff auf Amazon S3 über Bedingungsschlüssel in Bucket-Richtlinien steuern. **Topics** + [Gewährung von s3: PutObject Genehmigung mit einer Bedingung, nach der der Bucket-Besitzer die volle Kontrolle erlangen muss](#grant-putobject-conditionally-1) + [Erteilung der PutObject s3-Berechtigung mit einer Bedingung für den x-amz-acl Header](#example-acl-header) ## Gewährung von s3: PutObject Genehmigung mit einer Bedingung, nach der der Bucket-Besitzer die volle Kontrolle erlangen muss Die Operation [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) erlaubt Access Control List (ACL)-spezifische Header, mit denen Sie ACL-spezifische Berechtigungen erteilen können. Mit diesen Schlüsseln kann der Bucket-Eigentümer eine Bedingung festlegen, die bestimmte Zugriffsberechtigungen erfordert, wenn der Benutzer ein Objekt hochlädt. Angenommen, Konto A besitzt einen Bucket und der Kontoadministrator möchte Dave, einem Benutzer in Konto B, Berechtigungen zum Hochladen von Objekten erteilen. Standardmäßig gehören Objekte, die Dave hochgeladen hat, zu Konto B, und Konto A besitzt keine Berechtigungen für diese Objekte. Da der Bucket-Eigentümer die Rechnungen bezahlt, benötigt er volle Berechtigungen für die Objekte, die Dave hochlädt. Der Administrator von Konto A kann für diesen Zweck Dave die Berechtigung `s3:PutObject` erteilen. Dies erfolgt unter der Bedingung, dass die Anforderung ACL-spezifische Header enthält, die die vollständige Berechtigung explizit gewähren oder eine vordefinierte ACL verwenden. Weitere Informationen finden Sie unter [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html). ### Erfordert den x-amz-full-control Header Sie können in der Anforderung den Header `x-amz-full-control` mit vollständiger Kontrollberechtigung für den Bucket-Eigentümer anfordern. Die folgende Bucket-Richtlinie erteilt dem Benutzer Dave die Berechtigung `s3:PutObject` mit einer Bedingung, die den Bedingungsschlüssel `s3:x-amz-grant-full-control` enthält, in die Anforderung den Header `x-amz-full-control` aufzunehmen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Anmerkung** In diesem Beispiel geht es um die kontoübergreifende Berechtigung. Wenn Dave (der die Erlaubnis erhält) jedoch zu dem gehört AWS-Konto , dem der Bucket gehört, ist diese bedingte Berechtigung nicht erforderlich. Grund hierfür ist, dass das übergeordnete Konto, dem Dave angehört, Eigentümer von Objekten ist, die der Benutzer hochlädt. **Hinzufügen einer expliziten Zugriffsverweigerung** Die vorherige Bucket-Richtlinie erteilt dem Benutzer Dave in Konto B eine bedingte Berechtigung. Während diese Richtlinie in Kraft ist, ist es Dave möglich, die gleiche Berechtigung ohne Bedingung über eine andere Richtlinie zu erhalten. Beispiel: Dave kann einer Gruppe angehören, der Sie die Berechtigung `s3:PutObject` bedingungslos erteilen. Um solche Berechtigungslücken zu vermeiden, können Sie eine strengere Zugriffsrichtlinie schreiben, indem Sie eine explizite Zugriffsverweigerung hinzufügen. In diesem Beispiel verweigern Sie explizit die Upload-Berechtigung für Benutzer Dave, wenn er nicht die erforderlichen Header in die Anforderung einbindet, die dem Bucket-Eigentümer volle Berechtigungen gewährt. Eine explizite Verweigerung ersetzt immer eine anderswo erteilte Erlaubnis. Im Folgenden finden Sie das geänderte Zugriffsrichtlinienbeispiel mit hinzugefügter expliziter Ablehnung. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Testen Sie die Richtlinie mit dem AWS CLI** Wenn Sie zwei haben AWS-Konten, können Sie die Richtlinie mit dem AWS Command Line Interface (AWS CLI) testen. Sie hängen die Richtlinie an und verwenden Daves Anmeldeinformationen, um die Berechtigung mit dem folgenden AWS CLI `put-object` Befehl zu testen. Sie stellen dem Benutzer Dave die Anmeldeinformationen bereit, indem Sie den Parameter `--profile` hinzufügen. Sie erteilen dem Bucket-Eigentümer die volle Kontrolle, indem Sie den Parameter `--grant-full-control` hinzufügen. Weitere Informationen zur Einrichtung und Verwendung von finden Sie unter [Entwickeln mit Amazon S3 mithilfe der AWS CLI](https://docs.aws.amazon.com/AmazonS3/latest/API/setup-aws-cli.html) in der *Amazon S3 S3-API-Referenz*. AWS CLI ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile ``` ### Erfordert den x-amz-acl Header Sie können den Header `x-amz-acl` mit einer vordefinierten ACL anfordern, die dem Bucket-Eigentümer die vollständige Kontrollberechtigung erteilt. Um den Header `x-amz-acl` in der Anforderung erforderlich zu machen, können Sie das Schlüssel-Wert-Paar im Block `Condition` ersetzen und den Bedingungsschlüssel `s3:x-amz-acl` wie im folgenden Beispiel dargestellt angeben. ``` "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } ``` Um die Berechtigung mit dem zu testen AWS CLI, geben Sie den `--acl` Parameter an. Der fügt AWS CLI dann den `x-amz-acl` Header hinzu, wenn er die Anfrage sendet. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin ``` ## Erteilung der PutObject s3-Berechtigung mit einer Bedingung für den x-amz-acl Header Die folgende Bucket-Richtlinie gewährt die `s3:PutObject` Erlaubnis für zwei, AWS-Konten wenn die Anfrage den `x-amz-acl` Header enthält, der das Objekt öffentlich lesbar macht. Der `Condition`-Block verwendet die `StringEquals`-Bedingung und ist mit dem Schlüssel-Wert-Paar `"s3:x-amz-acl":["public-read"]` zur Auswertung versehen. Im Schlüssel-Wert-Paar ist `s3:x-amz-acl` ein Amazon S3–spezifischer Schlüssel, wie durch das Präfix `s3:` angezeigt ist. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AddCannedAcl", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::111122223333:root" ] }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::awsexamplebucket1/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } } ] } ``` ------ **Wichtig** Nicht alle Bedingungen machen für alle Aktionen auch Sinn. Beispielsweise ist es sinnvoll, die Bedingung `s3:LocationConstraint` für eine Richtlinie einzufügen, die die Amazon-S3-Berechtigung `s3:CreateBucket` erteilt. Es ist jedoch nicht sinnvoll, diese Bedingung in eine Richtlinie aufzunehmen, die die `s3:GetObject`-Genehmigung erteilt. Amazon S3 kann auf semantische Fehler dieses Typs testen, die Amazon-S3-spezifische Bedingungen beinhalten. Wenn Sie jedoch eine Richtlinie für eine(n) IAM-Benutzer oder -Rolle erstellen und eine semantisch ungültige Amazon-S3-Bedingung einfügen, wird kein Fehler gemeldet, weil IAM keine Amazon-S3-Bedingungen validieren kann.