Prévention du problème de l’adjoint confus entre services - AWS Transfer Family
Rôles des utilisateurs de Transfer FamilyRôles du flux de travail Transfer FamilyRôles de journalisation et d'invocation Transfer Family

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 député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les 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 d'appel peut être manipulé pour utiliser ses autorisations afin d'agir sur les ressources d'un autre client d'une manière à laquelle il ne devrait pas être autorisé à 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. Pour une description détaillée de ce problème, voir le problème de confusion des adjoints dans le guide de IAM l'utilisateur.

Nous recommandons d'utiliser les clés contextuelles de condition aws:SourceAccountglobale aws:SourceArnet les clés contextuelles dans les politiques de ressources afin de limiter les autorisations accordées à AWS Transfer Family pour la ressource. Si vous utilisez les deux clés de contexte de condition globale, la valeur aws:SourceAccount et le compte de la valeur aws:SourceArn doit utiliser le même ID de compte lorsqu’il est utilisé dans la même déclaration de stratégie.

Le moyen le plus efficace de se protéger contre le problème de confusion des adjoints est d'utiliser le nom de ressource Amazon exact (ARN) de la ressource que vous souhaitez autoriser. Si vous spécifiez plusieurs ressources, utilisez la clé de condition contextuelle aws:SourceArn globale avec des caractères génériques (*) pour les parties inconnues duARN. Par exemple, arn:aws:transfer::region::account-id:server/*.

AWS Transfer Family utilise les types de rôles suivants :

  • Rôle utilisateur — Permet aux utilisateurs gérés par le service d'accéder aux ressources Transfer Family nécessaires. AWS Transfer Family assume ce rôle dans le contexte d'un utilisateur de Transfer FamilyARN.

  • Rôle d'accès — Permet d'accéder uniquement aux fichiers Amazon S3 en cours de transfert. Pour les AS2 transferts entrants, le rôle d'accès utilise le nom de ressource Amazon (ARN) pour l'accord. Pour les AS2 transferts sortants, le rôle d'accès utilise le ARN pour le connecteur.

  • Rôle d'invocation : à utiliser avec Amazon API Gateway en tant que fournisseur d'identité personnalisé du serveur. Transfer Family assume ce rôle dans le contexte d'un serveur Transfer FamilyARN.

  • Rôle de journalisation : utilisé pour enregistrer les entrées sur Amazon CloudWatch. Transfer Family utilise ce rôle pour enregistrer les informations relatives aux réussites et aux échecs ainsi que les informations relatives aux transferts de fichiers. Transfer Family assume ce rôle dans le contexte d'un serveur Transfer FamilyARN. Pour les AS2 transferts sortants, le rôle de journalisation utilise le connecteurARN.

  • Rôle d'exécution — Permet à un utilisateur de Transfer Family d'appeler et de lancer des flux de travail. Transfer Family assume ce rôle dans le contexte d'un flux de travail Transfer FamilyARN.

Pour plus d'informations, consultez la section Politiques et autorisations IAM dans le guide de IAM l'utilisateur.

Note

Dans les exemples suivants, remplacez chaque user input placeholder avec vos propres informations.

Note

Dans nos exemples, nous utilisons à la fois ArnLike etArnEquals. Ils sont fonctionnellement identiques, et vous pouvez donc utiliser l'un ou l'autre lorsque vous élaborez vos politiques. La documentation Transfer Family ArnLike est utilisée lorsque la condition contient un caractère générique et ArnEquals pour indiquer une condition de correspondance exacte.

AWS Transfer Family : rôle d'utilisateur, interservices, prévention des adjoints confus

L'exemple de politique suivant permet à n'importe quel utilisateur de n'importe quel serveur du compte d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "account-id"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:transfer:region:account-id:user/*"
                }
            }
        }
    ]
}

L'exemple de politique suivant permet à n'importe quel utilisateur d'un serveur spécifique d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "account-id"
                },
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:transfer:region:account-id:user/server-id/*"
                }
            }
        }
    ]
}

L'exemple de politique suivant permet à un utilisateur spécifique d'un serveur spécifique d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:transfer:region:account-id:user/server-id/user-name"
                }
            }
        }
    ]
}

AWS Transfer Family Workflow, rôle, interservices, prévention des adjoints confus

L'exemple de politique suivant permet à n'importe quel flux de travail du compte d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "account-id"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:transfer:region:account-id:workflow/*"
                }
            }
        }
    ]
}

L'exemple de politique suivant permet à un flux de travail spécifique d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:transfer:region:account-id:workflow/workflow-id"
                }
            }
        }
    ]
}

AWS Transfer Family : enregistrement et rôle d'invocation, interservices, prévention des adjoints confus

Note

Les exemples suivants peuvent être utilisés à la fois dans les rôles de journalisation et d'invocation.

Dans ces exemples, vous pouvez supprimer les ARN détails d'un flux de travail si aucun flux de travail n'est associé à votre serveur.

L'exemple de politique de journalisation et d'appel suivant permet à n'importe quel serveur (et flux de travail) du compte d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAllServersWithWorkflowAttached",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "account-id"
                },
                "ArnLike": {
                   "aws:SourceArn": [
                     "arn:aws:transfer:region:account-id:server/*",
                     "arn:aws:transfer:region:account-id:workflow/*"
                   ]
                }
            }
        }
    ]
}

L'exemple de politique de journalisation et d'appel suivant permet à un serveur (et à un flux de travail) spécifiques d'assumer le rôle.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificServerWithWorkflowAttached",
            "Effect": "Allow",
            "Principal": {
                "Service": "transfer.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "account-id"
                },
                "ArnEquals": {
                   "aws:SourceArn": [
                       "arn:aws:transfer:region:account-id:server/server-id",
                       "arn:aws:transfer:region:account-id:workflow/workflow-id"
                   ]
                }
            }
        }
    ]
}