Masking Policy vs Row Access Policyの違いを8項目で比較

Snowflakeのデータ保護機能の中核をなすMasking PolicyとRow Access Policyは、 どちらもEnterprise Edition以上で利用できるポリシーベースのアクセス制御ですが、制御の対象と動作が根本的に異なります。 Masking Policyは列の値を変換して返し、Row Access Policyは行の可視性をフィルタします。 両者を正しく使い分け、必要に応じて同時適用する設計が、SnowPro Advanced: Security Engineer試験でも実務でも求められます。

8項目比較表

Masking Policyの実装例

-- メールアドレスのマスキング
CREATE OR REPLACE MASKING POLICY mask_email
  AS (val VARCHAR) RETURNS VARCHAR ->
  CASE
    WHEN IS_ROLE_IN_SESSION('HR_ADMIN') THEN val
    WHEN IS_ROLE_IN_SESSION('MANAGER') THEN
      CONCAT(LEFT(val, 2), '****@', SPLIT_PART(val, '@', 2))
    ELSE '****@****.***'
  END;

-- 列にアタッチ
ALTER TABLE hr.employees
  ALTER COLUMN email
  SET MASKING POLICY mask_email;

-- 数値型の給与マスキング
CREATE OR REPLACE MASKING POLICY mask_salary
  AS (val NUMBER) RETURNS NUMBER ->
  CASE
    WHEN IS_ROLE_IN_SESSION('HR_ADMIN') THEN val
    WHEN IS_ROLE_IN_SESSION('MANAGER') THEN
      ROUND(val, -4)  -- 万単位に丸め
    ELSE NULL
  END;

ALTER TABLE hr.employees
  ALTER COLUMN salary
  SET MASKING POLICY mask_salary;

Row Access Policyの実装例

-- 部署ベースの行フィルタ
CREATE OR REPLACE ROW ACCESS POLICY rap_department
  AS (dept_val VARCHAR) RETURNS BOOLEAN ->
  IS_ROLE_IN_SESSION('HR_ADMIN')
  OR dept_val = (
    SELECT department FROM hr.user_dept_mapping
    WHERE user_name = CURRENT_USER()
  );

-- テーブルにアタッチ
ALTER TABLE hr.employees
  ADD ROW ACCESS POLICY rap_department ON (department);

同時適用パターン

Masking PolicyとRow Access Policyは同一テーブルに同時に適用可能です。 この場合、Row Access Policy → Masking Policyの順で評価されます。

-- シナリオ: hr.employeesテーブルに両方を適用
-- Row Access Policy: 自部署の社員のみ表示
-- Masking Policy: salary列をロールに応じてマスク

-- Step 1: Row Access Policyをアタッチ
ALTER TABLE hr.employees
  ADD ROW ACCESS POLICY rap_department ON (department);

-- Step 2: Masking Policyをアタッチ
ALTER TABLE hr.employees
  ALTER COLUMN salary
  SET MASKING POLICY mask_salary;

ALTER TABLE hr.employees
  ALTER COLUMN email
  SET MASKING POLICY mask_email;

-- 結果（MANAGERロールの場合）:
-- 1. Row Access Policyで自部署の社員のみに絞られる
-- 2. salary列は万単位に丸められる
-- 3. email列は先頭2文字+マスクされた形で返される

Secure Viewとの使い分け

設計判断ガイド

要件: 特定のユーザー/ロールにデータを制限したい
│
├─ 行単位で制限したい（例: 自部署の社員のみ表示）
│   └─ → Row Access Policy
│
├─ 列の値を変換して返したい（例: SSNの一部をマスク）
│   └─ → Masking Policy
│
├─ 列自体を完全に非表示にしたい
│   ├─ クエリ結果から列を除外 → Projection Policy
│   └─ View定義で列を除外   → Secure View
│
└─ 行制限 + 列マスクの両方
    └─ → Row Access Policy + Masking Policy を併用

落とし穴と注意点

• Masking PolicyとWHERE句：Masking Policyはクエリ結果の表示時に適用されますが、WHERE句のフィルタはマスク前の値で実行されます。つまりSELECT email WHERE email = '[email protected]' は、emailがマスクされて返されてもWHEREの条件は元の値で評価されます
• Row Access PolicyとCOUNT：Row Access Policyが適用されたテーブルでCOUNT(*)を実行すると、フィルタ後の行数が返されます。テーブル全体の行数を別チャネルで知っているユーザーは、自分に見えない行数を推測できるリスクがあります
• ポリシーのデバッグ：ポリシーのロジックはOWNERロールでDESCRIBE MASKING POLICY / DESCRIBE ROW ACCESS POLICYで確認できます。意図した動作をテスト用ロールで検証してからプロダクション適用することが重要です
• Conditional Masking：Masking Policyの引数に複数列を渡すことで、他の列の値に基づいたマスキングが可能です（例：regionがAPACの場合のみマスク解除）

Conditional Masking（条件付きマスキング）

-- 他の列の値に基づいてマスクを切り替え
CREATE OR REPLACE MASKING POLICY mask_salary_by_region
  AS (salary_val NUMBER, region_val VARCHAR) RETURNS NUMBER ->
  CASE
    WHEN IS_ROLE_IN_SESSION('HR_ADMIN') THEN salary_val
    WHEN IS_ROLE_IN_SESSION('APAC_MANAGER')
      AND region_val = 'APAC' THEN salary_val
    ELSE NULL
  END;

-- 2つの列をマッピングしてアタッチ
ALTER TABLE hr.employees
  ALTER COLUMN salary
  SET MASKING POLICY mask_salary_by_region
  USING (salary, region);

問題で確認

よくある質問