翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# の既知の問題 AWS Lake Formation
これらの既知の問題を確認します AWS Lake Formation。
**Topics**
+ [テーブルメタデータのフィルタリングの制限](#issue-table-metadata-avro)
+ [除外された列の名前変更に関する問題](#issue-rename-column)
+ [CSV テーブルの列の削除に関する問題](#issue-csv-schema)
+ [テーブルパーティションを共通パスの下に追加する必要性](#issue-table-partitions)
+ [ワークフロー作成時におけるデータベースの作成に関する問題](#issue-create-table-permission)
+ [ユーザーの削除後での再作成に関する問題](#issue-recreate-user)
+ [Data Catalog API 操作が `IsRegisteredWithLakeFormation` パラメータの値を更新しない](#issue-get-tables-parameter)
+ [Lake Formation オペレーションは AWS Glue スキーマレジストリをサポートしていません](#not-support-GlueSchemaRegistry.title)
## テーブルメタデータのフィルタリングの制限
AWS Lake Formation 列レベルのアクセス許可を使用して、テーブル内の特定の列へのアクセスを制限できます。ユーザーがコンソールや `glue:GetTable` のような API を使用してテーブルに関するメタデータを取得する場合、テーブルオブジェクトの列リストには、ユーザーがアクセスできるフィールドのみが含まれます。このメタデータフィルタリングの制限を理解しておくことが重要です。
Lake Formation は、統合サービスが列の許可に関するメタデータを利用できるようにしますが、クエリ応答内の列の実際のフィルタリングは統合サービスの責任になります。Amazon Athena、Amazon Redshift Spectrum、および Amazon EMR などの列レベルのフィルタリングをサポートする Lake Formation クライアントは、Lake Formation に登録された列の許可に基づいてデータをフィルタリングします。ユーザーが、アクセス権を持つべきではないデータを読み取ることはできません。現在、AWS Glue ETL は列フィルタリングをサポートしていません。
**注記**
EMR クラスターは、 AWSが完全に管理しているわけではありません。このため、データへの不正アクセスを回避するためのクラスターの適切なセキュア化は、EMR 管理者の責任になります。
特定のアプリケーションまたはフォーマットでは、列の名前やタイプなどの追加のメタデータが、テーブルのプロパティとして `Parameters` マップに保存される場合があります。これらのプロパティは変更されずに返され、いずれかの列に対して `SELECT` 許可を持っていれば、どのユーザーでもアクセスすることができます。
例えば、[Avro SerDe](https://docs.aws.amazon.com/athena/latest/ug/supported-serdes.html) は `avro.schema.literal` というテーブルプロパティにテーブルスキーマの JSON 表現を保存し、このテーブルにアクセスできるすべてのユーザーが利用できます。機密情報をテーブルプロパティに保存することは避け、ユーザーが Avro 形式のテーブルの完全なスキーマを把握できることに留意することが推奨されます。この制限は、テーブルに関するメタデータに固有のものです。
AWS Lake Formation 呼び出し元にテーブル内のすべての列に対する`SELECT`アクセス許可がない場合、 は、 `glue:GetTable`または同様のリクエストに応答`spark.sql.sources.schema`するときに で始まるテーブルプロパティを削除します。これは、ユーザーが Apache Spark で作成されたテーブルに関する追加のメタデータにアクセスできないようにします。Apache Spark アプリケーションは、Amazon EMR で実行しても引き続きこれらのテーブルを読み取ることができますが、特定の最適化が適用されない場合があり、大文字と小文字を区別する列名はサポートされません。ユーザーがテーブル内のすべての列にアクセスできる場合、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 許可を付与。
1. ユーザーを削除。
1. 同じ名前のユーザーを再度作成。
`ListPermissions` は、古いユーザー向けのエントリと、新しいユーザー向けのエントリの 2 つのエントリを返します。古いユーザーに付与された許可を取り消そうとすると、それらの許可は新しいユーザーからも取り消されます。
## Data Catalog API 操作が `IsRegisteredWithLakeFormation` パラメータの値を更新しない
`GetTables` および `SearchTables` などの Data Catalog API 操作が `IsRegisteredWithLakeFormation` パラメータの値を更新せず、デフォルト値の false を返すという既知の制限があります。`IsRegisteredWithLakeFormation` パラメータの正しい値を表示するには、`GetTable` API を使用することが推奨されます。
## Lake Formation オペレーションは AWS Glue スキーマレジストリをサポートしていません
Lake Formation オペレーションは、[スキーマレジスター](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)で使用する `StorageDescriptor` `SchemaReference`の を含む AWS Glue テーブルをサポートしていません。