AWS Lake Formation入門｜S3データレイクのきめ細かいアクセス制御と列レベルセキュリティを実装する実践ガイド

データ分析基盤をAWSに構築してみて、「S3のバケットポリシーでは特定の列へのアクセスを制限できない」「AthenaやGlueのIAM権限が複雑になりすぎた」と壁にぶつかったことはないだろうか。

オンプレのDWHやHadoopクラスタであれば、Apache Rangerのようなセキュリティツールがテーブルや列単位のアクセス制御を担っていた。しかしAWSでS3＋Glue＋Athenaという構成に移行すると、従来のIAMポリシー管理だけでは同等のセキュリティレベルを保つのが難しくなる。

この記事では、AWS Lake Formationを使ってS3データレイクに「テーブル・列・行」単位の細粒度なアクセス制御を実装する方法を、オンプレ経験者にもわかりやすく解説する。Lake Formation固有の権限モデル、LF-Tagsによるタグベース制御、クロスアカウント展開まで順を追って説明する。

なぜIAMだけではデータレイクのアクセス制御が難しいのか

S3バケットポリシーとIAMポリシーを組み合わせれば、バケット・プレフィックス（フォルダ相当）レベルの制御は実現できる。しかし実際のデータレイク運用では、次の3つの壁にぶつかることが多い。

1. S3の最小制御単位はファイルパス、列単位の制御は不可能

S3のアクセス制御の最小単位は「オブジェクト（ファイル）」だ。Parquet形式で保存されたテーブルの「顧客名」列だけをマスクして、別のユーザーには「注文金額」列のみを見せたい——こうした列レベルの制御はS3バケットポリシーの設計概念にそもそも存在しない。

2. IAMポリシーの管理が爆発的に複雑になる

Glue Data Catalogのデータベース・テーブルへのアクセス権限を正しく設定するには、GlueのGetDatabase/GetTable権限、S3のs3:GetObject権限、AthenaでのStartQueryExecution権限など、複数のIAMポリシーを整合的に管理する必要がある。ユーザーやロールが増えるにつれ「誰がどのテーブルを見られるか」の全体像が見えなくなっていく。

3. クロスアカウントのデータ共有が煩雑

データ提供側アカウントのS3バケットポリシーを変更し、受け取り側アカウントのIAMポリシーも更新する——マルチアカウント構成でこれを手動管理すると、設定ミスによるデータ漏洩やアクセス不能が起きやすい。

AWS Lake Formationとは何か

AWS Lake Formationは、S3データレイクのアクセス管理を一元化するサービスだ。Glue Data Catalogの上に「Lake Formation権限」という独自の権限レイヤーを重ね、テーブル・列・行という粒度でデータアクセスを制御できる。

オンプレのHadoopエコシステムで例えると、Apache Rangerに相当するセキュリティ管理をAWSマネージドで利用できるイメージに近い。

Lake Formationが管理するコンポーネント

・Data Catalog: Glue Data Catalogの上に構築されたメタデータリポジトリ。データベース・テーブル・スキーマ情報を管理する
・Lake Formation権限: SELECT・INSERT・ALTER・DROPなどのSQL互換権限をテーブル・列単位で付与する
・LF-Tags（Lake Formation Tags）: データ資産にタグを付けてABAC（属性ベースアクセス制御）を実現する
・Data Filters（行フィルタ）: 特定条件に合う行のみを返すフィルタを定義する
・Cross-account sharing: AWS RAM経由でアカウント間のデータ共有を安全に管理する

GlueとLake Formationの役割分担

混乱しやすいポイントだが、役割は明確に分かれている。AWS GlueはETLジョブの実行とメタデータの管理が主な役割だ。Lake Formationはそのメタデータを「誰が・何を・どこまで見られるか」という権限面から制御する。

Lake Formationの権限モデルを理解する

IAMポリシーとLake Formation権限の「二重チェック」

Lake Formationを有効化すると、データアクセスはIAMポリシーとLake Formation権限の両方で評価される。

・IAMポリシーでGlue:GetTableのAllow + Lake Formation権限でSELECT付与 → アクセス可能
・IAMポリシーでGlue:GetTableのAllow + Lake Formation権限なし → アクセス不可
・IAMポリシーでGlue:GetTableのDeny + Lake Formation権限でSELECT付与 → アクセス不可

両方の条件を満たして初めてアクセスできる、という構造だ。既存の環境にLake Formationを導入すると、Lake Formation権限が付与されていないロールは突然アクセス不能になるため、移行計画が重要になる。

Lake Formation権限の種類

実践: Lake Formationのセットアップ手順

1. Data Lake Administratorを登録する

AWSコンソール → Lake Formation → 「Administration」→「Data lake administrators」でLake Formation全体を管理するロールまたはIAMユーザーを登録する。

# AWS CLI: Lake Formation Administrator登録
aws lakeformation put-data-lake-settings \
  --data-lake-settings '{
    "DataLakeAdmins": [
      {"DataLakePrincipalIdentifier": "arn:aws:iam::123456789012:role/LakeFormationAdminRole"}
    ],
    "CreateDatabaseDefaultPermissions": [],
    "CreateTableDefaultPermissions": []
  }'

重要: `CreateDatabaseDefaultPermissions` と `CreateTableDefaultPermissions` を空配列にすること。デフォルトのまま有効化すると、新規テーブル作成時に作成者のIAMエンティティへ暗黙的な全権限が付与され、最小権限の原則が崩れる。

2. S3データレイクの場所を登録する

# S3パスをLake Formationのデータロケーションとして登録
aws lakeformation register-resource \
  --resource-arn arn:aws:s3:::my-datalake-bucket \
  --use-service-linked-role

この手順でLake FormationのサービスリンクロールがS3への読み取り権限を取得する。

3. テーブルへのSELECT権限を付与する

# テーブル全体へのSELECT権限を付与
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/AnalystRole" \
  --permissions SELECT DESCRIBE \
  --resource '{
    "Table": {
      "DatabaseName": "sales_db",
      "Name": "orders_table"
    }
  }'

列レベルセキュリティ（Column-Level Security）の実装

Lake Formationの核心機能の一つが列単位のアクセス制御だ。注文テーブルに「顧客名」「メールアドレス」「注文金額」「商品コード」の4列があるとして、分析チームには金額と商品コードのみ、個人情報管理チームには全列を見せたい——こうした要件に対応できる。

特定の列のみSELECTを許可する（Include方式）

# 分析チームには「注文金額」「商品コード」列のみ許可
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/AnalystRole" \
  --permissions SELECT \
  --resource '{
    "TableWithColumns": {
      "DatabaseName": "sales_db",
      "Name": "orders_table",
      "ColumnNames": ["order_amount", "product_code"]
    }
  }'

特定の列だけを除外してSELECTを許可する（Exclude方式）

# 個人情報列（customer_name, email）以外の全列へのアクセスを許可
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/ReportingRole" \
  --permissions SELECT \
  --resource '{
    "TableWithColumns": {
      "DatabaseName": "sales_db",
      "Name": "orders_table",
      "ColumnWildcard": {
        "ExcludedColumnNames": ["customer_name", "email"]
      }
    }
  }'

列数の多いテーブルで「この列だけ隠したい」という場合はExclude方式が保守しやすい。列が追加されても自動的にアクセス可能になるため、スキーマ変更への追従コストが低い。

行レベルセキュリティ（Row-Level Security）の実装

Lake Formationの「Data Filters」を使うと、行レベルのフィルタリングも実現できる。たとえば「日本リージョンのデータ担当者には日本のレコードのみ見せる」といった運用だ。

Data Filterの作成と付与

# Step1: 「region = 'JP'」のデータのみ見えるフィルタを作成
aws lakeformation create-data-cells-filter \
  --table-data '{"DatabaseName":"sales_db","Name":"orders_table"}' \
  --name JapanRegionFilter \
  --row-filter '{"FilterExpression":"region = '\''JP'\''"}' \
  --column-wildcard '{}'

# Step2: JapanRegionFilterをJapanAnalystRoleに付与
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/JapanAnalystRole" \
  --permissions SELECT \
  --resource '{
    "DataCellsFilter": {
      "TableCatalogId": "123456789012",
      "DatabaseName": "sales_db",
      "TableName": "orders_table",
      "Name": "JapanRegionFilter"
    }
  }'

これによりJapanAnalystRoleがAthenaでクエリを実行すると、`region != ‘JP’` のレコードは自動的に除外される。アプリケーション側でWHERE句を書く必要がなく、フィルタ漏れが起きない。

LF-Tags（Lake Formation Tags）によるタグベースアクセス制御

テーブル数・ユーザー数が増えると、テーブルを個別に指定して権限付与するのが煩雑になる。LF-Tagsを使えば、「Sensitivity: High」タグが付いたテーブルには特定のロールだけがアクセスできる、といったABAC（属性ベースアクセス制御）が実現できる。

LF-Tagの定義・付与・権限設定の流れ

# Step1: タグキーと値の定義
aws lakeformation create-lf-tag \
  --tag-key Sensitivity \
  --tag-values High Medium Low

# Step2: テーブルにタグを付与
aws lakeformation add-lf-tags-to-resource \
  --resource '{
    "Table": {
      "DatabaseName": "sales_db",
      "Name": "orders_table"
    }
  }' \
  --lf-tags '[{"TagKey":"Sensitivity","TagValues":["High"]}]'

# Step3: タグ条件でロールに権限付与
aws lakeformation grant-permissions \
  --principal DataLakePrincipalIdentifier="arn:aws:iam::123456789012:role/DataStewardRole" \
  --permissions SELECT \
  --resource '{
    "LFTagPolicy": {
      "ResourceType": "TABLE",
      "Expression": [
        {"TagKey":"Sensitivity","TagValues":["High","Medium"]}
      ]
    }
  }'

「Sensitivity: High または Medium」タグを持つ全テーブルへの権限がDataStewardRoleに一括付与される。新しいテーブルを追加してもタグを付けるだけで権限範囲に自動的に含まれるため、テーブル追加のたびにIAMポリシーを更新する手間がなくなる。

クロスアカウントのデータ共有

Lake FormationはAWS RAMと連携して、複数アカウント間でデータカタログのリソースを安全に共有できる。

共有の基本フロー

・提供側アカウント: Lake FormationでデータベースまたはテーブルをAWS RAMのリソース共有に追加する
・受け取り側アカウント: AWS RAMの招待を承認し、自アカウントのGlue Data CatalogにResource Linkを作成する
・権限付与: 受け取り側アカウントのプリンシパルに、リソースリンク経由でSELECT権限を付与する

これにより、提供側のS3バケットポリシーを変更せずに、データの論理的な共有が可能になる。提供側がいつでも権限を取り消せる点もセキュリティ上の利点だ。AWS Organizationsと組み合わせると、組織内のアカウント間共有をより一元的に管理できる。

料金の仕組み

Lake Formation自体の利用料は無料だ（2026年9月時点）。ただし、Lake Formationを通じて利用する周辺サービスには通常の料金が発生する。

Lake Formationの導入による追加コストは、実質的にGlue Data Catalogのリクエスト増程度だ。大量クエリを投げなければ無視できるレベルの追加コストに収まることがほとんどだ。

よくあるトラブルと対処法

【トラブル1】Athenaで「Insufficient Lake Formation permission(s)」エラーが出る

Lake FormationのSELECT権限を付与しても、IAMポリシー側でGlue:GetTable/GetDatabase・S3:GetObjectが許可されていないと同様のエラーが出る。確認の順番は「①Lake Formation権限が付与されているか → ②IAMポリシーで必要なGlue・S3権限があるか → ③DATA_LOCATION_ACCESSが設定されているか」の3ステップで進める。

【トラブル2】Glue ETLジョブがLake Formation管理下のテーブルにアクセスできない

GlueジョブのサービスロールにもLake Formationの権限付与が必要だ。GlueジョブのIAMロールをLake Formationのプリンシパルとして追加し、対象テーブルのSELECT権限を付与する。

【トラブル3】Lake Formationを有効化したら既存のGlueジョブが全て失敗した

デフォルト権限の設定を空にしてLake Formationを有効化すると、既存のIAMポリシーだけでアクセスできていた全てのGlueジョブが権限不足になる。有効化前に必ず「どのロールに何の権限を付与するか」の移行マッピングを作り、テスト環境で動作確認してから本番適用すること。

【トラブル4】LF-Tagsで付与した権限が特定のテーブルに反映されない

LF-TagはTableだけでなくDatabaseレベルにも付与できる。Databaseレベルのタグ設定とTableレベルのタグ設定が競合している場合、予期しないアクセス制御になることがある。`get-resource-lf-tags`コマンドでテーブル・データベース双方のタグを確認すること。

AWS Macieとの連携でデータガバナンスを自動化する

S3のデータに個人情報が含まれるかどうかの検出には、AWS Macieとの組み合わせが効果的だ。Macieで「個人情報が含まれるバケット・パス」を特定してからLake Formationで当該テーブルの列レベルセキュリティを適用する、という運用フローを整備しておくと、データガバナンスが自動化に近づく。

また、コンプライアンス証拠の収集にはAWS Audit ManagerでLake Formationの権限付与ログをPCI DSS・SOC2対応の監査証跡として自動収集する構成も有効だ。

本記事のまとめ

・AWS Lake Formationとは: S3データレイクにデータベース・テーブル・列・行単位のアクセス制御を実装するAWSマネージドサービス
・IAMとの関係: IAMポリシーとLake Formation権限の「両方」を満たしてアクセス可能になる二重チェック構造
・列レベルセキュリティ: Include方式（指定列のみ許可）とExclude方式（指定列のみ除外）の2種類がある
・行レベルセキュリティ: Data Filtersで条件に合う行のみを返すフィルタを定義できる
・LF-Tags: タグベースのABACにより、テーブル追加時にもポリシー更新不要な権限管理が実現できる
・クロスアカウント共有: AWS RAM連携でS3バケットポリシー変更なしにデータの論理共有が可能
・料金: Lake Formation自体は無料。Glue Data Catalog・Athena・S3の通常料金のみ

オンプレのDWHセキュリティで慣れ親しんだ「テーブル・列単位のアクセス制御」をAWSのデータレイクでも実現したいエンジニアにとって、Lake Formationは現時点で最も実用的な選択肢だ。まずテスト環境で有効化し、既存IAMポリシーとの整合性を確認してから本番適用を進めることを強くすすめる。