AWSデータガバナンスVol2｜LF-Tag・セルレベル・データメッシュ

1. Vol2の概要とVol1との差別化

1-1. Vol2で扱うテーマ

Vol2は、Vol1で構築したデータガバナンスの基盤層の上に、きめ細かいアクセス制御と大規模・マルチアカウント展開のための実装層を積み重ねます。

Vol2の主要テーマは以下の5領域です。

① LF-Tag タグベースアクセス制御 (LF-TBAC)

Lake Formationのタグ(key:value属性)をData Catalogリソースとプリンシパルの両方に付与し、タグが一致した場合のみアクセスを許可する仕組みです。IAMリソース個別付与と比べて大規模環境でスケールしやすく、AND/OR演算子のタグ式で多数のリソースを一括制御できます。2024年11月にGAとなったnamed LF-Tag expressionsにより、複数タグの組み合わせに名前を付けた統一管理も可能です。

② 行/列/セルレベルセキュリティ

Lake Formationはdatabase/table/column/row/cellの各粒度でアクセス制限をサポートします。行レベルフィルタ(data filter)はSQL WHERE句形式の行フィルタ式で特定行のみを表示し、列レベルはinclude/excludeでカラムを限定します。セルレベルはこれら行フィルタと列フィルタの組み合わせによって実現します。テナント別データ分離やPII列の保護に有効です。

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

Lake Formation v4設定とAWS RAM(Resource Access Manager)の組み合わせにより、異なるAWSアカウント間でのデータアクセス付与を実現します。hybrid access modeにも対応しており、既存のIAM権限ベースの環境と段階的に統合できます。クロスアカウント共有は2段階の手順が必要で、RAM共有だけではアクセスできない点が重要な前提です(§4で詳説)。

④ データメッシュ(プロデューサ/コンシューマモデル)

ドメイン単位の所有権と自律性を保ちながら、中央Lake Formationカタログでドメイン所有者へアクセスを委任する分権構造です。LF-Tagの管理もドメインごとに分権(decentralized LF-Tag management)でき、大規模組織でのガバナンスと開発スピードを両立できます。

⑤ Amazon Macieによる機密データ検出

MacieはS3内の機密データ(PII/PHI等)を機械学習+パターンマッチで検出します。全バケット対象の継続的な自動機密データ検出と、個別に作成・実行する機密データ検出ジョブの2方式を提供します。Macieの検出結果をLake FormationのLF-Tag・列レベル・行レベルと組み合わせ、機密データへのアクセスをきめ細かく統制するガバナンスループを構築できます。

1-2. 読者像と前提

本記事は以下の読者を対象としています。

対象読者

• データ基盤エンジニア、データプラットフォームチームの技術担当
• データガバナンス推進担当、セキュリティ/コンプライアンス担当

前提知識

• Lake FormationおよびGlue Data Catalogの基本概念(Vol1相当): IAM権限+Lake Formation権限の2層モデル、データカタログの構造
• DataZoneの理解は必須ではありませんが、あると§5データメッシュの文脈が深まります

典型的な課題感

以下のような状況にある方を特に想定しています。

• リソース数の増加でIAM個別付与の管理が限界に近づいてきた
• 複数部門・テナントへのデータ提供でアクセス制御の粒度が不足している
• マルチアカウント化やデータメッシュ構成への移行を検討中
• S3内の機密データを自動検出し、ガバナンスのループに組み込みたい

Vol1の基礎概念(DataZone・Lake Formation基礎・Clean Rooms・データ品質/カタログ)は本記事では再掲しません。必要に応じてVol1を参照してください。

▶ Vol1: DataZone・Lake Formation・Clean Rooms・データ品質編

2. LF-Tag タグベースアクセス制御 (LF-TBAC)

2-1. LF-TBACの仕組み（重要な前提）

LF-TBAC(Lake Formation Tag-Based Access Control)はLF-Tag(key:value属性)をData Catalogリソースとプリンシパルの両方に付与し、タグが一致した場合のみアクセスを許可するアクセス制御モデルです。

LF-TBACの基本構造

IAM個別付与との違い

従来のLake Formation権限モデル(Named Resource方式)ではリソースを個別に指定してプリンシパルに付与します。リソース数が数百・数千になると付与関係の管理が困難になり、新しいテーブルを追加するたびに権限付与作業が発生します。

LF-TBACではリソースにタグを付与するだけで、同じタグを持つ全プリンシパルが自動的にアクセスできます。新しいテーブルを追加した場合も、適切なLF-Tagを付与するだけで既存の権限設定が自動的に適用されます。タグ式で多数のリソースを一括制御できるため、大規模データレイクの権限管理に適しています。

図2との対応

図2は以下のフローを示しています。

1. データ管理者がLF-Tag(例: sensitivity=INTERNAL)をGlue Data Catalogのテーブルに割当
2. データ管理者が同じLF-Tag(sensitivity=INTERNAL)をIAMロールに付与
3. IAMロールでAthenaからクエリを実行→Lake Formationがタグ一致を確認→アクセス許可

タグが一致しない場合(例: プリンシパルのタグがsensitivity=PUBLIC、リソースがsensitivity=INTERNAL)はアクセスが拒否されます。この判定はLake Formationが自動的に行い、IAMポリシーへの個別リソースARN記述は不要です。

タグ式によるスケール

複数のLF-Tagをタグ式(AND/OR演算子)で組み合わせることで、より精密なアクセス制御が可能です。「domain=finance かつ sensitivity=INTERNAL のリソースへのアクセスを許可する」というポリシーをタグ式1つで表現できます。これにより、数千のリソースに対するアクセス制御を数十のLF-Tag付与だけで管理できます。

Named Resource方式とLF-TBAC方式の比較

2-2. タグ付け戦略とタグ式

タグキーの設計方針

LF-Tagのキー設計はLF-TBAC全体の根幹です。後から変更が困難なため、導入前に組織のデータドメインとセキュリティ分類体系に合わせて設計します。

代表的なキー構成:

ひとつのリソースに複数のLF-Tagを付与できます(例: sensitivity=CONFIDENTIAL かつ domain=hr かつ data_class=pii)。複数タグを使うことで、「HRドメインのPIIデータへのアクセス」のような複合条件を表現できます。

タグ式(AND/OR演算子)

タグ式は複数のLF-Tagを組み合わせてアクセス条件を表現します。

• AND: すべてのタグ条件を満たすリソースにのみアクセス許可
• 例: sensitivity IN [INTERNAL, CONFIDENTIAL] AND domain = finance
• OR: いずれかのタグ条件を満たすリソースにアクセス許可
• 例: domain = hr OR domain = finance

AND/ORの組み合わせにより、複雑なアクセスポリシーをシンプルなタグ式で表現できます。

named LF-Tag expressions (2024年11月 GA)

named LF-Tag expressionsは、よく使うLF-Tagの組み合わせに名前を付けて再利用可能にする機能です。

# 例: 「機密HRまたは財務データ」の条件を命名
名前: confidential-people-data
タグ式: sensitivity=CONFIDENTIAL AND (domain=hr OR domain=finance)

命名したexpressionをプリンシパルに付与するだけで、個々のタグ条件を毎回記述する必要がなくなります。組織の共通ポリシー(例: セキュリティチームは全ドメインのCONFIDENTIALデータにアクセス可)を再利用可能な形で管理でき、大規模組織での権限管理の一元化に有効です。

2-3. ポリシー設計のベストプラクティス

タグキー・タグ値の設計ガイドライン

LF-Tagのキーと値は組織のデータ分類体系と一致させることが重要です。以下のガイドラインを参考にしてください。

• キー数を絞る: 過多なキーは管理コストを増やします。sensitivity・domain・envの3〜5キーから始めることを推奨します
• 値の数を制限する: 1キーあたりの値は10〜20程度に抑えます。細分化しすぎるとタグ付け作業が煩雑になります
• 命名規則を統一する: 大文字/小文字・スネークケース等を組織全体で統一し、誤付与を防ぎます
• 既存の分類体系に合わせる: 既存のデータカタログやIAMタグとキー名を揃えると運用の一貫性が高まります

最小権限の原則

LF-Tagをプリンシパルに付与する際は必要最小限のタグ範囲に絞ります。

• 特定ドメインのデータのみ必要なロールには domain=<対象ドメイン> のみ付与する
• 機密データへのアクセスが不要なロールには sensitivity=PUBLIC のみ付与する
• named LF-Tag expressionsで定義した共通ポリシーをベースに例外的な拡張を最小化する
• 定期的な権限レビューで不要なタグ付与を棚卸しする

分権管理とデータメッシュとの接続

大規模組織では中央のデータ管理者が全LF-Tagを管理することは現実的ではありません。Lake Formationでは特定のキーのLF-Tag管理をドメイン所有者(別アカウント/別チーム)に委任できます。

• 中央ガバナンスチームは sensitivity・data_class キーを管理(全社共通分類)
• 各ドメインチームは domain キーの値追加・リソースへのタグ付けを自律的に担当

この分権構造は§5データメッシュのプロデューサ/コンシューマモデルと直接つながります。ドメインごとにLF-Tagを自律管理しながら、中央カタログでクロスドメインのアクセス制御を統制できます。

LF-TBACの導入順序(推奨)

大規模環境への一括移行はリスクが高いため、段階的な導入を推奨します。まずsensitivityとdomainの2キーに絞ってパイロット導入し、運用負荷と権限モデルの妥当性を検証します。その後named LF-Tag expressionsで共通ポリシーを整備し、Named Resource方式との並行運用期間(hybrid access mode)を経てLF-TBAC中心の体制に移行します。

3. 行/列/セルレベルセキュリティ

3-1. 列レベルと行レベルのフィルタ（重要な前提）

Lake Formationのきめ細かいアクセス制御は database → table → column → row → cell という5段階の粒度でアクセスを制限できます。図3に示す3つの軸を正確に理解することが実装の前提です。

列レベルアクセス制御（Column-level）では、テーブルのカラムを include（対象カラムのみ公開）または exclude（指定カラムを非公開）で制限します。例えば salary・ssn 等のPIIカラムを特定ロールから除外する場合、exclude リストにカラム名を追加するだけで適用されます。

行レベルフィルタ（Row-level / data filter）は、SQL WHERE句形式の行フィルタ式で特定の行のみを返すように制限します。region = 'JP' や department = 'Finance' のような式を設定すると、プリンシパルはその条件に一致する行のみ参照できます。Lake FormationではこのフィルタをData filterと呼び、プリンシパルへの権限付与時に紐付けます。

3-2. セルレベルセキュリティの実装

セルレベルセキュリティは行フィルタ（data filter）と列フィルタを同一のData filterオブジェクトに組み合わせることで実現します。例えば「Finance部門の行のみ + PII列を除外」という制御を1つのData filterで表現できます。

コンソールでのData filter作成手順（AWS マネジメントコンソール）:

1. Lake Formation コンソール → 左メニュー「Data filters」→「Create data filter」
2. フィルタ名・対象データベース・対象テーブルを選択
3. 行フィルタ式（Row filter expression）にSQL WHERE句形式の条件を入力（例: department = 'Finance'）
4. 列フィルタ（Column selection）でincludeリスト（公開するカラム名）またはexcludeリスト（除外するカラム名）を指定
5. 「Create」でフィルタを保存

CLIでのData Cells Filter作成:

aws lakeformation create-data-cells-filter \
  --table-data-cells-filter \
 "DatabaseName=analytics_db,\
TableName=transactions,\
Name=finance_no_pii_filter,\
RowFilter={FilterExpression=\"department = 'Finance'\"},\
ColumnWildcard={ExcludedColumnNames=[\"ssn\",\"salary\"]}"

プリンシパルへの権限付与:

Data filterを作成したら、aws lakeformation grant-permissions または コンソールの「Grant」画面でIAMユーザー/ロールに付与します。付与後、そのプリンシパルがAthenaやRedshift Spectrumでクエリを実行すると、Lake FormationはData filterを自動的に適用し、行フィルタ条件に一致する行のみ・列フィルタで許可されたカラムのみを返します。アプリケーション側の改修は不要です。

3-3. ユースケース

① マルチテナント分析基盤（テナント別行制限）

複数のテナントデータが混在する共有テーブルに対し、tenant_id = 'tenant_a' のような行フィルタをテナントごとのIAMロールに付与します。テナントAのロールはテナントAの行のみ、テナントBのロールはテナントBの行のみを参照でき、テーブルを物理分割せずにマルチテナント分離を実現できます。テナントの増減があっても、Data filterの追加・削除だけで対応可能で、スキーマ変更は不要です。

② 部門別データ分割（組織の行制限）

department = 'Sales' や region = 'JP' のような行フィルタを部門ロールに付与することで、単一の大規模テーブルを部門ごとに論理分割できます。たとえばグローバル売上テーブルから「JP担当者はJP行のみ参照」という制御を、テーブルを複製せずに実現します。

③ PIIカラムのマスキング（列レベル）

氏名・メールアドレス・社会保障番号等のPIIカラムを exclude 指定で除外し、データアナリストには分析に必要な非PIIカラムのみを公開します。行フィルタと組み合わせれば「特定部門の行かつPII除外」というセルレベルの制御も1つのData filterで表現できます。

Macieで機密データの所在を自動検出し、検出されたPIIカラムをLake Formationの列レベルフィルタで制御する運用については§6で詳述します。

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

4-1. RAM統合によるクロスアカウント付与（重要な前提）

Lake Formation v4（UseOnlyIAMAccessControl: false）とAWS Resource Access Manager（RAM）を組み合わせることで、複数AWSアカウント間でData Catalogリソース（データベース/テーブル）を共有できます。hybrid access modeにより、Lake Formation管理下のリソースとIAMポリシーの混在環境にも対応します。

図4はクロスアカウント共有の2段階フローを示します。

ステップ1: プロデューサ側 — RAM共有

プロデューサアカウントのLake Formation管理者が、Data Catalogリソース（データベースまたはテーブル）をRAMリソース共有としてコンシューマアカウントに共有します。共有にはコンシューマアカウントID（またはAWS Organizationsの組織単位）を指定します。

ステップ2: コンシューマ側 — Lake Formation権限付与（必須）

重要な精度トラップ: RAM共有を受け入れただけではコンシューマはリソースにアクセスできません。 コンシューマアカウントのLake Formation管理者が追加手順を実施する必要があります。

1. コンシューマアカウントのData Catalogにリソースリンクを作成（プロデューサの共有リソースを参照するポインタ）
2. コンシューマアカウントのLake Formationで、データ利用者ロール/ユーザーに対してリソースリンクへのDESCRIBE権限 + 共有元テーブルへのSELECT権限を別途付与

この2段階の設計により、データオーナー（プロデューサ）がRAMで共有範囲を制御し、コンシューマ側管理者が利用者ごとの細粒度権限を管理する責任分担が実現します。RAM共有のみでアクセスが完結しないのは、Lake Formationがアカウント境界をまたいでもアクセス制御の分離を保証するための設計です。

4-2. コンシューマ側のリソースリンクとクエリ

リソースリンクの作成

コンシューマアカウントのLake Formationコンソール（またはGlue CreateDatabase APIでTargetDatabaseパラメータを使用）からリソースリンクを作成します。リソースリンクはコンシューマアカウントのローカルデータベース名として扱われますが、実態はプロデューサアカウントのData Catalogリソースへの参照です。作成後、コンシューマ側LF管理者が利用者ロールへDESCRIBE（リソースリンク）とSELECT（プロデューサ側テーブル）の権限を付与します。

Athenaからのクエリ

リソースリンクと権限付与が完了すると、コンシューマアカウントのAthenaから通常のテーブルと同様にクエリできます。

-- コンシューマアカウントのAthenaでクロスアカウントクエリ
SELECT department, SUM(sales_amount) AS total_sales
FROM consumer_local_db.resource_link_table
WHERE fiscal_year = 2026
GROUP BY department;

Athenaはリソースリンクを辿り、プロデューサアカウントのS3上のデータを直接参照します。データのコピーや転送は発生せず、Lake Formationの行フィルタ・列フィルタがクロスアカウント越しでも適用されます。

Redshift Spectrumからのクエリ

Redshift Spectrumを使う場合も、コンシューマアカウントのGlue Data Catalogをデータカタログとして参照することでリソースリンク経由のクロスアカウントクエリが可能です。Redshift IAMロールにコンシューマアカウントのLake Formation権限（lakeformation:GetDataAccessを含む）が付与されていることが前提です。外部スキーマ作成時にカタログIDとしてコンシューマアカウントIDを指定します。

5. データメッシュ — プロデューサ/コンシューマモデル

5-1. データメッシュの基本構造

データメッシュは、組織のデータをドメイン（業務領域）単位で所有・管理する分権型アーキテクチャです。Lake Formation v4の機能群は、AWSにおけるデータメッシュ実装の中核を担います。図5はプロデューサ/コンシューマドメインと中央Lake Formationカタログの全体像を示します。

ドメイン単位の所有権と自律性

各ドメイン（例: 販売・マーケティング・人事）は自律的にデータの生産・品質管理・アクセスポリシーを決定します。ドメインごとに独立したAWSアカウントを持つパターンが標準的で、各ドメインのデータオーナーが自らのData Catalogとデータ資産を管理します。ドメインを横断する中央チームがボトルネックになることなく、各ドメインが独立したペースでデータ基盤を進化させられる点がデータメッシュの本質的な価値です。

中央Lake Formationカタログによるアクセス委任

ドメイン間の自律性を維持しつつも、中央管理アカウントがLake Formationの管理者権限を保持し、各ドメインオーナーへアクセス制御の委任（delegation）を行います。この委任により、ドメインオーナーは中央管理者を介さずに、自ドメインのデータに対するLF-Tag管理や権限付与を実施できます。

§4で解説したRAM共有+コンシューマ側LF権限付与の2段階フローが、データメッシュにおけるドメイン間データ共有の基盤となります。

5-2. 分権LF-Tag管理

データメッシュの核心はLF-Tagの分権管理（decentralized LF-Tag management）にあります。§2で解説したLF-TBACの仕組みをドメイン分散型で適用することで、中央集権的な権限管理の複雑さを解消します。

LF-Tag管理権限の委任

Lake Formationでは、LF-Tag管理権限を特定のIAMプリンシパルへ委任できます。中央LF管理者がドメインごとのLF管理者ロールへGRANT PERMISSIONを委任することで、各ドメインは独立してタグの付与・変更を実施できます。

プロデューサ/コンシューマモデルでのLF-Tag統制フロー

LF-Tagによるドメイン間アクセス統制の典型的な流れは以下の通りです。

1. プロデューサ側LF管理者がEnvironment:prod・Sensitivity:internal・Domain:sales等のLF-Tagをテーブル/カラムに付与
2. プロデューサ側でRAM共有を実施、コンシューマアカウントへリソースを提供
3. コンシューマ側LF管理者が利用者ロールへLF-Tag: Environment=prod, Domain=salesに一致する権限を付与
4. コンシューマの分析者がAthena/Redshift Spectrum経由で当該LF-Tag付きデータにアクセス

LF-TBACによる自動スケール

この設計の最大の利点は、新規テーブルがプロデューサドメインに追加された場合も、既存のLF-Tagポリシーと一致するタグが付与されていれば自動的に権限が適用される点です（§2のLF-TBAC自動スケール特性のドメイン間版）。個別リソースごとのアクセス申請・更新作業が不要となり、データメッシュ規模でもガバナンスが持続可能になります。named LF-Tag expressions（2024-11 GA）を活用すると、Sensitivity=confidential AND Domain=hrのようなタグ組み合わせに名前を付けて管理できるため、複雑なドメイン間ポリシーも可読性高く維持できます。

6. Amazon Macieによる機密データ検出と統制

6-1. 自動機密データ検出と検出ジョブ（重要な前提）

Amazon Macieには機密データを検出する方式が2つあり、混同しやすい別機能として存在します。図6の左側（常時稼働）と右側（個別実行）に対応します。

① 自動機密データ検出（automated sensitive data discovery）

アカウント内の全S3バケットを対象に、継続的・自動的にサンプリングと分析を行う常時稼働型の機能です。

• 有効化するだけで全バケットをカバー: 新たにバケットが作成された場合も自動的に検出対象に追加されます
• 継続的モニタリング: 定期的にサンプリングを繰り返し、機密データの発生を早期に検知します
• 感度スコアの付与: バケット別に機密データの感度スコアと分類インベントリを自動生成します
• コスト最適化設計: 全オブジェクトをフルスキャンするのではなく、サンプリングベースで継続的に評価します

組織全体のS3データ資産における機密データの分布を把握し、ガバナンスの死角をなくすことが主眼です。

② 機密データ検出ジョブ（sensitive data discovery jobs）

特定のS3バケット・プレフィックス・オブジェクトを指定して個別に作成・実行する、手動トリガー型の別機能です。

• 対象を絞った精査: バケット名・プレフィックス・オブジェクトタグ等で対象を絞り込みます
• 実行タイプの選択: 1回限り（one-time）またはスケジュール（recurring: 日次/週次/月次）を選択可能です
• 詳細なfindingsレポート: 証拠の断片（occurrences）を含む詳細なfindings（検出結果）を生成します
• 主な活用場面: コンプライアンス監査、特定データセットの精査、セキュリティインシデント対応、移行前のデータ棚卸し

検出技術: 機械学習 + パターンマッチ

2つの方式は検出技術を共有しています。

さらにカスタムデータ識別子（custom data identifiers）を使えば、正規表現と近傍キーワードで独自の機密パターンを定義し、両方式の検出に適用できます。

6-2. Macie検出結果とLake Formation統制の連携

Macieのfindings（検出結果）は、機密データがどのS3バケット・オブジェクト・フィールドに存在するかを明示します。この情報を起点に、Lake FormationでS3上のデータレイク全体にきめ細かいアクセス制御とマスキングを適用します（図6右側フロー）。

連携の基本フロー

Macie findingsで機密データの所在（バケット・テーブル・カラム）を確認し、Glue Data Catalogで対象テーブル・カラムを特定した後、Lake Formationで以下のアクセス統制を適用します。

• LF-Tagによる機密度分類: PII/PHIを含む列・テーブルにsensitivity=high等のLF-Tagを付与し、アクセスポリシーを一括制御
• 列レベルフィルタ（column-level）: 機密列をexclude（除外）し、権限付与済みプリンシパルにのみ開示
• 行レベルフィルタ（data filter）: SQL WHERE句形式のフィルタで特定テナント・個人の行を絞り込み、マルチテナント分離を実現
• セルレベル（行×列の組み合わせ）: 行フィルタと列フィルタを組み合わせ、機密行かつ機密列のみを高権限ロール専用にマスキング

LF-Tagによる機密度分類の設計例

sensitivity = high ← PII/PHI/認証情報を含む列/テーブル
sensitivity = medium  ← 間接識別子（部門コード・IPアドレス等）
sensitivity = low  ← 非機密

Macieがsensitivity=high相当の機密データを検出したテーブル・カラムに対し、上記LF-Tagを付与することで、特定のIAMロールのみアクセス可能なポリシーを一括適用できます。

制御レベルと適用場面

EventBridgeを使った自動統制パイプライン

Macie findingsをリアルタイムで処理し、Lake Formation設定を自動更新するパイプラインを構築できます。

1. MacieがPII含む列を検出 → EventBridgeにfindings通知
2. Lambdaがテーブル名・カラム名を抽出
3. Lake Formation APIで当該カラムにLF-Tag（sensitivity=high）を付与
4. LF-Tagポリシーにより自動的にアクセス制限が適用される

この自動化により、新規データが追加された際にもガバナンスの空白期間を最小化できます。

7. データリネージとカタログ統制

7-1. カタログ中心のメタデータ統制

Glue Data Catalogは、データレイクにおけるメタデータの一元管理基盤です。データベース・テーブル・スキーマ・パーティション情報をカタログ化し、Lake FormationのLF-Tagと組み合わせることで、データ資産の分類とアクセス制御の統合が実現します。

TBAC文脈でのカタログ統制の核心は、LF-Tagをデータカタログのリソース(DB/テーブル/カラム)に付与し、タグ属性でデータ資産の機密度・ドメイン・環境を分類することです。分類されたメタデータはGlue Data Catalog上で可視化され、「機密度Highタグが付与されているテーブルは何か」「特定ドメインの資産一覧」といったデータ資産の俯瞰的な把握が可能になります。

データリネージの可視化という観点では、Glue Data Catalogに記録されたETLジョブとデータ移動の履歴が、「このデータはどこから来てどこへ流れたか」を追跡する起点になります。LF-Tagがリソースに紐付いているため、タグ分類とデータの流れを対応づけることで、機密データがどのパイプラインを経由しているかを把握できます。

データメッシュ構成(§5)では、各ドメインのLF-Tag管理者が自ドメインのカタログリソースにタグを付与します。この分権型メタデータ管理により、中央チームに依存しない自律的なデータカタログ運用が実現します。中央Lake Formationカタログはドメイン横断の可視性を保ちつつ、各ドメインが自ドメインのタグ・メタデータを自律管理する構造は、大規模組織のガバナンスに適合します。

7-2. 監査とコンプライアンス

Lake Formationの権限変更(GRANT/REVOKE)はすべてAWS CloudTrailに記録されます。CloudTrailのLakeFormationイベントを分析することで、「誰がいつどのリソースへの権限を変更したか」を詳細に追跡できます。

監査に活用する主要CloudTrailイベント:

データアクセスログの追跡では、Lake FormationのData Access Auditを有効化することで、S3データロケーションへのアクセスをAWS CloudTrail DataEventsとして記録できます。どのIAMプリンシパルがどのテーブル・パーティションにアクセスしたかを追跡し、意図しないアクセスパターンの検出に活用できます。

# CloudTrailでLake Formation権限変更を絞り込む(例: AWS CLIによるログ検索)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=lakeformation.amazonaws.com \
  --start-time 2026-01-01T00:00:00Z \
  --end-time 2026-06-30T23:59:59Z

コンプライアンス対応では、AWS CloudTrail Lakeを活用してLake FormationイベントをSQLクエリ可能な形で長期保管し、定期的な監査レポートを自動生成することが推奨されます。イベントデータストアにLake Formationログを集約することで、過去90日〜最大7年分の権限変更履歴を追跡できます。

Macieの機密データ検出結果(§6)と権限変更ログを組み合わせると、機密データへの不正アクセスリスクを多層的に把握できます。例えば、PII検出されたS3オブジェクトに対するLake Formation権限変更を優先的に監視することで、機密データガバナンスの実効性を高められます。

8. まとめとVol1連携

8-1. 本記事のまとめ

本記事で扱った各技術の要点を整理します。

LF-Tag タグベースアクセス制御 (LF-TBAC)
– LF-Tag(key:value)をデータカタログリソースとプリンシパルに付与し、一致時にアクセスを許可
– named LF-Tag expressions(2024-11 GA)でタグ組み合わせに名前を付けて管理
– タグ式はAND/OR演算子で表現し、IAM個別付与より大規模にスケール

行/列/セルレベルセキュリティ
– 行レベルフィルタ(data filter): SQL WHERE句形式で特定行のみ表示
– 列レベル: include/excludeでカラムを限定
– セルレベル: 行フィルタ+列フィルタの組み合わせでデータの最小単位まで制御

クロスアカウントデータ共有
– Lake Formation v4 + RAMでクロスアカウント付与・hybrid access mode対応
– ★RAM共有後、コンシューマ側でのLake Formation権限の別途付与が必須(RAM共有だけではアクセス不可)

データメッシュ
– ドメイン単位の所有権・自律性と中央Lake Formationカタログでの統制を両立
– decentralized LF-Tag管理でドメインチームが自律的に権限統制を担う

Amazon Macieによる機密データ検出
– 自動機密データ検出(automated sensitive data discovery): 全S3バケット対象に継続的にディスカバリ
– 機密データ検出ジョブ(sensitive data discovery jobs): 個別に作成・実行する別機能
– 機械学習+パターンマッチでPII/PHIを検出し、Lake Formationのきめ細かいアクセス制御と連携

データリネージとカタログ統制
– Glue Data CatalogにLF-Tagを組み合わせた分類・可視化でデータ資産のメタデータを統制
– CloudTrailでLake Formation権限変更を監査し、コンプライアンスを担保

8-2. シリーズ連携

Vol1ではAWS DataZone・Lake Formation基礎・Clean Rooms・データ品質/カタログというデータガバナンスの土台を構築しました。本Vol2では、その土台の上にきめ細かいアクセス制御の実装層を重ね、大規模・マルチアカウント環境での実践的なデータ統制を実現しました。

2巻を通じることで、データレイクの「設計から本番運用まで」のデータガバナンス全体像を実装できます。組織規模・マルチアカウント化・コンプライアンス要件の高度化に対応したAWSデータガバナンスのリファレンス実装として活用してください。

▶ Vol1: DataZone・Lake Formation・Clean Rooms・データ品質編に戻る