5 listopada 2026 r. AWS opisała architekturę, w której roszczenie z Amazon Cognito wskazuje rolę IAM, a jej tymczasowe poświadczenia ograniczają zapytania Amazon Athena przez AWS Lake Formation. W usłudze dla wielu tenantów, czyli klientów korzystających z jednej aplikacji, uprawnienia są egzekwowane na ścieżce dostępu do danych. Tutorial AWS opisuje ten wzorzec z użyciem AgentCore Gateway, Cognito, Athena i Lake Formation.
Traktuj custom:team jako część granicy uprawnień: jego wartość wpływa na to, jaką rolę IAM otrzymuje użytkownik.
Od logowania do zapytania Athena
W przykładzie AWS użytkownik loguje się przez Cognito User Pools. W tokenie ID znajduje się roszczenie custom:team, czyli atrybut wskazujący zespół. Aplikacja przekazuje token dostępu i token ID do środowiska AgentCore; AgentCore Gateway weryfikuje token dostępu, a token ID przekazuje do docelowej funkcji Lambda w nagłówku X-ID-Token.
Reguły Cognito Identity Pool mapują wartość roszczenia na rolę IAM. W przykładzie Team A wskazuje rolę TeamA, a Team B rolę TeamB. Lambda wymienia token ID na tymczasowe poświadczenia tej roli. Athena wykonuje zapytanie z użyciem tych poświadczeń, a Lake Formation stosuje uprawnienia roli, tagi LF-Tag i filtry komórek danych.
Dlaczego Lambda pośredniczy w wymianie poświadczeń
Rola docelowej funkcji Lambda ma w przykładzie dwie wymienione akcje Cognito Identity: cognito-identity:GetId i cognito-identity:GetCredentialsForIdentity. Nie ma uprawnień do danych w Athena, S3 ani Glue. Funkcja pośredniczy w uzyskaniu poświadczeń; zapytanie wykonuje Athena z tymczasowymi poświadczeniami przypisanymi do użytkownika. Role zespołów mają własne uprawnienia do usług danych, które Lake Formation dodatkowo ogranicza.
To rozdzielenie wiąże dostęp z tożsamością użytkownika i rolą używaną do zapytania. Sama treść pytania do agenta nie zastępuje tych uprawnień.
Jakie ograniczenia danych pokazuje przykład?
AWS przypisuje tag LF-Tag TeamA do tabeli venue, TeamB do category, a shared do users. Tabela sales_extended ma osobne filtry wierszy dla zespołów. W opisywanym sprawdzeniu użytkownik Team A widzi tabelę venue, współdzieloną users i własne wiersze sprzedaży; użytkownik Team B widzi category, users i wiersze przypisane swojemu zespołowi.
Pokazana konfiguracja nie demonstruje izolacji kolumn: filtr wierszy ogranicza rekordy warunkiem team = 'Team A', a dostęp do kolumn obejmuje wszystkie kolumny.
W przykładzie atrybut custom:team jest zadeklarowany jako modyfikowalny i służy do wyboru roli. Z tego wynika praktyczna zależność: kontrola nad zmianą tego atrybutu należy do granicy autoryzacji, bo jego wartość wpływa na uprawnienia do danych. Zmiany powinny więc przechodzić przez zaufany proces administracyjny.
Użytkownicy zewnętrzni i opisane kontrole
AWS przedstawia Cognito User Pools i Identity Pools jako rozwiązanie dla użytkowników zewnętrznych, na przykład klientów aplikacji. Dla tożsamości pracowników opisuje odrębną ścieżkę: IAM Identity Center z Trusted Identity Propagation.
W ramach walidacji tutorial zaleca logowanie jako Team A i Team B, sprawdzenie widocznych tabel oraz porównanie wyników zapytań do sales_extended. Opisuje też zmianę tagu tabeli i filtra wierszy, a następnie ponowne sprawdzenie dostępu. AWS zaznacza, że zmiana uprawnień Lake Formation może rozchodzić się przez kilka minut.
