目次 › 第2章 › 2-4

第2章 アカウント管理とデータガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

2-4. データガバナンス(マスキング・行アクセス・タグ・リネージ)

1. 動的データマスキング(列レベルセキュリティ)

動的データマスキング(Dynamic Data Masking)は、列(カラム)単位で、クエリを実行するロールに応じて値の見え方を変える機能です。Enterpriseエディション以上で利用できます。ポイントは次の3つです。

• マスキングポリシーはスキーマレベルのオブジェクトとして作成します。テーブル定義の中に書くのではなく、独立したポリシーを作って列に適用(SET)します
• 元データは変更されず、クエリの実行時にポリシーが評価されて結果が書き換わります(「動的」の意味)
• ポリシー本体は、CURRENT_ROLE() や IS_ROLE_IN_SESSION() などのコンテキスト関数で実行ロールを判定する条件式で書きます

-- マスキングポリシーを独立したオブジェクトとして作成する
CREATE MASKING POLICY email_mask AS (val STRING) RETURNS STRING ->
  CASE
    WHEN IS_ROLE_IN_SESSION('PII_READER') THEN val
    ELSE '*** MASKED ***'
  END;

-- 列に適用する
ALTER TABLE customers MODIFY COLUMN email
  SET MASKING POLICY email_mask;

-- 解除する場合
ALTER TABLE customers MODIFY COLUMN email
  UNSET MASKING POLICY;

関連機能としてExternal Tokenization(外部トークン化)があります。これはデータのロード前に外部のトークン化プロバイダーで値をトークンに置き換えておき、クエリ時にマスキングポリシー内から外部関数でデトークン化する方式です。「保存時点で生データを持たない」点が動的マスキングとの違いです。

2. 行アクセスポリシー(行レベルセキュリティ)

行アクセスポリシー(Row Access Policy)は、クエリ実行ロールなどの条件に応じてどの行を返すかを制御します。こちらもEnterpriseエディション以上の機能で、ポリシーをスキーマオブジェクトとして作成しテーブルに適用する構造はマスキングと同様です。

-- 営業担当は自分の地域の行だけ見えるようにするポリシー
CREATE ROW ACCESS POLICY region_policy AS (region STRING) RETURNS BOOLEAN ->
  CURRENT_ROLE() = 'SALES_MANAGER'
  OR region = (SELECT r.region FROM region_map r
               WHERE r.role_name = CURRENT_ROLE());

-- テーブルに適用する(対象列を指定)
ALTER TABLE orders ADD ROW ACCESS POLICY region_policy ON (region);

ポリシーがBOOLEANを返し、TRUEになった行だけが結果に含まれます。条件に合わない行は、そのロールにとって「存在しない」ように見えます。

3. オブジェクトタグとタグベースマスキング

オブジェクトタグ(tag)は、オブジェクトに付けられるキー/値ペアのラベルです。タグ自体もスキーマオブジェクトとして作成し、テーブル・列・ウェアハウスなど幅広いオブジェクトに付与できます。

-- タグを作成し、許可する値を制限することもできる
CREATE TAG confidentiality ALLOWED_VALUES 'public', 'internal', 'restricted';

-- テーブルや列に付与する
ALTER TABLE customers SET TAG confidentiality = 'restricted';
ALTER TABLE customers MODIFY COLUMN email
  SET TAG confidentiality = 'restricted';

-- ウェアハウスに付けてコスト配賦にも使える
ALTER WAREHOUSE analysis_wh SET TAG cost_center = 'analytics';

タグの代表的な使い道は次の3つです。

• 機密分類:個人情報や機密データの所在をタグで追跡できるようにする
• コスト管理:ウェアハウスに部門タグを付け、クレジット消費を部門別に集計する
• タグベースマスキング:マスキングポリシーをタグに関連付けることで、そのタグが付いた列すべてに自動的にポリシーが適用される。「PIIタグを付けたら自動でマスクされる」という統制を実現できる

また、Snowflakeには自動データ分類(Classification)機能があり、テーブルをスキャンして個人情報らしい列(氏名・メールアドレスなど)を検出し、システム定義タグで分類できます。「どこに機密データがあるか分からない」状態の解消に役立ち、タグベースマスキングと組み合わせることで検出から保護までを体系化できます。

マスキング・行アクセスに加えて、Snowflakeにはプライバシーポリシー(Privacy Policies)と呼ばれる機能群もあります。代表例が、集計結果しか返さないことを強制する集計ポリシー(aggregation policy)(最低限の行数を集計しないと結果を返さないため、個人単位の行の特定を防げます)と、特定の列をSELECTの出力に含めることを禁止するプロジェクションポリシー(projection policy)(結合キーとしては使えるが値そのものは見せない、といった制御ができます)です。いずれもポリシーをオブジェクトとして作成して適用するという枠組みはマスキングポリシーと共通で、データクリーンルームのようなプライバシー重視の共有シナリオで活用されます。

4. ACCESS_HISTORYによる監査とリネージ

「誰が・いつ・どのデータにアクセスしたか」を追跡するには、SNOWFLAKEデータベースの ACCOUNT_USAGE.ACCESS_HISTORY ビューを使います(ACCOUNT_USAGEスキーマの詳細は2-7で扱います)。

• クエリごとに、直接アクセスしたオブジェクト(base_objects_accessed)、参照したオブジェクト(direct_objects_accessed)、書き込んだオブジェクト(objects_modified)が列レベルまで記録されます
• ビュー経由のアクセスでも基になったテーブル・列まで遡って記録されるため、「この機密列は実際に誰に読まれているか」という監査に使えます
• 読み取り元と書き込み先の対応から、データリネージ(データの流れの系譜)を構成できます。SnowsightのUIでもリネージを可視化できます

5. ガバナンス機能の評価の流れ

1つのクエリに対して各ガバナンス機能がどの順で働くかを図で整理します。

練習問題