Lake Formation概要

この章では、データレイクの構築・管理・セキュリティを一元化するAWS Lake Formationについて学びます。これにより、カラムレベル・行レベルのアクセス制御とLF-Tagによるタグベース管理の基本が理解できます。

💡 ポイント
Lake Formationはアクセス制御の設定項目が多く、セクションの説明だけではイメージがつきにくい部分もあるかもしれません。次のセクションでLF-Tagを使ったアクセス制御のハンズオンを行いますので、まずはこのセクションで全体像を把握することを意識して読み進めてください。

1. 本章の概要

1.1 本章の目的

データレイクを組織横断で運用すると、S3のバケットポリシーやIAMだけではアクセス制御の設計・維持が難しくなります。Lake Formationは、テーブル・カラム・行という分析寄りの粒度でアクセス権を一元管理できるサービスで、部署ごとの権限分離やタグベース管理を短時間で構築できます。

1.2 本章で学ぶ内容

Lake Formationの位置づけ、データレイク管理者・データステアードといった役割、権限の付与単位（テーブル・カラム・行）を扱います。あわせて、LF-Tagによるタグベース管理、カラムレベル・行レベルのアクセス制御の設計方針も整理します。

2. Lake Formationの概要

2.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

2.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の必要性が高まります。

💡 ポイント

Lake Formationは「データレイクのセキュリティと管理を簡素化する」ためのサービスです。特にデータを複数のチームやユーザで共有する場合に、その価値が大きくなります。小規模な構成ではIAMポリシーだけで十分なこともありますが、データの種類やユーザが増えるにつれてLake Formationの必要性が高まります。

3. Lake Formationの主要機能

3.1 データレイクの登録

Lake Formationでは、まずS3上のデータ保存場所をデータレイクロケーションとして登録します。登録することで、そのS3パスに保存されたデータをLake Formationの管理下に置くことができます。

登録されたS3パスのデータに対するアクセスは、S3バケットポリシーやIAMポリシーではなく、Lake Formationの権限設定で制御されるようになります。

3.2 Glueデータカタログとの統合

Lake Formationは、Glueデータカタログの上位レイヤーとして機能します。Glueデータカタログで管理されているデータベースやテーブルに対して、Lake Formationから権限を付与・制御できます。

つまり、データの構造（スキーマ）はGlueデータカタログで管理し、データへのアクセス権限はLake Formationで管理する、という役割分担になります。

3.3 アクセス制御

Lake Formationのアクセス制御は、以下のレベルで設定できます。

制御レベル	説明	例
データベースレベル	データベース全体へのアクセスを制御	sales_dbへの全アクセスを許可
テーブルレベル	特定のテーブルへのアクセスを制御	sales_dataテーブルのみ読み取りを許可
カラムレベル	テーブル内の特定カラムへのアクセスを制御	個人情報カラム（名前、電話番号）を非表示にする
行レベル	特定の条件に合致する行のみアクセスを許可	region = '東京' の行のみ表示

3.4 権限の付与モデル

Lake Formationでは、以下の権限を組み合わせてアクセスを制御します。

権限	説明
SELECT	テーブルのデータを読み取る
INSERT	テーブルにデータを挿入する
DELETE	テーブルのデータを削除する
DESCRIBE	テーブルのメタデータ（スキーマ情報）を参照する
ALTER	テーブルの定義を変更する
DROP	テーブルを削除する
CREATE_TABLE	データベース内にテーブルを作成する
CREATE_DATABASE	データカタログにデータベースを作成する

4. カラムレベルのアクセス制御

4.1 ユースケース

カラムレベルのアクセス制御は、特に個人情報や機密情報を含むデータを扱う場合に重要です。

例えば、顧客データのテーブルに以下のカラムがあるとします。

カラム名	内容	機密性
customer_id	顧客ID	低
name	氏名	高（個人情報）
email	メールアドレス	高（個人情報）
phone	電話番号	高（個人情報）
region	地域	低
total_purchases	購入総額	中

この場合、Lake Formationを使って以下のように権限を設定できます。

マーケティングチームには customer_id, region, total_purchases のみ閲覧可能とし、個人を特定できる情報は非表示にする
カスタマーサポートチームには全カラムの閲覧を許可する（顧客対応に氏名・連絡先が必要なため）
データ分析チームには customer_id, name, region, total_purchases の閲覧を許可する（名前は分析に必要だが、連絡先は不要）

💡 ポイント
IAMポリシーでは「S3バケットやオブジェクト単位」のアクセス制御はできますが、「テーブルの特定のカラムだけを見せる・隠す」といった制御はできません。カラムレベルのアクセス制御は、Lake Formationならではの機能です。

💡 ポイント
カラムレベルのアクセス制御は、データのマスキング（値を「」などに置き換えて隠す処理）とは異なります。マスキングではカラム自体は見えるものの値が隠されるのに対し、Lake Formationのカラムレベル制御では、権限のないカラムはクエリ結果にそもそも含まれません*。カラムの存在自体を意識させない、より厳密なアクセス制御が可能です。

💡 ポイント

カラムレベルのアクセス制御は、データのマスキング（値を「*」などに置き換えて隠す処理）とは異なります。マスキングではカラム自体は見えるものの値が隠されるのに対し、Lake Formationのカラムレベル制御では、権限のないカラムはクエリ結果にそもそも含まれません**。カラムの存在自体を意識させない、より厳密なアクセス制御が可能です。

4.2 包含と除外の方式

カラムレベルのアクセス制御には、2つの設定方式があります。

方式	説明	適したケース
包含（Include）	指定したカラムのみアクセスを許可	アクセス可能なカラムが少ない場合
除外（Exclude）	指定したカラムへのアクセスを拒否	アクセス不可のカラムが少ない場合

5. 行レベルのセキュリティ

5.1 行フィルタリング

行レベルのセキュリティ（Row-Level Security）は、テーブル内の特定の行のみをユーザに表示する機能です。データフィルタを定義し、条件に合致する行のみがクエリ結果に含まれるようにします。

例えば、地域別の営業チームに対して、自分の担当地域のデータのみを表示させることができます。

ユーザ/グループ	フィルタ条件	表示されるデータ
東京営業チーム	region = '東京'	東京のデータのみ
大阪営業チーム	region = '大阪'	大阪のデータのみ
全国管理チーム	（フィルタなし）	全データ

6. LF-Tagによるタグベースのアクセス制御

6.1 名前付きリソース方式の課題

ここまで、カラムレベルや行レベルのきめ細かなアクセス制御について学びました。しかし、これらの権限をリソースごとに個別に設定していく方法（名前付きリソース方式、Named Resource Method）では、リソースやユーザの数が増えると管理が大変になるという課題があります。

例えば、3つのデータベースと7つのテーブルに対して3人のユーザに権限を付与する場合、最大で17個の権限設定が必要になります。データベースやテーブルが増えるほど、この設定数は爆発的に増加します。

6.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を持つリソースとユーザが自動的にマッチングされ、権限が適用されます。

6.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回の操作で済みます。

6.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公式ドキュメント）にまとまっています。

💡 ポイント

リソースやユーザが少ない場合は名前付きリソース方式でも十分ですが、数十のデータベースや数百のテーブルを管理する場合はLF-Tagの活用が効果的です。名前付きリソース方式では権限の数が「ユーザ数 × リソース数」に比例するのに対し、LF-Tagでは「ユーザ数 + リソース数」程度で済みます。LF-Tagの設計上の制約や運用上のベストプラクティスはLake Formation tag-based access control best practices and considerations（AWS Lake Formation公式ドキュメント）にまとまっています。

7. データレイク管理者

7.1 データレイク管理者の役割

Lake Formationでは、データレイク管理者（Data Lake Administrator）という特別な役割があります。データレイク管理者は、Lake Formationのすべてのリソースと権限を管理できる最上位の管理者です。

データレイク管理者は以下の操作が可能です。

データレイクロケーションの登録・管理
データベース・テーブルの作成・削除
他のユーザやロールへの権限付与・取り消し
権限の委譲（付与可能な権限を他のユーザに委譲）

📝 データレイク管理者の設定
Lake Formationを利用開始する際に、最初にデータレイク管理者を設定する必要があります。データレイク管理者はIAMユーザまたはIAMロールとして指定します。セキュリティの観点から、データレイク管理者は限られた信頼できるユーザのみに割り当ててください。

8. 他のサービスとの連携

8.1 Athenaとの連携

AthenaでSQLクエリを実行する際、Lake Formationの権限設定が自動的に適用されます。ユーザがAthenaからクエリを実行すると、Lake Formationがそのユーザの権限を確認し、アクセスが許可されたデータのみがクエリ結果に含まれます。

カラムレベルのアクセス制御が設定されている場合、SELECT * を実行すると権限のないカラムがクエリ結果から自動的に除外されます。また、権限のないカラムを明示的に指定して SELECT を実行した場合はエラーが返されます。

8.2 Glueジョブとの連携

GlueジョブでETL処理を実行する際にも、Lake Formationの権限設定が適用されます。Glueジョブに割り当てられたIAMロールに対して、必要なテーブル・カラムへのアクセス権限をLake Formationで付与する必要があります。

8.3 QuickSightとの連携

QuickSightのユーザがAthena経由でデータにアクセスする際にも、Lake Formationの権限設定が適用されます。これにより、ダッシュボードの閲覧者に対してもデータレベルのアクセス制御を実現できます。

9. 主なユースケース

9.1 マルチチームでのデータ共有

複数のチーム（営業、マーケティング、開発、経営企画など）が同じデータレイクを利用する場合に、チームごとにアクセス可能なデータベース・テーブル・カラムを制御します。

9.2 個人情報の保護

個人情報を含むデータを分析する際に、個人を特定できるカラム（氏名、メールアドレスなど）を特定のユーザにのみ公開し、それ以外のユーザには非表示にします。

9.3 コンプライアンス対応

データアクセスの監査ログを一元管理し、「誰が」「いつ」「どのデータに」アクセスしたかを追跡可能にします。金融業界や医療業界など、データ管理に関する規制が厳しい業界で特に重要です。

10. 設計のポイント

Lake Formationを設計する際の主要な検討項目を以下にまとめます。

設計項目	検討内容	推奨・注意事項
データレイク管理者	管理者の選定	信頼できる限られたユーザのみに割り当てる
アクセス制御の粒度	テーブル/カラム/行レベルの選択	要件に応じた適切な粒度を設定。過度に細かい制御は管理コストが増大
既存権限との整合性	IAMポリシーとの関係	Lake Formation導入時に既存のIAMポリシーとの競合に注意
データ分類	機密性に応じたデータの分類	機密レベルに応じてアクセス制御ポリシーを設計
権限付与方式	名前付きリソース方式とLF-TBACの選択	リソースやユーザが多い場合はLF-Tagの活用を検討
監査	アクセスログの管理	CloudTrailと連携してデータアクセスの監査証跡を記録

11. まとめ

この章では、データレイクの構築・管理・セキュリティを一元化するサービスであるAWS Lake Formationについて学びました。

AWS Lake Formationは、データレイクの構築・管理・セキュリティを一元化するサービスである
Glueデータカタログと統合し、データの構造はGlue、アクセス権限はLake Formationで管理する
カラムレベルや行レベルのきめ細かなアクセス制御ができ、個人情報の保護に活用できる
LF-Tagによるタグベースのアクセス制御により、大規模な環境でも権限管理を効率化できる
データレイク管理者が、Lake Formationの全リソースと権限を一元管理する
Athena・Glue・QuickSightなどのサービスと連携し、データアクセス時に自動的に権限チェックが行われる

次の章では、Lake Formation でアクセス制御を体験する流れをハンズオン形式で体験します。

Lake Formation概要

1. 本章の概要

1.1 本章の目的

1.2 本章で学ぶ内容

2. Lake Formationの概要

2.1 AWS Lake Formationとは

2.2 なぜLake Formationが必要なのか

3. Lake Formationの主要機能

3.1 データレイクの登録

3.2 Glueデータカタログとの統合

3.3 アクセス制御

3.4 権限の付与モデル

4. カラムレベルのアクセス制御

4.1 ユースケース

4.2 包含と除外の方式

5. 行レベルのセキュリティ

5.1 行フィルタリング

6. LF-Tagによるタグベースのアクセス制御

6.1 名前付きリソース方式の課題

6.2 LF-Tagとは

6.3 具体的な例

6.4 LF-Tagの継承

7. データレイク管理者

7.1 データレイク管理者の役割

8. 他のサービスとの連携

8.1 Athenaとの連携

8.2 Glueジョブとの連携

8.3 QuickSightとの連携

9. 主なユースケース

9.1 マルチチームでのデータ共有

9.2 個人情報の保護

9.3 コンプライアンス対応

10. 設計のポイント

11. まとめ

この教材は役に立ちましたか？