Lake Formation を使用し AWS アカウント間でセキュアにデータ共有を実現

近年、多くの企業で構造化データ・非構造化データをスケーラブルな形で一箇所に集約したいニーズが増えてきたことから、データレイクが非常に注目を集めています。データは元のまま保管されているため、事前に定められたスキーマへの変換は必要なく、ビジネスユースケースに応じて柔軟に新たな分析をデータレイク上で始めることができます。

実利用においては、自社が所有するデータを他の企業、組織、またはビジネスユニットに共有したい要件がよくあります。例として、他社のステークホルダーに自社のデータを共有し、共同のマーケティングキャンペーンを打ち出すなどが考えられます。このようなユースケースで、データの提供元 (プロデューサー) は自身のデータを丸ごとコピーすることなく、セキュアかつ簡単に共有したいと思うでしょう。

2019 年 8 月に私達は AWS Lake Formation の一般公開を発表しました。Lake Formation はデータレイクの構築を数日で行えるよう支援するフルマネージドなサービスです。Lake Formation を使用することで一元的に複数アカウントに渡るデータレイクを管理できます。また、AWS Glue Data Catalog や Amazon Simple Storage Service (Amazon S3) ロケーションに対するきめ細やかなアクセス制御を行うことが可能です。
別 AWS アカウントに対し、Lake Formation を使用してデータベースやテーブルのクロスアカウントアクセスを付与するには二通りの方法があります：

Lake Formation tag-based access control (推奨)
Lake Formation named resources

本ブログではこの二つの方法の違いを説明し、クロスアカウントアクセスを行うための手順を紹介します。

Tag-based access control の概要

Lake Formation tag-based access control は属性に応じて権限を定義する方法であり、Lake Formation ではこれらの属性を　LF-tag と呼びます。LF-tag は Glue Data Catalog や Lake Formation エンティティに付与することが可能です。データレイク管理者は Lake Formation リソースに対し、LF-tag を通じて権限の付与や剥奪を行います。Tag-based access control の詳細については、ブログ Easily manage your data lake at scale using AWS Lake Formation Tag-based access control をご参考ください。

この方式のアーキテクチャ図は以下の通りです。

Tag-based access control は以下のケースで推奨されます：

データレイク管理者が権限を付与する対象のテーブルやエンティティ数が多い
データをオントロジーに基づいて分類し、権限を付与したい
データレイク管理者は動的・疎結合な形で権限管理を行いたい

Tag-based access control を使用してデータカタログリソース (データベース、テーブル、カラム) を他 AWS アカウントに共有することが可能です。

Named resource 方式の概要

Lake Formation named resource 方式はリソースごとに権限を定義する方式です。リソースはデータベース、テーブル、カラムが対象となっており、データレイク管理者はこれらの Lake Formation リソースに対し権限の付与や剥奪を行うことが可能です。詳細はドキュメントクロスアカウントアクセス: 仕組みをご参考ください。

以下がこの方式のアーキテクチャ図です。

データレイク管理者が共有したいリソースそれぞれに対し明示的に権限を付与したい場合は named resource 方式を推奨します。Named resource 方式を使用して外部のAWSアカウントに Lake Formation 権限を付与する場合、Lake Formation は AWS Resource Access Manager (AWS RAM) を使用してリソースを共有します。

ここからはこの二通りの方式で実際にどのようにクロスアカウントアクセスを実現するかみていきましょう。共有するソーステーブルを保持しているAWSアカウントをプロデューサーアカウント、共有対象のAWSアカウントをコンシューマーアカウントと呼びます。

Lake Formation Data Catalog 設定をプロデューサーアカウントで実施

Lake Formation は独自の権限管理モデルを提供しています。 AWS Identity and Access Management (IAM) の権限モデルと後方互換性を維持するために、デフォルトでは既存の全 AWS Glue Data Catalog リソースにおいて IAMAllowedPrincipals に対し Super 権限が与えられています。また、Use only IAM access control 設定が新規 Data Catalog リソースに対し有効になっています。

このブログでは、きめ細やかなアクセスコントロールを Lake Formation で管理し、疎な権限管理を IAM ポリシーで管理します。詳細はきめ細かなアクセスコントロール方法をご参考ください。このため、 AWS CloudFormation テンプレートでセットアップを行う前に、プロデューサーアカウントにて Lake Formation Data Catalog 設定を変更する必要があります。

この設定は以降新たに作成されるすべてのデータベースやテーブルに影響を与えるため、このチュートリアルを本番以外のアカウント、もしくは新規取得した AWS アカウントで実施することを強く推奨します。また、共有アカウント (例: 会社の開発用アカウント) を使用する場合、他リソースに影響を与えないことを十分にご確認ください。設定変更を行わずにデフォルトの設定を維持したい場合、他アカウントへリソース共有を行う際に追加の作業が必要になります。具体的には、対象のデータベースやテーブルにおいて、デフォルトで付与されている Super 権限を IAMAllowedPrincipals から剥奪する必要があります。この作業の手順は本ブログの後半で紹介します。

プロデューサーアカウントで Lake Formation Data Catalog 設定を変更するには、以下の手順を実施します：

プロデューサーアカウントに Admin ユーザー、もしくは Lake Formation PutDataLakeSettings API 権限を持つユーザーでサインインします
Lake Formation コンソールの左側のナビゲーションペインから Data catalog、次に Settings を選択します
Use only IAM access control for new databases と Use only IAM access control for new tables in new databases のチェックを外します
Save を選択します

加えて、左側ナビゲーションペインの Permissions、次に Administrative roles and tasks 配下の Database creators より IAMAllowedPrincipals の CREATE_DATABASE 権限を削除することが可能です。これにより、新規データベースの作成権限は Lake Formation による管理に集約されます。

CloudFormation を使用して環境を構築

このブログでは二つの CloudFormation テンプレートを提供しています。一つはプロデューサーアカウント用、もう一つはコンシューマーアカウント用です。

プロデューサーアカウント用のテンプレートは以下リソースを作成します：

データレイクとして使用される S3 バケット
サンプルデータをパブリックな S3 バケットからこのチュートリアルで使用するプライベートな S3 バケットにコピーする Lambda 関数 (AWS Lambda-backed CloudFormation カスタムリソース)
IAM ユーザーおよびポリシー
- DataLakeAdminProducer
AWS Glue Data Catalog データベース、テーブルおよびパーティション。このブログでは二通りのクロスアカウント共有方式を紹介するため、データベースおよびテーブルも2つづつ作成されます
- Lake Formation データレイク設定および権限。具体的には以下が含まれます：
- Lake Formation のデータレイク管理者
S3 バケットを Lake Formation のデータレイクロケーションとして登録

コンシューマーアカウント用のテンプレートは以下リソースを作成します：

IAM ユーザーおよびポリシー
- DataLakeAdminConsumer
- DataAnalyst
AWS Glue Data Catalog データベース。このデータベースを使用し、共有されたリソースへの resource link を作成します

プロデューサーアカウントで CloudFormation スタックを起動

プロデューサーアカウントにサインインし、対象のリージョンで CloudFormation コンソールを起動します。
Launch Stack を選択します:
次へを選択します
スタックの名前で任意の名前を入力します (例: stack-producer)
ProducerDatalakeAdminUserName および ProducerDatalakeAdminUserPassword ではデータレイク管理者 IAM ユーザー用に指定したいユーザー名とパスワードを入力します
DataLakeBucketName ではデータレイク用の S3 バケット名を入力します。このバケット名は全世界でユニークである必要があります
DatabaseName および TableName はデフォルトのままにしておきます
次へを選択します
次のページも次へを選択します
最後のページで詳細を確認し、AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認しますにチェックを入れます
スタックの作成を選択します

コンシューマーアカウントで CloudFormation Stack を起動

コンシューマーアカウントで CloudFormation スタックを起動するには以下の手順を実施してください。

プロデューサーアカウントにサインインし、対象のリージョンで CloudFormation コンソールを起動します。
Launch Stack を選択します:
次へを選択します
スタックの名前で任意の名前を入力します (例: stack-consumer)
ConsumerDatalakeAdminUserName および ConsumerDatalakeAdminUserPassword ではデータレイク管理者 IAM ユーザー用に指定したいユーザー名とパスワードを入力します
DataAnalystUserName および DataAnalystUserPassword ではデータアナリスト IAM ユーザー用に指定したいユーザー名とパスワードを入力します
DatabaseName はデフォルトのままにしておきます
AthenaQueryResultS3BucketName では Amazon Athena クエリ結果を保存するための S3 バケット名を入力します。もしバケットが存在しない場合は、S3 バケットを作成しておきます
次へを選択します
次のページも次へを選択します
最後のページで詳細を確認し、AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認しますにチェックを入れます
スタックの作成を選択します

スタックの作成は1分ほどで終わります。

(オプショナル) AWS KMS サーバーサイド暗号化

共有するデータが格納されている S3 バケットが AWS Key Management Service (AWS KMS) customer master key (CMK) により暗号化されている場合、Lake Formation が S3 にアクセスするための IAM ロールが KMS CMK のキーユーザーとして登録されていることをご確認ください。デフォルトでデータアクセスには IAM ロール AWSServiceRoleForLakeFormationDataAccess が使用されますが、S3 データレイクロケーション登録時に別の IAM ロールを指定することも可能です。Lake Formation が使用するロールを KMS キーユーザーとして登録するには AWS KMS コンソールを使用するか、KMS PutKeyPolicy API または AWS Command Line Interface (AWS CLI) よりキーポリシーに権限を記述する方法が取れます。

複数のコンシューマーアカウントに対し共有する場合、キーポリシーに全ての対象アカウントの権限を追加する必要はなく、Lake Formation が使用する IAM Role のみで動作します。また、ソースの S3 バケットが AWS managed key により暗号化されている場合、このステップは不要です。

コンソールから Lake Formation ロールを KMS キーユーザーとして登録する場合、以下の手順を実施してください。

KMS キー管理者として AWS KMS コンソールにサインインします
左側のナビゲーションペインからカスタマー管理型のキーを選択し、S3バケットの暗号化に使用しているキーのエイリアスをクリックします
キーユーザーのセクションで追加を選択します
AWSServiceRoleForLakeFormationDataAccess を選択し、追加を選択します

AWS CLI を使用する場合、以下のコマンドを入力します ( <key-id>, <name-of-key-policy>, および <key-policy> は適宜置き換えてください)

aws kms put-key-policy --key-id <key-id> --policy-name <name-of-key-policy> --policy <key-policy>

詳細は put-key-policy をご参考ください。

Lake Formation クロスアカウント共有の前提条件

Lake Formation でリソースを共有する前に、tag-based access control と named resource 方式いずれも前提条件を満たす必要があります。

Tag-based access control を使用したクロスアカウント共有の前提条件

Lake Formation タグベースのアクセスコントロールのクロスアカウントの前提条件で記載されている通り、タグを使用して別アカウントへリソースのアクセス権を付与する前に、プロデューサーアカウントにて以下 JSON パーミッションを AWS Glue Data Catalog のリソースポリシーに記載する必要があります。これにより、glue:EvaluatedByLakeFormationTags が true の場合、コンシューマーアカウントが Data Catalog にアクセスできるようになります。これは Lake Formation タグを使用し、コンシューマーアカウントに共有されたリソースに適用されます。また、複数 AWS アカウントに共有を行う場合、共有対象の全アカウントに対しこのポリシーを記述する必要があります。

以下のポリシーは Statement の中で定義する必要があります。IAM Policy の完全版は後ほど紹介します。

{
    "Effect": "Allow",
    "Action": [
        "glue:*"
    ],
    "Principal": {
        "AWS": [
            "<consumer-account-id>"
        ]
    },
    "Resource": [
        "arn:aws:glue:<region>:<account-id>:table/*",
        "arn:aws:glue:<region>:<account-id>:database/*",
        "arn:aws:glue:<region>:<account-id>:catalog"
    ],
    "Condition": {
        "Bool": {
            "glue:EvaluatedByLakeFormationTags": true
        }
    }
}

Named resource 方式を使用したクロスアカウント共有の前提条件

AWS Glue と Lake Formation の両方を使用したクロスアカウントアクセス許可の管理で記載されている通り、Data Catalog リソースポリシーが定義されていない場合、Lake Formation クロスアカウントの許可は問題なく行えます。一方、Data Catalog リソースポリシーが存在する場合は、以下のステートメントを追加し named resource 方式による共有を許可する必要があります。もし named resource 方式または tag-based access control 方式のどちらかのみを使用する場合、このステップを省略してください。本チュートリアルでは両方の方式を試すため、このポリシーを追加する必要があります。

以下のポリシーは Statement の中で定義する必要があります。IAM Policy の完全版は次のセクションで紹介します。

{
    "Effect": "Allow",
    "Action": [
        "glue:ShareResource"
    ],
    "Principal": {
        "Service": [
            "ram.amazonaws.com"
        ]
    },
    "Resource": [
        "arn:aws:glue:<region>:<account-id>:table/*/*",
        "arn:aws:glue:<region>:<account-id>:database/*",
        "arn:aws:glue:<region>:<account-id>:catalog"
    ]
}

AWS Glue Data Catalog リソースポリシーを AWS CLI で追加

クロスアカウントの権限付与で named resource 方式と tag-based access control 方式の両方を使用する場合、以下のポリシーを追加する時に EnableHybrid を true と指定する必要があります。現在このオプションはAWSコンソールでサポートされていないため、 glue:PutResourcePolicy API / CLI を使用します。
まず、ポリシードキュメント (例えば policy.json ) を作成し、以下の二つのポリシーを追加します。 <consumer-account-id> には権限が与えられるアカウントのID、<region> には権限を付与するデータベースやテーブルが含まれる Glue Data Catalog のリージョンを、そして <account-id> には共有元であるプロデューサーアカウントの ID をそれぞれ書き換えてください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ram.amazonaws.com"
            },
            "Action": "glue:ShareResource",
            "Resource": [
                "arn:aws:glue:<region>:<account-id>:table/*/*",
                "arn:aws:glue:<region>:<account-id>:database/*",
                "arn:aws:glue:<region>:<account-id>:catalog"
            ]
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "<consumer-account-id>"
            },
            "Action": "glue:*",
            "Resource": [
                "arn:aws:glue:<region>:<account-id>:table/*/*",
                "arn:aws:glue:<region>:<account-id>:database/*",
                "arn:aws:glue:<region>:<account-id>:catalog"
            ],
            "Condition": {
                "Bool": {
                    "glue:EvaluatedByLakeFormationTags": "true"
                }
            }
        }
    ]
}

以下の AWS CLI コマンドを実行します。 <glue-resource-policy> を正しい内容に置き換えます (例えば file://policy.json)。

aws glue put-resource-policy --policy-in-json <glue-resource-policy> --enable-hybrid TRUE

詳細については put-resource-policy を参照してください。

Lake Formation tag-based access control 方式を実装する

このセクションでは、大きく以下の流れで作業を進めていきます：

LF-tag を定義
LF-tag を共有対象のリソースに割り当て
コンシューマーアカウントに LF-tag の権限を付与
コンシューマーアカウントにデータアクセス権限を付与
対象のデータベース、テーブル、カラムに対し IAMAllowedPrincipals の権限を剥奪 (オプショナル)
共有されたリソースへのリソースリンクを作成
LF-tag を作成し対象のデータベースへ割り当て
LF-tag 権限をコンシューマーアカウント内で付与

LF-tag を定義

既にプロデューサーアカウントにサインインしている場合、以下の手順を実施する前にまずサインアウトしてください。

プロデューサーアカウントにデータレイク管理者としてログインします。プロデューサーアカウント ID 及び CloudFromation スタック作成時に指定した IAM ユーザー名 (デフォルトは DatalakeAdminProducer) とパスワードを指定します
Lake Formation コンソールの左メニューの Permissions > Administrative roles and tasks より LF-tags を選択します
Add LF-tag を選択します
キーと値を指定します。このブログでは、LF-tag のキーを Confidentiality とし、値を private, sensitive, 及び public とします
Add LF-tag を選択します

LF-tag を共有対象のリソースに割り当て

データレイク管理者はリソースにタグを割り当てる権限を持っています。他のロールを使用する場合、そのロールに describe 及び attach の権限を付与する必要があります。

コンソールの左メニューの Data Catalog 配下にある Databases を選択します
共有対象であるデータベース (lakeformation_tutorial_cross_account_database_tbac) を選択し、Actions メニューより Edit LF-tags を選択します

このブログではデータベースに LF-tag を付与していますが、LF-tag はテーブルやカラムに付与することも可能です。

Assign new LF-tag を選択します
Assigned keys に Confidentiality、 Values に public を指定します
Save を選択します

コンシューマーアカウントに LF-tag の権限を付与

プロデューサーアカウント内でコンシューマーアカウントに対し LF-tag に対する権限を付与します。

コンソールの左メニューの Permissions > Administrative roles and tasks > LF-tag permissions で Grant を選択します
Principals には External accounts を選択します
対象の AWS アカウント ID (コンシューマーのアカウント ID) を指定します

同じ Organization の AWS アカウントは自動的に表示されます。一方、同じ Organization に属さない AWS アカウントは手動でアカウント ID を入力する必要があります。本ブログ執筆時点で Lake Formation tag-based access control は organizations や organization units に対する権限付与はサポートしていません。

LF-Tags ではコンシューマーアカウントに対し共有する LF-tag のキーと値を選択します (キーは Confidentiality、値は public)
Permission では LF-tag permissions の Describe を選択します
Grant を選択します

この時点でコンシューマーアカウントのデータレイク管理者は Lake Formation コンソール配下の Permissions > Administrative roles and tasks > LF-tags 画面で共有されたタグを確認することができます。

コンシューマーアカウントにデータアクセス権限を付与

ここでは実際にコンシューマーアカウントに LF-tag を用いてデータアクセス権を付与します。これにより、コンシューマーアカウントは LF-tag が付与されているテーブルやデータベースのデータにアクセスできるようになります。

コンソール左メニューの Permissions > Data lake permissions より Grant を選択します
Principals には External accounts を選択し、コンシューマーアカウントの AWS アカウント ID を入力します
LF-tags or catalog resources の部分で Resources matched by LF-Tags (recommended) を選択し、Add LF-Tag を選択します
コンシューマーアカウントに対し共有する LF-tag のキーと値を選択します (キーは Confidentiality、値は public)
Database permission では Describe 権限を Database permissions で追加し、データベースレベルの権限を定義します
Grantable permission では Describe 権限を追加し、コンシューマーアカウント内でユーザーに対し付与できるデータベースレベルの権限を定義します
Table and column permissions では Select と Describe 権限を Table permissions で追加します
Grantable permissions では Select と Describe 権限を追加します
Grant を選択します

対象のデータベース、テーブル、カラムに対し IAMAllowedPrincipals の権限を剥奪 (オプショナル)

このチュートリアルの冒頭で Lake Formation Data Catalog 設定の変更を行いました。もし冒頭で設定変更を行なっていない場合はこの手順を実施いただく必要がありますが、変更した場合はこの手順をスキップして問題ありません。

このステップでは、 IAMAllowedPrincipals にデフォルトで付与されているデータベースやテーブルへの Super 権限を剥奪します。詳細は既存のデータカタログリソースの保護をご参考ください。IAMAllowedPrincipals の権限を剥奪する前に、既存の IAM プリンシパルに対し Lake Formation 経由で必要な権限を付与していることを確認してください。これには2つのステップが含まれます：

対象の IAM ユーザーやロールに Lake Formation GetDataAccess アクションの IAM 権限を付与します (IAM ポリシーで定義)
対象の IAM ユーザーやロールに Lake Formation データアクセス権 (alter, select など) を付与します

これらを実施した上でIAMAllowedPrincipals の権限を剥奪します。上記ステップをスキップしてしまうと権限剥奪後に既存の IAM プリンシパルは対象のデータベースやテーブルにアクセスできなくなります。IAMAllowedPrincipals の Super 権限剥奪は (IAM ポリシーモデルではなく) Lake Formation 権限管理モデルを適用し、同一アカウント内あるいはクロスアカウントでアクセス管理を行う際に必要です。従来の IAM ポリシーモデルで管理したい他のテーブルやデータベースで IAMAllowedPrincipals の権限剥奪は不要です。

この時点でコンシューマーアカウントのデータレイク管理者は対象のデータベースとテーブルをコンシューマーアカウントの Lake Formation コンソール左メニュー Data catalog > Databases から確認することができます。もし見つからない場合、以下が正しく設定されているか確認してください：

対象のデータベースやテーブルに正しいタグが付与されいる
コンシューマーアカウントに正しいタグ権限とデータアクセス権が付与されている
IAMAllowedPrincipals に対しデフォルトで付与されているデータベースやテーブルへの Super 権限が剥奪されている

共有されたリソースへのリソースリンクを作成

アカウント間で共有されたリソースはコンシューマーアカウントのカタログに直接登録されません。リソースを利用可能にし、Athena などのサービスを使用して実際のデータをクエリするためには共有されたリソースに対しリソースリンクを作成する必要があります。リソースリンクは一種の Data Catalog オブジェクトであり、ローカルまたは共有されたデータベースやテーブルに対するリンクです。リソースリンクを作成することにより、

コンシューマーアカウント側の Data Catalog リソース命名規則に従ってデータベース名やテーブル名を定義できます
Athena や Amazon Redshift Spectrum などのサービスを使用して共有されたデータベースやテーブルをクエリできます

以下の手順に従ってリソースリンクを作成します。

既にコンシューマーアカウントにサインインしている場合、まずサインアウトする
コンシューマーアカウントにデータレイク管理者としてログインします。プロデューサーアカウント ID 及び CloudFromation スタック作成時に指定した IAM ユーザー名 (デフォルトは DatalakeAdminConsumer) とパスワードを指定します
Lake Formation コンソールの左メニュー Data catalog > Databases 配下で共有されたデータベース
lakeformation_tutorial_cross_account_database_tbac を選択します

もしデータベースが見つからない場合は前のセクションで記載されている項目が正しく設定されているか確認してください。

View tables を選択します
共有されたテーブル amazon_reviews_table_tbac を選択します
Actions メニューから Create resource link を選択します

Resource link name で名前を入力します (本ブログでは amazon_reviews_table_tbac_resource_link)
Database ではリソースリンクが作成されるデータベースを選択します (本ブログでは CloudFormation Stack により作成されたデータベース lakeformation_tutorial_cross_account_database_consumer を使用します)
Create を選択します

リソースリンクは Lake Formation コンソール左メニュー Data catalog 配下の Tables から確認できます。

LF-tag を作成し対象のデータベースへ割り当て

Lake Formation タグはリソースと同じカタログに存在します。つまり、プロデューサーアカウントで作成されたタグはコンシューマーアカウントでリソースリンクに対するアクセス権を付与するためには使用できません。追加でコンシューマーアカウントで Lake Formation tag-based access control を使用してリソースリンクへのアクセス権を制御するには別の LF-tag をコンシューマーアカウントで作成する必要があります。まずは過去の手順を参照しながら LF-tag を作成します。

コンシューマーアカウントで LF-tag を定義します。このブログでは、このブログでは、LF-tag のキーを Division とし、値を sales, marketing, 及び analyst とします

リソースリンクが作成されたデータベース lakeformation_tutorial_cross_account_database_consumer に対し、LF-tag キー Division、値 analyst を付与します

LF-tag 権限をコンシューマーアカウント内で付与

最後のステップとして、コンシューマーに対し LF-tag データアクセス権限を付与します。

コンソール左メニューの Permissions > Data lake permissions より Grant を選択します
Principals には IAM users and roles を選択し、IAM ユーザー DataAnalyst を選択します
LF-tags or catalog resources の部分で Resources matched by LF-tags (recommended) を選択します
Key は Division を、Values は analyst を選択します
Database permission では Describe 権限を Database permissions で追加します
Table and column permissions では Select と Describe 権限を Table permissions で追加します
Grant を選択します
上記 1 から 7 を繰り返します。対象は同じ IAM ユーザー DataAnalyst 、LF-tag Key は Confidentiality 、Values は public を指定します

この時点でコンシューマーアカウントのデータ分析ユーザー (IAM ユーザー DataAnalyst) はデータベースおよびリソースリンクを確認することができ、Athena コンソールから共有されたテーブルをクエリできるようになります。
問題が起きている場合、以下が正しく実装されているか確認してください：

共有されたテーブルに対しリソースリンクが作成されている
分析ユーザーに対し、プロデューサーアカウントから共有された LF-tag へのアクセス権を付与している
分析ユーザーに対し、リソースリンク及びリソースリンクが作成されたデータベースに割り当てられた LF-tag のアクセス権を付与している
リソースリンク及びリソースリンクが作成されたデータベースに正しい LF-tag が割り当てられている

Lake Formation named resource 方式を実装する

このセクションでは Named resource 方式を使用してリソースを共有します。大きく以下の流れで作業を進めていきます：

対象のデータベース、テーブル、カラムに対する IAMAllowedPrincipals の権限を剥奪 (オプショナル)
コンシューマーアカウントにデータアクセス権限を付与
AWS RAM リソース共有を承認
共有されたリソースへのリソースリンクを作成
共有されたリソースへのデータアクセス権限をコンシューマーに付与
リソースリンクへのデータアクセス権限をコンシューマーに付与

対象のデータベース、テーブル、カラムに対する IAMAllowedPrincipals の権限を剥奪 (オプショナル)

このチュートリアルの冒頭で Lake Formation Data Catalog 設定の変更を行いました。もし冒頭で設定変更を行なっていない場合はこの手順を実施いただく必要がありますが、変更した場合はこの手順を省略して問題ありません。具体的な手順は前のセクションで紹介されたものをご参考ください。

コンシューマーアカウントにデータアクセス権限を付与

既にプロデューサーアカウントにサインインしている場合、以下の手順を実施する前にまずサインアウトしてください。

プロデューサーアカウントにデータレイク管理者としてログインします。プロデューサーアカウント ID 及び CloudFromation スタック作成時に指定した IAM ユーザー名 (デフォルトは DatalakeAdminProducer) とパスワードを指定します
コンソール左メニューの Permissions > Data lake permissions より Grant を選択します
Principals には External accounts を選択し、コンシューマーアカウントの AWS アカウント ID または AWS Organizations ID を入力します

同じ Organization の AWS アカウントは自動的に表示されます。一方、同じ Organization に属さない AWS アカウントは手動でアカウント ID を入力する必要があります。

LF-tags or catalog resources の部分で Named data catalog resources を選択します
Database にはデータベース lakeformation_tutorial_cross_account_database_named_resource を選択します
Tables の部分で All tables を選択します
Table and column permissions では Select と Describe 権限を Table permissions で追加します
（オプショナル）カラムレベルの権限管理を行いたい場合、Data permissions で Simple column-based access を選択します
Grant を選択します

IAMAllowedPrincipals に対する権限を剥奪していない場合、Grant permissions failed のエラーが表示されます。
この時点で対象とするテーブルが AWS RAM を通じてコンシューマーに共有されていることを Permissions 配下の Data permissions 画面で確認することができます。

AWS RAM リソース共有を承認

この手順はアカウントID ベースの共有で必要とされており、Organizations ベースの共有では不要です。

コンシューマーアカウントにデータレイク管理者としてログインします。プロデューサーアカウント ID 及び CloudFromation スタック作成時に指定した IAM ユーザー名 (デフォルトは DatalakeAdminConsumer) とパスワードを指定します
AWS RAM コンソールの左メニュー Shared with me (日本語だと「自分と共有」) 配下の Resource share (日本語だと「リソースの共有」) より共有された Lake Formation リソースを選択します

ステータスは Pending になっているはずです

リソースの詳細を確認し、Accept resource share (日本語だと「リソースの共有を承認」) を選択します

この時点でコンシューマーアカウントのデータレイク管理者は共有されたリソースをコンシューマーアカウントの Lake Formation コンソール左メニュー Data catalog > Databases 配下で確認することができます。

共有されたリソースへのリソースリンクを作成

前のセクションで紹介した手順に従って共有されたテーブルへのリソースリンクを作成します。リソースリンク名にはamazon_reviews_table_named_resource_resource_link を指定し、データベースlakeformation_tutorial_cross_account_database_consumer に作成します。

共有されたリソースへのデータアクセス権限をコンシューマーに付与

データ分析ユーザーに対し共有されたテーブルへのデータアクセス権を付与するには以下の手順を実施します：

コンソール左メニューの Permissions > Data lake permissions より Grant を選択します
Principals には IAM users and roles を選択し、IAM ユーザー DataAnalyst を選択します
LF-tags or catalog resources の部分で Named data catalog resources を選択します
Databases ではデータベース lakeformation_tutorial_cross_account_database_named_resource を選択します

もし選択項目の中から対象のデータベースが見つからない場合、Load more を選択します

Tables ではテーブル amazon_reviews_table_named_resource を選択します
Table and column permissions では Select と Describe 権限を Table permissions で追加します
Grant を選択します

リソースリンクへのデータアクセス権限をコンシューマーに付与

データ分析ユーザーに対し共有されたテーブルへの権限だけでなく、リソースリンクへの権限も追加する必要があります。

コンソール左メニューの Permissions > Data lake permissions より Grant を選択します
Principals には IAM users and roles を選択し、IAM ユーザー DataAnalyst を選択します
LF-tags or catalog resources の部分で Named data catalog resources を選択します
Databases ではデータベース lakeformation_tutorial_cross_account_database_consumer を選択します
Tables ではテーブル amazon_reviews_table_named_resource_resource_link を選択します
Resource link permissions では Describe 権限を Resource link permissions で追加します
Grant を選択します

この時点でコンシューマーアカウントのデータ分析ユーザー (IAM ユーザー DataAnalyst) はデータベースおよびリソースリンクを確認することができ、Athena コンソールから共有されたテーブルをクエリできるようになります。

上手くいかない場合、以下が正しく実装されているか確認してください：

共有されたテーブルに対しリソースリンクを作成している
データ分析ユーザーに対し、共有されたテーブルへのアクセス権限を付与している
データ分析ユーザーに対し、リソースリンクおよびリソースリンクが作成されているデータベースへのアクセス権限を付与している

環境削除

このチュートリアルで作成されたリソースを削除するには以下リソースの削除または設定変更を行なってください：

プロデューサーアカウント
- AWS RAM リソース共有
- Lake Formation タグ
- CloudFormation スタック
- Lake Formation 設定
- AWS Glue Data Catalog 設定
コンシューマーアカウント
- Lake Formation タグ
- CloudFormation スタック

まとめ

Lake Formation のクロスアカウント共有機能を活用することで、実データのコピーをせず他の AWS アカウントとデータ共有が簡単に実現できます。また、プロデューサーとコンシューマーの両方においてデータアクセス権を柔軟に定義することができます。このブログでは、Lake Formation を使用し別AWSアカウントにあるカタログデータを参照する二種類の方法について紹介しました：

Tag-based access control
Named resource

Tag-based access control 方式はリソースやエンティティの数が多いユースケースで推奨します。このブログでは設定項目が多いように見えますが、tag-based access control 方式によってデータレイク管理者はユーザーとリソース間の関係性をタグで動的に管理できるメリットがあります。Named resource 方式はデータレイク管理者に対し、より直感的にカタログ権限を管理する手段を提供します。ぜひ要件に応じて最適な方法を選択してください。

このブログはソリューションアーキテクト金杉が執筆及び翻訳を行いました。
原文はこちらをご参照ください: https://thinkwithwp.com/jp/blogs/big-data/securely-share-your-data-across-aws-accounts-using-aws-lake-formation/

Amazon Web Services ブログ

Lake Formation を使用し AWS アカウント間でセキュアにデータ共有を実現

Tag-based access control の概要

Named resource 方式の概要

Lake Formation Data Catalog 設定をプロデューサーアカウントで実施

CloudFormation を使用して環境を構築

プロデューサーアカウントで CloudFormation スタックを起動

コンシューマーアカウントで CloudFormation Stack を起動

(オプショナル) AWS KMS サーバーサイド暗号化

Lake Formation クロスアカウント共有の前提条件

Tag-based access control を使用したクロスアカウント共有の前提条件

Named resource 方式を使用したクロスアカウント共有の前提条件

AWS Glue Data Catalog リソースポリシーを AWS CLI で追加

Lake Formation tag-based access control 方式を実装する

LF-tag を定義

LF-tag を共有対象のリソースに割り当て

コンシューマーアカウントに LF-tag の権限を付与

コンシューマーアカウントにデータアクセス権限を付与

対象のデータベース、テーブル、カラムに対し IAMAllowedPrincipals の権限を剥奪 (オプショナル)

共有されたリソースへのリソースリンクを作成

LF-tag を作成し対象のデータベースへ割り当て

LF-tag 権限をコンシューマーアカウント内で付与

Lake Formation named resource 方式を実装する

対象のデータベース、テーブル、カラムに対する IAMAllowedPrincipals の権限を剥奪 (オプショナル)

コンシューマーアカウントにデータアクセス権限を付与

AWS RAM リソース共有を承認

共有されたリソースへのリソースリンクを作成

共有されたリソースへのデータアクセス権限をコンシューマーに付与

リソースリンクへのデータアクセス権限をコンシューマーに付与

環境削除

まとめ

お役立ちリンク

フォローお願いいたします