Microsoft DefenderポータルでMicrosoft Sentinelを運用している場合、2026年5月14日に更新された公式情報「Discover and deploy Microsoft Sentinel out-of-the-box content from Content hub」で最初に押さえるべき点は、Content hubが標準コンテンツの検索・展開・更新・管理の中心になり、今後はDefenderポータル前提で運用設計すべきということです。特に、Microsoft Sentinelは2027年3月31日以降Azure portalではサポートされず、Microsoft Defender portalでの利用に移行する必要があります。(Microsoft Learn)
この記事では、Microsoft Defender環境でMicrosoft Sentinel Content hubを使う管理者・SOC担当者・開発者向けに、何が変わるのか、どこに影響するのか、展開前に確認すべき権限・設定・移行ポイントを実務目線で整理します。
Microsoft DefenderのContent hub更新で押さえるべき結論
Microsoft SentinelのContent hubは、分析ルール、データコネクタ、ワークブック、ハンティングクエリ、パーサー、プレイブックなどの組み込みコンテンツを探して導入する場所です。今回の公式情報では、Content hubが「標準コンテンツを一元的に発見・管理する場所」であることが明確に示され、ソリューション単位またはスタンドアロンコンテンツ単位でインストール、更新、管理できる流れが整理されています。(Microsoft Learn)
ただし、重要なのは操作手順そのものよりも、Azure portal中心の運用からMicrosoft Defender portal中心の運用へ移る前提です。すでにMicrosoft SentinelをAzure portalで使っている組織は、Content hubの使い方だけでなく、権限、データコネクタ、分析ルール、プレイブック、API連携、インシデント運用まで確認する必要があります。(Microsoft Learn)
何が変わるのか：Content hubは「探す場所」から「運用管理の入口」になる
Content hubは単なるカタログではありません。Microsoft Sentinelの組み込みコンテンツを検索し、ソリューションとしてまとめて導入し、更新があるコンテンツを確認し、インストール後の各コンテンツを管理する入口です。
| 確認項目 | 内容 | 実務上の影響 |
|---|---|---|
| ポータル | Microsoft SentinelはMicrosoft Defender portalとAzure portalの両方に適用されるが、2027年3月31日以降はDefender portalのみになる | Azure portal前提の手順書、教育資料、運用フローを見直す |
| Content hubの役割 | 組み込みコンテンツ、ソリューション、スタンドアロンコンテンツを検索・導入・更新・管理する | SOC運用の標準テンプレート管理場所として扱う |
| 検索 | ステータス、コンテンツタイプ、サポート、プロバイダー、カテゴリなどで絞り込み可能 | 必要な検知・可視化・自動化コンテンツを探しやすくなる |
| 展開 | 個別インストール、複数コンテンツの一括インストール・更新、APIによる展開に対応 | 本番展開だけでなく、検証環境やIaC運用にも使える |
| 更新 | ソリューションは更新有無を確認して更新、スタンドアロンコンテンツは自動更新される | 更新後に既存のアクティブルールやカスタム内容が意図通りか確認が必要 |
| 依存関係 | 一部ソリューションはデータコネクタなどの依存関係をまとめて導入できる | CEF、Syslog、カスタムログ、AMA関連の事前確認が重要 |
Content hubでは検索結果の件数に上限があり、検索時はEnterキーで検索を開始する必要があります。目的のソリューションが見つからない場合は、検索語を変える、カテゴリやプロバイダーで絞る、スタンドアロンコンテンツではなくソリューション名で探す、といった操作が有効です。(Microsoft Learn)
対象になる管理者・開発者
この変更の影響を受けるのは、Microsoft Defender製品を使うすべてのユーザーではなく、主にMicrosoft Defender portal上でMicrosoft Sentinelを使う組織です。Microsoft Defender for EndpointやMicrosoft Defender for Office 365だけを単体で使っている場合は、Content hubの運用変更が直接の作業になるとは限りません。
一方で、次の担当者は早めに確認すべきです。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Sentinelワークスペース、Content hub、権限、データコネクタの状態 |
| SOCアナリスト | インシデント、分析ルール、ハンティング、ワークブックの操作場所 |
| SIEM運用担当 | Azure portalからDefender portalへの移行計画 |
| 開発者・自動化担当 | API、ARMテンプレート、Azure CLI、PowerShell、CI/CD展開 |
| MSSP・複数テナント管理者 | 複数ワークスペース、複数テナント、権限境界、運用分担 |
Microsoft SentinelはDefender portalで一般提供されており、Microsoft Defender XDRやE5ライセンスがない顧客でもDefender portal上でMicrosoft Sentinelを利用できるとされています。つまり、「Defender XDRを使っていないから関係ない」と判断せず、Sentinelワークスペースを持っているかどうかで確認するのが実務上は安全です。(Microsoft Learn)
Content hubで扱うコンテンツの種類
Content hubでは、製品や業界、ドメインごとにまとめられた「ソリューション」と、個別に提供される「スタンドアロンコンテンツ」を扱います。ソリューション内の特定コンテンツだけを使いたい場合でも、原則として関連するソリューション全体をインストールする流れになります。(Microsoft Learn)
主なコンテンツタイプは次のとおりです。
| コンテンツタイプ | 役割 | 導入後に確認すべきこと |
|---|---|---|
| Data connector | 外部サービスやログソースからデータを取り込む | 認証、接続状態、ログ検出、重複取り込み |
| Analytics rule | 取り込んだデータからアラートやインシデントを生成する | テンプレートから有効なルールを作成したか |
| Hunting query | 脅威ハンティング用のKQLクエリ | 自社環境のテーブル名、ログ量、期間条件に合うか |
| Workbook | 可視化ダッシュボード | 保存して編集可能なインスタンスを作ったか |
| Parser | ログ形式を扱いやすくする関数 | Log Analyticsのワークスペース関数として使えるか |
| Playbook | Logic Appsベースの自動対応 | 接続情報、権限、実行条件、失敗時の通知 |
注意したいのは、インストールしただけでは運用開始にならないコンテンツが多いことです。たとえば分析ルールはテンプレートを導入した後に有効なルールを作成する必要があり、データコネクタは認証やログ取り込みの設定が必要です。プレイブックもテンプレートから作成した後、接続先サービスの資格情報やLogic Apps側の権限を確認しなければ実運用では動きません。(Microsoft Learn)
展開前に確認すべき権限
Content hubでスタンドアロンコンテンツやソリューションをインストール、更新、削除するには、リソースグループレベルでMicrosoft Sentinel Contributorロールが必要です。Microsoft Sentinelの公式ロール説明でも、Content hubの管理にはMicrosoft Sentinel Contributorが必要とされています。(Microsoft Learn)
権限確認では、次の3点を分けて見るとミスを減らせます。
| 作業 | 必要になる主な権限 | よくある失敗 |
|---|---|---|
| Content hubの閲覧 | Microsoft Sentinel Readerなど | 見えるがインストールできない |
| ソリューションの導入・更新 | Microsoft Sentinel Contributor | ワークスペース単位だけに権限を付け、関連リソースで失敗する |
| プレイブック作成・編集 | Logic App Contributorなど | Sentinel側は操作できるがLogic Appsを編集できない |
| 自動応答の実行 | Playbook Operatorや明示的なサービスアカウント権限 | ルールは作成済みでもプレイブックが実行されない |
| Defender portalへの接続 | Owner、User Access AdministratorとSentinel Contributorなど | Sentinel運用権限とオンボード権限を混同する |
権限は「とりあえずGlobal Administrator」ではなく、必要最小限で割り当てるべきです。Microsoftのドキュメントでも、最小権限のロール利用が推奨されています。(Microsoft Learn)
Microsoft Defender portalへの移行で注意すべき影響範囲
2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defender portalで利用する形になります。このため、Content hubの操作だけでなく、SOC運用全体の導線をDefender portalに合わせて見直す必要があります。(Microsoft Learn)
特に確認すべき影響範囲は次のとおりです。
データコネクタとログ取り込み
Microsoft SentinelをDefender portalに統合しても、既存のデータ収集アーキテクチャやLog Analyticsを使った保存・検索・相関の基本構造は維持されると説明されています。一方で、Microsoft Defender製品に関するアラートはMicrosoft Defender XDR connectorから直接ストリーミングされるため、ワークスペースでインシデントとアラートが有効になっているか確認が必要です。(Microsoft Learn)
また、Defender portalでは一部のDefender系データコネクタがData connectorsページに表示されません。表示されないからといって停止しているとは限らないため、Azure portalの表示とDefender portalの表示を単純比較して「消えた」と判断しないようにしてください。(Microsoft Learn)
分析ルールとインシデント相関
Microsoft Sentinelの分析ルールはDefender portalでも検出、構成、管理できます。ただし、Defender portalに移行すると、インシデントの相関や統合はDefender XDR側のエンジンが大きく関与します。Azure portalでFusion分析ルールに依存していた運用では、Defender portal側の相関ロジックに置き換わる点を理解しておく必要があります。(Microsoft Learn)
実務では、次のような確認が必要です。
| 確認項目 | 見直しポイント |
|---|---|
| アラートのみ生成するルール | Defender portalで見える運用になっているか |
| インシデント名を条件にした自動化 | 相関により名前が変わる可能性を考慮する |
| 複数ルールから発生するインシデント | Defender XDRの相関で統合される可能性を確認する |
| Fusion前提の手順書 | Defender portalの相関・統合を前提に修正する |
自動化ルールとプレイブック
Defender portal移行で特に失敗しやすいのが自動化です。公式ドキュメントでは、インシデントプロバイダー条件、SecurityIncidentテーブルのDescriptionフィールド、プレイブックトリガーの遅延、手動実行の制限など、複数の注意点が挙げられています。(Microsoft Learn)
とくに外部チケットシステムと連携している場合は、インシデント説明文を前提にしたマッピングや条件分岐が壊れる可能性があります。ServiceNowなどに連携している環境では、移行前にテストインシデントを作り、実際にどの項目が渡るか確認してください。
Content hubでソリューションを展開する基本手順
Content hubから個別ソリューションを展開する流れは、次のように整理できます。公式手順では、Content hubで対象ソリューションを選び、詳細画面からCreateまたはUpdateを実行し、サブスクリプション、リソースグループ、ワークスペースを指定して検証後に展開します。(Microsoft Learn)
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Defender portalでMicrosoft Sentinel > Content management > Content hubを開く | 対象ワークスペースが見えるか |
| 2 | ソリューションまたはスタンドアロンコンテンツを検索する | 検索語、カテゴリ、プロバイダーを使い分ける |
| 3 | 詳細ペインで含まれるコンテンツを確認する | データコネクタ、分析ルール、プレイブックの有無 |
| 4 | CreateまたはUpdateを選択する | 既存環境への影響を確認する |
| 5 | サブスクリプション、リソースグループ、ワークスペースを指定する | 本番・検証環境の取り違えに注意 |
| 6 | 必要な資格情報や設定を入力する | 外部サービス連携では認証情報を準備 |
| 7 | Review + createでValidation Passedを確認する | エラー時は権限と依存関係を確認 |
| 8 | CreateまたはUpdateで展開する | 展開後に各コンテンツを有効化・設定する |
ここで重要なのは、CreateまたはUpdateで終わりにしないことです。ソリューションをインストールしても、データコネクタの認証、分析ルールの有効化、ワークブックの保存、プレイブックの接続設定など、追加作業が残る場合があります。(Microsoft Learn)
一括インストール・更新を使うべき場面
Content hubではリストビューから複数のソリューションやスタンドアロンコンテンツを一括でインストール、更新できます。スタンドアロンコンテンツは自動的に最新状態に保たれ、Content hubから作成済みのアクティブコンテンツやカスタムコンテンツはそのまま維持されます。(Microsoft Learn)
一括操作が向いているのは、次のような場面です。
| 場面 | 一括操作が有効な理由 | 注意点 |
|---|---|---|
| 新しい検証ワークスペースを作る | 複数ソリューションをまとめて導入できる | 本番と同じ依存関係を再現する |
| 業界別・製品別の標準セットを入れる | 関連コンテンツを短時間で準備できる | 不要なルールを有効化しない |
| 更新対象が複数ある | Update表示のあるソリューションをまとめて処理できる | 更新後のテンプレート差分を確認する |
| MSSPが複数顧客に展開する | 標準化しやすい | 顧客ごとのログソース差を考慮する |
ただし、一括更新は「自社の検知ルールが自動的に最適化される」という意味ではありません。カスタム済みのアクティブルールや保存済みワークブックは維持されるため、テンプレート更新の内容を本番運用に反映するには、差分確認と手動調整が必要になる場合があります。
依存関係のあるソリューションで失敗しやすいポイント
一部のソリューションには依存関係があります。公式情報では、多くのドメインソリューションや、CEF、Syslog、カスタムログ向けの統合AMAコネクタを使うソリューションで依存関係が発生することが示されています。これらはInstall with dependenciesを使うことで、必要なデータコネクタもまとめてインストールできます。(Microsoft Learn)
展開で失敗しやすいのは次のケースです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| ソリューションは入ったがログが来ない | データコネクタの設定が未完了 | コネクタページを開き、認証とログ検出を確認する |
| CEF/Syslogの検知が動かない | AMA、DCR、コネクタの依存関係が不足 | Install with dependenciesを使い、エージェント構成も確認する |
| 分析ルールが発火しない | テンプレートを入れただけで有効化していない | Analytics ruleテンプレートからCreate ruleを実行する |
| プレイブックが動かない | Logic Appsの接続、権限、実行条件が未設定 | 接続情報とマネージドID、実行権限を確認する |
| 更新後も古い動きのまま | 既存のアクティブルールやカスタム内容が維持されている | テンプレートと既存ルールを比較する |
Content hubの展開作業は、セキュリティ製品のインストール作業というより、ログ、検知、可視化、自動化をつなぐ構成作業です。チェックリストを作らずに本番導入すると、「入れたのに検知しない」「見えているが対応が自動化されない」という状態になりやすいです。
APIやIaCで展開する場合の注意点
開発者やプラットフォームチームがContent hubのコンテンツをコードで展開する場合は、APIレスポンス内のproperties.mainTemplateに含まれるARMテンプレートJSONを取り出し、REST API、Azure CLI、PowerShellなどで展開する流れになります。公式手順では、ソリューションパッケージはGet Product Package API、個別テンプレートはGet Product Template APIで取得するとされています。(Microsoft Learn)
実務では、次の観点を追加で確認してください。
| 確認項目 | 理由 |
|---|---|
| テンプレートのバージョン管理 | 更新後に意図しない差分が入らないようにするため |
| 検証環境での事前展開 | 本番ワークスペースの分析ルールやプレイブックに影響を出さないため |
| 権限の分離 | CI/CD用サービスプリンシパルに過剰権限を与えないため |
| 依存リソースの定義 | Logic Apps、接続、DCR、データコネクタが抜けると動作しないため |
| ロールバック手順 | 削除してもアクティブ・クローン・保存済み・カスタム項目が残る場合があるため |
削除についても注意が必要です。Content hubからソリューションやテンプレートを削除しても、関連するアクティブ項目、クローン、保存済み、カスタム項目は削除されません。不要な検知ルールやワークブックを完全に整理したい場合は、Content hubだけでなく各機能側の作成済みリソースも確認してください。(Microsoft Learn)
サポートモデルを確認してから本番導入する
Content hubの各ソリューションやスタンドアロンコンテンツには、サポートモデルが表示されます。Microsoftがサポートするものもあれば、パートナー名が表示されるものもあります。問い合わせ時には、Publisher、Provider、Plan IDなどの情報が必要になる場合があります。(Microsoft Learn)
本番導入前には、少なくとも次の情報を運用台帳に残しておくと、障害対応や監査時に役立ちます。
| 記録項目 | 例 |
|---|---|
| ソリューション名 | Microsoft Defender XDR、Azure Activityなど |
| バージョン | 導入時点のバージョン |
| サポート元 | Microsoft、パートナー名 |
| 導入ワークスペース | 本番、検証、顧客別ワークスペース |
| 有効化したコンテンツ | 分析ルール、プレイブック、ワークブックなど |
| カスタム変更 | KQL条件、除外条件、しきい値、通知先 |
| 依存関係 | データコネクタ、AMA、DCR、Logic Apps |
| 更新確認日 | 月次、四半期、リリース後など |
特にパートナー提供コンテンツは、Microsoft純正コンテンツと同じ運用保証だと誤解しないことが重要です。サポート元、更新頻度、対象ログソース、前提ライセンスを確認してから有効化しましょう。
移行・展開前の実務チェックリスト
Microsoft Defender portalへの移行やContent hubからの展開を進める前に、次の順で確認すると手戻りを減らせます。
| 順番 | チェック項目 | 完了の目安 |
|---|---|---|
| 1 | Sentinelワークスペースの一覧を棚卸しする | 本番・検証・顧客別のワークスペースが分かる |
| 2 | Azure portal前提の手順書を洗い出す | Content hub、Analytics、Automationなどの画面遷移を特定する |
| 3 | Microsoft Defender portalで対象ワークスペースを確認する | Content hubにアクセスできる |
| 4 | Microsoft Sentinel Contributorなどの権限を確認する | インストール、更新、削除が実行できる |
| 5 | データコネクタの接続状態を確認する | ログが検出され、必要なテーブルに入っている |
| 6 | 分析ルールをテンプレートから有効化する | アクティブルールとして作成済み |
| 7 | プレイブックの接続と権限を確認する | テスト実行できる |
| 8 | 自動化ルールの条件を見直す | インシデント名やDescription依存を避けている |
| 9 | API・CI/CD展開のテンプレートを確認する | mainTemplateと依存リソースを管理できている |
| 10 | 更新・削除・ロールバック手順を決める | 更新後の差分確認と復旧手順がある |
このチェックリストで特に重要なのは、Content hubで導入したテンプレートと、実際にSOCで使うアクティブなコンテンツを分けて管理することです。テンプレートが更新されても、すでにカスタマイズした分析ルールやワークブックが自動的に最適化されるとは限りません。
よくある疑問
Microsoft Defenderの機能だけを使っている場合も対応が必要？
Microsoft Defender for EndpointやMicrosoft Defender for Office 365だけを使っていて、Microsoft Sentinelワークスペースを使っていない場合、この記事のContent hub運用は直接の対象ではありません。ただし、Defender portal上でMicrosoft Sentinelを接続している、またはSIEM/XDR統合を進める予定がある場合は対象になります。
Azure portalのMicrosoft Sentinelはすぐ使えなくなる？
すぐに使えなくなるわけではありませんが、公式情報では2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defender portalのみで利用可能になるとされています。移行期限直前に手順書、権限、SOC教育、API連携をまとめて変更するのはリスクが高いため、早めにDefender portal前提の運用へ寄せるべきです。(Microsoft Learn)
Content hubでインストールすれば検知はすぐ始まる？
始まらない場合があります。データコネクタの設定、ログ取り込み、分析ルールの有効化、プレイブックの接続設定などが必要です。とくに分析ルールは、テンプレートを導入しただけではなく、実際にアクティブルールを作成しているか確認してください。(Microsoft Learn)
既存のカスタムルールは更新で上書きされる？
Content hubの一括インストール・更新では、Content hubをもとに作成されたアクティブコンテンツやカスタムコンテンツはそのまま維持されます。そのため、テンプレート更新を自社の既存ルールに反映したい場合は、差分を確認して手動で調整する運用が必要です。(Microsoft Learn)
管理者が次に取るべき行動
まず、Microsoft Sentinelを利用しているワークスペースを棚卸しし、Azure portal前提の手順や自動化が残っていないか確認してください。次に、Microsoft Defender portalでContent hubにアクセスし、よく使うソリューション、更新があるソリューション、依存関係のあるソリューションを洗い出します。
本番展開では、Content hubからのインストールをゴールにせず、データコネクタ、分析ルール、ワークブック、プレイブック、API連携、サポートモデルまで確認することが重要です。2027年3月31日の移行期限を待たず、検証環境からDefender portal前提の運用に切り替えておくことで、SOCの手順変更や自動化の修正を段階的に進められます。
コメント