Microsoft Defender環境でMicrosoft Sentinelを使っている場合、「Threat intelligence – Microsoft Sentinel」で最も重要なのは、脅威インテリジェンスの管理・活用がMicrosoft Defenderポータル中心に移っていくことと、旧テーブルや旧コネクタに依存した運用を見直す必要があることです。
2026年5月14日に更新されたMicrosoft公式情報では、Microsoft SentinelのThreat intelligenceは、Microsoft DefenderポータルとAzureポータルの両方に適用される機能として説明されています。ただし、Microsoft Sentinelは2027年3月31日以降、Azureポータルではサポートされず、Microsoft Defenderポータルでのみ利用する形になります。AzureポータルでSentinelを運用している管理者は、脅威インテリジェンスの取り込み、検知ルール、KQL、ワークブック、Automation、API連携を早めに棚卸しする必要があります。(Microsoft Learn)
Microsoft Defenderの「Threat intelligence – Microsoft Sentinel」で押さえるべき変更点
Threat intelligence in Microsoft Sentinelは、IPアドレス、ドメイン、URL、ファイルハッシュなどのIoCだけを登録する機能ではありません。現在のMicrosoft Sentinelでは、STIX形式に基づいて、脅威アクター、攻撃パターン、ID、関係性なども扱えるようになっており、Microsoft Defenderポータル上のDefender Threat IntelligenceやThreat Analyticsと並んで管理されます。(Microsoft Learn)
特に影響が大きいポイントは次の3つです。
| 変更・確認ポイント | 影響を受ける対象 | 管理者・開発者が確認すべきこと |
|---|---|---|
| Microsoft Sentinelの利用場所がDefenderポータル中心になる | AzureポータルでSentinelを運用しているSOC、管理者 | 2027年3月31日までにDefenderポータルでの運用手順、権限、インシデント対応フローを確認する |
| Threat Intelligence Platformデータコネクタが非推奨の方向 | 既存TIPや独自アプリから旧APIでIoCを投入している環境 | upload APIやTAXIIコネクタへの移行可否を検討する |
ThreatIntelligenceIndicator依存のKQLや自動化が古くなる | カスタム分析ルール、検知ルール、ワークブック、Logic Apps、外部連携 | ThreatIntelIndicatorsとThreatIntelObjectsを前提にクエリを見直す |
単純に「ポータル画面が変わる」だけではありません。SOCの検知ロジック、アナリストの調査画面、外部チケットシステムとの連携、KQLベースのレポートまで影響する可能性があります。
Threat intelligence in Microsoft Sentinelとは何か
Threat intelligence in Microsoft Sentinelは、組織が収集・購入・共有している脅威インテリジェンスをMicrosoft Sentinelに取り込み、検知、調査、ハンティング、可視化に使うための仕組みです。
たとえば、次のような情報をSentinelのワークスペースに取り込めます。
| 種類 | 具体例 | 主な使い道 |
|---|---|---|
| Indicator | 悪性IP、ドメイン、URL、ファイルハッシュ、IPv6、X509証明書、JA3、JA3S、User-Agent | ログとの照合、アラート生成、調査時のコンテキスト付与 |
| Threat actor | APTグループ、攻撃者グループ、犯罪組織 | 攻撃キャンペーンやTTPの理解 |
| Attack pattern | フィッシング、初期アクセス、横展開など | MITRE ATT&CKに沿った分析、ハンティング |
| Identity | 被害組織、対象業種、関連する主体 | 攻撃対象の把握 |
| Relationship | 攻撃者とインジケーター、攻撃パターンと被害組織の関係 | 点ではなく線で脅威を分析する |
従来の運用では「危険なIPに通信していないか」を見る程度で終わりがちでした。しかし、STIXオブジェクトやRelationshipを使うと、「どの攻撃者が、どの攻撃手法を使い、どのインジケーターと関連しているのか」まで整理できます。これは、インシデント対応時の優先順位付けに役立ちます。
Microsoft Defenderポータル移行で何が変わるのか
Microsoft Sentinelは、Microsoft Defenderポータル上でSIEM、SOAR、XDRを統合する方向に進んでいます。Microsoftの公式情報では、DefenderポータルはMicrosoft Defender XDR、Microsoft Sentinel、Microsoft Security Exposure Management、Microsoft Security Copilotなどを統合し、監視、検知、調査、対応を一元化する場所として説明されています。(Microsoft Learn)
管理者がまず押さえるべき日付は、2027年3月31日です。この日以降、Microsoft SentinelはAzureポータルではサポートされず、Microsoft Defenderポータルのみで利用されます。(Microsoft Learn)
Azureポータル利用中の環境で確認すべきこと
AzureポータルでSentinelを使っている場合、次の項目を優先して確認してください。
| 確認項目 | 確認すべき理由 |
|---|---|
| SentinelワークスペースのDefenderポータルへのオンボード状況 | 新しい操作画面、統合インシデント、権限設計に影響する |
| Microsoft Defender XDRコネクタの状態 | Defender関連のアラートやインシデントの流れに影響する |
| アナリストの調査手順 | インシデントキューや相関の見え方が変わる |
| Automation RulesとPlaybooks | ルール条件、トリガー、遅延、ProviderNameなどに影響が出る可能性がある |
| 外部チケットシステム連携 | インシデントURL、説明フィールド、APIレスポンスの違いを確認する必要がある |
| 権限設計 | Azure RBACだけでなくDefender側の統合RBACを考慮する必要がある |
Microsoft公式情報では、Defenderポータルに移行しても、基本的なデータ収集アーキテクチャやLog Analyticsの取り込みパイプラインは維持され、既存のSentinelコネクタも継続動作するとされています。ただし、インシデントやアラートの相関、Automation、APIレスポンス、表示場所には差分があります。(Microsoft Learn)
脅威インテリジェンスの取り込み方法は4種類ある
Threat intelligence – Microsoft Sentinelで脅威インテリジェンスを取り込む方法は、主に次の4種類です。既存環境では複数を併用しているケースもあります。
| 取り込み方法 | 向いている用途 | 注意点 |
|---|---|---|
| Microsoft Defender Threat Intelligenceデータコネクタ | Microsoftが提供するIoCやOSINTを使いたい場合 | StandardとPremiumで利用できる情報に違いがある |
| Threat Intelligence – TAXIIデータコネクタ | STIX/TAXII 2.0または2.1対応の外部フィードを取り込みたい場合 | TAXIIサーバーのAPI Root、Collection IDなどが必要 |
| Threat Intelligence upload API | 独自TIPやカスタムアプリからSTIXオブジェクトを投入したい場合 | プレビュー機能。Microsoft EntraアプリとSentinel Contributorロールが必要 |
| Threat Intelligence Platformデータコネクタ | 旧来のTIP連携を使っている場合 | 非推奨の方向。インジケーターのみ対応で、STIXオブジェクト全体には向かない |
公式情報では、Threat Intelligence Platformデータコネクタは非推奨の方向にあり、upload APIの利用が推奨されています。upload APIはデータコネクタを必要とせず、ワークスペース単位でSTIXオブジェクトを取り込める点が特徴です。(Microsoft Learn)
Defender Threat Intelligenceデータコネクタで確認すべきポイント
Microsoft Defender Threat Intelligenceデータコネクタを使うと、Microsoft Defender Threat Intelligenceで生成されたIoCをMicrosoft Sentinelワークスペースに取り込み、監視、アラート、ハンティングに利用できます。公式ドキュメントでは、StandardとPremiumのデータコネクタが用意されていると説明されています。(Microsoft Learn)
管理者が見るべきポイントは、ライセンス名そのものよりも、どの品質・範囲のインテリジェンスを使って検知するかです。
| 項目 | Standard相当 | Premium相当 |
|---|---|---|
| 主な情報 | Public IoC、OSINT | Microsoftで強化されたOSINT、MicrosoftがキュレーションしたIoC |
| 向いている環境 | まずMicrosoft提供の基本的な脅威情報を使いたい環境 | より広いデータソースと文脈を使って検知・調査したいSOC |
| 確認点 | データコネクタがConnectedになっているか | MDTI API Access SKUなど、必要な契約・権限を確認する |
コネクタの有効化には、Content hubからThreat Intelligenceソリューションをインストールまたは更新し、Data connectorsからDefender Threat Intelligenceコネクタを選んでConnectします。必要な権限として、Content hubでのソリューション管理にはリソースグループレベルのMicrosoft Sentinel Contributor、コネクタ設定にはワークスペースへの読み取り・書き込み権限が必要です。(Microsoft Learn)
upload APIへ移行すべきケース
Threat Intelligence upload APIは、外部TIPや独自アプリケーションからMicrosoft SentinelにSTIXオブジェクトを投入するための方法です。データコネクタを介さずに脅威インテリジェンスを取り込めるため、既存のTIP連携や自社開発のセキュリティ基盤と組み合わせやすい構成です。(Microsoft Learn)
次のような環境では、upload APIの検討優先度が高くなります。
| 状況 | upload APIを検討すべき理由 |
|---|---|
| 旧Threat Intelligence Platformデータコネクタを使っている | 旧コネクタは非推奨の方向で、インジケーター以外のSTIXオブジェクトに弱い |
| 独自TIPからIoC以外の情報も送りたい | Threat actor、attack pattern、relationshipなどを活用できる |
| ワークスペース単位で権限を絞りたい | upload APIはワークスペーススコープで動作する |
| カスタムアプリで脅威インテリジェンスを生成している | Microsoft Entraアプリを使って連携しやすい |
upload APIを使う場合は、Microsoft Entraアプリケーションの登録、クライアントシークレットの作成、Microsoft Sentinel Contributorロールの割り当て、ワークスペースIDやOAuth 2.0アクセストークンの設定が必要です。公式情報では、upload APIはプレビューとして案内されています。(Microsoft Learn)
開発者が注意すべき実装ポイント
upload APIを使う開発者は、単にAPIへデータをPOSTできるかだけでなく、次の点を設計段階で確認してください。
| 確認項目 | 実務上の注意点 |
|---|---|
| STIXオブジェクトのID設計 | 重複や更新判定に関わるため、送信元ごとの命名・生成ルールを決める |
| Valid from / Valid until | 期限切れのIoCを大量投入するとノイズやコスト増につながる |
| Confidence | 検知ルールや優先度判断に使うため、送信元ごとのスコア基準を統一する |
| TLP | 共有範囲を誤ると情報漏えいリスクになる |
| エラー処理 | API失敗時の再送、重複投入、部分失敗の扱いを決める |
| ロール付与範囲 | アプリに過剰な権限を与えず、必要なワークスペースに限定する |
特に、脅威インテリジェンスは「取り込めば終わり」ではありません。誤検知の多いフィードや期限切れのIoCを放置すると、SOCのアラート疲れを招きます。
新テーブルへの移行が最重要ポイント
Threat intelligence – Microsoft Sentinelで最も見落としやすいのが、テーブルスキーマの変更です。
Microsoftは2025年4月3日に、STIX indicatorとSTIX objectスキーマをサポートする新しいテーブルとして、ThreatIntelIndicatorsとThreatIntelObjectsをパブリックプレビューしました。従来のThreatIntelligenceIndicatorテーブルへの同一データの取り込みは2025年7月31日まで継続され、その後は停止すると案内されています。(Microsoft Learn)
2026年時点で確認すべきことは、旧テーブル名を使ったKQLや自動化が残っていないかです。
| 旧来の確認対象 | 見直し内容 |
|---|---|
| カスタム分析ルール | ThreatIntelligenceIndicator参照をThreatIntelIndicators中心に変更する |
| ハンティングクエリ | STIXオブジェクトを使う場合はThreatIntelObjectsとの結合も検討する |
| ワークブック | 可視化対象のテーブル名と列名を確認する |
| Logic Apps / Playbook | KQLアクション、条件分岐、外部送信データを確認する |
| 外部SIEM・チケット連携 | APIやクエリ結果の列名変更に注意する |
| 社内手順書 | 旧テーブル名を前提にした調査手順を更新する |
新しいスキーマでは、ObservableKeyやObservableValueを使って、IP、ドメイン、URL、ファイルハッシュなどの観測値を扱います。Microsoft公式ドキュメントでは、旧スキーマの列を再現する例として、ObservableKeyに応じてNetworkIP、DomainName、FileHashValue、Urlなどをextendで作る方法も示されています。(Microsoft Learn)
旧テーブル依存を確認するKQLの考え方
まずは、保存済みの分析ルール、ワークブック、ハンティングクエリ、Automationで次の文字列を検索します。
ThreatIntelligenceIndicator該当が見つかったら、すぐに置換するのではなく、次の観点で分類します。
| 分類 | 対応方針 |
|---|---|
| IoC照合だけに使っている | ThreatIntelIndicatorsで置き換える |
| 脅威アクターや攻撃パターンの文脈も必要 | ThreatIntelObjectsも併用する |
| ワークブックの集計 | 新テーブルの列名に合わせて可視化項目を再設計する |
| 外部システム連携 | 出力列の変更がチケット項目に影響しないか確認する |
| 一時的な調査クエリ | 削除または社内ナレッジから除外する |
古いKQLを機械的に置き換えると、検知漏れや誤検知が起きる可能性があります。特に、IPアドレス、URL、ドメイン、ファイルハッシュを同じ列で扱っていたクエリは、ObservableKeyとObservableValueの意味を確認してから修正してください。
Ingestion rulesでノイズを減らす
Threat intelligenceでは、量が多いほど良いとは限りません。古いIoC、信頼度の低いIoC、組織に関係の薄いフィードをそのまま取り込むと、アラートが増え、調査の優先順位が下がります。
Microsoft SentinelのIngestion rulesを使うと、データコネクタから取り込む脅威インテリジェンスをフィルタリングしたり、属性を変更したりできます。たとえば、6か月更新されていない低信頼度の脅威情報を除外する、高信頼度IoCの有効期限を30日延長する、特定の分類タグを付与するといった運用が可能です。(Microsoft Learn)
ただし、重要な制約があります。
| 注意点 | 内容 |
|---|---|
| 適用対象 | データコネクタから取り込まれる脅威インテリジェンスに適用される |
| 適用されない対象 | upload API経由、手動作成された脅威インテリジェンスには影響しない |
| ルール順序 | すべてのルールが順番に評価される |
| Deleteアクション | 取り込みパイプラインから除外する。過去に取り込まれた既存データまでは削除しない |
| 反映時間 | 新規作成・編集されたルールは反映まで最大15分程度かかる場合がある |
現場では、最初から細かいルールを大量に作るよりも、次の3種類に絞ると運用しやすくなります。
| ルール例 | 目的 |
|---|---|
| 低Confidenceかつ古いIoCを除外 | 誤検知と調査負荷を減らす |
| 信頼できるソースのIoCにタグ付け | アナリストが優先度を判断しやすくする |
| 高ConfidenceのIoCの有効期限を延長 | 重要な脅威情報を短期間で失効させない |
Relationshipを使うと調査の質が上がる
Threat intelligenceの運用では、タグを便利に使いすぎると情報が散らかります。たとえば、APT29、phishing、initial-access、campaign-aのようなタグを自由に付け続けると、後から意味が分からなくなりやすいです。
Microsoft Sentinelでは、STIXオブジェクト同士のRelationshipを使って、脅威アクター、攻撃パターン、インジケーター、被害組織などを関連付けられます。公式ドキュメントでは、脅威アクターと攻撃パターンを結び付ける、ドメインインジケーターを脅威アクターに関連付ける、攻撃パターンを標的組織に関連付けるといった例が示されています。(Microsoft Learn)
使い分けの目安は次の通りです。
| 方法 | 向いている用途 | 例 |
|---|---|---|
| タグ | 一時的な分類、検索補助、インシデント単位の整理 | incident-2026-05、priority-high |
| Relationship | 脅威の意味を表す永続的な関係 | APTグループが特定の攻撃手法を使う、ドメインが攻撃者に帰属する |
| TLP | 情報共有範囲の制御 | White、Green、Amber、Red |
特に外部組織やMSSPと情報を共有する場合、TLPの設定は重要です。機密性の高い情報を誤って広く共有しないよう、社内でTLPの判断基準を決めておく必要があります。
検知ルールで使うときの確認ポイント
Threat intelligenceの価値は、取り込んだ後にログと照合して検知へつなげることで高まります。Microsoft Sentinelでは、脅威インジケーターとログを比較する分析ルールを使って、セキュリティアラートやインシデントを生成できます。(Microsoft Learn)
Microsoft Defender Threat Intelligence Analyticsルールを使うと、Microsoftが生成した脅威インテリジェンスを、CEFログ、Windows DNS、Syslog、Microsoft 365、Azure Activity、ASIM DNS、ASIM Network Sessionsなどのデータと照合できます。PremiumのMicrosoft Defender Threat Intelligenceライセンスは不要ですが、対象となるデータソースのコネクタやソリューションが必要です。(Microsoft Learn)
検知ルールを有効化する前に確認すること
| 確認項目 | なぜ重要か |
|---|---|
| 照合対象のログがSentinelに入っているか | IoCがあっても比較対象のログがなければ検知できない |
| フィールドに値が入っているか | ClientIP、RequestURL、DnsQueryなどが空だとマッチしない |
| アラートの重大度設計 | ブロック済み通信と許可済み通信では対応優先度が異なる |
| インシデント統合の挙動 | Defenderポータルでは複数アラートが相関され、1つのインシデントにまとまる場合がある |
| 抑制・チューニング | 既知の業務通信や誤検知を放置するとSOCの負担が増える |
「とりあえず有効化する」だけでは、アラートが増えるだけで終わることがあります。最初は対象データソースを絞り、1〜2週間程度の運用結果を見て、誤検知、検知漏れ、重大度、通知先を調整するのが現実的です。
Defenderポータル移行時のAutomationとAPIの注意点
Microsoft Defenderポータルへの移行では、Threat intelligenceそのものだけでなく、インシデント対応の自動化にも影響があります。
公式情報では、Defenderポータルにオンボードした後、Automation rulesやPlaybooksにいくつかの制約・差分があると説明されています。たとえば、インシデントプロバイダーの扱い、SecurityIncidentテーブルのDescriptionフィールド、インシデント名の変更、手動Playbook実行、インシデント同期の遅延などです。(Microsoft Learn)
特に開発者や運用自動化担当者は、次の点を確認してください。
| 対象 | 確認ポイント |
|---|---|
| Automation rules | インシデントタイトルだけを条件にしていないか。タイトルは相関により変わる可能性がある |
| Logic Apps | Sentinel同期前のインシデントに対して実行しようとして失敗しないか |
| 外部チケット連携 | インシデントURL、説明、ProviderNameの変更に対応しているか |
| API連携 | 統合インシデント・アラートにはMicrosoft Graph REST APIの利用を検討する |
| Sentinel API | 分析ルールやAutomation rulesなどSentinelリソース操作には引き続き使える |
Microsoft公式情報では、統合されたインシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨され、Microsoft Sentinel APIは分析ルールやAutomation rulesなどSentinelリソースへの操作を引き続きサポートすると説明されています。(Microsoft Learn)
管理者向けの実務チェックリスト
Threat intelligence – Microsoft Sentinelの変更に対応するには、画面確認だけでは不十分です。次の順序で棚卸しすると、影響範囲を漏らしにくくなります。
| 優先度 | 作業 | 確認内容 |
|---|---|---|
| 高 | ポータル移行状況の確認 | DefenderポータルでSentinelワークスペースを操作できるか |
| 高 | 旧テーブル依存の調査 | ThreatIntelligenceIndicatorを使うKQL、ルール、ワークブックが残っていないか |
| 高 | コネクタ確認 | Defender Threat Intelligence、TAXII、TIP、Defender XDRコネクタの状態 |
| 高 | 検知ルール確認 | TI map系ルール、Microsoft Defender Threat Intelligence Analyticsルールの有効化状況 |
| 中 | Ingestion rules整備 | 古いIoCや低信頼度IoCを除外できているか |
| 中 | タグ・Relationship設計 | タグ乱立を避け、脅威アクターや攻撃パターンとの関係を整理できているか |
| 中 | Automation確認 | ProviderName、Description、Incident URL、遅延への対応 |
| 低 | ワークブック見直し | 新テーブルに合わせた可視化になっているか |
| 低 | 社内手順書更新 | アナリストがDefenderポータル前提で調査できるか |
まずは高優先度の4項目から着手してください。特に旧テーブル依存は、検知ルールやダッシュボードが静かに機能しなくなる原因になりやすいため、最初に確認すべきです。
よくある失敗と回避策
旧テーブル名だけを機械的に置換してしまう
ThreatIntelligenceIndicatorをThreatIntelIndicatorsに置き換えるだけでは、列名やデータ構造の違いを吸収できない場合があります。ObservableKeyとObservableValueの意味を確認し、IP、ドメイン、URL、ハッシュごとに期待する値が取れているかをテストしてください。
低品質なIoCを大量に取り込んでしまう
オープンソースフィードを無条件に取り込むと、古いIoCや信頼度の低いIoCが増え、誤検知の原因になります。Ingestion rulesで古い情報や低Confidenceの情報を除外し、重要なソースにはタグを付けると運用しやすくなります。
Azureポータル前提の運用手順を放置する
2027年3月31日以降はDefenderポータル中心の運用になります。調査手順、教育資料、画面キャプチャ、問い合わせ対応、監査手順がAzureポータル前提のままになっていないか確認してください。
Automationがインシデント名に依存している
Defenderポータルではアラート相関によりインシデント名が変わる可能性があります。Automation rulesの条件には、可能であれば分析ルール名、タグ、エンティティ、重大度など、より安定した情報を使うべきです。
TIP連携の移行を後回しにする
Threat Intelligence Platformデータコネクタは非推奨の方向です。既存TIPや自社アプリからIoCを投入している場合は、upload APIまたはTAXII連携へ移行できるかを早めに検証してください。
まず何から対応すべきか
Microsoft Defender環境でThreat intelligence – Microsoft Sentinelを使っている管理者は、次の順番で対応すると効率的です。
- DefenderポータルでMicrosoft Sentinelワークスペースを操作できるか確認する
ThreatIntelligenceIndicatorを使っているKQL、分析ルール、ワークブック、Automationを洗い出す- Defender Threat Intelligence、TAXII、upload API、旧TIPコネクタの利用状況を整理する
- 低品質・期限切れIoCを抑えるIngestion rulesを作る
- Microsoft Defender Threat Intelligence Analyticsルールを有効化する場合は、照合対象ログが入っているか確認する
- Automation rules、Playbooks、外部チケット連携がDefenderポータル移行後も動くかテストする
今回の更新で重要なのは、脅威インテリジェンスを単なるIoCリストとして扱うのではなく、Microsoft Defenderポータル上の統合セキュリティ運用に組み込むことです。旧テーブル、旧コネクタ、Azureポータル前提の手順をそのまま残すと、検知漏れや運用混乱の原因になります。
まずは、旧テーブル依存とポータル移行状況の棚卸しから始めてください。そのうえで、upload API、STIXオブジェクト、Relationship、Ingestion rulesを活用すれば、Threat intelligence – Microsoft Sentinelを「取り込むだけの機能」から、調査と検知の精度を高める実用的な運用基盤にできます。
コメント