の既知の問題 AWS Lake Formation

のこれらの既知の問題を確認します AWS Lake Formation。

テーブルメタデータのフィルタリングの制限

AWS Lake Formation 列レベルのアクセス許可を使用して、テーブル内の特定の列へのアクセスを制限できます。ユーザーがコンソールなどの を使用してテーブルに関するメタデータを取得するとAPIglue:GetTable、テーブルオブジェクトの列リストには、アクセスできるフィールドのみが含まれます。このメタデータフィルタリングの制限を理解しておくことが重要です。

Lake Formation は、統合サービスが列の許可に関するメタデータを利用できるようにしますが、クエリ応答内の列の実際のフィルタリングは統合サービスの責任になります。Amazon Athena、Amazon Redshift Spectrum、Amazon など、列レベルのフィルタリングをサポートする Lake Formation クライアントは、Lake Formation に登録された列のアクセス許可に基づいてデータをEMRフィルタリングします。ユーザーが、アクセス権を持つべきではないデータを読み取ることはできません。現在、AWS Glue ETL は列フィルタリングをサポートしていません。

注記

EMR クラスターは によって完全に管理されません AWS。したがって、データへの不正アクセスを避けるためにクラスターを適切に保護するのはEMR管理者の責任です。

特定のアプリケーションまたはフォーマットでは、列の名前やタイプなどの追加のメタデータが、テーブルのプロパティとして Parameters マップに保存される場合があります。これらのプロパティは変更されずに返され、いずれかの列に対して SELECT 許可を持っていれば、どのユーザーでもアクセスすることができます。

例えば、Avro SerDe はテーブルスキーマのJSON表現を という名前のテーブルプロパティに保存します。これはavro.schema.literal、テーブルにアクセスできるすべてのユーザーが使用できます。機密情報をテーブルプロパティに保存することは避け、ユーザーが Avro 形式のテーブルの完全なスキーマを把握できることに留意することが推奨されます。この制限は、テーブルに関するメタデータに固有のものです。

AWS Lake Formation は、発信者がテーブル内のすべての列に対するSELECTアクセス許可を持っていない場合、 glue:GetTableまたは同様のリクエストに応答spark.sql.sources.schemaするときに で始まるテーブルプロパティを削除します。これは、ユーザーが Apache Spark で作成されたテーブルに関する追加のメタデータにアクセスできないようにします。Amazon で実行してもEMR、Apache Spark アプリケーションはこれらのテーブルを読み取ることができますが、特定の最適化が適用されない可能性があり、大文字と小文字を区別する列名はサポートされていません。ユーザーがテーブル内のすべての列にアクセスできる場合、Lake Formation は、変更されていないテーブルをすべてのテーブルプロパティと共に返します。

除外された列の名前変更に関する問題

列レベルの許可を使用して列を除外してから列の名前を変更すると、その列は SELECT * などのクエリから除外されなくなります。

CSV テーブルの列の削除に関する問題

CSV 形式で Data Catalog テーブルを作成し、スキーマから列を削除すると、クエリが誤ったデータを返し、列レベルのアクセス許可が遵守されない可能性があります。

回避方法: その代わりに新しいテーブルを作成します。

テーブルパーティションを共通パスの下に追加する必要性

Lake Formation は、テーブルのすべてのパーティションが、テーブルの [location] (ロケーション) フィールドに設定されている共通のパスの下にあることを期待します。これは、クローラを使用してカタログにパーティションを追加する場合は問題なく機能しますが、パーティションを手動で追加し、これらのパーティションが親テーブルに設定されたロケーションの下にない場合はデータアクセスが機能しません。

ワークフロー作成時におけるデータベースの作成に関する問題

Lake Formation コンソールを使用してブループリントからワークフローを作成するときは、ターゲットデータベースが存在しなければ、それを作成することができます。これを実行するとき、作成されるデータベースに対する CREATE_TABLE 許可を取得するのは、サインインしているユーザーです。しかし、ワークフローが生成するクローラは、テーブルの作成試行時にワークフローのロールを引き受けます。このロールにはデータベースに対する CREATE_TABLE 許可がないことから、テーブルの作成は失敗します。

回避方法: ワークフローのセットアップ中にコンソールからデータベースを作成する場合は、ワークフローを実行する前に、作成したばかりのデータベースに対する CREATE_TABLE 許可をワークフローに関連付けられているロールに付与する必要があります。

ユーザーの削除後での再作成に関する問題

以下のシナリオは、lakeformation:ListPermissions によって返される誤った Lake Formation 許可の原因になります。

1. ユーザーを作成し、Lake Formation 許可を付与。

2. ユーザーを削除。

3. 同じ名前のユーザーを再度作成。

ListPermissions は、古いユーザー向けのエントリと、新しいユーザー向けのエントリの 2 つのエントリを返します。古いユーザーに付与された許可を取り消そうとすると、それらの許可は新しいユーザーからも取り消されます。

GetTables パラメータの値を更新SearchTablesAPIsしない IsRegisteredWithLakeFormation

GetTables や などの Data Catalog APIオペレーションは の値を更新SearchTablesせずIsRegisteredWithLakeFormation parameter、デフォルトである false を返すことには既知の制限があります。を使用して、 の正しい値GetTableAPIを表示することをお勧めしますIsRegisteredWithLakeFormation parameter。

Data Catalog APIオペレーションは IsRegisteredWithLakeFormationパラメータの値を更新しません

GetTables や などの Data Catalog APIオペレーションは、 IsRegisteredWithLakeFormationパラメータの値を更新SearchTablesせず、デフォルトの false を返します。IsRegisteredWithLakeFormation パラメータの正しい値を表示するにはGetTableAPI、 を使用することをお勧めします。

Lake Formation オペレーションは AWS Glue スキーマレジストリをサポートしていません

Lake Formation オペレーションは、スキーマレジスター で使用する StorageDescriptor SchemaReferenceの を含む AWS Glue テーブルをサポートしていません。