翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Lake Formation のトラブルシューティング
AWS Lake Formation の使用中に問題が発生した場合は、このセクションのトピックを参照してください。
**Topics**
+ [一般的なトラブルシューティング](#trouble-general)
+ [クロスアカウントアクセスのトラブルシューティング](#trouble-cross-account)
+ [ブループリントとワークフローのトラブルシューティング](#trouble-workflows)
+ [の既知の問題 AWS Lake Formation](limitations.md)
+ [エラーメッセージを更新しました](error-message-update.md)
## 一般的なトラブルシューティング
この情報を使用して、さまざまな Lake Formation 問題の診断と修正に役立ててください。
### エラー: Insufficient Lake Formation permissions on ( に対する Lake Formation 許可が不十分です)
Data Catalog リソースがポイントする Amazon S3 ロケーションに対するデータロケーション許可がないまま、そのリソースの作成または変更が試行されました。
Data Catalog データベースまたはテーブルが Amazon S3 のロケーションをポイントする場合は、Lake Formation の `CREATE_TABLE` または `ALTER` 許可を付与するときに、そのロケーションに対する `DATA_LOCATION_ACCESS` 許可も付与する必要があります。外部のアカウントまたは組織にこれらの許可を付与している場合は、grant オプションを含める必要があります。
これらの許可が外部アカウントに付与されたら、そのアカウントのデータレイク管理者は、アカウント内のプリンシパル (ユーザーまたはロール) に許可を付与する必要があります。別のアカウントから受け取った`DATA_LOCATION_ACCESS`アクセス許可を付与する場合は、所有者アカウントのカタログ ID (AWS アカウント ID) を指定する必要があります。所有者アカウントは、ロケーションを登録したアカウントです。
詳細については、「[基盤となるデータのアクセスコントロール](access-control-underlying-data.md)」および「[データロケーション許可の付与](granting-location-permissions.md)」を参照してください。
### エラー:「Insufficient encryption key permissions for Glue API」(Glue API の暗号化キー許可が不十分です)
暗号化されたデータカタログの AWS KMS 暗号化キーに対する AWS Identity and Access Management (IAM) アクセス許可のない Lake Formation アクセス許可を付与しようとしました。
### マニフェストを使用する自分のクエリ Amazon Athena または Amazon Redshift クエリが失敗している
Lake Formation は、マニフェストを使用するクエリをサポートしません。
### エラー:「Insufficient Lake Formation permission(s): Required create tag on catalog」(Lake Formation 許可が不十分です: カタログに対する必須の create タグ)
ユーザー/ロールは、データレイク管理者である必要があります。
### 無効なデータレイク管理者を削除するとエラーが発生します
無効なデータレイク管理者 (データレイク管理者として定義された削除済み IAM ロール) をすべて同時に削除する必要があります。無効なデータレイク管理者を個別に削除しようとすると、Lake Formation は無効なプリンシパルエラーをスローします。
## クロスアカウントアクセスのトラブルシューティング
この情報を使用して、クロスアカウントアクセス問題の診断と修正に役立ててください。
**Topics**
+ [クロスアカウント Lake Formation 許可を付与しましたが、受領者がリソースを表示できません](#troubleshooting-problem1)
+ [受領者アカウントのプリンシパルは、Data Catalog リソースを表示することはできますが、基盤となるデータにはアクセスできません。](#troubleshooting-problem11)
+ [エラー: AWS RAM リソース共有の招待を受け入れると、「発信者が承認されなかったため関連付けに失敗しました」](#troubleshooting-cross-acct-accepting)
+ [エラー:「Not authorized to grant permissions for the resource」(リソースの許可を付与する権限がありません)](#troubleshooting-problem2)
+ [エラー: AWS 「組織情報を取得するためのアクセスが拒否されました」](#troubleshooting-problem3)
+ [エラー:「Organization not found」(組織 が見つかりません)](#troubleshooting-problem4)
+ [エラー:「Insufficient Lake Formation permissions: Illegal combination」(Lake Formation 許可が不十分です: 不正な組み合わせ)](#troubleshooting-problem5)
+ [外部アカウントへのリクエストを許可/取り消ししたときに発生する ConcurrentModificationException](#troubleshooting-problem6)
+ [Amazon EMR を使用して、クロスアカウント経由で共有されたデータにアクセスする際のエラー](#toubleshooting-problem7)
### クロスアカウント Lake Formation 許可を付与しましたが、受領者がリソースを表示できません
+ 受領者アカウントのユーザーはデータレイク管理者ですか。共有時にリソースを表示できるのは、データレイク管理者のみです。
+ 名前付きリソース方式を使用して組織外のアカウントとの共有を行っていますか。その場合、受信者アカウントのデータレイク管理者は AWS Resource Access Manager () でリソース共有の招待を受け入れる必要がありますAWS RAM。
詳細については、「[からのリソース共有の招待の承諾 AWS RAM](accepting-ram-invite.md)」を参照してください。
+ AWS Glue でアカウントレベルの (Data Catalog) リソースポリシーを使用していますか。使用しているならば、名前付きリソース方式を使用する場合、 AWS RAM がユーザーに代わってポリシーを共有することを認可する特別なステートメントをポリシーに含める必要があります。
詳細については、「[AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](hybrid-cross-account.md)」を参照してください。
+ クロスアカウントアクセスを付与するために必要な AWS Identity and Access Management (IAM) アクセス許可はありますか?
詳細については、「[前提条件](cross-account-prereqs.md)」を参照してください。
+ 許可を付与したリソースには、`IAMAllowedPrincipals` グループに付与された Lake Formation 許可がない必要があります。
+ アカウントレベルポリシーに、リソースに対する `deny` ステートメントがありますか。
### 受領者アカウントのプリンシパルは、Data Catalog リソースを表示することはできますが、基盤となるデータにはアクセスできません。
受信者アカウントのプリンシパルには、必要な AWS Identity and Access Management (IAM) アクセス許可が必要です。詳細については、「[共有テーブルの基盤となるデータへのアクセス](cross-account-read-data.md)」を参照してください。
### エラー: AWS RAM リソース共有の招待を受け入れると、「発信者が承認されなかったため関連付けに失敗しました」
リソースへのアクセス権を別のアカウントに付与した後で、受領側アカウントがリソース共有招待を承諾しようとすると、アクションが失敗します。
```
$ aws ram get-resource-share-associations --association-type PRINCIPAL --resource-share-arns arn:aws:ram:aws-region:444444444444:resource-share/e1d1f4ba-xxxx-xxxx-xxxx-xxxxxxxx5d8d
{
"resourceShareAssociations": [
{
"resourceShareArn": "arn:aws:ram:aws-region:444444444444:resource-share/e1d1f4ba-xxxx-xxxx-xxxx-xxxxxxxx5d8d
",
"resourceShareName": "LakeFormation-MMCC0XQBH3Y",
"associatedEntity": "5815803XXXXX",
"associationType": "PRINCIPAL",
"status": "FAILED",
"statusMessage": "Association failed because the caller was not authorized.",
"creationTime": "2021-07-12T02:20:10.267000+00:00",
"lastUpdatedTime": "2021-07-12T02:20:51.830000+00:00",
"external": true
}
]
}
```
このエラーは、受領側アカウントがリソース共有招待を承諾するときに AWS Glue によって `glue:PutResourcePolicy` が呼び出されるために発生します。この問題を解決するには、プロデューサー/付与者アカウントによって使用される、引き受けられたロールによる `glue:PutResourcePolicy` アクションを許可します。
### エラー:「Not authorized to grant permissions for the resource」(リソースの許可を付与する権限がありません)
別のアカウントが所有するデータベースまたはテーブルに対するクロスアカウント許可の付与が試行されました。データベースまたはテーブルがアカウントと共有されている場合、データレイク管理者としてこれらに対する許可を付与できるのは、アカウント内のユーザーのみです。
### エラー: AWS 「組織情報を取得するためのアクセスが拒否されました」
アカウントは AWS Organizations 管理アカウントであり、アカウントの組織単位などの組織情報を取得するために必要なアクセス許可がありません。
詳細については、「[Required permissions for cross-account grants](cross-account-prereqs.md#cross-account-permissions-needed)」を参照してください。
### エラー:「Organization not found」(組織 が見つかりません)
組織とのリソースの共有が試行されましたが、組織との共有が有効になっていません。組織とのリソース共有を有効にしてください。
詳細については、*AWS RAM 「 ユーザーガイド*」の[AWS 「組織との共有を有効にする](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」を参照してください。
### エラー:「Insufficient Lake Formation permissions: Illegal combination」(Lake Formation 許可が不十分です: 不正な組み合わせ)
リソースの `IAMAllowedPrincipals` グループに Lake Formation 許可が付与されているときに、ユーザーが Data Catalog リソースを共有しました。ユーザーは、リソースを共有する前に `IAMAllowedPrincipals` からすべての Lake Formation 許可を取り消す必要があります。
### 外部アカウントへのリクエストを許可/取り消ししたときに発生する ConcurrentModificationException
ユーザーが LF タグポリシーのプリンシパルに対する許可リクエストを複数同時に許可または取り消すと、Lake Formation は ConcurrentModificationException をスローします。ユーザーはこの例外を捕捉し、失敗した許可/取り消しリクエストを再試行する必要があります。バッチバージョンの `GrantPermissions`/`RevokePermissions` API オペレーション ([BatchGrantPermissions](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_BatchGrantPermissions.html) および [BatchRevokePermissions](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_BatchRevokePermissions.html)) を使用すると、同時許可/取り消しリクエストの数を減らすことで、この問題はある程度緩和されます。
### Amazon EMR を使用して、クロスアカウント経由で共有されたデータにアクセスする際のエラー
Amazon EMR を使用して他のアカウントから共有されているデータにアクセスすると、一部の Spark ライブラリは `Glue:GetUserDefinedFunctions` API オペレーションの呼び出しを試みます。 AWS RAM 管理アクセス許可のバージョン 1 および 2 はこのアクションをサポートしていないため、次のエラーメッセージが表示されます。
`"ERROR: User: arn:aws:sts::012345678901:assumed-role/my-spark-role/i-06ab8c2b59299508a is not authorized to perform: glue:GetUserDefinedFunctions on resource: arn:exampleCatalogResource because no resource-based policy allows the glue:GetUserDefinedFunctions action"`
このエラーを解決するには、リソース共有を作成したデータレイク管理者が、リソース共有にアタッチされた AWS RAM マネージドアクセス許可を更新する必要があります。 AWS RAM マネージドアクセス許可のバージョン 3 では、プリンシパルが `glue:GetUserDefinedFunctions` アクションを実行できます。
新しいリソース共有を作成すると、Lake Formation はデフォルトで AWS RAM マネージドアクセス許可の最新バージョンを適用します。ユーザーによるアクションは必要ありません。既存のリソース共有のクロスアカウントデータアクセスを有効にするには、 AWS RAM マネージドアクセス許可をバージョン 3 に更新する必要があります。
で共有されているリソースに割り当てられた AWS RAM アクセス許可を表示できます AWS RAM。バージョン 3 には次のアクセス許可が含まれています。
```
Databases
AWSRAMPermissionGlueDatabaseReadWriteForCatalog
AWSRAMPermissionGlueDatabaseReadWrite
Tables
AWSRAMPermissionGlueTableReadWriteForCatalog
AWSRAMPermissionGlueTableReadWriteForDatabase
AllTables
AWSRAMPermissionGlueAllTablesReadWriteForCatalog
AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```
**既存のリソース共有の AWS RAM マネージドアクセス許可バージョンを更新するには**
ユーザー (データレイク管理者) は、*AWS RAM 「 ユーザーガイド*」の手順に従って[AWS RAM 管理アクセス許可を新しいバージョンに更新](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-update-permissions.html)するか、リソースタイプの既存のアクセス許可をすべて取り消して再付与することができます。アクセス許可を取り消すと、 は AWS RAM リソースタイプに関連付けられたリソース共有 AWS RAM を削除します。アクセス許可を再付与すると、 AWS RAM は AWS RAM マネージドアクセス許可の最新バージョンをアタッチした新しいリソース共有を作成します。
## ブループリントとワークフローのトラブルシューティング
この情報を使用して、ブループリントとワークフローの問題の診断と修正に役立ててください。
**Topics**
+ [ブループリントが「User: is not authorized to perform: iam:PassRole on resource: 」(ユーザー: にはリソース: で iam:PassRole を実行する許可がありません) エラーで失敗しました](#problem-bp-1)
+ [ワークフローが「User: is not authorized to perform: iam:PassRole on resource: 」(ユーザー: にはリソース: で iam:PassRole を実行する許可がありません) エラーで失敗しました](#problem-bp-2)
+ [ワークフローのクローラが「Resource does not exist or requester is not authorized to access requested permissions」(リソースが存在しないかリクエストされた認可にアクセスする権限がリクエスト元にありません) エラーで失敗しました](#problem-bp-3)
+ [ワークフローのクローラが「An error occurred (AccessDeniedException) when calling the CreateTable operation...」(CreateTable 操作の呼び出し時にエラーが発生しました (AccessDeniedException)) で失敗しました](#problem-bp-4)
### ブループリントが「User: is not authorized to perform: iam:PassRole on resource: 」(ユーザー: にはリソース: で iam:PassRole を実行する許可がありません) エラーで失敗しました
選択されたロールを渡すために十分な許可を持たないユーザーによって、ブループリントの作成が試行されました。
ロールを渡すことができるようにユーザーの IAM ポリシーを更新するか、必要な PassRole 許可を持つ異なるロールを選択することをユーザーに依頼してください。
詳細については、「[Lake Formation のペルソナと IAM 許可のリファレンス](permissions-reference.md)」を参照してください。
### ワークフローが「User: is not authorized to perform: iam:PassRole on resource: 」(ユーザー: にはリソース: で iam:PassRole を実行する許可がありません) エラーで失敗しました
ワークフローに指定したロールに、ロールがそれ自体を渡すことを許可するインラインポリシーがありませんでした。
詳細については、「[(オプション) ワークフロー用の IAM ロールを作成する](initial-lf-config.md#iam-create-blueprint-role)」を参照してください。
### ワークフローのクローラが「Resource does not exist or requester is not authorized to access requested permissions」(リソースが存在しないかリクエストされた認可にアクセスする権限がリクエスト元にありません) エラーで失敗しました
原因の 1 つとして、渡されたロールがターゲットデータベースにテーブルを作成するために十分な許可を持っていなかったことが考えられます。データベースに対する `CREATE_TABLE` 許可をロールに付与してください。
### ワークフローのクローラが「An error occurred (AccessDeniedException) when calling the CreateTable operation...」(CreateTable 操作の呼び出し時にエラーが発生しました (AccessDeniedException)) で失敗しました
原因の 1 つとして、ワークフローロールがターゲットストレージロケーションに対するデータロケーション許可を持っていなかったことが考えられます。データロケーション許可をロールに付与してください。
詳細については、「[`DATA_LOCATION_ACCESS`](lf-permissions-reference.md#perm-location)」を参照してください。
# の既知の問題 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 Schema Registry をサポートしていません](#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 Schema Registry をサポートしていません
Lake Formation オペレーションは、[スキーマレジスター](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)で使用する `StorageDescriptor` `SchemaReference`に を含む AWS Glue テーブルをサポートしていません。
# エラーメッセージを更新しました
AWS Lake Formation は、セキュリティおよびコンプライアンスの目的を達成するために、以下の API オペレーションのリソース固有の例外を一般的な`EntityNotFound`エラーメッセージに更新しました。
+ RevokePermissions
+ GrantPermissions
+ GetResourceLFTags
+ GetTable
+ GetDatabase