FinchRide lance une application mobile qui doit permettre aux utilisateurs non authentifiés de parcourir le contenu public dans Amazon S3 et aux utilisateurs authentifiés d'enregistrer leurs préférences personnelles dans une table DynamoDB directement depuis le client. L'équipe de sécurité exige le principe du moindre privilège par utilisateur sans inclure de justificatifs d'identité à long terme dans l'application. Quelle approche l'architecte de solutions devrait-il recommander ?

L'option correcte utilise Amazon Cognito User Pools pour l'authentification des utilisateurs et Cognito Identity Pools pour échanger les identités authentifiées ou non authentifiées contre des informations d'identification AWS temporaires. Cela respecte le principe du moindre privilège en attribuant des rôles IAM distincts pour les utilisateurs authentifiés et non authentifiés, et en utilisant des conditions de politique IAM pour un contrôle d'accès granulaire. Cette approche évite les informations d'identification à long terme dans l'application. L'option "Utiliser uniquement un groupe d'utilisateurs Cognito..." est incorrecte car S3 et DynamoDB ne peuvent pas valider directement les JWT Cognito sans un service intermédiaire comme Identity Pools ou une fonction Lambda. L'option "Créer une API REST API Gateway..." est une solution valide mais introduit une complexité et des coûts supplémentaires pour un cas d'utilisation que Cognito Identity Pools gère nativement. L'option "Appeler STS AssumeRoleWithWebIdentity directement..." est moins sécurisée car elle expose potentiellement la logique d'échange de jetons côté client et ne gère pas nativement les utilisateurs non authentifiés de manière élégante comme Identity Pools.