Snowflake Row Access Policiesで行レベルセキュリティを実装する

Row Access Policy（行アクセスポリシー）は、テーブルやビューの行に対して、 クエリ実行者のロールやセッション属性に基づいてフィルタを自動適用するSnowflakeのセキュリティ機能です。 ポリシーはテーブルにアタッチされ、そのテーブルを参照するすべてのクエリに対して透過的に行フィルタが適用されます。Enterprise Edition以上で利用可能です。

CREATE ROW ACCESS POLICYの基本構文

-- 基本的なRow Access Policy（ロールベース）
CREATE OR REPLACE ROW ACCESS POLICY rap_region_filter
  AS (region_val VARCHAR) RETURNS BOOLEAN ->
  CASE
    WHEN IS_ROLE_IN_SESSION('ADMIN') THEN TRUE
    WHEN IS_ROLE_IN_SESSION('APAC_ANALYST')
      AND region_val = 'APAC' THEN TRUE
    WHEN IS_ROLE_IN_SESSION('EMEA_ANALYST')
      AND region_val = 'EMEA' THEN TRUE
    ELSE FALSE
  END;

-- テーブルにポリシーをアタッチ
ALTER TABLE sales.transactions
  ADD ROW ACCESS POLICY rap_region_filter ON (region);

-- ポリシーの解除
ALTER TABLE sales.transactions
  DROP ROW ACCESS POLICY rap_region_filter;

ポリシーの引数はテーブルの列にマッピングされます。RETURNS BOOLEANで、TRUEを返した行のみがクエリ結果に含まれます。 FALSEまたはNULLを返した行は結果から除外されます。

CURRENT_ROLE()による判定パターン

-- CURRENT_ROLE()ベースの判定（Primary Roleのみ評価）
CREATE OR REPLACE ROW ACCESS POLICY rap_dept_filter
  AS (dept_val VARCHAR) RETURNS BOOLEAN ->
  CURRENT_ROLE() IN ('SYSADMIN', 'HR_ADMIN')
  OR dept_val = (
    SELECT department
    FROM hr.user_department_mapping
    WHERE user_name = CURRENT_USER()
  );

-- IS_ROLE_IN_SESSION()ベース（Secondary Roles対応）
CREATE OR REPLACE ROW ACCESS POLICY rap_dept_filter_v2
  AS (dept_val VARCHAR) RETURNS BOOLEAN ->
  IS_ROLE_IN_SESSION('SYSADMIN')
  OR IS_ROLE_IN_SESSION('HR_ADMIN')
  OR dept_val = (
    SELECT department
    FROM hr.user_department_mapping
    WHERE user_name = CURRENT_USER()
  );

Mapping Table方式

大規模な組織でロール数が多い場合、ポリシー内にロール名をハードコードするのは管理が困難です。 Mapping Table（マッピングテーブル）を使うと、アクセス制御の条件をテーブルデータとして管理でき、ポリシーの変更なしにアクセス制御を更新できます。

-- マッピングテーブルの作成
CREATE TABLE security.region_access_mapping (
  role_name    VARCHAR,
  region       VARCHAR,
  access_level VARCHAR  -- 'FULL' or 'RESTRICTED'
);

-- マッピングデータの投入
INSERT INTO security.region_access_mapping VALUES
  ('APAC_ANALYST', 'APAC', 'FULL'),
  ('EMEA_ANALYST', 'EMEA', 'FULL'),
  ('GLOBAL_ANALYST', 'APAC', 'FULL'),
  ('GLOBAL_ANALYST', 'EMEA', 'FULL'),
  ('GLOBAL_ANALYST', 'AMER', 'FULL');

-- Mapping Tableを参照するRow Access Policy
CREATE OR REPLACE ROW ACCESS POLICY rap_region_mapping
  AS (region_val VARCHAR) RETURNS BOOLEAN ->
  IS_ROLE_IN_SESSION('ADMIN')
  OR EXISTS (
    SELECT 1
    FROM security.region_access_mapping m
    WHERE IS_ROLE_IN_SESSION(m.role_name)
      AND m.region = region_val
  );

-- テーブルにアタッチ
ALTER TABLE sales.transactions
  ADD ROW ACCESS POLICY rap_region_mapping ON (region);

Masking Policyとの比較

必要な権限

-- Row Access Policyの管理に必要な権限
-- ポリシーの作成
GRANT CREATE ROW ACCESS POLICY ON SCHEMA security
  TO ROLE policy_admin;

-- ポリシーのアタッチ（テーブルへの適用）
GRANT APPLY ROW ACCESS POLICY ON ACCOUNT
  TO ROLE policy_admin;

-- または特定のテーブルにのみ適用権限を付与
GRANT APPLY ROW ACCESS POLICY ON TABLE sales.transactions
  TO ROLE policy_admin;

-- ポリシーのOWNERSHIPを持つロールはポリシーの変更・削除が可能
-- APPLY権限を持つロールはアタッチ・デタッチが可能
-- この2つの権限を分離することで職務分掌を実現

ポリシー実行順序

Row Access PolicyとMasking Policyが同じテーブルに適用されている場合、Row Access Policyが先に評価され、フィルタを通過した行に対してMasking Policyが適用されます。 この順序はSnowflakeが内部的に制御するため、ユーザーが変更することはできません。

設計のベストプラクティス

• 管理者ロールの除外：ポリシーの最初の条件でSYSADMINやACCOUNTADMINをTRUEにしておく。管理者がデータにアクセスできなくなるとトラブルシューティングが困難になる
• IS_ROLE_IN_SESSION()の使用：CURRENT_ROLE()はSecondary Rolesを考慮しないため、IS_ROLE_IN_SESSION()を使用することでSecondary Roles有効時も正しく評価される
• テスト時にSIMULATE：EXECUTE USING ... コマンドは存在しないため、テスト用ロールでUSE ROLEしてクエリを実行し、期待通りの行のみが返されるか確認する
• Mapping Tableの保護：Mapping Table自体へのアクセス権限を厳格に管理する。Mapping Tableを改ざんされるとアクセス制御がバイパスされる

問題で確認

よくある質問