Bonnes pratiques de sécurité pour les groupes d'identités Amazon Cognito

Les pools d'identités Amazon Cognito fournissent des AWS informations d'identification temporaires pour votre application. Comptes AWS contiennent souvent à la fois les ressources dont les utilisateurs de votre application ont besoin et des ressources dorsales privées. Les IAM rôles et les politiques qui constituent les AWS informations d'identification peuvent accorder l'accès à n'importe laquelle de ces ressources.

La principale bonne pratique en matière de configuration du pool d'identités consiste à garantir que votre application peut effectuer le travail sans privilèges excessifs ou involontaires. Pour éviter toute mauvaise configuration de sécurité, consultez ces recommandations avant le lancement de chaque application que vous souhaitez mettre en production.

IAMmeilleures pratiques de configuration

Lorsqu'un invité ou un utilisateur authentifié lance une session dans votre application qui nécessite des informations d'identification du pool d'identités, votre application récupère les informations AWS d'identification temporaires pour un rôle. IAM Les informations d'identification peuvent concerner un rôle par défaut, un rôle choisi par les règles de la configuration de votre pool d'identités ou un rôle personnalisé choisi par votre application. Les autorisations attribuées à chaque rôle permettent à votre utilisateur d'accéder à vos AWS ressources.

Pour plus d'informations sur les IAM meilleures pratiques générales, consultez les IAM meilleures pratiques du Guide de AWS Identity and Access Management l'utilisateur.

Utiliser les conditions de la politique de confiance dans IAM les rôles

IAMexige que les rôles pour les pools d'identités soient soumis à au moins une condition de politique de confiance. Cette condition peut, par exemple, définir l'étendue du rôle pour les utilisateurs authentifiés uniquement. AWS STS exige également que les demandes d'authentification de base entre comptes soient soumises à deux conditions spécifiques : cognito-identity.amazonaws.com:aud etcognito-identity.amazonaws.com:amr. Il est recommandé d'appliquer ces deux conditions à tous les IAM rôles qui font confiance au principal du service des pools d'identitéscognito-identity.amazonaws.com.

• cognito-identity.amazonaws.com:aud: La réclamation AUD dans le jeton du pool d'identités doit correspondre à un ID de pool d'identités fiable.

• cognito-identity.amazonaws.com:amr: La réclamation amr contenue dans le jeton du pool d'identités doit être authentifiée ou non authentifiée. Avec cette condition, vous pouvez réserver l'accès à un rôle uniquement à des invités non authentifiés, ou uniquement à des utilisateurs authentifiés. Vous pouvez affiner davantage la valeur de cette condition pour restreindre le rôle aux utilisateurs d'un fournisseur spécifique, par exemplegraph.facebook.com.

L'exemple de politique de confiance des rôles suivant accorde l'accès à un rôle dans les conditions suivantes :

{
  "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:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

Éléments relatifs aux pools d'identités

• "Federated": "cognito-identity.amazonaws.com": Les utilisateurs doivent provenir d'un pool d'identités.

• "cognito-identity.amazonaws.com:aud": "us-east-1:a1b2c3d4-5678-90ab-cdef-example11111": Les utilisateurs doivent provenir du pool d'identités spécifiqueus-east-1:a1b2c3d4-5678-90ab-cdef-example11111.

• "cognito-identity.amazonaws.com:amr": "authenticated": Les utilisateurs doivent être authentifiés. Les utilisateurs invités ne peuvent pas assumer ce rôle.

Appliquer les autorisations du moindre privilège

Lorsque vous définissez des autorisations avec des IAM politiques d'accès authentifié ou d'accès invité, accordez uniquement les autorisations spécifiques requises pour effectuer des tâches spécifiques, ou les autorisations du moindre privilège. L'exemple de IAM politique suivant, lorsqu'il est appliqué à un rôle, accorde un accès en lecture seule à un seul fichier image dans un compartiment Amazon S3.

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

Bonnes pratiques en matière de configuration du pool d'identités

Les pools d'identités proposent des options flexibles pour la génération d' AWS informations d'identification. N'utilisez pas de raccourcis de conception lorsque votre application peut fonctionner avec les méthodes les plus sécurisées.

Comprenez les effets de l'accès des invités

L'accès invité non authentifié permet aux utilisateurs de récupérer des données auprès de vous Compte AWS avant de se connecter. Toute personne connaissant l'ID de votre pool d'identités peut demander des informations d'identification non authentifiées. L'identifiant de votre pool d'identités n'est pas une information confidentielle. Lorsque vous activez l'accès invité, les AWS autorisations que vous accordez aux sessions non authentifiées sont accessibles à tous.

Il est recommandé de laisser l'accès invité désactivé et de récupérer les ressources requises uniquement après l'authentification des utilisateurs. Si votre application nécessite l'accès aux ressources avant de vous connecter, prenez les précautions suivantes.

• Familiarisez-vous avec les limites automatiques imposées aux rôles non authentifiés.

• Surveillez et ajustez les autorisations de vos IAM rôles non authentifiés en fonction des besoins spécifiques de votre application.

• Accordez l'accès à des ressources spécifiques.

• Sécurisez la politique de confiance de votre rôle non authentifié IAM par défaut.

• Activez l'accès invité uniquement lorsque vous êtes sûr d'accorder les autorisations correspondant à votre IAM rôle à n'importe qui sur Internet.

Utiliser l'authentification améliorée par défaut

Avec l'authentification de base (classique), Amazon Cognito délègue la sélection du IAM rôle à votre application. En revanche, le flux amélioré utilise la logique centralisée de votre pool d'identités pour déterminer le IAM rôle. Il fournit également une sécurité supplémentaire pour les identités non authentifiées grâce à une politique de délimitation qui fixe une limite supérieure aux autorisations. IAM Le flux amélioré est le choix le plus sûr qui demande le moins d'efforts aux développeurs. Pour en savoir plus sur ces options, consultezFlux d'authentification des groupes d'identités.

Le flux de base peut exposer la logique côté client qui sous-tend la sélection des rôles et l'assemblage de la AWS STS API demande d'informations d'identification. Le flux amélioré masque à la fois la logique et la demande d'attribution de rôle qui sous-tendent l'automatisation du pool d'identités.

Lorsque vous configurez l'authentification de base, appliquez les IAM meilleures pratiques à vos IAM rôles et à leurs autorisations.

Utilisez les fournisseurs de développement en toute sécurité

Les identités authentifiées par les développeurs sont une fonctionnalité des pools d'identités pour les applications côté serveur. Les seules preuves d'authentification dont les pools d'identités ont besoin pour authentifier les développeurs sont les AWS informations d'identification d'un développeur de pool d'identités. Les pools d'identités n'imposent aucune restriction quant à la validité des identifiants développeur-fournisseur que vous présentez dans ce flux d'authentification.

Il est recommandé de n'implémenter des fournisseurs de développement que dans les conditions suivantes :

• Pour responsabiliser l'utilisation des informations d'identification authentifiées par le développeur, concevez le nom et les identifiants de votre fournisseur de développement de manière à indiquer la source d'authentification. olpPar exemple : "Logins" : {"MyCorp provider" : "[provider application ID]"}.

• Évitez les informations d'identification utilisateur de longue durée. Configurez votre client côté serveur pour demander des identités avec des rôles liés à un service, tels que des EC2profils d'instance et des rôles d'exécution Lambda.

• Évitez de mélanger des sources de confiance internes et externes dans le même pool d'identités. Ajoutez votre fournisseur de développement et vos fournisseurs d'authentification unique (SSO) dans des pools d'identités distincts.