Microsoft DefenderポータルでMicrosoft Sentinelを運用している管理者がまず押さえるべき点は、今回の「What’s new in Microsoft Sentinel」が単なる新機能紹介ではなく、SOC運用、UEBA設定、Okta/GCPの検出、自動化ルール、Azure portalからDefenderポータルへの移行に関わる変更を含んでいることです。
特に重要なのは、2026年5月時点のUEBA強化と、2026年7月1日までに確認すべきAccountName関連の自動化見直しです。Windows Defenderのウイルス対策設定の話ではなく、Microsoft Defenderポータル上でMicrosoft Sentinelを使うSIEM/SOAR運用者向けの変更として整理すると理解しやすくなります。
この記事では、2026年5月10日時点で確認すべき公式情報をもとに、何が変わるのか、誰に影響するのか、管理者・開発者がどの設定を確認すべきかを実務目線で解説します。
Microsoft Defender管理者がまず確認すべき結論
Microsoft Learnの「Microsoft Sentinel の新着情報」は、Microsoft Sentinelに追加された最近の機能と、Sentinelのユーザー体験を強化する関連サービスの新機能をまとめたページです。公式情報では、掲載対象は直近6か月にリリースされた機能とされています。(Microsoft Learn)
今回の確認ポイントは、大きく次の6つです。
| 確認ポイント | 影響を受けやすい対象 | 最初にやること |
|---|---|---|
| UEBA設定画面の変更 | SOC管理者、検出エンジニア | DefenderポータルのMicrosoft Sentinel設定でUEBAタブを確認する |
| OktaV2_CL対応 | Okta連携を使う組織 | Okta_CLだけでなくOktaV2_CLの取り込み状況を確認する |
| GCP Audit Logsの新しい異常検出 | GCPを監視対象にしている組織 | GCP監査ログがSentinelに入り、異常検出に使える状態か確認する |
| AccountNameのUPNプレフィックス化 | 自動化ルール、Logic Apps、KQL、ブック | [email protected]の完全一致条件を洗い出す |
| Defenderポータルへの移行 | Azure portalでSentinelを運用中の組織 | 2027年3月31日までの移行計画を作る |
| Sentinel repositories APIの更新 | IaC、CI/CD、DevSecOps担当 | 古いAPIバージョンを使っていないか確認する |
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスを持たないユーザーでも利用できます。一方で、2027年3月31日以降はAzure portalでMicrosoft Sentinelがサポートされなくなり、Defenderポータルでのみ利用する形になります。(Microsoft Learn)
2026年5月の中心はUEBA強化：設定場所と検出範囲が変わる
2026年5月のMicrosoft Sentinel新着情報で中心となるのは、UEBA、つまりUser and Entity Behavior Analyticsの強化です。公式情報では、UEBA設定とBehaviors設定の統合ビューが作成され、Microsoft Sentinel設定ページの新しいUEBAタブからUEBA設定にアクセスできるようになったと説明されています。(Microsoft Learn)
UEBAは、接続されたデータソースのログやアラートを分析し、ユーザー、ホスト、IPアドレス、アプリケーションなどのエンティティごとに通常時の行動プロファイルを作り、機械学習で異常なアクティビティを検出する機能です。(Microsoft Learn)
Okta利用組織はOktaV2_CL対応を確認する
今回の更新では、UEBAのOkta異常検出が、既存のOkta_CLテーブルに加えてOktaV2_CLテーブルもサポートするようになりました。重要なのは、新しい異常タイプが増えたわけではなく、既存の異常アクティビティや異常なMFA失敗の検出が、新しいOktaコネクタ形式の利用者にも広がる点です。(Microsoft Learn)
実務では、次のような組織が確認対象になります。
- Oktaの新しいコネクタ形式へ移行済み、または移行予定
- 以前は
Okta_CLを前提に検出ルールやブックを作っていた - OktaのMFA失敗やセッションイベントをSOCで監視している
- IDaaSとしてOktaを使い、Microsoft Entra IDと併用している
確認すべきことは、OktaV2_CLにログが取り込まれているか、UEBA対象データソースとして機能しているか、既存の分析ルールやブックがOkta_CLだけに固定されていないかです。
GCP Audit Logsの異常検出が広がる
UEBAでは、GCP Audit Logsに対して5つの新しい異常検出がサポートされました。対象は、異常なログイン行動、特権操作、リソースデプロイ、シークレットやKMSキーへのアクセス、インフラ利用パターンです。(Microsoft Learn)
GCP監査ログは、GCPAuditLogsテーブルを通じてUEBAのデータソースとして扱われ、IAM、Compute Engine、Cloud Storage、Kubernetes Engine、Cloud KMS、Secret Managerなど複数のGoogle Cloudサービスが対象に含まれます。(Microsoft Learn)
たとえば、次のようなシナリオで効果が出やすくなります。
| シナリオ | 期待できる検出観点 |
|---|---|
| 通常とは異なる地域・時間帯からのGCP管理操作 | 異常ログイン、異常な管理行動 |
| サービスアカウントによる想定外の権限操作 | 特権操作、IAM操作の異常 |
| 短時間でのVM、コンテナ、ストレージ作成 | リソースデプロイの異常 |
| Secret ManagerやCloud KMSへの急なアクセス増加 | シークレット/KMSキーアクセスの異常 |
| 普段使われないAPIやインフラ操作の急増 | インフラ利用パターンの異常 |
ただし、GCPの運用変更直後は検出が増える可能性があります。新しいCI/CDパイプライン、Terraform実行、GKE構成変更、権限棚卸しなどを行った直後は、アラートの意味を運用変更と照らし合わせて確認する必要があります。
UEBAを有効化・確認する手順
UEBAは、Microsoft Sentinel設定のSIEMワークスペースタブ、新しいUEBAタブ、またはサポート対象データコネクタの構成画面から有効化できます。いずれの方法でも、UEBAを有効にしてデータソースを構成する流れです。(Microsoft Learn)
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| UEBAが有効か確認 | Microsoft Sentinel設定のUEBAタブを見る | Azure portal側の古い手順だけを参照している |
| データソースを確認 | Okta、GCP、Microsoft Entra ID、Defender XDRなどを確認 | コネクタは有効でもUEBA対象になっていない |
| 権限を確認 | Entra IDのセキュリティ管理者相当、Azure RBACを確認 | 最小権限設計でLog Analytics権限が不足する |
| ログ生成を確認 | BehaviorAnalyticsやAnomaliesを確認 | 有効化直後に十分なベースラインがない |
| コストを確認 | UEBAが生成する追加データ量を確認 | UEBA自体は追加ライセンス不要でも、データ保存料金は発生し得る |
UEBA機能そのものに特別なライセンスは不要とされていますが、UEBAが作成する新しいテーブルにデータが保存されるため、Log Analyticsワークスペースのデータストレージ料金が発生する場合があります。(Microsoft Learn)
異常検出が出ているかを確認する最初のKQLは、まず公式の基本例に近い形で十分です。
Anomalies
| where TimeGenerated > ago(1d)
| where RuleStatus == "Production"このクエリは、直近1日に本番状態のSentinelルールで生成された異常を確認する例です。公式のクエリ例でもAnomaliesテーブル、TimeGenerated、RuleStatusを使った確認方法が示されています。(Microsoft Learn)
運用では、この結果を見たうえで、GCPやOktaに関係するルール名、対象ユーザー、スコア、関連エンティティを絞り込んでいくとよいでしょう。いきなり自動対応につなげるのではなく、まずは2〜4週間ほど通常運用の傾向を見て、誤検知が多い業務イベントを洗い出すのが安全です。
AccountName変更は自動化ルールとLogic Appsに影響しやすい
今回の新着情報で、管理者が最も早く手を付けるべきなのはAccountNameの扱いです。
Microsoft Sentinelでは、分析ルールで完全なUPN、たとえば[email protected]をAccount Nameにマップしている場合、分析ルールアラートのアカウントエンティティでAccountNameが常にUPNプレフィックス、つまりuserになるよう更新されます。あわせて、SecurityAlertテーブルのアカウントエンティティには、完全なUPNを表すUserPrincipalName、UPNSuffix、UPNプレフィックスが追加されます。(Microsoft Learn)
影響しやすいのは、次のような条件です。
| 影響箇所 | 危ない条件例 | 見直し方 |
|---|---|---|
| 自動化ルール | AccountNameが[email protected]に等しい | UPNプレフィックスとサフィックスを分けて比較する |
| Logic Appsプレイブック | 動的コンテンツのAccountNameをメールアドレスとして扱う | UserPrincipalNameやUPNSuffixの利用を検討する |
| KQLクエリ | where AccountName == "[email protected]" | プレフィックス、サフィックス、完全UPNのどれを使うべきか整理する |
| ブック | AccountName単位でユーザーを集計している | 既存表示がユーザー単位で崩れないか確認する |
| 外部連携 | SIEM、チケット、通知本文でAccountNameをメールアドレスとして期待 | 通知テンプレートやWebhookペイロードを確認する |
公式情報では、完全なUPNと比較する自動化ルールやロジックアプリは更新が必要であり、厳密な等価比較ではなく、ContainsやStarts withの利用が推奨されています。(Microsoft Learn)
たとえば、次のような考え方に変えます。
変更前の考え方:
AccountName Equals [email protected]
変更後の考え方:
AccountName Starts with user
UPNSuffix Equals domain.com注意点は、Containsを雑に使うと別ユーザーに一致する可能性があることです。たとえばuserだけで判定すると、user01、superuser、test-userなどを巻き込む可能性があります。重要な自動対応では、プレフィックスだけでなく、UPNサフィックスやテナント、エンティティID、アラート種別も組み合わせて条件を作るべきです。
Defenderポータル移行は後回しにしない
Microsoft Sentinelは、今後さらにMicrosoft Defenderポータル中心の運用に寄っていきます。公式情報では、Microsoft DefenderポータルでMicrosoft Sentinelが一般提供されており、Microsoft Defender XDRやE5ライセンスがなくても利用できるとされています。さらに、2027年3月31日以降はAzure portalでMicrosoft Sentinelがサポートされず、Defenderポータルでのみ利用可能になります。(Microsoft Learn)
移行そのものは、E5以外の顧客でも追加コストは発生せず、Sentinelの利用量に対する通常の課金は継続されます。(Microsoft Learn)
ただし、画面が変わるだけと考えると失敗します。SOC運用では、調査手順、権限、インシデント対応、ブック、クエリ実行場所、教育資料、監査証跡の確認方法まで影響します。
移行前に確認すること
| 項目 | 確認内容 |
|---|---|
| ワークスペース | Defenderポータルにオンボード済みか |
| 権限 | Azure RBAC、Sentinelロール、Defender側の統合RBACを整理したか |
| 運用手順 | インシデント確認、ハンティング、ブック閲覧の手順をDefenderポータル基準に更新したか |
| 教育 | SOCアナリストが新しい画面で同じ対応を再現できるか |
| 自動化 | Logic Apps、分析ルール、プレイブック、通知連携が動作するか |
| 監査 | 変更管理、証跡、承認フローが新しい画面でも説明できるか |
Defenderポータルへの移行手順では、計画ガイダンスと前提条件を確認してからワークスペースをオンボードすること、また一部のMicrosoft Sentinel機能にはDefenderポータルで新しい場所があることが示されています。(Microsoft Learn)
移行の実務では、いきなり全SOCメンバーを切り替えるのではなく、次の順番が安全です。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 準備 | 権限、ワークスペース、既存手順を棚卸し | 現行運用の画面・権限・自動化一覧がある |
| パイロット | 少人数のSOCメンバーでDefenderポータル運用を試す | 代表的なインシデント対応を再現できる |
| 並行運用 | Azure portal手順とDefenderポータル手順を比較 | 差分と未対応項目が明確になる |
| 本番移行 | SOP、教育資料、通知文面を更新 | 通常運用をDefenderポータルで完結できる |
| 定着 | 監査・改善・権限レビューを定期化 | 古いAzure portal前提の手順が残っていない |
開発者・DevSecOpsはSentinel repositories APIの更新を確認する
開発者やDevSecOps担当者は、Sentinel repositories APIの更新も見落とせません。公式情報では、Microsoft Sentinel repositoriesで使われる古いAPIバージョンが2026年6月15日以降サポートされなくなり、APIを使ってリポジトリ接続を作成または管理している場合は、2026年6月1日より前に2025-09-01、2025-06-01、または2025-07-01-previewへ移行するよう案内されています。(Microsoft Learn)
影響する可能性があるのは、次のような環境です。
- Microsoft Sentinelの分析ルールをGitHubやAzure DevOpsで管理している
- Sentinel repositoriesをCI/CDに組み込んでいる
- REST APIでSource Control、Source Controls操作を実行している
- Terraform、Bicep、ARMテンプレート、独自スクリプトでSentinel環境を展開している
- SDKや古いAPIバージョンを固定している
確認方法はシンプルです。CI/CDパイプライン、IaCテンプレート、APIクライアント、内部ドキュメントを検索し、古いAPIバージョン文字列が残っていないか確認します。
検索するキーワード例:
2021-03-01-preview
2022-*
2023-*
2024-*
2025-03-01
2025-04-01-preview
2025-07-01-preview
api-version=
sourceControls既存のリポジトリ接続自体は継続して動作するとされていますが、古いAPIで新規作成や管理要求を行う処理は失敗する可能性があります。したがって、本番パイプラインの前に検証用ワークスペースで接続作成、同期、更新、削除の一連の動作を確認しておくべきです。(Microsoft Learn)
データ管理とコスト：新機能は便利だが設計なしに使わない
2026年4月の更新では、Microsoft Sentinel data federation、フィルターと分割によるデータ変換、カスタムグラフ、行レベルRBACに相当するSentinelスコープなど、データ管理と調査体験を変える機能も追加されています。(Microsoft Learn)
これらは便利ですが、すべてを一気に有効化するのではなく、目的ごとに使い分ける必要があります。
| 目的 | 向いている機能 | 注意点 |
|---|---|---|
| 外部データをコピーせずに調査したい | データフェデレーション | 外部ソースの応答性やデータ量に性能が左右される |
| 低価値ログを取り込まない | フィルター変換 | 条件に一致したデータはAnalyticsにもData Lakeにも取り込まれない |
| 重要データはAnalytics、長期保管はData Lakeに分けたい | 分割変換 | 既存DCRとの競合や反映遅延を確認する |
| 共有ワークスペースでチーム別に閲覧範囲を制御したい | Sentinelスコープ | 取り込み時のタグ付けと統合RBAC設計が必要 |
| 攻撃パスや関係性を可視化したい | カスタムグラフ | プレビュー機能として検証環境から始める |
データフェデレーションでは、Azure Databricks、Azure Data Lake Storage Gen2、Microsoft Fabricなどの外部データソースを、データ移動や複製なしにMicrosoft Sentinel Data Lake側からクエリできます。ただし、フェデレーションはSentinel Data Lakeから外部ソースへの一方向であり、読み取り専用です。外部ソースへの書き戻しはできません。(Microsoft Learn)
フィルターと分割は、取り込み時点でデータを制御する機能です。フィルターは条件に一致したデータを破棄するため、KQL条件を誤ると必要なログまで失います。分割はデータをAnalytics層とData Lake層へ振り分け、コストと検索性能のバランスを取る用途に向いています。(Microsoft Learn)
特にフィルターは、削減効果が分かりやすい反面、復元できないログ欠落を生みやすい機能です。最初は本番テーブルではなく、検証用テーブルや影響の小さいログから始め、1週間程度は件数、検出ルール、調査手順への影響を確認することをおすすめします。
Entity analyzerとコスト見積もりも確認する
Entity analyzerは一般提供になりました。Microsoft SentinelのModel Context Protocol、つまりMCPのデータ探索ツールコレクションで、URLやIDに対する説明可能なエンティティリスク評価を得るための機能です。一方で、2026年4月1日からEntity analyzer利用時に必要なSecurity Compute Units、SCUに対して課金されるとされています。(Microsoft Learn)
そのため、導入前には次の3点を確認します。
| 確認項目 | 理由 |
|---|---|
| 誰がEntity analyzerを使えるか | 不要な利用によるコスト増を避ける |
| どの調査フローで使うか | SOC全員が常時使うのか、特定の高度調査だけに使うのかを決める |
| コスト見積もりと上限管理 | SCU課金を運用コストに反映する |
同じくプレビューとして、3年間の予測を備えたメーターレベルのコスト見積もりツールも紹介されています。Sentinelはログ量、保持期間、分析層、Data Lake利用、外部連携によってコスト構造が変わりやすいため、新機能を有効化する前に見積もりを更新するのが現実的です。(Microsoft Learn)
管理者・開発者向けの実務チェックリスト
今回のMicrosoft Sentinel新着情報を受けて、まずは以下の順番で確認すると効率的です。
すぐ確認すべき項目
| 優先度 | チェック項目 | 対象者 |
|---|---|---|
| 高 | AccountNameを完全UPNとして扱う自動化ルールやLogic Appsがないか | SOC管理者、SOAR担当 |
| 高 | Azure portal前提のSentinel運用手順が残っていないか | セキュリティ管理者 |
| 高 | UEBAが有効で、Okta/GCPのデータソースが対象になっているか | 検出エンジニア |
| 中 | OktaV2_CLとGCPAuditLogsの取り込み状況 | ID管理者、クラウド管理者 |
| 中 | 古いSentinel repositories APIバージョンの利用 | DevSecOps、開発者 |
| 中 | フィルター/分割変換と既存DCRの競合 | ログ基盤担当 |
| 中 | Entity analyzer利用時のSCU課金 | SOC管理者、FinOps |
| 低 | カスタムグラフやデータフェデレーションの検証 | 高度調査チーム |
変更前にテストすべきこと
本番環境へ展開する前に、次のテストを行います。
- 代表的なインシデントをDefenderポータルで最初から最後まで調査できるか
- UEBA有効化後、
AnomaliesやBehaviorAnalyticsに期待どおりデータが出るか - OktaやGCPの運用変更が誤検知として大量に出ないか
AccountName変更後もプレイブックが正しいユーザーを処理するか- フィルター変換で必要なログを破棄していないか
- 分割変換後、分析ルールが必要なデータにアクセスできるか
- APIバージョン更新後もCI/CDでSentinelコンテンツを展開できるか
政府機関向けクラウドでは機能の提供状況が異なる場合があるため、該当環境ではMicrosoft Sentinelのクラウド機能可用性もあわせて確認する必要があります。(Microsoft Learn)
まとめ：次に取るべき行動
Microsoft DefenderポータルにおけるMicrosoft Sentinelの新着情報で、最初に対応すべきなのは新機能の試用ではありません。優先順位は、自動化が壊れないか、UEBAの検出範囲が正しく広がっているか、Defenderポータル移行の準備ができているかです。
まずは、次の順番で進めると失敗しにくくなります。
- 自動化ルール、Logic Apps、KQL、ブックから
AccountNameと完全UPN比較を洗い出す - DefenderポータルでMicrosoft Sentinelワークスペース、権限、運用手順を確認する
- UEBAタブで設定とデータソースを確認し、Okta/GCPの取り込み状況を見る
AnomaliesとBehaviorAnalyticsで実際の出力を確認する- Sentinel repositories APIやCI/CDのAPIバージョンを更新する
- フィルター、分割、データフェデレーション、カスタムグラフは検証環境から試す
今回の更新は、単に検出機能が増えたというより、Microsoft SentinelをDefenderポータル中心の統合セキュリティ運用へ移していく流れの一部です。今のうちに設定、権限、自動化、コストを整理しておけば、新機能を安全に取り込みながら、将来のポータル移行にもスムーズに対応できます。
コメント