Databricks ABAC で実現するガバナンス― カラムアクセス監査 × 属性ベース制御で「見える化」と「防止」を両立する ―

これはDatabricks Advent Calendar 2025の24日目の記事です。

こんにちは、IVRy でデータ基盤まわりを担当している George です。

直近は Databricks を中心に、
「事業で安心して使い倒せるデータ基盤をどう作るか」 というテーマで、
データ設計・権限設計・ガバナンスの実装を考えたり手を動かしたりしています。

全くの余談ですが、この 1 年間は 日本酒にどっぷりハマり、
ついには 日本酒の資格を取得するほど 好きになりました 🍶
弊社IVRy内で日本酒のクラブ活動の様子を紹介してますので、良ければ読んでください。
日本酒が繋ぐIVRy ― 入社1年の僕が見た「人が集まる」文化

本記事では、そんな自分がこの 1 年間 Databricks を本格運用する中で向き合ってきた ABAC（Attribute-Based Access Control）を使った PII カラムのガバナンス設計と実装について、実運用の視点でまとめています。

TL;DR（サマリ）

Databricks ABAC を活用することで、PII カラムへの「実際のアクセス可視化」と「事前防止」を両立した実運用レベルのデータガバナンスが実現できます。

• Databricks ABAC（Attribute-Based Access Control）が2025年に GA
• PIIカラムへの「誰が・いつ・どう触ったか」を system テーブルで可視化
• dbt の yaml で PII タグを管理し、ABAC ポリシーと連携
• ABAC は View には効かないため、Table化が必須
• RBACのリリースによてい、今後は RBAC × ABAC の併用が王道になる

はじめに

Databricks をデータ基盤として本格利用する中で、
「PII（個人情報）をどう安全に、かつスケーラブルに扱うか」 は避けて通れないテーマです。

多くの現場では、

• テーブル単位では OK だが、一部カラムだけが PII
• アクセス制御はしているが、実際に誰が触っているか分からない
• ロールベースだけでは データの意味（PII / 非 PII）を表現しきれない

といった課題に直面します。

こうした課題に対する Databricks の一つの答えが、
ABAC（Attribute-Based Access Control） です。

本記事では、2025年にGAしたABACを軸に、実運用での設定方法と注意点、そして 今後予定されている RBAC との関係 までをまとめて紹介します。

予防的統制と発見的統制という考え方

データガバナンスや内部統制の文脈では、統制は大きく 「予防的統制（Preventive Control）」 と 「発見的統制（Detective Control）」 の2つに分類されます。

予防的統制とは、
不正や事故が起きる前に、それ自体を防ぐための仕組みです。

例えば、

• アクセス権限による閲覧制御
• PII カラムのマスキング
• 実行できる操作そのものの制限

などが該当します。
「そもそも見えない・触れない」状態を作ることで、事故を未然に防ぐのが目的です。

一方で 発見的統制 とは、
不正や事故が起きた後に、それを検知・把握できる仕組みです。

例えば、

• 誰が・いつ・どのデータにアクセスしたかの監査ログ
• クエリ履歴やダウンロード履歴の追跡
• 異常なアクセスパターンの検知

などがこれにあたります。
「何が起きたのかを後から説明できる」状態を作ることが重要になります。

多くのデータ基盤では、
どちらか一方だけに偏ってしまうケースが少なくありません。

• 制御はしているが、実際に誰が触っているか分からない
• ログはあるが、問題が起きる前に止められない

という状態です。

本記事で紹介する Databricks の ABAC を活用した設計は、

• system テーブルによるカラムアクセス監査（発見的統制）
• ABAC による PII カラムのマスキング・制御（予防的統制）

を組み合わせることで、
「見える化」と「防止」を両立する実運用レベルのデータガバナンスを実現するアプローチになります。

Databricks ABAC とは？

ABAC は、データやユーザーに付与された「属性（タグ）」に基づいてアクセス制御を行う仕組みです。

Databricks では Unity Catalog と統合され、

• カタログ / スキーマ / テーブル / カラム
• に管理タグ（例：pii = end_user）を付与し
• そのタグを条件に用意した関数を実行して マスキング・フィルタ・アクセス制御 を行えます。

Attribute-based access control (ABAC) enables fine-grained data access control based on attributes such as data classification tags.
https://docs.databricks.com/aws/en/data-governance/unity-catalog/abac

ABAC を実現するDatabricksの機能の特徴は

• カラム単位の制御が可能
• ポリシーを一度定義すれば 複数テーブルに横断適用
• 新しいカラムが追加されても タグが付けば自動保護
• クエリを書き換えずに制御可能

になります。
本記事の後半で実際にどう設定するといいか実践していきます。

まずは「実際の PII アクセス」を可視化する

ただ、制御の前に重要なのが 現状把握 です。
そもそも誰が PII にアクセスしているのか分からない状態で制御を設計しても、過剰・不足のどちらかになりがちです。

Databricks では以下の system テーブルを組み合わせることで、カラム単位の実アクセス履歴 を追跡できます。

• system.query.history
• system.access.column_lineage
• system.access.audit

これにより、

• どのユーザーが
• どのテーブル・カラムを参照し
• どんなクエリを実行し
• その結果をダウンロードしたか

までが分かるようになります。

実際に使っているクエリ例（抜粋）

WITH download_events AS (
  SELECT
    request_params.queryId AS query_id,
    MIN(event_time) AS first_download_query_result_event_time
  FROM system.access.audit
  WHERE action_name = 'downloadQueryResult'
  GROUP BY ALL
)
SELECT
  h.start_time,
  h.executed_by,
  t.source_table_full_name,
  t.source_column_name,
  h.statement_text,
  h.statement_type,
  e.first_download_query_result_event_time
FROM system.query.history h
INNER JOIN system.access.column_lineage t
  ON t.statement_id = h.cache_origin_statement_id
LEFT JOIN download_events e
  ON h.query_source.sql_query_id = e.query_id
ORDER BY h.start_time DESC;

この結果を可視化することで、
「PII カラムを見た」「その時どんなクエリを実行した」「ダウンロードした」事実を後追いで確認可能になります。

これを踏まえたうえで、DatabricksでABACの具体的な設定として、
カラムマスキングを行う手順を説明します。

ABAC を使った PII カラム制御の実装

カラムにPIIタグを設定し、ユーザーがクエリした際にマスキングを行う関数を作成し、それらをポリシー設定画面で設定することにより、対象となるユーザーがPIIカラムをクエリした際に関数が適用される仕組みとなっています。

1. dbt で PII カラムに管理タグを付与

Databricks UI から対象のPIIカラムにタグを付与することもできますが、dbtでも可能です。

models:
  - name: confidential_table_x
    columns:
      - name: end_user_name
        databricks_tags:
          pii: "end_user"

https://docs.getdbt.com/reference/resource-configs/databricks-configs

dbtのyamlに上記の様に記述することにより、
dbt 実行時にconfidential_table_xテーブルのend_user_nameカラムへpii = end_user タグが付与されます。

dbtのコードで記述することで、githubなどで管理することができ、手動運用により誤りを防ぐことができます。

2. カラムマスキング関数の作成

マスキング適用時に実行される関数を定義します。ユーザが対象カラムにアクセスしたとき実行されます。下記の関数を事前に作成しておき、ポリシー作成時に指定します。

CREATE FUNCTION catalog_x.default.mask_pii_string(
  target_string STRING
)
RETURNS STRING
RETURN '***-**-****';

3. ABAC ポリシーを作成

UnityCatalogのカタログ画面からポリシーを作成します。

例えば以下のように設定することで、管理者ユーザを除いた全ユーザにカラムマスキングを適用できます。

• 対象タグ：pii = end_user
• 対象ユーザーを「すべてのユーザー」に適用
• 除外ユーザーを「管理者ユーザ(account_admin)」に適用

これだけの設定でユーザーとテーブル横断で一括適用できるのがABAC の強みです。

以上のABAC関連の設定により、PIIカラムへのアクセスを制限することができました。

運用Tips：ABAC は View には効かない（重要）

ここは地味に重要なポイントで、現時点では、ABACのカラムマスキングはViewには適用されません。

Databricks 公式ドキュメントで、

Policies are enforced on tables. Policies are not applied to standard views.
https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks?utm_source=chatgpt.com#limitations

と明記されています。

そのためPIIを含むデータをViewで提供せず、Tableにしておく必要があります。

今後、RBAC がリリースされたらどう変わるか？

これまで説明してきたABACとは違い、ユーザーにロールを割り当て、そのロールに権限を付与する 仕組みを中心にデータアクセスを制御する方式をRBAC（Role-Based Access Control）といいます。

先日Databricks社から RBAC が Private Preview のアナウンスがありました。(公開ドキュメントはまだないようで、セミナー内での発表でした)

ABAC は「属性」による動的なアクセス制御 を行うのに対し、RBAC は「役割」ベースでアクセス制御を行います。

• RBAC： ユーザー → ロール → 権限
• ABAC： ユーザー属性 + リソース属性 + 環境属性 → ポリシー

詳細はドキュメントが公開されたら検証しようと思いますが、Snowflakeなどで実装されている同機能を鑑みると、下記のような機能になるかと思います。

• ロールごとにデータセットへの権限（閲覧、編集、管理）が付与される
• ユーザーは役割（ロール）を持つことで初めて権限を有する
• ユーザは複数の役割（ロール）を切り替えることができる
• ロール同士を階層化できるため、権限継承も可能

今後 Databricks に RBAC が本格導入されると、最も自然なのは RBAC × ABAC の併用です。

Databricks も Snowflake と同様に、“役割で入口を制御し、属性で意味を制御する” 世界観に向かっていると考えています。

RBAC で大枠を決め、ABAC で意味的な制御をかける方式になり、例えば、下記のように分けて管理する形になるかと思います。

• RBAC
  • 業務ロール（Biz / SRE / Data Engineer）
  • テーブル・操作レベルの大枠制御
• ABAC
  • PII / Confidential などのデータ属性
  • カラム・行レベルの細粒度制御

現時点だとユーザが所属するユーザーグループ単位での権限付与になっていますが、これを独立したロール単位で権限構成を決め、ユーザに複数持たせる形での設計ができることになります。

来年にはGAになるでしょうから、Databricks における 次世代ガバナンスの形と捉えて準備しておきたいですね。

おわりに

• ABAC は 「後付けガバナンス」ではなく設計思想そのもの
• カラムアクセス監査と組み合わせることで 実効性が生まれる
• View 制約を理解しないと 事故る
• RBAC が来ても ABAC の価値はむしろ高まる

Databricks の大きな特徴であるデータガバナンスを本気で使い倒すためにも、ABAC は触っておきましょう！

Happy Databricks & Happy Advent Calendar 🎄