Pourquoi mes objets Amazon S3 ne se répliquent-ils pas lorsque je configure la réplication entre mes compartiments ?

Lecture de 10 minute(s)
0

J'ai configuré la réplication entre régions (CRR) ou la réplication dans la même région (SRR) entre mes compartiments Amazon Simple Storage Service (Amazon S3). Cependant, les objets ne sont pas répliqués dans le compartiment de destination.

Résolution

Pour résoudre les problèmes liés aux objets S3 qui ne se répliquent pas dans le compartiment de destination, vérifiez les différents types d'autorisations associés à votre compartiment. Vérifiez également les paramètres d'accès public et les paramètres de propriété des compartiments.

**Conseil :**Chargez un objet dans le compartiment source pour tester la réplication après chaque modification de configuration. Il est recommandé d'apporter une modification de configuration à la fois afin d'identifier tout problème de configuration de la réplication.

Une fois les problèmes à l'origine de l'échec de la réplication résolus, il se peut que certains objets du compartiment source n'aient pas été répliqués. Par défaut, la réplication S3 ne réplique pas les objets existants ou les objets dont l'état de réplication estÉCHEC ou RÉPLIQUE. Pour vérifier l'état de réplication des objets qui n'ont pas été répliqués, consultez la section Récupérer la liste des objets S3 dont la réplication a échoué. Utilisez la réplication par lots S3 pour répliquer ces objets.

Autorisations Amazon S3 minimales

Vérifiez que le rôle AWS Identity Access Management (IAM) que vous avez utilisé dans la règle de réplication dispose des autorisations appropriées. Si les compartiments source et de destination se trouvent sur des comptes différents, vérifiez que la politique de compartiment du compte de destination accorde également des autorisations suffisantes au rôle de la réplication.

L'exemple suivant montre une politique IAM dotée des autorisations minimales requises pour la réplication. Selon les options des règles de réplication (par exemple : chiffrement avec SSE-KMS), vous devrez peut-être accorder des autorisations supplémentaires.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetReplicationConfiguration",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::SourceBucket"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObjectVersionForReplication",
        "s3:GetObjectVersionAcl",
        "s3:GetObjectVersionTagging"
      ],
      "Resource": [
        "arn:aws:s3:::SourceBucket/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateDelete",
        "s3:ReplicateTags"
      ],
      "Resource": "arn:aws:s3:::DestinationBucket/*"
    }
  ]
}

Remarque : RemplacezSourceBucket et DestinationBucket par les noms de vos compartiments S3.

Le rôle IAM doit être doté d'une stratégie d'approbation qui permet à Amazon S3 d'assumer le rôle de répliquer des objets.

Exemple :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Si le compartiment de destination se trouve dans un autre compte, la politique du compartiment de destination doit accorder les autorisations suivantes :

{
  "Version": "2012-10-17",
  "Id": "PolicyForDestinationBucket",
  "Statement": [
    {
      "Sid": "Permissions on objects",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"
      },
      "Action": [
        "s3:ReplicateTags",
        "s3:ReplicateDelete",
        "s3:ReplicateObject"
      ],
      "Resource": "arn:aws:s3:::DestinationBucket/*"
    }
  ]
}

Remarque : Remplacez arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role par l'ARN de votre rôle de réplication.

Autorisations Amazon S3 supplémentaires

Si la règle de réplication est définie surModifier la propriété de l'objet au propriétaire du compartiment de destination, le rôle IAM doit disposer de l'autorisation s3:ObjectOwnerOverrideToBucketOwner. Cette autorisation est placée sur la ressource objet S3.

Exemple :

{
    "Effect":"Allow",
         "Action":[
       "s3:ObjectOwnerOverrideToBucketOwner"
    ],
    "Resource":"arn:aws:s3:::DestinationBucket/*"
}

Le compte de destination doit également accorder l'autorisation s3:ObjectOwnerOverrideToBucketOwner par le biais de la politique de compartiment :

{
    "Sid":"1",
    "Effect":"Allow",
    "Principal":{"AWS":"arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"},
    "Action":["s3:ObjectOwnerOverrideToBucketOwner"],
    "Resource":"arn:aws:s3:::DestinationBucket/*"
}

Remarque : Si les paramètres de propriété des objets du compartiment de destination** incluent le paramètre Propriétaire du compartiment forcé**, il n'est pas nécessaire de modifier la propriété de l'objet par le propriétaire du compartiment de destination dans la règle de réplication. Cette modification intervient par défaut.

Si le marqueur de suppression est activé dans la règle de réplication, le rôle IAM doit disposer des autorisations s3:ReplicateDelete. Si le compartiment de destination se trouve dans un autre compte, le propriétaire du compartiment de destination doit également accorder cette autorisation par le biais de la politique du compartiment. Par exemple :

{
    "Effect":"Allow",
    "Action":["s3:ReplicateDelete"],
    "Resource":"arn:aws:s3:::DestinationBucket/*"
}

Remarque : Remplacez DestinationBucket par le nom de votre compartiment S3.

Une fois que vous avez ajouté les autorisations S3 supplémentaires au rôle IAM, les mêmes autorisations doivent être accordées via la politique de compartiment du compartiment de destination :

{
  "Version": "2012-10-17",
  "Id": "PolicyForDestinationBucket",
  "Statement": [
    {
      "Sid": "Stmt1644945277847",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"
      },
      "Action": [
        "s3:ReplicateObject",
        "s3:ReplicateTags",
        "s3:ObjectOwnerOverrideToBucketOwner",
        "s3:ReplicateDelete"
      ],
      "Resource": "arn:aws:s3:::DestinationBucket/*"
    }
  ]
}

Autorisations AWS KMS

Si les objets sources d'un compartiment sont chiffrés avec une clé AWS KMS, la règle de réplication doit être configurée pour inclure les objets chiffrés par AWS KMS.

Pour inclure des objets chiffrés avec AWS KMS, procédez comme suit :

1.    Ouvrez la console Amazon S3.

2.    Choisissez le compartiment S3 qui contient les objets source.

3.    Dans l'onglet Gestion, sélectionnez une règle de réplication.

5.    Choisissez Modifier.

6.    Sous Chiffrement, sélectionnez Répliquer les objets chiffrés avec AWS KMS.

7.    Sous Clé AWS KMS pour le chiffrement des objets de destination, sélectionnez une clé AWS KMS. L'option par défaut consiste à utiliser la clé AWS KMS (aws/S3).

Exemples : Exemples de politiques : utilisation de SSE-S3 et de SSE-KMS avec réplication

Important : Si le compartiment de destination se trouve dans un autre compte AWS, spécifiez une clé gérée par le client KMS qui appartient au compte de destination. N'utilisez pas la clé aws/S3 par défaut. Cela permet de chiffrer les objets à l'aide de la clé gérée par AWS qui appartient au compte source et qui ne peut pas être partagée avec un autre compte. Par conséquent, le compte de destination ne peut pas accéder aux objets du compartiment de destination.

Autorisations supplémentaires d'AWS KMS pour les scénarios impliquant plusieurs comptes

Pour utiliser une clé AWS KMS qui appartient au compte de destination afin de chiffrer les objets de destination, le compte de destination doit accorder le rôle de réplication dans la stratégie de clé KMS :

{
    "Sid": "AllowS3ReplicationSourceRoleToUseTheKey",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::SourceBucket-account-ID:role/service-role/source-account-IAM-role"},
    "Action": ["kms:GenerateDataKey", "kms:Encrypt"],
    "Resource": "*"
}

**Remarque :**Supposons que vous utilisiez un astérisque (*) pour Resource dans la politique de clés d'AWS KMS. Dans ce cas, la politique accorde l'autorisation d'utiliser la clé AWS KMS uniquement au rôle de réplication. La politique n'autorise pas le rôle de réplication à élever ses autorisations.

En outre, le compte source doit ajouter les autorisations minimales suivantes à la politique IAM du rôle de réplication :

{
    "Effect": "Allow",
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": [
        "SourceKmsKeyArn"
    ]
},
{
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey",
        "kms:Encrypt"
    ],
    "Resource": [
        "DestinationKmsKeyArn"
    ]
}

Par défaut, la stratégie de clé KMS accorde à l'utilisateur racine des autorisations complètes sur la clé. Vous pouvez ainsi déléguer ces autorisations à d'autres utilisateurs du même compte. Vous pouvez utiliser une politique IAM pour accorder au rôle de réplication des autorisations sur la clé KMS source. Cela est suffisant à moins que la politique de clé KMS source ne contienne des instructions de refus.

Instructions de refus explicite et d'autorisation conditionnelle

Si vos objets ne sont pas toujours répliqués une fois que vous avez validé les autorisations, vérifiez s'il existe des instructions de rejet explicite :

  • Refuser les instructions figurant dans la politique du compartiment de destination ou dans les politiques clés d'AWS KMS qui limitent l'accès aux éléments suivants peut entraîner l'échec de la réplication.
    • Gammes CIDR spécifiques
    • Points de terminaison du cloud privé virtuel (VPC)
    • Points d'accès S3
  • Les instructions de rejet ou les limites d'autorisations associées au rôle IAM peuvent entraîner l'échec de la réplication.
  • Les instructions de rejet figurant dans les politiques de contrôle des services AWS Organizations associées aux comptes source ou de destination peuvent entraîner l'échec de la réplication.

Conseil : Avant de supprimer toute instruction de rejet explicite, confirmez la raison de l'utilisation du rejet et déterminez si l'instruction a un impact sur la sécurité des données.

Clés de compartiment Amazon S3 et considérations relatives à la réplication

Si les clés KMS source ou de destination accordent des autorisations en fonction du contexte de chiffrement, vérifiez que les clés de compartiment S3 sont activées pour les compartiments. Si les clés de compartiment sont activées, le contexte de chiffrement doit concerner la ressource au niveau du compartiment :

"kms:EncryptionContext:aws:s3:arn": [
     "arn:aws:s3:::SOURCE_BUCKET_NAME"
     ]
"kms:EncryptionContext:aws:s3:arn": [
     "arn:aws:s3:::DESTINATION_BUCKET_NAME"
     ]

Remarque : Remplacez SOURCE_BUCKET_NAME et DESTINATION_BUCKET_NAME par les noms de vos compartiments source et de destination.    

Si les clés de compartiment ne sont pas activées pour les compartiments source ou de destination, le contexte de chiffrement doit être la ressource au niveau de l'objet :

"kms:EncryptionContext:aws:s3:arn": [
     "arn:aws:s3:::SOURCE_BUCKET_NAME/*"
     ]
"kms:EncryptionContext:aws:s3:arn": [
     "arn:aws:s3:::DESTINATION_BUCKET_NAME/*"
     ]

Remarque : Remplacez SOURCE_BUCKET_NAME et DESTINATION_BUCKET_NAME par les noms de vos compartiments source et de destination.

Les ACL d'objet et le blocage de l'accès public

Vérifiez si les compartiments source et de destination utilisent des listes de contrôle d'accès (ACL). Si l'objet est associé à une ACL qui autorise l'accès public, mais que le compartiment de destination utilise le blocage de l'accès public, la réplication échoue.

Propriété de l'objet source

Si les objets du compartiment source ont été chargés par un autre compte AWS, le compte source n'est peut-être pas autorisé à accéder à ces objets. Vérifiez le compartiment source pour voir si les ACL sont désactivées. Si les ACL du compartiment source sont désactivées, le compte source est le propriétaire de tous les objets du compartiment. Si les ACL du compartiment source ne sont pas désactivées, vérifiez si la Propriété de l'objet est définie sur Propriétaire de l'objet préféré ou Propriétaire du compartiment préféré. Si le compartiment est défini sur Propriétaire du compartiment préféré, les objets du compartiment source ont besoin d'une ACL avec contrôle total du propriétaire du compartiment pour que le propriétaire du compartiment devienne le propriétaire de l'objet.

Le compte source peut devenir propriétaire de tous les objets de son compartiment en désactivant les ACL. La plupart des cas d'utilisation ne nécessitent pas l'utilisation des ACL pour gérer l'accès. Il est recommandé d'utiliser les politiques IAM et de compartiment pour gérer l'accès aux ressources S3. Pour désactiver les ACL sur votre compartiment S3, consultez la section Contrôle de la propriété des objets et désactivation des listes ACL pour votre compartiment. Assurez-vous d'évaluer l'utilisation actuelle des ACL sur votre compartiment et vos objets. Votre compartiment actuel et vos politiques IAM doivent accorder des autorisations suffisantes pour que vous puissiez désactiver les ACL sans affecter l'accès à Amazon S3.

Filtre de règles de réplication

Assurez-vous d'avoir correctement spécifié le filtre de règles de réplication.

Si vous spécifiez un filtre de règles combinant un préfixe clé et des balises d'objet, S3 exécute une opération logique AND pour combiner ces filtres. En d'autres termes, la règle s'applique à un sous-ensemble d'objets dotés d'un préfixe clé spécifique et de balises spécifiques.

Informations connexes

Procédures pas à pas : Exemples de configuration de la réplication

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 10 mois