【Databricks】管理タグの伝搬（Tag propagation）とABACを組み合わせて利用してみた
データ事業本部のueharaです。
2026年10月12日に、Databricksの 管理タグ（Governed tag）の伝搬（Tag propagation） がBeta版としてリリースされました。
リリースノートには、次のように書かれています。
When you enable tag propagation for a governed tag, Unity Catalog uses lineage to automatically apply that tag to derived tables and views whenever a supported operation runs, such as
CREATE TABLE AS SELECT,CREATE VIEW,INSERT INTO ... SELECT, orMERGE.
今回は、管理タグの伝搬が何を解決する機能なのかを整理したうえで、ABAC（属性ベースのアクセス制御）のマスクが、派生テーブルでも自動で反映されることを実際に確認してみたいと思います。
管理タグとABACについて
管理タグ
管理タグは、アカウントレベルで管理するタグです。
タグを作る際に、次のようなルールを定義します。
- 許可する値（例:
ssn、email） - タグを付けられるユーザー、グループ（
ASSIGN権限） - タグの定義を管理できるユーザー、グループ（
MANAGE権限）
通常のタグは誰でも自由に付けられますが、管理タグは決められた人が、決められた値だけを付けられます。
ABAC
ABAC（Attribute-Based Access Control）は、管理タグをもとに、行フィルタや列マスクを自動で適用する仕組みです。
例えば「pii というタグが付いた列は、アナリストにはマスクして見せる」というポリシーを、カタログやスキーマに1つ作れば、タグが付いたすべての列に適用されます。
これにより、テーブルごとにマスクを設定しなくて済み、設定や管理が容易になります。
伝搬（Tag propagation）がないと困ること
ABACは便利ですが、1つ注意点があります。
それは、タグが付いていない列にはポリシーが適用されないことです。
例えば、ソーステーブルの ssn 列にタグを付けてマスクを適用していても、 CREATE TABLE AS SELECT （CTAS）で作った派生テーブルには、タグが自動では引き継がれません。
派生テーブルの ssn 列は、タグがないのでマスクされず、アナリストに生データが見えてしまいます。
これを防ぐには、派生テーブルを作るたびに手動でタグを付け直す必要がありますが、付け忘れによる事故が発生する可能性が生じます。
Tag propagationは、この問題を解決する機能です。
伝搬の仕様
公式ドキュメントから、押さえておきたい点をまとめます。
| 項目 | 内容 |
|---|---|
| 対象のタグ | 管理タグ（システムタグを含む）のみ。通常のタグは伝搬しない |
| 設定の単位 | タグごとにON/OFFを設定する。デフォルトはOFF |
| 伝搬の仕組み | リネージをもとに、テーブルレベル、列レベルの両方で伝搬する |
| 対象の操作 | CREATE TABLE AS SELECT、CLONE(テーブルレベルのみ)、CREATE VIEW / ALTER VIEW / CREATE OR REPLACE VIEW、INSERT INTO ... SELECT、MERGE |
| コンピュート | サーバーレスのみ。クラシックコンピュートは非対応 |
| タイミング | 非同期。操作の完了後、通常は数分以内に反映される |
| 衝突時 | 複数のソースで同じキーの値が異なる場合は、タグごとに設定した Default propagation value が使われる |
| 権限 | 新しい権限は不要。実行ユーザーに ASSIGN 権限がなくても伝搬する |
また、次のものは対象外です。
- ボリュームなど、テーブル以外のセキュリティ保護可能なオブジェクト
- Lakeflow Spark宣言型パイプラインのストリーミングテーブルとマテリアライズドビュー
検証の構成
今回は、次の構成で検証します。
| 項目 | 内容 |
|---|---|
| ユーザーA | 管理者兼データエンジニア。マスクの対象外 |
| ユーザーB | アナリスト。マスクの対象 |
| グループ | tagprop_admins（ユーザーA）、tagprop_analysts（ユーザーB） |
| 管理タグ | pii（許可値: ssn、email） |
| カタログ | tagprop_test（スキーマ: src、derived、common） |
| ソーステーブル | src.customers（ssn 列と email 列に pii タグを付ける） |
| ABACポリシー | pii タグが付いた列を、tagprop_analysts にだけマスクする |
確認する流れは、次の通りです。
- Before：伝搬がOFFの状態で、CTASで派生テーブルを作る。アナリストにマスクが適用されるか確認する。
- 伝搬をONにする。
- After：同じ操作を行い、タグが付いて、マスクが適用されるか確認する。
やってみた
Previewsの設定確認
ワークスペース管理者として、画面右上のユーザー名から『Previews』を開きます。
『Tag Propagation』が、ONになっていることを確認します。
※PreviewsでONになっていても、タグごとの伝搬設定は別で必要になります。
グループの作成とユーザーの追加
アカウントコンソールの『User management』から『Groups』を開き、『Add group』でグループを作成します。
今回は、次の2つを作成しました。
tagprop_adminstagprop_analysts
その後、各グループの『Members』タブから、メンバーを追加します。
| グループ | メンバー |
|---|---|
tagprop_admins |
ユーザーA |
tagprop_analysts |
ユーザーB |
対応が完了したら、ワークスペースの『Permissions』で、グループおよびメンバーの追加を行います。
管理タグの作成
ワークスペースの『Catalog』から『Govern』→『Governed Tags』を開きます。
以下の通り、管理タグを作成します。
- タグキー：
pii - 許可値：
ssn、email
作成後、pii の権限で、tagprop_admins に MANAGE と ASSIGN を付与します。
この時点では、伝搬の設定はOFFのままにしておきます。
カタログとテーブルの作成
ここからは、ユーザーAがサーバーレスSQLウェアハウスで実行します。
最初に、検証用のカタログ、スキーマ、テーブルを作成します。
CREATE CATALOG IF NOT EXISTS tagprop_test;
CREATE SCHEMA IF NOT EXISTS tagprop_test.src;
CREATE SCHEMA IF NOT EXISTS tagprop_test.derived;
CREATE SCHEMA IF NOT EXISTS tagprop_test.common;
CREATE OR REPLACE TABLE tagprop_test.src.customers (
customer_id INT, name STRING, email STRING, ssn STRING
);
INSERT INTO tagprop_test.src.customers VALUES
(1, 'Taro Yamada', 'taro@example.com', '123-45-6789'),
(2, 'Hanako Sato', 'hanako@example.com', '987-65-4321');
ここまでの実行で、カタログは以下のようになっているかと思います。
次に、アナリストのグループに、読み取り権限を付与します。
GRANT USE CATALOG ON CATALOG tagprop_test TO tagprop_analysts;
GRANT USE SCHEMA, SELECT ON SCHEMA tagprop_test.src TO tagprop_analysts;
GRANT USE SCHEMA, SELECT ON SCHEMA tagprop_test.derived TO tagprop_analysts;
ソーステーブルの列に、pii タグを付けます。
ALTER TABLE tagprop_test.src.customers ALTER COLUMN ssn SET TAGS ('pii' = 'ssn');
ALTER TABLE tagprop_test.src.customers ALTER COLUMN email SET TAGS ('pii' = 'email');
ABACポリシーの作成
マスク用の関数と、ABACポリシーを作成します。
CREATE OR REPLACE FUNCTION tagprop_test.common.mask_full(v STRING)
RETURNS STRING
RETURN CASE WHEN v IS NULL THEN NULL ELSE '***MASKED***' END;
CREATE OR REPLACE POLICY mask_pii
ON CATALOG tagprop_test
COLUMN MASK tagprop_test.common.mask_full
TO tagprop_analysts
FOR TABLES
MATCH COLUMNS has_tag('pii') AS c
ON COLUMN c;
MATCH COLUMNS has_tag('pii') で、pii タグが付いた列を対象にしています。
カタログに対するポリシーなので、src と derived のどちらにも適用されます。
ソースのマスクを確認
まず、ソーステーブルに対して、マスクが効いていることを確認します。
SELECT * FROM tagprop_test.src.customers;
ユーザーAとユーザーBで、それぞれ実行します。
ユーザーAの実行結果は以下の通りです。
対して、ユーザーBの実行結果は以下の通りです。
ユーザーAには生データが、ユーザーBには ssn と email がマスクされた結果が返ります。
Before：伝搬OFFで派生テーブルを作成
伝搬がOFFの状態で、ユーザーAがCTASで派生テーブルを作成します。
CREATE OR REPLACE TABLE tagprop_test.derived.t_before AS
SELECT * FROM tagprop_test.src.customers;
次に、ユーザーBで派生テーブルを参照します。
SELECT * FROM tagprop_test.derived.t_before;
ソーステーブルではマスクされていた ssn と email が、派生テーブルではマスクされずに見えているのが分かります。
伝搬をON
『Catalog』→『Govern』→『Governed Tags』から pii を開き、Tag propagationの『Enable』を押下します。
『Tag propagation』のトグルをONにして、保存します。
Default propagation valueは、タグの値が衝突したときに使われる値です。今回は、別々の列をコピーするだけで衝突しないため、どちらを選んでも結果は変わりません。今回は ssn にしました。
次のようになっていれば、設定完了です。
After：伝搬ONで同じ操作を実行
伝搬がONの状態で、ユーザーAで次のSQLを実行します。
-- CTAS
CREATE OR REPLACE TABLE tagprop_test.derived.t_after AS
SELECT * FROM tagprop_test.src.customers;
-- CTAS(列名の変更と式)
CREATE OR REPLACE TABLE tagprop_test.derived.t_after_expr AS
SELECT customer_id,
ssn AS national_id,
concat(ssn, '-x') AS ssn_x
FROM tagprop_test.src.customers;
-- ビュー
CREATE OR REPLACE VIEW tagprop_test.derived.v_after AS
SELECT customer_id, ssn, email FROM tagprop_test.src.customers;
-- INSERT INTO ... SELECT
CREATE OR REPLACE TABLE tagprop_test.derived.t_after_insert (
customer_id INT, ssn STRING
);
INSERT INTO tagprop_test.derived.t_after_insert
SELECT customer_id, ssn FROM tagprop_test.src.customers;
伝搬で付いたタグは、Catalog Explorerでも確認できます。
少し待って、ユーザーBで派生テーブルとビューを参照します。
SELECT * FROM tagprop_test.derived.t_after;
SELECT * FROM tagprop_test.derived.v_after;
Beforeでは見えていた ssn と email が、タグの手動付与をしなくとも、マスクされるようになりました。
列名の変更と式を挟んだ t_after_expr の結果は、次の通りでした。
SELECT * FROM tagprop_test.derived.t_after_expr;
こちらも、マスクされていることが確認できました。
データを挿入した t_after_insert も、同様にマスクされていることが確認できます。
SELECT * FROM tagprop_test.derived.t_after_insert;
最後に
今回は、管理タグの伝搬（Tag propagation）をABACと組み合わせて検証しました。
伝搬がないと、ソースにマスクがかかっていても、CTASで作った派生テーブルでは、マスクが外れてしまいます。伝搬をONにすると、派生テーブルにもタグが付き、ABACのポリシーが自動で効くことを確認できました。
タグを1回付ければ、下流にも統制が広がる点は、データの利用者が増えるほど効いてくると感じました。
一方で、サーバーレス限定であることや、反映までの時間差があることなど、前提と制約もあるので導入するときは注意が必要です。
参考になりましたら幸いです。
