![[新機能]Feature Policy Rules が一般提供となったので TEMPORARY テーブルとサーバーレスタスクの作成だけをブロックしてみた](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-3610e3c1ff5961bdb7b464e17f8bf06d/90b168b240005ead852ec1d474bb74fb/snowflake-logo-1200x630-1.png?w=3840&fm=webp)
[新機能]Feature Policy Rules が一般提供となったので TEMPORARY テーブルとサーバーレスタスクの作成だけをブロックしてみた
かわばたです。
2026年8月16日にFeature Policy Rules が一般提供となりました。
本記事では、rules によるオブジェクト作成の条件付きブロックと、同時に GA となった DESC FEATURE POLICY の出力を検証します。
【公式ドキュメント】
Feature Policy Rules
【追記】
Snowflake Community Awards の「RISING COMMUNITY LEADER OF THE YEAR」部門・APJ枠のファイナリストに選ばれました。
詳細は下記よりご確認ください。
Feature Policy Rules の概要
Feature Policy は「そのコンテナ内でどのオブジェクトを作成できるか」を制御するガバナンス機能です。適用単位はユーザーやロールではなく、データベース・Personal Database・Native App というコンテナです(アカウントレベルでの一括適用も可能)。
今回の GA で、従来のタイプ単位ブロックに加えて rules による条件付きブロックが書けます。
| 従来: BLOCKED_OBJECT_TYPES_FOR_CREATION | 新: rules (YAML body) | |
|---|---|---|
| 粒度 | オブジェクトタイプ単位の all-or-nothing | リクエスト属性による条件付き |
| 例 | タスクを一切作らせない | サーバーレスタスクだけ禁止 |
| 対象タイプ | TASKS, DATABASES, WAREHOUSES 等 12種 | TABLE, VIEW, STAGE, FUNCTION, PROCEDURE 等に拡大 |
rules はポリシー定義の AS $$ ... $$ に YAML で記述します。block_when の SQL 式が TRUE と評価された作成リクエストがブロックされます。
CREATE FEATURE POLICY <name>
[ BLOCKED_OBJECT_TYPES_FOR_CREATION = ( <type> [ , ... ] ) ]
AS $$
blocked_creation_rules:
- object_type: <OBJECT_TYPE>
block_when: "<SQL式>"
$$;
式の中では SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', '<プロパティ>') で作成リクエストの属性を参照します。プロパティは IS_TEMPORARY / IS_TRANSIENT / WAREHOUSE / EXTERNAL_VOLUME / DATABASE / SCHEMA の6種類で、戻り値はすべて文字列です(Boolean 系は = 'TRUE' と比較します)。
前提条件
- ポリシー作成: ポリシー格納先スキーマへの
CREATE FEATURE POLICY権限 - ポリシー適用: アカウントへの
APPLY FEATURE POLICY権限と、適用する Feature Policy へのAPPLYまたはOWNERSHIP権限 - エディション要件はドキュメントに明記されていません(トライアルアカウントで動作を確認済み)
検証は2026年8月21日および23日(日本時間)に AWS 東京リージョンのアカウントで実施しています。ロールはすべて ACCOUNTADMIN です。
事前準備
ポリシー格納用 DB と適用対象 DB を作成します。
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE DATABASE FP_POLICY_DB; -- ポリシー格納用
CREATE SCHEMA FP_POLICY_DB.POLICIES;
CREATE OR REPLACE DATABASE FP_TEST_DB; -- 適用対象
CREATE OR REPLACE DATABASE FP_TEST_DB2; -- 優先順位検証用
試してみた
従来型: タイプ単位の all-or-nothing
比較のため、まず従来の BLOCKED_OBJECT_TYPES_FOR_CREATION でタスク作成を禁止します。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TASKS_ALL
BLOCKED_OBJECT_TYPES_FOR_CREATION = (TASKS)
COMMENT = 'Block all task creation (legacy style)';
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TASKS_ALL;
ウェアハウス指定タスクを作成してみます。
CREATE TASK FP_TEST_DB.PUBLIC.T_WH
WAREHOUSE = COMPUTE_WH SCHEDULE = '60 MINUTE' AS SELECT 1;

サーバーレスタスク(WAREHOUSE 指定なし)も同じエラーでブロックされ、テーブル作成は成功しました。タイプ単位のためタスクは全部か無かの制御になります。
注目すべきは、ACCOUNTADMIN でもブロックされる点です。Feature Policy はロールではなく DB というコンテナに効くため、管理者の操作も例外になりません。
次の検証のため解除しておきます。
ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
rules: TEMPORARY テーブルだけブロックできる
GA の本命である rules を試します。IS_TEMPORARY プロパティを条件に、TEMPORARY テーブルの作成だけを禁止します。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES
COMMENT = 'Block only temporary tables'
AS $$
blocked_creation_rules:
- object_type: TABLE
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'IS_TEMPORARY') = 'TRUE'"
$$;
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES;

3種類のテーブルを作成した結果です。
CREATE TABLE FP_TEST_DB.PUBLIC.T2 (ID INT); -- 成功
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T3 (ID INT); -- ブロック (003001)
CREATE TRANSIENT TABLE FP_TEST_DB.PUBLIC.T4 (ID INT); -- 成功



TEMPORARY だけがブロックされました。TRANSIENT は IS_TEMPORARY に該当しないため成功します(TRANSIENT も止めるなら IS_TRANSIENT の条件を追加します)。従来型では不可能だった「テーブルは許可、ただし一時テーブルだけ禁止」が実現できています。
rules: サーバーレスタスクだけブロックできる
タスクの WAREHOUSE プロパティは、ウェアハウス指定がないサーバーレスタスクで NULL になります。これを条件にすると、コスト統制の定番要望「サーバーレスタスクだけ禁止」を実装できます。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS
COMMENT = 'Block only serverless tasks'
AS $$
blocked_creation_rules:
- object_type: TASK
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') IS NULL"
$$;
適用しようとしたところ、エラーになりました。
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS;

1つのデータベースに直接バインドできる Feature Policy は1つです。既存の DB レベルポリシーがある状態で FORCE を付けずに SET するとエラーになります。今回は FORCE を指定して直接置き換えます。
-- FORCE で既存の DB レベルポリシーを直接置き換える
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS
FORCE;

タスクを2パターン作成した結果です。
-- ウェアハウス指定タスク → 成功
CREATE TASK FP_TEST_DB.PUBLIC.T_WH
WAREHOUSE = COMPUTE_WH SCHEDULE = '60 MINUTE' AS SELECT 1;
-- サーバーレスタスク → ブロック (003001)
CREATE TASK FP_TEST_DB.PUBLIC.T_SERVERLESS
SCHEDULE = '60 MINUTE' AS SELECT 1;


狙いどおり、ウェアハウス指定タスクは作成でき、サーバーレスタスクだけがブロックされました。
名前付き条件で複数タイプに同じ条件を使い回せる
conditions で名前を付けた式は、block_when_any で複数のルールから参照できます。従来型パラメータとの併用も可能です。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH
COMMENT = 'Named condition + legacy param combined'
BLOCKED_OBJECT_TYPES_FOR_CREATION = (WAREHOUSES)
AS $$
conditions:
- name: is_temp
expression: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'IS_TEMPORARY') = 'TRUE'"
blocked_creation_rules:
- object_type: TABLE
block_when_any:
- is_temp
- object_type: STAGE
block_when_any:
- is_temp
$$;
ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T6 (ID INT); -- ブロック
CREATE TEMPORARY STAGE FP_TEST_DB.PUBLIC.S_TEMP; -- ブロック (Create STAGE denied)
CREATE STAGE FP_TEST_DB.PUBLIC.S1; -- 成功



テーブル・ステージの両方で TEMPORARY だけがブロックされました。一方、併用した WAREHOUSES は効きませんでした。
CREATE WAREHOUSE FP_TEST_WH WITH WAREHOUSE_SIZE = 'XSMALL' INITIALLY_SUSPENDED = TRUE;

ウェアハウスはアカウントレベルオブジェクトで、作成は DB コンテナの外の操作です。そのため DB にバインドしたポリシーでは制御されません。ドキュメントでも、アカウントレベルオブジェクトタイプは Native App にバインドした場合のみ有効とされています。
DESC FEATURE POLICY: policy_definition に YAML が表示される
同時に GA となった DESC FEATURE POLICY で rules を確認します。
DESC FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS;

policy_definition プロパティに、設定した YAML のポリシー定義が表示されます。今回の検証環境では、rules を持たないポリシーを DESC すると policy_definition 行自体が表示されませんでした。
適用状況の確認には SHOW と POLICY_REFERENCES を使います。IN は「その場所に作成されたポリシー」、ON は「適用されているポリシー」で、ON の結果には適用先を示す set_on カラムが付きます。
SHOW FEATURE POLICIES IN DATABASE FP_POLICY_DB; -- 作成した4ポリシーが一覧表示
SHOW FEATURE POLICIES ON DATABASE FP_TEST_DB; -- 適用中の1ポリシーのみ (set_on = DATABASE)
SELECT POLICY_NAME, POLICY_KIND, REF_ENTITY_NAME, REF_ENTITY_DOMAIN, POLICY_STATUS
FROM TABLE(FP_POLICY_DB.INFORMATION_SCHEMA.POLICY_REFERENCES(
POLICY_NAME => 'FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH'));

適用の優先順位を確認する
通常のデータベースでは、DB レベルのポリシーがアカウントレベル(FOR ALL DATABASES)のポリシーより優先されます。アカウント全体を縛りつつ、特定 DB だけ空ポリシーで制限解除する公式記載のテクニックを試します。
ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
-- アカウント内のすべての通常の DB に TEMPORARY テーブル禁止を適用
ALTER ACCOUNT
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES FOR ALL DATABASES;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T8 (ID INT);

FP_TEST_DB2 でも同じエラーになりました。DB 適用時とはメッセージが異なり、アカウントポリシー起因であることと確認コマンドが示されます。
次に「何もブロックしない」空ポリシーを作成し、FP_TEST_DB にだけ適用します。空リスト () で作成できました。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_NOTHING
BLOCKED_OBJECT_TYPES_FOR_CREATION = ()
COMMENT = 'Empty policy to lift account-level restrictions';
ALTER DATABASE FP_TEST_DB
SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_NOTHING;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T8 (ID INT); -- 成功
CREATE TEMPORARY TABLE FP_TEST_DB2.PUBLIC.T9 (ID INT); -- 引き続きブロック


DB レベルの空ポリシーがアカウントレベルより優先され、FP_TEST_DB だけ制限が解除されました。なお今回の検証環境では、アカウント適用中に SHOW FEATURE POLICIES ON ACCOUNT の options カラムへ {"target_scopes":["ALL_DATABASES"]} が表示されました。
検証後はアカウントレベルの適用を解除します。
ALTER ACCOUNT UNSET FEATURE POLICY FOR ALL DATABASES;
つまずいたところ
評価できない式は作成時に拒否される
WAREHOUSE プロパティは TASK 以外の作成リクエストでは常に NULL です。これを TABLE のルールで等価比較すると、実行時ではなくポリシー作成時に拒否されました。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.NULL_TRAP2
AS $$
blocked_creation_rules:
- object_type: TABLE
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') = 'COMPUTE_WH'"
$$;

object_type: ALL でも同じエラーです。対象タイプで評価しようがない式は作成段階で弾かれます。
NULL 評価は fail-closed でブロックされる
作成時バリデーションを通った式でも、実行時に NULL と評価されるケースがあります。TASK に WAREHOUSE = 'COMPUTE_WH' の条件を付けてサーバーレスタスクを作成すると、NULL = 'COMPUTE_WH' は NULL になります。
CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.NULL_TRAP3
AS $$
blocked_creation_rules:
- object_type: TASK
block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') = 'COMPUTE_WH'"
$$;
-- (FP_TEST_DB に適用後)
CREATE TASK FP_TEST_DB.PUBLIC.T_B SCHEDULE = '60 MINUTE' AS SELECT 1;

FALSE のときだけ許可、TRUE と NULL はブロックという fail-closed の挙動で、NULL の場合は専用のエラーメッセージになります。実際に COMPUTE_WH 指定(TRUE)はブロック、別ウェアハウス指定(FALSE)は成功でした。「条件に該当しなければ許可されるはず」という感覚で書くと、NULL の分岐で意図せずブロックされるため注意が必要です。
制限事項・注意点
制限事項・注意点
- バインド中のポリシーは
CREATE OR REPLACE/DROPできません。変更はALTER FEATURE POLICYを使い、削除は先に適用を解除します - ポリシー定義に
CLONE句は使えません - rules の式でテーブル等の DB オブジェクトや副作用のある関数は参照できません
- アカウントレベルのポリシー参照をレプリケーションする場合、ポリシーの格納 DB をレプリケーショングループに含めないと適用先で強制されません
最後に
Feature Policy Rules により、オブジェクト作成の制御が「タイプ丸ごと」から「条件付き」に進化しました。サーバーレスタスクや一時テーブルだけの禁止など、コスト統制・ガバナンスの実用的なポリシーを ACCOUNTADMIN 含む全ユーザーに強制できます。NULL 評価が fail-closed でブロックになる点だけは、ポリシー設計時に注意してください。
この記事が何かの参考になれば幸いです!





