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.

Rôles IAM

Lors de la création d'un groupe d'identités, vous êtes invité à mettre à jour les rôles IAM qu'assument vos utilisateurs. Les rôles IAM fonctionnent de la manière suivante : quand un utilisateur se connecte à votre application, Amazon Cognito génère des informations d'identification AWS temporaires pour celui-ci. Ces informations d'identification temporaires sont associées à un rôle IAM spécifique. Ce rôle IAM vous permet de définir un ensemble d'autorisations pour accéder à vos ressources AWS .

Vous pouvez spécifier des rôles IAM par défaut pour les utilisateurs authentifiés et ceux qui ne le sont pas. Vous pouvez également définir des règles pour choisir le rôle pour chaque utilisateur en fonction de demandes dans le jeton d'identification de l'utilisateur. Pour de plus amples informations, veuillez consulter Utilisation du contrôle d'accès basé sur les rôles.

Par défaut, la console Amazon Cognito crée des rôles IAM donnant accès à Amazon Mobile Analytics et à Amazon Cognito Sync. Vous pouvez également choisir d'utiliser des rôles IAM existants.

Modifiez les rôles IAM pour autoriser ou restreindre l'accès à d'autres services. Pour cela, connectez-vous à la console IAM. Sélectionnez ensuite Roles (Rôles), puis sélectionnez un rôle. Les politiques associées au rôle sélectionné sont répertoriées dans l'onglet Permissions. Vous pouvez personnaliser une stratégie d'accès en sélectionnant le lien correspondant Manage Policy (Gérer la politique). Pour plus d'informations sur l'utilisation et la définition des politiques, consultez la section Présentation des politiques IAM.

Configurer une politique d'approbation

Amazon Cognito utilise des rôles IAM pour générer des informations d'identification temporaires pour les utilisateurs de votre application. L'accès aux autorisations est contrôlé par les relations d'approbation d'un rôle. En savoir plus sur Autorisations et approbation de rôle.

Le jeton présenté AWS STS est généré par un pool d'identités, qui traduit un pool d'utilisateurs, un jeton social ou un jeton de fournisseur OIDC, ou une assertion SAML, en son propre jeton. Le jeton de la réserve d'identités contient une réclamation aud qui est l'ID de la réserve d'identités.

L'exemple de politique de confiance des rôles suivant permet au principal du service fédéré cognito-identity.amazonaws.com d'appeler l' AWS STS APIAssumeRoleWithWebIdentity. La demande n'aboutira que si le jeton de la réserve d'identités figurant dans la demande d'API comporte les demandes suivantes.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "cognito-identity.amazonaws.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "cognito-identity.amazonaws.com:aud": "us-west-2:abcdefg-1234-5678-910a-0e8443553f95"
                },
                "ForAnyValue:StringLike": {
                    "cognito-identity.amazonaws.com:amr": "authenticated"
                }
            }
        }
    ]
}

Politiques de confiance pour les rôles IAM dans l'authentification de base (classique)

Vous devez appliquer au moins une condition qui limite les politiques de confiance pour les rôles que vous utilisez avec les groupes d'identités. Lorsque vous créez ou mettez à jour des politiques d'approbation des rôles pour les pools d'identités, IAM renvoie un message d'erreur si vous essayez d'enregistrer vos modifications sans au moins une clé de condition limitant les identités sources. AWS STS n'autorise pas les AssumeRoleWithWebIdentityopérations entre comptes, qu'il s'agisse de pools d'identités ou de rôles IAM dépourvus de ce type de condition.

Cette rubrique inclut plusieurs conditions qui limitent les identités sources pour les pools d'identités. Pour une liste complète, voir Clés disponibles pour la fédération d'identité AWS Web.

Dans le cadre de l'authentification de base ou classique avec un pool d'identités, vous pouvez assumer n'importe quel rôle IAM AWS STS s'il dispose de la bonne politique de confiance. Les rôles IAM pour les groupes d’identités Amazon Cognito font confiance au principal de service cognito-identity.amazonaws.com pour assumer ce rôle. Cette configuration n'est pas suffisante pour protéger vos rôles IAM contre tout accès involontaire aux ressources. Les rôles de ce type doivent appliquer une condition supplémentaire à la politique de confiance des rôles. Vous ne pouvez pas créer ou modifier des rôles pour des pools d'identités sans au moins l'une des conditions suivantes.

L'authentification à flux amélioré nécessite que le rôle IAM soit identique à celui Compte AWS du pool d'identités, mais ce n'est pas le cas dans le cas de l'authentification de base.

Des considérations supplémentaires s’appliquent aux groupes d’identités Amazon Cognito qui assument des rôles IAM entre comptes. Les politiques de confiance de ces rôles doivent accepter le principe du cognito-identity.amazonaws.com service et contenir la cognito-identity.amazonaws.com:aud condition spécifique. Pour empêcher tout accès involontaire à vos AWS ressources, la clé de aud condition limite le rôle aux utilisateurs des pools d'identités figurant dans la valeur de la condition.

Le jeton émis par un pool d'identités pour une identité contient des informations sur l'origine Compte AWS du pool d'identités. Lorsque vous présentez un jeton de pool d'identités dans une AWS STS demande d'AssumeRoleWithWebIdentityAPI, vérifiez si le pool d'identités d'origine est Compte AWS identique au rôle IAM. S'il AWS STS détermine que la demande est intercomptes, il vérifie si la politique de confiance des rôles comporte une aud condition. L'appel assume-rôle échoue si aucune condition de ce type n'est présente dans la politique d'approbation des rôles. Si la demande n'est pas intercomptes, cette restriction AWS STS n'est pas appliquée. La meilleure pratique consiste à toujours appliquer une condition de ce type aux politiques de confiance des rôles de votre pool d'identités.

Conditions supplémentaires de la politique de confiance

Réutilisation des rôles entre les groupes d'identités

Pour réutiliser un rôle dans plusieurs groupes d'identités qui partagent un jeu d'autorisations commun, procédez comme suit afin d'inclure les groupes d'identités requis :

"StringEquals": {
    "cognito-identity.amazonaws.com:aud": [
        "us-east-1:12345678-abcd-abcd-abcd-123456790ab",
        "us-east-1:98765432-dcba-dcba-dcba-123456790ab"
    ]
}

Restriction de l'accès à des identités spécifiques

Pour créer une politique limitée à un ensemble spécifique d'utilisateurs de l'application, vérifiez la valeur   :cognito-identity.amazonaws.com:sub

"StringEquals": {
    "cognito-identity.amazonaws.com:aud": "us-east-1:12345678-abcd-abcd-abcd-123456790ab",
    "cognito-identity.amazonaws.com:sub": [
        "us-east-1:12345678-1234-1234-1234-123456790ab",
        "us-east-1:98765432-1234-1234-1243-123456790ab"
    ]
}

Restriction de l'accès à des fournisseurs spécifiques

Pour créer une politique limitée aux utilisateurs qui se sont connectés avec un fournisseur spécifique (votre propre fournisseur de connexion, par exemple), vérifiez la valeur   :cognito-identity.amazonaws.com:amr

"ForAnyValue:StringLike": {
    "cognito-identity.amazonaws.com:amr": "login.myprovider.myapp"
}

Par exemple, une application qui n'autorise que Facebook présente la clause AMR suivante :

"ForAnyValue:StringLike": {
    "cognito-identity.amazonaws.com:amr": "graph.facebook.com"
}

politiques d'accès

Les autorisations que vous attachez à un rôle s'appliquent à tous les utilisateurs qui assument ce rôle. Pour partitionner l'accès de vos utilisateurs, utilisez des conditions et des variables de politique. Pour en savoir plus, consultez Éléments des politiques IAM : variables et balises. Vous pouvez utiliser sub cette condition pour limiter les actions à l'identité Amazon Cognito IDs dans vos politiques d'accès. Utilisez cette option avec prudence, surtout avec les identités non authentifiées, qui ne disposent pas d'un ID d'utilisateur constant. Pour plus d'informations sur les variables de politique IAM pour la fédération Web avec Amazon Cognito, consultez la section Clés contextuelles IAM AWS STS et conditionnelles dans AWS Identity and Access Management le Guide de l'utilisateur.

Pour une sécurité accrue, Amazon Cognito applique une politique de limitation de portée aux informations d'identification que vous attribuez à vos utilisateurs non authentifiés dans le flux amélioré, à l'aide de GetCredentialsForIdentity. La politique de limitation de portée ajoute une Politique de session en ligne et une AWS politique de session gérée aux politiques IAM que vous appliquez à votre rôle non authentifié. Puisque vous devez accorder l'accès à la fois dans les politiques IAM de votre rôle et dans les politiques de session, la politique de limitation de portée limite l'accès des utilisateurs aux services autres que ceux figurant dans la liste suivante.

Amazon Cognito empêche également les utilisateurs authentifiés et non authentifiés d'envoyer des demandes d'API aux réserves d'identités Amazon Cognito et à Amazon Cognito Sync. D'autres Services AWS peuvent imposer des restrictions sur l'accès aux services à partir d'identités Web.

Dans le cas d'une demande réussie avec le flux amélioré, Amazon Cognito effectue une demande d'API AssumeRoleWithWebIdentity en arrière-plan. Parmi les paramètres de cette demande, voici ceux qu'Amazon Cognito inclut.

Services auxquels les utilisateurs non authentifiés peuvent accéder

Lorsque vous utilisez le flux amélioré, les politiques de limitation d'étendue qu'Amazon Cognito applique à la session de votre utilisateur l'empêchent d'utiliser d'autres services que ceux répertoriés dans le tableau suivant. Pour un sous-ensemble de services, seules des actions spécifiques sont autorisées.

¹ Pour ce Services AWS qui est du tableau suivant, la politique intégrée autorise un sous-ensemble d'actions. Le tableau affiche les actions disponibles pour chaque politique.

Pour autoriser l'accès Services AWS au-delà de cette liste, activez le flux d'authentification de base (classique) dans votre pool d'identités. Si vos utilisateurs Services AWS constatent NotAuthorizedException des erreurs autorisées par les politiques attribuées au rôle IAM pour les utilisateurs non authentifiés, évaluez si vous pouvez supprimer ce service de votre cas d'utilisation. Si ce n'est pas possible, basculez sur le flux de base.

La politique de session en ligne pour les utilisateurs invités

Amazon Cognito applique d'abord une politique intégrée dans la demande d'informations d'identification IAM. La politique de session en ligne limite les autorisations effectives de votre utilisateur qui ne peut pas inclure d'accès aux Services AWS en dehors de ceux figurant dans la liste suivante. Vous devez également leur accorder des autorisations Services AWS dans les politiques que vous appliquez au rôle IAM de l'utilisateur. Les autorisations effectives d'un utilisateur pour une session avec rôle assumé se trouvent à l'intersection des politiques attribuées à son rôle et de sa politique de session. Pour en savoir plus, consultez Politiques de session dans le Guide de l'utilisateur AWS Identity and Access Management .

Amazon Cognito ajoute la politique en ligne suivante aux sessions de vos utilisateurs dans les Régions AWS qui sont activées par défaut. Pour un aperçu de l'effet net de la politique en ligne et des autres politiques de session, voirServices auxquels les utilisateurs non authentifiés peuvent accéder.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:*",
                "logs:*",
                "dynamodb:*",
                "kinesis:*",
                "mobileanalytics:*",
                "s3:*",
                "ses:*",
                "sns:*",
                "sqs:*",
                "lambda:*",
                "machinelearning:*",
                "execute-api:*",
                "iot:*",
                "gamelift:*",
                "scs:*",
                "cognito-identity:*",
                "cognito-idp:*",
                "lex:*",
                "polly:*",
                "comprehend:*",
                "translate:*",
                "transcribe:*",
                "rekognition:*",
                "mobiletargeting:*",
                "firehose:*",
                "appsync:*",
                "personalize:*",
                "sagemaker:InvokeEndpoint",
                "cognito-sync:*",
                "sumerian:View*",
                "codewhisperer:*",
                "textract:DetectDocumentText",
                "textract:AnalyzeDocument",
                "sdb:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Pour toutes les autres régions, la politique de limitation d'étendue intégrée inclut tout ce qui est répertorié dans les régions par défaut, à l'exception des déclarations Action suivantes.

                "cognito-sync:*",
                "sumerian:View*",
                "codewhisperer:*",
                "textract:DetectDocumentText",
                "textract:AnalyzeDocument",
                "sdb:*"

La politique de session AWS gérée pour les invités

Amazon Cognito applique également une politique AWS gérée en tant que politique de session aux sessions à flux amélioré des invités non authentifiés. Cette politique limite la portée des autorisations des utilisateurs non authentifiés grâce à la politique. AmazonCognitoUnAuthedIdentitiesSessionPolicy

Vous devez également accorder cette autorisation dans les politiques que vous attachez à votre rôle IAM non authentifié. Les autorisations effectives d'un utilisateur pour une session assumant un rôle se situent à l'intersection des politiques IAM attribuées à son rôle et de leurs politiques de session. Pour en savoir plus, consultez Politiques de session dans le Guide de l'utilisateur AWS Identity and Access Management .

Pour un aperçu de l'effet net de cette stratégie AWS gérée et des autres politiques de session, voirServices auxquels les utilisateurs non authentifiés peuvent accéder.

La politique gérée AmazonCognitoUnAuthedIdentitiesSessionPolicy contient les autorisations suivantes.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "rum:PutRumEvents",
            "polly:*",
            "comprehend:*",
            "translate:*",
            "transcribe:*",
            "rekognition:*",
            "mobiletargeting:*",
            "firehose:*",
            "personalize:*",
            "sagemaker:InvokeEndpoint",
            "geo:GetMap*",
            "geo:SearchPlaceIndex*",
            "geo:GetPlace",
            "geo:CalculateRoute*",
            "geo:*Geofence",
            "geo:*Geofences",
            "geo:*DevicePosition*",
            "kms:Encrypt",
            "kms:Decrypt",
            "kms:ReEncryptTo",
            "kms:ReEncryptFrom",
            "kms:GenerateDataKey",
            "kms:GenerateDataKeyPair",
            "kms:GenerateDataKeyPairWithoutPlaintext",
            "kms:GenerateDataKeyWithoutPlaintext"
        ],
        "Resource": "*"
    }]
}

Exemples de politiques d'accès

Dans cette section, vous trouverez des exemples de stratégies d'accès Amazon Cognito qui accordent aux utilisateurs les autorisations minimales nécessaires pour exécuter une opération spécifique. Vous pouvez limiter davantage les autorisations pour un ID d'identité donné en utilisant des variables de politique dans la mesure du possible. Par exemple, avec ${cognito-identity.amazonaws.com:sub}. Pour plus d'informations, consultez Présentation de l'authentification Amazon Cognito 3e partie : Rôles et politiques sur le blog AWS Mobile.

Octroi à une identité d'un accès en lecture à un objet individuel dans Amazon S3

La stratégie d'accès suivante accorde des autorisations de lecture à une identité pour récupérer un seul objet à partir d'un compartiment S3 donné.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/assets/my_picture.jpg"]
    }
  ]
}

Octroi à une identité d'un accès en lecture et en écriture à des chemins spécifiques à l'identité dans Amazon S3

La stratégie d'accès suivante accorde des autorisations de lecture et d'écriture pour accéder à un préfixe spécifique « folder » d'un compartiment S3 en mappant le préfixe à la variable ${cognito-identity.amazonaws.com:sub}.

Avec cette stratégie, une identité telle que us-east-1:12345678-1234-1234-1234-123456790ab insérée via ${cognito-identity.amazonaws.com:sub} est en mesure d'obtenir, de placer et de répertorier des objets dans arn:aws:s3:::amzn-s3-demo-bucket/us-east-1:12345678-1234-1234-1234-123456790ab. Toutefois, l'identité ne se verra pas accorder l'accès à d'autres objets dans arn:aws:s3:::amzn-s3-demo-bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["s3:ListBucket"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
      "Condition": {"StringLike": {"s3:prefix": ["${cognito-identity.amazonaws.com:sub}/*"]}}
    },
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/${cognito-identity.amazonaws.com:sub}/*"]
    }
  ]
}

Attribution à des identités d'un accès précis à Amazon DynamoDB

La stratégie d'accès suivante fournit un contrôle précis des accès aux ressources DynamoDB à l'aide de variables d'environnement Amazon Cognito. Ces variables accordent l'accès aux éléments dans DynamoDB par ID d'identité. Pour de plus amples informations, veuillez consulter Utilisation des conditions de politique IAM pour un contrôle précis des accès dans le Manuel du développeur Amazon DynamoDB.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:BatchGetItem",
        "dynamodb:Query",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-west-2:123456789012:table/MyTable"
      ],
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys":  ["${cognito-identity.amazonaws.com:sub}"]
        }
      }
    }
  ]
}

Octroi à une identité de l'autorisation d'invoquer une fonction Lambda

La stratégie d'accès suivante accorde à une identité l'autorisation d'invoquer une fonction Lambda.

{
    "Version": "2012-10-17",
    "Statement": [
         { 
             "Effect": "Allow",
             "Action": "lambda:InvokeFunction",
             "Resource": [
                 "arn:aws:lambda:us-west-2:123456789012:function:MyFunction"
             ]
         }
     ]
 }

Octroi à une identité de l'autorisation de publier des enregistrements dans Kinesis Data Streams

La stratégie d'accès suivante permet à une identité d'utiliser l'opération PutRecord avec n'importe lequel des Kinesis Data Streams. Elle peut être appliquée aux utilisateurs qui ont besoin d'ajouter des enregistrements de données à tous les flux d'un compte. Pour de plus amples informations, veuillez consulter Contrôle de l'accès aux ressources Amazon Kinesis Data Streams à l'aide d'IAM dans le Manuel du développeur Amazon Kinesis Data Streams.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "kinesis:PutRecord",
            "Resource": [
                "arn:aws:kinesis:us-east-1:111122223333:stream/stream1"
            ]
        }
    ]
}

Octroi à une identité de l'accès à ses données dans le magasin de synchronisation Amazon Cognito

La stratégie d'accès suivante accorde à une identité les autorisations d'accéder uniquement à ses propres données dans le magasin Amazon Cognito Sync.

{
  "Version": "2012-10-17",
  "Statement":[{
      "Effect":"Allow",
      "Action":"cognito-sync:*",
      "Resource":["arn:aws:cognito-sync:us-east-1:123456789012:identitypool/${cognito-identity.amazonaws.com:aud}/identity/${cognito-identity.amazonaws.com:sub}/*"]
      }]
  }

Autorisations et approbation de rôle

Ces rôles diffèrent au niveau de leurs relations d'approbation. Voici un exemple de stratégie d'approbation pour un rôle non authentifié :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "us-east-1:12345678-corner-cafe-123456790ab"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "unauthenticated"
        }
      }
    }
  ]
}

Cette stratégie autorise les utilisateurs fédérés à partir de cognito-identity.amazonaws.com (émetteur du jeton OpenID Connect) à assumer ce rôle. En outre, la politique restreint le paramètre aud du jeton (dans ce cas, l'ID du groupe d'identités) pour qu'il corresponde au groupe d'identités. Enfin, la politique spécifie que l'un des membres du tableau de la revendication amr de valeur multiple du jeton émis par l'opération API GetOpenIdToken Amazon Cognito possède la valeur unauthenticated.

Lorsque Amazon Cognito crée un jeton, le paramètre amr du jeton est défini comme unauthenticated ou authenticated. Si le paramètre amr est authenticated, le jeton inclut tous les fournisseurs utilisés au cours de l'authentification. Cela signifie que vous pouvez créer un rôle qui approuve uniquement les utilisateurs qui se sont connectés via Facebook en modifiant la condition amr comme indiqué :

"ForAnyValue:StringLike": {
  "cognito-identity.amazonaws.com:amr": "graph.facebook.com"
}

Soyez prudent lorsque vous modifiez les relations d'approbation de vos rôles ou lorsque vous essayez d'utiliser des rôles entre plusieurs groupes d'identités. Si vous ne configurez pas votre rôle correctement pour approuver votre groupe d'identités, il en résulte une exception STS similaire à la suivante :

AccessDenied -- Not authorized to perform sts:AssumeRoleWithWebIdentity

Si vous voyez ce message, vérifiez que votre groupe d'identités et votre type d'authentification disposent d'un rôle approprié.