Microsoft Sentinelは、クラウドネイティブなSIEMであり、Microsoft Defenderポータル上で利用できる統合セキュリティプラットフォームです。2026年5月14日に更新された公式情報では、従来の「ログを集めて検知するSIEM」という位置づけに加え、データレイク、グラフ分析、MCP、Security Copilot連携を前提にしたAI主導のセキュリティ運用基盤として整理されています。(Microsoft Learn)
管理者がまず押さえるべき結論は3つです。Microsoft SentinelはMicrosoft Defenderポータルでの利用が中心になり、AzureポータルでのSentinel利用は2027年3月31日以降サポートされなくなります。次に、データ保持は「リアルタイム分析向けのAnalytics tier」と「長期保管向けのData lake tier」を使い分ける設計が重要になります。最後に、インシデント相関、自動化ルール、API、RBAC、データコネクタの見え方が変わるため、既存環境は単なる画面移行ではなく、SOC運用全体の見直しが必要です。(Microsoft Learn)
Microsoft Sentinelとは何か
Microsoft Sentinelは、複数のクラウド、オンプレミス、エンドポイント、ID、アプリケーション、ネットワーク機器などからセキュリティデータを収集し、脅威の検知、調査、ハンティング、対応、自動化を行うSIEMです。公式情報では、Microsoft Sentinelを「cloud-native SIEM」かつ「agentic defenseのための統合セキュリティプラットフォーム」と説明しています。(Microsoft Learn)
ここで重要なのは、Microsoft Sentinelが「Microsoft Defenderの一機能」だけではない点です。Microsoft Defenderポータルで利用できるようになったことで、Defender XDR、Microsoft Entra、Microsoft Purview、Microsoft 365、Azure、AWS、GCP、サードパーティ製品のデータを横断して扱いやすくなりました。一方で、課金、ワークスペース、データ保持、コネクタ、KQL、Logic Appsによる自動化など、従来のSentinel運用で必要だった設計要素は引き続き残ります。(Microsoft Learn)
SIEMとしての役割
SIEMとしてのMicrosoft Sentinelは、セキュリティログを収集し、分析ルールや脅威インテリジェンスを使ってインシデントを生成し、SOCアナリストが調査・対応できる状態にするサービスです。Microsoft Sentinelには多数のデータコネクタが用意されており、Microsoft製品だけでなく、マルチクラウドやサードパーティ製品のログも取り込めます。(Microsoft Learn)
具体的には、次のような用途に向いています。
| 用途 | 具体例 | 実務上のポイント |
|---|---|---|
| 脅威検知 | 不審なサインイン、権限昇格、マルウェア検知、異常な通信 | 既定の分析ルールをそのまま使うだけでなく、自社の重要資産や業務時間に合わせて調整する |
| インシデント調査 | ユーザー、端末、IP、クラウドリソースを横断して確認 | Defenderポータルでは統合インシデントキューで複数製品のアラートをまとめて見られる |
| ハンティング | KQLで過去ログから未知の脅威を探索 | ルール化する前の仮説検証に使う。検知できたクエリは分析ルール化を検討する |
| 自動対応 | チケット作成、通知、アカウント無効化、端末隔離など | Logic Appsベースのプレイブックを使う。移行時はトリガー条件の見直しが必要 |
| 長期調査 | 数か月から年単位のログを使った侵害範囲確認 | Data lake tierを使うと長期保持に向くが、リアルタイム検知には向かない |
2026年5月14日更新情報で押さえるべき変更点
2026年5月14日更新の公式概要では、Microsoft Sentinelの説明が「SIEM」だけではなく、「SIEM and platform」として整理されています。つまり、単にアラートを出す製品ではなく、セキュリティデータをAI、グラフ分析、エージェント、自動化に使うための基盤として扱う方向が明確になっています。(Microsoft Learn)
| 変更・強調点 | 内容 | 管理者への影響 |
|---|---|---|
| Defenderポータル中心の運用 | Microsoft SentinelはDefenderポータルで一般提供され、Defender XDRやE5なしでも利用可能 | Azureポータル前提の手順書、教育資料、運用フローを更新する |
| Azureポータル利用の終了予定 | 2027年3月31日以降、AzureポータルでMicrosoft Sentinelはサポートされず、Defenderポータルのみになる | 2027年を待たずに検証環境から移行リハーサルを始める |
| データレイクの重視 | 長期保持、フォレンジック、KQLジョブ、Notebook分析に使える基盤として整理 | ログをすべて高価なリアルタイム分析対象にするのではなく、用途別に保持階層を設計する |
| Sentinel graph | ユーザー、端末、クラウドリソース、データフロー、攻撃経路をノードとエッジで分析 | インシデント単位ではなく、侵害経路や影響範囲で調査できるようになる |
| MCPサポート | 自然言語でのデータ探索やセキュリティエージェント構築を支援 | AIエージェントの権限、監査、利用範囲をあらかじめ定義する必要がある |
| 開発者向け拡張 | Security StoreやContent Hub向けにコネクタ、分析ルール、プレイブック、エージェントなどを構築可能 | 自社・パートナー製ソリューションをSentinel上で展開する選択肢が広がる |
Microsoft Defenderとの関係を整理する
Microsoft Defenderは、エンドポイント保護、クラウドセキュリティ、ID保護、メールセキュリティ、脅威インテリジェンス、露出管理、SIEMを統合するセキュリティ運用基盤として位置づけられています。その中でMicrosoft Sentinelは、SIEM機能とセキュリティデータ基盤を担います。(Microsoft Learn)
実務上は、次のように考えると分かりやすくなります。
| 領域 | 主な役割 | 例 |
|---|---|---|
| Microsoft Defender XDR | Microsoft製品群のXDR。エンドポイント、ID、メール、クラウドアプリなどの検知・対応 | Defender for Endpoint、Defender for Office 365、Defender for Identityなど |
| Microsoft Sentinel | SIEM。Microsoft以外も含むログ収集、相関分析、ハンティング、自動化 | AWS、GCP、ファイアウォール、Syslog、独自アプリログなど |
| Microsoft Defenderポータル | SIEMとXDRを横断する統合運用画面 | 統合インシデント、Advanced hunting、エンティティページ、Security Copilot連携 |
注意したいのは、「Defenderポータルで使うようになったからSentinelの設計が不要になる」わけではないことです。既存のMicrosoft Sentinelワークスペース、Log Analytics、KQL、コネクタ、分析ルール、プレイブックは引き続き重要です。Microsoftの移行ガイドでも、Defender統合後もデータ収集の基本構造やLog Analyticsとの統合は維持されると説明されています。(Microsoft Learn)
影響を受ける担当者
今回の変更は、SOCアナリストだけでなく、管理者、開発者、運用設計者、コスト管理者にも影響します。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| SOCアナリスト | インシデント画面、ハンティング画面、エンティティ調査の導線が変わる | AzureポータルとDefenderポータルのメニュー差分、統合インシデントキューの使い方 |
| Sentinel管理者 | ワークスペースのDefenderポータル移行、権限、コネクタ表示が変わる | Microsoft Defender XDR connector、Defender for Cloud連携、重複アラート |
| セキュリティアーキテクト | SIEMとXDRを前提にした運用設計が必要 | インシデント相関、データ保持、マルチワークスペース、マルチテナント管理 |
| 自動化・開発担当 | API、Logic Apps、プレイブック、MCP、Security Copilot連携に影響 | Microsoft Graph API、SecurityInsights API、トリガー条件、権限範囲 |
| コスト管理者 | Analytics tierとData lake tierの使い分けがコストに直結 | 30日、90日、2年、12年などの保持期間設定と追加コスト |
| コンプライアンス担当 | データ保持、暗号化、データ所在、RBACの扱いを再確認する必要 | CMK、IdentityInfoテーブル、データレイクの暗号化方式 |
管理者が最初に確認すべき設定
Defenderポータルへの移行状況
既存のMicrosoft Sentinel環境をAzureポータルで運用している場合、最初に確認すべきなのは、対象ワークスペースがDefenderポータルにオンボード済みかどうかです。公式情報では、2027年3月31日以降、Microsoft SentinelはAzureポータルではサポートされず、Defenderポータルのみで利用可能になると案内されています。(Microsoft Learn)
特に注意が必要なのは、新規顧客と既存顧客で挙動が異なる点です。2025年7月以降、新規顧客がテナント内で最初のSentinelワークスペースをオンボードし、かつサブスクリプションのOwnerまたはUser Access Administrator権限を持つ場合、ワークスペースはDefenderポータルへ自動オンボードされると説明されています。一方、既存顧客がワークスペースを追加するケースなどでは、自動オンボードされない場合があります。(Microsoft Learn)
確認時は、次の順で進めると失敗しにくくなります。
| 手順 | 確認内容 | 見落としやすい点 |
|---|---|---|
| ワークスペース棚卸し | Sentinel有効化済みのLog Analyticsワークスペースを一覧化する | 複数サブスクリプション、MSSP管理、検証環境を漏らしやすい |
| Defenderポータル接続 | 各ワークスペースがDefenderポータルで見えるか確認する | 自動オンボード対象外のワークスペースが残ることがある |
| 権限確認 | Microsoft Sentinel Contributor、Reader、Azure RBAC、Defender側RBACを確認する | 画面が見える人と設定変更できる人が一致しないことがある |
| 運用手順更新 | インシデント調査、ハンティング、ワークブック、分析ルールの操作場所を更新する | 旧Azureポータルのスクリーンショット付き手順がそのまま使えない |
| 教育・リハーサル | SOC担当者にDefenderポータルでの調査手順を試してもらう | 本番切替直前に操作導線の違いが判明しやすい |
データコネクタと重複アラート
Defenderポータルへ移行しても、Microsoft Sentinelの既存コネクタやデータ取り込みパイプラインが一律に作り直されるわけではありません。Microsoftの移行ガイドでは、既存のデータコネクタは継続して動作し、Log Analyticsへの取り込みパイプラインやデータスキーマにも基本的な変更はないと説明されています。(Microsoft Learn)
ただし、Defender製品のアラートはMicrosoft Defender XDR connectorから直接ストリーミングされるため、コネクタの設定とインシデント・アラートの有効化状態を確認する必要があります。また、Defender for Cloudを利用している場合は、テナントベースのコネクタと従来のサブスクリプションベースのコネクタで重複イベントや重複アラートが発生しないよう注意が必要です。(Microsoft Learn)
見落としやすいのは、Defenderポータルにオンボード後、一部のDefender系データコネクタがDefenderポータルのData connectorsページに表示されなくなる点です。表示されないから停止しているのではなく、統合セキュリティ運用で使われるコネクタとして扱われる場合があります。(Microsoft Learn)
分析ルールとインシデント相関
Microsoft Sentinelの分析ルールは、Defenderポータルでも作成、更新、管理できます。機能自体は大きく変わりませんが、インシデント相関の考え方は変わります。移行後は、Defender XDRの相関エンジンがアラートを統合し、Fusion分析ルールによる相関はDefender側の相関機能に置き換えられます。(Microsoft Learn)
この変更は、SOCの運用に直接影響します。たとえば、これまで「1つの分析ルールから1つのインシデントが作られる」と想定してチケットを切っていた場合、Defenderポータルでは複数のアラートが1つのインシデントに統合されることがあります。逆に、アラートのみを生成し、インシデント作成を無効にしている分析ルールは、Defenderポータルで見えない可能性があります。(Microsoft Learn)
実務では、次の観点で分析ルールを点検してください。
| 点検項目 | 確認すべき内容 |
|---|---|
| インシデント作成設定 | アラートのみのルールがないか。Defenderポータルで運用上見える必要があるか |
| ルール名 | 自動化ルールや外部連携が分析ルール名を条件にしていないか |
| 重大度 | Defender側の相関で別アラートと統合されたとき、優先度判断が破綻しないか |
| Fusion依存 | Fusionルール前提の運用手順をDefender XDR相関前提に更新しているか |
| カスタム検知 | Defender XDRデータとSentinelデータを横断する場合、Advanced huntingのカスタム検知を使うべきか |
自動化ルールとプレイブック
Microsoft SentinelのプレイブックはAzure Logic Appsをベースにしています。Defenderポータル移行後も自動化は重要ですが、トリガー条件や実行タイミングに注意が必要です。公式の移行ガイドでは、アラートトリガー、インシデントトリガー、SecurityIncidentテーブル、手動実行、インシデント同期などに関する制限や変更点が整理されています。(Microsoft Learn)
特に影響が大きいのは、SecurityIncidentテーブルのDescriptionフィールドです。Defenderポータルへのオンボード後、SecurityIncidentテーブルにDescriptionフィールドが含まれなくなるため、このフィールドを条件にした自動化ルールや、ServiceNowなど外部チケットシステムへの連携は見直しが必要です。(Microsoft Learn)
また、Defenderポータルではインシデント名が相関処理によって変わる可能性があります。自動化ルールの条件にインシデントタイトルを使っていると、移行後に想定外の動作をするおそれがあります。条件には、分析ルール名、タグ、重大度、エンティティ、カスタムフィールドなど、より安定した情報を使うべきです。(Microsoft Learn)
データ保持とコスト設計のポイント
2026年時点のMicrosoft Sentinelでは、データ保持を「Analytics tier」と「Data lake tier」で使い分ける設計が重要です。Analytics tierはリアルタイム分析、アラート、ハンティング、ワークブックなどに向いた高性能な保持領域です。一方、Data lake tierは長期保管、監査、フォレンジック、履歴分析に向く低コストな保持領域です。(Microsoft Learn)
| 項目 | Analytics tier | Data lake tier |
|---|---|---|
| 向いている用途 | リアルタイム検知、分析ルール、ハンティング、ワークブック | 長期保管、監査、フォレンジック、履歴傾向分析 |
| クエリ性能 | 高性能な対話型クエリに向く | リアルタイム分析には不向き。KQLジョブやNotebookで利用 |
| 機能制限 | Sentinel機能を広く利用できる | 分析ルール、ハンティング、ワークブック、プレイブックなど一部用途に制限 |
| 保持期間の考え方 | 既定では30日。条件により90日や最大2年まで拡張可能 | Analytics保持を超えて最大12年までの長期保持に対応 |
| コスト設計 | 検知に必要なログだけを残す | 低頻度参照ログや長期証跡を保管する |
重要なのは、「Data lake tierに移せばすべて解決」ではないことです。公式情報では、テーブルをAnalytics tierからData lake tierへ変更すると、リアルタイム分析とハンティングクエリが動作しなくなると説明されています。検知ルールに必要なログまでData lake tierのみにしてしまうと、アラートが出なくなるリスクがあります。(Microsoft Learn)
設計の目安は次の通りです。
| ログの種類 | 推奨される考え方 |
|---|---|
| 侵害検知に直結するログ | Analytics tierに保持。例：サインイン、端末イベント、重要サーバーの監査ログ |
| 調査時だけ参照する大量ログ | Data lake tierを検討。例：長期のDNS、プロキシ、ファイアウォールログ |
| コンプライアンス証跡 | Data lake tierで長期保持を検討。ただし検索頻度と要件を確認 |
| Defender XDRのハンティングデータ | 既定の30日を超える保持では、取り込みやストレージのコスト影響を確認 |
| 独自アプリログ | 検知に使う項目だけAnalytics tier、詳細ログはData lake tierなど分離を検討 |
Microsoft Sentinel data lakeで何ができるのか
Microsoft Sentinel data lakeは、セキュリティデータを長期に保持し、KQL、Jupyter notebooks、Pythonライブラリ、機械学習、ジョブ実行などで分析するための基盤です。公式情報では、単一コピーのオープン形式データ、ストレージとコンピュートの分離、複数分析エンジンのサポートが特徴として説明されています。(Microsoft Learn)
現場で使いやすいシナリオは、次のようなものです。
| シナリオ | 活用例 |
|---|---|
| 長期侵害調査 | 90日を超える過去ログから、攻撃者の初期侵入や横展開の痕跡を確認する |
| ベースライン作成 | 数か月分のログから通常時の通信量、サインイン傾向、ユーザー行動を把握する |
| フォレンジック | アラート発生時点だけでなく、前後数か月の関連アクティビティを分析する |
| コスト最適化 | すべてのログをリアルタイム検知対象にせず、低頻度ログを長期保管する |
| Notebook分析 | Pythonや機械学習ライブラリを使い、標準機能では難しい分析を行う |
ただし、Data lake tierは「低コストで長期保存できる検知基盤」ではなく、「長期保存と深い分析に向いた基盤」と考えるべきです。リアルタイムアラートに必要なログは、Analytics tierに保持する必要があります。
Microsoft Sentinel graphの意味
Microsoft Sentinel graphは、ユーザー、デバイス、クラウドリソース、アクティビティ、脅威インテリジェンスなどの関係性をグラフとして分析する機能です。従来の表形式データでは見えにくい「どのアカウントが侵害されたら、どの重要資産に到達できるか」「このファイル流出の影響範囲はどこまでか」といった問いに答えやすくなります。(Microsoft Learn)
たとえば、単一の不審サインインだけを見ると重要度が低く見えるケースでも、そのユーザーが特権グループに所属し、重要サーバーへアクセスでき、過去に機密ファイルへアクセスしていた場合、対応優先度は大きく変わります。グラフ分析は、こうした「点」ではなく「つながり」を見るための仕組みです。
Defender XDRでは、Blast RadiusやHunting graphのようなグラフベースの機能にもつながります。Microsoft Purview側でも、データ流出の影響範囲や機密データの移動を理解する用途でグラフが使われます。(Microsoft Learn)
MCPとSecurity Copilot連携で変わること
Microsoft SentinelのMCPサポートは、セキュリティデータを自然言語で探索したり、セキュリティエージェントを構築したりするための仕組みです。公式情報では、Microsoft Entraを使ったID管理、ホスト型のMCPサーバー、自然言語によるデータ探索、Microsoft Sentinel data lakeやMicrosoft Defenderとの統合が説明されています。(Microsoft Learn)
実務で期待できるのは、次のような使い方です。
| 用途 | 例 |
|---|---|
| データ探索 | 「過去180日でこのユーザーに関連する異常なファイル操作を探して」といった自然言語ベースの調査 |
| エンティティ分析 | URL、ユーザー、端末などを複数データソースからまとめて評価 |
| エージェント作成 | SOCの定型作業を自然言語で定義し、調査補助エージェントを構築 |
| コンテキスト収集 | インシデント調査時に関連ログ、エンティティ、脅威情報を自動で集約 |
ただし、本番導入では慎重な設計が必要です。AIエージェントは便利ですが、強い権限を持たせすぎると、誤操作や情報漏えいのリスクが高まります。最初は「読み取り専用の調査補助」「限定されたテーブルへのアクセス」「SOC内の検証用途」から始め、監査ログ、承認フロー、権限分離を確認してから対応自動化に広げるのが安全です。
開発者が確認すべきポイント
開発者やセキュリティエンジニアにとって、Microsoft Sentinelは単なる運用ツールではなく、セキュリティソリューションを構築・配布するプラットフォームにもなります。公式情報では、コネクタ、分析ルール、ハンティングクエリ、プレイブック、Jupyter notebook jobs、Security Copilot agentsなどを組み合わせ、Microsoft Security StoreやMicrosoft Sentinel Content Hubを通じてソリューションを提供できると説明されています。(Microsoft Learn)
開発時に特に重要なのは、データ正規化です。Microsoft SentinelではASIMを使い、サードパーティ製品のログを共通スキーマに変換することで、SOCアナリストが個別製品の細かいスキーマを覚えなくても分析ルールやハンティングクエリを使えるようにできます。(Microsoft Learn)
開発者向けのチェックポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| コネクタ | どのログを、どの頻度で、どのテーブルへ取り込むか |
| スキーマ | ASIMなどの正規化スキーマに対応できるか |
| 分析ルール | 誤検知を抑えつつ、実務で使える重大度・説明・エンティティを付与しているか |
| ハンティングクエリ | 検知ルール化前の調査に使えるサンプルを用意しているか |
| プレイブック | 通知だけでなく、チケット起票、隔離、証跡収集などの運用まで考えているか |
| API | 統合インシデントやアラートにはMicrosoft Graph REST APIの利用を検討しているか |
| 配布 | Content Hub、Security Store、リポジトリ管理、CI/CDの方針を決めているか |
APIと外部連携で注意すべきこと
Defenderポータルの統合体験では、インシデントやアラートのAPI利用にも変更があります。公式移行ガイドでは、統合インシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨され、Microsoft Sentinel APIは分析ルールや自動化ルールなどSentinelリソースに対する操作を引き続きサポートすると説明されています。(Microsoft Learn)
外部チケットシステムやSOAR、独自ダッシュボードを使っている場合は、次の項目を必ず確認してください。
| 確認項目 | 変更の影響 |
|---|---|
| インシデントURL | providerIncidentUrlなどDefender側のURLを使う必要がある場合がある |
| providerName | Azure SentinelではなくMicrosoft XDRとして扱われるケースがある |
| alertProductNames | 取得時に?$expand=alertsが必要になる場合がある |
| serviceSource / detectionSource / productName | Defenderポータル側で製品・検知元を判断するために重要 |
| SecurityIncidentのDescription | 移行後に利用できないため、チケット本文生成や条件分岐を見直す |
外部連携の失敗は、移行後すぐに表面化しないことがあります。たとえば、チケットは作成されるが説明文が空になる、重大度のマッピングだけずれる、リンク先が旧ポータルのままになる、といった部分的な不具合が起こりやすいです。移行テストでは、単に「APIが200を返すか」ではなく、「SOC担当者がそのチケットを見て対応を開始できるか」まで確認してください。
RBAC、CMK、データ保護の確認ポイント
Defenderポータルへの移行では、権限とデータ保護も重要です。Microsoftの移行ガイドでは、Azureポータル利用時はMicrosoft Sentinel側のデータ保存・処理・保持・共有ポリシーが適用され、Defenderポータル利用時はMicrosoft Defender XDR側のポリシーが適用されると説明されています。(Microsoft Learn)
CMKを使っている環境では、移行前に有効化済みのワークスペースログデータは引き続きCMKで暗号化されますが、オンボード後のアラートやインシデントはCMK暗号化の対象外になると説明されています。また、Microsoft Sentinel data lakeに格納されるデータではCMKが完全にはサポートされず、Microsoft管理キーで暗号化される点にも注意が必要です。(Microsoft Learn)
さらに、IdentityInfoテーブルにも注意が必要です。移行後、IdentityInfoテーブルはAdvanced Hunting側でも利用できますが、Defender側ではテーブルレベルRBACがサポートされないと説明されています。AzureポータルでIdentityInfoへのアクセスをテーブルレベルRBACで制限している組織は、移行後のアクセス制御を見直す必要があります。(Microsoft Learn)
移行・展開時の実践チェックリスト
Microsoft SentinelをDefenderポータル中心の運用へ移す場合は、次の順番で進めると安全です。
| フェーズ | やること | 成功基準 |
|---|---|---|
| 現状把握 | ワークスペース、コネクタ、分析ルール、プレイブック、API連携を棚卸しする | どの設定が本番影響を持つか一覧化できている |
| 権限設計 | Azure RBAC、Sentinelロール、Defender側RBAC、テーブルレベルRBACを確認する | SOC、管理者、外部委託先の権限が最小権限になっている |
| 検証環境 | 代表的なワークスペースをDefenderポータルで検証する | インシデント、ハンティング、コネクタ、ワークブックが操作できる |
| 検知確認 | 既存の分析ルールとカスタム検知を動作確認する | 重要アラートが欠落せず、重複も許容範囲に収まっている |
| 自動化確認 | Logic Apps、通知、チケット起票、隔離処理を検証する | トリガー条件、遅延、チケット内容、実行権限に問題がない |
| API確認 | Microsoft Graph APIとSentinel APIの使い分けを確認する | 外部システムが正しいURL、製品名、重大度、説明を受け取れる |
| データ保持設計 | Analytics tierとData lake tierの対象テーブルを決める | 検知に必要なログはAnalytics、長期証跡はData lakeに分けられている |
| 教育 | SOCアナリスト向けに新しい画面導線と調査手順を共有する | 旧ポータルを見なくても一次対応が完結できる |
| 本番移行 | 影響の少ないワークスペースから段階的に進める | 重大インシデント対応、通知、監査ログに問題がない |
| 移行後監視 | 誤検知、見逃し、コスト、クエリ性能、プレイブック失敗を確認する | 移行前後の検知件数と対応時間を比較できる |
失敗しやすいポイント
「Defenderポータルに移れば移行完了」と考える
画面が変わるだけなら簡単ですが、実際にはインシデント相関、自動化ルール、API、RBAC、データ保持、SOC手順まで影響します。特に、外部チケット連携やプレイブックは、移行後に一見動いているように見えても、説明文の欠落やトリガー遅延が起こる可能性があります。(Microsoft Learn)
Data lake tierに検知用ログを移してしまう
Data lake tierは長期保管には便利ですが、リアルタイム分析やハンティングには制限があります。分析ルールで使うログまでData lake tierのみにすると、検知が止まる可能性があります。ログごとに「即時検知に使うか」「調査時だけ参照するか」を分けて判断してください。(Microsoft Learn)
インシデントタイトルを自動化条件に使う
Defenderポータルでは、相関エンジンによってインシデント名が変わる可能性があります。自動化条件にタイトルを使うと、移行後にルールが実行されない、または想定外のインシデントで実行されるリスクがあります。分析ルール名やタグを使うほうが安定します。(Microsoft Learn)
旧ポータル前提の教育資料を残す
AzureポータルとDefenderポータルでは、メニューの場所が変わります。たとえば、ログ調査はAdvanced hunting、インシデントはDefenderポータルのIncidents、Threat intelligenceはIntel managementなど、操作導線を更新する必要があります。(Microsoft Learn)
MCPやAIエージェントを権限設計なしで使い始める
MCPやSecurity Copilot連携は、調査効率を高める可能性があります。ただし、自然言語で広範囲のデータを扱えるからこそ、誰がどのデータにアクセスできるか、プロンプトや出力をどう監査するか、どこまで自動対応を許可するかを事前に決めるべきです。
まず何から始めるべきか
既存のMicrosoft Sentinel環境がある場合、最初にやるべきことは「Defenderポータルで同じ運用ができるか」を確認することです。具体的には、ワークスペース、コネクタ、分析ルール、プレイブック、API連携、データ保持設定を一覧化し、Defenderポータル上での動作を検証します。
新規導入の場合は、最初からDefenderポータル中心で設計し、ログをすべてAnalytics tierに入れるのではなく、検知対象ログと長期保存ログを分けて設計してください。SOC運用では、統合インシデントキュー、Advanced hunting、エンティティページ、Security Copilot、Data lake、Graphをどう使い分けるかを最初に決めておくと、後からの手戻りを減らせます。
Microsoft Sentinelは、単なるSIEMから、Microsoft Defenderポータルを中心としたAI時代のセキュリティ運用基盤へ広がっています。2027年3月31日のAzureポータルサポート終了を待つのではなく、今のうちに移行計画、保持階層、権限、自動化、外部連携を点検しておくことが、安定したSOC運用への近道です。
コメント