FinchRide uruchamia aplikację mobilną, która musi umożliwiać nieuwierzytelnionym użytkownikom przeglądanie publicznych treści w Amazon S3, a uwierzytelnionym użytkownikom zapisywanie osobistych preferencji w tabeli DynamoDB bezpośrednio z klienta. Zespół ds. bezpieczeństwa wymaga zasady najmniejszych uprawnień dla każdego użytkownika, bez dostarczania długoterminowych poświadczeń w aplikacji. Które podejście powinien zarekomendować architekt rozwiązań?

Prawidłowa odpowiedź wykorzystuje Amazon Cognito Identity Pools (pule tożsamości) do wymiany tożsamości użytkowników (uwierzytelnionych i nieuwierzytelnionych) na tymczasowe poświadczenia AWS. Cognito User Pools (pule użytkowników) służą do rejestracji i logowania. To podejście jest zgodne z zasadą najmniejszych uprawnień, ponieważ role IAM są konfigurowane dla obu typów użytkowników, a warunki polityki IAM, takie jak ${cognito-identity.amazonaws.com:sub}, pozwalają na precyzyjne określenie zakresu dostępu do S3 i DynamoDB dla każdej tożsamości, bez dostarczania długoterminowych poświadczeń. Pozostałe opcje są nieprawidłowe, ponieważ: Użycie tylko puli użytkowników Cognito i przekazywanie tokena ID w nagłówku autoryzacji nie jest standardowym sposobem na bezpośredni dostęp do S3 i DynamoDB, które oczekują poświadczeń AWS. Tworzenie API Gateway z backendem Lambda dodaje niepotrzebną warstwę pośredniczącą i zwiększa złożoność, podczas gdy Cognito Identity Pools oferują bezpośrednie rozwiązanie. Klucze API nie są mechanizmem autoryzacji dla S3/DynamoDB. Bezpośrednie wywoływanie STS AssumeRoleWithWebIdentity z aplikacji jest możliwe, ale Cognito Identity Pools upraszczają ten proces, zarządzając wymianą tokenów i dostarczaniem poświadczeń w bardziej zintegrowany sposób.