Microsoft Sentinel / Microsoft DefenderのUnified SecOps移行で、2026年4月更新の最大ポイントは「どのポータルを使うか」ではありません。結論から言うと、これはSOCのデータ設計、検知設計、権限設計、自動化、コンプライアンス運用を見直すセキュリティアーキテクチャの判断です。
Microsoftは2026年4月23日の公式記事で、Unified SecOps transitionを単なるポータル移行ではなく、2階層データアーキテクチャ、グラフベース調査、AIエージェントを前提にしたSOC運用モデルへの転換として位置付けています。さらにMicrosoft Sentinelは、2027年3月31日以降Azure portalでサポートされず、Microsoft Defender portalでのみ利用される予定です。つまり、今後の移行計画では「画面が変わる」だけでなく、「何をリアルタイム検知に残し、何を長期分析に回し、誰がどこまで操作できるか」を決める必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Sentinel / Microsoft DefenderのUnified SecOps移行で何が変わったか
今回の更新で押さえるべき考え方は明確です。Microsoft SentinelをAzure portalからMicrosoft Defender portalへ移す作業は、既存ログを別環境へ丸ごと移す「データ移行」ではありません。既存のLog Analyticsワークスペースやデータ収集の基本構造は維持されますが、インシデント相関、権限、分析ルール、自動化、API、データ保持ポリシーの扱いが変わります。(Microsoft Learn)
特に影響が大きいのは、次の4点です。
| 観点 | 従来の見方 | 2026年4月更新で重視すべき見方 |
|---|---|---|
| ポータル | Azure portalからDefender portalへ移る | SIEMとXDRを統合したSOC運用基盤へ移る |
| ログ設計 | すべてを同じ感覚でSentinelに取り込む | 分析層とData Lake層を使い分ける |
| インシデント | Sentinel側の分析ルール単位で確認する | Defender XDRの相関エンジンで攻撃ストーリーとして見る |
| 権限 | Azure RBAC中心に考える | Unified RBAC、Azure RBAC、Entra IDロールの関係を整理する |
| 自動化 | 既存のLogic AppsやAPI連携をそのまま使う | スキーマ差分、incident provider、チケット連携を検証する |
重要なのは、移行のゴールを「Defender portalでSentinelが見える状態」に置かないことです。ゴールは、SOCがより少ないノイズで、より広い文脈を持ち、より長い期間の証跡を使って調査できる状態にすることです。
まず確認すべき公式スケジュール
Microsoft SentinelはMicrosoft Defender portalで利用できる統合セキュリティ運用体験に移行しており、2027年3月31日以降、Azure portalでのMicrosoft Sentinelはサポートされなくなる予定です。Microsoft Learnでも、Azure portalでMicrosoft Sentinelを利用している顧客に対し、Defender portalへの移行計画を開始するよう案内されています。(Microsoft Learn)
ここで誤解しやすいのは、「期限まで何もしなくてよい」という考え方です。画面上の切り替え自体は短時間で済むケースがありますが、実務上の確認には時間がかかります。特に以下の環境では、早めの棚卸しが必要です。
- 複数ワークスペース、複数テナントでSOCを運用している
- ServiceNow、Jira、独自チケットシステムとインシデント連携している
- Logic Appsプレイブックで自動隔離、通知、承認フローを組んでいる
- Defender for Cloud、Defender XDR、Microsoft Entra ID Protectionなど複数のMicrosoft Security製品を併用している
- CMK、データ所在地、監査証跡、保持期間に厳しい要件がある
移行期限はポータルの話ですが、準備すべき対象はポータルだけではありません。
更新ポイント：2階層データアーキテクチャが移行判断の中心になる
Unified SecOps移行で最も重要なのは、Microsoft Sentinel Data Lakeを含む2階層のデータ設計です。
Microsoft Sentinel Data Lakeは、大量のセキュリティデータを長期保持し、KQLやJupyter notebooksなどで分析できるクラウドネイティブなセキュリティデータレイクです。Microsoftのドキュメントでは、Analytics tierはリアルタイム分析、アラート、インシデント管理向け、Data lake tierは長期保持、KQLジョブ、Pythonベースの高度分析向けと説明されています。Data Lake層では最大12年の保持が可能です。(Microsoft Learn)
分析層とData Lake層の使い分け
| データ種別 | 推奨される配置 | 判断理由 |
|---|---|---|
| Entra IDサインインログ | 分析層、必要に応じてData Lakeにも保持 | パスワードスプレー、不審なサインイン、侵害調査の両方で使う |
| Defender for Endpointの高重要度アラート | 分析層 | インシデント対応で即時性が必要 |
| Firewallのセッションログ | Data Lake層中心 | 大量で、主用途は長期ハンティングやフォレンジックになりやすい |
| DNSクエリログ | Data Lake層中心、一部は分析層 | C2通信や長期的な異常検知に有効だが、全量リアルタイム検知は高コストになりやすい |
| 特権ID操作ログ | 分析層 | 権限昇格や管理操作は即時検知が必要 |
| 監査・規制対応用ログ | Data Lake層 | 長期保存と調査時アクセスを重視する |
ポイントは、「安いからData Lakeに置く」ではなく、「リアルタイムに検知すべきか、後から深く調査できればよいか」で分けることです。
たとえば、Entra IDサインインログはリアルタイム検知にも、数か月後の侵害範囲調査にも使われます。このようなデータは、分析層だけ、またはData Lake層だけで考えるより、検知要件と調査要件の両方から設計する必要があります。
Defender XDRの相関エンジンを前提にインシデント運用を見直す
Unified SecOpsでは、SIEMとXDRのインシデントを別々に追うのではなく、Microsoft Defender portal上の統合インシデントキューで横断的に調査する流れが中心になります。
Microsoftの移行ガイドでは、Defender portalの統合インシデントキューが複数製品のインシデントを1か所に集約し、攻撃者の横展開のような複数ドメインにまたがるアラートを関連付けて管理できると説明されています。Defenderの相関エンジンは、別々のアラートやインシデントに共通要素を認識した場合、それらを統合して攻撃ストーリーを示します。(Microsoft Learn)
たとえば、次のような攻撃は従来のSIEM運用では分断されやすいパターンです。
- 端末で情報窃取マルウェアを検知
- 盗まれたセッション Cookie や資格情報でEntra IDに不審なサインイン
- Exchangeで転送ルールが作成される
- SharePointやOneDriveからデータが外部に持ち出される
従来は、エンドポイント、ID、メール、DLPの担当者が別々のアラートを見ることがありました。Unified SecOpsでは、これらを1つの攻撃の流れとして見る設計に近づきます。
SOC運用で見直すべき点
統合インシデントキューを使うと、アナリストの作業は効率化されます。一方で、担当範囲が広がるため、単に「アラートを閉じる人」ではなく、ID、端末、メール、クラウドアプリ、データ保護を横断して読む力が必要になります。
実務では、次のように運用を変更すると効果が出やすくなります。
| 見直し対象 | 変更前 | 変更後 |
|---|---|---|
| 一次トリアージ | 製品別、アラート別に確認 | インシデント単位で攻撃ストーリーを確認 |
| エスカレーション | 端末担当、ID担当、メール担当へ個別依頼 | インシデント内のエンティティと攻撃段階で判断 |
| チケット起票 | アラートごとに起票 | 統合インシデント単位で起票し、重複を抑える |
| クローズ基準 | 単一アラートの真偽で判断 | 影響範囲、侵害経路、再発防止まで確認 |
この変更をしないままポータルだけ移すと、統合インシデントが「見慣れない大きなチケット」に見え、逆に現場が混乱します。移行前に、インシデント分類、重要度判定、担当分担、クローズ条件を更新しておくべきです。
Sentinel Graphで「点のログ」から「関係性の調査」へ進む
Microsoft Sentinel Graphは、ユーザー、デバイス、クラウドリソース、データ、脅威インテリジェンスなどの関係性をグラフとして扱う機能です。従来の表形式ログでは答えにくい「侵害されたアカウントの影響範囲はどこまでか」「どの経路で重要資産へ到達できるか」といった問いに対応しやすくなります。(Microsoft Learn)
セキュリティ管理者にとっては、これは単なる可視化機能ではありません。検知後の判断基準が変わります。
たとえば、同じ「ユーザーAの不審なサインイン」でも、次の2つでは対応優先度が違います。
| ケース | 判断 |
|---|---|
| 一般ユーザーで、重要システムへのアクセス権がない | 端末確認、パスワードリセット、追加監視を優先 |
| 特権ロールを持ち、複数のサービスプリンシパルやKey Vaultに接続している | 即時封じ込め、権限剥奪、関連資産の調査を優先 |
この違いをログの検索だけで毎回判断するのは時間がかかります。Graphを使うと、エンティティ間の関係をもとに、影響範囲や攻撃経路を調査しやすくなります。
Security CopilotとMCPは「分析補助」から「SOCの自動化基盤」へ広がる
今回のMicrosoft公式記事では、AIエージェントを前提にしたSOC、いわゆるAgentic SOCへの準備も強調されています。ここで重要になるのがSecurity CopilotとMCPです。
Microsoft Sentinel MCP serverは、AIモデルがセキュリティデータへ標準的にアクセスできるようにする仕組みです。Microsoft Learnでは、MCPにより、関連テーブルの検索、データ取得、エンティティ分析、インシデントのトリアージ、脅威ハンティングなどにAIを活用できると説明されています。多くのMCPツールではMicrosoft Sentinel Data Lakeへのオンボードが前提になります。(Microsoft Learn)
実務では、次のような使い方が考えられます。
- 最新の重大インシデントを要約する
- 関連するユーザー、端末、IP、URL、メール送信者を横断的に確認する
- KQLクエリの下書きを生成する
- 既知の脅威インテリジェンスと照合する
- 封じ込めアクションの候補を作る
ただし、AIに任せる範囲を決めずに導入すると危険です。自動ブロック、自動隔離、権限剥奪などの影響が大きい操作は、人間の承認を挟む設計が現実的です。AIは「判断を代替するもの」ではなく、「調査・要約・候補提示を高速化するもの」として設計すると失敗しにくくなります。
セキュリティ管理者がやるべきこと
セキュリティ管理者は、今回の移行をSOC基盤の再設計として扱う必要があります。最初にやるべきことは、現在のMicrosoft Sentinel環境の棚卸しです。
棚卸しのチェックリスト
| 確認項目 | 見るべきポイント |
|---|---|
| ワークスペース | どのテナント、サブスクリプション、リージョンにあるか |
| データコネクタ | Defender系、クラウド、ネットワーク、ID、SaaSの取り込み状況 |
| 分析ルール | 有効・無効、重複、誤検知率、MITRE ATT&CKとの対応 |
| 自動化ルール | incident trigger、alert trigger、条件式、タグ、タイトル依存 |
| プレイブック | Logic Apps権限、実行対象、外部システム連携 |
| API連携 | Microsoft Sentinel API、Microsoft Graph API、チケットシステム |
| RBAC | Azure RBAC、Entra IDロール、Unified RBACの使い分け |
| 保持期間 | 分析層、Data Lake層、監査要件、コスト |
| SOC手順書 | トリアージ、エスカレーション、封じ込め、報告 |
特に分析ルールは「動いているか」だけでなく、「統合インシデントの中でどう見えるか」を確認してください。Defender portalでは、Fusion分析ルールによる相関ではなくDefender XDRの相関エンジンが担う領域があり、アラートのグルーピングやインシデント統合の挙動が変わる可能性があります。(Microsoft Learn)
IDチームが注意すべきポイント
Identity teamにとって、Unified SecOps移行はMicrosoft Entra IDログの表示場所が変わるだけではありません。侵害調査におけるIDの重要性がさらに高まります。
特に確認すべき対象は次の通りです。
- サインインログ、監査ログ、リスク検出の保持期間
- 特権ロール操作の検知ルール
- 条件付きアクセス変更の監査
- サービスプリンシパル、アプリ登録、証明書・シークレットの監視
- ブレークグラスアカウントの監査
- ID関連アラートが統合インシデントにどう相関されるか
IDチームでありがちな失敗は、「IDログはセキュリティチームがSentinelで見ているはず」と考えることです。Unified SecOpsでは、IDが攻撃ストーリーの中心になります。パスワードスプレー、トークン盗難、同意フィッシング、特権昇格、横展開を一連の流れとして見るには、IDチームとSOCの検知ロジックを合わせる必要があります。
たとえば、特権ロールが付与されたユーザーに海外IPからサインインがあり、その後メール転送ルールが作成された場合、単独のIDアラートではなく、統合インシデントとして重大度を引き上げるべきです。
コンプライアンスチームが確認すべきポイント
Compliance teamが見るべきポイントは、データ保持、データ所在地、暗号化、監査証跡、アクセス権限です。Microsoft SentinelをDefender portalで使う場合、データストレージ、処理、保持、共有に関する適用ポリシーの考え方が変わるため、規制業種では事前確認が欠かせません。(Microsoft Learn)
特にCMKを使っている組織は注意が必要です。Microsoftの移行ガイドでは、CMKを有効にしたワークスペースをDefender portalへオンボードした場合、既存および新規のログデータやSentinelコンテンツはCMKで暗号化され続ける一方、オンボード後のアラートとインシデントはCMK暗号化されないと説明されています。また、Microsoft Sentinel Data Lakeに保存されるデータではCMKが完全にはサポートされず、Microsoft管理キーで暗号化される点も明記されています。(Microsoft Learn)
コンプライアンス観点の確認表
| 項目 | 確認すべき内容 |
|---|---|
| データ所在地 | 対象リージョン、国・地域ごとの規制要件 |
| 保持期間 | 監査・訴訟・内部規程で必要な保持年数 |
| 暗号化 | CMKが必要なデータと、Microsoft管理キーで許容できるデータ |
| アクセス制御 | SOC、ID、監査、外部委託先の最小権限 |
| 監査証跡 | 誰がインシデントを閲覧、更新、クローズしたか |
| 越境運用 | グローバルSOCやMSSPが複数国のデータを見る場合の制約 |
グローバル企業では、「SOCは一元管理したいが、データ閲覧は地域ごとに制限したい」という要件がよくあります。この場合、Unified RBAC、Azure RBAC、Sentinel scoping、ワークスペース分割、ログ保持ポリシーを組み合わせて設計する必要があります。
Unified RBACは移行後の権限設計で避けて通れない
Microsoft Defender unified RBACは、複数のMicrosoft Security製品の権限をDefender portalで一元管理するモデルです。Microsoftのドキュメントでは、Microsoft SentinelのワークスペースがDefender portalへオンボードされている場合、Unified RBACでSentinelのアクセス管理をサポートし、Unified RBACで作成されたSentinelロール割り当てはAzure RBACと同期されると説明されています。ただし、Unified RBACを有効化すると、それが権限のソースになります。(Microsoft Learn)
さらに、Microsoft SentinelでUnified RBACを有効化した後は、Defender portal側でSentinel権限を管理することが推奨されます。Azure portal側で権限変更を行うと、同期エラーにつながる可能性があります。(Microsoft Learn)
権限設計で避けたい失敗
最も避けたいのは、移行作業を急ぐあまり、Global AdministratorやSecurity Administratorを広く付与してしまうことです。Microsoft Sentinelの権限ドキュメントでも、必要最小限の権限を使うことが推奨されています。(Microsoft Learn)
実務では、次のように職務別に分けると整理しやすくなります。
| 役割 | 代表的な権限設計 |
|---|---|
| SOCアナリスト | インシデント閲覧・更新、ハンティング、必要範囲のデータ閲覧 |
| セキュリティエンジニア | 分析ルール、コネクタ、ブック、コンテンツ管理 |
| ID管理者 | Entra ID関連アラート、ID調査、条件付きアクセス変更の監査 |
| SOAR担当 | Logic Apps、プレイブック、Automation rulesの管理 |
| コンプライアンス担当 | 読み取り、監査証跡確認、レポート出力 |
| MSSP | テナント横断の可視性。ただし顧客ごとのスコープ制限が必要 |
権限設計は移行後に直すより、移行前に整理した方が安全です。特に多国籍企業や委託SOCでは、閲覧可能なデータ範囲を明確にしておかないと、セキュリティ強化のための移行が、逆に過剰権限の温床になります。
自動化ルールとプレイブックは必ず事前検証する
Unified SecOps移行で現場がつまずきやすいのが、自動化ルールとプレイブックです。Microsoftの移行ガイドでは、Defender portalでのAutomation rulesやplaybooksには複数の制約や変更点があると説明されています。たとえば、Defender portalオンボード後はSecurityIncidentテーブルにDescriptionフィールドが含まれなくなるため、このフィールドを条件に使っている自動化ルールや外部チケット連携では影響が出る可能性があります。(Microsoft Learn)
また、Defender portalではインシデント名が相関エンジンによって変更される可能性があるため、automation ruleの条件にインシデントタイトルを使うことは推奨されません。代わりに、分析ルール名やタグを使って条件を安定させるべきです。(Microsoft Learn)
事前にテストすべき自動化
| 対象 | テスト内容 |
|---|---|
| メール通知 | 統合インシデントで想定どおり通知されるか |
| Teams通知 | 重要度、担当者、リンク、エンティティ情報が正しく出るか |
| ServiceNow/Jira連携 | incident URL、provider、description、severityのマッピング |
| 自動隔離 | 誤検知時の影響範囲、承認フロー、ロールバック |
| ユーザー無効化 | IDチーム承認、例外アカウント、ブレークグラス除外 |
| タグ付け | 相関後のインシデントでも条件が維持されるか |
| クローズ処理 | Defender側とSentinel側の状態同期 |
特に外部チケットシステムとの連携では、フィールド名やURLの変更が運用に直結します。移行前にサンプルインシデントを作成し、起票、更新、クローズ、再オープン、コメント同期まで確認してください。
API連携はMicrosoft Graph前提へ寄せる
Defender portalの統合体験では、インシデントやアラートに関するAPIの扱いも重要です。Microsoftの移行ガイドでは、統合されたインシデントやアラートを扱う場合、Microsoft Graph REST APIの利用が推奨されています。一方で、Microsoft Sentinel APIは分析ルールや自動化ルールなどSentinelリソースに対する操作を引き続きサポートします。(Microsoft Learn)
移行後は、たとえばproviderNameが従来の「Azure Sentinel」ではなく「Microsoft XDR」になるなど、レスポンス内の値が変わる可能性があります。連携システム側で固定文字列に依存している場合、移行後にチケット分類や自動振り分けが崩れることがあります。
API連携の見直しポイント
| 確認項目 | 実務上の注意 |
|---|---|
| incident URL | Defender portalのURLを使うか、旧Sentinel URLを使うか |
| providerName | 固定値で判定している場合は移行後に影響が出る |
| productName | Defender製品別の分類に使う場合はマッピングが必要 |
| severity | 既存チケットシステムの優先度変換と一致するか |
| alert expansion | alertsの展開取得が必要な処理がないか |
| API権限 | アプリ登録、Graph権限、監査ログの確認 |
APIは「動くか」だけでなく、「移行後のデータ意味論が同じか」を検証してください。
Defender for CloudやXDRコネクタの重複に注意する
Microsoft Defender XDRとMicrosoft Sentinelの統合では、アラートやインシデントの流れが整理されます。Microsoftのドキュメントでは、Defender XDRとSentinelの統合により、Defender XDRのインシデントがMicrosoft Sentinelから見えるようになり、複数のMicrosoft Defender製品のアラートをグループ化・エンリッチできると説明されています。(Microsoft Learn)
一方で、Defender for CloudやDefender XDRコネクタの設定によっては、重複イベントや空のインシデント、想定外の同期が発生する可能性があります。移行時は、どの製品のアラートがどの経路でSentinelやDefender portalに入っているかを図にして確認することをおすすめします。
確認すべき観点は以下です。
- Defender XDR connectorでincidentとalertの収集が有効か
- Defender for Cloudのtenant-based connectorとlegacy connectorが重複していないか
- 複数ワークスペースにXDRデータを取り込んでいないか
- どのワークスペースがprimary workspaceとして扱われるか
- Microsoft incident creation rulesが無効化される影響を理解しているか
ログやアラートの重複は、コストだけでなくSOCの信頼性にも影響します。「また同じアラートだ」と思われる状態が続くと、本当に重要なインシデントの見落としにつながります。
移行プロジェクトの進め方
Unified SecOps移行は、いきなり本番切り替えするより、段階的に進める方が安全です。
推奨ステップ
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | ワークスペース、コネクタ、ルール、権限、自動化の棚卸し | 現行構成一覧 |
| 影響分析 | 相関、API、チケット連携、CMK、保持期間の差分確認 | 影響分析メモ |
| 設計 | データ階層、RBAC、SOC手順、チケット連携の設計 | 移行設計書 |
| 検証 | テストインシデント、プレイブック、API、権限の確認 | 検証結果 |
| 教育 | アナリスト、IDチーム、コンプライアンス担当向け手順説明 | 新運用手順 |
| 移行 | Defender portalへのオンボード、運用切り替え | 切替記録 |
| 最適化 | ノイズ削減、Data Lake活用、MITRE ATT&CKマッピング | 改善ロードマップ |
特におすすめなのは、移行前後でMITRE ATT&CKの検知カバレッジを比較することです。単に「移行できた」ではなく、「横展開、資格情報アクセス、データ流出、永続化に対する検知がどう改善したか」を可視化できます。
失敗しやすいポイントと回避策
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| ポータル移行だけで完了と考える | 自動化、権限、運用手順が崩れる | 移行前に運用・API・RBACを棚卸しする |
| すべてのログを分析層に置く | コストが増え、使われないログが増える | リアルタイム検知と長期調査で階層を分ける |
| Data Lakeに寄せすぎる | 即時検知できないログが増える | 高重要度ログは分析層に残す |
| インシデントタイトルを自動化条件に使う | 相関後に条件が外れる | 分析ルール名、タグ、エンティティ条件を使う |
| Global Adminを広く付与する | 過剰権限と監査リスクが増える | Unified RBACと最小権限で設計する |
| チケット連携を未検証で切り替える | ServiceNow/Jiraで項目欠落や分類ミスが起きる | provider、URL、description、severityを事前確認する |
| CMKやデータ所在地を後回しにする | 規制・内部統制に抵触する可能性がある | コンプライアンスチームを初期段階から参加させる |
| アナリスト教育を省略する | 統合インシデントの読み方が分からず対応が遅れる | 実インシデントに近い演習を行う |
移行で最も危険なのは、技術的には完了しているのに、現場の判断基準が古いまま残ることです。統合インシデント、Graph、Data Lake、Copilotを使うなら、それに合わせて手順書と役割分担も更新する必要があります。
よくある疑問
Defender portalへの移行には追加費用がかかるのか
Microsoftの移行ガイドでは、Defender portalへの移行自体に追加費用はなく、顧客は通常どおりMicrosoft Sentinelの利用量に基づいて課金されると説明されています。ただし、Data Lake、保持期間、処理、クエリ、追加サービスの利用によって費用は変わるため、移行前にコスト見積もりを行うべきです。(Microsoft Learn)
既存のログは移行で消えるのか
Microsoft SentinelをDefender portalに統合しても、既存のLog Analyticsワークスペースや基本的なデータ収集パイプラインは維持されます。既存コネクタも中断なく動作すると説明されています。ただし、表示場所、相関、スキーマ差分、Automation rules、API連携には注意が必要です。(Microsoft Learn)
Microsoft Defender XDRを使っていない組織でも関係あるのか
関係あります。Microsoft SentinelはDefender portalで単独利用できるようになっており、Azure portalでのSentinelサポート終了が予定されています。Defender XDRを全面導入していない組織でも、Microsoft Sentinelの運用場所、権限設計、データ保持、SOC手順の見直しは必要です。(Microsoft Learn)
すべてのログをData Lakeに移せばよいのか
いいえ。Data Lake層は長期保持や高度分析に向いていますが、リアルタイム分析、アラート、インシデント管理には分析層が必要です。特権ID操作、不審なサインイン、高重要度アラートなど、即時検知すべきデータは分析層に残す判断が重要です。(Microsoft Learn)
移行後にAzure portal側で権限を変更してもよいのか
Unified RBACをMicrosoft Sentinelで有効化した後は、Defender portal側で権限管理することが推奨されます。Azure portalで変更すると同期エラーが起きる可能性があるため、権限変更の運用ルートを明確にしておく必要があります。(Microsoft Learn)
2026年4月時点で取るべき次のアクション
Microsoft Sentinel / Microsoft DefenderのUnified SecOps移行は、ポータル変更ではなく、SOC全体の設計変更です。まずは現在のSentinel環境を棚卸しし、以下の順に進めてください。
- 既存ワークスペース、データコネクタ、分析ルール、自動化、API連携を一覧化する
- ログを「リアルタイム検知」「長期調査」「規制保持」に分類する
- Analytics tierとData Lake tierの配置方針を決める
- Unified RBACと最小権限の設計を行う
- ServiceNow、Jira、Logic Apps、独自API連携をテストする
- SOC、ID、コンプライアンスの手順書を統合インシデント前提に更新する
- MITRE ATT&CKを使って移行前後の検知カバレッジを測定する
2027年3月31日の期限だけを見ていると、移行は後回しになります。しかし、今回の更新の本質は期限対応ではなく、AIエージェント、グラフ分析、長期データ保持を使えるSOCへ変えることです。
今すぐ始めるべき最初の作業は、Defender portalへの接続ではなく、現在の検知・データ・権限・自動化がどのように攻撃対応を支えているかを可視化することです。その棚卸しができて初めて、Unified SecOps移行は「画面変更」ではなく、実際にセキュリティを強くするアーキテクチャ判断になります。
コメント