【Snowflake】初心に帰って:Snowflake導入時における設計考慮事項
記事の概要
- 企業においてSnowflakeを導入する際に考えなければいけないことをまとめます
- 個人的なノウハウ/知見も加えています
❄️ 本件は Tech Fast Trackでもお話しさせていただいていますのでこちらでも確認可能です!
■ 検討項目とクラウド選択
Snowflake導入において考えるべき検討事項は、活用範囲/取り扱うデータによると思います.
一方、大抵の場合は下記の5項目を見ることになるのではないかと思います.
- インフラ・NW: 境界の防御
- ID・アクセス管理: 人・権限の統制
- データガバナンス: データの保護
- AIガバナンス: AIの監督
- コスト・可観測性: 持続可能性の確保
⭐️ ということで、上記5項目を元に見ていきます!
■ 前提 : クラウドの選択
Snowflake導入の際にはそもそもどのPublic Cloudを前提とするか選択しなければいけません.
- Amazon Web Services (AWS)
- Microsoft Azure
- Google Cloud
Snowflakeは全てのパブリッククラウド(AWS, Azure, Google Cloud)を選択可能です.
また、⭐️特定のクラウドを選択しても他クラウドのストレージを統合することが可能です.
正しく真のマルチクラウドです
■ Category 0: エディション選択
選べる4つのエディション:
- Standard
- Enterprise
- Business Critical
- Virtual Private
-
💡 おすすめ
- 一般的なガバナンスを利かせたいならば「Enterprise」
- Private Linkなどよりセキュアなガバナンスが必要であれば「Business Critical」
エディション早見表
| カテゴリ | 機能・要件 | Standard | Enterprise | Business Critical | Virtual Private |
|---|---|---|---|---|---|
| 基本機能 | SQL/全データ暗号化/MFA | ○ | ○ | ○ | ○ |
| ガバナンス | データマスキング・行アクセス制御他 / Access History(閲覧監査)等 | X | ○ | ○ | ○ |
| セキュリティ | PrivateLink (閉域網接続) / 顧客管理キー/PCI-DSS準拠等 | X | X | ○ | ○ |
| 可用性 | フェイルオーバー/復旧等 | X | X | ○ | ○ |
| インフラ | 環境の独立性 | 共有 | 共有 | 共有 | 専用環境 |
■ Category 1: インフラ/NW
Snowflakeは入口(インバウンド)と出口(アウトバウンド)をきめ細やかに制御できます.
-
入口の制御
-
Network Policy等を用いたアクセス制御
- 許可リスト: 会社拠点など信頼できるIPのみを許可
- ブロックリスト: 特定の攻撃元や不要なセグメントを遮断
-
階層的な適用
- アカウントレベル: 全ユーザーに適用
- ユーザーレベル: 特定の管理者やプログラム用IDのみより厳しい/または緩い制限を適用
-
Network Policy等を用いたアクセス制御
-
出口の制御
- 外部アクセス統合や API統合等を用いたアクセス制御
インフラ/NW 早見表
| レイヤー | 主要機能 | 目的 |
|---|---|---|
| 1. 境界防御 | Network Policy (IP / Public Cloud Private Endpoint制限) | 許可された拠点(オフィスやVPN) 以外からのアクセスの遮断による外部不正アクセスの排除 |
| 2. 通信経路 | Private Link (閉域網接続) | 自社ネットワークと Snowflakeを直結することによる外部攻撃リスクの排除 |
| 3. 出口制御 | External Network Access | Snowflake内部(Python/SQL)から通信できる外部サイトの制限によるデータの不正持ち出し防止 |
| 4. ストレージ連携 | Storage Integration | クラウドストレージ(S3等)接続用認証情報露出の防止 |
■ Category 2: ID/アクセス管理
「誰が」「どの権限で」「どのデータに」アクセスできるかを、最小権限の原則に基づいて制御します.
認証方式は多種多様であり、アクセス制御の基本は RBAC と UBAC です.
-
認証
- フェデレーション認証 (SSO)
- 多要素認証(MFA)
- キーペア認証
- Personal Access Token
- パスワード: MFA必須 (パスワードのみでサインイン不可)
-
認可 (Role-Based Access Control)
- システム定義ロール
- カスタムロール
-
認可 (User-Based Access Control)
-
USERに権限を直接付与
-
RBAC ではアプリケーションロールなど他にも概念はありますが今回は省きます
ID/アクセス管理 早見表
| レイヤー | 主要機能 | 目的 |
|---|---|---|
| 1. 認証 | SSO (SAML), OAuth, MFA | 外部ID基盤との連携および多要素認証による統一された本人確認の実施 |
| 2. ポリシー | Authentication Policy, Session Policy | 接続元や認証方式の制限、およびセッション維持期間の定義によるアクセス状況の統制 |
| 3. 自動化 | SCIM | ID基盤側のユーザー・グループ情報の変更同期、アカウント運用の自動化 |
| 4. 認可 | Role, Database Role | 役割ベースの権限管理(RBAC)、DB単位の権限パッケージ化による最小権限に基づくアクセス認可 |

■ Category 3: データ・ガバナンス
Roleに大きく分けて下記3つの要素を設定します.
- 対象(どこを): どのデータベースやテーブルにアクセスさせるか
- 操作(何を): 「見るだけ(SELECT)」か、「追加・修正(INSERT/UPDATE)」もできるようにするか
- 制約(どんなルールで): マスキングや行フィルタを適用し、どのようにデータを見せるか
データ・ガバナンス 早見表
| レイヤー | 主要機能 | 役割・目的 |
|---|---|---|
| 1. 発見・分類 | Object Tagging, Sensitive Data Classification | PII(個人情報)の自動検出と機密タグ付与による可視化と管理を自動化 |
| 2. データ保護 | Dynamic Data Masking, Row Access Policy | 権限に応じたカラムの伏せ字化および行単位のフィルタリングによる動的なアクセスの制御 |
| 3. プライバシー保護 | Projection / Aggregation Policy, Differential Privacy | 特定列の露出制限、集約結果のみの表示、数学的ノイズ付与による個人の再識別リスクの排除 |
| 4. 品質・可観測性 | Data Quality Monitoring, Data Lineage | データの鮮度・異常の監視および、上流から下流へのデータ流転の可視化による信頼性の担保 |
| 5. 監査・管理 | Access History, Trust center | 証跡管理と、ガバナンス状況を俯瞰する一元的なモニタリング |
■ Category 4: AIガバナンス
「AIをいかに安全にビジネスへ組み込むか(AI Safety)」「生成AI特有の法的リスクをどう回避するか」を見ていきます.
まず前提として、Snowflakeはそもそも 「顧客データでモデルを再学習しない」「データの中身を見ない」 としています
また、下記のような機能を提供しています.
- 細かなアクセス/利用制御:
- モデル毎のRBAC制御
- 国内・特定地域等でのデータ流通制限
- モデルのアウトプットに対する予防的ガードレールの設定
※SnowflakeはISO 42001 (AIガバナンスの新基準)も取得済み
AIガバナンス 早見表
| レイヤー | 主要機能 | 役割・目的 |
|---|---|---|
| 1. データ境界 | Cortex AI | データを外部APIに送らずSnowflakeの管理領域内で推論を完結させ、データ流出を防止 |
| 2. AIガードレール | Cortex Guard | LLMへの入力(プロンプト)および出力に含まれる有害コンテンツやPIIを検知・遮断 |
| 3. モデル・権限管理 | Model RBAC | どの職務(Role)がどのLLMモデル (Llama, Mistral等)を使用できるか制御 |
| 4. 可観測性 | AI系Usage History | 「誰がどのデータを使ってどのくらいAIを実行したか」を記録 |
| 5. リーガル・信頼性 | AI Trust and Safety ※規約 | 顧客データが再学習に利用されないことを保証し、知的財産権や法規制上のリスクを排除 |
■ Category 5: コスト・運用管理
「従量課金」というリスクを管理しつつ、システムの透明性(いつ・誰が・何をしたか)を確保します
-
「自動化」によるコスト増加の抑制:
- Auto-suspend を最短(例:60秒)に設定
- Resource Monitor / Budget を設定し「予算の80%で通知、100%でWH停止」といったガードレールを敷く / 施策毎の予算を設定
-
「タグ」による責任の明確化:
- Object Tagging を活用し、すべてのウェアハウスやデータベースに「部署名」や「プロジェクトコード」のタグを付与
コスト・運用管理 早見表
| レイヤー | 主要機能 | 役割・目的 |
|---|---|---|
| 1. コスト実行制御 | Resource Monitor, Budgets, Auto-suspend/resume | 予算超過時の自動停止・通知、およびリソースの自動休止により使いすぎを防止 |
| 2. コスト可視化 | Account Usage, Information Schema (Usage Views) | クレジット消費やストレージ利用を分析し、データ活用の投資対効果 (ROI)を最適化 |
| 3. 運用透明性/監査 | Access History, Query Profile, Login History | 「誰がどのデータに、どのような効率で触れたか」を可視化し監査 |
| 4. 費用按分/組織管理 | Object Tagging (Cost Center Tags) | 部署やプロジェクト単位でコストをタグ付けし、部門間での正確な費用按分を実現 |
まとめ
強固なガバナンスが構築されているからこそ、データ・AI活用は加速します!
- 「迷わず使える」: どのデータが安全で、どのデータが機密かがわかる
- 「即座に使える」: 物理的なデータコピーや加工を待たず、ポリシーによって加工されたデータを即座に分析できる
- 「安心して挑戦できる」: 生成AIを使っても、データが学習に使われたり流出したりする心配がない
みなさん強固なガバナンスを武器に、Snowflakeを使い倒しましょう!!!
Snowflake データクラウドのユーザ会 SnowVillage のメンバーで運営しています。 Publication参加方法はこちらをご参照ください。 zenn.dev/dataheroes/articles/db5da0959b4bdd
Discussion