Microsoft Sentinel×Snowflake：Codeless Connector Framework（CCF）版の課題・GA動向・テーブル追加の現実解と実装ガイド

Microsoft Sentinel に Snowflake をつなぐ最新の選択肢は「Codeless Connector Framework（CCF）版」ですが、まだプレビュー段階で、旧 Function ベースは非推奨。現場では「いつ GA になるのか」「監視したいテーブルが拾えない」「設定手順が見つけづらい」という悩みが起きがちです。本稿は、その3点を軸に、意思決定と実装の両面で“いま出来る最善策”をまとめました。

Snowflake コネクター（CCF 版）の現在地と前提

Microsoft Sentinel の Codeless Connector Framework（旧称 CCP）は、関数アプリの運用を不要にし、ポーリング・変換・ヘルス監視までをサービス側に持たせた「フル SaaS」型のコネクター技術です。Snowflake 向けにも CCF 版コネクターが提供されていますが、執筆時点では「プレビュー」です。プレビュー機能は SLA 対象外、仕様やスキーマが断りなく変わる可能性がある前提で評価・運用判断を行う必要があります。

よくある疑問（Q）と先に結論（A）

Q1. GA はいつ？ — A: 公式に期日未公表。最新情報は Microsoft Sentinel の「What’s new（新着情報）」で追跡。
Q2. 監視対象に含まれない Snowflake のテーブルを追加できる？ — A: できません（ユーザー側でリストを編集する機能は未提供）。要望は Azure フィードバックポータルや Sentinel ポータルの「フィードバック」から提出。
Q3. 設定手順はどこ？ — A: Sentinel の「Content Hub」に Snowflake ソリューション（プレビュー）があり、そこからコネクターを開いて設定します。検索語は “Snowflake（Preview）” が見つけやすい。

課題ごとの現実解（最新版）

課題	解決策・現時点の対応	補足情報
GA 時期が不明	公式アナウンス待ち。更新は Sentinel の「What’s new」に掲載されるため、運用判断のチェックポイントとして定期確認する。	プレビューは SLA 外・仕様変更の可能性あり。変更検知のために検証環境での継続テストを推奨。
監視対象外テーブルの追加	ユーザー側での追加不可。拡張要望は Azure フィードバックポータル、または Sentinel ポータルの「フィードバック」へ。	サポート契約がある場合は Microsoft サポート経由で要望のエスカレーションも可。
設定手順が見つけづらい	Content Hub で「Snowflake（Preview）」を検索→ソリューションをインストール→データコネクター画面から設定。	Defender ポータル側でも Content Hub は「Sentinel > Content management > Content hub」に配置。

Snowflake コネクター（CCF 版）で取り込まれる主なログ

Snowflake SQL API を経由して、Snowflake SNOWFLAKE.ACCOUNT_USAGE 配下の代表的なビュー由来のイベントが取り込まれます。下表は用途イメージです。

ログ（ビュー）	主な活用シナリオ	注意点
LOGIN_HISTORY	ログイン可視化、異常地点・異常時間帯の検出、多要素失敗の観測	アカウント単位。位置情報の解釈や NAT 越しの相関は補助情報が必要になりがち。
QUERY_HISTORY	高負荷・長時間・大量スキャンのクエリ検出、深夜帯の異常実行監視	最大 45 分程度の遅延があるためリアルタイム検知には不向き。
GRANTS_TO_USERS / GRANTS_TO_ROLES	権限ドリフト監査、過剰付与検出（RBAC 基準の逸脱）	ロール付与の履歴と現状の差分を見ると効果的。
LOAD_HISTORY	データロードの失敗率や遅延の監視（パイプライン健全性）	バルクロードのバッチ特性を考慮し閾値を調整。
MATERIALIZED_VIEW_REFRESH_HISTORY	MV リフレッシュ失敗の検出、負荷集中の可視化	ワークロードの計画変更時に増減が顕著に出る。
ROLES / USERS / TABLES / TABLE_STORAGE_METRICS	資産台帳・容量増加の傾向監視、棚卸し（棚卸しとクリーンアップ）	ACCOUNT_USAGE のデータは最大 2〜3 時間の遅延を伴うものがある。

※ ACCOUNT_USAGE のビューは、一般に 45 分〜3 時間の更新遅延や 1 年の保持などの性質があるため、運用監視の粒度設定に反映してください。

「プレビューを使う／待つ」以外の選択肢（実務オプション）

1) CCF で自社専用コネクターを作る（私設 CCF）

CCF は ARM テンプレートと UI/ポーリング定義（connectorUiConfig と pollingConfig）からなる構造で、Snowflake SQL API への RestApiPoller を記述すれば、既定リストにないビュー（例：ACCESS_HISTORY）を含むコネクターを自社用にデプロイできます。メリデメは以下。

メリット：Function/Logic Apps の運用不要、ヘルス監視・接続 UI を Sentinel に統合、DCR 変換で取り込み時のスキーマ成形も可能。
デメリット：テンプレート作成・保守は自社責任。プレビュー API/仕様変更の影響を自前で吸収する必要。

2) Logs Ingestion API（DCR）でカスタム取り込み

既定コネクターでは拾えないテーブルは、Snowflake から取得した JSON を Azure Monitor の Logs Ingestion API で Log Analytics に送る方法が堅実です。DCE（Data Collection Endpoint）＋DCR（Data Collection Rule） を定義し、取り込み時に KQL 変換でスキーマを正規化します。旧 HTTP Data Collector API は長期的に非推奨化の方向であるため、新規は Logs Ingestion API を選ぶのが定石です。

3) 一時回避：外部ステージ・バッチ転送＋AMA カスタムログ

Snowflake から外部ステージ（例：Azure Storage）へ CSV/JSON をエクスポートし、Azure Monitor Agent（AMA）のカスタムログで取り込む手もあります。構成は単純ですが、ファイル到着の遅延や再送制御の実装コストに注意が必要です。ストリーミング性が欲しい場合は不向きです。

Snowflake 側の最小権限設計（サービスユーザーの作り方）

コネクターが参照するのは主に SNOWFLAKE.ACCOUNT_USAGE のビュー群です。ACCOUNTADMIN 付与は避け、IMPORTED PRIVILEGES を用いた最小権限ロールを推奨します。

-- アカウント管理者で1回だけ実施
use role ACCOUNTADMIN;

-- Sentinel 取り込み用ロール
create role if not exists SENTINEL_INGESTOR;

-- SNOWFLAKE データベースのインバウンド共有に対するインポート権限
grant imported privileges on database SNOWFLAKE to role SENTINEL_INGESTOR;

-- 必要に応じて MONITOR USAGE 等を別ロールで補完（不要なら省略）
-- grant monitor usage on account to role SENTINEL_INGESTOR;

-- サービスユーザー作成とロール付与
create user if not exists SVC_SENTINEL password = '<強固なパスワード>' must_change_password = false;
grant role SENTINEL_INGESTOR to user SVC_SENTINEL;

上記により、ACCOUNT_USAGE の代表的なビュー（LOGIN/QUERY/GRANTS/LOAD 等）への SELECT が可能になります。キー/証明書や OAuth を使った SQL API 認証を採る場合は、その方式に応じたクレデンシャルを準備してください。

Sentinel 側の導入手順（Content Hub から）

Defender ポータルで Microsoft Sentinel > Content management > Content hub を開く。
検索バーで “Snowflake” を入力し、プレビュー タグ付きソリューションを選択してインストール。
インストール後、Data connectors から Snowflake（Preview） を開く。
Snowflake のアカウント識別子、ユーザー/パスワードまたはトークン、（必要に応じて）ロールや対象データベース/スキーマなど、コネクター UI の指示に従って接続を構成。
ワークブック・アナリティクスルール・ハンティングクエリが同梱されている場合は、必要なものだけ有効化（誤検知を避けるため、まず Audit/Info レベルから開始）。

ヘルス監視と運用可観測性（つながっているかを測る）

プレビュー運用では「つながっていることを継続的に確認するしくみ」が鍵です。Sentinel の監査・ヘルス機能を有効化し、コネクターの成否・失敗イベントをログ化しておきます。

// データコネクターの最新状態を把握（SentinelHealth）
SentinelHealth
| where Category == "Data Connectors"
| where ResourceDisplayName has "Snowflake"
| summarize LastEvent = arg_max(TimeGenerated, Status, OperationName, ResultDescription)
          by ResourceId
| project TimeGenerated=LastEvent.TimeGenerated, ResourceId, Status=LastEvent.Status,
          Operation=LastEvent.OperationName, Detail=LastEvent.ResultDescription

// 直近24時間の失敗イベントと頻度
SentinelHealth
| where Category == "Data Connectors"
| where ResourceDisplayName has "Snowflake"
| where TimeGenerated >= ago(24h) and Status != "Succeeded"
| summarize Failures = count() by OperationName, bin(TimeGenerated, 1h)
| order by TimeGenerated desc

正規化（パース）と KQL レシピ

Snowflake CCF コネクターは、環境によっては汎用列（例：Data）に JSON 文字列として行データを格納する挙動があり、可視化・検知の前処理として「パース関数」または KQL 上での parse_json() が有効です。下記は汎用レシピです（列名は実データに合わせて調整）。

// 例：QUERY_HISTORY 相当の行をパース
let SnowflakeRaw = () {
  // 実テーブル名は環境により異なるため "Snowflake" を含むテーブルを対象に調整
  union isfuzzy=true
    (Snowflake_CL),
    (SnowflakeQueryHistory_CL)
};
SnowflakeRaw
| extend J = parse_json(Data)
| project TimeGenerated,
          QueryId = tostring(J.QUERY_ID),
          UserName = tostring(J.USER_NAME),
          Warehouse = tostring(J.WAREHOUSE_NAME),
          Database = tostring(J.DATABASE_NAME),
          Schema = tostring(J.SCHEMA_NAME),
          BytesScanned = tolong(J.BYTES_SCANNED),
          RowsProduced = tolong(J.ROWS_PRODUCED),
          QueryText = tostring(J.QUERY_TEXT),
          ErrorCode = tostring(J.ERROR_CODE),
          ErrorMessage = tostring(J.ERROR_MESSAGE)
| where ErrorCode !~ "" // 失敗クエリを抽出
| order by TimeGenerated desc

// 例：LOGIN_HISTORY 相当から異常ログインを抽出（深夜帯×海外）
let nightHours = dynamic([0,1,2,3,4,5]);
SnowflakeRaw
| extend J = parse_json(Data)
| where tostring(J.EVENT_TYPE) == "LOGIN"
| extend UserName = tostring(J.USER_NAME),
         ClientIP = tostring(J.CLIENT_IP),
         Result = tostring(J.IS_SUCCESS),
         Country = tostring(J.CLIENT_REGION),
         Hour = datetime_part("Hour", TimeGenerated)
| where Result == "FALSE" or (Hour in (nightHours) and Country !in~ ("JP","Unknown"))
| summarize Attempts=count(), Failed=countif(Result=="FALSE") by UserName, Country, ClientIP, bin(TimeGenerated, 1h)
| order by TimeGenerated desc

※ 実テーブルや列名はバージョン・環境により変わるため、最初に getschema で列構造を確認し、関数化（ワークスペース関数）しておくと再利用性が上がります。

「監視したいテーブルがリスト外」のときの打ち手

正式要望の提出：Azure フィードバックポータル、または Sentinel ポータルの「フィードバック送信」から、必要なビューとビジネス理由（検知ユースケース・監査要件など）を明記して依頼。
短期の運用回避策：自社用 CCF コネクター、または Logs Ingestion API で目的のビュー（例：ACCESS_HISTORY）を取り込み、プレフィックスを合わせたカスタムテーブル（例：Snowflake_AccessHistory_CL）に格納。
正規化の共通化：同梱パーサーと整合する形で、自前取り込み分も同じ列名・型で整える（ダッシュボードや検知ロジックが流用可能になる）。

プレビュー運用のガードレール（リスク最小化）

二系統運用：本番は「最低限の検知」に絞り、詳細監視は検証ワークスペースで先行評価。ルールは Feature Flag 的に段階的有効化。
スキーマ変動に備える：取り込み直後に DCR 変換で 列名を固定化。上流変更があっても下流のダッシュボード/ルールの破壊を回避。
遅延を踏まえた閾値：ACCOUNT_USAGE の 45 分〜3 時間の遅延を考慮し、即時性が必要な検知は他ソース（IdP、ネットワーク等）と多層化。
ヘルス監視の常時化：SentinelHealth/SentinelAudit を常時クエリし、失敗率上昇でアラート。週次で「取り込み量の異常値」もレポート化。
ロールバック準備：更新で不具合が出た場合に、即座に前バージョンのテンプレート/DCR に戻せる運用手順（IaC）を用意。

コストと保持期間の設計ヒント

取り込み量の見積り：1 日あたりの行数 × 1 行平均サイズ で GB/日を算出。QUERY_HISTORY はクエリ数依存、LOGIN_HISTORY はユーザー数とアクセス頻度に比例。
保持と階層：Sentinel のテーブル管理で、分析層（高価・短期）とデータレイク層（安価・長期）を使い分けると TCO 最適化に効く。
要約ルール：生ログを即座に要約テーブルに集約（例：ユーザー×日×失敗回数）することでクエリコスト・保持コストを抑制。

よくある落とし穴と対策

「データが来ない」＝即障害ではない：ACCOUNT_USAGE の自然遅延や Snowflake 側のタイムゾーン差異を先に疑う。加えて、最近のスキーマ変化がないかも確認。
過剰権限の安易な付与：ACCOUNTADMIN をサービスユーザーに与えない。IMPORTED PRIVILEGES を基本に、必要最小で運用。
大量の無料ルール有効化：同梱の検知テンプレートを一括で有効化すると誤検知やコストが増える。段階的かつスコープ限定で有効化。

運用チェックリスト（導入〜安定運用）

フェーズ	やること	完了基準
準備	サービスユーザー・ロール作成（IMPORTED PRIVILEGES）、Secret 管理方式の決定	最小権限で ACCOUNT_USAGE の主要ビューが SELECT 可能
導入	Content Hub から Snowflake（Preview）インストール、接続設定	コネクター状態が「Connected」、同梱ワークブックで可視化
検証	取り込み遅延の計測、スキーマ確認、パーサー/関数の整備	KQL 関数で列名固定の正規化完了
運用	ヘルス監視・失敗率監視、週次レポート、検知の段階的有効化	失敗時の通知と一次対処（再試行/ロールバック）が 30 分以内に実行可能
改善	足りないテーブルの要望提出、Logs Ingestion API の並行検討	要望のトラッキングと代替導線（私設 CCF / DCR）が用意済み

質問への回答を改めて整理

GA 時期は未公表。公式の新着情報を監視しつつ、プレビュー前提の運用ガードレールを敷く。
テーブル追加は不可。要望はフィードバック経由で提出。短期的には私設 CCF や Logs Ingestion API を使って補完。
設定手順は Content Hub。検索で “Snowflake（Preview）” と入力、ソリューションをインストールしてからコネクターを構成。

サンプル：最低限の可観測性ダッシュボード指標

コネクター健全性：直近 24 時間の 成功率（Succeeded / 全試行）、連続失敗回数、最後の成功時刻。
取り込み量：ログ種別ごとの イベント数/日 と 7 日移動平均の偏差。
検知品質：誤検知率（抑制ルール前提）、MTTD/MTTR のトレンド。

運用メモ（フィールドで役立つ小ネタ）

ACCOUNT_USAGE は「ドロップ済みオブジェクトも記録」するため、資産棚卸しに強い一方、現状の権限状態だけを見たい場合は INFORMATION_SCHEMA の方が早い。
QUERY_HISTORY の BYTES_SCANNED と ROWS_PRODUCED は検知にもコスト最適化にも効く神列。まずはこれらのプロファイル化から。
遅延と時刻解像度の違いで「ゼロ件」に見える時間帯がある。固定のクエリではなく「時刻ウィンドウ可変」のクエリをヘルスチェックに使うと良い。

結論

Snowflake コネクター（CCF 版）は、旧 Function ベースの運用負荷を取り払い、SaaS 的に統合された“次の当たり前”を提示しています。ただし GA 前の今は、（1）ヘルス監視の常時化、（2）スキーマ固定化、（3）不足テーブルの代替導線（私設 CCF / Logs Ingestion API） の 3 点を押さえたうえで段階的に組み込むのが安全策です。要望は迷わずフィードバックに投げ、プロダクトの進化と歩調を合わせましょう。

要点まとめ

GA 時期は公式未公表。最新動向は「What’s new」を定期確認。
プレビュー版の監視対象リストはユーザー編集不可。追加はフィードバック提出を。
設定手順は Content Hub の Snowflake（Preview）ソリューション経由。
不足分は「私設 CCF」または「Logs Ingestion API（DCE/DCR）」で補完。
ACCOUNT_USAGE の自然遅延（45 分〜3 時間）を踏まえ、検知は多層化・閾値調整。
ヘルス監視（SentinelHealth/SentinelAudit）とスキーマ固定化で運用を安定化。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Sentinel×Snowflake：Codeless Connector Framework（CCF）版の課題・GA動向・テーブル追加の現実解と実装ガイド

Snowflake コネクター（CCF 版）の現在地と前提

よくある疑問（Q）と先に結論（A）

課題ごとの現実解（最新版）

Snowflake コネクター（CCF 版）で取り込まれる主なログ

「プレビューを使う／待つ」以外の選択肢（実務オプション）

1) CCF で自社専用コネクターを作る（私設 CCF）

2) Logs Ingestion API（DCR）でカスタム取り込み

3) 一時回避：外部ステージ・バッチ転送＋AMA カスタムログ

Snowflake 側の最小権限設計（サービスユーザーの作り方）

Sentinel 側の導入手順（Content Hub から）

ヘルス監視と運用可観測性（つながっているかを測る）

正規化（パース）と KQL レシピ

「監視したいテーブルがリスト外」のときの打ち手

プレビュー運用のガードレール（リスク最小化）

コストと保持期間の設計ヒント

よくある落とし穴と対策

運用チェックリスト（導入〜安定運用）

質問への回答を改めて整理

サンプル：最低限の可観測性ダッシュボード指標

運用メモ（フィールドで役立つ小ネタ）

結論

要点まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Sentinel×Snowflake：Codeless Connector Framework（CCF）版の課題・GA動向・テーブル追加の現実解と実装ガイド

Snowflake コネクター（CCF 版）の現在地と前提

よくある疑問（Q）と先に結論（A）

課題ごとの現実解（最新版）

Snowflake コネクター（CCF 版）で取り込まれる主なログ

「プレビューを使う／待つ」以外の選択肢（実務オプション）

1) CCF で 自社専用 コネクターを作る（私設 CCF）

2) Logs Ingestion API（DCR）でカスタム取り込み

3) 一時回避：外部ステージ・バッチ転送＋AMA カスタムログ

Snowflake 側の最小権限設計（サービスユーザーの作り方）

Sentinel 側の導入手順（Content Hub から）

ヘルス監視と運用可観測性（つながっているかを測る）

正規化（パース）と KQL レシピ

「監視したいテーブルがリスト外」のときの打ち手

プレビュー運用のガードレール（リスク最小化）

コストと保持期間の設計ヒント

よくある落とし穴と対策

運用チェックリスト（導入〜安定運用）

質問への回答を改めて整理

サンプル：最低限の可観測性ダッシュボード指標

運用メモ（フィールドで役立つ小ネタ）

結論

要点まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

1) CCF で自社専用コネクターを作る（私設 CCF）

コメントするコメントをキャンセル