Snowflake Tag-based Masking入門：大規模ガバナンスと自動適用の実務

タグベース・マスキングは、列に付与したタグをトリガにしてマスキングポリシーを自動適用できるSnowflakeの機能です。大量のテーブル・列をまたいで一貫した統制を敷き、追加・変更にも追従します。

本稿では、仕組みと前提、最小実装、運用自動化、他方式との比較、試験で狙われやすい要点までを一気通貫で整理します。

タグベース・マスキングが大規模運用で効く理由

タグは「意味情報」を列に与え、タグに結びつけたマスキングポリシーが自動で適用されます。新規列や新規テーブルにタグが付く限り、個別にポリシーを張り替える運用は不要です。

データ分類(例: PII/CONFIDENTIAL)→タグ付け→自動マスキングという流れを作ることで、人手の属人化や適用漏れを抑止し、監査可能性も高められます。

• スケール: 数百〜数千列でもタグ付けだけで統一適用
• 変化耐性: 列追加・スキーマ変更に自動追従
• 監査容易: タグ・ポリシー参照のメタデータが残る

仕組みと前提：タグ、ポリシー、適用順位、権限

タグはスキーマ内で定義するオブジェクトです。列にタグとタグ値を付与し、そのタグ(やタグ値)にマスキングポリシーを関連付けます。クエリ実行時に、該当列へポリシーが自動適用され、ユーザーのロールなどに応じて値がマスクされます。

適用順位は、一般に「列へ直接付与したマスキングポリシー」が最優先で、次に「タグベース・マスキング」が評価されます。競合を設計で避けるのが定石です。

• 前提権限(代表例): CREATE TAG(タグ作成)、タグへのAPPLY相当の権限、対象オブジェクト(テーブル/列)の所有または変更権限、マスキングポリシーの所有/適用権限
• 評価時情報: IS_ROLE_IN_SESSION、CURRENT_ROLEなどの関数でロールに応じた表示/非表示を制御
• データ型: マスキングポリシーは列のデータ型とシグネチャを合わせる。型ごとに別ポリシーを用意するのが安全

最小構成の実装手順（文字列PII例）

ここでは文字列列(例: EMAIL)に対して、PIIタグが付いたら自動的にマスクする最小構成を示します。数値など他の型は、同様に型を合わせた別ポリシーを用意します。

実装は「タグ定義 → ポリシー作成 → タグへ関連付け → 列へタグ付与 → 動作確認」という順序が分かりやすく、監査証跡も追いやすくなります。

• タグは分類語彙に合わせてALLOWED_VALUESを明確化
• ポリシーは誰が見えるかをロールベースで記述
• タグにポリシーを関連付けると以後はタグ付けだけで自動適用

タグ→ポリシー→クエリ時マスキングの流れ

例: タグ定義、ポリシー作成、タグへの関連付け、列への適用

use role SECURITYADMIN;

-- 1) タグ定義
create or replace tag DATA_CLASSIFICATION allowed_values 'PII','CONFIDENTIAL','INTERNAL','PUBLIC';

-- 2) 文字列用マスキングポリシー(例)
create or replace masking policy PII_MASK_STR as (val string) returns string ->
  case
    when is_role_in_session('DATA_STEWARD') then val
    else regexp_replace(val, '(?<=.).', 'X')
  end;

-- 3) タグ値 'PII' にポリシーを関連付け
alter tag DATA_CLASSIFICATION set masking policy PII_MASK_STR using (value => 'PII');

-- 4) 列にタグを設定(以後、自動でマスク適用)
alter table SALES.CUSTOMER modify column EMAIL set tag DATA_CLASSIFICATION = 'PII';

-- 5) 動作確認
use role ANALYST;
select EMAIL from SALES.CUSTOMER limit 5;

自動化と運用：分類→タグ付け→自動適用のパイプライン

Snowflakeのデータ分類機能やETL段階のパターン検出で候補列を抽出し、ワークフロー(Tasks/外部CI/CD)でタグ付けを自動化します。タグさえ付けばマスキングは自動適用されるので、運用の焦点は「正しいタグ付け」と「監査」に集約されます。

監査はACCOUNT_USAGEビュー等でタグ・ポリシー参照状況を定期取得し、逸脱(タグ付きなのに型不一致で未適用等)を検知します。

• 自動タグ付け: 分類結果→タグ付けスクリプト(ALTER TABLE ... SET TAG ...)
• 逸脱検知: タグ付き列に対応ポリシーが無い/型不一致を検出
• 例外処理: 一部列は直接ポリシーを付与し、タグ適用を上書き(優先度に留意)

監査SQL例(タグ/ポリシー参照の可視化)

-- タグ参照(列)を確認
select tag_database, tag_schema, tag_name, object_database, object_schema, object_name, column_name, tag_value
from snowflake.account_usage.tag_references
where tag_name = 'DATA_CLASSIFICATION' and domain = 'COLUMN'
order by object_database, object_schema, object_name, column_name;

-- マスキングポリシーの参照先(タグ/列)を確認
select policy_name, policy_kind, ref_entity_name, ref_column_name, ref_entity_domain
from snowflake.account_usage.policy_references
where policy_kind = 'MASKING_POLICY'
order by policy_name;

他方式との比較と使い分け

タグベース・マスキングは大規模ガバナンスの主役です。一方で、列単位で直接ポリシーを付ける方式や、ビューでの手動マスキングも局所的な要件では有効です。特徴と注意点を整理します。

• 大規模・標準化: タグベースが第一選択
• 個別例外/一時対応: 列へ直接ポリシー付与でピンポイント制御
• 外部公開/サブセット: ビューでの露出制御と併用(ただし直接テーブル参照の抜け道に注意)

テスト、パフォーマンス、エッジケース

マスクはクエリ時に評価され、一般的な分析ワークロードで顕著な性能低下は起きにくい設計です。とはいえ、大量のCASE/正規表現を組み込むとCPU負荷が増すため、ポリシーはシンプルに保つのが無難です。

競合や型不一致はガバナンス上の落とし穴です。直接ポリシー付与が優先される点と、タグベースの複数割当を避ける設計原則を周知し、定期的に参照先を棚卸してください。

• 性能: 役割チェック(IS_ROLE_IN_SESSION)中心の軽量ロジックを心がける
• 型: 列型とポリシーの型シグネチャを一致させる(型変換は避ける)
• 優先度: 直接付与 > タグベース。意図的な例外管理に活用
• バイパス: 監査や運用上の必要があればEXEMPT OTHER POLICIES等の権限設計を検討(最小権限原則を厳守)

簡易テスト(ロールを切り替えて確認)

use role DATA_STEWARD;  -- 見えるロール
select EMAIL from SALES.CUSTOMER limit 3;  -- 平文

use role ANALYST;       -- マスク対象ロール
select EMAIL from SALES.CUSTOMER limit 3;  -- マスク後の値

-- どのロールで評価されたか確認
select current_role();

問題で確認

よくある質問