はじめに
SnowPro Coreの勉強をしていて、Managed Access Schemaという単語に出会ったとき、私は「マネージドなんちゃらってAWSのMSKみたいに勝手に運用してくれるやつ？」とふんわり捉えていました。全然違いました（実際に模試で1問落としました）。
このスキーマ、ざっくり言うと 「権限管理を中央集権化するための仕組み」 です。Snowflakeの権限まわりは「誰がオーナーで、誰が権限を渡せて、誰が叩けるか」が試験でも実務でも地味にややこしいのですが、Managed Access Schemaを理解すると一気に視界がクリアになります。
この記事では、SnowPro Coreで問われる観点に絞って、通常スキーマとManaged Access Schemaの違いを「誰が権限を渡せるか」という1つの軸で整理していきます。
対象読者
- SnowPro Core認定試験の勉強中で、Managed Access Schemaの違いを腹落ちさせたい人
- Snowflakeの権限管理が分散してきて、そろそろ統制したいと考えている実務者
参考
先に結論から
最初に結論をどうぞ。観点で並べるとこうなります。
「で、何が嬉しいの？」を一言で言うと、子オブジェクトのオーナーが勝手に他ロールへ権限をバラまけなくなる ということです。順に見ていきます。
そもそも：通常のスキーマでは「誰が」権限を渡せるのか
Snowflakeでは、オブジェクト（テーブル、ビュー、ストアドプロシージャ等）を作成すると、それを作ったロールがそのオブジェクトの OWNERSHIP 権限を持ちます。そして通常のスキーマでは、このオブジェクトオーナーが自分のオブジェクトに対する権限を他のロールへ自由に付与できる、というのが基本ルールです。
ざっくり図にするとこんな感じです。
一見便利なのですが、これ、組織が大きくなるとちょっと怖いんです。
たとえばあるアナリストロールが分析用テーブルを作成したとします。そのアナリストは「同僚にも見せたいな〜」と気軽に GRANT SELECT を打って権限を広げられてしまう。セキュリティ管理者からすると「えっ、いつのまにこのロールに見せてたの？」となる事故が起きやすい。これが分散管理の弱点です。
権限がどこに付いているかを追跡するために、毎回 SHOW GRANTS を全オブジェクトに対して打つようなことをしていませんか？私は最初そうやって追っていて、すぐに「これスケールしないな」と気づきました。
Managed Access Schemaの正体
そこで登場するのが Managed Access Schema です。公式ドキュメントの定義を要約すると、こうなります。
Managed Access Schemaは、スキーマ内のオブジェクトに対する権限付与を スキーマオーナーに一元化する スキーマである。オブジェクトオーナーは引き続き OWNERSHIP を保持するが、権限付与の権利は持たない。
つまり、オーナーシップと権限付与権を切り離す という発想です。
ROLE_AはT1のオーナーですが、自分の判断ではT1をROLE_Xに見せられません。スキーマオーナー（または MANAGE GRANTS 権限を持つロール）を経由する必要があります。
作成構文
シンプルに WITH MANAGED ACCESS を付けるだけです。
CREATE SCHEMA my_schema WITH MANAGED ACCESS;
確認するときは SHOW SCHEMAS; の options 列を見ます。
name | options
--------------|-------------------
MY_SCHEMA | MANAGED ACCESS
PUBLIC |
options に MANAGED ACCESS と出ていれば、それがManaged Access Schemaです。
既存スキーマも切り替え可能
「既に作っちゃった通常スキーマ、もうダメじゃん…」と思った方、安心してください。ALTER SCHEMA で後から切り替えられます。
-- 通常スキーマ → Managed Access Schema
ALTER SCHEMA my_schema ENABLE MANAGED ACCESS;
-- Managed Access Schema → 通常スキーマ
ALTER SCHEMA my_schema DISABLE MANAGED ACCESS;
ここ、SnowPro Coreの選択肢で出てきても焦らないようにしておきたいポイントです。
「誰が権限を渡せるか」をきっちり整理する
ここがこの記事の核心です。問題文を読むときの脳内デコーダだと思ってください。
| ロール／状況 | 通常のスキーマ | Managed Access Schema |
|---|---|---|
| オブジェクトオーナー（OWNERSHIP保持） | ✅ 付与できる | ❌ 付与できない |
| スキーマオーナー（スキーマのOWNERSHIP保持） | ❌（オブジェクトの権限は付与不可） | ✅ 付与できる |
MANAGE GRANTS権限保持ロール（典型例: SECURITYADMIN） |
✅ 付与できる | ✅ 付与できる |
よくある誤解：「Managed Access Schemaではスキーマオーナーだけが権限を付与できる」と覚えてしまうと、MANAGE GRANTS が絡む選択肢に引っかかります。公式ドキュメントでも、Managed Access Schemaにおいて権限付与ができるのは スキーマオーナー または MANAGE GRANTS を持つロール と明記されています。
さらにもう一段、知っておくと得する仕様があります。Managed Access Schemaでは、スキーマオーナーは grant 管理の権限を持つだけで、配下のオブジェクトに対する USAGE / SELECT / DROP 等の操作権限は自動では持たない のです。「権限を渡す係」と「実際に触る人」が分離される、と理解するとスッキリします。
メリットを実務目線で整理する
ここまでの内容を踏まえて、Managed Access Schemaを使う具体的なメリットを整理します。
-
権限管理がスキーマオーナーに一元化される
どのロールが何を見られるかを、スキーマオーナー（またはMANAGE GRANTS保持ロール）に集約できます。レビューが格段にやりやすい。 -
子オブジェクトのオーナーが暴走しない
ETLジョブ用のロールがオブジェクトを作っても、そのロールが勝手に他者へ権限を付与することはできません。「ジョブが作ったテーブルがいつの間にか全社に見えていた」事故を防げます。 -
ガバナンス・監査要件への対応がしやすい
金融や医療など、誰が誰に何を見せたかの監査ログが厳密に求められる組織で特に効きます。権限付与の経路が絞られるので、誰を絞めれば統制できるかが明確です。 -
Future Grantsとの組み合わせで威力倍増
スキーマレベルのFuture Grants（GRANT SELECT ON FUTURE TABLES IN SCHEMA ... TO ROLE ...）と組み合わせると、「このスキーマに今後作られるテーブルは全部このロールに見せる」を一元管理できます。
トレードオフ：いつ使わないほうがいいか
良いことばかり書きましたが、当然トレードオフもあります。
-
スキーマオーナーの負担が増える
権限付与のリクエストがすべてスキーマオーナーに集まります。小さい組織でロールが少ない場合、過剰なボトルネックになることがあります。 -
開発スピードが落ちることがある
「アナリストがアドホックに自作テーブルを共有したい」というユースケースでは、Managed Access Schemaは摩擦になります。サンドボックス的なスキーマは通常スキーマのまま、本番系はManaged Access Schemaにする、といった使い分けが現実的です。
まとめ
Managed Access Schemaを一言で言えば、「権限管理の窓口をスキーマオーナーに絞る仕組み」 です。WITH MANAGED ACCESS という1行を足すだけで、子オブジェクトのオーナーが勝手に権限を付与する経路を塞げる。シンプルですが、ガバナンス的にはかなりインパクトのある機能です。
SnowPro Core対策としては、「通常スキーマ＝分散」「Managed Access＝中央集権」という対比を軸に、付与できるロールが誰なのかを正確に覚えれば、関連問題はだいたい取れます。
私はこの違いを腹落ちさせた瞬間、ロール設計の問題が一気に解けるようになりました。同じく勉強中の方がいたら、ぜひ手元のSnowflakeアカウントで CREATE SCHEMA ... WITH MANAGED ACCESS を打って、SHOW SCHEMAS で options 列を確認してみてください。「あ、これか」と腑に落ちる瞬間が来ます。