Snowflake でできることが増えたら、 ABAC が必要になった

Transcript

1. Snowflake でできることが増えたら、 ABAC が必要になった 2026年10⽉24⽇ 第2回 Snowflake OKINAWA User Group 株式会社ナウキャスト ⽻⼊達也 © 2025 Finatext Group © Finatext Group
2. 昔：⾒るだけのデータ基盤 ⼊⼝が少なく⻑く使われていたので、ロールとウェアハウスの分割で⼗分だった データを⼊れる⼈ Snowflake データを読みに来る⼝ 基盤チーム ⼈（エンジニア‧アナリスト） DWH テーブル Tableau マート ロールは⼈‧ツールごと。 ⼊⼝が少なく、⻑く使われた ウェアハウス（部署ごと） 統制で決めたいことは2つ 誰が何を⾒られるか 誰がいくら使ったか → ロールで答えられた → ウェアハウスを部署ごとに分ければ答えられた ©© Finatext Group Finatext Group
3. 今：作って動かすデータ基盤 Snowflake は「作って動かす」場所になり、⼊⼝とデータが両側から増えた データを⼊れる⼈ Snowflake データを読みに来る⼝ 基盤チーム ⼈（エンジニア‧アナリスト） 営業部 DWH テーブル 部署 DB 企画部 マート Workspace のファイル CoCo：⼈が AI と⼀緒に触る 管理部 … ウェアハウス（部署ごと） SPCS のアプリ Cortex Agent / MCP：エージェントが聞きに来る Tableau Streamlit アプリ × 多数：市⺠開発 AI 関数：SQL から AI を呼ぶ 統制で知りたいこと‧決めたいことは、昔から変わっていない 誰が何を⾒られるか 誰がいくら使ったか → ⼊⼝ごとのロールでは追えない → ウェアハウスだけでは分からない Streamlit in Snowflake‧SPCS は GA（2026-10 時点） ©© Finatext Group Finatext Group
4. 困ること①：権限 ⼊⼝ごとにロールを切ると、ロールが掛け算で増え、誰が何を⾒られるか追えなくなる ⼊⼝ 5 部署 × 3 機密区分 × 4 経路 ＝ 60 ロール ロール App A APP_A_ROLE App B APP_B_ROLE Agent X AGENT_X_ROLE Agent Y SALES_ROLE データ 営業 DB ※ 数字は例⽰ 顧客テーブル ＝ role explosion（ロールの爆発） 機密列 例：同じ営業部の⼈でも、エージェント経由のときは機密列を⾒せ たくない → ⼈でもロールでもなく、「経路」で変えたい CoCo PII_ROLE どの⼊⼝が、どのロールで、何を⾒られる？ 出典：NIST SP 800-162 §2.1（“role explosion”） ©© Finatext Group Finatext Group
5. 困ること②：コスト ウェアハウスで仕切るだけでは、AI のコストが⾒えず、⽌められない 今：コストの出どころが増えた これまで 営業部の WH コストの出どころ 人単位で見る場所（ ACCOUNT_USAGE） ウェアハウスの計算 QUERY_ATTRIBUTION_HISTORY CoCo SNOWFLAKE_COCO_USAGE_HISTORY Cortex Agents CORTEX_AGENT_USAGE_HISTORY AI 関数 CORTEX_AI_FUNCTIONS_USAGE_HISTORY サーバーレス機能・ SPCS ユーザー単位の列がない 営業部のコスト ウェアハウスの請求 ＝ 部署のコスト ウェアハウスでは⽌まらない ‧AI 関数はサーバーレスで動き、WH のクレジットに乗らない ‧Resource Monitor はウェアハウス専⽤ ‧CoCo の上限設定は、CoCo が書いた SQL 内の AI 関数を⽌めない 部署ごとのコストは、機能ごとのビューから⼈単位の利⽤量を集め、部署に⾜し上げないと出ない 参考：永井「Snowflake CoCo の隠れた AI SQL コスト問題まとめ」（Finatext Tech Blog、2026-06-29）∕ Snowflake Docs：Resource monitors、QUERY_ATTRIBUTION_HISTORY ©© Finatext Group Finatext Group
6. 転換：⼊⼝ではなく属性で考える ⼊⼝は増え続けるが、部署や機密区分の種類はそれほど増えない 増え続けるもの（⼊⼝） Streamlit Streamlit Agent Agent CoCo ロール ロール ロール SPCS 権限とコストを、こちらに紐づける 増えにくいもの（属性） 部署 機密区分 出どころ コストの按分‧⾏の絞り込み 列のマスキング 認定データかどうかの区別 アプリやエージェントが3本でも30本でも、属性は数個のまま。権限もコストも、この属性に紐づける ©© Finatext Group Finatext Group …
7. ABAC とは：⼊⼝はロール、中⾝は属性 ABAC でもロールは残る。⼊⼝はロールで、中⾝は⼈‧データ‧状況の属性で毎回判定する ⼊⼝：このテーブルに⼊れるか → ロールで判定（これまでどおり GRANT） 中⾝：どの⾏‧列が⾒えるか → 3つの属性の組み合わせで、毎回判定 ⼈の属性 データの属性 状況の属性 部署（ユーザーの部署タグ） 例：営業部 機密タグ‧部署の列 例：email 列＝機密 エージェント経由かどうか Agent identity（SERVICE_AGENT は GA） 同じ営業部の⼈（⼈の属性は同じ）でも、エージェント経由（状況の属性が違う）なら機密列を隠す ABAC ⾃体は新しくない（NIST SP 800-162、2014年）。前提が変わり、道具が揃ったので、今⾒合うようになった ©© Finatext Group Finatext Group
8. タグでできること：権限もコストも タグで、権限もコストも「把握する」から「制御する」まで扱える 把握する 制御する 権限 コスト 機密の在りかが分かる 誰がいくら使ったか分かる ⾃動分類で、機密の列にタグが付く ⼈‧ウェアハウスの部署タグで、部署ごとに集計 機密データの分類：GA Snowflake 提供のタグ（COST_CENTER など）：GA ⾒せ⽅を変える 使いすぎを⽌める 機密列のマスキング：GA 部署で⾏を絞る：Public Preview タグで、⼈ごとの AI 利⽤の上限を切り替える → ⼊⼝が増えてもロールを増やさずに済む → AI の使いすぎを、⼈ごとに⽌められる per-user quotas：GA 参考：「Snowflake per-user quotas による AI コスト管理の運⽤設計」（Finatext Tech Blog、2026-10-05）∕ 機能の状態は Snowflake Docs（2026-10 時点） ©© Finatext Group Finatext Group
9. うちではここから（途中経過） 部署 DB では、3つのタグから始めている タグ 付ける先 使い道 部署 人・ウェアハウス コスト集計と権限の判定 機密 データ 見せる・隠すの判定 出どころ データ 基盤チームが作った認定データか、部署が入れた データか 次の課題：データ側に寄せると、タグを誰が付けるかという分類の責任も部署に移る ©© Finatext Group Finatext Group
10. まとめ 増え続けるものに権限を紐づけない。 増えにくいものに紐づける。 Snowflake CoCo の隠れた AI SQL コスト問題まとめ：https://zenn.dev/finatext/articles/snowflake-coco-hidden-ai-cost Snowflake per-user quotas による AI コスト管理の運⽤設計：https://zenn.dev/finatext/articles/snowflake-ai-quota-escalation-tag ©© Finatext Group Finatext Group
11. ©© Finatext Group Finatext Group