Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôle de la propriété des objets et désactivation ACLs pour votre compartiment

La propriété des objets S3 est un paramètre au niveau du compartiment Amazon S3 que vous pouvez utiliser pour contrôler la propriété des objets chargés dans votre compartiment et pour désactiver ou activer les listes de contrôle d'accès () ACLs. Par défaut, Object Ownership est défini sur le paramètre imposé par le propriétaire du bucket et tous ACLs sont désactivés. Lorsqu'elles ACLs sont désactivées, le propriétaire du compartiment possède tous les objets du compartiment et gère l'accès aux données exclusivement à l'aide de politiques de gestion des accès.

La majorité des cas d'utilisation modernes d'Amazon S3 ne nécessitent plus l'utilisation deACLs, et nous vous recommandons de le ACLs désactiver, sauf dans des circonstances exceptionnelles où vous devez contrôler l'accès à chaque objet individuellement. Lorsque cette ACLs option est désactivée, vous pouvez utiliser des politiques pour contrôler plus facilement l'accès à chaque objet de votre compartiment, quelle que soit la personne qui a chargé les objets dans votre compartiment.

La propriété des objets comporte trois paramètres que vous pouvez utiliser pour contrôler la propriété des objets chargés dans votre bucket et pour désactiver ou activer ACLs :

Pour la majorité des cas d'utilisation modernes de S3, nous vous recommandons de conserver la ACLs désactivation en appliquant le paramètre d'application obligatoire du propriétaire du compartiment et en utilisant votre politique de compartiment pour partager des données avec des utilisateurs extérieurs à votre compte selon les besoins. Cette approche simplifie la gestion des autorisations. Vous pouvez ACLs le désactiver à la fois sur les buckets nouvellement créés et sur les buckets déjà existants. Pour les buckets nouvellement créés, ACLs ils sont désactivés par défaut. Dans le cas d'un compartiment existant qui contient déjà des objets, une fois que vous l'avez désactivéACLs, l'objet et le compartiment ne ACLs font plus partie d'une évaluation de l'accès, et l'accès est accordé ou refusé sur la base de politiques. Pour les buckets existants, vous pouvez les réactiver ACLs à tout moment après les avoir désactivés, et votre bucket et votre objet ACLs préexistants seront restaurés.

Avant de procéder à la désactivationACLs, nous vous recommandons de consulter votre politique relative aux compartiments afin de vous assurer qu'elle couvre toutes les manières dont vous avez l'intention d'accorder l'accès à votre compartiment en dehors de votre compte. Après la désactivationACLs, votre compartiment accepte uniquement les PUT demandes qui ne spécifient pas un ACL ou des PUT demandes avec le contrôle ACLs total du propriétaire du compartiment, par exemple bucket-owner-full-control les formes prédéfinies ACL ou équivalentes ACL exprimées enXML. Les applications existantes qui prennent en charge le contrôle total du propriétaire du ACLs bucket n'ont aucun impact. PUTles demandes qui en contiennent d'autres ACLs (par exemple, des autorisations personnalisées accordées à certains Comptes AWS) échouent et renvoient une 400 erreur avec le code d'erreurAccessControlListNotSupported.

En revanche, un bucket avec le paramètre préféré du propriétaire du bucket continue d'accepter et de respecter le bucket et l'objetACLs. Avec ce paramètre, les nouveaux objets écrits avec le code prédéfini bucket-owner-full-control ACL sont automatiquement détenus par le propriétaire du compartiment plutôt que par le rédacteur de l'objet. Tous les autres ACL comportements restent en place. Pour exiger que toutes les PUT opérations Amazon S3 incluent le scanACL, bucket-owner-full-control vous pouvez ajouter une politique de compartiment qui autorise uniquement le téléchargement d'objets à l'aide de ce ACL paramètre.

Pour voir quels paramètres de propriété d'objets sont appliqués à vos compartiments, vous pouvez utiliser les métriques Amazon S3 Storage Lens. S3 Storage Lens est une fonction d'analyse du stockage dans le cloud que vous pouvez utiliser pour obtenir une visibilité à l'échelle de l'organisation sur l'utilisation et l'activité du stockage d'objets. Pour plus d'informations, consultez Using S3 Storage Lens to find Object Ownership settings (Utilisation de S3 Storage Lens pour trouver les paramètres de propriété des objets).

Paramètres de la propriété de l'objet

Ce tableau montre l'impact de chaque paramètre de propriété des objets sur les objetsACLs, la propriété des objets et les téléchargements d'objets.

Modifications apportées par la désactivation ACLs

Lorsque le paramètre imposé par le propriétaire du compartiment pour la propriété des objets est appliqué, ACLs il est désactivé et vous possédez automatiquement tous les objets du compartiment et vous en prenez le contrôle total sans effectuer d'actions supplémentaires. Propriétaire du compartiment appliqué est le paramètre par défaut pour tous les compartiments nouvellement créés. Après l'application du paramètre Propriétaire du compartiment appliqué, trois changements sont notables :

Si vous utilisez la gestion des versions S3, le propriétaire du compartiment possède et contrôle total sur toutes les versions d'objets de votre compartiment. L'application du paramètre Propriétaire du compartiment appliqué n'ajoute pas de nouvelle version d'un objet.

Les nouveaux objets ne peuvent être chargés dans votre bucket que s'ils utilisent le contrôle total du propriétaire du bucket ACLs ou s'ils ne spécifient pas deACL. Les chargements d'objets échouent s'ils en spécifient un autreACL. Pour de plus amples informations, veuillez consulter Résolution des problèmes.

Étant donné que l'exemple d'PutObjectopération suivant utilisant le AWS Command Line Interface (AWS CLI) inclut le bucket-owner-full-control scanACL, l'objet peut être chargé dans un bucket lorsque cette option est désactivéeACLs.

aws s3api put-object --bucket amzn-s3-demo-bucket --key key-name --body path-to-file --acl bucket-owner-full-control

Comme l'PutObjectopération suivante ne spécifie pas de ACL paramètre, elle aboutit également pour un bucket désactivéACLs.

aws s3api put-object --bucket amzn-s3-demo-bucket --key key-name --body path-to-file

Réactivation ACLs

Vous pouvez le réactiver ACLs en passant du paramètre imposé au propriétaire du compartiment à un autre paramètre de propriété de l'objet à tout moment. Si vous avez utilisé un objet ACLs pour la gestion des autorisations avant d'appliquer le paramètre imposé au propriétaire du compartiment et que vous n'avez pas fait migrer ces ACL autorisations d'objet vers votre politique de compartiment, une fois réactivéesACLs, ces autorisations sont restaurées. De plus, les objets écrits dans le compartiment pendant que le paramètre Propriétaire du compartiment appliqué était appliqué appartiennent toujours au propriétaire du compartiment.

Par exemple, si du paramètre Propriétaire du compartiment appliqué vous revenez au paramètre Créateur d'objets, en tant que propriétaire du compartiment, vous ne possédez plus les objets qui appartenaient auparavant à d'autres Comptes AWS, et n'en avez plus le contrôle total. Au lieu de cela, les comptes de chargement sont à nouveau propriétaires de ces objets. Les objets appartenant à d'autres comptes utilisent ACLs des autorisations. Vous ne pouvez donc pas utiliser de politiques pour accorder des autorisations à ces objets. Toutefois, en tant que propriétaire du compartiment, vous possédez toujours les objets qui ont été écrits dans le compartiment quand le paramètre Propriétaire du compartiment appliqué était appliqué. Ces objets ne sont pas la propriété de l'auteur de l'objet, même si vous les réactivezACLs.

Pour obtenir des instructions sur l'activation et la gestion à l'ACLsaide de AWS Management Console RESTAPI, AWS Command Line Interface (CLI) ou AWS SDKs, voirConfiguration ACLs.

Conditions préalables à la désactivation ACLs

Avant de procéder à ACLs la désactivation pour un bucket existant, remplissez les conditions préalables suivantes.

Passez en revue le bucket et l'objet ACLs et migrez ACL les autorisations

Lorsque vous désactivezACLs, les autorisations accordées par bucket et par objet ACLs n'affectent plus l'accès. Avant de procéder à la désactivationACLs, passez en revue votre bucket et votre objetACLs.

Si votre compartiment ACLs accorde des autorisations de lecture ou d'écriture à des personnes extérieures à votre compte, vous devez migrer ces autorisations vers votre politique de compartiment avant de pouvoir appliquer le paramètre imposé par le propriétaire du compartiment. Si vous ne migrez pas un bucket ACLs qui accorde un accès en lecture ou en écriture en dehors de votre compte, votre demande d'application du paramètre imposé par le propriétaire du bucket échoue et renvoie le InvalidBucketAclWithObjectOwnershipcode d'erreur.

Par exemple, si vous souhaitez la désactiver ACLs pour un compartiment qui reçoit les journaux d'accès au serveur, vous devez faire migrer les ACL autorisations de compartiment pour le groupe de mise à disposition des journaux S3 vers le principal du service de journalisation dans une politique de compartiment. Pour de plus amples informations, veuillez consulter Octroi de l’accès au groupe de livraison des journaux S3 pour la journalisation des accès au serveur.

Si vous souhaitez que le rédacteur d'objets conserve le contrôle total de l'objet qu'il télécharge, le rédacteur d'objets est le meilleur paramètre de propriété d'objets pour votre cas d'utilisation. Si vous souhaitez contrôler l'accès au niveau de l'objet individuel, le propriétaire du compartiment préféré est le meilleur choix. Ces cas d'utilisation sont rares.

Pour consulter ACLs et migrer ACL les autorisations vers les politiques de compartiment, consultezConditions préalables à la désactivation ACLs.

Identifier les demandes nécessitant ACL une autorisation

Pour identifier les demandes Amazon S3 nécessitant ACLs une autorisation, vous pouvez utiliser la aclRequired valeur dans les journaux d'accès au serveur Amazon S3 ou AWS CloudTrail. Si la demande nécessitait une ACL autorisation ou si vous avez des PUT demandes qui spécifient uneACL, la chaîne estYes. Si aucune valeur ACLs n'est requise, ou si vous définissez une analyse bucket-owner-full-controlACL, ou si les demandes sont autorisées par votre politique de compartiment, la chaîne de aclRequired valeur est « - » dans les journaux d'accès au serveur Amazon S3 et est absente dans CloudTrail. Pour plus d'informations sur les valeurs aclRequired attendues, consultez Valeurs aclRequired pour les demandes Amazon S3 courantes.

Si vous avez PutBucketAcl ou demandez des PutObjectAcl en-têtes qui accordent des autorisations ACL basées sur des autorisations, à l'exception des en-têtes bucket-owner-full-control prédéfinisACL, vous devez supprimer ces en-têtes avant de pouvoir les désactiver. ACLs Dans le cas contraire, vos demandes échoueront.

Pour toutes les autres demandes nécessitant une ACL autorisation, migrez ces ACL autorisations vers des politiques de compartiment. Supprimez ensuite tout compartiment ACLs avant d'activer le paramètre imposé par le propriétaire du compartiment.

Si vous constatez qu'aucune ACL demande d'autorisation n'est requise, vous pouvez procéder à la désactivationACLs. Pour plus d'informations sur l'identification des demandes, consultez Utilisation des journaux d’accès au serveur Amazon S3 pour identifier des demandes et Identification des demandes Amazon S3 à l'aide CloudTrail.

Passez en revue et mettez à jour les politiques relatives aux compartiments qui utilisent ACL des clés de condition associées

Une fois que vous avez appliqué le paramètre de désactivation obligatoire du propriétaire du compartimentACLs, les nouveaux objets ne peuvent être téléchargés dans votre compartiment que si la demande utilise le contrôle total du propriétaire du compartiment ACLs ou ne spécifie pas deACL. Avant de procéder à la désactivationACLs, consultez votre politique de compartiment pour connaître les clés ACL de condition associées.

Si votre politique de compartiment utilise une ACL clé de condition associée pour exiger le scan bucket-owner-full-control ACL (par exemple,s3:x-amz-acl), vous n'avez pas besoin de mettre à jour votre politique de compartiment. La politique de compartiment suivante utilise le s3:x-amz-acl pour exiger le bucket-owner-full-control scan ACL pour les PutObject requêtes S3. Cette politique oblige toujours le rédacteur de l'objet à spécifier l'objet bucket-owner-full-control prédéfiniACL. Toutefois, les compartiments ACLs désactivés l'acceptent toujoursACL, de sorte que les demandes continuent de réussir sans qu'aucune modification côté client ne soit requise.

{
    "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"
                }
            }
        }
    ]
}

Toutefois, si votre politique de compartiment utilise une clé ACL de condition associée qui nécessite une clé de condition différenteACL, vous devez supprimer cette clé de condition. Cet exemple de politique de compartiment nécessite les PutObject requêtes public-read ACL for S3 et doit donc être mis à jour avant la désactivation. ACLs

{
    "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"
                }
            }
        }
    ]
}

Autorisations de propriété d'objet

Pour appliquer, mettre à jour ou supprimer un paramètre de propriété d'objet pour un compartiment, vous devez utiliser l'autorisation s3:PutBucketOwnershipControls. Pour renvoyer le paramètre propriété de l'objet d'un compartiment, vous devez utiliser l'autorisation s3:GetBucketOwnershipControls. Pour plus d’informations, consultez Définition de la propriété d'objet lors de la création d'un compartiment et Affichage du paramètre de propriété d'objet pour un compartiment S3.

Désactivation ACLs pour tous les nouveaux buckets

Par défaut, tous les nouveaux compartiments sont créés avec le paramètre appliqué par le propriétaire du compartiment et ACLs sont désactivés. Nous vous recommandons de rester ACLs handicapé. En règle générale, nous recommandons d'utiliser des politiques basées sur les ressources S3 (politiques de compartiment et politiques de point d'accès) ou IAM des politiques de contrôle d'accès au lieu de. ACLs Les politiques constituent une option de contrôle d'accès simplifiée et plus flexible. Les politiques de compartiment et de point d'accès vous permettent de définir des règles s'appliquant de manière générale à toutes les demandes adressées à vos ressources Amazon S3.

Réplication et propriété d'objet

Lorsque vous utilisez la réplication S3 et que les compartiments source et de destination appartiennent à des propriétaires différents Comptes AWS, vous pouvez les désactiver ACLs (en appliquant le paramètre propriétaire du compartiment pour la propriété de l'objet) pour remplacer la propriété de la réplique par Compte AWS celle qui possède le compartiment de destination. Ce paramètre imite le comportement de remplacement du propriétaire existant sans avoir besoin d'une autorisation s3:ObjectOwnerOverrideToBucketOwner. Tous les objets répliqués dans le compartiment de destination avec le paramètre Propriétaire du compartiment appliqué appartiennent au propriétaire du compartiment de destination. Pour plus d'informations sur l'option de remplacement du propriétaire pour les configurations de réplication, consultez Modification du propriétaire d'un réplica.

Définition de la propriété de l'objet

Vous pouvez appliquer un paramètre de propriété d'objet à l'aide de la console Amazon S3 AWS CLI AWS SDKs,, RESTAPI, Amazon S3 ou AWS CloudFormation. Les AWS CLI commandes REST API et commandes suivantes prennent en charge la propriété des objets :

Pour plus d'informations sur l'application et l'utilisation des paramètres de propriété d'objet, consultez les rubriques suivantes.