Überlegungen und Einschränkungen bei der Verwendung von Athena zum Abfragen von bei Lake Formation registrierten Daten

Beachten Sie Folgendes, wenn Sie Athena verwenden, um in Lake Formation registrierte Daten abzufragen. Weitere Informationen finden Sie unter Bekannte Probleme für AWS Lake Formation im AWS Lake Formation -Entwicklerhandbuch.

Spaltenmetadaten sind bei Avro und Benutzerdefiniert unter bestimmten Umständen für nicht autorisierte Benutzer sichtbar SerDe

Die Autorisierung auf Lake-Formation-Spaltenebene verhindert, dass ein Benutzer auf Daten in Spalten zugreift, für die er keine Lake-Formation-Berechtigungen besitzt. In bestimmten Situationen können Benutzer jedoch auf Metadaten zugreifen, die alle Spalten in der Tabelle beschreiben, einschließlich der Spalten, für deren Daten sie keine Berechtigungen besitzen.

Dies tritt auf, wenn Spaltenmetadaten in Tabelleneigenschaften für Tabellen gespeichert werden, die entweder das Apache Avro-Speicherformat oder einen benutzerdefinierten Serializer/Deserializer (SerDe) verwenden, in dem das Tabellenschema zusammen mit der Definition in den Tabelleneigenschaften definiert ist. SerDe Wenn Sie Athena mit Lake Formation verwenden, empfehlen wir, den Inhalt der Tabelleneigenschaften zu überprüfen, die Sie in Lake Formation registrieren, und nach Möglichkeit die in den Tabelleneigenschaften gespeicherten Informationen zu begrenzen, um zu verhindern, dass vertrauliche Metadaten für Benutzer sichtbar sind.

Arbeiten mit Lake-Formation-Berechtigungen für Ansichten

Für bei Lake Formation registrierte Daten kann ein Athena-Benutzer nur dann ein VIEW erstellen, wenn er über Lake-Formation-Berechtigungen für die Tabellen, Spalten und Amazon-S3-Quelldatenspeicherorte verfügt, auf denen VIEW basiert. Nachdem ein VIEW in Athena erstellt wurde, können die Berechtigungen für Lake Formation auf das VIEW angewendet werden. Berechtigungen auf Spaltenebene sind für einen VIEW nicht verfügbar. Benutzer mit Lake-Formation-Berechtigungen für einen VIEW aber ohne Berechtigungen für die Tabelle und Spalten, auf denen die Ansicht basiert, können den VIEW nicht zur Datenabfrage verwenden. Benutzer mit dieser Berechtigungskombination können jedoch Anweisungen wie DESCRIBE VIEW, SHOW CREATE VIEW und SHOW COLUMNS verwenden, um VIEW-Metadaten anzuzeigen. Stellen Sie daher sicher, dass Sie die Lake-Formation-Berechtigungen für jeden VIEW an den zugrunde liegenden Tabellenberechtigungen ausrichten. Zellfilter, die für eine Tabelle definiert sind, gelten nicht für einen VIEW für diese Tabelle. Die Namen der Ressourcenlinks müssen den gleichen Namen wie die Ressource im Ausgangskonto haben. Bei der Arbeit mit Ansichten in einer kontoübergreifenden Konfiguration gibt es zusätzliche Einschränkungen. Weitere Informationen zum Einrichten von Berechtigungen für freigegebene Ansichten über Konten hinweg finden Sie unter Kontoübergreifender Zugriff auf den Datenkatalog.

Differenzierte Zugriffskontrolle von Lake Formation und Athena-Arbeitsgruppen

Benutzer in derselben Athena-Arbeitsgruppe können die Daten anzeigen, die die differenzierte Zugriffskontrolle von Lake Formation so konfiguriert hat, dass sie für die Arbeitsgruppe zugänglich sind. Weitere Informationen zur Verwendung der differenzierten Zugriffskontrolle in Lake Formation finden Sie unter Verwaltung der differenzierten Zugriffskontrolle mithilfe von AWS Lake Formation im AWS -Big-Data-Blog.

Athena-Abfrageergebnisse-Speicherort in Amazon S3 nicht bei Lake Formation registriert

Die Abfrageergebnisorte in Amazon S3 für Athena können nicht bei Lake Formation registriert werden. Lake-Formation-Berechtigungen beschränken den Zugriff auf diese Standorte nicht. Wenn Sie den Zugriff nicht einschränken, können Athena-Benutzer auf Abfrageergebnisdateien und Metadaten zugreifen, wenn sie keine Lake-Formation-Berechtigungen für die Daten haben. Um dies zu vermeiden, sollten Sie Arbeitsgruppen verwenden, um den Speicherort für Abfrageergebnisse anzugeben und die Arbeitsgruppenmitgliedschaft mit den Lake-Formation-Berechtigungen auszurichten. Anschließend können Sie IAM-Berechtigungsrichtlinien verwenden, um den Zugriff auf Abfrageergebnisspeicherorte zu beschränken. Weitere Informationen zu Abfrageergebnissen finden Sie unter Arbeiten mit Abfrageergebnissen, letzten Abfragen und Ausgabedateien.

Verwenden von Athena-Workgroups zum Einschränken des Zugriffs auf den Abfrageverlauf

Der Abfrageverlauf von Athena stellt eine Liste gespeicherter Abfragen und vollständiger Abfragezeichenfolgen bereit. Sofern Sie nicht Arbeitsgruppen verwenden, um den Zugriff auf Abfrageverläufe zu trennen, können Athena-Benutzer, die nicht zum Abfragen von Daten in Lake Formation berechtigt sind, Abfragezeichenfolgen anzeigen, die für diese Daten ausgeführt werden, einschließlich Spaltennamen, Auswahlkriterien usw. Es wird empfohlen, Arbeitsgruppen zu verwenden, um Abfrageverläufe zu trennen und Athena-Arbeitsgruppenmitgliedschaft mit Lake-Formation-Berechtigungen auszurichten, um den Zugriff zu beschränken. Weitere Informationen finden Sie unter Verwendung von Arbeitsgruppen zur Kontrolle des Abfragenzugriffs und der Kosten.

Kontoübergreifender Zugriff auf den Datenkatalog

Um auf einen Datenkatalog in einem anderen Konto zuzugreifen, können Sie das kontenübergreifende AWS Glue -Feature von Athena verwenden oder den kontenübergreifenden Zugriff in Lake Formation einrichten.

Kontoübergreifender Athena-Datenkatalog-Zugriff

Sie können die kontoübergreifende Katalogfunktion von Athena verwenden, um den AWS Glue Katalog in Ihrem Konto zu registrieren. Diese Funktion ist nur in Athena-Engine-Version 2 und späteren Versionen verfügbar und auf die Verwendung in derselben Region zwischen Konten beschränkt. Weitere Informationen finden Sie unter Ein Konto AWS Glue Data Catalog von einem anderen Konto aus registrieren.

Wenn für den Datenkatalog, der gemeinsam genutzt werden soll, eine Ressourcenrichtlinie konfiguriert ist AWS Glue, muss diese aktualisiert werden, um Zugriff auf die zu gewähren AWS Resource Access Manager und Konto B die Berechtigungen zur Nutzung des Datenkatalogs von Konto A zu gewähren, wie im folgenden Beispiel.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "Service": "ram.amazonaws.com"
        },
        "Action": "glue:ShareResource",
        "Resource": [
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:table/*/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:database/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:catalog"
        ]
    }, 
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::<ACCOUNT-B>:root"
        },
        "Action": "glue:*",
        "Resource": [
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:table/*/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:database/*", 
          "arn:aws:glue:<REGION>:<ACCOUNT-A>:catalog"
        ]
    }
    ]
}

Weitere Informationen finden Sie unter Kontoübergreifender Zugriff auf AWS Glue -Datenkataloge.

Einrichten des kontoübergreifenden Zugriffs in Lake Formation

AWS Lake Formation ermöglicht die Verwendung eines einzigen Kontos zur Verwaltung eines zentralen Datenkatalogs. Sie können dieses Feature verwenden, um den kontoübergreifenden Zugriff auf Datenkatalog-Metadaten und zugrunde liegende Daten zu implementieren. Beispielsweise kann ein Besitzerkonto einem anderen (Empfänger-)Konto SELECT die Berechtigung für eine Tabelle erteilen.

Damit eine freigegebene Datenbank oder Tabelle im Athena-Abfrage-Editor angezeigt wird, erstellen Sie in Lake Formation einen Ressourcenlink zur freigegebenen Datenbank oder Tabelle. Wenn das Empfängerkonto in Lake Formation die Tabelle des Besitzers abfragt, wird das Datenzugriffsereignis den Protokollen sowohl für das Empfängerkonto als auch für das Besitzerkonto CloudTrailhinzugefügt.

Beachten Sie bei freigegebenen Ansichten die folgenden Punkte:

• Abfragen werden auf Zielressourcen-Links ausgeführt, nicht in der Quelltabelle oder -Ansicht, und dann wird die Ausgabe für das Zielkonto freigegeben.

• Es reicht nicht aus, nur die Ansicht zu teilen. Alle Tabellen, die an der Erstellung der Ansicht beteiligt sind, müssen Teil der kontoübergreifenden Freigabe sein.

• Der Name des auf den freigegebenen Ressourcen erstellten Ressourcenlinks muss mit dem Namen der Ressource im Eigentümerkonto übereinstimmen. Wenn der Name nicht übereinstimmt, wird eine Fehlermeldung wie Fehler beim Analysieren der gespeicherten Ansicht 'awsdatacatalog' angezeigt. my-lf-resource-link. my-lf-view': Zeile 3:3: Schema schema_name existiert nicht tritt auf.

Weitere Informationen zum kontenübergreifenden Zugriff in Lake Formation finden Sie in den folgenden Ressourcen im AWS Lake Formation -Entwicklerhandbuch:

Kontenübergreifender Zugriff

Funktionsweise von Ressourcenverbindungen in Lake Formation

CloudTrail Kontoübergreifende Protokollierung

Mit CSE-KMS verschlüsselte Amazon S3 S3-Standorte, die bei Lake Formation registriert sind

OTF-Tabellen (Open Table Format) wie Apache Iceberg, die die folgenden Eigenschaften aufweisen, können mit Athena nicht abgefragt werden:

• Die Tabellen basieren auf Amazon S3 S3-Datenstandorten, die bei Lake Formation registriert sind.

• Die Objekte in Amazon S3 werden mit clientseitiger Verschlüsselung (CSE) verschlüsselt.

• Die Verschlüsselung verwendet vom AWS KMS Kunden verwaltete Schlüssel (). CSE_KMS

Um Nicht-OTF-Tabellen abzufragen, die mit einem CSE_KMS Schlüssel verschlüsselt sind, fügen Sie der Richtlinie des AWS KMS Schlüssels, den Sie für die CSE-Verschlüsselung verwenden, den folgenden Block hinzu. <KMS_KEY_ARN>ist der ARN des AWS KMS Schlüssels, der die Daten verschlüsselt. <IAM-ROLE-ARN>ist der ARN der IAM-Rolle, die den Amazon S3 S3-Standort in Lake Formation registriert.

{
    "Sid": "Allow use of the key",
    "Effect": "Allow",
    "Principal": {
        "AWS": "*"
    },
    "Action": "kms:Decrypt",
    "Resource": "<KMS-KEY-ARN>",
    "Condition": {
        "ArnLike": {
            "aws:PrincipalArn": "<IAM-ROLE-ARN>"
        }
    }
}

Speicherorte für partitionierte Daten, die bei Lake Formation registriert sind, müssen sich in Tabellen-Unterverzeichnissen befinden

Bei Lake Formation registrierte partitionierte Tabellen müssen über partitionierte Daten in Verzeichnissen verfügen, die Unterverzeichnisse der Tabelle in Amazon S3 sind. Beispielsweise kann eine Tabelle mit dem Speicherort s3://DOC-EXAMPLE-BUCKET/mytable und den Partitionen s3://DOC-EXAMPLE-BUCKET/mytable/dt=2019-07-11, s3://DOC-EXAMPLE-BUCKET/mytable/dt=2019-07-12 usw. in Lake Formation registriert und mit Athena abgefragt werden. Andererseits kann eine Tabelle mit dem Speicherort s3://DOC-EXAMPLE-BUCKET/mytable und Partitionen in s3://DOC-EXAMPLE-BUCKET/dt=2019-07-11, s3://DOC-EXAMPLE-BUCKET/dt=2019-07-12 usw. nicht in Lake Formation registriert werden. Da solche Partitionen keine Unterverzeichnisse von s3://DOC-EXAMPLE-BUCKET/mytable sind, können sie auch nicht von Athena gelesen werden.

Erstellen von CTAS (Table As Select)-Abfragen erfordern Amazon-S3-Schreibberechtigungen

Create Table As Statements (CTAS) erfordern Schreibzugriff auf den Amazon-S3-Speicherort von Tabellen. Um CTAS-Abfragen für bei Lake Formation registrierte Daten auszuführen, müssen Athena-Benutzer zusätzlich zu den entsprechenden Lake-Formation-Berechtigungen zum Lesen der Datenstandorte über IAM-Berechtigungen zum Schreiben in die Tabelle von Amazon-S3-Standorten verfügen. Weitere Informationen finden Sie unter Erstellen einer Tabelle aus Abfrageergebnissen (CTAS).

Die DESCRIBE-Berechtigung ist für die Standarddatenbank erforderlich

Die Lake-Formation-Berechtigung DESCRIBE ist für die default-Datenbank erforderlich. Der folgende AWS CLI Beispielbefehl erteilt dem Benutzer datalake_user1 im AWS Konto 111122223333 die DESCRIBE Berechtigung für die default Datenbank.

aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Database": {"Name":"default"}}

Weitere Informationen finden Sie in der Referenz zu Lake-Formation-Berechtigungen im AWS Lake Formation -Entwicklerhandbuch.