第7章 ガバナンスとセキュリティ / 想定学習時間:30〜40分 / 最終確認:2026年8月

7-4. Unity Catalog ABACポリシーによる集中管理

🎯 この節の学習目標

1. ABAC とは:「誰に」ではなく「どんな属性のデータか」で制御する

7-2 で学んだ GRANT / REVOKE は、「このグループに、このテーブルの権限を与える」というオブジェクトとロールの対応付け、いわゆる RBAC(ロールベースアクセス制御)的な考え方でした。7-3 のマスク/フィルタも、対象テーブルを1つずつ指定して取り付ける個別適用です。これらは対象が数十テーブルなら十分機能しますが、数千テーブル規模になると「PII を含むテーブルを漏れなく洗い出し、1つずつ ALTER TABLE する」という運用自体が破綻します。

ABAC(Attribute-Based Access Control:属性ベースアクセス制御)は、この問題を「データ資産に付いた属性(タグ)を条件にポリシーを書く」ことで解決します。Unity Catalog の ABAC では次の2つを組み合わせます。

💡 具体例:「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か所だけで、適用漏れの心配が構造的になくなります。

2. RBAC・個別マスク/フィルタとの違い

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つで済む点にあります。

3. ポリシーの構成要素

ABAC ポリシーは、おおまかに次の4つの要素で構成されます。

運用の流れとしては、「①管理者が governed tags のキー・許可値を定義 → ②セキュリティ担当がマスク/フィルタ用 UDF とポリシーを作成 → ③各チームは自分のテーブル・列に適切なタグを付けるだけ」という役割分担になります。タグ付けは自動分類機能やデータカタログ整備の一環として進められるため、セキュリティ設定そのものを各チームに配る必要がなくなります。

4. 大規模組織でのメリット

5. 第7章のまとめ:ガバナンス機能の使い分け

最後に、第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 tags7-4
DROP してもデータを残したい/外部ツールから直接読みたい外部テーブル(それ以外はマネージド)7-1

土台にはつねに 7-2 のアクセス制御(そもそも読めるか)があり、その上で 7-3 が「読める人の中での見え方」を制御し、7-4 の ABAC がそれを組織規模で自動化する、という積み重ねの関係です。

✅ この節のまとめ

練習問題

問1. 数千のテーブルを持つ組織で、「PII に分類される列は、許可グループ以外にはすべてマスクする」という統制を、将来作られるテーブルも含めて適用漏れなく実現したい。最も適切な方法はどれか。

  1. PII を含む全テーブルを洗い出し、1つずつ ALTER COLUMN ... SET MASK を実行する運用手順書を整備する
  2. governed tag(例:classification = pii)を定義し、タグ付きの列にカラムマスクを自動適用する ABAC ポリシーをカタログに定義する
  3. PII 列を含むテーブルへの SELECT をすべて DENY 文で拒否する
  4. PII 列を除外したビューをテーブルごとに作成して公開する
解答と解説を見る

正解:B

「組織横断」「将来のテーブルにも」「適用漏れなく」という要件は ABAC ポリシー+governed tags の典型ユースケースです。Aは手作業の個別適用であり、規模と将来のテーブルへの追随という点で破綻します。Cはそもそも Unity Catalog では DENY がサポートされておらず(レガシーの hive_metastore のみ)、仮に拒否できたとしてもテーブル全体が読めなくなり「PII 以外の列は使わせたい」という前提に合いません。Dはビューがテーブル数だけ乱立し、Aと同様に漏れと管理負荷の問題が残ります。

問2. governed tags(統制タグ)が、自由記述のタグと比べて ABAC に適している理由として最も適切なものはどれか。

  1. governed tags を付けるとテーブルのクエリ性能が向上するため
  2. キーと許可される値、付与できる人を管理者が統制でき、表記ゆれによるポリシーのすり抜けを防げるため
  3. governed tags は自動的にすべての列に付与されるため、タグ付け作業が不要になるため
  4. governed tags を付けたテーブルは GRANT なしで全員が読めるようになるため
解答と解説を見る

正解:B

ポリシーはタグ条件で発火するため、タグの値が統制されていることが前提になります。governed tags はキー・許可値・付与権限を管理でき、「pii」「PII」「pii_data」のような表記ゆれで条件に合致しない事故を防ぎます。Aのような性能効果はありません。Cも誤りで、タグ付け自体は(自動分類の支援はあっても)資産ごとに行う必要があります。Dは誤りで、タグはアクセス許可を与えるものではありません。

問3. ABAC ポリシーと、7-3 で学んだ個別のカラムマスク(ALTER TABLE ... SET MASK)の関係として正しいものはどれか。

  1. ABAC はマスクとは無関係の、GRANT/REVOKE を自動発行する仕組みである
  2. ABAC ポリシーが適用する制御の中身は行フィルタ・カラムマスクと同種のものであり、違いは「テーブルごとに手動で取り付けるか、タグ条件で集中適用するか」にある
  3. ABAC を有効にすると、個別のカラムマスクはすべて無効になる
  4. 個別のカラムマスクの方が常に優れており、ABAC は小規模組織向けの簡易機能である
解答と解説を見る

正解:B

ABAC は行フィルタ・カラムマスクという制御手段を、タグ条件のポリシーとして集中管理する層です。中身の技術は 7-3 と同じで、取り付け方が「個別」か「一括」かが違いです。Aは誤りで、ABAC が自動化するのは GRANT の発行ではなくマスク/フィルタの適用です。Cのような一律無効化はありません。Dは関係が逆で、ABAC はむしろ大規模組織での統制に強みがあります。

問4. 次の要件と機能の組み合わせのうち、適切でないものはどれか。

  1. 「UC 上で、あるグループにテーブルを読ませたくない」→ SELECT を GRANT しない/REVOKE する(UC に DENY はない)
  2. 「営業担当には自分の地域の行だけ見せたい(対象は特定の1テーブル)」→ 行フィルタ(SET ROW FILTER)
  3. 「全カタログで『confidential』タグ付きテーブルの行を一括で絞りたい」→ ABAC ポリシー
  4. 「特定テーブルのメール列を伏字にしたい」→ GRANT USE SCHEMA
解答と解説を見る

正解:D

列の伏字化はカラムマスク(SET MASK)の役割であり、USE SCHEMA はスキーマの中を通行するための前提権限にすぎないため、Dの組み合わせが不適切です。Aは適切な組み合わせです(Unity Catalog に DENY はないため、読ませたくない相手には GRANT しない/REVOKE するのが正しい対応です)。Bは特定テーブルへの個別適用なので行フィルタ、Cはタグ条件による組織横断の一括制御なので ABAC が適切です。