Conditions préalables à la désactivation des listes ACL

Une liste de contrôle d'accès aux compartiments (ACL) dans Amazon S3 est un mécanisme qui vous permet de définir des autorisations détaillées pour des objets individuels au sein d'un compartiment S3, en spécifiant quels AWS comptes ou groupes peuvent accéder à ces objets et les modifier. La majorité des cas d’utilisation modernes dans Amazon S3 ne nécessitent plus l’utilisation des listes ACL. Nous vous recommandons d'utiliser des politiques Gestion des identités et des accès AWS (IAM) et de bucket pour gérer l'accès et pour désactiver les ACL, sauf dans les cas où vous devez contrôler l'accès à chaque objet individuellement.

Si des listes ACL sont activées sur votre compartiment, remplissez les prérequis suivants avant de les désactiver :

Examinez les listes ACL de compartiment et d’objet et migrez les autorisations ACL

Lorsque vous désactivez les listes ACL, les autorisations accordées par les listes ACL de compartiment et d’objets n’affectent plus l’accès. Avant de désactiver les listes ACL, vérifiez les listes ACL de votre compartiment et de vos objets.

Chacune de vos listes ACL de compartiment et d’objet existantes possède un équivalent dans une politique IAM. Les exemples de stratégie de compartiment suivants montrent comment les autorisations READ et WRITE pour les listes ACL de compartiment et d’objet correspondent aux autorisations IAM. Pour plus d’informations sur la façon dont chaque liste ACL se traduit par des autorisations IAM, consultez Mappage des autorisations de liste ACL et de stratégie d’accès.

Avant de désactiver des listes ACL :

Si les listes ACL de votre compartiment accordent des autorisations de lecture ou d’écriture à des personnes extérieures à votre compte, vous devez migrer ces autorisations vers votre stratégie de compartiment. Après avoir migré ces autorisations, vous pouvez définir Propriétaire de l’objet sur Propriétaire du compartiment appliqué. Si vous ne migrez pas les listes ACL de compartiment qui accordent un accès en lecture ou en écriture hors de votre compte, votre demande d’application du paramètre Propriétaire du compartiment appliqué échoue et renvoie le code d’erreur InvalidBucketAclWithObjectOwnership.

Si l'ACL de votre bucket accorde un accès en dehors de la Compte AWS vôtre, avant de désactiver les ACL, vous devez migrer les autorisations ACL de votre bucket vers votre politique de bucket et réinitialiser votre ACL de bucket sur l'ACL privée par défaut. Si vous ne le faites pas, votre demande d’application du paramètre Propriétaire du compartiment appliqué pour désactiver les listes ACL échoue et renvoie le code d’erreur InvalidBucketAclWithObjectOwnership. Nous vous recommandons également de revoir les autorisations ACL de votre objet et de les migrer vers votre stratégie de compartiment.

Pour consulter et migrer les autorisations ACL vers des stratégies de compartiment, consultez les rubriques suivantes.

Exemples de stratégies de compartiment

Ces exemples de politiques de compartiment vous montrent comment migrer les autorisations ACL de WRITE compartiment READ et d'objet pour un tiers Compte AWS vers une politique de compartiment. READ_ACPet WRITE_ACP les ACL sont moins pertinentes pour les politiques car elles accordent ACL-related des autorisations (s3:GetBucketAcl, s3:GetObjectAcls3:PutBucketAcl, ets3:PutObjectAcl).

"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/OBJECT-KEY"

Utilisation de la console S3 pour réviser et migrer les autorisations ACL

Utilisation de AWS CLI pour vérifier et migrer les autorisations ACL

Identifier toutes les demandes qui ont nécessité une liste ACL pour l’autorisation

Pour identifier les demandes Amazon S3 qui ont nécessité des listes ACL pour l'autorisation, vous pouvez utiliser la valeur aclRequired dans les journaux d'accès du 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 ACL 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 ACL requises pour les demandes Amazon S3 courantes.

Si vous avez PutBucketAcl ou demandez PutObjectAcl des en-têtes qui accordent des ACL-based autorisations, à l'exception de l'ACL bucket-owner-full-control prédéfinie, vous devez supprimer ces en-têtes avant de pouvoir désactiver les ACL. 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 stratégies de compartiment. Supprimez ensuite toutes les listes ACL du compartiment avant d’activer le paramètre appliqué par le propriétaire du compartiment.

Si vous constatez qu’aucune demande ne nécessite une liste ACL pour l’autorisation, vous pouvez procéder à la désactivation des listes ACL. 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 politiques relatives aux compartiments qui utilisent des clés de ACL-related condition

Une fois que vous avez appliqué le paramètre Propriétaire du compartiment appliqué pour désactiver les listes ACL, les nouveaux objets peuvent être téléchargés dans votre compartiment uniquement si la demande utilise des listes ACL de contrôle total du propriétaire du compartiment ou ne spécifie pas de liste ACL. Avant de désactiver les ACL, consultez votre politique de compartiment en matière de clés de ACL-related condition.

Si votre politique de compartiment utilise une clé de ACL-related condition pour exiger l'bucket-owner-full-controlACL prédéfinie (par exemple,s3:x-amz-acl), vous n'avez pas besoin de mettre à jour votre politique de compartiment. La stratégie 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. Toutefois, les compartiments dont les listes ACL sont désactivées acceptent toujours cette liste ACL, de sorte que les demandes continuent d’aboutir sans modification côté client requise.

Toutefois, si votre politique de compartiment utilise une clé de ACL-related condition qui nécessite une autre ACL, vous devez supprimer cette clé de condition. Cet exemple de stratégie de compartiment nécessite la liste ACL public-read pour les demandes S3 PutObject et doit donc être mis à jour avant de désactiver les listes ACL.

Exemples de cas d’utilisation

Les exemples suivants vous montrent comment migrer les autorisations ACL vers des stratégies de compartiment pour des cas d’utilisation spécifiques.

Octroi de l’accès au groupe de livraison des journaux S3 pour la journalisation des accès au serveur

Si vous souhaitez appliquer le paramètre Propriétaire du compartiment appliqué pour désactiver les listes ACL pour un compartiment de destination de journalisation des accès au serveur (également appelé compartiment cible), vous devez migrer les autorisations ACL de compartiment pour le groupe de livraison des journaux S3 vers le principal du service de journalisation (logging.s3.amazonaws.com) dans une stratégie de compartiment. Pour plus d’informations sur les autorisations de la diffusion des journaux, consultez Autorisations de diffusion de journaux.

Ce compartiment ACL accorde un accès en WRITE et en READ_ACP au groupe de mise à disposition des journaux S3 :

{
    "Owner": {
        "ID": "852b113e7a2f25102679df27bb0ae12b3f85be6BucketOwnerCanonicalUserID"
    }, 
    "Grants": [
        {
            "Grantee": {
                "Type": "CanonicalUser", 
                "ID": "852b113e7a2f25102679df27bb0ae12b3f85be6BucketOwnerCanonicalUserID"
            }, 
            "Permission": "FULL_CONTROL"
        }, 
        {
            "Grantee": {
                "Type": "Group", 
                "URI": "http://acs.amazonaws.com/groups/s3/LogDelivery"
            }, 
            "Permission": "WRITE"
        }, 
        {
            "Grantee": {
                "Type": "Group", 
                "URI": "http://acs.amazonaws.com/groups/s3/LogDelivery"
            }, 
            "Permission": "READ_ACP"
        }
    ]
}

Accordez un accès public en lecture aux objets se trouvant dans un compartiment.

Si vos listes ACL d’objet accordent un accès public en lecture à tous les objets de votre compartiment, vous pouvez migrer ces autorisations ACL vers une stratégie de compartiment.

Cette liste ACL d’objet accorde un accès public en lecture à un objet dans un compartiment :

{
    "Owner": {
        "ID": "852b113e7a2f25102679df27bb0ae12b3f85be6BucketOwnerCanonicalUserID"
    },
    "Grants": [
        {
            "Grantee": {
                "ID": "852b113e7a2f25102679df27bb0ae12b3f85be6BucketOwnerCanonicalUserID",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        },
        {
            "Grantee": {
                "Type": "Group",
                "URI": "http://acs.amazonaws.com/groups/global/AllUsers"
            },
            "Permission": "READ"
        }
    ]
}

Accordez à Amazon ElastiCache (Redis OSS) l'accès à votre compartiment S3

Vous pouvez exporter votre sauvegarde ElastiCache (Redis OSS) vers un compartiment S3, ce qui vous permet d'accéder à la sauvegarde depuis l'extérieur ElastiCache. Pour exporter votre sauvegarde vers un compartiment S3, vous devez autoriser ElastiCache la copie d'un instantané dans le compartiment. Si vous avez accordé des autorisations ElastiCache à une ACL de compartiment, vous devez migrer ces autorisations vers une politique de compartiment avant d'appliquer le paramètre imposé par le propriétaire du compartiment pour désactiver les ACL. Pour plus d'informations, consultez la section Accorder l' ElastiCache accès à votre compartiment Amazon S3 dans le guide de ElastiCache l'utilisateur Amazon.

L'exemple suivant montre les autorisations ACL du bucket qui accordent des autorisations à ElastiCache.

{
    "Owner": {
        "ID": "852b113e7a2f25102679df27bb0ae12b3f85be6BucketOwnerCanonicalUserID"
    },
    "Grants": [
        {
            "Grantee": {
                "ID": "852b113e7a2f25102679df27bb0ae12b3f85be6BucketOwnerCanonicalUserID",
                "Type": "CanonicalUser"
            },
            "Permission": "FULL_CONTROL"
        },
        {
            "Grantee": {
                "ID": "540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353",
                "Type": "CanonicalUser"
            },
            "Permission": "READ"
        },
        {
            "Grantee": {
                "ID": "540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353",
                "Type": "CanonicalUser"
            },
            "Permission": "WRITE"
        },
        {
            "Grantee": {
                "ID": "540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353",
                "Type": "CanonicalUser"
            },
            "Permission": "READ_ACP"
        }
    ]
}