Lake Formation講座
この講座では、データレイクの構築・管理・セキュリティを一元化するサービスであるAWS Lake Formationについて学びます。
- AWS Lake Formationの概要と役割
- データレイクの課題とLake Formationによる解決
- Lake Formationの主要機能（データカタログ統合・アクセス制御・データ登録）
- きめ細かなアクセス制御（カラムレベル・行レベル）
- LF-Tagによるタグベースのアクセス制御
- データレイク管理者の役割
- 設計のポイント
| 💡 ポイント |
|---|
| Lake Formationはアクセス制御の設定項目が多く、講座の説明だけではイメージがつきにくい部分もあるかもしれません。次の講座でLF-Tagを使ったアクセス制御のハンズオンを行いますので、まずはこの講座で全体像を把握することを意識して読み進めてください。 |
1. Lake Formationの概要
1.1 AWS Lake Formationとは
AWS Lake Formationは、安全なデータレイク（大量の生データを一元的に保管する仕組み）を短期間で構築・管理するためのフルマネージドサービスです。データの収集、カタログ化、クレンジング（不要データの除去や形式の統一）、変換、セキュリティ設定を一元的に管理できます。
Lake Formationの中核的な役割は、データレイク全体のアクセス制御とガバナンス（データの管理・統制）です。「誰が」「どのデータに」「どのような操作を」行えるかを、一箇所で管理できます。
以下は、Lake Formationがデータレイクのアクセス制御を一元管理する構成を示した図です。
flowchart TB
A[Lake Formation<br>アクセス制御・ガバナンス]
B[Glue データカタログ<br>スキーマ管理]
C[Amazon S3<br>データレイク]
A --- B
B --- C
D[Athena] -->|権限チェック| A
E[Glueジョブ] -->|権限チェック| A
F[QuickSight] -->|権限チェック| A
1.2 なぜLake Formationが必要なのか
S3をデータレイクとして利用する場合、従来はデータへのアクセス制御を以下の方法で個別に設定する必要がありました。
- S3バケットポリシーでバケットレベルのアクセス制御を設定する
- IAMポリシーでユーザ・ロールレベルのアクセス制御を設定する
- Glueデータカタログの権限でデータベース・テーブルレベルのアクセス制御を設定する
これらを個別に管理していると、いくつかの問題が発生します。まず、複数のサービスにまたがる権限設定が煩雑になり、権限管理が複雑化します。また、S3バケットポリシーやIAMポリシーではテーブル内の特定のカラムへのアクセスを制御できないため、カラムレベルのきめ細かな制御が困難です。さらに、「誰がどのデータにアクセスできるか」を横断的に把握しにくく、監査が難しくなるという課題もあります。
Lake Formationは、これらの権限管理を一箇所に集約し、テーブルレベル・カラムレベルのきめ細かなアクセス制御を実現します。カラムレベル・行レベル・セルレベルのデータフィルタリングのしくみはData filtering and cell-level security in Lake Formation（AWS Lake Formation公式ドキュメント）で詳しく解説されています。
| 💡 ポイント |
|---|
| Lake Formationは「データレイクのセキュリティと管理を簡素化する」ためのサービスです。特にデータを複数のチームやユーザで共有する場合に、その価値が大きくなります。小規模な構成ではIAMポリシーだけで十分なこともありますが、データの種類やユーザが増えるにつれてLake Formationの必要性が高まります。 |
2. Lake Formationの主要機能
2.1 データレイクの登録
Lake Formationでは、まずS3上のデータ保存場所をデータレイクロケーションとして登録します。登録することで、そのS3パスに保存されたデータをLake Formationの管理下に置くことができます。
登録されたS3パスのデータに対するアクセスは、S3バケットポリシーやIAMポリシーではなく、Lake Formationの権限設定で制御されるようになります。
2.2 Glueデータカタログとの統合
Lake Formationは、Glueデータカタログの上位レイヤーとして機能します。Glueデータカタログで管理されているデータベースやテーブルに対して、Lake Formationから権限を付与・制御できます。
つまり、データの構造（スキーマ）はGlueデータカタログで管理し、データへのアクセス権限はLake Formationで管理する、という役割分担になります。
2.3 アクセス制御
Lake Formationのアクセス制御は、以下のレベルで設定できます。
| 制御レベル | 説明 | 例 |
|---|---|---|
| データベースレベル | データベース全体へのアクセスを制御 | sales_dbへの全アクセスを許可 |
| テーブルレベル | 特定のテーブルへのアクセスを制御 | sales_dataテーブルのみ読み取りを許可 |
| カラムレベル | テーブル内の特定カラムへのアクセスを制御 | 個人情報カラム（名前、電話番号）を非表示にする |
| 行レベル | 特定の条件に合致する行のみアクセスを許可 | region = '東京' の行のみ表示 |
2.4 権限の付与モデル
Lake Formationでは、以下の権限を組み合わせてアクセスを制御します。
| 権限 | 説明 |
|---|---|
| SELECT | テーブルのデータを読み取る |
| INSERT | テーブルにデータを挿入する |
| DELETE | テーブルのデータを削除する |
| DESCRIBE | テーブルのメタデータ（スキーマ情報）を参照する |
| ALTER | テーブルの定義を変更する |
| DROP | テーブルを削除する |
| CREATE_TABLE | データベース内にテーブルを作成する |
| CREATE_DATABASE | データカタログにデータベースを作成する |
3. カラムレベルのアクセス制御
3.1 ユースケース
カラムレベルのアクセス制御は、特に個人情報や機密情報を含むデータを扱う場合に重要です。
例えば、顧客データのテーブルに以下のカラムがあるとします。
| カラム名 | 内容 | 機密性 |
|---|---|---|
| customer_id | 顧客ID | 低 |
| name | 氏名 | 高（個人情報） |
| メールアドレス | 高（個人情報） | |
| phone | 電話番号 | 高（個人情報） |
| region | 地域 | 低 |
| total_purchases | 購入総額 | 中 |
この場合、Lake Formationを使って以下のように権限を設定できます。
- マーケティングチームには customer_id, region, total_purchases のみ閲覧可能とし、個人を特定できる情報は非表示にする
- カスタマーサポートチームには全カラムの閲覧を許可する（顧客対応に氏名・連絡先が必要なため）
- データ分析チームには customer_id, name, region, total_purchases の閲覧を許可する（名前は分析に必要だが、連絡先は不要）
| 💡 ポイント |
|---|
| IAMポリシーでは「S3バケットやオブジェクト単位」のアクセス制御はできますが、「テーブルの特定のカラムだけを見せる・隠す」といった制御はできません。カラムレベルのアクセス制御は、Lake Formationならではの機能です。 |
| 💡 ポイント |
|---|
| カラムレベルのアクセス制御は、データのマスキング（値を「*」などに置き換えて隠す処理）とは異なります。マスキングではカラム自体は見えるものの値が隠されるのに対し、Lake Formationのカラムレベル制御では、権限のないカラムはクエリ結果にそもそも含まれません**。カラムの存在自体を意識させない、より厳密なアクセス制御が可能です。 |
3.2 包含と除外の方式
カラムレベルのアクセス制御には、2つの設定方式があります。
| 方式 | 説明 | 適したケース |
|---|---|---|
| 包含（Include） | 指定したカラムのみアクセスを許可 | アクセス可能なカラムが少ない場合 |
| 除外（Exclude） | 指定したカラムへのアクセスを拒否 | アクセス不可のカラムが少ない場合 |
4. 行レベルのセキュリティ
4.1 行フィルタリング
行レベルのセキュリティ（Row-Level Security）は、テーブル内の特定の行のみをユーザに表示する機能です。データフィルタを定義し、条件に合致する行のみがクエリ結果に含まれるようにします。
例えば、地域別の営業チームに対して、自分の担当地域のデータのみを表示させることができます。
| ユーザ/グループ | フィルタ条件 | 表示されるデータ |
|---|---|---|
| 東京営業チーム | region = '東京' | 東京のデータのみ |
| 大阪営業チーム | region = '大阪' | 大阪のデータのみ |
| 全国管理チーム | （フィルタなし） | 全データ |
5. LF-Tagによるタグベースのアクセス制御
5.1 名前付きリソース方式の課題
ここまで、カラムレベルや行レベルのきめ細かなアクセス制御について学びました。しかし、これらの権限をリソースごとに個別に設定していく方法（名前付きリソース方式、Named Resource Method）では、リソースやユーザの数が増えると管理が大変になるという課題があります。
例えば、3つのデータベースと7つのテーブルに対して3人のユーザに権限を付与する場合、最大で17個の権限設定が必要になります。データベースやテーブルが増えるほど、この設定数は爆発的に増加します。
5.2 LF-Tagとは
この課題を解決するのが、LF-Tag（Lake Formation Tag）を使ったタグベースのアクセス制御（LF-TBAC: Lake Formation Tag-Based Access Control）です。
LF-Tagは、Lake Formationで使用できるキーと値のペアです。例えば department=sales や classification=restricted のように定義します。一つのキーに対して複数の値を持たせることもでき、department=sales,marketing,engineering のように設定できます。
タグベースのアクセス制御では、以下の2つのステップで権限を管理します。
- データカタログのリソース（データベースやテーブル）にLF-Tagを割り当てる
- ユーザやロールにLF-Tagの権限を付与する
同じLF-Tagを持つリソースとユーザが自動的にマッチングされ、権限が適用されます。
5.3 具体的な例
例えば、ERP（基幹業務システム）のデータを管理するケースを考えます。module というキーのLF-Tagを作成し、値として Sales、Orders、Customers を定義します。
まず、リソースにLF-Tagを割り当てます。
- データベースA →
module=Sales - データベースB →
module=Orders - データベースC →
module=Customers
次に、ユーザにLF-Tagの権限を付与します。
- ユーザ1 →
module=Salesとmodule=Customers - ユーザ2 →
module=Orders - ユーザ3 →
module=Customers
これだけで、ユーザ1はデータベースAとCのデータにアクセスでき、ユーザ2はデータベースBのデータにアクセスできるようになります。名前付きリソース方式では17個の権限設定が必要だったものが、LF-Tagの割り当て5回と権限付与4回の合計9回の操作で済みます。
5.4 LF-Tagの継承
LF-Tagには継承の仕組みがあります。データベースに割り当てたLF-Tagは、そのデータベース内のテーブルに自動的に継承されます。同様に、テーブルに割り当てたLF-Tagはカラムに継承されます。継承された値は、必要に応じて個別に上書きすることも可能です。
この継承の仕組みにより、データベースにLF-Tagを1つ割り当てるだけで、配下のすべてのテーブルに同じタグが適用されるため、管理の手間がさらに軽減されます。
| 💡 ポイント |
|---|
| リソースやユーザが少ない場合は名前付きリソース方式でも十分ですが、数十のデータベースや数百のテーブルを管理する場合はLF-Tagの活用が効果的です。名前付きリソース方式では権限の数が「ユーザ数 × リソース数」に比例するのに対し、LF-Tagでは「ユーザ数 + リソース数」程度で済みます。LF-Tagの設計上の制約や運用上のベストプラクティスはLake Formation tag-based access control best practices and considerations（AWS Lake Formation公式ドキュメント）にまとまっています。 |
6. データレイク管理者
6.1 データレイク管理者の役割
Lake Formationでは、データレイク管理者（Data Lake Administrator）という特別な役割があります。データレイク管理者は、Lake Formationのすべてのリソースと権限を管理できる最上位の管理者です。
データレイク管理者は以下の操作が可能です。
- データレイクロケーションの登録・管理
- データベース・テーブルの作成・削除
- 他のユーザやロールへの権限付与・取り消し
- 権限の委譲（付与可能な権限を他のユーザに委譲）
| 📝 データレイク管理者の設定 |
|---|
| Lake Formationを利用開始する際に、最初にデータレイク管理者を設定する必要があります。データレイク管理者はIAMユーザまたはIAMロールとして指定します。セキュリティの観点から、データレイク管理者は限られた信頼できるユーザのみに割り当ててください。 |
7. 他のサービスとの連携
7.1 Athenaとの連携
AthenaでSQLクエリを実行する際、Lake Formationの権限設定が自動的に適用されます。ユーザがAthenaからクエリを実行すると、Lake Formationがそのユーザの権限を確認し、アクセスが許可されたデータのみがクエリ結果に含まれます。
カラムレベルのアクセス制御が設定されている場合、SELECT * を実行すると権限のないカラムがクエリ結果から自動的に除外されます。また、権限のないカラムを明示的に指定して SELECT を実行した場合はエラーが返されます。
7.2 Glueジョブとの連携
GlueジョブでETL処理を実行する際にも、Lake Formationの権限設定が適用されます。Glueジョブに割り当てられたIAMロールに対して、必要なテーブル・カラムへのアクセス権限をLake Formationで付与する必要があります。
7.3 QuickSightとの連携
QuickSightのユーザがAthena経由でデータにアクセスする際にも、Lake Formationの権限設定が適用されます。これにより、ダッシュボードの閲覧者に対してもデータレベルのアクセス制御を実現できます。
8. 主なユースケース
8.1 マルチチームでのデータ共有
複数のチーム（営業、マーケティング、開発、経営企画など）が同じデータレイクを利用する場合に、チームごとにアクセス可能なデータベース・テーブル・カラムを制御します。
8.2 個人情報の保護
個人情報を含むデータを分析する際に、個人を特定できるカラム（氏名、メールアドレスなど）を特定のユーザにのみ公開し、それ以外のユーザには非表示にします。
8.3 コンプライアンス対応
データアクセスの監査ログを一元管理し、「誰が」「いつ」「どのデータに」アクセスしたかを追跡可能にします。金融業界や医療業界など、データ管理に関する規制が厳しい業界で特に重要です。
9. 設計のポイント
Lake Formationを設計する際の主要な検討項目を以下にまとめます。
| 設計項目 | 検討内容 | 推奨・注意事項 |
|---|---|---|
| データレイク管理者 | 管理者の選定 | 信頼できる限られたユーザのみに割り当てる |
| アクセス制御の粒度 | テーブル/カラム/行レベルの選択 | 要件に応じた適切な粒度を設定。過度に細かい制御は管理コストが増大 |
| 既存権限との整合性 | IAMポリシーとの関係 | Lake Formation導入時に既存のIAMポリシーとの競合に注意 |
| データ分類 | 機密性に応じたデータの分類 | 機密レベルに応じてアクセス制御ポリシーを設計 |
| 権限付与方式 | 名前付きリソース方式とLF-TBACの選択 | リソースやユーザが多い場合はLF-Tagの活用を検討 |
| 監査 | アクセスログの管理 | CloudTrailと連携してデータアクセスの監査証跡を記録 |
10. まとめ
この講座では、データレイクの構築・管理・セキュリティを一元化するサービスであるAWS Lake Formationについて学びました。
- AWS Lake Formationはデータレイクの構築・管理・セキュリティを一元化するサービス
- Glueデータカタログと統合し、データの構造はGlue、アクセス権限はLake Formationで管理する
- カラムレベルや行レベルのきめ細かなアクセス制御が可能で、個人情報の保護に活用できる
- LF-Tagによるタグベースのアクセス制御で、大規模な環境でも権限管理を効率化できる
- データレイク管理者がLake Formationの全リソースと権限を一元管理する
- Athena、Glue、QuickSightなどのサービスと連携し、データアクセス時に自動的に権限チェックが行われる