Weitere Informationen finden Sie unter Steuern des Eigentums an Objekten und Deaktivieren von ACLs für Ihren Bucket.

S3 Object Ownership ist eine Amazon-S3-Einstellung auf Bucket-Ebene, mit der Sie die Eigentümerschaft von Objekten steuern können, die in Ihre Buckets hochgeladen werden, und Zugriffssteuerungslisten (ACLs) deaktivieren oder aktivieren können. Standardmäßig ist die Objekteigentümerschaft 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 Datenzugriff 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 jedes Objekt in Ihrem Bucket besser steuern, unabhängig davon, wer die Objekte in Ihren Bucket hochgeladen hat.

Object Ownership verfügt über drei Einstellungen, mit denen Sie die Eigentümerschaft von Objekten, die in Ihren Bucket hochgeladen werden, steuern und ACLs deaktivieren oder aktivieren können:

Deaktivierte ACLs

• Bucket-Eigentümer erzwungen (Standard) – ACLs sind deaktiviert und der Bucket-Eigentümer besitzt automatisch jedes Objekt im Bucket und hat die volle Kontrolle darüber. ACLs haben keine Auswirkungen mehr auf Berechtigungen für Daten im S3-Bucket. Der Bucket verwendet Richtlinien, um die Zugriffssteuerung zu definieren.

Aktivierte ACLs

• Bucket-Eigentümer bevorzugt – Der Bucket-Eigentümer besitzt und hat die volle Kontrolle über neue Objekte, die andere Konten mit der bucket-owner-full-control-vordefinierten ACL.

• Objekt-Writer – Das AWS-Konto , das ein Objekt hochlädt, besitzt das Objekt, hat die volle Kontrolle darüber und kann anderen Benutzern über ACLs Zugriff darauf gewähren.

Für die meisten modernen Anwendungsfälle in S3 empfehlen wir Ihnen, ACLs deaktiviert zu lassen, indem Sie die Einstellung „Bucket-Eigentümer erzwungen“ übernehmen und Ihre Bucket-Richtlinie verwenden, um bei Bedarf Daten mit Benutzern außerhalb Ihres Kontos zu teilen. Dieser Ansatz vereinfacht die Berechtigungsverwaltung. Sie können ACLs sowohl für neu erstellte als auch für bereits vorhandene Buckets deaktivieren. Für neu erstellte Buckets sind ACLs standardmäßig deaktiviert. Im Falle eines vorhandenen Buckets, der bereits Objekte enthält, sind die Objekt- und Bucket-ACLs nach dem Deaktivieren von ACLs nicht mehr Teil einer Zugriffsauswertung, und der Zugriff wird auf der Grundlage von Richtlinien gewährt oder verweigert. Für vorhandene Buckets können Sie ACLs jederzeit wieder aktivieren, nachdem Sie sie deaktiviert haben, und Ihre bereits vorhandenen Bucket- und Objekt-ACLs werden wiederhergestellt.

Bevor Sie ACLs deaktivieren, empfehlen wir Ihnen, Ihre Bucket-Richtlinie zu überprüfen, um sicherzustellen, dass sie alle Möglichkeiten abdeckt, wie Sie außerhalb Ihres Kontos Zugriff auf Ihren Bucket gewähren möchten. Nachdem Sie ACLs deaktiviert haben, akzeptiert Ihr Bucket nur PUT-Anforderungen, die keine ACL angeben, oder PUT-Anforderungen mit ACLs für den Bucket-Eigentümer mit voller Kontrolle, wie z. B. die vordefinierte bucket-owner-full-control-ACL oder gleichwertige Formen dieser ACL in XML ausgedrückt. Vorhandene Anwendungen, die ACLs mit voller Kontrolle des Bucket-Eigentümers unterstützen, haben keine Auswirkungen. -PUTAnforderungen, die andere ACLs enthalten (z. B. benutzerdefinierte Erteilungen für bestimmte AWS-Konten), schlagen fehl und geben einen 400 Fehler mit dem Fehlercode zurückAccessControlListNotSupported.

Im Gegensatz dazu akzeptiert und berücksichtigt ein Bucket mit der Einstellung „Bevorzugter Bucket-Eigentümer“ weiterhin Bucket- und Objekt-ACLs. Mit dieser Einstellung gehören neue Objekte, die mit der von bucket-owner-full-control vordefinierten ACL geschrieben werden, automatisch dem Bucket-Eigentümer und nicht dem Objekt-Writer. Alle anderen ACL-Verhaltensweisen bleiben bestehen. Damit alle PUT-Vorgänge von Amazon S3 die vordefinierte bucket-owner-full-control-ACL enthalten müssen, können Sie eine Bucket-Richtlinie hinzufügen, die nur Objekt-Uploads mit dieser ACL zulässt.

Wenn Sie feststellen möchten, welche Einstellungen für die Objekteigentümerschaft auf Ihre Buckets angewendet werden, können Sie die Metriken von Amazon S3 Storage Lens verwenden. S3 Storage Lens ist eine Cloud-Speicheranalysefunktion, mit der Sie unternehmensweite Einblicke in die Nutzung und Aktivität von Objektspeichern erhalten können. Weitere Informationen finden Sie unter Verwenden von S3 Storage Lens, um Einstellungen für die Objekteigentümerschaft zu finden.

Anmerkung

Weitere Informationen zur Verwendung der Speicherklasse Amazon S3 Express One Zone mit Verzeichnis-Buckets finden Sie unter Was ist S3 Express One Zone? und Verzeichnis-Buckets.

Einstellungen für Object Ownership

Diese Tabelle zeigt die Auswirkungen, die jede Einstellung für Object Ownership auf ACLs, Objekte, Objekteigentümer und Objekt-Uploads hat.

Einstellung	Gilt für	Auswirkung auf Object Ownership	Auswirkungen auf ACLs	Hochladen akzeptiert
„Bucket-Eigentümer erzwungen“ (Standard)	Alle neuen und bestehenden Objekte	Bucket-Eigentümer besitzt jedes Objekt.	ACLs sind deaktiviert und wirken sich nicht mehr auf die Zugriffsberechtigungen für Ihren Bucket aus. Anfragen zum Festlegen oder Aktualisieren von ACLs schlagen fehl. Anfragen zum Lesen von ACLs werden jedoch unterstützt. Bucket-Eigentümer hat das volle Eigentum und die volle Kontrolle. Der Objekt-Writer hat nicht mehr das volle Eigentum und die volle Kontrolle.	Uploads mit ACLs mit vollem Zugriff des Bucket-Eigentümers oder Uploads, die keine ACL angeben
Bucket-Eigentümer bevorzugt	Neue Objekte	Wenn ein Objekt-Upload die bucket-owner-full-control vordefinierte ACL beeinhaltet, gehört dem Bucket Eigentümer das Objekt. Objekte, die mit anderen ACLs hochgeladen wurden, gehören dem Schreibkonto.	ACLs können aktualisiert werden und können Berechtigungen erteilen. Wenn ein Objekt-Upload die bucket-owner-full-control vordefinierte ACL enthält, hat der Bucket-Eigentümer Vollzugriff und der Objekt-Writer hat keinen Vollzugriff mehr.	Alle Uploads
Objektschreiber	Neue Objekte	Der Objekt-Writer besitzt das Objekt.	ACLs können aktualisiert werden und können Berechtigungen erteilen. Der Objekt-Writer hat vollen Kontrollzugriff.	Alle Uploads

Änderungen, die durch Deaktivieren von ACLs eingeführt wurden

Wenn die Einstellung „Bucket-Eigentümer erzwungen“ für die Objekteigentümerschaft angewendet wird, werden ACLs deaktiviert und Sie besitzen und übernehmen automatisch die volle Kontrolle über jedes Objekt im Bucket, ohne zusätzliche Aktionen auszuführen. „Bucket-Eigentümer erzwungen“ ist die Standardeinstellung für alle neu erstellten Buckets. Nachdem die Einstellung „Bucket-Eigentümer erzwungen“ angewendet wurde, sehen Sie drei Änderungen:

• Alle Bucket-ACLs und Objekt-ACLs sind deaktiviert, was Ihnen als Bucket-Eigentümer vollen Zugriff gewährt. Wenn Sie eine Lese-ACL-Anfrage für Ihren Bucket oder Objekt ausführen, werden Sie feststellen, dass nur dem Bucket-Eigentümer voller Zugriff gewährt wird.

• Sie als Bucket-Eigentümer besitzen automatisch jedes Objekt in Ihrem Bucket und haben die volle Kontrolle darüber.

• ACLs wirken sich nicht mehr auf die Zugriffsberechtigungen für Ihren Bucket aus. Daher basiert die Zugriffssteuerung für Ihre Daten auf Richtlinien wie IAM-Richtlinien, S3-Bucket-Richtlinien, VPC-Endpunktrichtlinien und SCPs von Organisationen.

Wenn Sie S3-Versioning verwenden, besitzt der Bucket-Eigentümer alle Objektversionen in Ihrem Bucket und hat die volle Kontrolle über sie. Durch das Anwenden der Einstellung „Bucket-Eigentümer erzwungen“ wird keine neue Version eines Objekts hinzugefügt.

Neue Objekte können nur dann in Ihren Bucket hochgeladen werden, wenn sie Vollzugriffs-ACLs des Bucket-Eigentümers verwenden oder keine ACL angeben. Objekt-Uploads schlagen fehl, wenn sie eine andere ACL angeben. Weitere Informationen finden Sie unter Fehlerbehebung.

Da die folgende PutObject-Beispieloperation mit AWS Command Line Interface (AWS CLI) die bucket-owner-full-control vordefinierte ACL enthält, kann das Objekt in einen Bucket mit deaktivierten ACLs hochgeladen werden.

aws s3api put-object --bucket DOC-EXAMPLE-BUCKET --key key-name --body path-to-file --acl bucket-owner-full-control

Da der folgende PutObject-Vorgang keine ACL angibt, ist er auch für einen Bucket mit deaktivierten ACLs erfolgreich.

aws s3api put-object --bucket DOC-EXAMPLE-BUCKET --key key-name --body path-to-file

Anmerkung

Wenn andere nach dem Hochladen Zugriff auf Objekte AWS-Konten benötigen, müssen Sie diesen Konten über Bucket-Richtlinien zusätzliche Berechtigungen erteilen. Weitere Informationen finden Sie unter Beispiel-Walkthroughs: Verwalten des Zugriffs auf Ihre Amazon-S3-Ressourcen.

ACLs erneut aktivieren

Sie können ACLs jederzeit wieder aktivieren, indem Sie von der Einstellung „Bucket-Eigentümer erzwungen“ zu einer anderen Einstellung für die Objekteigentümerschaft wechseln. Wenn Sie Objekt-ACLs für die Berechtigungsverwaltung verwendet haben, bevor Sie die Einstellung „Bucket-Eigentümer erzwungen“ angewendet haben und Sie diese Objekt-ACL-Berechtigungen nicht zu Ihrer Bucket-Richtlinie migriert haben, werden diese Berechtigungen nach dem erneuten Aktivieren von ACLs wiederhergestellt. Darüber hinaus gehören Objekte, die in den Bucket geschrieben wurden, während die „Einstellung „Bucket-Eigentümer erzwungen“ angewendet wurde, weiterhin dem Bucket-Eigentümer.

Wenn Sie beispielsweise von der Einstellung „Bucket-Eigentümer erzwungen“ zurück zur Einstellung „Objektschreiber“ wechseln, besitzen Sie als Bucket-Eigentümer nicht mehr die volle Kontrolle über Objekte, die zuvor anderen AWS-Konten gehörten. Stattdessen besitzen die Upload-Konten diese Objekte erneut. Objekte, die anderen Konten gehören, verwenden ACLs für Berechtigungen, sodass Sie keine Richtlinien verwenden können, um diesen Objekten Berechtigungen zu erteilen. Sie als Bucket-Eigentümer besitzen jedoch weiterhin alle Objekte, die in den Bucket geschrieben wurden, während die Einstellung „Bucket-Eigentümer erzwungen“ angewendet wurde. Diese Objekte gehören nicht im Besitz des Objektschreibers, auch wenn Sie ACLs erneut aktivieren.

Anweisungen zum Aktivieren und Verwalten von ACLs mithilfe der AWS Management Console, AWS Command Line Interface (CLI), REST-API oder AWS SDKs finden Sie unter Konfigurieren von ACLs.

Voraussetzungen für die Deaktivierung von ACLs

Stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind, bevor Sie ACLs für einen vorhandenen Bucket deaktivieren.

Überprüfen Sie Bucket- und Objekt-ACLs und migrieren Sie ACL-Berechtigungen

Wenn Sie ACLs deaktivieren, wirken sich die von Bucket- und Objekt-ACLs gewährten Berechtigungen nicht mehr auf den Zugriff aus. Bevor Sie ACLs deaktivieren, überprüfen Sie Ihre Bucket- und Objekt-ACLs.

Wenn Ihre Bucket-ACLs anderen Benutzern außerhalb Ihres Kontos Lese- oder Schreibberechtigungen erteilen, müssen Sie diese Berechtigungen zu Ihrer Bucket-Richtlinie migrieren, bevor Sie die Einstellung „Bucket-Eigentümer erzwungen“ anwenden können. Wenn Sie keine Bucket-ACLs migrieren, die Lese- oder Schreibzugriff außerhalb Ihres Kontos gewähren, schlägt Ihre Anfrage zum Anwenden der Einstellung „Bucket-Eigentümer erzwungen“ fehl und gibt den Fehlercode InvalidBucketAclWithObjectOwnership zurück.

Wenn Sie beispielsweise ACLs für einen Bucket deaktivieren möchten, der Serverzugriffsprotokolle empfängt, müssen Sie die Bucket-ACL-Berechtigungen für die S3-Protokollbereitstellungsgruppe zum Protokollierungsserviceprinzipal in einer Bucket-Richtlinie migrieren. Weitere Informationen finden Sie unter Gewähren von Zugriff auf die S3-Protokollbereitstellungsgruppe für die Protokollierung des Serverzugriffs.

Wenn Sie möchten, dass der Objektschreiber die volle Kontrolle über das hochgeladene Objekt behält, ist der Objektschreiber die beste Einstellung für die Objekteigentümerschaft in Ihrem Anwendungsfall. Wenn Sie den Zugriff auf der Ebene einzelner Objekte steuern möchten, ist Bucket-Eigentümer bevorzugt die beste Wahl. Diese Anwendungsfälle sind ungewöhnlich.

Informationen zum Überprüfen von ACLs und zum Migrieren von ACL-Berechtigungen auf Bucket-Richtlinien finden Sie unter Voraussetzungen für die Deaktivierung von ACLs.

Identifizieren von Anforderungen, für die eine ACL zur Autorisierung erforderlich war

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. Wenn für die Anforderung eine ACL zur Autorisierung erforderlich war oder wenn Sie PUT-Anfragen haben, die eine ACL angeben, lautet die Zeichenfolge Yes. Wenn keine ACLs erforderlich waren oder wenn Sie eine bucket-owner-full-control vordefinierte ACL festlegen oder wenn die Anforderungen von Ihrer Bucket-Richtlinie zugelassen werden, lautet die aclRequired Wertzeichenfolge in den Amazon S3-Serverzugriffsprotokollen „-“ und in fehlt sie CloudTrail. Weitere Informationen zu den erwarteten Werten für aclRequired finden Sie unter aclRequired-Werte für allgemeine Amazon-S3-Anfragen.

Wenn Sie PutBucketAcl- oder PutObjectAcl-Anfragen mit Headern haben, die ACL-basierte Berechtigungen gewähren, mit Ausnahme der vordefinierten bucket-owner-full-control-ACL, müssen Sie diese Header entfernen, bevor Sie ACLs deaktivieren können. Andernfalls schlagen Ihre Anfragen fehl.

Für alle anderen Anfragen, für die eine ACL zur Autorisierung erforderlich war, migrieren Sie diese ACL-Berechtigungen zu Bucket-Richtlinien. Entfernen Sie dann alle Bucket-ACLs, bevor Sie die Einstellung „Bucket-Eigentümer erzwungen“ aktivieren.

Anmerkung

Entfernen Sie keine Objekt-ACLs. Andernfalls verlieren Anwendungen, die bezüglich Berechtigungen auf Objekt-ACLs angewiesen sind, den Zugriff.

Wenn Sie feststellen, dass für keine Anfrage eine ACL für die Autorisierung erforderlich ist, können Sie mit der Deaktivierung der ACLs fortfahren. Weitere Informationen zur Identifizierung von Anfragen finden Sie unter Verwenden von Amazon-S3-Serverzugriffsprotokollen zur Identifizierung von Anforderungen und Identifizieren von Amazon S3-Anforderungen mit CloudTrail.

Überprüfen und aktualisieren Sie Bucket-Richtlinien, die ACL-bezogene Bedingungsschlüssel verwenden

Nachdem Sie die Einstellung „Bucket-Eigentümer erzwungen“ zum Deaktivieren von ACLs angewendet haben, können neue Objekte nur dann in Ihren Bucket hochgeladen werden, wenn die Anforderung Vollzugriffs-ACLs des Bucket-Eigentümers verwendet oder keine ACL angibt. Bevor Sie ACLs deaktivieren, überprüfen Sie Ihre Bucket-Richtlinie auf ACL-bezogene Bedingungsschlüssel.

Wenn Ihre Bucket-Richtlinie einen ACL-bezogenen Bedingungsschlüssel verwendet, um die bucket-owner-full-control vordefinierte ACL (z. B. s3:x-amz-acl) anzufordern, müssen Sie Ihre Bucket-Richtlinie nicht aktualisieren. Die folgende Bucket-Richtlinie verwendet das s3:x-amz-acl, um die vordefinierte bucket-owner-full-control-ACL für S3-PutObject-Anforderungen anzufordern. Diese Richtlinie erfordert immer noch, dass der Objekt-Writer die vordefinierte bucket-owner-full-control-ACL angibt. Buckets mit deaktivierten ACLs akzeptieren diese ACL jedoch weiterhin, sodass Anfragen weiterhin erfolgreich sind, ohne dass clientseitige Änderungen erforderlich sind.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Only allow writes to my bucket with bucket owner full control",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/ExampleUser"
                ]
            },
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

Wenn Ihre Bucket-Richtlinie jedoch einen Zustandsschlüssel im Zusammenhang mit ACL verwendet, der eine andere Zugriffssteuerungsliste erfordert, müssen Sie diesen Bedingungsschlüssel entfernen. Diese Beispiel-Bucket-Richtlinie erfordert die public-read-ACL für PutObject-S3-Anforderungen und muss daher vor dem Deaktivieren von ACLs aktualisiert werden.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Only allow writes to my bucket with public read access",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/ExampleUser"                ]
            },
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "public-read"
                }
            }
        }
    ]
}

Berechtigungen für Object Ownership

Um eine Einstellung für Object Ownership für einen Bucket anzuwenden, zu aktualisieren oder zu löschen, benötigen Sie die s3:PutBucketOwnershipControls-Berechtigung. Um die Object-Ownership-Einstellung für einen Bucket zurückzugeben, benötigen Sie die s3:GetBucketOwnershipControls-Berechtigung. Weitere Informationen finden Sie unter Festlegen von Object Ownership beim Erstellen eines Buckets und Anzeigen der Einstellung Object Ownership für einen S3-Bucket.

Deaktivieren von ACLs für alle neuen Buckets

Standardmäßig werden alle neuen Buckets mit der Einstellung „Bucket-Eigentümer erzwungen“ erstellt und ACLs sind deaktiviert. Wir empfehlen, ACLs deaktiviert zu lassen. Als allgemeine Regel sollten Sie S3-ressourcenbasierte Richtlinien (Bucket-Richtlinien und Zugriffspunkt-Richtlinien) oder IAM-Richtlinien für die Zugriffssteuerung anstelle von ACLs verwenden. Richtlinien stellen eine vereinfachte und flexiblere Zugriffskontrolloption dar. Mit Bucket- und Zugriffspunktrichtlinien können Sie Regeln definieren, die allgemein für alle Anfragen an Ihre Amazon-S3-Ressourcen gelten.

Replikation und Object Ownership

Wenn Sie die S3-Replikation verwenden und die Quell- und Ziel-Buckets verschiedenen gehören AWS-Konten, können Sie ACLs deaktivieren (mit der Einstellung „Bucket-Eigentümer erzwungen“ für Object Ownership), um die Replikateigentümerschaft in den zu ändern AWS-Konto , der den Ziel-Bucket besitzt. Diese Einstellung ahmt das Verhalten der bestehenden Besitzerüberschreibung nach, ohne dass eine s3:ObjectOwnerOverrideToBucketOwner-Berechtigung erforderlich ist. Alle Objekte, die mit der Einstellung „Bucket-Eigentümer erzwungen“ in den Ziel-Bucket repliziert werden, gehören dem Eigentümer des Ziel-Buckets. Weitere Informationen zur Besitzerüberschreibungsoption für Replikationskonfigurationen finden Sie unter Ändern des Replikat-Eigentümers.

Einstellung von Object Ownership

Sie können eine Object-Ownership-Einstellung mithilfe der Amazon S3-Konsole, AWS CLI, AWS SDKs, Amazon S3-REST-API oder anwenden AWS CloudFormation. Die folgenden REST-API- und - AWS CLI Befehle unterstützen Object Ownership:

REST-API	AWS CLI	Beschreibung
PutBucketOwnershipControls	put-bucket-ownership-controls	Erstellt oder ändert die Einstellung Object Ownership für einen vorhandenen S3-Bucket.
CreateBucket	create-bucket	Erstellt einen Bucket mit dem x-amz-object-ownership-Anforderungsheader zur Angabe der Einstellung für Object Ownership.
GetBucketOwnershipControls	get-bucket-ownership-controls	Ruft die Einstellung Object Ownership für einen Amazon-S3-Bucket ab.
DeleteBucketOwnershipControls	delete-bucket-ownership-controls	Löscht die Einstellung für Object Ownership für einen Amazon-S3-Bucket.

Weitere Informationen zum Anwenden und Arbeiten mit Object Ownership-Einstellungen finden Sie in den folgenden Themen.

Themen

• Voraussetzungen für die Deaktivierung von ACLs
• Festlegen von Object Ownership beim Erstellen eines Buckets
• Einstellung für Object Ownership für einen vorhandenen Bucket
• Anzeigen der Einstellung Object Ownership für einen S3-Bucket
• Deaktivieren von ACLs für alle neuen Buckets und Durchsetzung von Object Ownership
• Fehlerbehebung