Dynamic Data Maskingとは？Snowflakeのデータマスキング

Snowflake Dynamic Data Masking（DDM）は、テーブルの元データを変更することなく、クエリ結果のカラム値をユーザーのロールに応じてリアルタイムにマスクする機能です。Masking Policyオブジェクトを作成してカラムに適用するだけで、機密データ（個人情報・クレジットカード番号・メールアドレス等）の保護を実現できます。Enterprise Edition以上が必要です。

Dynamic Data Maskingの仕組み

DDMはSnowflakeのサービスレイヤーでクエリ実行時に評価されます。カラムに設定されたMasking Policyの条件式がクエリの実行ロールに基づいて評価され、条件に一致する場合はマスク済みの値が返却されます。

クエリ実行フロー:

[SELECT email FROM customers]
       │
       ▼
[サービスレイヤー: Masking Policy評価]
       │
       ├─ 実行ロール = DATA_ADMIN → 元データ返却: [email protected]
       │
       └─ 実行ロール = ANALYST   → マスク済み返却: ****@****.com

Masking Policyの作成

Masking PolicyはCREATE MASKING POLICYで作成します。入力データ型と戻り値の型は同じである必要があります。

-- メールアドレスのマスキング
CREATE OR REPLACE MASKING POLICY email_mask AS
  (val STRING) RETURNS STRING ->
    CASE
      WHEN IS_ROLE_IN_SESSION('DATA_ADMIN') THEN val
      WHEN IS_ROLE_IN_SESSION('ANALYST')    THEN REGEXP_REPLACE(val, '.+@', '****@')
      ELSE '********'
    END;

-- 数値（給与）のマスキング
CREATE OR REPLACE MASKING POLICY salary_mask AS
  (val NUMBER) RETURNS NUMBER ->
    CASE
      WHEN IS_ROLE_IN_SESSION('HR_ADMIN') THEN val
      ELSE 0
    END;

-- 日付のマスキング（生年月日を年のみに）
CREATE OR REPLACE MASKING POLICY dob_mask AS
  (val DATE) RETURNS DATE ->
    CASE
      WHEN IS_ROLE_IN_SESSION('DATA_ADMIN') THEN val
      ELSE DATE_FROM_PARTS(YEAR(val), 1, 1)
    END;

ロール判定関数

IS_ROLE_IN_SESSION()はロール階層を考慮するため、子ロールから継承されたロールも正しく判定できます。CURRENT_ROLE()はアクティブロールの名前のみを返すため、ロール階層を無視してしまう問題があります。

Masking Policyの適用

作成したMasking Policyは、ALTER TABLE ... ALTER COLUMN ... SET MASKING POLICYでカラムに適用します。

-- 既存テーブルのカラムにポリシー適用
ALTER TABLE customers
  ALTER COLUMN email SET MASKING POLICY email_mask;

ALTER TABLE employees
  ALTER COLUMN salary SET MASKING POLICY salary_mask;

ALTER TABLE employees
  ALTER COLUMN date_of_birth SET MASKING POLICY dob_mask;

-- ポリシーの解除
ALTER TABLE customers
  ALTER COLUMN email UNSET MASKING POLICY;

-- テーブル作成時にポリシーを適用
CREATE TABLE sensitive_data (
  id NUMBER,
  ssn STRING WITH MASKING POLICY ssn_mask,
  email STRING WITH MASKING POLICY email_mask
);

Tag-based Masking

Tag-based Maskingは、オブジェクトタグとMasking Policyを紐付けることで、タグが付与されたすべてのカラムに自動的にマスキングを適用する仕組みです。カラムが数百〜数千ある大規模環境で、手動でカラムごとにポリシーを設定する手間を削減します。

-- Step 1: タグの作成
CREATE OR REPLACE TAG pii_type
  ALLOWED_VALUES 'email', 'phone', 'ssn', 'name';

-- Step 2: タグにMasking Policyを紐付け
ALTER TAG pii_type SET
  MASKING POLICY email_mask  FOR 'email',
  MASKING POLICY phone_mask  FOR 'phone',
  MASKING POLICY ssn_mask    FOR 'ssn',
  MASKING POLICY name_mask   FOR 'name';

-- Step 3: カラムにタグを適用（ポリシーが自動適用される）
ALTER TABLE customers ALTER COLUMN email
  SET TAG pii_type = 'email';

ALTER TABLE customers ALTER COLUMN phone_number
  SET TAG pii_type = 'phone';

-- タグの値に応じて対応するMasking Policyが自動適用される

直接適用 vs Tag-based Masking

ポリシーの優先順位

1つのカラムに対して直接適用のMasking PolicyとTag-based Masking Policyの両方が設定された場合、直接適用のポリシーが優先されます。

• 直接適用（ALTER COLUMN SET MASKING POLICY）が最優先
• Tag-based Maskingはカラムに直接ポリシーが設定されていない場合のみ有効
• 1つのカラムに複数のMasking Policyを直接適用することはできない

エディション要件

ポリシーの管理と確認

-- アカウント内のMasking Policyの一覧
SELECT * FROM TABLE(INFORMATION_SCHEMA.POLICY_REFERENCES(
  POLICY_NAME => 'email_mask'
));

-- カラムに適用されているポリシーを確認
DESCRIBE TABLE customers;

-- SHOW MASKING POLICIES でスキーマ内のポリシー一覧
SHOW MASKING POLICIES IN SCHEMA my_db.my_schema;

-- ポリシーの定義を確認
DESCRIBE MASKING POLICY email_mask;

試験対策のポイント

• DDMはEnterprise Edition以上が必要
• Masking Policyの入力型と戻り値の型は同一でなければならない
• IS_ROLE_IN_SESSION()はロール階層を考慮し、CURRENT_ROLE()は考慮しない
• 1つのカラムに直接適用できるMasking Policyは1つのみ
• 直接適用ポリシーはTag-based Maskingより優先される
• 元データは変更されず、クエリ結果のみマスクされる（Dynamic）
• Tag-based MaskingはALTER TAG SET MASKING POLICYで紐付ける

サンプル問題

よくある質問