[新機能]既存・将来オブジェクトへの権限をまとめて管理できる「Inherited Grants」と、権限管理を委任できる「Container-level MANAGE GRANTS」を試してみた

さがらです。

Snowflakeの権限管理をしていると、「あるデータベース配下のテーブルに、既存分も将来作成される分もまとめてSELECT権限を付与したい」というケースがよくあります。これまではGRANT ... ON ALLとGRANT ... ON FUTUREを組み合わせて実現する必要がありましたが、この2つを1つのGRANT文にまとめられるInherited Grantsという機能が提供されています。

さらに、Inherited Grantsと同じPreview Featureを有効化すると、データベースやスキーマ単位で権限管理そのものを別ロールに委任できるContainer-level MANAGE GRANTSという機能も合わせて使えるようになります。

（実はこれらの機能、リリースノートには特に記載が見当たらなかったのですが、いつの間にかリリースされていたようです。）

https://docs.snowflake.com/en/user-guide/inherited-grants-intro

https://docs.snowflake.com/en/user-guide/inherited-grants-using

https://docs.snowflake.com/en/user-guide/container-manage-grants-intro

実際にどこまでできるのか、既存オブジェクト・将来オブジェクトへの適用範囲やオブジェクトタイプごとの制御、監査方法、そしてContainer-level MANAGE GRANTSによる権限管理の委任まで一通り試してみたので、本記事でまとめます。

機能概要

Inherited Grantsは、ACCOUNT/DATABASE/SCHEMAといった下位にオブジェクトを持つオブジェクトに対して1つの権限を定義するだけで、その配下にある現在および将来作成される対象オブジェクトへ自動的に権限が適用される機能です。通常のGRANT文にINHERITEDキーワードを付けて実行します。

GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE some_db
  TO ROLE some_reader_role;

このように付与すると、some_db内の既存テーブルだけでなく、将来作成されるテーブルにもSELECT権限が自動的に適用されます。従来のON ALL＋ON FUTUREの組み合わせを、この1文に置き換えられるのが最大のポイントです。

併せて、同じPreview Featureで利用できるようになるContainer-level MANAGE GRANTSにも触れます。従来MANAGE GRANTSはアカウント全体に効くグローバル権限でしたが、Container-level MANAGE GRANTSを使うと、特定のデータベースやスキーマに絞って権限管理そのものを別ロールに委任できます。

GRANT MANAGE GRANTS ON DATABASE some_db TO ROLE some_admin_role;

これにより、some_admin_roleはACCOUNTADMINを介さずに、some_db配下のオブジェクトに対するgrant（Inherited Grantsを含む）を管理できるようになります。

制限事項

• 2026年7月17日時点ではいずれもPreview Featureです。利用にはアカウントでのPreview Feature有効化と、ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED'によるアカウント設定が必要です（この1つのパラメータでInherited GrantsとContainer-level MANAGE GRANTSの両方が有効になります）
• Inherited Grantsはオブジェクトタイプ単位で付与する必要があります。TABLESに付与してもVIEWSやDYNAMIC TABLESには適用されないため、対象タイプごとに個別のGRANT INHERITEDが必要です
• OWNERSHIPはInherited Grantsの対象外です。またORGANIZATION・APPLICATION・APPLICATION PACKAGE・SHARE・INTEGRATIONや、ROLE/USERに対するUSAGEなども対象外です
• データベースやスキーマ配下の一部オブジェクトだけ異なるアクセス制御をしたい場合、Inherited Grantsだけでは制御しきれません。
• Container-level MANAGE GRANTSはデータベース・スキーマ単位の委任機能であり、アカウント全体に効くグローバルなMANAGE GRANTS権限を置き換えるものではありません。

事前準備

検証用に、ロール・データベース・スキーマ・テーブル・ウェアハウスを準備します。ここで準備するオブジェクトは、この後の「Inherited Grants」と「Container-level MANAGE GRANTS」という2つの検証で共通して使用します。まず、Inherited Grantsを利用できるようにアカウント設定を変更しておきます。

Preview Featureの有効化

USE ROLE ACCOUNTADMIN;

ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED';

エラーなく実行できればOKです。

なお、このパラメータを有効化すると、Inherited Grantsだけでなく、データベースやスキーマ単位で権限管理を委任できるContainer-level MANAGE GRANTSも同時に利用できるようになります。

https://docs.snowflake.com/en/user-guide/container-manage-grants-intro

検証用ロール

検証用オブジェクトの作成、Inherited Grantsの付与・取り消しといった基本の検証手順はすべてACCOUNTADMINで行います。IG_DEMO_ADMINはContainer-level MANAGE GRANTSの検証で使用します。

検証用データベース・スキーマ・テーブル

検証用ウェアハウス

まずACCOUNTADMINでウェアハウス・データベース・スキーマ・既存テーブル・ビューを作成しておきます。

USE ROLE ACCOUNTADMIN;

-- 検証用Warehouse
CREATE OR REPLACE WAREHOUSE IG_DEMO_WH
  WAREHOUSE_SIZE = XSMALL
  AUTO_SUSPEND = 60
  INITIALLY_SUSPENDED = TRUE;

-- 検証用Database / Schema
CREATE OR REPLACE DATABASE IG_DEMO_DB;
CREATE OR REPLACE SCHEMA IG_DEMO_DB.DOMAIN_A;

-- Inherited Grants付与前から存在するテーブル
CREATE OR REPLACE TABLE IG_DEMO_DB.DOMAIN_A.T_EXISTING (
  ID NUMBER,
  NAME STRING
);

INSERT INTO IG_DEMO_DB.DOMAIN_A.T_EXISTING VALUES
  (1, 'alice'),
  (2, 'bob');

-- TABLESとVIEWSの違いを見るためのView
CREATE OR REPLACE VIEW IG_DEMO_DB.DOMAIN_A.V_EXISTING AS
SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING;

続けて、2つの検証で共通して使う検証用ロールを作成し、Warehouseの利用権限を付与します。

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE ROLE IG_DEMO_READER;
CREATE OR REPLACE ROLE IG_DEMO_ADMIN;

-- 現在のユーザーに検証用ロールを付与
SET MY_USER = CURRENT_USER();

GRANT ROLE IG_DEMO_READER TO USER IDENTIFIER($MY_USER);
GRANT ROLE IG_DEMO_ADMIN TO USER IDENTIFIER($MY_USER);

-- 検証用Warehouseの利用権限
GRANT USAGE ON WAREHOUSE IG_DEMO_WH TO ROLE IG_DEMO_READER;
GRANT USAGE ON WAREHOUSE IG_DEMO_WH TO ROLE IG_DEMO_ADMIN;

-- IG_DEMO_ADMIN自身がDBを解決できるようにする
GRANT USAGE ON DATABASE IG_DEMO_DB TO ROLE IG_DEMO_ADMIN;

本記事ではこの後、「Inherited Grants」と「Container-level MANAGE GRANTS」という2つの検証を行います。基本の検証手順はいずれもACCOUNTADMINで実行し、IG_DEMO_ADMINへのContainer-level MANAGE GRANTSの委任は後半の検証内で行います。

試してみた（Inherited Grants）

1. Inherited Grantsを付与する

IG_DEMO_READERに対して、以下の3つを付与します。

• IG_DEMO_DBへの通常のUSAGE
• IG_DEMO_DB内の全スキーマへの継承USAGE
• IG_DEMO_DB内の全テーブルへの継承SELECT

USE ROLE ACCOUNTADMIN;

-- DB自体は通常のUSAGEが必要
GRANT USAGE ON DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;

-- DB配下の現在・将来のスキーマに対するUSAGE
GRANT INHERITED USAGE ON ALL SCHEMAS
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

-- DB配下の現在・将来のテーブルに対するSELECT
GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

エラーなく3文とも実行できればOKです。

2. 既存テーブルにアクセスできることを確認する

まずは、Inherited Grants付与前からすでに存在していたT_EXISTINGテーブルにアクセスできるかを確認します。

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING;

下図のように結果が返ってくればOKです。

Inherited Grantsを付与した時点ですでに存在していたテーブルにも、SELECT権限が適用されていることが確認できました。

3. 将来作成されるテーブルにもアクセスできることを確認する

次に、Inherited Grants付与後に新規作成したテーブルにもアクセスできるかを確認します。まずはACCOUNTADMINで新しいテーブルを作成します。

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE TABLE IG_DEMO_DB.DOMAIN_A.T_FUTURE (
  ID NUMBER,
  VALUE STRING
);

INSERT INTO IG_DEMO_DB.DOMAIN_A.T_FUTURE VALUES
  (100, 'created after inherited grant');

IG_DEMO_READERに切り替えて参照します。

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_FUTURE;

以下のように結果が返ってくればOKです。

Inherited Grants付与後に作成されたテーブルにも、追加のGRANTなしでアクセスできることを確認できました。

4. 将来作成されるスキーマ配下のテーブルにもアクセスできることを確認する

さらに範囲を広げて、新規作成したスキーマ配下のテーブルにもアクセスできるかを確認します。ACCOUNTADMINで新しいスキーマとテーブルを作成します。

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE SCHEMA IG_DEMO_DB.DOMAIN_B;

CREATE OR REPLACE TABLE IG_DEMO_DB.DOMAIN_B.T_FUTURE_SCHEMA (
  ID NUMBER,
  VALUE STRING
);

INSERT INTO IG_DEMO_DB.DOMAIN_B.T_FUTURE_SCHEMA VALUES
  (200, 'new schema and new table');

IG_DEMO_READERで参照します。

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_B.T_FUTURE_SCHEMA;

以下のように結果が返ってくればOKです。

ここでポイントになるのは、事前に以下の2つを付与していたことです。

GRANT INHERITED USAGE ON ALL SCHEMAS IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;
GRANT INHERITED SELECT ON ALL TABLES IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;

前者により将来作成されるスキーマのUSAGEがカバーされ、後者により将来作成されるテーブルのSELECTがカバーされるため、新規スキーマ配下のテーブルであっても追加のGRANTなしで参照できています。

5. オブジェクトタイプ単位の制御を確認する（TABLESだけではVIEWSは対象外）

ここまでで付与したInherited GrantsはALL TABLESに対するものだけなので、ビューに対するSELECTはまだ付与されていません。実際にビューへアクセスできるか確認します。

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.V_EXISTING;

以下のようにエラーになれば想定どおりです。

ビューにもアクセスさせたい場合は、VIEWSに対しても明示的にInherited Grantsを付与する必要があります。

USE ROLE ACCOUNTADMIN;

GRANT INHERITED SELECT ON ALL VIEWS
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

再度確認すると、以下のように結果が返ってくればOKです。

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.V_EXISTING;

Inherited Grantsはオブジェクトタイプ単位で適用されるため、テーブル・ビュー・Dynamic Table・Iceberg Tableなどをまとめて対象にしたい場合は、それぞれのオブジェクトタイプに対して個別にGRANT INHERITEDを発行する必要があります。

6. Inherited Grantsの監査方法を確認する

Inherited Grantsは、以下の3つのコマンドと1つのビューで確認できます。

データベース/スキーマに定義されたInherited Grantsを確認する

USE ROLE ACCOUNTADMIN;

SHOW INHERITED GRANTS IN DATABASE IG_DEMO_DB;

特定オブジェクトに適用されているgrantを確認する

SHOW GRANTS ON TABLE IG_DEMO_DB.DOMAIN_A.T_EXISTING;

ロールに付与されたgrantを確認する

SHOW GRANTS TO ROLE IG_DEMO_READER;

7. Information Schemaでの見え方の注意点を確認する

Information Schemaのビューは、Inherited Grantsを可視性判定に考慮しない場合があります。そのため、Inherited Grantsのみでアクセスできるオブジェクトが、実際には参照できるにもかかわらずInformation Schemaに表示されないことがあります。

USE ROLE IG_DEMO_READER;

SELECT
  TABLE_SCHEMA,
  TABLE_NAME
FROM IG_DEMO_DB.INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME IN ('T_EXISTING', 'T_FUTURE', 'T_FUTURE_SCHEMA')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING自体は成功するにもかかわらず、下図のようにInformation Schema上では対象テーブルが表示されない、ということが確認できました。運用上のはまりどころになりえると感じたのでご注意ください。

8. revoke後にアクセスできなくなることを確認する

最後に、TABLESに対するInherited Grantsを取り消し、アクセスできなくなることを確認します。

USE ROLE ACCOUNTADMIN;

REVOKE INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  FROM ROLE IG_DEMO_READER;

再度テーブルを参照します。

USE ROLE IG_DEMO_READER;
USE WAREHOUSE IG_DEMO_WH;

SELECT * FROM IG_DEMO_DB.DOMAIN_A.T_EXISTING;

以下のようにエラーになればOKです。

Inherited Grantsを取り消すと、既存テーブル・将来テーブルのいずれに対するアクセスも失われることが確認できました。

9. 従来のON ALL + ON FUTUREとの比較

従来は、既存オブジェクトと将来オブジェクトそれぞれに対して個別にGRANTする必要がありました。

-- 従来の書き方
GRANT SELECT ON ALL TABLES IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;
GRANT SELECT ON FUTURE TABLES IN DATABASE IG_DEMO_DB TO ROLE IG_DEMO_READER;

-- Inherited Grantsの書き方
GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

ただし、この置き換えができるのは以下をすべて満たす場合のみです。

• 既存オブジェクトと将来オブジェクトに付与する権限が同一であること
• 付与先ロールが同一であること
• 除外したいオブジェクトがないこと

一部のオブジェクトだけ除外したい場合は、Inherited Grantsではなく従来の粒度の細かいGRANTとの併用を検討する必要があります。

試してみた（Container-level MANAGE GRANTS）

ここまでの検証はすべてACCOUNTADMINでInherited Grantsを付与・取り消ししてきましたが、実運用ではACCOUNTADMINを都度使うのではなく、特定のロールにデータベース単位で権限管理を委任したいケースが多いはずです。事前準備で有効化したContainer-level MANAGE GRANTSを使うと、この委任が可能です。

1. Container-level MANAGE GRANTSを付与する

事前準備で作成しておいたIG_DEMO_ADMINロールに対して、IG_DEMO_DBへのMANAGE GRANTSを付与します。

USE ROLE ACCOUNTADMIN;

-- IG_DEMO_DBに対するMANAGE GRANTSをIG_DEMO_ADMINに委任（Container-level MANAGE GRANTS）
GRANT MANAGE GRANTS ON DATABASE IG_DEMO_DB TO ROLE IG_DEMO_ADMIN;

エラーなく実行できればOKです。

2. 委任されたMANAGE GRANTSを確認する

SHOW GRANTS ON DATABASE IG_DEMO_DB;

PRIVILEGE列がMANAGE GRANTS、GRANTEE_NAME列がIG_DEMO_ADMINになっている行があればOKです。

3. IG_DEMO_ADMINがInherited Grantsを付与できることを確認する

IG_DEMO_ADMINがACCOUNTADMINを介さずにInherited Grantsを付与できるかを確認します。なお、TABLESに対するInherited Grantsは、試してみた（Inherited Grants）の手順8で一度取り消しているため、ここではIG_DEMO_ADMINによる再付与という形で確認します。

USE ROLE IG_DEMO_ADMIN;

GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

エラーなく実行できればOKです。MANAGE GRANTSが委任されたIG_DEMO_ADMINだけで、ACCOUNTADMINを使わずにInherited Grantsを管理できることが確認できました。

4. MANAGE GRANTSを持たないロールでは実行できないことを確認する

比較のため、MANAGE GRANTSを付与していないIG_DEMO_READERで同じ操作を試してみます。

USE ROLE IG_DEMO_READER;

GRANT INHERITED SELECT ON ALL TABLES
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

以下のようなアクセス権限不足のエラーになればOKです。

5. 委任を取り消して確認する

最後に、IG_DEMO_ADMINへのMANAGE GRANTS委任を取り消し、Inherited Grantsを管理できなくなることを確認します。

USE ROLE ACCOUNTADMIN;

REVOKE MANAGE GRANTS ON DATABASE IG_DEMO_DB FROM ROLE IG_DEMO_ADMIN;

再度IG_DEMO_ADMINでInherited Grantsの付与を試みます。

USE ROLE IG_DEMO_ADMIN;

GRANT INHERITED SELECT ON ALL VIEWS
  IN DATABASE IG_DEMO_DB
  TO ROLE IG_DEMO_READER;

先ほどと同様のアクセス権限不足のエラーになればOKです。MANAGE GRANTSの委任を取り消すと、ACCOUNTADMIN以外のロールではInherited Grantsを管理できなくなることが確認できました。

お片付け

検証後は、Inherited GrantsとContainer-level MANAGE GRANTSのどちらの検証でも使ったオブジェクトを、以下のSQLでまとめて削除しておきます。

USE ROLE ACCOUNTADMIN;

DROP DATABASE IF EXISTS IG_DEMO_DB;
DROP WAREHOUSE IF EXISTS IG_DEMO_WH;

DROP ROLE IF EXISTS IG_DEMO_READER;
DROP ROLE IF EXISTS IG_DEMO_ADMIN;

最後に

SnowflakeのInherited Grantsを試して、既存オブジェクトと将来オブジェクトに対する権限付与を1つのGRANT INHERITED文で管理できることを確認できました。特に、データベースやスキーマ単位で一貫したread権限を付与したいケースでは、従来のON ALLとON FUTUREの組み合わせよりもシンプルに管理できると感じました。

さらに、Container-level MANAGE GRANTSを組み合わせることで、ACCOUNTADMINに頼らずデータベース単位でInherited Grantsの管理を委任できることも確認できました。委任先のロールでもInherited Grantsを問題なく付与・取り消しできる一方、MANAGE GRANTSを持たないロールでは操作が拒否されることも確認でき、権限の境界線がわかりやすく設計されている印象です。

2026年7月17日時点ではInherited GrantsとContainer-level MANAGE GRANTSのいずれもPreview Featureのため、今後GAに向けて仕様が変わる可能性があります。権限管理の運用改善を検討している方は、まずは検証環境で触ってみることをおすすめします。