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.
Kontrolle des Besitzes von Objekten und Deaktivierung ACLs für Ihren Bucket
S3 Object Ownership ist eine Einstellung auf Amazon S3 S3-Bucket-Ebene, mit der Sie den Besitz von Objekten kontrollieren können, die in Ihren Bucket hochgeladen wurden, und um Zugriffskontrolllisten zu deaktivieren oder zu aktivieren () ACLs. Standardmäßig ist für Object Ownership die erzwungene Einstellung Bucket Owner festgelegt, und alle sind ACLs deaktiviert. Wenn ACLs diese Option deaktiviert ist, besitzt der Bucket-Besitzer alle Objekte im Bucket und verwaltet den Zugriff auf Daten ausschließlich mithilfe von Zugriffsverwaltungsrichtlinien.
In den meisten modernen Anwendungsfällen in Amazon S3 ist die Verwendung von nicht mehr erforderlichACLs, und wir empfehlen, diese ACLs Option weiterhin zu deaktivieren, außer in ungewöhnlichen Fällen, in denen Sie den Zugriff für jedes Objekt einzeln kontrollieren müssen. Wenn diese ACLs Option deaktiviert ist, können Sie Richtlinien verwenden, um den Zugriff auf jedes Objekt in Ihrem Bucket einfacher zu kontrollieren, unabhängig davon, wer die Objekte in Ihren Bucket hochgeladen hat.
Object Ownership verfügt über drei Einstellungen, mit denen Sie die Inhaberschaft der in Ihren Bucket hochgeladenen Objekte kontrollieren und deaktivieren oder aktivieren könnenACLs:
ACLsdeaktiviert
-
Bucket-Besitzer erzwungen (Standard) — ACLs sind deaktiviert, und der Bucket-Besitzer besitzt automatisch jedes Objekt im Bucket und hat die volle Kontrolle darüber. ACLswirkt sich nicht mehr auf die Berechtigungen für Daten im S3-Bucket aus. Der Bucket verwendet Richtlinien, um die Zugriffssteuerung zu definieren.
ACLsaktiviert
-
Bevorzugter Bucket-Besitzer — Der Bucket-Besitzer besitzt und hat die volle Kontrolle über neue Objekte, die andere Accounts in den Bucket mit den gespeicherten Objekten
bucket-owner-full-control
schreibenACL. -
Objekt-Writer — AWS-Konto Derjenige, der ein Objekt hochlädt, besitzt das Objekt, hat die volle Kontrolle darüber und kann anderen Benutzern Zugriff darauf gewähren. ACLs
Für die meisten modernen Anwendungsfälle in S3 empfehlen wir, die ACLs Deaktivierung beizubehalten, indem Sie die Einstellung Bucket Owner erforced anwenden und Ihre Bucket-Richtlinie verwenden, um Daten nach Bedarf mit Benutzern außerhalb Ihres Kontos zu teilen. Dieser Ansatz vereinfacht die Berechtigungsverwaltung. Sie können die Option sowohl für neu erstellte als auch für bereits bestehende Buckets deaktivierenACLs. Bei neu erstellten Buckets ACLs sind diese standardmäßig deaktiviert. Bei einem vorhandenen Bucket, der bereits Objekte enthält, ACLs sind das Objekt und der Bucket nach der Deaktivierung ACLs nicht mehr Teil einer Zugriffsevaluierung, und der Zugriff wird auf der Grundlage von Richtlinien gewährt oder verweigert. Bestehende Buckets können Sie ACLs jederzeit wieder aktivieren, nachdem Sie sie deaktiviert haben. Ihr bereits vorhandener Bucket und Ihr Objekt ACLs werden wiederhergestellt.
Wir empfehlen IhnenACLs, vor der Deaktivierung Ihre Bucket-Richtlinie zu überprüfen, um sicherzustellen, dass sie alle Möglichkeiten abdeckt, mit denen Sie außerhalb Ihres Kontos Zugriff auf Ihren Bucket gewähren möchten. Nach der Deaktivierung ACLs akzeptiert Ihr Bucket nur PUT
Anfragen, die kein ACL oder PUT
Anfragen angeben, bei denen der Bucket-Besitzer die volle Kontrolle hatACLs, z. B. bucket-owner-full-control
vorgefertigte ACL oder gleichwertige Formen davon, ACL ausgedrückt inXML. Bestehende Anwendungen, die die Vollzugriff ACLs des Bucket-Besitzers unterstützen, haben keine Auswirkungen. PUT
Anfragen, die andere ACLs (z. B. benutzerdefinierte Zuschüsse für bestimmte AWS-Konten) enthalten, schlagen fehl und geben einen 400
Fehler mit dem Fehlercode zurückAccessControlListNotSupported
.
Im Gegensatz dazu akzeptiert und berücksichtigt ein Bucket mit der bevorzugten Einstellung des Bucket-Besitzers weiterhin Bucket und ObjektACLs. Mit dieser Einstellung gehören neue Objekte, die mit der bucket-owner-full-control
gespeicherten Option geschrieben wurden, automatisch dem Bucket-Besitzer und nicht dem Object-Writer. ACL Alle anderen ACL Verhaltensweisen bleiben bestehen. Um zu verlangen, dass alle Amazon S3 PUT
S3-Operationen die gespeicherten bucket-owner-full-control
Daten enthaltenACL, können Sie eine Bucket-Richtlinie hinzufügen, die nur Objekt-Uploads mit dieser ACL Methode 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 Verzeichnis-Buckets und S3 Express One Zone und Übersicht über Verzeichnis-Buckets.
Einstellungen für Object Ownership
Diese Tabelle zeigt die Auswirkungen, die jede Einstellung „Objekteigentum“ auf ObjekteACLs, Objekteigentum und Objekt-Uploads hat.
Einstellung | Gilt für | Auswirkung auf Object Ownership | Auswirkung auf ACLs | Hochladen akzeptiert |
---|---|---|---|---|
„Bucket-Eigentümer erzwungen“ (Standard) | Alle neuen und bestehenden Objekte | Bucket-Eigentümer besitzt jedes Objekt. |
ACLssind deaktiviert und wirken sich nicht mehr auf die Zugriffsberechtigungen für Ihren Bucket aus. Anfragen zum Einrichten oder Aktualisieren ACLs schlagen fehl. Leseanfragen 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, bei denen der Bucket-Besitzer die volle Kontrolle hat, ACLs oder Uploads, bei denen kein ACL |
Bucket-Eigentümer bevorzugt | Neue Objekte | Wenn bei einem Objekt-Upload auch das gespeicherte bucket-owner-full-control Objekt enthalten istACL, gehört das Objekt dem Bucket-Besitzer. Objekte, die zusammen mit anderen hochgeladen wurden, ACLs gehören dem Schreibkonto. |
ACLskann aktualisiert werden und kann Berechtigungen gewähren. Wenn ein Objekt-Upload die |
Alle Uploads |
Objektschreiber | Neue Objekte | Der Objekt-Writer besitzt das Objekt. |
ACLskann aktualisiert werden und kann Berechtigungen gewähren. Der Objekt-Writer hat vollen Kontrollzugriff. |
Alle Uploads |
Änderungen, die durch Deaktivierung eingeführt wurden ACLs
Wenn die vom Bucket-Besitzer erzwungene Einstellung für Objekteigentum angewendet wird, ACLs sind sie deaktiviert und Sie besitzen automatisch jedes Objekt im Bucket und übernehmen die volle Kontrolle über jedes Objekt im Bucket, ohne weitere Maßnahmen ergreifen zu müssen. „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 Buckets ACLs und Objekte ACLs sind deaktiviert, sodass Sie als Bucket-Besitzer vollen Zugriff haben. Wenn Sie eine ACL Leseanforderung für Ihren Bucket oder Ihr Objekt ausführen, werden Sie feststellen, dass nur der Bucket-Besitzer vollen Zugriff hat.
-
Sie als Bucket-Eigentümer besitzen automatisch jedes Objekt in Ihrem Bucket und haben die volle Kontrolle darüber.
-
ACLswirkt sich nicht mehr auf die Zugriffsberechtigungen für Ihren Bucket aus. Daher basiert die Zugriffskontrolle für Ihre Daten auf Richtlinien wie Richtlinien, IAM S3-Bucket-Richtlinien, VPC Endpunktrichtlinien und OrganizationsSCPs.
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 für sie die Vollzugriff des Bucket-Besitzers verwendet wird ACLs oder wenn kein Objekt angegeben istACL. Objekt-Uploads schlagen fehl, wenn sie ein anderes ACL angeben. Weitere Informationen finden Sie unter Fehlerbehebung.
Da die folgende PutObject
Beispieloperation mit der AWS Command Line Interface
(AWS CLI) die Funktion „Gespeichert“ bucket-owner-full-control
beinhaltetACL, kann das Objekt in einen Bucket mit deaktivierter Option ACLs hochgeladen werden.
aws s3api put-object --bucket
amzn-s3-demo-bucket
--keykey-name
--bodypath-to-file
--acl bucket-owner-full-control
Da die folgende PutObject
Operation keine spezifiziertACL, ist sie auch für einen Bucket mit deaktivierter Option ACLs erfolgreich.
aws s3api put-object --bucket
amzn-s3-demo-bucket
--keykey-name
--bodypath-to-file
Anmerkung
Wenn andere Benutzer nach dem Hochladen Zugriff auf Objekte AWS-Konten benötigen, müssen Sie diesen Konten über Bucket-Richtlinien zusätzliche Berechtigungen gewähren. Weitere Informationen finden Sie unter Exemplarische Vorgehensweisen, die Richtlinien verwenden, um den Zugriff auf Ihre Amazon S3 S3-Ressourcen zu verwalten.
Erneut aktivieren ACLs
Sie können die Aktivierung jederzeit wieder aktivieren, ACLs indem Sie von der Einstellung „Bucket-Besitzer erzwungen“ zu einer anderen Einstellung „Objektbesitz“ wechseln. Wenn Sie ein Objekt ACLs für die Rechteverwaltung verwendet haben, bevor Sie die Einstellung „Bucket-Besitzer erzwungen“ angewendet haben, und Sie diese ACL Objektberechtigungen nicht in Ihre Bucket-Richtlinie migriert haben, werden diese Berechtigungen nach der erneuten Aktivierung wiederhergestelltACLs. 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. Sie können also keine Richtlinien verwenden, um diesen Objekten Berechtigungen zu gewähren. 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 dem Object Writer, auch wenn Sie sie erneut aktivierenACLs.
Anweisungen zur Aktivierung und Verwaltung ACLs mithilfe von AWS Management Console, AWS Command Line Interface (CLI) REST API AWS SDKs, oder finden Sie unterKonfiguration ACLs.
Voraussetzungen für die Deaktivierung ACLs
Bevor Sie die Deaktivierung ACLs für einen vorhandenen Bucket durchführen, müssen Sie die folgenden Voraussetzungen erfüllen.
Überprüfen Sie den Bucket und das Objekt ACLs und migrieren Sie die ACL Berechtigungen
Wenn Sie die Option deaktivierenACLs, wirken sich die von Bucket und Objekt erteilten Berechtigungen nicht ACLs mehr auf den Zugriff aus. Überprüfen Sie vor der Deaktivierung ACLs Ihren Bucket und Ihr ObjektACLs.
Wenn Ihr Bucket anderen Benutzern außerhalb Ihres Kontos Lese- oder Schreibberechtigungen ACLs gewährt, müssen Sie diese Berechtigungen in Ihre Bucket-Richtlinie migrieren, bevor Sie die erzwungene Einstellung für den Bucket-Besitzer anwenden können. Wenn Sie BucketsACLs, die Lese- oder Schreibzugriff außerhalb Ihres Kontos gewähren, nicht migrieren, schlägt Ihre Anfrage zur Anwendung der erzwungenen Einstellung „Bucket-Besitzer“ fehl und gibt den InvalidBucketAclWithObjectOwnershipFehlercode.
Wenn Sie die Option beispielsweise ACLs für einen Bucket deaktivieren möchten, der Serverzugriffsprotokolle empfängt, müssen Sie die ACL Bucket-Berechtigungen für die S3-Protokollbereitstellungsgruppe in einer Bucket-Richtlinie auf den Logging-Serviceprinzipal 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 ACLs und Migrieren von ACL Berechtigungen zu Bucket-Richtlinien finden Sie unterVoraussetzungen für die Deaktivierung ACLs.
Identifizieren Sie Anfragen, ACL für die eine Autorisierung erforderlich war
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. Wenn ACL für die Anfrage eine Autorisierung erforderlich war oder wenn Sie PUT
Anfragen haben, die eine angebenACL, lautet die ZeichenfolgeYes
. Wenn keine erforderlich ACLs waren oder wenn Sie einen bucket-owner-full-control
gespeicherten Wert festlegen oder wenn die Anfragen gemäß Ihrer Bucket-Richtlinie zulässig sind, lautet die aclRequired
Wertzeichenfolge in den Amazon S3 S3-Serverzugriffsprotokollen -
"" und fehlt in CloudTrail. ACL Weitere Informationen zu den erwarteten Werten für aclRequired
finden Sie unter aclRequired-Werte für allgemeine Amazon-S3-Anfragen.
Wenn Sie PutObjectAcl
Anfragen mit Headern habenPutBucketAcl
, die bestimmte ACL Berechtigungen gewähren, mit Ausnahme der bucket-owner-full-control
gespeichertenACL, müssen Sie diese Header entfernen, bevor Sie sie deaktivieren können. ACLs Andernfalls schlagen Ihre Anfragen fehl.
Für alle anderen Anfragen, ACL für die eine Autorisierung erforderlich ist, migrieren Sie diese ACL Berechtigungen in die Bucket-Richtlinien. Entfernen Sie anschließend alle Buckets, ACLs bevor Sie die Einstellung „Bucket Owner erforced“ aktivieren.
Anmerkung
Objekt ACLs nicht entfernen. Andernfalls verlieren Anwendungen, die ACLs für Berechtigungen auf Objekte angewiesen sind, den Zugriff.
Wenn Sie feststellen, dass keine Anfragen ACL zur Autorisierung erforderlich sind, können Sie mit der Deaktivierung fortfahrenACLs. Weitere Informationen zur Identifizierung von Anfragen finden Sie unter Verwenden von Amazon-S3-Serverzugriffsprotokollen zur Identifizierung von Anforderungen und Identifizieren von Amazon S3 S3-Anfragen mithilfe von CloudTrail.
Überprüfen und aktualisieren Sie Bucket-Richtlinien, die verwandte ACL Bedingungsschlüssel verwenden
Nachdem Sie die Einstellung Bucket Owner erforced auf Deaktivierung angewendet habenACLs, können neue Objekte nur dann in Ihren Bucket hochgeladen werden, wenn für die Anfrage die Vollzugriff auf den Bucket Owner verwendet wird ACLs oder wenn kein Bucket Owner angegeben istACL. Überprüfen Sie vor der Deaktivierung ACLs Ihre Bucket-Richtlinie auf zugehörige ACL Bedingungsschlüssel.
Wenn in Ihrer Bucket-Richtlinie ein ACL verwandter Bedingungsschlüssel verwendet wird, bucket-owner-full-control
der ACL vordefinierte Daten verlangt (z. B.s3:x-amz-acl
), müssen Sie Ihre Bucket-Richtlinie nicht aktualisieren. Die folgende Bucket-Richtlinie verwendet dies3:x-amz-acl
, um zu verlangen, dass bucket-owner-full-control
die PutObject
Anfragen ACL für S3 gesperrt werden. Diese Richtlinie verlangt immer noch, dass der Object Writer die gespeicherten Daten bucket-owner-full-control
spezifiziertACL. ACLsDeaktivierte Buckets akzeptieren dies jedoch weiterhinACL, 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:::amzn-s3-demo-bucket
/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } ] }
Wenn Ihre Bucket-Richtlinie jedoch einen verwandten ACL Bedingungsschlüssel verwendet, der einen anderen erfordertACL, müssen Sie diesen Bedingungsschlüssel entfernen. Diese Beispiel-Bucket-Richtlinie erfordert die public-read
ACL für PutObject
S3-Anfragen und muss daher vor der Deaktivierung 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:::amzn-s3-demo-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 erhalten Sie unter Festlegen von Object Ownership beim Erstellen eines Buckets und Anzeigen der Einstellung Object Ownership für einen S3-Bucket.
Deaktivierung ACLs für alle neuen Buckets
Standardmäßig werden alle neuen Buckets mit der Einstellung Bucket Owner erforced erstellt und sind deaktiviert. ACLs Wir empfehlen, diese Option weiterhin deaktiviert zu lassen. ACLs In der Regel empfehlen wir, stattdessen ressourcenbasierte S3-Richtlinien (Bucket-Richtlinien und Zugriffspunktrichtlinien) oder IAM Richtlinien für die Zugriffskontrolle zu verwenden. ACLs 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 unterschiedlichen Besitzern gehören AWS-Konten, können Sie deaktivieren ACLs (wobei die Einstellung Bucket-Besitzer für Objekteigentümer erzwungen wird), um den Besitz des Replikats auf den AWS-Konto Besitzer des Ziel-Buckets zu ändern. 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 Einstellung für Objektbesitz mithilfe der Amazon S3-Konsole, AWS CLI, AWS SDKs, Amazon S3 REST API oder anwenden AWS CloudFormation. Die folgenden AWS CLI Befehle REST API und 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 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
- Deaktivierung ACLs für alle neuen Buckets und Durchsetzung des Objektbesitzes
- Fehlerbehebung