はじめに
セキュリティ運用の現場で「SIEM（Security Information and Event Management）」や「SOAR（Security Orchestration, Automation, and Response）」の導入を検討されている方は多いのではないでしょうか。
本記事は、読者がSentinelの運用設計を作成できることを目標として記事を作成しました。
本記事では、私が実務の中でSentinel導入した経験を元に、AzureのクラウドネイティブSIEM/SOARサービスである Microsoft Sentinel について、Defenderポータルとの統合を踏まえた活用方法を解説します。具体的には、コンテンツハブの活用、インシデント管理、アラートチューニング（抑制） を中心に、運用に役立つ実践的なポイントをまとめました。
想定読者
- SIEM/SOARの導入・検討を進めているAzureユーザー
- セキュリティ運用の効率化・自動化を目指しているSOC担当者
- Microsoft Sentinelにこれから触れる、または使い始めたばかりの方
記事で触れる内容
| # | 内容 |
|---|---|
| 1章 | Microsoft Sentinelの概要 |
| 2章 | SentinelとDefenderポータルの統合 |
| 3章 | コンテンツハブの活用とGitHubでの事前確認 |
| 4章 | Defenderポータルでのインシデント管理 |
| 5章 | 自動化ルールによるインシデント抑制 |
| 6章 | Defender XDRのアラートチューニング |
1章 Microsoft Sentinelとは
Microsoft Sentinelは、Azureが提供するクラウドネイティブなSIEM/SOARプラットフォームです。
Log Analyticsワークスペースをデータ基盤として、組織全体のセキュリティログを集約・分析し、脅威の検出から対応までを一元管理できます。
主な特徴は以下の通りです。
- SIEM機能：多様なデータソースからのログ収集、KQLによる高度な分析、分析ルールによる脅威検出
- SOAR機能：自動化ルールやプレイブック（Logic Apps）による自動対応
- コンテンツハブ：すぐに使えるデータコネクタ、分析ルール、ワークブック等をパッケージ化したソリューション
- UEBA（User and Entity Behavior Analytics）：ユーザーやエンティティの行動分析による内部脅威の検出
2章 SentinelとDefenderポータルの統合
Azure Portalのサポート終了と移行
2027年3月31日以降、Microsoft SentinelはAzure Portalでサポートされなくなり、Microsoft Defenderポータルでのみ使用可能になります。 現在Azure PortalでSentinelを使用している場合は、早めにDefenderポータルへの移行計画を策定することを推奨します。
参考：すべての Microsoft Sentinel のお客様向けの Microsoft Defender ポータルへの移行の計画
Defenderポータルで利用可能な主要機能
Defenderポータルでは、従来のAzure Portalでの機能に加え、以下の機能が利用可能です。
各機能の詳細は参考リンク先をご確認ください。
| 機能 | 説明 | 参考 |
|---|---|---|
| 統合インシデントキュー | SentinelとDefender XDRのインシデントを1つのキューで管理 | 統合セキュリティ操作とは |
| 統合エンティティページ | デバイス・ユーザー・IPアドレス等のエンティティ情報をSentinelとDefender双方のデータソースから統合表示 | Microsoft Defender ポータルの Microsoft Sentinel |
| 自動攻撃かく乱 | 忠実性の高い真陽性に対し、侵害されたエンティティの修復を自動実行 | Microsoft Defenderでの自動攻撃の中断 |
| Security Copilot | インシデント要約やスクリプト分析など、AI支援による調査効率の向上 | Microsoft Defender の Security Copilot |
| 高度なハンティング | Microsoft SentinelとDefender XDRのデータを統一スキーマで30日間無料ハンティング | 高度なハンティングの概要 |
| SOC最適化の推奨事項 | コストと露出を削減するためのガイド付き推奨事項の提供 | セキュリティ オペレーションを最適化する |
Defenderポータルでのナビゲーション
移行後は操作画面の配置が変わります。主要な機能のマッピングは以下の通りです。
現在（2026/4/20）としてはまだ移行が進んでいない機能もあります。その点を留意の上、利用をしてください。
| Azure Portal | Defenderポータル |
|---|---|
| インシデント | 調査と対応 > インシデントとアラート > インシデント |
| ワークブック | Microsoft Sentinel > 脅威の管理 > ブック |
| ハンティング | Microsoft Sentinel > 脅威の管理 > 追求 |
| コンテンツハブ | Microsoft Sentinel > コンテンツ管理 > コンテンツハブ |
| データコネクタ | Microsoft Sentinel > 構成 > データコネクタ |
| 分析 | Microsoft Sentinel > 構成 > 分析 |
| 自動化 | Microsoft Sentinel > 構成 > オートメーション |
Defender XDRやE5ライセンスを持たなくても、Defenderポータルで Microsoft Sentinelは利用可能です。SentinelのみのオンボードでもDefenderポータルの統合UIを活用できます。
3章 コンテンツハブの活用とGitHubでの事前確認
コンテンツハブとは
コンテンツハブは、データコネクタ・分析ルール・ワークブック・プレイブック・ハンティングクエリなどをソリューション単位でまとめてデプロイできる仕組みです。ゼロからルールを構築する必要がなく、Microsoftやコミュニティが提供するベストプラクティスを即座に利用できます。
ここまでは、コンテンツハブの謳い文句です。
実際には、データコネクタに関しては診断設定やDCR等AzurePortalの画面で手動設定する部分が多いです。また、手動で設定しないとランダムなリソース名で作られてしまうことが多いので、管理上手動で作成した方が良いケースも多いです。
おすすめのコンテンツソリューション
初期導入時に特におすすめのソリューションを、脅威検出・不正アクセス検知・監査・SOC運用基盤の観点で整理します。
脅威検出
外部からの攻撃やマルウェア活動など、セキュリティ脅威の検出に関連するソリューションです。
| ソリューション名 | 対象リソース | 含まれる主なコンテンツ | 説明 |
|---|---|---|---|
| Microsoft Defender XDR | Defender for Endpoint / Office 365 / Identity / Cloud Apps | データコネクタ、分析ルール | Defender各製品のアラートを統合収集・検出 |
| Tenant-based Microsoft Defender for Cloud (Preview) | Microsoft Defender for Cloud | データコネクタ、分析ルール | Defender for Cloudのセキュリティアラート・推奨事項をテナント単位で収集 |
| Endpoint Threat Protection Essentials | Defender for Endpoint / Windows VM | 分析ルール、ハンティングクエリ | エンドポイントの脅威検出（マルウェア実行、不審なプロセス等） |
| Network Threat Protection Essentials | Azure Network / NSG / Azure Firewall | 分析ルール、ハンティングクエリ | ネットワークベースの脅威検出（C2通信、ポートスキャン等） |
| Azure Firewall | Azure Firewall | データコネクタ、ワークブック、分析ルール | Azure Firewallのログ収集とネットワーク脅威の分析 |
| Azure Web Application Firewall (WAF) | Azure WAF（Application Gateway / Front Door） | データコネクタ、ワークブック | WAFの検出ログ収集とWebアプリケーション攻撃の可視化 |
不正アクセス検知
認証・認可に関連する不正アクセスや内部脅威の検出に関連するソリューションです。
| ソリューション名 | 対象リソース | 含まれる主なコンテンツ | 説明 |
|---|---|---|---|
| Microsoft Entra ID Protection | Microsoft Entra ID P2 | データコネクタ、分析ルール、ワークブック | リスクの高いサインイン・ユーザーの検出（漏洩資格情報、異常な場所からのアクセス等） |
| Cloud Identity Threat Protection Essentials | Microsoft Entra ID | 分析ルール、ハンティングクエリ | クラウドID関連の脅威検出（ブルートフォース、異常なサインインパターン等） |
| UEBA Essentials | Microsoft Entra ID / Sentinel UEBA | ハンティングクエリ | ユーザー・エンティティの行動分析による内部脅威・異常アクセスの検出 |
| Windows Security Events via AMA | Windows Server / Client（Azure Monitor Agent） | データコネクタ、分析ルール | Windowsセキュリティイベント（ログオン、特権使用、アカウント管理等）の収集・検出 |
監査
Azureリソースの操作履歴やコンプライアンス要件に関連するソリューションです。
| ソリューション名 | 対象リソース | 含まれる主なコンテンツ | 説明 |
|---|---|---|---|
| Azure Activity | Azure サブスクリプション（アクティビティログ） | データコネクタ、ワークブック、分析ルール | Azureリソースの管理操作ログ（作成・変更・削除等）の収集・監査 |
| ゼロトラスト (TIC 3.0) | Microsoft Entra ID / Defender / Azure 全般 | 分析ルール、プレイブック、ワークブック | ゼロトラストアーキテクチャに基づくコンプライアンス監査・可視化 |
SOC運用基盤
SOCの運用プロセスや自動化を支えるソリューションです。
| ソリューション名 | 対象リソース | 含まれる主なコンテンツ | 説明 |
|---|---|---|---|
| SOAR Essentials | Microsoft Sentinel（共通） | プレイブック | インシデント対応の自動化に必要な基本プレイブック集 |
| SOC ハンドブック | Microsoft Sentinel（共通） | ワークブック | SOC運用の全体像を可視化するダッシュボード |
| SOC プロセスフレームワーク | Microsoft Sentinel（共通） | ワークブック、ウォッチリスト、プレイブック | SOCの運用プロセスを標準化するためのフレームワーク |
すべてのソリューション一覧は Azure Marketplace から確認可能です。「製品の種類 = ソリューションテンプレート」でフィルタしてください。
GitHubでコンテンツの中身を事前確認する
コンテンツハブにあるソリューションの多くは、GitHubリポジトリで中身を事前に確認可能です。デプロイ前に分析ルールのKQLや検出ロジック、プレイブックのワークフローを把握できます。
この中で最も内容の理解が重要なのは、分析ルールです。分析ルールをもとにアラートとインシデントが生成されます。つまり唯一利用ユーザーが受動的に利用するコンテンツになります。アラートが上がってからあたふたしないように、導入するコンテンツの分析ルールはしっかりと確認してアラート（またはインシデント）発生時の対応計画を作成しておきましょう。
公開リポジトリ：
このリポジトリには以下のようなディレクトリ構成でコンテンツが格納されています。
Azure-Sentinel/
├── Solutions/ # ソリューション単位のパッケージ
│ ├── Microsoft Entra ID/
│ ├── Microsoft 365/
│ └── ...
├── Detections/ # 分析ルール（検出ルール）
├── Hunting Queries/ # ハンティングクエリ
├── Playbooks/ # プレイブック（Logic Apps）
├── Workbooks/ # ワークブック
└── DataConnectors/ # データコネクタ
たとえば、特定の分析ルールが自組織の環境に適合するかどうか、デプロイ前にKQLのロジックを確認したい場合は、Solutions/<ソリューション名>/Analytics Rules/ 配下のYAMLファイルを確認できます。
# 例：分析ルールのYAML構造
id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
name: Brute force attack against Azure Portal
description: |
Identifies evidence of brute force activity against Azure Portal...
severity: Medium
queryFrequency: 1d
query: |
SigninLogs
| where ResultType == "50126"
| summarize Count = count() by UserPrincipalName, IPAddress
| where Count > 10
GitHubリポジトリはコミュニティからのコントリビューションも活発です。自組織の要件に合わせたカスタムルールを作成する際の参考にもなります。
4章 Defenderポータルでのインシデント管理
インシデントとは
Microsoft Sentinelにおけるインシデントは、関連するアラートやエンティティ、分析情報をまとめた「ケースファイル」です。単独のアラートと違い、インシデントは状態の変更やコメントの追加、タグ付け、所有者の割り当てなどが可能で、SOCの運用における中心的な管理単位となります。
インシデントの調査フロー
Defenderポータルでインシデントを開くと、画面上部にタブが並んでおり、各タブで調査に必要な情報を確認できます。以下は、Defenderポータルのインシデント画面のタブに沿った調査の流れです。
ナビゲーション： 調査と対応 > インシデントとアラート > インシデント > 対象インシデントを選択
1. インシデントキューで状態・重大度をフィルタしてトリアージ
↓
2. 攻撃ストーリータブで攻撃フロー・アラートの時系列を把握
↓
3. 証拠と対応タブでエンティティ（Device, User, IP, File）を横断確認
↓
4. 資産タブで影響のあるデバイスやアプリを確認
↓
5. 調査タブで自動調査結果を確認
↓
6. 必要に応じてGo Huntで高度なハンティング（KQL）へ遷移
↓
7. 対応完了後、ステータスと分類（真陽性/誤検知等）を入力してクローズ
インシデント詳細画面の各タブ（攻撃ストーリー、アラート、資産、調査、証拠と対応、概要）の詳細については、以下の公式ドキュメントを参照してください。
5章 自動化ルールによるインシデント抑制
なぜチューニングが必要か
Sentinelを導入すると、大量のアラートが生成されます。しかし、すべてが対応を要するわけではありません。
誤検知（False Positive） やメンテナンス作業による想定内のアラートは、SOCの対応キャパシティを圧迫します。これらのノイズを適切に抑制し、本当に重要なインシデントに集中できる環境を整えることが重要です。運用の中で随時チューニングをしていきましょう。
Defenderポータルでのチューニングには大きく分けて2つのアプローチがあります。
| アプローチ | 対象 | 機能 | 説明 |
|---|---|---|---|
| インシデント抑制（本章） | インシデント | Sentinel 自動化ルール | インシデント作成時に条件に基づいて自動クローズ |
| アラートチューニング（6章） | アラート | Defender XDR アラートチューニング | アラート自体を非表示・解決・動作に変換 |
自動化ルールによるインシデント抑制
Microsoft Sentinelでは、自動化ルール（Automation Rules） を使ってインシデントの抑制を実現します。
基本的な抑制ルールの作成手順
-
Defenderポータル →
Microsoft Sentinel>構成>Automationを開く - 「Automation Rules」タブ → 「Create」→「Automation Rule」を選択
- 以下を設定する
| 設定項目 | 説明 |
|---|---|
| Trigger | 「インシデントが作成されたとき」を選択 |
| Conditions | 分析ルール名、重大度、エンティティ属性などでフィルタ |
| Actions | 「状態の変更」→「クローズ」 |
| Rule expiration | メンテナンス等の場合、期限を設定可能 |
実践例：よくある抑制パターン
パターン：定期メンテナンスによるアラートの抑制
侵入テストやスケジュールされたメンテナンスの期間中に発生するアラートを自動クローズします。
条件：
- 分析ルール名 が含む：「Brute force」
- エンティティ（IPアドレス）が等しい：「10.0.0.100」（テストサーバーIP）
アクション：
- 状態を「クローズ」に変更
- 終了理由：害のない正検知
- タグ追加：「PlannedMaintenance」
有効期限：2026-04-30（メンテナンス終了予定日）
自動化ルールの実行順序
自動化ルールは順序番号（Order） に従って順番に実行されます。先に実行されたルールによる状態変更は、後続のルールの条件評価に影響します。
例えば、ルールAが重大度を「中」→「低」に変更した場合、「重大度が中以上」の条件を持つルールBはそのインシデントでは実行されません。
実行順序の例：
Order 1：重大度を「低」に変更 → 実行される
Order 2：重大度が「中」以上なら通知 → 実行されない（すでに「低」のため）
プレイブックとの組み合わせ
自動化ルールの中で**プレイブック（Logic Apps）**を呼び出すことも可能です。例えば以下のような応用ができます。
- インシデント発生時にTeamsやSlackに通知
- 外部のチケット管理システム（ServiceNow等）にチケットを自動起票
- エンティティ情報をもとに脅威インテリジェンスを自動照会
- 対象ユーザーのアカウントを一時的に無効化
プレイブックを自動化ルールから実行するには、対象のリソースグループに対してMicrosoft Sentinelサービスアカウントへのアクセス許可を付与する必要があります。オートメーション画面の「プレイブックのアクセス許可の管理」から設定できます。自動化処理の閉域化を実現するためにLogicApps（Standard）を使用することもできます。
6章 Defender XDRのアラートチューニング
インシデント抑制との違い
5章で紹介した自動化ルールはインシデント単位の抑制でした。一方、Defender XDRのアラートチューニングは、インシデントの構成要素であるアラート自体を対象とした制御です。
アラートチューニングでは、条件に一致するアラートに対して以下のいずれかのアクションを自動適用できます。
| アクション | 説明 |
|---|---|
| アラートの非表示 | アラートを抑制し、インシデントの作成を防止。非表示のアラートはAlertInfo/AlertEvidenceテーブルには残る（※Defender for Endpointアラートのみ対象） |
| アラートの解決 | アラートと関連インシデントを自動的に解決済みステータスに変更 |
| 動作として設定 | アラートをBehavior（動作）に変換。アラートキューに表示されず、インシデントもトリガーしない。データはBehaviorInfo/BehaviorEntitiesテーブルに残りハンティングで利用可能 |
アラートチューニングルールの作成手順
アラートチューニングルールは、以下の2つの方法で作成できます。
方法1：設定画面から作成
-
Defenderポータル →
設定>Microsoft Defender XDR>ルール>アラートチューニングを開く - 「＋ 新しいルールの追加」を選択
- 以下を設定する
| 設定項目 | 説明 |
|---|---|
| アラートの種類 | 特定のアラートのみ、または条件に基づく任意のアラートの種類を選択 |
| サービスソース | 任意のアラートの種類を選択した場合、対象サービスを指定 |
| 条件 | ファイル、プロセス、スケジュールされたタスク等のIOC（Indicators of Compromise）に基づく条件を定義 |
| アクション | 「アラートの非表示」「アラートの解決」「動作として設定」から選択 |
方法2：アラート画面から作成
アラート一覧またはアラート詳細画面で対象のアラートを選択し、「アラートの調整」を選択すると、そのアラートの情報が条件として事前にセットされた状態でチューニングルールを作成できます。
Microsoft Sentinelの分析ルールから生成されたアラートについては、アラート画面から直接チューニングルールを作成することができません。 Sentinelの分析ルール由来のアラートをチューニングする場合は、方法1の設定画面（設定 > Microsoft Defender XDR > ルール > アラートチューニング）から「＋ 新しいルールの追加」で新規作成してください。
インシデント抑制とアラートチューニングの使い分け
両方の手段を状況に応じて使い分けることで、効率的なノイズ削減が可能です。
| ユースケース | 推奨アプローチ |
|---|---|
| Sentinel分析ルールの誤検知をインシデント単位でクローズしたい | 自動化ルール（5章） |
| メンテナンス期間中の一時的な抑制（有効期限付き） | 自動化ルール（5章） |
| Defender XDR由来のアラート自体を表示させたくない | アラートチューニング（非表示） |
| 特定条件のアラートを自動解決し、インシデントも解決済みにしたい | アラートチューニング（解決） |
| ノイズだがハンティング用にデータは残したい | アラートチューニング（動作として設定） |
さいごに
Microsoft Sentinelは、Defenderポータルとの統合によってSIEM/SOARの運用体験が大きく進化しています。特にDefenderポータルでは、インシデントの統合管理・自動攻撃かく乱・Security Copilotなど、Azure Portal単体では利用できない機能が多数提供されています。
本記事のポイントをまとめます。
- ✅ 2027年3月にAzure PortalでのSentinelサポートが終了 → Defenderポータルへの移行計画を早めに
- ✅ コンテンツハブで分析ルール・プレイブック等をすぐに展開、GitHubで事前にロジック確認
- ✅ 統合インシデントキューでSentinel/Defender双方のインシデントを一元管理
- ✅ 自動化ルールでノイズの多いインシデントを抑制し、SOCの対応効率を向上
- ✅ Defender XDRのアラートチューニングでアラート単位の細かな制御が可能（Sentinel由来は設定画面から作成）
セキュリティ運用は「導入して終わり」ではなく、継続的なチューニングと改善が不可欠です。まずはコンテンツハブのソリューションを活用してスモールスタートし、自動化ルールとアラートチューニングで徐々にSOCの成熟度を高めていくアプローチをするように運用設計しましょう。