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.

Prévention du problème de l’adjoint confus entre services

Le problème de l’adjoint confus est un problème de sécurité dans lequel une entité qui n’a pas l’autorisation d’effectuer une action peut contraindre une entité plus privilégiée à effectuer cette action. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé d’accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services avec des principaux de service qui ont eu accès aux ressources de votre compte.

Nous recommandons d'utiliser les clés de contexte de condition aws:SourceAccountglobale aws:SourceArnet les clés contextuelles dans les politiques de ressources afin de limiter les autorisations qui AWS Database Migration Service accordent un autre service à la ressource. Si la valeur aws:SourceArn ne contient pas l’ID de compte, tel qu’un nom d’instance de réplication AWS DMS (ARN), vous devez utiliser les deux clés de contexte de condition globale pour limiter les autorisations. Si vous utilisez les deux clés de contexte de condition globale et que la valeur aws:SourceArn contient l'ID de compte, la valeur aws:SourceAccount et le compte dans la valeur aws:SourceArn doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction de politique. Utilisez aws:SourceArn si vous souhaitez qu'une seule ressource soit associée à l'accès entre services. Utilisez aws:SourceAccount si vous souhaitez autoriser l’association d’une ressource de ce compte à l’utilisation interservices.

AWS DMS prend en charge les options secondaires confuses à partir de la version 3.4.7 et supérieure. Pour plus d’informations, consultez AWS Notes de mise à jour du Database Migration Service 3.4.7. Si votre instance de réplication utilise AWS DMS version 3.4.6 ou antérieure, assurez-vous de passer à la dernière version avant de définir les options d’adjoint confus.

Le moyen le plus efficace de se protéger du problème de l’adjoint désorienté consiste à utiliser la clé de contexte de condition globale aws:SourceArn avec l’ARN complet de la ressource. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale aws:SourceArn avec des caractères génériques (*) pour les parties inconnues de l’ARN. Par exemple, arn:aws:dms:*:123456789012:rep:*.

Rôles IAM à utiliser avec l' AWS DMS API pour prévenir la confusion entre les services

Pour utiliser l'API AWS CLI ou l' AWS DMS API pour la migration de votre base de données, vous devez ajouter les rôles dms-vpc-role et dms-cloudwatch-logs-role IAM à votre AWS compte avant de pouvoir utiliser les fonctionnalités de AWS DMS. Pour plus d’informations, consultez Création des IAM rôles à utiliser avec AWS CLI et AWS DMS API.

L’exemple suivant illustre les politiques d’utilisation du rôle dms-vpc-role avec l’instance de réplication my-replication-instance. Utilisez ces politiques pour prévenir le problème de l’adjoint confus.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "dms.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceAccount": "your_account_id"
                },
                "ArnEqual": {
                    "AWS:SourceArn": "arn:aws:dms:your_region:your_account_id:rep:my-replication-instance"
                }
            }
        }
    ]
}

Politique IAM visant à stocker les évaluations de contrôle en amont dans Amazon S3 pour la prévention du problème de l’adjoint confus entre services

Pour stocker les résultats de la pré-évaluation dans votre compartiment S3, vous créez une politique IAM qui permet à AWS DMS de gérer les objets dans Amazon S3. Pour plus d’informations, consultez Créez des IAM ressources .

L'exemple suivant montre une politique de confiance comportant des conditions d'adjoint confuses définies pour un rôle IAM qui permet d'accéder AWS DMS à toutes les tâches et à toutes les évaluations sous un compte utilisateur spécifié.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "dms.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceAccount": "your_account_id"
                },
                "ArnLike": {
                    "AWS:SourceArn": [
                        "arn:aws:dms:your_region:your_account_id:assessment-run:*",
                        "arn:aws:dms:region:your_account_id:task:*"
                    ]
                }
            }
        }
    ]
}

Utilisation d'Amazon DynamoDB comme point de terminaison cible pour la prévention de la confusion AWS DMS entre les services

Pour utiliser Amazon DynamoDB comme point de terminaison cible pour la migration de votre base de données, vous devez créer le rôle IAM qui AWS DMS permet d'assumer et d'accorder l'accès aux tables DynamoDB. Utilisez ensuite ce rôle lorsque vous créez votre point de terminaison DynamoDB cible dans AWS DMS. Pour plus d’informations, consultez Utilisation d'Amazon DynamoDB en tant que cible.

L'exemple suivant montre une politique de confiance comportant des conditions secondaires confuses définies sur un rôle IAM qui permet à tous les AWS DMS points de terminaison d'accéder aux tables DynamoDB.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "dms.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceAccount": "your_account_id"
                },
                "ArnLike": {
                    "AWS:SourceArn": "arn:aws:dms:your_region:your_account_id:endpoint:*"
                }
            }
        }
    ]
}