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.

IAMrôles

Lors de la création d'un pool d'identités, vous êtes invité à mettre à jour les IAM rôles assumés par vos utilisateurs. IAMles rôles fonctionnent comme suit : lorsqu'un utilisateur se connecte à votre application, Amazon Cognito génère des AWS informations d'identification temporaires pour l'utilisateur. Ces informations d'identification temporaires sont associées à un IAM rôle spécifique. Ce IAM rôle vous permet de définir un ensemble d'autorisations pour accéder à vos AWS ressources.

Vous pouvez définir IAM des rôles par défaut pour les utilisateurs authentifiés et non authentifiés. 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 IAM des rôles qui donnent accès à Amazon Mobile Analytics et à Amazon Cognito Sync. Vous pouvez également choisir d'utiliser les IAM rôles existants.

Modifiez IAM les rôles pour autoriser ou restreindre l'accès à d'autres services. Pour ce faire, connectez-vous à la IAM console. 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 en savoir plus sur l'utilisation et la définition des politiques, consultez la section Présentation des IAM politiques.

Configurer une politique d'approbation

Amazon Cognito utilise des IAM rôles 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 OIDC fournisseur, ou une SAML assertion, 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 de service fédéré cognito-identity.amazonaws.com d'appeler le AWS STS APIAssumeRoleWithWebIdentity. La demande n'aboutira que si le jeton du pool d'identités contenu dans la API demande comporte les revendications 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 IAM les rôles 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 des pools d'identités, IAM renvoie une 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 depuis des pools d'identités vers IAM des rôles 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 IAM rôle AWS STS si celui-ci dispose de la bonne politique de confiance. IAMles rôles des pools d'identités Amazon Cognito font confiance au principal du service cognito-identity.amazonaws.com pour assumer le rôle. Cette configuration n'est pas suffisante pour protéger vos IAM rôles 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 IAM rôle soit Compte AWS identique à celui 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 entre IAM 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 AssumeRoleWithWebIdentityAPIdemande, AWS STS vérifiez si le pool d'identités d'origine est Compte AWS identique au IAM rôle. 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 plus d'informations, voir Éléments IAM de politique : 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 IAM politique relatives à la fédération Web avec Amazon Cognito, consultez IAMet AWS STS conditionnez les clés de contexte dans le guide de l'AWS Identity and Access Management 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 délimitation ajoute un Politique de session en ligne et un AWS politique de session gérée aux IAM politiques que vous appliquez à votre rôle non authentifié. Étant donné que vous devez accorder l'accès à la fois dans IAM les politiques relatives à votre rôle et dans les politiques de session, la politique de délimitation limite l'accès des utilisateurs à des services autres que ceux figurant dans la liste ci-dessous.

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

En cas de demande réussie avec le flux amélioré, Amazon Cognito effectue une AssumeRoleWithWebIdentity API demande 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.

¹ Services AWS Dans le 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 IAM rôle 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 IAM rôle 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:*",
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "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 associez à votre rôle non authentifié. IAM Les autorisations effectives d'un utilisateur pour une session assumant un rôle se situent à l'intersection des IAM politiques 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*"
        ],
        "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 plus d'informations, consultez la section Utilisation des conditions de IAM politique pour un contrôle d'accès précis 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 plus d'informations, consultez la section Contrôle de l'accès aux ressources Amazon Kinesis Data Streams à IAM l'aide du guide 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 précise que l'un des membres du tableau de la amr réclamation à valeurs multiples du jeton émis par l'opération Amazon GetOpenIdToken API 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 correctement votre rôle pour faire confiance à votre pool d'STSidentités, une exception se produira, comme suit :

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é.