Snowflake Secondary Rolesの権限評価ロジックと監査への影響

Snowflakeのロールモデルでは、セッションに対して1つのPrimary Roleと、0個以上のSecondary Rolesを設定できます。 Primary RoleはUSE ROLEで切り替える従来のロールで、Secondary Rolesを有効にすると、ユーザーに付与されている他のロールの権限もクエリ実行時に同時に評価されます。 これにより「USE ROLEで頻繁にロールを切り替える」運用負荷を大幅に削減できます。

基本構文

-- セッションでSecondary Rolesを有効化（付与済み全ロールの権限を使用）
USE SECONDARY ROLES ALL;

-- Secondary Rolesを無効化（Primary Roleのみで評価）
USE SECONDARY ROLES NONE;

-- 現在のSecondary Roles設定を確認
SELECT CURRENT_SECONDARY_ROLES();

-- 現在のPrimary Roleを確認
SELECT CURRENT_ROLE();

-- ユーザーのデフォルト設定を変更
ALTER USER analyst_user
  SET DEFAULT_SECONDARY_ROLES = ('ALL');

-- デフォルトをNONEに戻す
ALTER USER analyst_user
  SET DEFAULT_SECONDARY_ROLES = ();

権限評価ロジック

Secondary Roles有効時、Snowflakeはクエリで参照するオブジェクトに対して、Primary Roleとすべての Secondary Rolesのロール階層を合算して権限チェックを行います。 いずれかのロール階層にSELECT権限があればクエリは成功します。

権限評価の詳細比較

実務シナリオ

あるユーザーにANALYST_ROLE（Primary）とDATA_ENGINEER_ROLE（Secondary候補）が付与されている場合の動作を確認します。

-- Primary RoleをANALYSTに設定
USE ROLE ANALYST_ROLE;

-- この状態ではDATA_ENGINEER_ROLEが持つテーブルにはアクセスできない
SELECT * FROM raw.events;  -- ERROR: Insufficient privileges

-- Secondary Rolesを有効化
USE SECONDARY ROLES ALL;

-- DATA_ENGINEER_ROLEの権限も評価され、アクセス可能に
SELECT * FROM raw.events;  -- 成功

-- しかしCURRENT_ROLE()は依然としてANALYST_ROLE
SELECT CURRENT_ROLE();  -- 'ANALYST_ROLE'

-- IS_ROLE_IN_SESSION()で両方のロールを確認可能
SELECT IS_ROLE_IN_SESSION('DATA_ENGINEER_ROLE');  -- TRUE
SELECT IS_ROLE_IN_SESSION('ANALYST_ROLE');         -- TRUE

監査ログへの影響

Secondary Roles有効時、SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORYビューのROLE_NAME列にはPrimary Roleが記録されます。 Secondary Rolesが使われたかどうかはQUERY_HISTORYに直接記録されないため、LOGIN_HISTORYやSESSIONS ビューと組み合わせて監査する必要があります。

-- セッションごとのSecondary Roles使用状況を監査
SELECT
  s.session_id,
  s.user_name,
  s.login_event_id,
  q.role_name AS primary_role,
  q.query_text,
  q.start_time
FROM SNOWFLAKE.ACCOUNT_USAGE.SESSIONS s
JOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY q
  ON s.session_id = q.session_id
WHERE q.start_time >= DATEADD(DAY, -7, CURRENT_TIMESTAMP())
  AND q.query_text ILIKE '%USE SECONDARY ROLES%'
ORDER BY q.start_time DESC;

ポリシー設計上の注意点

• CURRENT_ROLE()の限界：Masking PolicyやRow Access PolicyでCURRENT_ROLE()を使ってアクセス制御している場合、Secondary Rolesの権限は考慮されない。IS_ROLE_IN_SESSION()に置き換えることで、Secondary Rolesも含めた評価が可能になる
• 最小権限の原則との緊張関係：Secondary Roles ALLは利便性が高い一方、意図しないロールの権限が適用されるリスクがある。機密データを扱う環境ではIS_ROLE_IN_SESSION()ベースのポリシー設計を推奨
• DEFAULT_SECONDARY_ROLESの管理：ユーザーごとにALTER USERで設定する必要があり、一括変更にはスクリプトが必要

CURRENT_ROLE()からIS_ROLE_IN_SESSION()への移行パターン

-- 移行前: CURRENT_ROLE()ベースのMasking Policy
CREATE OR REPLACE MASKING POLICY mask_ssn AS (val STRING)
  RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() IN ('HR_ADMIN', 'COMPLIANCE')
      THEN val
    ELSE '***-**-****'
  END;

-- 移行後: IS_ROLE_IN_SESSION()ベース（Secondary Roles対応）
CREATE OR REPLACE MASKING POLICY mask_ssn AS (val STRING)
  RETURNS STRING ->
  CASE
    WHEN IS_ROLE_IN_SESSION('HR_ADMIN')
      OR IS_ROLE_IN_SESSION('COMPLIANCE')
      THEN val
    ELSE '***-**-****'
  END;

問題で確認

よくある質問