Databricks Certified Data Engineer Associate 教科書
第7章 ガバナンスとセキュリティ(Governance and Security, 15%)
🎯 この節の学習目標
7-2 で学んだ GRANT / REVOKE は、「このグループに、このテーブルの権限を与える」というオブジェクトとロールの対応付け、いわゆる RBAC(ロールベースアクセス制御)的な考え方でした。7-3 のマスク/フィルタも、対象テーブルを1つずつ指定して取り付ける個別適用です。これらは対象が数十テーブルなら十分機能しますが、数千テーブル規模になると「PII を含むテーブルを漏れなく洗い出し、1つずつ ALTER TABLE する」という運用自体が破綻します。
ABAC(Attribute-Based Access Control:属性ベースアクセス制御)は、この問題を「データ資産に付いた属性(タグ)を条件にポリシーを書く」ことで解決します。Unity Catalog の ABAC では次の2つを組み合わせます。
classification に対して値 pii / confidential / public だけを許可する、といった定義をします。自由記述のタグと違い、表記ゆれ(PII、pii_data…)でポリシーがすり抜ける事故を防げます。💡 具体例:「PII タグが付いた列はすべてマスク」ポリシー
マスキング関数(7-3 と同様の SQL UDF)を1つ用意し、カタログ main に対して「classification = 'pii' の governed tag が付いた列には、pii_readers グループ以外に対してこのマスク関数を適用する」というポリシーを定義したとします。ポリシーは SQL(CREATE POLICY)または Catalog Explorer の UI から作成できます。
-- イメージ:カタログ main 配下で、pii タグ付きの列をマスクするポリシー
CREATE POLICY pii_mask_policy
ON CATALOG main
COMMENT 'PIIタグ付き列の一括マスク'
COLUMN MASK main.security.mask_string
TO `account users`
EXCEPT `pii_readers`
FOR TABLES
MATCH COLUMNS has_tag_value('classification', 'pii') AS col
ON COLUMN col;
以後、データエンジニアが main 配下のどのテーブルであっても、列に classification: pii のタグを付ければ(ALTER TABLE ... ALTER COLUMN email SET TAGS ('classification' = 'pii'))、個別に SET MASK を実行しなくてもマスクが自動的に効きます。ポリシー定義は1か所だけで、適用漏れの心配が構造的になくなります。
ABAC は 7-2・7-3 の仕組みを置き換えるものではなく、その上に乗る集中管理層です。実際、ABAC ポリシーが適用する中身は 7-3 で学んだ行フィルタとカラムマスクそのものです。違いは「取り付け方」にあります。
| 観点 | RBAC(GRANT/REVOKE) | 個別のマスク/フィルタ | ABAC ポリシー |
|---|---|---|---|
| 制御の単位 | オブジェクト全体(読める/読めない) | 特定テーブルの特定の列・行 | タグ条件に合致する全資産の列・行 |
| 適用方法 | オブジェクトごとに GRANT/REVOKE | テーブルごとに ALTER TABLE で取り付け | ポリシーを1か所で定義し、タグで自動適用 |
| 新テーブルへの対応 | 継承があれば自動、なければ個別付与 | その都度 ALTER TABLE が必要 | タグさえ付けば自動適用 |
| 得意な規模 | すべての規模(アクセス制御の土台) | 対象が少数で個別要件が強い場合 | 大規模・組織横断の一括統制 |
📝 試験のポイント
キーワードの対応で判断できるようにしましょう。「特定のテーブルの列をマスクしたい」→ 7-3 の SET MASK。「組織内のあらゆるテーブルで、PII に分類された列を一貫してマスクしたい」「個別適用の漏れをなくしたい」→ ABAC ポリシー+governed tags。ABAC の本質は「ポリシーとデータ資産をタグで疎結合にする」ことで、テーブルが何千あってもポリシーは1つで済む点にあります。
ABAC ポリシーは、おおまかに次の4つの要素で構成されます。
TO で対象(例:account users = 全ユーザー)、EXCEPT で除外(例:許可グループ)を指定します。運用の流れとしては、「①管理者が governed tags のキー・許可値を定義 → ②セキュリティ担当がマスク/フィルタ用 UDF とポリシーを作成 → ③各チームは自分のテーブル・列に適切なタグを付けるだけ」という役割分担になります。タグ付けは自動分類機能やデータカタログ整備の一環として進められるため、セキュリティ設定そのものを各チームに配る必要がなくなります。
最後に、第7章で学んだガバナンス機能を「要件からの逆引き」で整理します。
| 要件 | 使う機能 | 節 |
|---|---|---|
| テーブル単位でアクセスの可否を制御したい | GRANT / REVOKE(グループへ、最小権限で) | 7-2 |
| 特定オブジェクトだけ読ませたくない(UC では DENY 非対応) | GRANT しない/REVOKE と権限範囲の設計(DENY はレガシーの hive_metastore のみ) | 7-2 |
| 特定テーブルの特定の列を伏字にしたい | カラムマスク(SET MASK) | 7-3 |
| 特定テーブルで本人の担当分の行だけ見せたい | 行フィルタ(SET ROW FILTER) | 7-3 |
| 組織全体で「PII 列はすべてマスク」のように一括統制したい | ABAC ポリシー + governed tags | 7-4 |
| DROP してもデータを残したい/外部ツールから直接読みたい | 外部テーブル(それ以外はマネージド) | 7-1 |
土台にはつねに 7-2 のアクセス制御(そもそも読めるか)があり、その上で 7-3 が「読める人の中での見え方」を制御し、7-4 の ABAC がそれを組織規模で自動化する、という積み重ねの関係です。
✅ この節のまとめ
問1. 数千のテーブルを持つ組織で、「PII に分類される列は、許可グループ以外にはすべてマスクする」という統制を、将来作られるテーブルも含めて適用漏れなく実現したい。最も適切な方法はどれか。
ALTER COLUMN ... SET MASK を実行する運用手順書を整備する正解:B
「組織横断」「将来のテーブルにも」「適用漏れなく」という要件は ABAC ポリシー+governed tags の典型ユースケースです。Aは手作業の個別適用であり、規模と将来のテーブルへの追随という点で破綻します。Cはそもそも Unity Catalog では DENY がサポートされておらず(レガシーの hive_metastore のみ)、仮に拒否できたとしてもテーブル全体が読めなくなり「PII 以外の列は使わせたい」という前提に合いません。Dはビューがテーブル数だけ乱立し、Aと同様に漏れと管理負荷の問題が残ります。
問2. governed tags(統制タグ)が、自由記述のタグと比べて ABAC に適している理由として最も適切なものはどれか。
正解:B
ポリシーはタグ条件で発火するため、タグの値が統制されていることが前提になります。governed tags はキー・許可値・付与権限を管理でき、「pii」「PII」「pii_data」のような表記ゆれで条件に合致しない事故を防ぎます。Aのような性能効果はありません。Cも誤りで、タグ付け自体は(自動分類の支援はあっても)資産ごとに行う必要があります。Dは誤りで、タグはアクセス許可を与えるものではありません。
問3. ABAC ポリシーと、7-3 で学んだ個別のカラムマスク(ALTER TABLE ... SET MASK)の関係として正しいものはどれか。
正解:B
ABAC は行フィルタ・カラムマスクという制御手段を、タグ条件のポリシーとして集中管理する層です。中身の技術は 7-3 と同じで、取り付け方が「個別」か「一括」かが違いです。Aは誤りで、ABAC が自動化するのは GRANT の発行ではなくマスク/フィルタの適用です。Cのような一律無効化はありません。Dは関係が逆で、ABAC はむしろ大規模組織での統制に強みがあります。
問4. 次の要件と機能の組み合わせのうち、適切でないものはどれか。
正解:D
列の伏字化はカラムマスク(SET MASK)の役割であり、USE SCHEMA はスキーマの中を通行するための前提権限にすぎないため、Dの組み合わせが不適切です。Aは適切な組み合わせです(Unity Catalog に DENY はないため、読ませたくない相手には GRANT しない/REVOKE するのが正しい対応です)。Bは特定テーブルへの個別適用なので行フィルタ、Cはタグ条件による組織横断の一括制御なので ABAC が適切です。