翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Lake Formation でのクロスアカウントデータ共有 Lake Formation のクロスアカウント機能を使用すると、ユーザーは分散データレイクを複数の AWS 組織間で安全に共有したり AWS アカウント、別のアカウントの IAM プリンシパルと直接共有したりして、データカタログのメタデータと基盤となるデータにきめ細かなアクセスを提供したりできます。大企業は通常、複数の を使用します。これらのアカウントの多くは AWS アカウント、単一の によって管理されるデータレイクにアクセスする必要がある場合があります AWS アカウント。ユーザーおよび AWS Glue 抽出、変換、ロード (ETL) ジョブは、複数のアカウント間でテーブルをクエリおよび結合できますが、Lake Formation のテーブルレベルおよび列レベルのデータ保護を活用できます。 Data Catalog リソースに対する Lake Formation アクセス許可を外部アカウントまたは別のアカウントの IAM プリンシパルに直接付与すると、Lake Formation は AWS Resource Access Manager (AWS RAM) サービスを使用してリソースを共有します。付与対象アカウントが付与する側のアカウントと同じ組織内にある場合、付与対象アカウントはその共有リソースをただちに使用できるようになります。被付与者アカウントが同じ組織にない場合、 は被付与者アカウントにリソース付与を承認または拒否するための招待 AWS RAM を送信します。次に、共有リソースを使用できるようにするには、被付与者アカウントのデータレイク管理者が AWS RAM コンソールまたは AWS CLI を使用して招待を受け入れる必要があります。 Lake Formation は、ハイブリッドアクセスモードでの外部アカウントとの Data Catalog リソースの共有をサポートしています。ハイブリッドアクセスモードでは、 AWS Glue Data Catalog内のデータベースとテーブルの Lake Formation 許可を柔軟かつ選択的に有効にできます。
 ハイブリッドアクセスモードでは、他の既存のユーザーやワークロードのアクセス許可ポリシーを中断することなく、特定のユーザーのセットに Lake Formation 許可を設定できる増分パスが導入されました。 詳細については、「[ハイブリッドアクセスモード](hybrid-access-mode.md)」を参照してください。 **直接的なクロスアカウント共有** 許可されたプリンシパルは、外部アカウントの IAM プリンシパルとリソースを明示的に共有できます。この機能は、外部アカウントの誰がリソースにアクセスできるかをアカウント所有者が制御する場合に便利です。IAM プリンシパルが受け取るアクセス許可は、直接の付与とアカウントレベルの付与を組み合わせたもので、それらはプリンシパルにカスケードされます。アクセス許可の受領者のみが、直接クロスアカウント付与を表示できます。リソース共有を受け取るプリンシパルが、他のプリンシパルとリソースを共有することはできません。 **データカタログリソースを共有する方法** 単一の Lake Formation 付与操作で、以下の Data Catalog リソースに対するクロスアカウント許可を付与できます。 + 1 つのデータベース + 個々のテーブル (オプションで列フィルタリングを使用) + 選択された数個のテーブル + データベース内のすべてのテーブル (すべてのテーブルのワイルドカードを使用) データベースとテーブルを別の アカウントの別の AWS アカウント または IAM プリンシパルと共有するには、2 つのオプションがあります。 + Lake Formation のタグベースのアクセスコントロール (LF-TBAC) (推奨) Lake Formation のタグベースのアクセスコントロールは、属性に基づいて許可を定義する認可戦略です。タグベースのアクセスコントロールを使用して、Data Catalog リソース (データベース、テーブル、列) を外部の IAM プリンシパル、組織 AWS アカウント、組織単位 (OUs) と共有できます。これらの属性は、Lake Formation で LF タグと呼ばれています。詳細については、「[Lake Formation のタグベースのアクセスコントロールを使用したデータレイクの管理](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-dl-tutorial.html)」を参照してください。 **注記** クロスアカウント付与 AWS Resource Access Manager に使用する Data Catalog アクセス許可を付与する LF-TBAC メソッド。 Lake Formation では、LF-TBAC 方式を使用した Organizations および組織単位へのクロスアカウントアクセス許可の付与をサポートするようになりました。 この機能を有効にするには、**[クロスアカウントのバージョン設定]** を **[バージョン 3]** に更新する必要があります。 詳細については、「[クロスアカウントデータ共有のバージョン設定の更新](optimize-ram.md)」を参照してください。 + Lake Formation の名前付きリソース 名前付きリソース方式を使用した Lake Formation のクロスアカウントデータ共有では、外部、IAM プリンシパル AWS アカウント、組織、または組織単位に、データカタログテーブルとデータベースに対する許可オプションを使用して Lake Formation アクセス許可を付与できます。この付与操作は、これらのリソースを自動的に共有します。 **注記** Lake Formation 認証情報を使用して、 AWS Glue クローラが別のアカウントのデータストアにアクセスすることを許可することもできます。詳細については、「 AWS Glue デベロッパーガイド」の[「クロスアカウントクローリング](https://docs.aws.amazon.com/glue/latest/dg/crawler-configuration.html#cross-account-crawling)」を参照してください。 Athena や Amazon Redshift Spectrum などの統合されたサービスでは、クエリに共有リソースを含めることができるように、リソースリンクが必要になります。リソースリンクの詳細については、「[Lake Formation でのリソースリンクの仕組み](resource-links-about.md)」を参照してください。 考慮事項と制限事項については、「[クロスアカウントデータ共有のベストプラクティスと考慮事項](cross-account-notes.md)」を参照してください。 **Topics** + [前提条件](cross-account-prereqs.md) + [クロスアカウントデータ共有のバージョン設定の更新](optimize-ram.md) + [外部アカウントから AWS アカウント または IAM プリンシパル間で Data Catalog テーブルとデータベースを共有する](cross-account-data-share-steps.md) + [アカウントと共有されたデータベースまたはテーブルに対する許可の付与](regranting-shared-resources.md) + [リソースリンク許可の付与](granting-link-permissions.md) + [共有テーブルの基盤となるデータへのアクセス](cross-account-read-data.md) + [CloudTrail のクロスアカウントロギング](cross-account-logging.md) + [AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](hybrid-cross-account.md) + [GetResourceShares API 操作を使用したすべてのクロスアカウント付与の表示](cross-account-getresourcepolicies.md) **関連トピック** [Lake Formation 許可の概要](lf-permissions-overview.md) [共有 Data Catalog テーブルとデータベースへのアクセスと表示](viewing-shared-resources.md) [リソースリンクの作成](creating-resource-links.md) [クロスアカウントアクセスのトラブルシューティング](troubleshooting.md#trouble-cross-account) # 前提条件 AWS アカウントが Data Catalog リソース (カタログ、データベース、テーブル) を別のアカウントまたは別のアカウントのプリンシパルと共有する前に、およびアカウントと共有されているリソースにアクセスする前に、次の前提条件を満たす必要があります。 **クロスアカウントデータ共有の一般的な要件** + ハイブリッドアクセスモードでデータカタログのデータベースとテーブルを共有し、フェデレーティッドカタログでオブジェクトを共有するには、**[クロスアカウントバージョン設定]** を **[バージョン 4]** に更新する必要があります。 + Data Catalog リソースに対するクロスアカウント許可を付与する前に、そのリソースの `IAMAllowedPrincipals` グループからすべての Lake Formation 許可を取り消す必要があります。呼び出し元のプリンシパルがリソースにアクセスするためのクロスアカウント許可を持っていて、リソースに `IAMAllowedPrincipals` 許可がある場合、Lake Formation は `AccessDeniedException` をスローします。 この要件は、基盤となるデータロケーションを Lake Formation モードで登録する場合にのみ該当します。データロケーションをハイブリッドモードで登録すると、`IAMAllowedPrincipals` グループ許可が共有データベースまたはテーブルに存在することになる可能性があります。 + 共有する予定のテーブルが含まれるデータベースについては、新しいテーブルに `IAMAllowedPrincipals` への `Super` のデフォルト付与がないようにする必要があります。Lake Formation コンソールで、データベースを編集してオフにします。**このデータベースの新しいテーブルには IAM アクセスコントロールのみを使用する**か、次の AWS CLI コマンドを入力して、 をデータベースの名前`database`に置き換えます。基になるデータロケーションがハイブリッドアクセスモードで登録されている場合は、このデフォルト設定を変更する必要はありません。ハイブリッドアクセスモードでは、Lake Formation ではAmazon S3と IAM アクセス許可ポリシーを同じリソース AWS Glue に選択的に適用できます。 ``` aws glue update-database --name database --database-input '{"Name":"database","CreateTableDefaultPermissions":[]}' ``` + クロスアカウントアクセス許可を付与するには、付与者に AWS Glueおよび AWS RAM サービスに対する必要な AWS Identity and Access Management (IAM) アクセス許可が必要です。 AWS 管理ポリシーは、必要なアクセス許可`AWSLakeFormationCrossAccountManager`を付与します。 を使用してリソース共有を受信するアカウントのデータレイク管理者には、次の追加ポリシー AWS RAM が必要です。これにより、管理者は AWS RAM リソース共有の招待を受け入れることができます。また、管理者が組織とのリソース共有を有効にすることも可能にします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ram:AcceptResourceShareInvitation", "ram:RejectResourceShareInvitation", "ec2:DescribeAvailabilityZones", "ram:EnableSharingWithAwsOrganization" ], "Resource": "*" } ] } ``` ------ + Data Catalog リソースを AWS Organizations または組織単位と共有する場合は、 で組織との共有を有効にする必要があります AWS RAM。 組織との共有を有効にする方法については、*AWS RAM 「 ユーザーガイド*」の[AWS 「組織との共有を有効にする](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)」を参照してください。 組織との共有を有効にするには、`ram:EnableSharingWithAwsOrganization` 許可が必要です。 + 別のアカウントの IAM プリンシパルとリソースを直接共有するには、**[Cross account version settings]** (クロスアカウントバージョン設定) を **[Version 3]** (バージョン 3) に更新する必要があります。この設定は、**[Data catalog settings]** (データカタログ設定) ページにあります。**[Version 1]** (バージョン 1) を使用している場合は、設定を更新する手順「[クロスアカウントデータ共有のバージョン設定の更新](optimize-ram.md)」を参照してください。 + AWS Glue サービスマネージドキーで暗号化された Data Catalog リソースを別のアカウントと共有することはできません。共有できるのは、お客様の暗号化キーで暗号化された Data Catalog リソースのみです。リソース共有を受け取るアカウントには、オブジェクトを復号するための Data Catalog 暗号化キーに対する許可が必要です。 **LF-TBAC 要件を使用したクロスアカウントデータ共有** + Data Catalog リソースを AWS Organizations および組織単位 (OUs) と共有するには、**クロスアカウントバージョン設定**を**バージョン 3** 以上に更新する必要があります。 + Data Catalog リソースをバージョン 3 の**クロスアカウントバージョン設定**と共有するには、付与者はアカウントの AWS 管理ポリシー `AWSLakeFormationCrossAccountManager` で定義されている IAM アクセス許可を持っている必要があります。 + **[クロスアカウントのバージョン設定]** のバージョン 1 またはバージョン 2 を使用している場合、LF-TBAC を有効にする Data Catalog リソースポリシー (`glue:PutResourcePolicy`) が必要です。詳細については、「[AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](hybrid-cross-account.md)」を参照してください。 + 現在 AWS Glue Data Catalog リソースポリシーを使用しており、**[クロスアカウントバージョン設定]** のバージョン 3 を使用してクロスアカウント許可を付与したいという場合、[AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](hybrid-cross-account.md) セクションに示されているように `glue:PutResourcePolicy` API オペレーションを使用して Data Catalog 設定で `glue:ShareResource` 許可を付与する必要があります。AWS Glue Data Catalog リソースポリシー (バージョン 1 とバージョン 2 では `glue:PutResourcePolicy` の許可を使用) を使用してクロスアカウントアクセス付与を行わなかった場合、このポリシーは必要ありません。 ``` { "Effect": "Allow", "Action": [ "glue:ShareResource" ], "Principal": {"Service": [ "ram.amazonaws.com" ]}, "Resource": [ "arn:aws:glue:::table/*/*", "arn:aws:glue:::database/*", "arn:aws:glue:::catalog" ] } ``` + アカウントが AWS Glue データカタログリソースポリシーを使用してクロスアカウント共有を行っており、現在 AWS RAM を使用してリソースを共有するために名前付きリソースメソッドまたは LF-TBAC **[クロスアカウント設定]** バージョン 3 を使用してリソースを共有している場合は、`glue:PutResourcePolicy` API オペレーションを呼び出すときに引数 `EnableHybrid` を `'true'` に設定する必要があります。詳細については、「[AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](hybrid-cross-account.md)」を参照してください。 **共有リソースにアクセスする各アカウントで必要になるセットアップ** + リソースを共有する場合 AWS アカウント、共有リソースを表示するには、コンシューマーアカウントの少なくとも 1 人のユーザーがデータレイク管理者である必要があります。データレイク管理者の作成方法については、「[データレイク管理者を作成する](initial-lf-config.md#create-data-lake-admin)」を参照してください。 データレイク管理者は、共有リソースに対する Lake Formation 許可をアカウント内の他のプリンシパルに付与できます。他のプリンシパルは、データレイク管理者から共有リソースに対する許可を付与されるまで、そのリソースにアクセスできません。 + Athena や Redshift Spectrum などの統合されたサービスでは、クエリに共有リソースを含めることができるように、リソースリンクが必要になります。プリンシパルは、その Data Catalog に、別の AWS アカウントアカウントからの共有リソースへのリソースリンクを作成する必要があります。リソースリンクの詳細については、「[Lake Formation でのリソースリンクの仕組み](resource-links-about.md)」を参照してください。 + リソースを IAM プリンシパルと直接共有する場合、Athena を使用してテーブルをクエリする場合、プリンシパルはそのリソースリンクを作成する必要があります。リソースリンクを作成するには、プリンシパルは Lake Formation の `CREATE_TABLE` または `CREATE_DATABASE` アクセス許可と、`glue:CreateTable` または `glue:CreateDatabase` IAM アクセス許可が必要です。 プロデューサーアカウントが同じデータベース内の別のテーブルを同じプリンシパルまたは別のプリンシパルと共有している場合、そのプリンシパルはすぐにテーブルをクエリできます。 **注記** データレイク管理者と、データレイク管理者から許可が付与されたプリンシパルには、共有リソースがローカル (所有) リソースであるかのように Data Catalog に表示されます。抽出、変換、ロード (ETL) ジョブは、共有リソースの基盤となるデータにアクセスできます。 共有リソースについては、Lake Formation コンソールの **[Tables]** (テーブル) および **[Databases]** (データベース) ページに所有者のアカウント ID が表示されます。 共有リソースの基盤となるデータに対するアクセスが行われると、共有リソース受領者のアカウントと、リソース所有者のアカウントの両方で CloudTrail ログイベントが生成されます。CloudTrail イベントには、データにアクセスしたプリンシパルの ARN を含めることができますが、これは受領者アカウントがログにプリンシパル ARN を含めるようにオプトインする場合のみになります。詳細については、「[CloudTrail のクロスアカウントロギング](cross-account-logging.md)」を参照してください。 # クロスアカウントデータ共有のバージョン設定の更新 は、クロスアカウントデータ共有設定を随時 AWS Lake Formation 更新して、 AWS RAM 使用状況に加えられた変更を区別し、クロスアカウントデータ共有機能に加えられた更新をサポートします。Lake Formation がこれを行うと、**[Cross account version settings]** (クロスアカウントバージョン設定) の新しいバージョンが作成されます。 ## クロスアカウントバージョン設定の主な違い さまざまな **[Cross account version settings]** (クロスアカウントバージョン設定) でのクロスアカウントデータ共有の仕組みの詳細については、以下のセクションを参照してください。 **注記** 別のアカウントとデータを共有するには、付与者が `AWSLakeFormationCrossAccountManager` マネージド IAM ポリシーのアクセス許可を持っている必要があります。これがすべてのバージョン必須の前提条件です。 **[Cross account version settings]** (クロスアカウントバージョン設定) を更新しても、共有リソースに対する受信者のアクセス許可には影響しません。これは、バージョン 1 からバージョン 2、バージョン 2 からバージョン 3、バージョン 1 からバージョン 3 への更新の場合に適用されます。バージョンを更新する際は、以下の考慮事項を参照してください。 **バージョン 1** *名前付きリソースメソッド: *各クロスアカウント Lake Formation アクセス許可付与を 1 つの AWS RAM リソース共有にマッピングします。ユーザー (付与者ロールまたはプリンシパル) には追加のアクセス許可は必要ありません。 *LF-TBAC メソッド: *クロスアカウント Lake Formation アクセス許可の付与は、データの共有 AWS RAM に を使用しません。ユーザーには `glue:PutResourcePolicy` アクセス許可が必要です。 *バージョン更新のメリット: *初期バージョン - 該当しません *バージョンを更新する際の考慮事項: *初期バージョン - 該当しません **バージョン 2** *名前付きリソースメソッド: * 複数のクロスアカウントアクセス許可の付与を 1 つの AWS RAM リソース共有にマッピングすることで、 AWS RAM リソース共有の数を最適化します。ユーザーには、追加のアクセス許可は必要ありません。 *LF-TBAC メソッド: *クロスアカウント Lake Formation アクセス許可の付与は、データの共有 AWS RAM に を使用しません。ユーザーには `glue:PutResourcePolicy` アクセス許可が必要です。 *バージョンを更新するメリット: * AWS RAM 容量の最適な使用率によるスケーラブルなクロスアカウント設定。 *バージョンを更新する際の考慮事項: *クロスアカウント Lake Formation アクセス許可を付与するユーザーには、 `AWSLakeFormationCrossAccountManager` AWS マネージドポリシーの アクセス許可が必要です。それ以外の場合は、別のアカウントとリソースを正常に共有するための `ram:AssociateResourceShare` および `ram:DisassociateResourceShare` アクセス許可が必要です。 **バージョン 3** *名前付きリソースメソッド: * 複数のクロスアカウントアクセス許可の付与を 1 つの AWS RAM リソース共有にマッピングすることで、 AWS RAM リソース共有の数を最適化します。ユーザーには、追加のアクセス許可は必要ありません。 *LF-TBAC メソッド: * Lake Formation はクロスアカウント付与 AWS RAM に を使用します。ユーザーは `glue:PutResourcePolicy` アクセス許可に glue: ShareResource ステートメントを追加する必要があります。受信者は、 からのリソース共有の招待を受け入れる必要があります AWS RAM。 *バージョン更新のメリット: *次の機能をサポートします。 + 外部アカウントの IAM プリンシパルとリソースを明示的に共有できます。 詳細については、「[データカタログリソースに対するアクセス許可の付与](granting-catalog-permissions.md)」を参照してください。 + Organizations または組織単位 (OU) に対して、LF-TBAC 方式を使用したクロスアカウント共有を可能にします。 + クロスアカウント付与の追加 AWS Glue ポリシーを維持するオーバーヘッドを排除します。 *バージョンを更新する際の考慮事項:* LF-TBAC 方式を使用してリソースを共有する場合、付与者がバージョン 3 より前のバージョンを使用していて、受信者がバージョン 3 以降を使用していると、付与者に「Invalid cross account grant request. Consumer account has opt-in to cross account version: v3. Please update `CrossAccountVersion` in `DataLakeSetting` to minimal version v3 (Service: AmazonDataCatalog; Status Code: 400; Error Code: InvalidInputException)」というエラーメッセージが表示されます。ただし、付与者がバージョン 3 を使用していて、受信者がバージョン 1 またはバージョン 2 を使用している場合、LF タグを使用したクロスアカウント付与は正常に行われます。 名前付きリソース方式を使用したクロスアカウント付与は、異なるバージョン間で互換性があります。付与者アカウントが以前のバージョン (バージョン 1 または 2) を使用していて、受信者アカウントが新しいバージョン (バージョン 3 以降) を使用している場合でも、クロスアカウントアクセス機能は互換性の問題やエラーなしでシームレスに動作します。 リソースを別のアカウントの IAM プリンシパルと直接共有するには、付与者だけがバージョン 3 を使用する必要があります。 LF-TBAC 方式を使用してクロスアカウント付与を行うには、ユーザーがアカウントに AWS Glue Data Catalog リソースポリシーを持っている必要があります。バージョン 3 に更新すると、LF-TBAC は AWS RAMを使用して付与します。 AWS RAM ベースのクロスアカウント許可を成功させるには、 [AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理](hybrid-cross-account.md)セクションに示すように、 `glue:ShareResource`ステートメントを既存の Data Catalog リソースポリシーに追加する必要があります。 **バージョン 4** ハイブリッドアクセスモードでデータカタログリソースを共有したり、フェデレーティッドカタログ内のオブジェクトを共有したりするには、付与者にバージョン 4 以降が必要です。 **バージョン 5** クロスアカウントバージョン 5 では、クロスアカウントリソース共有が強化され、無制限の数のテーブルを別のアカウントと共有できるため、リソースタイプごとの以前のリソース関連付け制限がなくなります。開始するには、Lake Formation コンソールまたは API を使用してクロスアカウントバージョン 5 にアップグレードします。新しいクロスアカウントアクセス許可の付与では、個々のリソースの関連付けではなく、リソース共有でワイルドカードパターンが自動的に使用されます。既存のすべてのクロスアカウント共有は引き続き機能し、既存のすべての Lake Formation APIs互換性を維持します。 *バージョンを更新するメリット: *クロスアカウント v5 はクロスアカウント共有を強化し、アカウント間で数十万のテーブルを共有できるようにします。 *バージョンを更新する際の考慮事項: *バージョン 5 のアップグレード後の新しい権限では、既存の AWS Resource Manager リソース共有にワイルドカードリソースパターンが追加されるか、ワイルドカードパターンで新しい共有が作成されます。バージョン 5 にアップグレードすると、ダウングレードはサポートされません。 ## AWS RAM リソース共有の最適化 クロスアカウント付与の新しいバージョン (バージョン 2 以降) では、クロスアカウントの使用を最大化するために AWS RAM 容量が最適に活用されます。外部 AWS アカウント または IAM プリンシパルとリソースを共有すると、Lake Formation は新しいリソース共有を作成するか、リソースを既存の共有に関連付けることができます。Lake Formation は、既存の共有と関連付けることによって、コンシューマーが受け入れる必要があるリソース共有への招待数を減らします。バージョン 5 では、個々のリソースの関連付けの代わりにワイルドカードベースのリソースパターンを使用することで、RAM の使用がさらに最適化されるため、リソース共有あたりのリソースの関連付けが大幅に削減されます。 ## TBAC 経由で AWS RAM 共有を有効にするか、リソースをプリンシパルに直接共有する リソースを別のアカウントの IAM プリンシパルと直接共有するか、Organizations や組織単位との TBAC クロスアカウント共有を有効にするには、**[Cross account version settings]** (クロスアカウントバージョン設定) を [Version 3] (バージョン 3) に更新する必要があります。 AWS RAM リソース制限の詳細については、「」を参照してください[クロスアカウントデータ共有のベストプラクティスと考慮事項](cross-account-notes.md)。 ### クロスアカウントのバージョン設定の更新に必要なアクセス許可 クロスアカウント許可の付与者に `AWSLakeFormationCrossAccountManager` マネージド IAM ポリシーのアクセス許可がある場合、クロスアカウントアクセス許可の付与者ロールまたはプリンシパルに追加のアクセス許可設定は必要ありません。ただし、クロスアカウントの付与者がマネージドポリシーを使用していない場合、新しいバージョンのクロスアカウント付与を成功させるには、付与者ロールまたはプリンシパルに次の IAM 許可が付与されている必要があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "ram:AssociateResourceShare", "ram:DisassociateResourceShare", "ram:GetResourceShares" ], "Resource": "*", "Condition": { "StringLike": { "ram:ResourceShareName": "LakeFormation*" } } } ] } ``` ------ ## 新しいバージョンを有効にするには コンソールまたは を使用して**クロスアカウントバージョン設定**を更新するには、 AWS Lake Formation次の手順に従います AWS CLI。 ------ #### [ Console ] 1. **データカタログ****設定ページのクロスアカウントバージョン**設定で、**バージョン 2**、**バージョン 3**、**バージョン 4**、または**バージョン 5 **を選択します。**[Version 1]** (バージョン 1) を選択すると、Lake Formation はデフォルトのリソース共有モードを使用します。 ![\[画面には、アカウント内のすべての LF タグのアクセス許可が表示されます。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/cross-account-version-setting.png) 1. **[保存]** を選択します。 ------ #### [ AWS Command Line Interface (AWS CLI) ] `put-data-lake-settings` AWS CLI コマンドを使用して `CROSS_ACCOUNT_VERSION`パラメータを設定します。使用できる値は 1、2、3、4、5 です。 ``` aws lakeformation put-data-lake-settings --region us-east-1 --data-lake-settings file://settings { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam::111122223333:user/test" } ], "CreateDatabaseDefaultPermissions": [], "CreateTableDefaultPermissions": [], "Parameters": { "CROSS_ACCOUNT_VERSION": "3" } } ``` ------ **重要** **[Version 2]** (バージョン 2) または **[Version 3]** (バージョン 3) を選択すると、新しい**名前付きリソース**の付与はすべて新しいクロスアカウント付与モードになります。既存のクロスアカウント共有の AWS RAM 容量を最適に使用するには、古いバージョンで行われた許可を取り消し、新しいモードで再付与することをお勧めします。 # 外部アカウントから AWS アカウント または IAM プリンシパル間で Data Catalog テーブルとデータベースを共有する このセクションでは、Data Catalog リソースに対するクロスアカウントアクセス許可を外部 AWS アカウント、IAM プリンシパル、 AWS 組織、または組織単位に付与する方法について説明します。この付与操作は、これらのリソースを自動的に共有します。 **Topics** + [タグベースのアクセスコントロールを使用したデータ共有](cross-account-TBAC.md) + [名前付きリソース方式を使用したクロスアカウントデータ共有。](cross-account-named-resource.md) # タグベースのアクセスコントロールを使用したデータ共有 AWS Lake Formation タグベースのアクセスコントロール (LF-TBAC) は、属性に基づいてアクセス許可を定義する認可戦略です。以下の手順では、LF タグを使用してクロスアカウント許可を付与する方法を説明します。 **プロデューサー/付与者アカウントで必要なセットアップ** 1. LF タグを追加します。 1. Lake Formation コンソールにデータレイク管理者または LF タグ作成者としてサインインします。 1. ナビゲーションペインで、**[アクセス許可]** の **[LF タグとアクセス許可]** を選択します。 1. **[Add LF-Tag]** (LF タグを追加) を選択します。 LF タグの作成手順については、「[LF タグの作成](TBAC-creating-tags.md)」を参照してください。 1. 自分のカウントまたは外部アカウントの IAM プリンシパルに、**LF タグのキーと値**のペアの**記述**および/または**関連付け**のアクセス許可を付与します。 **LF タグのキーと値**のペアに対するアクセス許可を付与すると、プリンシパルは LF タグを表示し、それをデータカタログリソース (データベース、テーブル、列) に割り当てることができるようになります。 1. 次に、データレイク管理者または**関連付け**アクセス許可を持つ IAM プリンシパルは、データベース、テーブル、または列に LF タグを割り当てることができます。詳細については、「[Data Catalog リソースへの LF タグの割り当て](TBAC-assigning-tags.md)」を参照してください。 1. 次に、LF タグ式を使用して外部アカウントにデータアクセス許可を付与します。これにより、アクセス許可の被付与者または受領者は、同じキーと値でタグ付けされたデータカタログリソースにアクセスできます。 1. ナビゲーションペインの **[アクセス許可]** で **[データのアクセス許可]** を選択します。 1. **[付与]** を選択します。 1. **[アクセス許可の付与]** ページで、**[プリンシパル]** に **[外部アカウント]** を選択し、外部プリンシパルに直接クロスアカウント付与を行う場合は、プリンシパルの被付与者 AWS アカウント ID もしくは IAM ロール、またはプリンシパルの Amazon リソースネーム (ARN) (プリンシパル ARN) を入力します。アカウント ID を入力した後、**Enter** キーを押します。 ![\[外部アカウントと LF タグのキーと値のペアが指定されたアクセス許可の付与画面。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/cross-acct-grant-tags.png) 1. **[LF タグまたはカタログリソース]** で、**[LF タグに一致するリソース (推奨)]** を選択します。 1. オプションの **[LF タグのキーと値のペア]** または **[保存された LF タグ式]** を選択します。 1. ****[LF タグのキーと値のペア]** を選択した場合は**、被付与者アカウントと共有されているデータカタログリソースに関連付けられている **LF タグ**のキーと値を入力します。 被付与者には、LF タグ式で一致する LF タグが割り当てられたデータカタログリソースに対するアクセス許可が付与されます。LF タグ式がタグキーごとに複数の値を指定する場合、タグ値のいずれかを一致させることができます。 1. LF タグ式と一致するリソースに付与する、データベースレベルまたはテーブルレベルのアクセス許可を選択します。 **重要** データレイク管理者は、共有リソースに対するアクセス許可を被付与者アカウント内のプリンシパルに付与する必要があるため、クロスアカウントアクセス許可は、常に付与オプションと共に付与される必要があります。 詳細については、「[コンソールを使用した LF-Tag アクセス許可の付与](TBAC-granting-tags-console.md)」を参照してください。 **注記** クロスアカウント付与を直接受け取るプリンシパルには、**[Grantable permissions]** (付与可能なアクセス許可) オプションがありません。 **受信者側/被付与者アカウントで必要なセットアップ** 1. Lake Formation コンソールにデータレイク管理者としてサインインします。 1. 次に、コンシューマーアカウントでリソース共有を受け取ります。 1. AWS RAM コンソールを開きます。 1. ナビゲーションペインの **[自分と共有]**で、**[リソース共有]** を選択します。 1. リソース共有を選択し、**[リソース共有を受け入れる]** を選択します。 1. 別のアカウントとリソースを共有しても、そのリソースは引き続きプロデューサーアカウントに属し、Athena コンソール内には表示されません。リソースを Athena コンソールで表示するには、共有リソースを指すリソースリンクを作成する必要があります。リソースリンクの作成手順については、「[共有 Data Catalog テーブルへのリソースリンクの作成](create-resource-link-table.md)」および「[共有 Data Catalog データベースへのリソースリンクの作成](create-resource-link-database.md)」を参照してください。 1. データカタログで **[データベース]** または **[テーブル]** を選択します。 1. [データベース/テーブル] ページで、**作成]**、**[リソースリンク]** を選択します。 1. データベースリソースリンクに次の情報を入力します。 + **リソースリンク名** – リソースリンクの一意の名前。 + **送信先カタログ** – リソースリンクを作成するカタログ。 + **共有データベースのリージョン** - 別のリージョンでリソースリンクを作成する場合は、共有するベースのリージョン。 + **共有データベース** – 共有データベースを選択します。 + **共有データベースのカタログ ID** – 共有データベースのカタログ ID を入力します。 1. **[作成]** を選択します。新しく作成されたリソースリンクは、データベースリストに表示されます。 同様に、共有テーブルへのリソースリンクを作成できます。 1. ここで、リソースを共有する IAM プリンシパルへのリソースリンクに対する **記述**アクセス許可を付与します。 1. **[データベース/テーブル]**ページでリソースリンクを選択し、**[アクション]** メニューで、**[付与]** を選択します。 1. **[アクセス許可を付与]** セクションで、**[IAM ユーザーとロール]** を選択します。 1. リソースリンクへのアクセスを許可する IAM ロールを選択します。 1. **[リソースリンク]** のアクセス許可セクションで、**[記述]** を選択します。 1. **[付与]** を選択します。 1. 次に、コンシューマーアカウントのプリンシパルに **[LF タグのキーと値のアクセス許可]** を付与します。 共有されている LF タグは、Lake Formation コンソールのコンシューマーアカウントにある、**[アクセス許可]** の **[LF タグとアクセス許可]** で確認できます。付与者から共有されたタグを、データベース、テーブル、列を含む付与者アカウントから共有されたリソースに関連付けることができます。また、リソースに対するアクセス許可を他のプリンシパルに付与できます。 ![\[画面には、アカウントの LF タグのアクセス許可が表示されます。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/lf-tag-permissions.png) 1. ナビゲーションペインで、**[アクセス許可]**、**[データレイクのアクセス許可]** の順に移動し、**[付与]** を選択します。 1. **[アクセス許可の付与]** ページで、**[IAM ユーザーとロール]** を選択します。 1. 次に、アカウント内の IAM ユーザーとロールを選択して、共有データベース/テーブルへのアクセスを許可します。 1. **[LF タグまたはカタログリソース]** で、**[LF タグに一致するリソース]** を選択します。 1. 次に、共有されている LF タグのキーと値を選択します。 1. 次に、IAM ユーザーとロールに付与するデータベースとテーブルのアクセス許可を選択します。また、IAM ユーザーとロールが他のユーザー/ロールにアクセス許可を付与できるようにする **[付与可能なアクセス許可]** を選択することもできます。 1. **[付与]** を選択します。 1. Lake Formation コンソールの **[データのアクセス許可]** でアクセス許可の付与を表示できます。 # 名前付きリソース方式を使用したクロスアカウントデータ共有。 アクセス許可は、別の AWS アカウントのプリンシパル、または外部 AWS アカウント または に直接付与できます AWS Organizations。Lake Formation のアクセス許可を Organizations または組織単位に付与することは、その組織または組織単位 AWS アカウント のすべての にアクセス許可を付与することと同じです。 外部のアカウントまたは組織にアクセス許可を付与する場合は、**[Grantable permissions]** (付与可能なアクセス許可) オプションを含める必要があります。共有リソースにアクセスできるのは、外部アカウント内のデータレイク管理者が外部アカウント内の他のプリンシパルに共有リソースに対する許可を付与するまで、データレイク管理者のみになります。 **注記** 外部アカウントから IAM プリンシパルに直接アクセス許可を付与する場合、**[Grantable permissions]** (付与可能なアクセス許可) オプションはサポートされません。 「[名前付きリソース方式を使用したデータベースのアクセス許可の付与](granting-database-permissions.md)」の手順に従い、名前付きリソース方式を使用してクロスアカウント許可を付与します。 次の動画は、Lake Formation を使用して AWS 組織とデータを共有する方法を示しています。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/S-Mdcmq6oPM?controls=0&/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/S-Mdcmq6oPM?controls=0&) # アカウントと共有されたデータベースまたはテーブルに対する許可の付与 別の AWS アカウントに属する Data Catalog リソースがアカウント AWS と共有されると、データレイク管理者として、共有リソースに対するアクセス許可をアカウントの他のプリンシパルに付与できます。ただし、リソースに対する許可を他の AWS アカウントまたは組織に付与することはできません。 AWS Lake Formation コンソール、API、または AWS Command Line Interface (AWS CLI) を使用してアクセス許可を付与できます。 **共有データベースに対する許可を付与する (名前付きリソース方式、コンソール)** + 「[名前付きリソース方式を使用したデータベースのアクセス許可の付与](granting-database-permissions.md)」の手順を実行します。**[LF-Tags or catalog resources]** (LF タグまたはカタログリソース) の **[Database]** (データベース) リストでは、外部アカウントのデータベースを選択して、データベースのリソースリンクは選択しないようにしてください。 データベースのリストにデータベースが表示されない場合は、そのデータベースの AWS Resource Access Manager (AWS RAM) リソース共有招待を承諾していることを確認してください。詳細については、「[からのリソース共有の招待の承諾 AWS RAM](accepting-ram-invite.md)」を参照してください。 また、`CREATE_TABLE` および `ALTER` 許可については、「[データロケーション許可の付与 (同じアカウント)](granting-location-permissions-local.md)」の手順を実行し、**[Registered account location]** (登録されたアカウントのロケーション) に所有側のアカウント ID を入力するようにしてください。 **共有テーブルに対する許可を付与する (名前付きリソース方式、コンソール)** + 「[名前付きリソース方式を使用したテーブル許可の付与](granting-table-permissions.md)」の手順を実行します。**[LF-Tags or catalog resources]** (LF タグまたはカタログリソース) の **[Database]** (データベース) リストでは、外部アカウントのデータベースを選択して、データベースのリソースリンクは選択しないようにしてください。 テーブルのリストにテーブルが表示されない場合は、そのテーブルの AWS RAM リソース共有招待を承諾していることを確認してください。詳細については、「[からのリソース共有の招待の承諾 AWS RAM](accepting-ram-invite.md)」を参照してください。 また、`ALTER` 許可については、「[データロケーション許可の付与 (同じアカウント)](granting-location-permissions-local.md)」の手順を実行し、**[Registered account location]** (登録されたアカウントのロケーション) に所有側のアカウント ID を入力するようにしてください。 **共有リソースに対する許可を付与する (LF-TBAC 方式、コンソール)** + 「[データカタログ許可の付与](granting-catalog-perms-TBAC.md#granting-cat-perms-TBAC-console)」の手順を実行します。**[LF タグまたはカタログリソース]** セクションで、外部アカウントがアカウントに付与したものと同一の LF タグ式、またはその式のサブセットを付与します。 例えば、外部アカウントが LF タグ式 `module=customers AND environment=production` を付与オプションでアカウントに付与した場合は、データレイク管理者として、同じ式や、`module=customers` または `environment=production` をアカウント内のプリンシパルに付与できます。付与できるのは、リソースに対して LF タグ式で付与された Lake Formation 許可 (例えば `SELECT` や `ALTER` など) と同じ許可、またはそのサブセットのみです。 **共有テーブルに対するアクセス許可を付与するには (名前付きリソースメソッド AWS CLI)** + 以下のようなコマンドを入力します。この例では、以下のようになっています。 + AWS アカウント ID は 1111-2222-3333 です。 + テーブルを所有し、それをアカウントに付与したアカウントは 1234-5678-9012 です。 + 共有テーブル `pageviews` に対する `SELECT` 許可がユーザー `datalake_user1` に付与されています。そのユーザーはアカウントのプリンシパルです。 + `pageviews` テーブルは、アカウント 1234-5678-9012 が所有する `analytics` データベースにあります。 ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"CatalogId":"123456789012", "DatabaseName":"analytics", "Name":"pageviews"}}' ``` `resource` 引数の `CatalogId` プロパティには、所有側のアカウントを指定する必要があることに注意してください。 # リソースリンク許可の付与 AWS アカウントのプリンシパルに 1 つ以上のリソースリンクに対する AWS Lake Formation アクセス許可を付与するには、次の手順に従います。 リソースリンクの作成後は、作成したユーザーのみがそのリンクを表示してアクセスすることができます。(これは、データベースに **[Use only IAM access control for new tables in this database]** (このデータベース内の新しいテーブルには IAM アクセスコントロールのみを使用する) が有効化されていないことを前提としています。) アカウント内の他のプリンシパルがリソースリンクにアクセスすることを許可するには、少なくとも `DESCRIBE` 許可を付与してください。 **重要** リソースリンクに対する許可を付与しても、ターゲットの (リンクされた) データベースまたはテーブルに対する許可は付与されません。ターゲットに対する許可は、別途付与する必要があります。 Lake Formation コンソール、 API、または AWS Command Line Interface () を使用してアクセス許可を付与できますAWS CLI。 ------ #### [ console ] **Lake Formation コンソールを使用してリソースリンク許可の付与するには** 1. 次のいずれかを行います。 + データベースリソースリンクの場合は、「[名前付きリソース方式を使用したデータベースのアクセス許可の付与](granting-database-permissions.md)」の手順に従って以下を実行します。 1. [データカタログ] の **[データベース]** で、データベースリストからリソースリンクを選択します。 1. **[付与]** を選択して**[アクセス許可の付与]** ページを開きます。 1. アクセス許可を付与するプリンシパルを指定します。 1. **[カタログ]** フィールドと **[データベース]** フィールドにデータが入力されます。 + テーブルリソースリンクの場合は、「[名前付きリソース方式を使用したテーブル許可の付与](granting-table-permissions.md)」の手順に従って以下を実行します。 1. [データカタログ] の **[テーブル]** で、テーブルリストからリソースリンクを選択します。 1. **[アクセス許可の付与]** ページを開きます。 1. プリンシパルを指定します。 1. **[カタログ]**、**[データベース]**、**[テーブル]** フィールドにデータが入力されます。 1. プリンシパルを指定します。 1. **[Permissions]** (許可) で、付与する許可を選択します。オプションで、[Grantable Permissions] (付与可能な許可) を選択します。 ![\[[アクセス許可] セクションには タイルが 1 つあります。タイルには、付与するリソースリンクへのアクセス許可に対するチェックボックスのグループがあります。チェックボックスには [ドロップ]、[記述]、および [スーパー] があります。そのグループの下には、付与可能な許可に対する同じチェックボックスのグループがもう 1 つあります。\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/images/grant-resource-link-permissions-TBAC.png) 1. **[Grant]** (付与) を選択します。 ------ #### [ AWS CLI ] **を使用してリソースリンクのアクセス許可を付与するには AWS CLI** + リソースリンクをリソースとして指定して、`grant-permissions` コマンドを実行します。 **Example** この例では`DESCRIBE`、 AWS アカウント 1111-2222-3333 `datalake_user1`のデータベース`incidents-link`内のテーブルリソースリンク`issues`の ユーザーに を付与します。 ``` 1. aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"issues", "Name":"incidents-link"}}' ``` ------ **以下も参照してください。** [リソースリンクの作成](creating-resource-links.md) [Lake Formation 許可のリファレンス](lf-permissions-reference.md) # 共有テーブルの基盤となるデータへのアクセス AWS アカウント A がデータカタログテーブルをアカウント B と共有しているとします。たとえば、 にテーブルの付与オプション`SELECT`を指定してアカウント B に付与します。アカウント B のプリンシパルが共有テーブルの基盤となるデータを読み取れるようにするには、次の条件を満たす必要があります。 + アカウント B のデータレイク管理者が共有を承諾すること。(これは、アカウント A と B が同じ組織内にある場合、またはこの付与が Lake Formation のタグベースのアクセスコントロール方式で行われた場合は必要ありません。) + アカウント A が付与した共有テーブルに対する Lake Formation `SELECT` 許可を、データレイク管理者がプリンシパルに再度付与すること。 + プリンシパルが、テーブル、テーブルが含まれるデータベース、およびアカウント A Data Catalog に対する以下の IAM 許可を持っていること。 **注記** 以下の IAM ポリシーで、これらを実行してください。 ** を AWS アカウント A のアカウント ID に置き換えます。 ** を有効なリージョンに置き換える。 ** を、アカウント A 内の共有テーブルが含まれるデータベースの名前に置き換える。 ** を共有テーブルの名前に置き換える。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:table//
", "arn:aws:glue:us-east-1:111122223333:database/", "arn:aws:glue:us-east-1:111122223333:catalog" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": [ "*" ] } ] } ``` ------ **以下も参照してください。** [からのリソース共有の招待の承諾 AWS RAM](accepting-ram-invite.md) # CloudTrail のクロスアカウントロギング Lake Formation は、データレイク内のデータに対するすべてのクロスアカウントアクセスの一元的な監査証跡を提供します。受信者 AWS アカウントが共有テーブルのデータにアクセスすると、Lake Formation は CloudTrail イベントを所有アカウントの CloudTrail ログにコピーします。コピーされたイベントには、 Amazon Athena や Amazon Redshift Spectrum などの統合サービスによるデータに対するクエリと、AWS Glueジョブによるデータアクセスが含まれます。 Data Catalog リソースへのクロスアカウント操作に関する CloudTrail イベントも、同様にコピーされます。 リソース所有者として Amazon S3 でのオブジェクトレベルのロギングを有効にすると、S3 CloudTrail イベントと Lake Formation CloudTrail イベントを結合するクエリを実行して、S3 バケットにアクセスしたアカウントを特定することができます。 **Topics** + [クロスアカウント CloudTrail ログにプリンシパルアイデンティティを含める](#cross-account-logging-optin) + [Amazon S3 クロスアカウントアクセスの CloudTrail ログのクエリ](#cross-account-logging-s3) ## クロスアカウント CloudTrail ログにプリンシパルアイデンティティを含める デフォルトでは、共有リソース受信者のログに追加され、リソース所有者のログにコピーされたクロスアカウント CloudTrail イベントには、外部アカウントプリン AWS シパルのプリンシパル ID のみが含まれ、プリンシパル (プリンシパル ARN) の人間が読み取り可能な Amazon リソースネーム (ARN) は含まれません。同じ組織またはチーム内などの信頼できる境界範囲内でリソースを共有するときは、CloudTrail イベントにプリンシパル ARN を含めることをオプトインできます。そうすることで、リソース所有者アカウントは、アカウントが所有するリソースにアクセスする受領者アカウントのプリンシパルを追跡できるようになります。 **重要** 共有リソースの受領者として独自の CloudTrail ログ内のイベントのプリンシパル ARN を表示するには、所有者アカウントとプリンシパル ARN を共有することをオプトインする必要があります。 リソースリンク経由でデータアクセスが行われる場合、リソースリンクへのアクセスと、ターゲットリソースへのアクセスの 2 つのイベントが、共有リソース受領者のアカウントにログに記録されます。リソースリンクアクセスのイベントには、プリンシパル ARN が*含まれて*います。オプトインされなかった場合、ターゲットリソースアクセスのイベントにプリンシパル ARN は含まれません。リソースリンクアクセスイベントは、所有者アカウントにコピーされません。 以下は、デフォルトのクロスアカウント CloudTrail イベント (オプトインなし) からの抜粋です。データアクセスを実行するアカウントは 1111-2222-3333 です。これは、呼び出し側のアカウントとリソース所有者アカウントの両方に表示されるログです。クロスアカウントの場合、Lake Formation は両方のアカウントにログを入力します。 ``` { "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AROAQGFTBBBGOBWV2EMZA:GlueJobRunnerSession", "accountId": "111122223333" }, "eventSource": "lakeformation.amazonaws.com", "eventName": "GetDataAccess", ... ... "additionalEventData": { "requesterService": "GLUE_JOB", "lakeFormationRoleSessionName": "AWSLF-00-GL-111122223333-G13T0Rmng2" }, ... } ``` 共有リソースのコンシューマーとしてプリンシパル ARN を含めることをオプトインすると、この抜粋は以下のようになります。`lakeFormationPrincipal` フィールドは、Amazon Athena、Amazon Redshift Spectrum、または AWS Glue ジョブを使用してクエリを実行するエンドロールまたはユーザーを表します。 ``` { "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AROAQGFTBBBGOBWV2EMZA:GlueJobRunnerSession", "accountId": "111122223333" }, "eventSource": "lakeformation.amazonaws.com", "eventName": "GetDataAccess", ... ... "additionalEventData": { "requesterService": "GLUE_JOB", "lakeFormationPrincipal": "arn:aws:iam::111122223333:role/ETL-Glue-Role", "lakeFormationRoleSessionName": "AWSLF-00-GL-111122223333-G13T0Rmng2" }, ... } ``` **クロスアカウント CloudTrail ログにプリンシパル ARN を含めることをオプトインする** 1. Lake Formation コンソール (‭‬[https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/)‬) を開きます。 `Administrator` ユーザー、または `Administrator Access` の IAM ポリシーを持つユーザーとしてサインインします。 1. ナビゲーションペインで **[Settings]** (設定) を選択します。 1. **データカタログ設定**ページの**「 のデフォルトアクセス許可 AWS CloudTrail**」セクションで、**リソース所有者**に 1 つ以上の AWS リソース所有者アカウント ID を入力します。 IDs 各アカウント ID の後で **Enter** キーを押します。 1. **[Save]** (保存) を選択します。 これで、共有リソース受領者とリソース所有者両方のログに保存されるクロスアカウント CloudTrail イベントに、プリンシパル ARN が含まれるようになりました。 ## Amazon S3 クロスアカウントアクセスの CloudTrail ログのクエリ 共有リソース所有者は、S3 CloudTrail ログをクエリして、Amazon S3 バケットにアクセスしたアカウントを特定することができます (Amazon S3 でオブジェクトレベルのロギングが有効化されている場合)。これは、Lake Formation に登録した S3 ロケーションのみに適用されます。共有リソースのコンシューマーが Lake Formation CloudTrail ログにプリンシパル ARN を含めることをオプトインする場合は、バケットにアクセスしたロールまたはユーザーを特定することができます。 を使用してクエリを実行する場合 Amazon Athena、セッション名プロパティで Lake Formation CloudTrail イベントと S3 CloudTrail イベントを結合できます。クエリは、Lake Formation イベントを `eventName="GetDataAccess"` で、S3 イベントを `eventName="Get Object"` または `eventName="Put Object"` でフィルタリングすることもできます。 以下は、登録された S3 ロケーションのデータに対するアクセスが行われた Lake Formation クロスアカウント CloudTrail イベントからの抜粋です。 ``` { "eventSource": "lakeformation.amazonaws.com", "eventName": "GetDataAccess", .............. .............. "additionalEventData": { "requesterService": "GLUE_JOB", "lakeFormationPrincipal": "arn:aws:iam::111122223333:role/ETL-Glue-Role", "lakeFormationRoleSessionName": "AWSLF-00-GL-111122223333-B8JSAjo5QA" } } ``` `lakeFormationRoleSessionName` キーの値である `AWSLF-00-GL-111122223333-B8JSAjo5QA` は、S3 CloudTrail イベントの `principalId` キーにあるセッション名と結合させることができます。以下は、S3 CloudTrail イベントからの抜粋です。これには、セッション名のロケーションが表示されています。 ``` { "eventSource": "s3.amazonaws.com", "eventName": "Get Object" .............. .............. "principalId": "AROAQSOX5XXUR7D6RMYLR:AWSLF-00-GL-111122223333-B8JSAjo5QA", "arn": "arn:aws:sets::111122223333:assumed-role/Deformationally/AWSLF-00-GL-111122223333-B8JSAjo5QA", "session Context": { "session Issuer": { "type": "Role", "principalId": "AROAQSOX5XXUR7D6RMYLR", "arn": "arn:aws:iam::111122223333:role/aws-service-role/lakeformation.amazonaws.com/Deformationally", "accountId": "111122223333", "user Name": "Deformationally" }, .............. .............. } ``` セッション名は以下のような形式になります。 ``` AWSLF---- ``` **`version-number`** この形式のバージョンは、現在 `00` です。セッション名の形式が変更される場合、次のバージョンは `01` になります。 **`query-engine-code`** データにアクセスしたエンティティを示します。現在の値は次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/cross-account-logging.html) **`account-id`** Lake Formation から認証情報をリクエストした AWS アカウント ID。 **`suffix`** ランダムに生成された文字列。 # AWS Glue と Lake Formation の両方を使用したクロスアカウント許可の管理 AWS Glue または AWS Lake Formationを使用することで、Data Catalog リソースと基盤となるデータに対するクロスアカウントアクセス権を付与することが可能です。 AWS Glue では、データカタログリソースポリシーを作成または更新することでクロスアカウント許可を付与します。Lake Formation では、Lake Formation の `GRANT/REVOKE` 許可モデルと、`Grant Permissions` API 操作を使用することによって、クロスアカウント許可を付与します。 **ヒント** データレイクをセキュア化するには、Lake Formation 許可のみに頼ることをお勧めします。 Lake Formation のクロスアカウント付与を表示するには、Lake Formation コンソールまたは AWS Resource Access Manager (AWS RAM) コンソールを使用します。ただし、これらのコンソールページには、AWS Glue Data Catalog リソースポリシーによって付与されたクロスアカウント許可が表示されません。同様に、AWS Glue コンソールの **[Settings]** (設定) ページを使用して Data Catalog リソースポリシー内のクロスアカウント許可を表示することはできますが、そのページに Lake Formation を使用して付与されたクロスアカウント許可は表示されません。 クロスアカウント許可を表示および管理するときに付与を見落とさないようにするため、Lake Formation と AWS Glue では、以下のアクションを実行して、Lake Formation と AWS Glue の両方によるクロスアカウント付与を認識しており、それらを許可していることを示す必要があります。 **AWS Glue Data Catalog リソースポリシーを使用してクロスアカウント許可を付与する場合** アカウント (付与者アカウントまたはプロデューサーアカウント) が、 AWS RAM を使用してリソースを共有するクロスアカウント付与を行っていない場合は、データカタログリソースポリシーを通常どおり AWS Glue に保存できます。ただし、 AWS RAM リソース共有を含む許可がすでに作成されている場合は、リソースポリシーの保存が成功するように、次のいずれかを実行する必要があります。 + AWS Glue コンソールの [**Settings**] (設定) ページでリソースポリシーを保存するときは、ポリシー内の許可が Lake Formation コンソールを使用して付与された許可に追加されることを示す警告が、コンソールに表示されます。**[Proceed]** (続行) を選択してポリシーを保存する必要があります。 + `glue:PutResourcePolicy` API オペレーションを使用してリソースポリシーを保存するときは、`EnableHybrid` フィールドを「`TRUE`」(型 = 文字列) に設定する必要があります。 既存のリソースポリシーを更新するには、`glue:GetResourcePolicy` API オペレーションを使用してまず現在のポリシーを取得し、必要に応じて変更してから `glue:PutResourcePolicy` を呼び出します。 **注記** クロスアカウントアクセス用の AWS Glue リソースポリシーを作成するときは、特定のユースケースに必要な最小限のアクセス許可のみを付与します。 詳細については、「*AWS Glue デベロッパーガイド*」の「[PutResourcePolicy アクション (Python: put\$1resource\$1policy)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-jobs-security.html#aws-glue-api-jobs-security-PutResourcePolicy)」を参照してください。 **Lake Formation の名前付きリソース方式を使用してクロスアカウント許可を付与する場合** アカウント (プロデューサーアカウント) にデータカタログリソースポリシーがない場合、Lake Formation クロスアカウント付与は通常どおりに実行されます。ただし、Data Catalog リソースポリシーが存在する場合は、以下のステートメントをポリシーに追加して、クロスアカウント付与が名前付きリソース方式で行われた場合でもそれらが成功することを許可する必要があります。** を有効なリージョン名に置き換え、** を AWS アカウント ID (プロデューサーアカウント ID) に置き換えます。 ``` { "Effect": "Allow", "Action": [ "glue:ShareResource" ], "Principal": {"Service": [ "ram.amazonaws.com" ]}, "Resource": [ "arn:aws:glue:::table/*/*", "arn:aws:glue:::database/*", "arn:aws:glue:::catalog" ] } ``` この追加のステートメントがないと、Lake Formation 許可は成功しますが、ブロックされ AWS RAM、受信者アカウントは付与されたリソースにアクセスできません。 **重要** クロスアカウント付与を実行するために Lake Formation のタグベースのアクセスコントロール (LF-TBAC) 方式も使用している場合、少なくとも「[前提条件](cross-account-prereqs.md)」で指定されている許可がある Data Catalog リソースポリシーが必要です。 **以下も参照してください。** 「[メタデータのアクセスコントロール](access-control-metadata.md)」(名前付きリソース方式と Lake Formation のタグベースのアクセスコントロール (LF-TBAC) 方式の説明) [共有 Data Catalog テーブルとデータベースの表示](viewing-available-shared-resources.md) 「*AWS Glue デベロッパーガイド*」の「[AWS Glue コンソールでのデータカタログ設定の使用](https://docs.aws.amazon.com/glue/latest/dg/console-data-catalog-settings.html)」 「*AWS Glue デベロッパーガイド*」の「[クロスアカウントアクセス許可の付与](https://docs.aws.amazon.com/glue/latest/dg/cross-account-access.html)」(データカタログリソースポリシーのサンプル) # GetResourceShares API 操作を使用したすべてのクロスアカウント付与の表示 企業がリソース AWS Glue Data Catalog ポリシーと Lake Formation 許可の両方を使用してクロスアカウント許可を付与する場合、すべてのクロスアカウント許可を 1 か所に表示する唯一の方法は、 `glue:GetResourceShares` API オペレーションを使用することです。 名前付きリソースメソッドを使用してアカウント間で Lake Formation アクセス許可を付与すると、 AWS Resource Access Manager (AWS RAM) は AWS Identity and Access Management (IAM) リソースポリシーを作成し、 AWS アカウントに保存します。このポリシーは、リソースへのアクセスに必要なアクセス許可を付与します。 は、クロスアカウント付与ごとに個別のリソースポリシー AWS RAM を作成します。`glue:GetResourceShares` API 操作を使用することで、これらすべてのポリシーを表示することができます。 **注記** この操作は、Data Catalog リソースポリシーも返します。ただし、Data Catalog 設定でメタデータ暗号化を有効にし、 AWS KMS キーに対するアクセス許可がない場合、オペレーションは Data Catalog リソースポリシーを返しません。 **すべてのクロスアカウント付与を表示する** + 次のコマンドを入力します AWS CLI 。 ``` aws glue get-resource-policies ``` 以下は、`t`データベースのテーブルに対するアクセス許可を AWS アカウント 1111-2222-3333 `db1`に付与するときに AWS RAM 作成および保存するリソースポリシーの例です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:GetTables", "glue:GetTableVersion", "glue:GetTableVersions", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:SearchTables" ], "Principal": {"AWS": [ "111122223333" ]}, "Resource": [ "arn:aws:glue:us-east-1:111122223333:table/db1/t" ] } ] } ``` ------ **以下も参照してください。** *AWS Glue デベロッパーガイド*の「[GetResourceShares アクション (Python: get\$1resource\$1policies)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-jobs-security.html#aws-glue-api-jobs-security-GetResourcePolicies)」