AWS beschreibt ein Muster, bei dem Amazon Cognito einen externen Nutzer anhand des Anspruchs custom:team einer IAM-Rolle zuordnet. Mit deren temporären Zugangsdaten fragt Amazon Athena Daten ab; AWS Lake Formation begrenzt den Zugriff im Beispiel auf freigegebene Tabellen und passende Zeilen. Der praktische Kern: Die Mandantenzuordnung wird in der Identitäts- und Datenberechtigungskette verankert. AWS veröffentlichte die technische Anleitung zu AgentCore und Lake Formation am 5. November 2026.
Bei einer mandantenfähigen Datenabfrage muss die Nutzeridentität bis zu den Berechtigungen reichen, die Athena beim Zugriff auf die Daten verwendet.
Vom Login zur eingeschränkten Athena-Abfrage
Für externe Nutzer setzt AWS in diesem Beispiel auf Amazon Cognito User Pools und Identity Pools. Nach der Anmeldung enthält das ID-Token den Anspruch custom:team. Das Frontend übermittelt ID- und Zugriffstoken an die Laufzeitumgebung von Amazon Bedrock AgentCore. Der AgentCore Gateway prüft das Zugriffstoken mit einem JWT-Autorisierer und leitet das ID-Token im Header X-ID-Token an eine AWS-Lambda-Funktion weiter.
Die Regeln des Cognito Identity Pool ordnen den Wert des Anspruchs einer IAM-Rolle zu. AWS zeigt etwa, wie Team A auf die Rolle TeamA und Team B auf TeamB abgebildet wird. Die Lambda-Funktion tauscht das ID-Token über Cognito Identity gegen temporäre Zugangsdaten für die zugeordnete Rolle. Athena führt die Abfrage mit diesen nutzerbezogenen Zugangsdaten aus; Lake Formation prüft dabei die Berechtigungen und anwendbaren Filter.
Warum die Lambda als Berechtigungsvermittler dient
Die Target-Lambda vermittelt im Beispiel den Austausch der Cognito-Zugangsdaten. AWS führt in ihrer Ausführungsrolle die Aktionen cognito-identity:GetId und cognito-identity:GetCredentialsForIdentity auf. Zugriffsrechte für Athena, S3 oder Glue hat diese Lambda-Rolle laut AWS nicht. Die Datenabfrage läuft stattdessen mit den temporären Zugangsdaten der zugeordneten Teamrolle.
Diese Trennung ist wichtig für die Architektur: Der Dienst, der Token weiterreicht und Zugangsdaten beschafft, erhält nicht automatisch selbst die Datenrechte, mit denen Athena die Abfrage ausführt.
Was die Team-Regeln absichern
AWS verwendet im Beispiel die LF-Tag-Werte TeamA, TeamB und shared. Die Tabelle venue ist Team A zugeordnet, category Team B und users beiden Teams. Für sales_extended gelten teambezogene Zeilenfilter. Team A soll damit eigene Zeilen sowie venue und users sehen; Team B eigene Zeilen sowie category und users.
Der gezeigte Filter beschränkt Zeilen über den Ausdruck team = 'Team A'; die Einstellung für den Spaltenzugriff lautet „Access to all columns“. Die konkrete Konfiguration zeigt damit Tabellenberechtigungen und Zeilenfilter. Eine Spaltenbeschränkung gehört nicht zu den gezeigten Regeln.
Der Anspruch custom:team ist im Beispiel als änderbar deklariert und bestimmt mit, welche Rolle der Identity Pool auswählt. Daraus folgt eine sicherheitsrelevante Abhängigkeit: Wer den Anspruch ändern darf, kann die Mandantenzuordnung beeinflussen. Die Kontrolle über solche Änderungen ist deshalb Teil der Berechtigungsgrenze dieser Architektur.
AWS weist außerdem darauf hin, dass Änderungen an Lake-Formation-Berechtigungen mehrere Minuten bis zur Weitergabe benötigen können. Bei einer Prüfung sollten Änderungen daher nicht als sofort wirksam vorausgesetzt werden.
Externe Nutzer und die dokumentierten Prüfungen
AWS unterscheidet zwischen externen Nutzern und Beschäftigten: Für kundenorientierte Anwendungen beschreibt die Anleitung Cognito User Pools und Identity Pools. Für die Belegschaft nennt sie IAM Identity Center mit Trusted Identity Propagation.
Zur Prüfung der Mandantenregeln empfiehlt AWS, sich als Team A und Team B anzumelden, die sichtbaren Tabellen zu vergleichen und die Zeilen in sales_extended zu kontrollieren. Die Anleitung beschreibt außerdem eine Änderung am Tabellen-Tag und am Zeilenfilter von Team A, gefolgt von einer erneuten Prüfung der Zugriffe.
