Microsoft Sentinel入門｜SIEMの基本と導入・運用の考え方

「アラートは出ていたのに、誰も気づいていませんでした」——インシデント発生後の調査でこのセリフが出てくることがあります。ログは取れていた。検知ルールも動いていた。ただ、アラートが膨大すぎて誰も確認していなかった。

ログを「集める」だけでは守れません。集めたログを「検知につなげる」仕組みが必要です。

この記事では、Microsoftのクラウド型SIEMであるMicrosoft Sentinelの基本的な仕組みと、導入・運用の考え方を解説します。

SIEMとは——ログを「集める」から「検知する」へ

SIEM（Security Information and Event Management：セキュリティ情報・イベント管理） 複数のシステムからログを一元収集し、相関分析・アラート生成・インシデント管理を行うセキュリティ基盤。個別のログを単独で見るのではなく、複数のログを組み合わせて攻撃パターンを検知することが目的。

従来のログ管理との違いを整理します。

SIEMの価値は「点のログを線でつなぐ」ことにあります。

たとえば以下の3つのイベントが個別に発生しても、それぞれ単独では異常とは判断しにくいです。

• 深夜2時に管理者アカウントでのログイン（イベントID 4624）
• その5分後に大量のファイルアクセス（イベントID 4663）
• さらに10分後に外部IPへの通信

しかしこの3つを時系列で相関させると、情報窃取の典型的なパターンとして検知できます。SIEMはこの「線でつなぐ」処理を自動で行います。

Microsoft Sentinelとは——クラウドネイティブなSIEMの特徴

Microsoft Sentinel Microsoftが提供するクラウドネイティブのSIEM・SOARプラットフォーム。Azure上で動作し、Microsoft 365・Entra ID・Azure・オンプレミス環境など多様なソースからログを収集・分析できる。従来のオンプレSIEMと異なり、インフラの構築・管理が不要。

SOAR（Security Orchestration, Automation and Response） セキュリティインシデントへの対応を自動化する仕組み。SIEMと組み合わせて使われることが多く、アラート発生時に自動でチケット作成・通知・遮断などのアクションを実行できる。

Microsoft Sentinelの主な特徴は以下の4点です。

① インフラ不要で即日導入できる オンプレSIEMはサーバー構築・ライセンス・チューニングに数ヶ月かかります。SentinelはAzureのリソースとして数分でデプロイでき、初期インフラコストがかかりません。

② Microsoft製品との親和性が高い Entra ID・Microsoft 365・Defender製品群とネイティブ連携しています。M365環境を使っている組織であれば、数クリックでサインインログ・メール監査ログ・エンドポイントログを取り込めるのは大きなメリットです。

③ コネクタで多様なソースに対応 Microsoft製品以外にも、AWS・Cisco・Palo Alto・Linuxサーバーなど300以上のデータコネクタが用意されています。オンプレのWindowsイベントログもエージェント経由で収集できます。

④ 従量課金でスモールスタートできる ログの取り込み量（GB/日）に応じた従量課金です。最初は重要ログだけに絞って小さく始め、運用が安定してから対象を広げるアプローチが取れます。

参考：Microsoft Learn｜Microsoft Sentinel とは

Sentinelが収集できるログソース

Sentinelへのログ取り込みはデータコネクタで設定します。主要なソースを整理します。

Microsoft製品（ネイティブ連携）

オンプレミス・その他

Windowsイベントログの重要なイベントIDについては「Windowsイベントログ重要ID一覧｜セキュリティ調査で使うIDまとめ」を参照してください。

分析ルールとアラート——何を検知するか設計する

Sentinelの検知エンジンは分析ルール（Analytics Rules）で動きます。ルールが一致したときにアラートが生成され、インシデントとして管理されます。

ルールの種類

MITREマッピングとコンテンツハブ

Sentinelにはコンテンツハブと呼ばれる既製ルール集が用意されています。「Active Directory」「Microsoft 365」などのソリューションをインストールすると、よく使われる検知ルールをまとめて適用できます。

MITRE ATT&CK（マイター・アタック） 攻撃者の戦術・技術・手順（TTP）を体系化したフレームワーク。Sentinelの分析ルールはMITRE ATT&CKのカテゴリにマッピングされており、「どの攻撃段階を検知できているか」を可視化できる。

参考：Microsoft Learn｜Microsoft Sentinel のコンテンツとソリューション

KQLの基本

Sentinelのクエリ言語はKQL（Kusto Query Language）です。独自の検知ルールを作る場合に必要になります。

KQLの具体的な記述方法はMicrosoft公式ドキュメントが最も正確です。
参考：Microsoft Learn｜KQL クイックリファレンス

最初から独自ルールを作る必要はありません。まずコンテンツハブの既製ルールを適用し、誤検知を減らすチューニングから始めるのが現実的なアプローチです。

導入前に決めておくべきこと

Sentinelは「とりあえず有効化」できますが、設計なしで進めるとコストとアラート過多で運用が破綻します。導入前に以下を決めておきます。

① 何のために導入するか目的を明確にする

目的によって、収集するログソースと検知ルールが変わります。

② コストを試算する

Sentinelのコストは主に**ログ取り込み量（GB/日）**で決まります。

無計画に全ログを取り込むと想定外のコストが発生します。導入前に以下を確認してください。

• 対象ログソースの1日あたりのデータ量を見積もる
• 90日間の無料トライアルを活用して実データで試算する
• コストが高い場合は「重要ログに絞る」か「Basic Logsプランを検討する」

参考：Microsoft Learn｜Microsoft Sentinel のコストと課金

③ 誰がアラートを見るか運用体制を決める

Sentinelを有効化しても、アラートを確認する担当者がいなければ意味がありません。

• アラートの一次確認者を決める
• エスカレーション先（CSIRT・上長）を決める
• 対応時間帯（24時間対応か、業務時間内のみか）を決める

SOCとCSIRTの体制設計については「SOCとCSIRTの違い｜セキュリティ運用体制の考え方と規模別の設計パターン」を参照してください。

④ まず何を検知したいか優先順位をつける

全部を一度に検知しようとするとチューニングが追いつかず、アラート疲れを起こします。最初は3〜5個の重要な検知ルールに絞り、運用が回ってから拡張していくことを推奨します。

最初に有効化すべきルールの候補は以下です。

• 不審なサインイン（海外IPからのアクセス・多数の失敗後の成功）
• 特権アカウントの深夜ログイン
• 大量のファイルダウンロード・削除
• マルウェア検知（Defender for Endpoint連携）

よくある失敗パターン4選

① 全ログを取り込んでコストが爆発する

「とりあえず全部入れよう」とすべてのログソースを有効化した結果、月のコストが想定の10倍になるケースがあります。Sentinelの従量課金はログ量に比例するため、取り込むログを目的に合わせて絞ることが最初の設計で最も重要です。

② アラートが多すぎて誰も確認しなくなる

既製ルールをそのまま全部有効化すると、1日数百件のアラートが発生することがあります。アラートが多すぎると担当者が疲弊し、結果として重要なアラートを見逃します。導入直後は少数のルールに絞り、誤検知を減らすチューニングを優先してください。

③ 運用担当者を決めずに導入する

「導入すれば自動で守られる」という誤解が生まれやすいツールです。Sentinelはアラートを生成しますが、そのアラートを見て対応するのは人間です。担当者・エスカレーション先・対応手順を決めずに導入しても、インシデントを検知しても対応できません。

④ ログの保存期間を設計しない

Sentinelのデフォルトのログ保持期間は90日です。インシデント発生後の調査では、数ヶ月前のログが必要になることがあります。コンプライアンス要件や調査対応を見越して、保持期間を設計してください。長期保存が必要な場合はアーカイブ層（低コスト）への移行も検討します

導入検討チェックリスト

目的・スコープ

• [ ] 導入目的（何を検知したいか）を明確にした
• [ ] 優先するログソースを3〜5個に絞った
• [ ] 最初に有効化する検知ルールを決めた

コスト

• [ ] 対象ログの1日あたりのデータ量を見積もった
• [ ] 月間コストの上限を設定した
• [ ] 無料トライアルで実データのコストを試算した

運用体制

• [ ] アラートの一次確認担当者を決めた
• [ ] エスカレーション先・対応フローを文書化した
• [ ] 対応時間帯（業務時間内 / 24時間）を決めた

技術設定

• [ ] ログの保持期間を設計した（最低180日推奨）
• [ ] コンテンツハブのソリューションを確認した
• [ ] 既製ルールの誤検知チューニング計画を立てた

まとめ

今日確認すべきことは1つです。

Microsoft Entra IDのサインインログがSentinelに取り込まれているか確認してください。

Entra IDのサインインログはパスワードスプレー・不正ログイン・海外からのアクセスを検知する最重要ログソースです。すでにAzure環境があれば、Sentinelのデータコネクタから「Microsoft Entra ID」を有効化するだけで取り込みを開始できます。

SIEMは「導入して終わり」ではなく、運用しながら育てていくものです。最初から完璧を目指さず、重要ログに絞ったスモールスタートで始め、アラートの質を上げながら段階的に拡張していく進め方が現実的です。

あわせてご覧ください

• セキュリティインシデント対応入門｜若手エンジニアが最初に知っておくべき対応フローと考え方
• Windowsイベントログ重要ID一覧｜セキュリティ調査で使うIDまとめ
• SOCとCSIRTの違い｜セキュリティ運用体制の考え方と規模別の設計パターン
• Azure Defender for Cloudとは？セキュリティスコアと推奨事項で守れる環境を作る
• M365 Purview入門｜監査ログの取り方とインシデント調査への活用