DEA / ドメイン4 データセキュリティとガバナンス
重要な内容
AWS Lake Formation
は、 のと Data Catalog に対するアクセス権限を、データベース・テーブル・列・行の単位で一元管理するサービスです。 DEA では、・・・Glue から同じテーブルを使う利用者に、どの列・行まで見せるかを Lake Formation で制御し、アカウントをまたいで共有する設計が問われます。
Point
- Lake Formation は「データレイクの形成」という意味で、データレイクの構築とガバナンスを助けるサービスです。
- LF-Tags は Lake Formation 専用のタグで、IAM のタグとは別物です。
- Data Catalog は、Glue が持つテーブル定義 (スキーマと S3 の場所) の目録です。
- 和訳
- Formation: 形成、構成
- Governance: 統治、管理
- Weblio英和辞書「governance」
概要
のポリシーと だけでの権限を管理すると、「この列だけ隠したい」「この部署の行だけ見せたい」といった要件を表現できません。オブジェクト (ファイル) 単位の制御しかできないためです。 は、Data Catalog のテーブルに対して の GRANT のような権限を付け、統合された分析エンジンがその権限に従ってデータを返します。
| 見るポイント | 代表的な判断 |
|---|---|
| 列や行の単位で見せ分けたいか | Lake Formation のデータフィルターを使います。 |
| テーブルが多く、権限の付与が爆発しそうか | によるタグベースの制御を使います。 |
| 別アカウントにデータを使わせたいか | Lake Formation の共有で、コピーせずに共有します。 |
| 既存の IAM による運用を止めずに移行したいか | ハイブリッドアクセスモードで段階的に切り替えます。 |
主要技術
①仕組み: 場所の登録と権限の二重チェック
で管理するには、まずデータの の場所 (やプレフィックス) を Lake Formation に登録します。登録時に指定した ロール (サービスリンクロールまたは独自のロール) で、Lake Formation がデータにアクセスします。 統合された分析エンジンは、利用者の権限を Lake Formation に確かめ、許可された範囲だけを読むためのを受け取ります (認証情報の払い出し)。
| 権限の層 | 役割 |
|---|---|
| IAM ポリシー | や の を呼べるか、lakeformation:GetDataAccess を呼べるかを決めます。 |
| Lake Formation の権限 | どのデータベース・テーブル・列・行を読めるか、書けるかを決めます。 |
| 主な権限 | 対象 | 内容 |
|---|---|---|
CREATE_DATABASE | カタログ | データベースを作れます。 |
CREATE_TABLE、ALTER、DROP | データベース・テーブル | メタデータを作成・変更・削除できます。 |
SELECT、INSERT、DELETE | テーブル | データを読む・書く・消すことができます。 |
DESCRIBE | データベース・テーブル | メタデータを見られます。 |
DATA_LOCATION_ACCESS | 登録した S3 の場所 | その場所を指すテーブルを作れます。 |
| 付与可能 (grant option) | 各権限 | 受け取った権限をさらに他者へ付与できます。 |
管理者 (data lake administrator) は、すべてのリソースに権限を付与できる管理者です。日常の付与は、管理者が付与可能な権限を各チームのデータ所有者へ委ねる形にすると運用が回ります。
⚠️ 頻出: 利用者に S3 の直接の読み取り権限 (s3:GetObject) が残っていると、Lake Formation を通さずにファイルを読めてしまいます。Lake Formation で絞るなら、利用者の IAM ポリシーから対象の場所への S3 の直接の権限を外します。
②列・行・セルの単位の権限 (データフィルター) ⚠️ 頻出
| 制御 | 設定 | 例 |
|---|---|---|
| 列レベル | 含める列・除く列を指定します。 | 人事部以外には生年月日やマイナンバーの列を見せません。 |
| 行レベル | 行フィルター式 (PartiQL の WHERE 句に近い書き方) を指定します。 | 各地域の担当者には region='kanto' の行だけを見せます。 |
| セルレベル | 列の指定と行フィルター式を組み合わせます。 | 国が UK の行だけ住所の列を隠します。 |
データフィルターは読み取りにだけ効くため、付与できるのは SELECT 権限だけです。
入れ子の列 (struct) の一部だけを含めたり除いたりすることもできます。
③LF タグによるタグベースのアクセス制御 (LF-TBAC)
は classification=confidential のようなキーと値の組です。データベース・テーブル・列に付け、利用者には「この LF タグ式に一致するリソースへの SELECT」のように付与します。
| 方式 | 付与の数 | 向いている場面 |
|---|---|---|
| 名前付きリソース方式 | 利用者の数 × リソースの数 | テーブルが少なく、個別に付与したい場合です。 |
| LF タグ方式 (LF-TBAC) | 利用者の数 + リソースの数 | テーブルが多く、増え続ける場合です。AWS が推奨する方式です。 |
テーブルはデータベースの LF タグを、列はテーブルの LF タグを継承し、継承した値は上書きできます。 新しいテーブルを作っても、適切な LF タグを付ければ既存の付与がそのまま効くため、権限の付け忘れが起きにくくなります。
④統合された分析エンジン
| エンジン | との関係 |
|---|---|
| 利用者 (ワークグループのロールやした利用者) の Lake Formation の権限に従い、列・行・セルのフィルターを適用します。 | |
| 外部スキーマを Data Catalog から作り、Lake Formation の権限に従って のテーブルを読みます。を Lake Formation で管理する方式もあります。 | |
| EMR ( 上のクラスター、EMR Serverless、EMR on ) は、ランタイムロールなどの設定で Lake Formation の細かい権限に従って のクエリを実行できます。 | |
| ( ジョブ、) | ジョブやクローラーのロールに Lake Formation の権限を付与します。クローラーがテーブルを作るには、データベースへの CREATE_TABLE と場所への DATA_LOCATION_ACCESS が必要です。 |
| (旧 ) | Athena 経由で読む場合、Lake Formation の権限が効きます。 |
⚠️ 頻出: 「Glue クローラーのロールに S3 の権限を付けたのにテーブルが作られない」場合は、Lake Formation でデータベースへの CREATE_TABLE (と場所の権限) が付与されているかを確かめます。
⑤アカウントをまたぐ共有
は、中央のアカウントのテーブルを、データをコピーせずに他のアカウントへ共有できます。共有には (Resource Access Manager) が裏で使われます。
| 用語 | 意味 |
|---|---|
| リソースリンク | 共有されたデータベース・テーブルを、利用側の Data Catalog から参照するための別名です。 などはリソースリンク経由でクエリします。 |
| のバージョン設定 | 共有の方式の版です。新しい版ほど RAM の共有の数を減らせたり、ハイブリッドアクセスモードと組み合わせられたりします。 |
| 再付与 | 利用側のデータレイク管理者が、受け取った権限を自アカウントの利用者へ付与します。 |
型の構成 (各ドメインが自分のアカウントでデータを持ち、中央のアカウントがカタログと権限を管理する) でも、この共有の仕組みを使います (「データガバナンスとデータ共有のパターン」の章)。
⑥ハイブリッドアクセスモードと既定の動き
を有効にしても、既存のテーブルには IAMAllowedPrincipals グループへの権限が付いていて、 だけでアクセスできる状態のことがあります (IAM のみのアクセス制御との互換の設定)。
既存の IAM による運用を止めずに移行したい場合は、 の場所をハイブリッドアクセスモードで登録します。
| モード | 動き |
|---|---|
| Lake Formation の権限を強制 | 登録した場所のテーブルは、Lake Formation の権限がないと読めません。 |
| ハイブリッドアクセスモード | オプトインした利用者には Lake Formation の権限 (と IAM の権限) を求め、それ以外の利用者は従来どおり IAM の権限で読めます。 |
⑦Lake Formation を前提にしたスキーマの設計
権限は Data Catalog のデータベース・テーブル・列に付くため、スキーマの設計が権限の設計を左右します。
| 設計の観点 | 考え方 |
|---|---|
| データベースの分け方 | 取り込みの段階 (raw、curated、分析用) やドメイン (販売、人事) ごとにデータベースを分け、データベースの単位で を付けると継承で管理しやすくなります。 |
| 機密の列 | の列には classification=pii のような LF タグを列レベルで付け、一般の利用者への付与から外します。 |
| 機密の列が多いテーブル | 個人情報だけを別テーブルに分け、共通のキーで結合できるようにする設計もあります。 |
| パーティション | 行フィルターで使う列 (地域、日付) をパーティションにすると、フィルターと読み取り量の削減を両立できます。 |
| 個人情報の発見 | で の個人情報を検出し、その結果を基に該当するテーブル・列へ LF タグを付けて保護します。 |
試験対策
の問題では、「 や では表現できない粒度 (列・行・セル) の制御」「多数のテーブルへの付与」「コピーなしの共有」のどれが要件かを見ます。 どれかが当てはまれば Lake Formation を選びます。
①判断マトリクス
| 問題文のキーワード | 選ぶもの | 理由 |
|---|---|---|
| 特定の列 () をアナリストから隠したい | 列レベルの権限 (データフィルター) | などのクエリ結果から列を除きます。 |
| 地域ごとの担当者に自地域の行だけ見せたい | 行フィルター式のデータフィルター | 行の単位で絞ります。 |
| 行の条件によって特定の列だけ隠したい | セルレベルのデータフィルター | 行と列の組み合わせで制御します。 |
| 数百のテーブルに機密度ごとの権限を付けたい | (LF-TBAC) | 付与の数が利用者数 + リソース数で済みます。 |
| 新しいテーブルにも自動で同じ権限を効かせたい | データベースに LF タグを付けて継承させる | 個別の付与が不要になります。 |
| 中央のを複数アカウントで使いたい | の共有 + リソースリンク | データをコピーしません。 |
| 既存の の利用者を止めずに導入したい | ハイブリッドアクセスモード | 利用者ごとに段階的に切り替えます。 |
| がテーブルを作れない | CREATE_TABLE と DATA_LOCATION_ACCESS の付与 | Lake Formation の権限が不足しています。 |
| Lake Formation で絞ったのに から直接読めてしまう | 利用者の IAM から S3 の直接の権限を外す | Lake Formation を経由しない経路を断ちます。 |
| S3 の個人情報を見つけて保護したい | で検出 + Lake Formation で列を保護 | 検出と制御を組み合わせます。 |
②よくある誤答
- と のタグを同じものとして扱うこと。
- データフィルターで
INSERTやDELETEを絞れると考えること。フィルターはSELECTだけです。 - が の処理をすると考えること。ETL は のジョブ、Lake Formation は権限の管理です。
- Lake Formation だけで暗号化が完結すると考えること。 の暗号化と のキーポリシーは別に設定します。