Lake Formationのハイブリッドアクセスモードとタグベースアクセス制御を検証
はじめに
KINTOテクノロジーズのデジタル戦略部DataOpsG所属の西です。
普段は社内のデータ分析基盤の開発・保守・運用を担当しています。
データガバナンスの一環としてのデータ分析基盤へのアクセス制御のため、AWS Lake Formation、その機能であるハイブリッドアクセスモードとLFタグを扱う機会がありました。
はじめてLake Formationを触ると、その仕様や用語を理解するだけでも大変だと思います。(自分は、なかなか苦労しました。)
そのため本記事ではLake Formationの主要な概念や設定方法をご紹介します。
- Data lake locations、Data permissions、Data locations、IAMAllowedPrincipalsについて
- ハイブリッドアクセスモードについて
- LFタグによるアクセス制御について
- ハイブリッドアクセスモード、LFタグによるアクセス制御の設定方法
またLake Formationを触って気づいた注意点として、下記を本稿後半の注意点に記します
- ハイブリッドアクセスモード運用における新規作成IAMロールの関係について
- ハイブリッドアクセスモードとCloudFormation
- Amazon Athenaビューへのアクセス制御
AWS Lake Formation
データ分析基盤のデータカタログにGlueデータカタログを採用している場合、IAMポリシーやS3バケットポリシーよりもさらにきめ細かいアクセス制御を実施するには Lake Formationの導入検討が必要になると思います。
Lake Formation自体の詳細はAWSから出ている下記ドキュメントをあたってください。
- デベロッパーガイド
- AWS Black Belt ← 個人的に、Lake Formationの概要を掴むのにわかりやすい資料でした
Data lake locations
Lake Formationでアクセス制御する対象を登録する機能
- 対象:S3パス
- 説明:ここに登録されたS3パス配下をLake Formationによるアクセス制御対象として登録する
- 例:Glueデータカタログ上のデータベースをアクセス制御したい場合、データベースのS3ロケーションはData lake locationsに登録されたS3パス配下である必要がある
- 注意点:ここにS3パスを登録するだけではLake Formationによるアクセス制御は実施されない
Data locations
- 対象:プリンシパル[1] とS3パス
- 説明:Glueデータカタログのデータベースやテーブルへの作成や変更の権限を付与する。ここで行う設定はデータロケーション(S3リソース)へのメタデータをプリンシパルに作成、変更する権限
Data permissions
- 対象:プリンシパル、Glueデータカタログのデータベースやテーブル
- 説明:下記のアクセス権限をプリンシパルに付与する
- データベースに対して Create Table、Alter、Update、Drop、Describe
- テーブルに対して Select、Insert、Delete、Describe、Alter、Drop
- 注意点:
- Data lake locationsの設定を事前におこなっておく
- メタデータを作成、変更する権限(Create Table/Alterなど)をData locationsで事前に設定しておく
AWS Black Belt のP19,P20 がわかりやすいです。
IAMAllowedPrincipals
IAMAllowedPrincipals について
Lake Formation 許可のリファレンス に下記の通り説明があります。(2025/11)
「Lake Formation は、データカタログ内のすべてのデータベースとテーブルに対する Super アクセス許可を、デフォルトで IAMAllowedPrincipals というグループに設定します。このグループアクセス許可がデータベースまたはテーブルに存在する場合、アカウント内のすべてのプリンシパルが、 AWS Glueの IAM プリンシパルポリシーを介してリソースにアクセスできるようになります。」
IAMAllowedPrincipalsにSuper権限があるため、Lake Formationのデフォルト設定時では、GlueデータカタログリソースにIAMポリシーでアクセスが可能です。
Glueデータカタログのデータベースやテーブルのアクセス制御について、IAMポリシーでのアクセス制御からLake Formationでのアクセス制御に移行するには
- IAMAllowedPrincipalsの設定の排除が必要
- それぞれのIAMプリンシパルに対して、Lake Formationでアクセス制御(メタデータ、データロケーションへの制御)を設定する
上記を実施する場合、既存IAMプリンシパルの棚卸が必要になります。
この棚卸に漏れがあると、GlueデータカタログのリソースにアクセスできないIAMプリンシパルが発生することに注意が必要です。
また、Lake Formationのアクセス制御を解除し元のIAMによるアクセス制御に戻す際は、手順の逆を実施することになります。
- こちらにその手順とスクリプトが公開されています Using only IAM access controls
ハイブリッドアクセスモード
これまでの方式では、Lake Formationでアクセス制御を実施するには、IAMAllowedPrincipalsの設定を排除しLake Formationを設定する必要があります。(この方式はLake Formationモードと呼ばれます)
一方、ハイブリッドアクセスモードの場合はIAMAllowedPrincipalsが付与されていてもLake Formationのアクセス制御が優先されるため、IAMAllowedPrincipalsの設定を排除せずにLake Formationのアクセス制御を有効にできます。
つまり、IAMAllowedPrincipalsが付与されていてもLake Formationによる制御を強制的に⾏わせる機能です。そのため、上述のIAMプリンシパルの棚卸を行わずにLake Formationによるアクセス制御を有効にできます。
ハイブリッドアクセスモードの場合、下記が可能になります。
- 選択したリソースとプリンシパルについてLake Formationのアクセス制御を有効化(ハイブリッドアクセスモードのオプトイン)
- Lake Formationアクセス制御を解除するには、ハイブリッドアクセスモードのオプトインを解除する
LFタグ
Glueデータカタログのリソース(データベース、テーブル、カラム)にタグを割り当て、そのタグに基づいてプリンシパルにアクセス権限を付与するための機能です。
- LFタグを定義(例: Key=Confidential, Value=True/False)
- リソースにLFタグを付与する
- プリンシパルに、LFタグに対するアクセス権を付与する
LFタグを使うと、リソースとプリンシパル間の権限関係を疎結合に保つことができます。
LFタグを使わない場合、リソースとプリンシパル間で直接アクセス権を設定する必要があります。この場合、リソースやプリンシパルが増えると、アクセス権の管理が煩雑になります。
設定方法
以下、Lake FormationのハイブリッドアクセスモードとLFタグ方式によるアクセス制御の手順を記します。
前提条件
今回は、下記のペルソナのもとアクセス制御を実施したいと思います。
ペルソナとLFタグ
| ペルソナ | 役割 | 対象IAMロール名 | 対象LFタグ | 許可する権限 |
|---|---|---|---|---|
| データレイク管理者 | Lake Formationの操作権 | lf-test-001 | Confidential = True, False | Super |
| データユーザー | 許可されたテーブルにアクセスできる | lf-test-001-user | Confidential = False | Select、Describe |
手順
Lake Formationでアクセス制御を実施するには、大まかには、下記を実施します。
- データレイク管理者に登録する
- Glueデータカタログのメタデータへのアクセス制御のため、S3パスをData lake locationsに登録し、そのS3パスをLake Formationで制御可能状態にする
- Glueデータカタログのメタデータの作成の制御として、Data locationsの設定。これでテーブルのCreateやAlter権限をLake Formationで付与
- LFタグの設定
Data lake administratorsの設定

- Lake Formationの操作設定権をIAMロールに付与する
- Data lake administratorとして今回はlf-test-001というIAMロールをセットする
Data lake locationsの設定

- GlueデータカタログのデータベースのS3ロケーションを設定する
- Hybrid access modeを選択する
Data locationsの設定

-
Data locationsの設定として、ハイブリッドアクセスモードでアクセス制御をしたいプリンシパルと制御対象のS3プレフィックスを登録する
-
この制御対象のS3プレフィックスはGlueデータカタログのデータベースのうち、ハイブリッドアクセスモードでアクセス制御したいデータベースのS3ロケーションを設定している
LFタグを作成

- キーはConfidential、バリューはTrue、Falseを作成する
LFタグへのアクセス権を設定
「Permissions」の「Data permissions」からアクセス権を設定します。

- Lake Formationで権限を渡したいプリンシパルを選択する
- Lake Formationで管理したいLFタグを選択する
- 今回は、lf-test-001-userというIAMロールに対して、LFタグのキーがConfidentialでバリューがFalseにアクセス権を付与する

- Lake Formationで許可したいアクセス権を選択する
- lf-test-001-userはキーがConfidential、バリューがFalseのリソースに対して、データベースの場合Describeを付与、テーブルの場合Select、Describeを付与する
LFタグを管理対象リソースに設定する
今回はconfidential というデータベースのtable_001、table_002 というテーブルに下表のようにLFタグを付与します。
| データベース名 | テーブル名 | LFタグのキー名 | LFタグのバリュー名 |
|---|---|---|---|
| confidential | table_001 | Confidential | True |
| confidential | table_002 | Confidential | False |


- table_001にはキー=Confidentialのバリュー=True、table_002にはキー=Confidentialのバリュー=Falseを設定する
ハイブリッドアクセスモードを有効化する

- 管理したいリソース(テーブル)を設定
- 今回はデータベースを設定しないため、データベースはIAMポリシーでのアクセス制御が継続される
- アクセス制御したいプリンシパルを設定
動作確認

アクセスさせないテーブルについて
- lf-test-001-user にスイッチロールするとConfidential=Trueであるtable_001はUI上から見えない
- confidential.table_001 へのクエリは失敗する

アクセス許可しているテーブルについて
- Confidential=Falseであるtable_002 はUI上から見える
- confidential.table_002 へのクエリは成功する
解除手順

- ハイブリッドアクセスモードをRemove(解除)することでLake Formationによるアクセス制御は解除される
注意点
最後にLake Formationを触ってみて気づいた注意点を書いておきます。
- 異なるキーのLFタグによるリソースへのアクセス制御はLFタグの AND条件ではなく OR条件になる
- 例:キーがConfidential=TrueのLFタグとキーがDepartment=SalesのLFタグが付与されたリソースに対しては、プリンシパルにキーがConfidential=TrueのLFタグへのアクセス権またはキーがDepartment=SalesのLFタグへのアクセス権を持つ場合、アクセス可能になる
- 運用時にはハイブリッドアクセスモードでは新規作成されたIAMロールには対応できない。Lake Formation管理者とIAM管理者が異なる場合、Lake Formation管理者が予期せぬIAMロールがGlueデータカタログにアクセスする可能性がある
- ハイブリッドアクセスモードのオプトイン操作はCloudFormationには現時点で非対応と思われる。
- ハイブリッドアクセスモードのオプトインの実施(CreateLakeFormationOptIn)が必要だが、CloudFormationには現時点では見当たらない。[2]
- CloudFormationでリソースの作成後、下記が必要なのではないかと思われる。(今後の検証が必要)
- Lake FormationコンソールやAWS CLIなどでプリンシパルのオプトインの設定を行う
- CloudFormationのカスタムリソースを用いて、Lambda関数からCreateLakeFormationOptIn APIを実行する
- Athenaで作成したビューに対するアクセス制御は基礎となるテーブルの権限と一致させておく必要がある。そのためAthenaビューとテーブルのアクセス制御は同じものとなる[3]
- ※1 データカタログビューを使うとテーブルとは異なるアクセス制御をビューに設定できる。[4]
- ※2 データカタログビューはハイブリッドアクセスモードのIAMAllowedPrincipalsを排除が不要という恩恵を受けられない [5]
- データカタログビューの作成には下記が必要
- データカタログビュー作成にはIAMAllowedPrincipalsのアクセス権限をビューの基のテーブルから外す
- テーブルが所属するデータベースからデフォルトで設定されている[Use only IAM access control for new databases] を外す
- データカタログビューを作成するIAMロールに対して、Lake Formationでビューの基のテーブルに対するアクセス権限を設定する
あとがき
Lake Formationを使うとGlueデータカタログのリソースに対してきめ細かいアクセス制御が可能になることは分かりました。
一方で、Lake Formation自体の理解と設定に学習コストがかかる印象を受けました。
そのためチーム内で知見を十分に共有できていないと、誰もアクセスできないリソースが発生しそれを解決できる人間がわずかしかいないという状況に陥りかねないと感じました。ドキュメントの整備、ハンズオンの実施などでチーム内の知見を高めることが重要と思います。
また、Lake Formation管理下のテーブルとビューのアクセス制御については、テーブルとビューで異なるアクセス制御を実施したい場合は注意が必要です。
既存のIAMロールの管理体制、Glueデータカタログの運用方法とLake Formationの仕様を十分に検証することが重要と思います。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_principal.html ↩︎
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/TemplateReference/aws-resource-lakeformation-resource.html ↩︎
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/lf-athena-limitations.html#lf-athena-limitations-permissions-to-views ↩︎
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/views.html#when-to-use-views-gdc ↩︎
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/views-glue.html#views-glue-limitations ↩︎
関連記事 | Related Posts
We are hiring!
【クラウドエンジニア】Cloud Infrastructure G/東京・大阪・福岡
KINTO Tech BlogWantedlyストーリーCloud InfrastructureグループについてAWSを主としたクラウドインフラの設計、構築、運用を主に担当しています。
【クラウドエンジニア(クラウド活用の推進)】Cloud Infrastructure G/東京・大阪・福岡
KINTO Tech BlogCloud InfrastructureグループについてAWSを主としたクラウドインフラの設計、構築、運用を主に担当しています。


