Microsoft 365 の可視性を解き放つ: 既定の SIEM コネクタで見落とすリスク

By Mirko Peters · 2026-08-11

ブログへようこそ。Microsoft 365を利用する組織でセキュリティ運用を担当している方は、根拠の乏しい安心感を抱いている可能性があります。「en…

Automatically translated with AI from the original post. Read the English original

ブログへようこそ。Microsoft 365 を利用する組織でセキュリティ運用を担当している方は、おそらく安心しきっているのではないでしょうか。SIEM の既定の M365 コネクタで「有効にする」をクリックし、ログが流れていることを確認して、コンプライアンスのチェックボックスにもチェックを入れた。しかし、本当に保護されているのでしょうか。不都合な真実として、標準状態の SIEM コネクタは大きな死角を残すことが多く、攻撃者が好んで活動する高度なクラウドワークロードを丸ごと取りこぼしています。この重要なテーマを十分に理解するには、関連ポッドキャストエピソードSend Critical Microsoft 365 Logs to Your SIEMもぜひお聴きください。このエピソードでは、これらのギャップを詳しく解説しています。

本記事では、既定の構成がなぜ機能しないのか、死角がどこに潜んでいるのか、そして分析担当者がそのまま活用できる高シグナルな検知を生み出す、回復力があり費用対効果の高い取り込みパイプラインをどう構築するかを掘り下げていきます。

主要な SIEM に共通する Microsoft 365 の死角

Microsoft Sentinel、Splunk、QRadar のいずれを使っている場合でも、既定の取り込みテンプレートは通常、基本的な Azure Active Directory のサインインと、簡易的な Office 365 のアクティビティログに重点を置いています。これは最低限の範囲はカバーしていますが、重要なワークロードは完全に無防備なままです。主要な SIEM プラットフォームでは、次のような大きな死角が繰り返し見られます。

• Exchange: 既定のコネクタは、所有者以外によるメールボックスへのアクセス、不審な受信トレイのルールや転送設定の作成、SendAs や SendOnBehalf の操作、突然のメールボックスのアクセス許可変更を見落としがちです。
• SharePoint と OneDrive: ファイルのダウンロードは見えているかもしれません。しかし、外部リンクや匿名リンクの作成と利用、ファイルの再共有、特権的なサイトのアクセス許可変更は見えているでしょうか。
• Teams: 攻撃者はオープンな場での共同作業を好みます。既定の構成では、SharePoint がバックエンドの チャネル を介した外部共有、メッセージの削除や編集、会議ポリシーの変更、不正なアプリのサイドロードをほとんど記録しません。
• Power Platform: ローコード/ノーコード環境の普及により、見えにくいリスクが生まれています。フローやアプリの作成が急増する、Outlook、Teams、任意の HTTP コネクタといったリスクの高いコネクタが使用される、Data Loss Prevention (DLP) ポリシーの回避といった事象が、しばしば除外されています。
• 秘密度と DLP: 秘密度ラベルの適用や削除イベント、ポリシーの一致、手動による上書きは、明示的に対象としない限り、ほぼ完全に欠落していることが多くあります。
• Azure AD のコンテキスト: リスクのあるサインイン、条件付きアクセスの結果、デバイスや地理的な異常といった重要な文脈が、標準的なクエリから抜け落ちていることがよくあります。

根本原因: 重要なイベントが欠落する理由

これらの重要なテレメトリストリームが欠落するのはなぜでしょうか。偶然に起こることはめったにありません。むしろ、プラットフォームプロバイダーと企業の購入者の双方が行った、アーキテクチャ上および商業上の選択の結果です。

第一に、ライセンスの制限が大きな役割を果たしています。高度な監査、詳細な Exchange のテレメトリ、豊富な SharePoint のイベントログ記録は、Microsoft 365 E5 のような上位のライセンスや、Advanced Audit のアドオンの背後に置かれていることがよくあります。テナントが E3 レベルである場合、それらのイベントはそもそも生成されず、保持もされていません。

第二に、コネクタの対象範囲の制限がデータ収集を制約します。標準のコネクタは通常、基本的な「OfficeActivity」ストリームのみを取得し、高度なワークロードは無視します。第三に、API のスループット制限とバッチ処理の遅延により、ピーク時にネイティブのコレクターが処理しきれず、ログが欠落することがあります。第四に、パーサーのギャップがあると、生の JSON が SIEM に届いていても、マッピングされていないフィールドや暗黙のスキーマ変更によって、意味のわからないデータに見えてしまいます。最後に、コストを気にするチームが実施するコスト管理により、セキュリティ上の影響を理解しないまま、ノイズの多いカテゴリが静かに除外されてしまいます。

死角を作らずにコストを管理する

「完全な」Microsoft 365 の可視性を取り込むことに対する最大の反論の一つは、コストです。大規模な M365 テナントで生成されるすべてのログを取り込むと、セキュリティ用のストレージ予算を使い果たしかねません。しかし、破産するか死角を抱えるかの二択にする必要はありません。重要なのは、取り込む量を減らすことではなく、賢くフィルタリングすることです。

まず上流でフィルタリングを行います。取り込みの仕組みを設定し、New-InboxRule、Add-MailboxPermission、匿名リンクの作成や利用のイベントなど、シグナルの強い操作だけを取り込むようにしてください。SharePoint のバージョン保存のような、価値の低いバックグラウンドイベントは、SIEM に届く前に重複排除と集約を行いましょう。

階層型のストレージ戦略を実装します。アクティブな調査に使うホットストレージは 30～60 日程度に抑え、コールドストレージやアーカイブは、コンプライアンス要件の保持期間に合わせて安価なオブジェクトストアへ振り分けます。さらに、新しいストリームを有効にする前にボリュームを試算してください。ソース別に 1 日あたりのギガバイト数を予測し、業務のピーク、四半期ごとの監査、法的開示の期間に備えて、その見積もりを 2 倍にしておきます。

回復力のある取り込みパイプラインの設計

直接ポーリングする脆弱なコネクタに頼ると、セキュリティインシデントが深刻な局面で、アラートを取りこぼす原因になります。そこで、スロットリングを考慮した回復力のあるパイプラインを設計しましょう。堅牢なパターンは次のとおりです。

• ソース: Microsoft 365 監査ログ（Unified Audit Log）、Advanced Audit、Azure AD のサインインとリスクログ、Microsoft Information Protection（MIP）、DLP アラート、Microsoft Defender のセキュリティアラートからデータを取得します。
• トランスポート: Graph API または Management API からのデータを、SIEM に転送する前に Azure Event Hub（バッファとリプレイの仕組みとして機能）へルーティングします。
• 処理: ランディングゾーンでデータを正規化し、エンリッチします。ユーザーのコンテキスト、部門フラグ、VIP の指定、デバイスの状態、地理情報を追加します。
• ガバナンス: 日次の完全性チェック、429 レート制限に対するバックオフハンドラー、スキーマ変更の監視、デッドレターキューのアラートを実装します。

アナリストが使える形にするための正規化とエンリッチメント

生の M365 ログは、ネストされた JSON オブジェクトや、ワークロードごとに異なるフィールド命名規則が混在しており、扱いにくいものです。生データをそのままティア 1 のアナリストに渡すと、脅威のトリアージではなく、ペイロードの解読に勤務時間の半分を費やすことになってしまいます。

取り込みの時点で主要フィールドを平坦化します。対象フィールドは、Actor、Target、Action、ResourcePath、LinkType（匿名、組織、特定のユーザー）、ExternalRecipient、LabelName です。これらを Azure Monitor の Common Security Incident Model（ASIM）や Elastic Common Schema（ECS）などの統一スキーマにマッピングすると、ワークロードをまたいだ検出エンジニアリングが無理なく行えるようになります。最後に、HR データ（役割、雇用形態、部門）、VIP リスト、パートナーの許可リスト、デバイスのコンプライアンス状態、秘密度分類でイベントをエンリッチします。

今すぐ展開すべき高シグナルの検出ルール

パイプラインが稼働し、データの正規化ができたら、高度な攻撃者の振る舞いを実際に検出できる、シグナルの強い検出ルールを展開できます。すぐに構築すべき基本的な検出ルールは 8 つあります。

• メールボックスの情報持ち出し: 新しい受信トレイルールで、外部へ転送する、または メッセージを RSS フィードや迷惑メールフォルダーへ移動するものを検出します。これが、新しい地理的な場所や未知のデバイスからのサインインの 1 時間以内に発生した場合に対象とします。
• ステルスアクセス: VIP アカウントのメールボックスに対して、所有者以外がアクセスしたものを検出します。その直前 24 時間以内に Add-MailboxPermission のイベントが発生している場合にフラグを立てます。
• SharePoint の情報漏えい: 秘密度ラベルが「Confidential」または「Restricted」のファイルに作成された、匿名リンクや「特定のユーザー」向けの共有リンクについてアラートを出します。
• リンクの悪用: 新しく作成された共有リンクから、新しい IP アドレスまたは ASN を発信元として、15 分の時間枠内に大量の外部ダウンロードが発生しているものを検出します。
• Teams の横展開: ファイルが外部と共有され、同じユーザーが 2 時間以内に外部ゲストをチームへ追加するケースを捕捉します。
• Power Automate の悪用: 開発者ではないアカウントによる 1 日あたりのフロー作成が、3 件以上に急増している場合にフラグを立てます。特に HTTP コネクタや Outlook コネクタを使用しているものが対象です。
• 権限の肥大化: 同じ機密性の高いワークスペースまたはサイトに対して、メンバーや管理者ロールの追加と削除が 24 時間以内に繰り返し行われていないかを追跡します。
• 古いデータによる誤判断: 経営層や財務部門のコンテンツのデータセットが、2 回以上の更新サイクルにわたって更新に失敗した場合に検出します。古いデータに基づいて経営陣が判断してしまうことを防ぎます。

30 日間のギャップ解消実装計画

M365 の可視性の課題を解決するのに、1 年もかける必要はありません。可視性のギャップを、わずか 30 日で体系的に埋めることができます。

• 1 週目: 必要に応じて Advanced Audit を有効にし、現在の SIEM コネクタを棚卸しして、不足しているイベントカテゴリを洗い出します。
• 2週目: Event Hubのパイプラインを構築します。Unified Audit Logs、Advanced Audit、Azure AD、Defenderのテレメトリを経路設定し、上流のフィルターを実装します。
• 3週目: データストリームを正規化して拡充し、直近30日分の重要なログをバックフィルします。そのうえで、前述の7つの高シグナルな検出ルールを、適切な抑制期間とともにデプロイします。
• 4週目: 残っているノイズを除去し、保持階層を調整してコストを最適化します。完全性モニターを追加し、メールボックスルール、外部共有、フローの急増を検証するパープルチーム型の机上演習を実施します。

効果を証明するためのエグゼクティブKPI

経営層から、パイプライン改善に費やしたセキュリティ予算は価値があったのかと問われたとき、成果を証明する指標が必要です。以下のエグゼクティブKPIを追跡してください。

• カバレッジ: 対象となるM365のイベントファミリーのうち、正常に取り込みおよび解析されたものの割合(目標95%以上)。
• スピード: M365関連インシデントの平均確認時間(MTTA)と平均解決時間(MTTR)(下降傾向)。
• ノイズ: アラートに対する真の陽性の比率(シグナルの質が上昇傾向)。
• コスト: 取り込み1GBあたりのコスト(上流フィルタリングにより約40%下降する傾向)。
• 信頼性: 取り込みに欠落が発生した日数(目標はゼロ)と、スキーマ変更のSLA(Microsoftのスキーマ変更から7日以内にパーサーを更新)。

よくある落とし穴と対処法

どれほど綿密な計画でも、障害にぶつかることがあります。以下のよくある落とし穴に注意してください。

「設定はオンにした」と主張するチームは多いものの、Advanced Auditのライセンスやメールボックス監査のベースラインが適切に確認されていないため、ログが実際には出力されていないことがよくあります。もう一つよくある問題は、SIEMのルールがイベントを個別に評価し、ルールの作成、地理的な変化、外部共有を関連付けないため、攻撃中も完全に沈黙してしまうことです。

事前フィルタリングを省略すると、コストが急増します。ノイズの多い操作は必ず事前にフィルタリングし、バックグラウンドの同期イベントは除外してください。パーサーの劣化も静かに効いてくる問題です。月次でスキーマの差分確認を行い、サンプルペイロードに対する単体テストを実行する仕組みを整えてください。最後に、アラートに文脈がないと、アナリストはすぐに疲弊します。アラートには必ず「誰が」「何を」「どこで」「秘密度ラベル」を含め、詳細な調査のためのMicrosoft Compliance Centerへの直接リンクも添えてください。

結論: コンプライアンスに頼った保護をやめる

要点は単純です。SIEMの標準コネクタはコンプライアンスを満たすことはできても、保護まではしてくれません。適切なMicrosoft 365のログを取得し、統一スキーマに正規化し、重要なビジネス文脈で拡充し、実際の攻撃者の振る舞いに合わせて調整された検出ルールで脅威を探索することで、可視性のギャップを完全になくすことができます。それがSIEMが「何が起きているのか」を見逃すのをやめ、その物語を自ら語り始める方法です。この戦略をさらに深く知りたい方は、エピソード全編Send Critical Microsoft 365 Logs to Your SIEMをお聴きいただき、今日から可視性のギャップを埋めていきましょう。