Snowflake のタグベースポリシーが集計・行アクセス・プロジェクション・結合ポリシーに対応(Public Preview)したので4種類まとめて試してみた
かわばたです。
データガバナンスの運用では、保護対象のテーブルが増えるたびに、テーブルごとにポリシーを割り当てる作業が負担になるケースは少なくありません。マスキングポリシーについては以前からタグベースの適用が可能でしたが、行アクセスポリシーや集計ポリシーなどは対象オブジェクトへの直接割り当てが必要でした。
2026年7月21日に、集計ポリシー (Aggregation Policy)・行アクセスポリシー (Row Access Policy)・プロジェクションポリシー (Projection Policy)・結合ポリシー (Join Policy) のタグベース適用がパブリックプレビューになりました。タグにポリシーを設定しておけば、タグを付与したオブジェクトが自動的に保護されるようになります。
本記事では、この4種類のタグベースポリシーをトライアルアカウント (Enterprise Edition) で検証します。タグへのポリシー設定からオブジェクトへのタグ付与、制限対象ロールでの適用確認まで、4タイプすべての動きと、検証で確認した細かい仕様 (FORCE オプションによるポリシー置き換え、1タグ1ポリシーの制約など) を紹介します。
注意: 本記事は2026年8月4日時点のパブリックプレビュー段階の検証結果です。プレビュー段階のため、挙動は今後変わる可能性があります。
なお、プレビュー公開直後の2026年7月24日に検証した際は、テーブル/ビューに適用されるタイプ (集計・行アクセス・結合) のタグ経由の制御を本検証環境で確認できない事象がありました。2026年8月4日の再検証では、同じ環境で再現しなくなっています。原因は特定できていませんが、公開直後であったため、環境への機能展開のタイミングが影響した可能性があります。
タグベースポリシーの概要
タグベースポリシーは、オブジェクトタグ機能とデータ保護ポリシーを組み合わせた仕組みです。ALTER TAG ... SET <POLICY_TYPE> POLICY でタグにポリシーを設定すると、そのタグが付与されたオブジェクトすべてにポリシーが自動適用されます。
今回のリリースで、タグに設定できるポリシータイプは以下の5種類になりました。
| ポリシータイプ | 制御対象 | タグベース適用の提供状況 |
|---|---|---|
| マスキングポリシー | 列の値の秘匿 | GA (従来から利用可能) |
| 集計ポリシー | 最小グループサイズ以上への集約の強制 | パブリックプレビュー (今回追加) |
| 行アクセスポリシー | 条件に合致しない行の除外 | パブリックプレビュー (今回追加) |
| プロジェクションポリシー | 列をクエリ結果に含められるかの制御 | パブリックプレビュー (今回追加) |
| 結合ポリシー | テーブルのクエリに結合を必須化し、必要に応じて許可する結合キーを制限 | パブリックプレビュー (今回追加) |
タグを付与できるレベルはポリシータイプによって異なります。
| ポリシータイプ | データベース | スキーマ | テーブル/ビュー | 列 |
|---|---|---|---|---|
| 集計ポリシー | ○ | ○ | ○ | - |
| 行アクセスポリシー | ○ | ○ | ○ | - |
| プロジェクションポリシー | ○ | ○ | ○ | ○ |
| 結合ポリシー | ○ | ○ | ○ | - |
データベースやスキーマにタグを付与した場合、配下のテーブル・ビューがタグを継承し、まとめて保護されます。
前提条件
- タグベースの集計・行アクセス・プロジェクション・結合ポリシーは Enterprise Edition 以上で利用できます
- タグの作成にはスキーマレベルの
CREATE TAG権限が必要です - ポリシーの作成にはスキーマレベルの
CREATE <POLICY_TYPE>権限が必要です - タグへのポリシー設定にはアカウントレベルの
APPLY <POLICY_TYPE>権限が必要です - オブジェクトへのタグ付与には
APPLY TAG権限 (またはタグ固有の APPLY 権限) が必要です
検証はトライアルアカウント (Enterprise Edition) に対して Snowflake CLI 3.23.0 経由で実施しました。
事前準備
データ用の SALES スキーマと、タグ・ポリシー管理用の GOVERNANCE スキーマを分けて作成します。
事前準備
USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS TAG_POLICY_DEMO;
CREATE SCHEMA IF NOT EXISTS TAG_POLICY_DEMO.SALES;
CREATE SCHEMA IF NOT EXISTS TAG_POLICY_DEMO.GOVERNANCE;
USE SCHEMA TAG_POLICY_DEMO.SALES;
CREATE OR REPLACE TABLE customers (
customer_id INT,
customer_name VARCHAR,
email VARCHAR,
region VARCHAR
);
INSERT INTO customers VALUES
(1, 'Sato', 'sato@example.com', 'EAST'),
(2, 'Suzuki', 'suzuki@example.com', 'EAST'),
(3, 'Takahashi', 'takahashi@example.com', 'WEST'),
(4, 'Tanaka', 'tanaka@example.com', 'WEST'),
(5, 'Ito', 'ito@example.com', 'NORTH'),
(6, 'Watanabe', 'watanabe@example.com', 'EAST');
CREATE OR REPLACE TABLE orders (
order_id INT,
customer_id INT,
order_date DATE,
amount INT,
region VARCHAR
);
INSERT INTO orders VALUES
(101, 1, '2026-07-01', 1000, 'EAST'),
(102, 2, '2026-07-02', 1500, 'EAST'),
(103, 6, '2026-07-03', 2000, 'EAST'),
(104, 1, '2026-07-04', 1200, 'EAST'),
(105, 2, '2026-07-05', 1800, 'EAST'),
(106, 3, '2026-07-06', 3000, 'WEST'),
(107, 4, '2026-07-07', 2500, 'WEST'),
(108, 3, '2026-07-08', 1100, 'WEST'),
(109, 4, '2026-07-09', 900, 'WEST'),
(110, 5, '2026-07-10', 4000, 'NORTH'),
(111, 5, '2026-07-11', 600, 'NORTH');
orders の region 別の件数は EAST 5件・WEST 4件・NORTH 2件です。集計ポリシーの最小グループサイズを 3 に設定するので、NORTH が残余グループ (remainder group) に統合されるケースを確認できる設計です。
ポリシーの制限を受ける側のロールとして TAG_POLICY_ANALYST を作成します。ポリシー定義内では SYSADMIN を制限対象外とします。
ロール
USE ROLE SECURITYADMIN;
CREATE ROLE IF NOT EXISTS TAG_POLICY_ANALYST;
GRANT USAGE ON DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT USAGE ON ALL SCHEMAS IN DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT SELECT ON ALL TABLES IN DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT SELECT ON FUTURE TABLES IN DATABASE TAG_POLICY_DEMO TO ROLE TAG_POLICY_ANALYST;
GRANT USAGE ON WAREHOUSE compute_wh TO ROLE TAG_POLICY_ANALYST;
GRANT ROLE TAG_POLICY_ANALYST TO USER <検証ユーザー名>;
タグへのポリシー設定にはアカウントレベルの APPLY <POLICY_TYPE> 権限、オブジェクトへのタグ付与には APPLY TAG 権限が必要です。本記事では検証を簡略化するため、これらを SYSADMIN に付与して進めます。
USE ROLE SECURITYADMIN;
GRANT APPLY TAG ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY AGGREGATION POLICY ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY ROW ACCESS POLICY ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY PROJECTION POLICY ON ACCOUNT TO ROLE SYSADMIN;
GRANT APPLY JOIN POLICY ON ACCOUNT TO ROLE SYSADMIN;
注意: 上記は検証を簡略化するための付与です。実運用では、タグ管理者ロールとポリシー管理者ロールを分けるなど、職務分離した専用ロールでの管理を推奨します。
試してみた
タグベース集計ポリシー
まずタグと集計ポリシーを作成し、ALTER TAG ... SET AGGREGATION POLICY でタグにポリシーを設定します。SYSADMIN は制限なし、それ以外のロールには最小グループサイズ 3 を要求するポリシーです。
USE ROLE SYSADMIN;
USE SCHEMA TAG_POLICY_DEMO.GOVERNANCE;
CREATE OR REPLACE TAG agg_protection;
CREATE OR REPLACE AGGREGATION POLICY min3_agg_policy
AS () RETURNS AGGREGATION_CONSTRAINT ->
CASE
WHEN CURRENT_ROLE() = 'SYSADMIN' THEN NO_AGGREGATION_CONSTRAINT()
ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 3)
END;
ALTER TAG agg_protection SET AGGREGATION POLICY min3_agg_policy;
ALTER TABLE TAG_POLICY_DEMO.SALES.orders SET TAG agg_protection = 'protected';
TAG_POLICY_ANALYST ロールで集計を伴わないクエリを実行すると、タグ経由で集計ポリシーが適用され、エラーになります。
USE ROLE TAG_POLICY_ANALYST;
SELECT * FROM TAG_POLICY_DEMO.SALES.orders;
最小グループサイズ 3 の制約を満たす集計クエリは成功します。region 別の件数は EAST 5件・WEST 4件・NORTH 2件のため、グループサイズ 3 未満の NORTH は残余グループ (remainder group) に統合されて返るはずです。
SELECT region, COUNT(*) AS cnt
FROM TAG_POLICY_DEMO.SALES.orders
GROUP BY region;
タグ経由の関連付けを確認する
タグ経由のポリシー関連付けは POLICY_REFERENCES テーブル関数で確認できます。TAG_NAME 列に、どのタグを経由して適用されているかが表示されます。
SELECT policy_name, policy_kind, ref_entity_name, tag_name, policy_status
FROM TABLE(TAG_POLICY_DEMO.INFORMATION_SCHEMA.POLICY_REFERENCES(
REF_ENTITY_DOMAIN => 'TABLE',
REF_ENTITY_NAME => 'TAG_POLICY_DEMO.SALES.ORDERS'
));
なお、POLICY_REFERENCES の TAG_NAME と POLICY_STATUS は、タグ経由のポリシーの関連付けを確認するために利用できます。ただし POLICY_STATUS = 'ACTIVE' の公式定義は列レベルの関連付けを前提とした記述です。特にプレビュー機能の導入時は、メタデータの確認に加えて、制限を受けるロールで実クエリを実行し、期待どおりに制御されることを確認するのがおすすめです。
タグベース行アクセスポリシー
行アクセスポリシーも同じ流れです。ポリシー引数と同名・同型の列 (region) を持つ orders にタグベースで適用します。
CREATE OR REPLACE TAG row_protection;
CREATE OR REPLACE ROW ACCESS POLICY region_rap
AS (region VARCHAR) RETURNS BOOLEAN ->
CURRENT_ROLE() = 'SYSADMIN'
OR region = 'EAST';
ALTER TAG row_protection SET ROW ACCESS POLICY region_rap;
ALTER TABLE TAG_POLICY_DEMO.SALES.orders SET TAG row_protection = 'protected';
TAG_POLICY_ANALYST ロールでクエリすると、EAST の行だけに絞られます。
USE ROLE TAG_POLICY_ANALYST;
SELECT region, COUNT(*) AS cnt
FROM TAG_POLICY_DEMO.SALES.orders
GROUP BY region;
列名が異なるテーブル向けには、タグへのポリシー設定時に ON 句でシグネチャエイリアスを指定できます。エイリアスタプルは指定順に照合され、テーブルの列名・データ型に解決できた最初のタプルが使用されます。複数のタプルが同一テーブルに解決できる場合はエラーになり、どのタプルも解決できない場合はそのテーブルにポリシーが適用されない、と公式ドキュメントに記載されています。列名が sales_area のテーブルを用意して試します。
CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES.orders_by_area (
order_id INT,
sales_area VARCHAR,
amount INT
);
INSERT INTO TAG_POLICY_DEMO.SALES.orders_by_area VALUES
(201, 'EAST', 1000),
(202, 'WEST', 2000),
(203, 'EAST', 1500),
(204, 'NORTH', 3000);
CREATE OR REPLACE TAG row_protection_alias;
ALTER TAG row_protection_alias SET ROW ACCESS POLICY region_rap
ON (region VARCHAR), (sales_area VARCHAR);
ALTER TABLE TAG_POLICY_DEMO.SALES.orders_by_area
SET TAG row_protection_alias = 'protected';
sales_area 列が2番目のタプルに解決されるため、orders_by_area でも EAST の 2 行だけが返ります。
タグベース結合ポリシー
結合ポリシーは、テーブルの単独クエリを禁止して結合を必須化するポリシーです。タグへの設定時に ALLOWED JOIN KEYS で許可する結合キーも制限できます。
CREATE OR REPLACE TAG join_protection;
CREATE OR REPLACE JOIN POLICY customer_join_policy
AS () RETURNS JOIN_CONSTRAINT ->
CASE
WHEN CURRENT_ROLE() = 'SYSADMIN' THEN JOIN_CONSTRAINT(JOIN_REQUIRED => FALSE)
ELSE JOIN_CONSTRAINT(JOIN_REQUIRED => TRUE)
END;
ALTER TAG join_protection SET JOIN POLICY customer_join_policy
ALLOWED JOIN KEYS (customer_id);
ALTER TABLE TAG_POLICY_DEMO.SALES.customers SET TAG join_protection = 'protected';
TAG_POLICY_ANALYST ロールで単独 SELECT を実行すると、タグ経由で結合ポリシーが適用され、エラーになります。
USE ROLE TAG_POLICY_ANALYST;
SELECT customer_id, region FROM TAG_POLICY_DEMO.SALES.customers;
許可された結合キー (customer_id) で orders と結合するクエリは成功します。
SELECT c.region, COUNT(*) AS cnt
FROM TAG_POLICY_DEMO.SALES.customers c
JOIN TAG_POLICY_DEMO.SALES.orders o
ON c.customer_id = o.customer_id
GROUP BY c.region;
確認できたら、以降の検証 (プロジェクション・マスキング) では customers への単独クエリを使うため、結合ポリシーのタグを外しておきます。外さないままだと、後続の単独 SELECT が結合必須のエラーになります。
USE ROLE SYSADMIN;
ALTER TABLE TAG_POLICY_DEMO.SALES.customers
UNSET TAG TAG_POLICY_DEMO.GOVERNANCE.join_protection;
タグベースプロジェクションポリシー
プロジェクションポリシーは4種類の中で唯一、列レベルにもタグを付与できます。「値そのものは見せないが、絞り込みには使わせる」という制御を列単位で展開できます。
USE ROLE SYSADMIN;
USE SCHEMA TAG_POLICY_DEMO.GOVERNANCE;
CREATE OR REPLACE TAG pii_column;
CREATE OR REPLACE PROJECTION POLICY pii_proj_policy
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
WHEN CURRENT_ROLE() = 'SYSADMIN' THEN PROJECTION_CONSTRAINT(ALLOW => TRUE)
ELSE PROJECTION_CONSTRAINT(ALLOW => FALSE)
END;
ALTER TAG pii_column SET PROJECTION POLICY pii_proj_policy;
ALTER TABLE TAG_POLICY_DEMO.SALES.customers
ALTER COLUMN email SET TAG pii_column = 'email';
TAG_POLICY_ANALYST ロールで email 列を射影しようとすると、タグ付与直後からエラーになります。
USE ROLE TAG_POLICY_ANALYST;
SELECT customer_name, email FROM TAG_POLICY_DEMO.SALES.customers;
email 列を含めないクエリと、射影せず WHERE 句の条件としてだけ使うクエリはどちらも成功します。「値そのものは見せないが、絞り込みには使わせる」というプロジェクションポリシー本来の動きが、タグ経由でも機能しています。
-- 成功する
SELECT customer_name, region FROM TAG_POLICY_DEMO.SALES.customers;
-- 射影しなければWHERE句での利用は可能
SELECT customer_name FROM TAG_POLICY_DEMO.SALES.customers
WHERE email LIKE '%example.com';
テーブルレベルのタグでも試したところ、同様に適用され、テーブルの全列が射影不可になりました。
参考: タグベースマスキングポリシー (GA)
参考として、以前からGAで提供されているタグベースマスキングポリシーも同じ環境で確認しました。
USE ROLE SYSADMIN;
USE SCHEMA TAG_POLICY_DEMO.GOVERNANCE;
CREATE OR REPLACE TAG mask_test;
CREATE OR REPLACE MASKING POLICY mask_string AS (val STRING) RETURNS STRING ->
CASE WHEN CURRENT_ROLE() = 'SYSADMIN' THEN val ELSE '***MASKED***' END;
ALTER TAG mask_test SET MASKING POLICY mask_string;
ALTER TABLE TAG_POLICY_DEMO.SALES.customers
MODIFY COLUMN customer_name SET TAG mask_test = 'on';
こちらはタグ付与直後から customer_name が ***MASKED*** になりました。
スキーマレベルのタグ継承と直接割り当ての優先順位
スキーマにタグを付与すると、配下のテーブル・ビューがタグを継承してまとめて保護されます。タグ付与後に新規作成したテーブルにも自動で適用されるはずです。検証用の専用スキーマ SALES_PROTECTED を用意して確認します (SALES スキーマに直接付与すると customers などにも集計ポリシーが掛かり、他の検証と干渉するためです)。
USE ROLE SYSADMIN;
CREATE SCHEMA IF NOT EXISTS TAG_POLICY_DEMO.SALES_PROTECTED;
CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES_PROTECTED.orders_copy AS
SELECT * FROM TAG_POLICY_DEMO.SALES.orders;
-- スキーマにタグを付与 → 配下のテーブルが継承して保護される
ALTER SCHEMA TAG_POLICY_DEMO.SALES_PROTECTED
SET TAG TAG_POLICY_DEMO.GOVERNANCE.agg_protection = 'protected';
-- タグ付与後に新規作成したテーブル
CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES_PROTECTED.new_table AS
SELECT 1 AS id UNION ALL SELECT 2;
新規テーブル
このスキーマ継承は、dbt との組み合わせで特に重要です。dbt-snowflake の一般的な table materialization では、モデルが dbt run のたびに CREATE OR REPLACE 相当で再作成されるため、テーブルに直接付与したタグやポリシーは再作成後に維持されません (実際に発行される DDL は dbt のバージョン・materialization・プロジェクトのカスタマイズに依存します)。一方、スキーマ継承であれば再作成後のモデルにも自動で保護が適用されるはずです。dbt の再作成を CREATE OR REPLACE でシミュレートして確認します。
-- dbt run によるモデル再作成をシミュレート
CREATE OR REPLACE TABLE TAG_POLICY_DEMO.SALES_PROTECTED.orders_copy AS
SELECT * FROM TAG_POLICY_DEMO.SALES.orders;
また、直接割り当てポリシーとタグベースポリシーが競合する場合は直接割り当てが優先されます (集計ポリシーはエンティティキーが一致する場合のみで、一致しない場合は両方が適用され得ます)。タグベース (min3) が適用された orders に、最小グループサイズ 5 の別ポリシーを直接割り当てて確認します。
USE ROLE SYSADMIN;
-- 行アクセスポリシーのタグが付いたままだと EAST のみになり差が見えにくいため、一旦外す
ALTER TABLE TAG_POLICY_DEMO.SALES.orders UNSET TAG TAG_POLICY_DEMO.GOVERNANCE.row_protection;
CREATE OR REPLACE AGGREGATION POLICY TAG_POLICY_DEMO.GOVERNANCE.min5_agg_policy
AS () RETURNS AGGREGATION_CONSTRAINT ->
CASE
WHEN CURRENT_ROLE() = 'SYSADMIN' THEN NO_AGGREGATION_CONSTRAINT()
ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5)
END;
ALTER TABLE TAG_POLICY_DEMO.SALES.orders
SET AGGREGATION POLICY TAG_POLICY_DEMO.GOVERNANCE.min5_agg_policy;
タグベースの min3 のままなら EAST (5件) と WEST (4件) が表示されますが、直接割り当ての min5 が優先されることが下記より確認できました。
制限事項の実機確認
公式ドキュメント記載の制限事項がどのようなエラーになるかを確認しました。
ポリシーが設定されたタグは削除できません。
DROP TAG TAG_POLICY_DEMO.GOVERNANCE.agg_protection;
タグに設定されているポリシーも削除できません。
DROP AGGREGATION POLICY TAG_POLICY_DEMO.GOVERNANCE.min3_agg_policy;
1つのタグに同じタイプのポリシーを複数設定することはできません。エラーメッセージには FORCE オプションによる置き換えが案内されます。
ALTER TAG agg_protection SET AGGREGATION POLICY min5_agg_policy;
実際に FORCE を付けて実行すると成功し、POLICY_REFERENCES で確認するとタグに関連付くポリシーが MIN5_AGG_POLICY に置き換わっていました。公式ドキュメントにも、UNSET→SET を2文に分けるとその間は当該タグベースポリシーによる保護がない時間帯が発生し得るため、単一ステートメントで置き換えたい場合は FORCE を使う手順が記載されています。ポリシーの入れ替えでは積極的に使いたいオプションです。
ALTER TAG agg_protection SET AGGREGATION POLICY min5_agg_policy FORCE;
また、異なるタイプのポリシーを同一タグに共存させることもできません。集計ポリシーが設定されたタグに行アクセスポリシーを設定しようとすると、以下のエラーになります。複数タイプを併用したい場合はタイプごとにタグを分ける設計が必要です。なお、マスキングポリシーは例外で、公式ドキュメントに「A tag can have only one masking policy per data type」とあるとおり、1つのタグにデータ型ごとに1つ設定できます。
ALTER TAG agg_protection SET ROW ACCESS POLICY region_rap;
ポリシー付きタグを含むスキーマも削除できません。エラーメッセージからは、タグが他のスキーマのオブジェクトに付与されている (使用中である) ことが削除ブロックの理由になっていることがわかります。
DROP SCHEMA TAG_POLICY_DEMO.GOVERNANCE;
削除するには、先に ALTER TAG ... UNSET <POLICY_TYPE> POLICY でタグとポリシーの関連付けを解除する必要があります。
制限事項・注意点
検証および公式ドキュメントから、主なポイントを整理します。
制限事項・注意点
- Enterprise Edition 以上が必要です (パブリックプレビュー段階)
- プレビュー公開直後 (2026年7月24日) の検証では、テーブル/ビューに適用されるタイプ (集計・行アクセス・結合) のタグ経由の制御を確認できない事象がありました (2026年8月4日の再検証では再現せず。原因は特定できていませんが、環境への機能展開のタイミングが影響した可能性があります)。プレビュー機能の導入時は、メタデータの確認だけでなく、制限を受けるロールでの実クエリで適用を確認することをおすすめします
- 今回追加された4タイプは、1つのタグにつき各タイプ1つまでで、異なるタイプのポリシーの共存も不可です (実測で確認)。マスキングポリシーのみ例外で、データ型ごとに1つ設定できます
- 同種のタグベースポリシーを同じオブジェクトに複数関連付けることはできません (1つのテーブル/ビューに複数のタグベース行アクセスポリシー・結合ポリシー、1つの列に複数のタグベースプロジェクションポリシーは不可)。複数のタグベース集計ポリシーが同じテーブルに及ぶ構成では、適用挙動を事前に確認してください
- ポリシー付きタグの値を変更する際、タグの所有者とポリシー管理者が異なる構成では、スキーマ所有者などがタグ値を変更できないケースがあります。その場合は、タグからポリシーをいったん解除し、値を変更してから再設定する手順が必要になることがあります
- ポリシーの置き換えは
FORCEオプションでUNSETなしに実行できます (実測で確認。公式ドキュメントにも記載あり) - 直接割り当てポリシーとタグベースポリシーが競合する場合、直接割り当てポリシーが優先されます (集計ポリシーはエンティティキーが一致する場合のみで、一致しない場合は両方が適用され得ます)
- ポリシーが設定されたタグ、タグに設定されたポリシー、それらを含むデータベース・スキーマは削除できません (先に関連付けの解除が必要)
- システムタグにはポリシーを設定できません
最後に
タグベースポリシーの4タイプ対応により、データ保護ポリシーの管理を「オブジェクト単位」から「タグ単位」に集約できるようになります。検証では、集計・行アクセス・プロジェクション・結合の4タイプすべてについて、タグへのポリシー設定とオブジェクトへのタグ付与だけで保護が適用されることを確認できました。スキーマレベルのタグ継承と組み合わせれば、「スキーマにタグを付けておけば、後から作られるテーブルも自動で保護される」というガバナンス運用が実現できます。
今までマスキングポリシーしかできなかったことが、4つのポリシーでも可能になったことでより活用の幅が広がったなという印象です。
GAが待ち遠しいですね。
この記事が何かの参考になれば幸いです！
