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 de ACLs, 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ésactivation ACLs, 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ésactivation ACLs, votre compartiment accepte uniquement les PUT demandes qui ne spécifient pas d'ACL ou les PUT demandes avec le contrôle total du propriétaire du bucket ACLs, par exemple, l'bucket-owner-full-controlACL prédéfinie ou des formes équivalentes de cette ACL exprimées en XML. 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'objet ACLs. Avec ce paramètre, de nouveaux objets écrits avec la liste ACL bucket-owner-full-control prédéfinie sont automatiquement détenus par le propriétaire du compartiment plutôt que par l'auteur d'objets. Tous les autres comportements ACL restent en place. Pour exiger que toutes les opérations PUT Amazon S3 incluent la liste ACL bucket-owner-full-control prédéfinie, vous pouvez ajouter une politique de compartiment qui n’autorise que les chargements d’objets à l’aide de cette ACL.

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 objets ACLs, 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 d'ACL. Les téléchargements d’objets échouent s’ils spécifient une autre liste ACL. 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 l'bucket-owner-full-controlACL prédéfinie, l'objet peut être chargé dans un bucket lorsque cette option est désactivée ACLs.

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 d'ACL, elle réussit é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 migré ces autorisations ACL d'objet vers votre politique de compartiment ACLs, ces autorisations sont restaurées une fois que vous les avez réactivé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éactivez ACLs.

Pour obtenir des instructions sur l'activation et la gestion à l' ACLs AWS Management Console aide de l'API REST AWS Command Line Interface (CLI) AWS SDKs, ou consultezConfiguration 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 les autorisations ACL

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

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 autorisations ACL du bucket 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 les autorisations ACL vers les politiques de bucket, consultezConditions préalables à la désactivation ACLs.

Identifier toutes les demandes qui ont nécessité une liste ACL pour l’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 a nécessité une liste ACL pour l’autorisation ou si vous avez des demandes PUT qui spécifient une liste ACL, la chaîne est Yes. Si aucune valeur ACLs n'est requise, ou si vous définissez une ACL bucket-owner-full-control prédéfinie, 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 basées sur l'ACL, à l'exception de l'ACL bucket-owner-full-control prédéfinie, 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 liste ACL pour l’autorisation, migrez ces autorisations de liste ACL 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 demande ne nécessitait une ACL pour obtenir une autorisation, vous pouvez procéder à la désactivation ACLs. 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.

Vérifiez et mettez à jour les stratégies de compartiment qui utilisent des clés de condition associées à ACL

Une fois que vous avez appliqué le paramètre de désactivation obligatoire du propriétaire du compartiment ACLs, les nouveaux objets ne peuvent être 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 d'ACL. Avant de procéder à la désactivation ACLs, consultez votre politique de compartiment en ce qui concerne les clés de condition liées à l'ACL.

Si votre politique de compartiment utilise une clé de condition associée à la liste ACL pour exiger la liste ACL bucket-owner-full-control prédéfinie (par exemple, s3:x-amz-acl), vous n’avez pas besoin de mettre à jour votre politique de compartiment. La politique de compartiment suivante utilise la s3:x-amz-acl pour exiger la liste ACL bucket-owner-full-control prédéfinie pour les demandes PutObject S3. Cette politique demande encore au rédacteur d’objets qu’il spécifie la liste ACL bucket-owner-full-control prédéfinie. Cependant, les buckets ACLs désactivés acceptent toujours cette ACL, 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"
                }
            }
        }
    ]
}

Cependant, si votre politique de compartiment utilise une clé de condition associée à la liste ACL qui nécessite une liste ACL différente, vous devez supprimer cette clé de condition. Cet exemple de politique de compartiment nécessite l'public-readACL pour les PutObject requêtes 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 des politiques IAM pour le 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, de l'API REST Amazon S3 ou AWS CloudFormation. L'API et les AWS CLI commandes REST 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.