AWS Lake Formationのタグを使用して直接IAMプリンシパルとのクロスアカウント共有を有効化

この記事は、Enable cross-account sharing with direct IAM principals using AWS Lake Formation Tags を翻訳したものです。

AWS Lake Formation を使用すると、複数の AWS アカウントを使用してさまざまな方法でデータレイクを構築できます。たとえば、データメッシュを構築して、中央集権的なデータガバナンスモデルを実装し、データプロデューサーを中央のガバナンスから切り離すことができます。このようなデータレイクにより、データを資産として利用できるようになり、組織全体のコンシューマーを対象としたデータ発見と探索によって新たな可能性が開けます。組織全体の意思決定におけるデータの力を活用する一方で、データを保護することも重要です。Lake Formation を使えば、アカウント間でデータセットを共有する簡単な手順がいくつかあればよく、共有するリソースを管理できます。

Lake Formation は、アカウント間で AWS Glue データカタログリソースを共有するためのバージョン 3 機能をリリースしました。Lake Formation のクロスアカウント共有 V3 に移行すると、いくつかのメリットが得られます。V1 から移行すると、AWS Resource Access Manager (AWS RAM) をより最適に使用して、リソースの共有を拡張できます。V2 から移行すると、いくつかの機能が強化されます。まず、バージョン 3 は AWS RAM を使用するため、LF タグを使用して共有する AWS Glue リソースポリシーを管理する必要はありません。2 つ目は、LF タグを使用して AWS Organizationsと共有できることです。3 つ目は、他のアカウントの個々の AWS Identity and Access Management (IAM) ユーザーやロールを共有できるため、データ所有者はどの個人が自分のデータにアクセスできるかを制御できます。

Lake Formation タグベースのアクセス制御 (LF-TBAC) は、LF タグと呼ばれる属性に基づいて権限を定義する認可方法です。LF タグは IAM リソースタグとは異なり、Lake Formation のデータベース、テーブル、および列にのみ関連付けられます。LF-TBACでは、データカタログリソースをグループ化して権限の付与と取り消しのポリシーを定義できるため、多数のデータベースやテーブルにわたって権限管理をスケーリングするのに役立ちます。LF タグは、データベースからデータベースのすべてのテーブルと各テーブルのすべての列に継承されます。

バージョン 3 には次の利点があります。

ターゲットアカウントの特定の IAM プリンシパルとのクロスアカウント共有による中央制御のガバナンス
LF-TBAC のための AWS Glue リソースポリシーの維持が不要
AWS RAM 共有の効率的な再利用
LF-TBACで数百のアカウントへのスケーリングの簡単さ

この投稿では、TPC データセットを使用したプロデューサーとコンシューマーのシナリオにおけるクロスアカウント共有バージョン 3 の新機能について説明します。LF-TBAC を使用してデータプロデューサーアカウントのデータカタログリソースをコンシューマーアカウントの IAM ユーザーに共有する設定について説明します。また、データコンシューマーアカウントでシェアを受け入れ、データを照会する手順も実行します。

ソリューション概要

Lake Formation のクロスアカウントバージョン 3 機能のデモンストレーションには、s3://aws-data-analytics-workshops/shared_datasets/tpcparquet/ にある TPC データセットを使用します。ソリューションは両方のアカウントのステップで構成されています。

アカウント A で、次の手順を実行します。

データプロデューサーとして、データセットを Lake Formation に登録し、AWS Glue データカタログテーブルを作成します。
LF タグを作成し、データベースとテーブルに関連付けます。
リソースに対する LF タグベースの権限をコンシューマーアカウント B のリソースに直接付与します。

アカウント B では次の手順を実行します。

コンシューマーアカウントのデータレイク管理者は、AWS RAM の招待を確認して承認します。
データレイク管理者は、IAM ユーザー lf_business_analysts に CREATE DATABASE アクセス権を付与します。
データレイク管理者はマーケティングチーム用のデータベースを作成し、lf_campaign_manager に CREATE TABLE アクセス権を付与します。
IAM ユーザーは、共有されたデータベースとテーブルにリソースリンクを作成し、Amazon Athena でクエリを実行します。

プロデューサーアカウント A には次のペルソナがあります。

データレイク管理者 — プロデューサーアカウントのデータレイクを管理
lf-producersteward — データとユーザーアクセスを管理

コンシューマーアカウント B には次のペルソナがあります。

データレイク管理者 — コンシューマーアカウントのデータレイクを管理
lf-business-analysts — 営業チームのビジネスアナリストは、個人情報以外のデータにアクセスする
lf-campaign manager — マーケティングチームのマネージャーは、商品やプロモーションに関連するデータにアクセスする必要がある

前提条件

以下の前提条件を確認してください。

2 つの AWS アカウント。AWS RAM の招待がどのように作成され承認されるかを示すこのデモンストレーションでは、同じ組織に属していない 2 つのアカウントを使用する必要がある。
AWS CloudFormation スタックを起動するには、両方のアカウントの管理者の IAM ユーザーが必要。
クロスアカウントバージョン 3 を使用するプロデューサーアカウントとコンシューマーアカウントの両方で Lake Formation の許可モデルが有効になっている必要がある。手順については、「デフォルトの許可モデルを変更する」を参照。

アカウント A での Lake Formation と AWS CloudFormation のセットアップ

セットアップをシンプルにするために、IAM 管理者をデータレイク管理者として登録しています。

us-east-1 リージョンの AWS マネジメントコンソールにサインインします。
Lake Formation コンソールのナビゲーションペインの Permissions の下にある、 Administrative roles and tasks を選択します。
Datalake administrators の下の Choose Administrators を選択します。
ポップアップウィンドウの Manage data lake administrators の IAM users and roles で、IAM admin user を選択し、 Save を選択します。
Launch Stack を選択して CloudFormation テンプレートをデプロイします。
Next （次へ）を選択します。
Stack name （スタックの名前）を指定し、 Next （次へ）を選択します。
次のページで、 Next （次へ）を選択します。
最後のページの詳細を確認し、 I acknowledge that AWS CloudFormation might create IAM resources （AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。）を選択します。
Create （送信）を選択します。

スタックの作成には約 2 ～ 3 分かかります。スタックは、次のようにプロデューサーのセットアップを行います。

Amazon Simple Storage Service (Amazon S3) データレイクバケットを作成。
データレイクバケットを Lake Formation に登録。
AWS Glue データベースとテーブルを作成。
プロデューサースチュワードを務める IAM ユーザー (lf-producersteward) を作成。
LF タグを作成し、次の表に示すように、作成したカタログリソースに割り当て。

Database	Table	LF-Tag Key	LF-Tag Value	Resource Tagged
`lftpcdb`	.	`Sensitivity`	`Public`	`DATABASE`
`lftpcdb`	`items`	`HasCampaign`	`true`	`TABLE`
`lftpcdb`	`promotions`	`HasCampaign`	`true`	`TABLE`
`lftpcdb`	`customers table columns = "c_last_name","c_first_name","c_email_address"`	`Sensitivity`	`Confidential`	`TABLECOLUMNS`

アカウント A の権限を確認

CloudFormation スタックが起動したら、アカウント A で以下の手順を実行します。

AWS CloudFormation コンソールで、スタックの Outputs （出力）タブに移動します。

LFProducerStewardCredentials の値を選択して、AWS Secrets Manager コンソールに移動します。
Secret value （シークレットの値）セクションで、 Retrieve secret value （シークレットの値を取得する）を選択します。
IAM ユーザー lf-producersteward のpasswordの値を書き留めておきます。

これは、後で lf-producersteward というユーザーとしてコンソールにログインする際に必要です。

LakeFormation コンソールのナビゲーションペインで Databases を選択します。
データベース lftpcdb を開きます。
データベースの LF タグが作成されていることを確認します。

View tables を選択し、 items テーブルを選択して LF-tags を確認します。

promotions テーブルと customers テーブルで同じ手順を繰り返して、LFタグが割り当てられていることを確認します。

Lake Formation コンソールのナビゲーションペインの Data catalog で、 Databases を選択します。
データベース lftpcdb を選択し、 Actions メニューで View Permissions を選択します。
データベース lftpcdb に IAMAllowedPrincipals のデフォルト権限が付与されていないことを確認します。
その権限が見つかった場合は、権限を選択し、 Revoke を選択して権限を取り消します。
AWS マネジメントコンソールで、トップメニューの AWS CloudShell アイコンを選択します。

これにより、ブラウザの別のタブに AWS CloudShell が開きます。CloudShell 環境がセットアップされるまで数分お待ちください。

スタック出力の {BUCKET_NAME} を DataLakeBucket に置き換えた後、次の AWS コマンドラインインターフェイス (AWS CLI) コマンドを実行します。

aws s3 cp s3://aws-data-analytics-workshops/shared_datasets/tpcparquet/ s3://${BUCKET_NAME}/tpcparquet/  --recursive

選択したリージョンで CloudShell を利用できない場合は、次の AWS CLI コマンドを実行して、必要なデータセットを任意の AWS CLI 環境から IAM 管理者ユーザーとしてコピーします。

S3 バケットにデータセットがコピーされていることを確認します。
IAM 管理者ユーザーとしてログアウトします。

アカウント A に権限を付与

引き続きプロデューサーアカウント内のデータスチュワードとしてデータセットへの Lake Formation 権限を付与します。データスチュワードは、以下のLFタグベースの権限をコンシューマーペルソナに付与します。

コンシューマーペルソナ	LF-tag Policy
`lf-business-analysts`	`Sensitivity=Public`
`lf-campaign-manager`	`HasCampaign=true`

先ほど Secrets Manager でメモしたパスワードを使用して、アカウント A に lf-producersteward というユーザーとしてログインします。
Lake Formation コンソールのナビゲーションペインの Permissions で、 Data Lake permissions を選択します。
Grant を選択します。
Principals で External accounts を選択します。
コンシューマーアカウントの IAM ユーザーの ARN（arn:aws:iam::<accountB_id>:user/lf-business-analysts）を入力し、Enter キーを押します。

LF-Tags or catalog resources で、Resources matched by LF-Tags を選択します。
Add LF-Tag を選択して、新しいキーと値のペアを追加します。
キーには Sensitivity を選択し、値には Public を選択します。
Database permissions で Describe を選択し、 Table permissions で Select と Describe を選択します。

Grant を選択して権限を適用します。
Lake Formation コンソールのナビゲーションペインの Permissions で、Data Lake permissions を選択します。
Grant を選択します。
Principals で External accounts を選択します。
コンシューマーアカウントの IAM ユーザーの ARN（arn:aws:iam::<accountB_id>:user/lf-campaign-manager）を入力し、Enter キーを押します。
LF-Tags or catalog resources で、Resources matched by LF-Tags を選択します。
Add LF-Tag を選択して、新しいキーと値のペアを追加します。
キーには HasCampaign を選択し、値には true を選択します。

Database permissions で Describe を選択し、 Table permissions で Select と Describe を選択します。
Grant を選択して権限を適用します。
Data lake permissions タブで、付与した権限が正しく表示されていることを確認します。

アカウント B の AWS Cloud Formation セットアップ

コンシューマーアカウントで次の手順を実行します。

アカウント B に IAM 管理者ユーザーとしてログインし、CloudFormation スタックを起動します。
Next （次へ）を選択します。
Stack name （スタックの名前）を指定し、 Next （次へ）を選択します。
次のページで、 Next （次へ）を選択します。
最後のページの詳細を確認し、 I acknowledge that AWS CloudFormation might create IAM resources （AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。）を選択します。
Create （送信）を選択します。

スタックの作成には約 2 ～ 3 分かかります。スタックは、アカウント B に次のリソースを設定します。

関連するIAM権限とLake Formation権限を持つIAM ユーザー datalakeadmin1、 lf-business-analysts 、lf-campaign-manager
lf-campaign manager ユーザーが Create_Table 権限を持つ db_for_shared_tables データベース
lfblog-athenareresults-<your-accountB-id>-us-east-1 という名前の S3 バケットで、ListBucket と lf-business-analysts と lf-campaign-manager への書き込み権限が付いている

スタック出力の詳細をメモしておいてください。

アカウント B でリソース共有を承認

CloudFormation スタックを起動したら、アカウント B で以下の手順を実行します。

CloudFormation スタックの Outputs （出力）タブで、DataLakeAdminCredentials のリンクを選択します。

これにより、Secrets Manager のコンソールが表示されます。

Secrets Manager のコンソールで、 Retrieve secret value （シークレットの値を取得する）を選択し、datalakeadmin1 ユーザーのパスワードをコピーします。
CloudFormation テンプレートの出力の ConsoleIAMLoginURL の値を使用して、データレイク管理者のユーザー名 datalakeadmin1 と Secrets Manager からコピーしたパスワードでアカウント B にログインします。
AWS RAM コンソールを別のブラウザタブで開きます。
ナビゲーションペインの Shared with me （自分と共有）で、 Resource shares （リソースの共有）を選択すると、保留中の招待が表示されます。

プロデューサーアカウント A から 2 つのリソース共有への招待が表示されます。1 つはデータベースレベルの共有用、もう 1 つはテーブルレベルの共有用です。

各リソース共有リンクを選択し、詳細を確認して、 Accept （リソースの共有を承認）を選択します。

招待を受け入れると、リソース共有のステータスが Pending から Active に変わります。

アカウント B に権限を付与

アカウント B に権限を付与するには、次の手順を実行します。

Lake Formation コンソールのナビゲーションペインの Permissions で、 Administrative roles and tasks を選択します。

Database creators で Grant を選択します。

IAM users and roles で、 lf-business-analysts を選択します。
Catalog permissions については、 Create database を選択します。
Grant を選択します。
データレイク管理者ユーザーとしてコンソールからログアウトします。

コンシューマーユーザーとして共有データセットをクエリする

lf-business-analysts ユーザーのデータアクセスを検証するには、次の手順を実行します。

CloudFormation スタックの出力に記録された資格情報を使用して、lf-business-analysts としてコンソールにログインします。
Lake Formation コンソールのナビゲーションペインの Data catalog で、 Databases を選択します。

データベース lftpcdb を選択し、 Actions メニューで Create resource link を選択します。

Resource link name に rl_lftpcdb と入力します。
Create を選択します。
リソースリンクを作成したら、そのリソースリンクを選択し、 View tables を選択します。

これで、共有データベースの 4 つのテーブルが表示されます。

別のブラウザタブで Athena コンソールを開き、クエリ結果の場所として lfblog-athenaresults-<your-accountB-id>-us-east-1 バケットを選択します。
次のクエリを使用してデータアクセスを確認します (詳細については、 Amazon Athena を使用した SQL クエリの実行を参照してください)。

Select * from rl_lftpcdb.customers limit 10;

次のスクリーンショットは、クエリ出力を示しています。

アカウント A が LF タグ式 Sensitivity=Public を使用してデータベース lftpcdb をアカウント B と共有していることに注目してください。customers テーブルの c_first_name、c_last_name、c_email_address の各列は Sensitivity=Confidential で上書きされています。そのため、この 3 つの列はユーザー lf-business-analysts では表示されません。

データベースの他のテーブルも同様にプレビューして、使用可能な列とデータを確認できます。

lf-business-analysts としてコンソールからログアウトします。

lf-campaign-manager ユーザーのデータアクセスを検証します。

CloudFormation スタックの出力に記録された認証情報を使用して、lf-campaign-manager としてコンソールにログインします。
Lake Formation コンソールのナビゲーションペインの Data catalog で、 Databases を選択します。
データレイク管理者が共有しているデータベース db_for_shared_tables が表示されていることを確認します。

ナビゲーションペインの Data catalog で、 Tables を選択します。

LF タグ式 HasCampaign=true を使用すると、アカウント A から共有されている 2 つのテーブルを確認できます。2 つのテーブルの Owner account ID がアカウント A と表示されます。

lf-campaign-manager はテーブルレベルの共有を受け取ったので、このユーザーが Athena でクエリを行うためのテーブルレベルのリソースリンクを作成します。

promotions テーブルを選択し、 Actions メニューで Create resource link を選択します。

Resource link name に rl_promotions を入力します。

Database で、リソースリンク作成先のデータベース db_for_shared_tables を選択します。
Create を選択します。
他のテーブルについても、リソースリンクの作成を行います。

リソースリンクではアカウント B が所有者として表示されているのに対し、実際のテーブルではアカウント A が所有者として表示されていることに注目してください。

別のブラウザタブで Athena コンソールを開き、クエリ結果の場所として lfblog-athenaresults-<your-accountB-id>-us-east-1 バケットを選択します。
リソースリンクを使用してテーブルをクエリします。

次のスクリーンショットに示すように、lf-campaign-manager では両方のテーブルのすべての列にアクセスできます。

ここまでで、LF タグを使用してあるアカウントから別のアカウントの IAM ユーザーにデータベースを共有しテーブルを選択する方法を見てきました。

クリーンアップ

この記事で作成した AWS リソースに料金が発生しないようにするには、次の手順を実行してください。

まず、アカウント A のリソースをクリーンアップします。

ダウンロードしたオブジェクトを S3 バケットから削除して、この記事用に作成した S3 バケットを空にします。
CloudFormation スタックを削除します。

これにより、S3 バケット、カスタム IAM ロール、ポリシー、LF データベース、テーブル、権限が削除されます。

Lake Formationの設定を元に戻して、Lake Formationコンソールの Settings ページからIAMアクセスを再度追加することもできます。

次に、アカウント B で次の手順を実行します。

Athena のクエリ結果の保存場所として使用されている S3 バケット lfblog-athenaresults-<your-accountB-id>-us-east-1 を空にします。
データベース作成者としての lf-business-analysts の権限を取り消してください。
CloudFormation スタックを削除します。

これにより、IAMユーザー、S3バケット、LF データベース db_for_shared_tables、リソースリンク、およびすべての権限が Lake Formation から削除されます。

リソースリンクと権限が残っている場合は、Lake Formationで両方のアカウントから手動で削除してください。

結論

この記事では、Lake Formation のクロスアカウント共有バージョン 3 で LF タグを使用して IAM プリンシパルに権限を設定する利点と、コンシューマーアカウントで共有を受け取る方法について説明しました。データプロデューサーアカウントが LF タグを使用して別のアカウントの個々の IAM ユーザーにデータベースと特定のテーブルを共有する 2 つのアカウントのシナリオを使用しました。受信側のアカウントでは、データレイク管理者と受信側のIAMユーザーが果たす役割を示しました。また、列タグを上書きして PII データをマスクして共有する方法についても説明しました。

Lake Formation では、バージョン 3 のクロスアカウント共有機能により、プロデューサーがアカウント全体ではなく別のアカウントの IAM プリンシパルと直接共有できる、より現代的なデータメッシュモデルが可能になりました。データメッシュの実装は、LF タグベースの組織単位や ID への共有を使用して数百のコンシューマーアカウントに簡単に拡張できるため、データ管理者やデータプラットフォームの所有者にとってより簡単になります。

Lake Formation のクロスアカウント共有をバージョン 3 にアップグレードして、機能強化の恩恵を受けることをお勧めします。詳細については、クロスアカウントデータ共有のバージョン設定の更新を参照してください。

翻訳はプロフェッショナルサービスの赤羽根が担当しました。原文はこちらです。

Amazon Web Services ブログ