はじめに
SnowPro Coreの対策をしていて、私が一番こんがらがった論点が OWNERSHIP 権限でした。SELECT や INSERT のような「やっていいことを表す権限」と同じ感覚で読むと、確実に踏み抜きます。
OWNERSHIPは、ほかの権限とは設計思想からして違う、いわば「メタ権限」です。この別格さを最初に整理しておくと、試験で問われる典型パターン(Managed Access Schema、GRANT OWNERSHIP の挙動、譲渡できないオブジェクト)はすべて派生問題として解けるようになります。
対象読者
- SnowPro Core(COF-C02)を受験予定の方
- Snowflakeの権限管理を業務で触り始めた方
- 「OWNERSHIPって他の権限と何が違うんだっけ?」と聞かれて即答できない方
この記事で扱う3つの特殊ルール(結論先出し)
| # | 特殊ルール | 試験での出題形 |
|---|---|---|
| 1 | オブジェクトは「ただ1つのロール」が必ず所有する | 「誰がOWNERSHIPを持つか」を選ぶ問題 |
| 2 | OWNERSHIPは GRANT でしか移譲できず、REVOKE 不可 |
「ownerを外したい時の操作」を選ぶ問題 |
| 3 | 所有者は対象オブジェクトに対する事実上の全権限を持つ(ただしManaged Access Schemaでは制約あり) | Managed Access Schema問題 |
ここからは、なぜそうなっているのかを順に解きほぐします。
参考リンク
本記事は2026年5月時点の公式ドキュメントを参照しています。Snowflakeの仕様は頻繁に更新されるため、実運用や受験前は必ず最新の公式ドキュメントをご確認ください。
前提:Snowflakeの権限モデルをサクッと
Snowflakeのアクセス制御は DAC(Discretionary Access Control) と RBAC(Role-Based Access Control) を組み合わせたモデルです。
- DAC的な側面: 各オブジェクトには所有者がいて、所有者が自分のオブジェクトへの権限を他者に与えられる
- RBAC的な側面: 権限はユーザーに直接ではなく、ロールに付与される。ユーザーはロールを経由して権限を行使する
ここで重要なのは、 OWNERSHIPは「DAC側の根幹」を担っている権限 だということです。SELECTやINSERTが「やっていいこと」を表すのに対し、OWNERSHIPは「このオブジェクトを支配しているのは誰か」を表します。性質がまったく違うのです。
OWNERSHIPの3つの特殊ルール
ルール1: オブジェクトは必ず1つのロールが所有する
Snowflakeの全セキュア可能オブジェクト(テーブル、ビュー、スキーマ、データベース、ウェアハウス、ロール、ステージなど)は、 必ず1つのロールに所有されています。「所有者なし」「複数所有者」は存在しません。
デフォルトの所有者は、 そのオブジェクトを CREATE した時に使っていたロール です。
USE ROLE data_engineer;
CREATE TABLE sales.public.orders (id INT);
-- このorders表のOWNERは data_engineer ロールになる
ここで地味に試験で問われるのが、ロールはユーザーに紐づくが、OWNERSHIPはユーザーではなくロールが持つ という点です。ロールが複数ユーザーに割り当てられている場合、そのロールを使う全員が実質的に共同管理者になります。
確認するときは SHOW GRANTS ON <object> で見られます。
SHOW GRANTS ON TABLE sales.public.orders;
-- privilege列に OWNERSHIP、grantee_name列に data_engineer が出る
ルール2: OWNERSHIPは GRANT でしか移譲できず、REVOKE 不可
ここがOWNERSHIPの一番の「クセ」です。
普通の権限であれば、「SELECT を付与した」「SELECT を剥奪した」というやり取りができます。 OWNERSHIPには「剥奪」という概念がありません。 必ずどこかのロールが持っている状態を維持しなければならないので、 REVOKE OWNERSHIP FROM ROLE ... のような構文は存在しない のです。
ではどうやって所有者を変えるのか。答えは「別のロールへ譲り渡す(GRANT)」しかありません。これが GRANT OWNERSHIP コマンドの正体です。
-- data_engineer から data_admin へ所有権を譲渡
GRANT OWNERSHIP ON TABLE sales.public.orders
TO ROLE data_admin
COPY CURRENT GRANTS;
通常のGRANT文(GRANT SELECT ON ... など)とは構文が違います。OWNERSHIPだけは専用の GRANT OWNERSHIP 構文で扱います。試験では「OWNERSHIPを移譲する正しいSQLはどれか」が問われることがあるので、構文の形を覚えておきましょう。
ルール3: 所有者はそのオブジェクトに対する事実上の全権限を持つ
通常のスキーマでは、所有ロール(OWNERSHIPを持つロール)は、対象オブジェクトに対する すべての操作と、他ロールへの権限付与・剥奪 を行えます。SELECT も INSERT も DROP も GRANT も REVOKE もできる、いわばオブジェクトの王様です。
ただしこのルールには大きな例外があり、それが後述の Managed Access Schema です。Managed Access Schemaに属するオブジェクトでは、所有者であっても 権限付与の決定権を失います。試験ではこの例外が頻出します。
GRANT OWNERSHIPの構文と動作
OWNERSHIPの移譲を実行するときに、必ず指定する必要があるのが COPY CURRENT GRANTS と REVOKE CURRENT GRANTS のどちらかです。
GRANT OWNERSHIP ON <object_type> <object_name>
TO ROLE <new_owner_role>
{ COPY CURRENT GRANTS | REVOKE CURRENT GRANTS };
なぜ必須なのかというと、 既存の権限(outbound privileges)をどうするかを明示しないと、新しい所有者が意図しない権限を背負ってしまうから です。例えば「元の所有者が analytics_team ロールに SELECT を付与済み」だった場合、所有権だけ移して既存の SELECT 付与を放置すると、新しい所有者の意図しない権限関係が残ります。
COPY vs REVOKE の違い
| 指定 | 既存の権限(outbound privileges)の扱い | 用途 |
|---|---|---|
COPY CURRENT GRANTS |
既存の権限をそのまま新オーナー名義で引き継ぐ | 所有者だけ入れ替えたい時(運用引き継ぎ等) |
REVOKE CURRENT GRANTS |
既存の権限をすべて取り消す | クリーンな状態でリセットしたい時 |
実務での感覚としては、 運用引き継ぎなら COPY、棚卸し・リセットなら REVOKE という棲み分けです。
GRANT OWNERSHIP 文は、 対象オブジェクトに既存のoutbound権限がある場合、COPY も REVOKE も指定しないとエラーで止まります(ロールオブジェクトを除く)。「OWNERSHIPだけ手早く変えたい」ができないのは、安全装置として設計されているためです。
ハマりどころ:Managed Access Schema(試験頻出)
ここがSnowPro Core試験で 本当によく出る 論点です。
通常スキーマとManaged Access Schemaの違い
通常スキーマでは、各オブジェクトの所有者が自分のオブジェクトに対する権限を他ロールに自由に付与できます。一方、 Managed Access Schema を使うと、この「権限を付与する権利」がスキーマ所有者に集約されます。
-- Managed Access Schemaの作成
CREATE SCHEMA my_db.governed_schema WITH MANAGED ACCESS;
「所有者なのに権限付与できない」のカラクリ
Managed Access Schema配下では、 オブジェクトの所有者はOWNERSHIPは保持したまま ですが、 他ロールへ権限を付与する権利だけが奪われます。 権限付与ができるのは以下の2種類のロールだけです。
- スキーマ所有者(スキーマに対する OWNERSHIP を持つロール)
-
MANAGE GRANTSグローバル権限を持つロール(デフォルトではACCOUNTADMINとSECURITYADMIN)
つまり、ガバナンスの観点で「権限付与の窓口を一元化したい」という要件にぴったり合う仕組みです。
試験で出そうな問題
Q1. Managed Access Schemaに追加されたテーブルのOWNERSHIPを持つのは誰か?
→ オブジェクトの所有者(=作成ロールまたは譲渡先ロール)。スキーマ所有者ではない。
Q2. Managed Access Schemaで、オブジェクトに対する権限を他ロールへ付与できるのは誰か?(複数選択)
→ スキーマ所有者 と MANAGE GRANTS 権限を持つロール (デフォルトでは ACCOUNTADMIN と SECURITYADMIN)
Q3. 新しく作成されたオブジェクトに対する権限付与の主導権を、作成者ではなくスキーマ所有者に持たせたい場合、何を使うか?
→ Managed Access Schema (WITH MANAGED ACCESS で作成)
ここで間違えやすいのが、 「Managed Access SchemaではOWNERSHIPがスキーマ所有者に集約される」と勘違いすること。 OWNERSHIPはオブジェクトを作ったロール(または譲渡先)が保持し続けます。集約されるのは「権限付与の決定権」だけです。
譲渡できない/制約があるオブジェクト
GRANT OWNERSHIP はすべてのオブジェクトで自由に使えるわけではありません。試験対策として以下は押さえておきたいポイントです。
譲渡そのものが不可
-
Connectionオブジェクト:
ACCOUNTADMINロールのみOWNERSHIPを持てる - クラスのインスタンス
- 機械学習オブジェクト(モデル、モデルバージョン、モデルモニター)
追加条件が必要
| オブジェクトタイプ | 譲渡前に必要な操作 |
|---|---|
| Pipe | パイプを一時停止する必要あり |
| Task | スケジュールタスクを一時停止する必要あり |
なお、データベースやスキーマに含まれる全タスクをまとめて譲渡すると、 Snowflakeが自動的にすべてのタスクを一時停止 します。COPY CURRENT GRANTSで同じロールに譲渡しても、やはり自動停止されるという挙動です。
共有データベース(Shared Database)の特殊ルール
共有データベース(GRANT USAGE ON DATABASE ... TO SHARE 済みのもの)は、譲渡時の挙動に制約があります。
COPY CURRENT GRANTSは使える-
REVOKE CURRENT GRANTSは使えない(エラーになる)
REVOKEを使いたい場合は、いったんシェアからUSAGEを取り消し、OWNERSHIPを移譲し、再度USAGEを付与し直す、という3ステップが必要です。試験で「共有データベースの所有権を REVOKE CURRENT GRANTS で移譲しようとしたらどうなるか」と聞かれたら、 失敗する が正解です。
Future Grantsとオーナーシップ
Future Grantsは、 これから作成されるオブジェクトに対して、あらかじめ権限を付与しておく仕組み です。OWNERSHIPもFuture Grantsに対応していますが、いくつか制約があります。
-- スキーマ配下に今後作成される全テーブルのOWNERSHIPを team_lead ロールへ
GRANT OWNERSHIP ON FUTURE TABLES IN SCHEMA my_db.my_schema
TO ROLE team_lead;
重要な制約
- OWNERSHIPのFuture Grantは、スキーマ所有者の下位ロールに対してのみ設定可能
- Managed Access Schemaの所有権を別ロールへ移譲する前に、OWNERSHIPのFuture Grantsを
REVOKE ... ON FUTUREですべて解除しておく必要がある
このあたりは細かいですが、選択肢として出てくることがあります。
試験対策チェックリスト
ここまでの内容を、試験本番で迷わないためのチェックリストにまとめます。
| 論点 | 押さえること |
|---|---|
| 所有者の単位 | ユーザーではなく ロール。必ず1つだけ |
| 所有者の決まり方 | 作成時に使っていたロールがデフォルト |
| 所有権の確認方法 | SHOW GRANTS ON <object> |
| 移譲の構文 | GRANT OWNERSHIP ... TO ROLE ... { COPY | REVOKE } CURRENT GRANTS |
| COPY / REVOKE の使い分け | COPY=既存権限引き継ぎ、REVOKE=既存権限クリア |
| OWNERSHIPの剥奪 | REVOKE構文は存在しない。譲渡のみ |
| Managed Access Schemaでのオブジェクト所有者 | OWNERSHIPは保持。権限付与権だけ失う |
| Managed Access Schemaで権限付与できるロール | スキーマ所有者 + MANAGE GRANTS 保有ロール |
| 譲渡できないオブジェクト | Connection、ML系オブジェクト |
| 譲渡に一時停止が必要なオブジェクト | Pipe、Task |
| 共有DB の譲渡 |
COPY は可、REVOKE は不可 |
おわりに
OWNERSHIP権限は、Snowflakeの権限モデル全体を理解する上で「分岐点」になる概念だと思っています。 「Snowflakeの全権限はSELECTやINSERTのように追加/剥奪できる」 という前提を一度捨てて、 「OWNERSHIPだけは別格で、必ず誰かが1人持っている『支配権』だ」 と捉え直すと、Managed Access Schemaや GRANT OWNERSHIP の挙動が一気に腹落ちします。
私自身、試験対策中はここを通常権限と同じ感覚で読んでしまい、模試で点を落としていました。整理し直してからは、関連問題が一気に取れるようになったので、もし同じところでつまずいているなら、この記事の表を一度頭に入れてから過去問に戻ってみてください。
次は同じ流れで、 System-defined Roles(SYSADMIN/SECURITYADMIN/USERADMIN/...)の役割分担と階層関係 をまとめる予定です。OWNERSHIPの話と密接にからむ論点なので、続けて読むと試験対策としては相性が良いはずです。