2026年4月10日、Microsoft は Microsoft Sentinel に Microsoft Intune ログを取り込むための公式ガイダンスを公開しました。今回の要点は、Intune のログを単に管理画面で見るのではなく、Microsoft Sentinel に流して検知・相関分析・コンプライアンス監視までつなげることです。Intune 管理センターだけで閉じた運用では、非準拠端末の増加、登録失敗の急増、想定外の管理操作といった兆候を、他のセキュリティログと横断して追いにくくなります。今回のガイドは、その弱点を埋めるために、必要権限、診断設定、送信先ワークスペース、確認すべきテーブル、初期クエリまでを整理した内容です。 (TECHCOMMUNITY.MICROSOFT.COM)
Intune をすでに使っている組織ほど、「ログはあるのに SOC で活用できていない」状態になりがちです。この記事では、Microsoft Sentinel データ コネクタの観点で今回のガイダンスがなぜ重要なのか、どのログを送るべきか、どこで詰まりやすいか、取り込み後に何を作れば実運用に乗るのかまで、実務目線で整理します。 (TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Sentinel データ コネクタで押さえるべき今回のポイント
今回の公式ブログは、単なるお知らせではなく、Intune から Sentinel へログを送る具体的な実装手順に踏み込んでいます。前提条件として、Microsoft Sentinel が有効な Log Analytics ワークスペース、Intune の設定権限、Log Analytics ワークスペースへの書き込み権限を確認し、そのうえで Intune 管理センターの Reports > Diagnostics settings からログを送信する流れが案内されています。 (TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、起点が Sentinel 側の専用コネクタ画面ではなく、Intune 側の Diagnostic settings だという点です。つまり今回のガイダンスは、「Intune のログをどう正しく Azure Monitor / Log Analytics 経由で Sentinel に着地させるか」という実装ベストプラクティスに近い内容です。Sentinel 側では、その後にテーブル確認、KQL、分析ルール、ワークブックへつなげていきます。 (マイクロソフト ラーン)
もう1つ見逃せないのがポータルの前提です。今回のガイドでは Defender ポータルと Azure ポータルの両方で確認手順が紹介されていますが、Microsoft は 2027年3月31日以降、Microsoft Sentinel は Azure ポータルではサポートされず、Defender ポータルのみになると案内しています。今から運用手順を作るなら、日常運用の標準は Defender ポータル寄りで考えるのが安全です。 (TECHCOMMUNITY.MICROSOFT.COM)
エンドポイントとコンプライアンスの監視で、なぜ Intune-to-Sentinel が効くのか
Microsoft は今回のガイダンスで、Intune ログを Sentinel に集約すると、問題の検知が速くなり、他のセキュリティログとの相関分析がしやすくなり、コンプライアンス報告にも役立つと説明しています。Sentinel 自体も、Intune を含む複数の Microsoft サービスや外部ソースのログを一元化して扱う前提の SIEM / セキュリティプラットフォームとして位置づけられています。 (TECHCOMMUNITY.MICROSOFT.COM)
特に見落としやすいのが、Intune の「運用ログ」はそのままセキュリティシグナルになるという点です。たとえば、急に非準拠端末が増えた、登録失敗が続発した、想定外のアカウントがポリシーを変更した、といった事象は、IT 運用の問題であると同時に、セキュリティ監視の優先イベントでもあります。Intune 単体の画面で見るより、Sentinel に入れてアラートやインシデント化したほうが、SOC の初動は明らかに速くなります。 (TECHCOMMUNITY.MICROSOFT.COM)
また、Intune の監査ログは、作成・更新・削除・割り当て・リモート操作など、変更を発生させる操作を記録します。監査自体は Intune で既定で有効ですが、Sentinel に送らなければ、他ログとの横断調査や継続的な検知につなげにくいままです。変更管理や内部統制の観点でも、ここを SIEM に載せる価値は大きいです。 (マイクロソフト ラーン)
まず送るべき 4 つの Intune ログ
今回のガイドと Microsoft Learn のテーブル定義を合わせて見ると、最初に押さえるべきログは次の 4 種類です。Intune 側のログカテゴリと、Sentinel 側で確認するテーブル名はセットで覚えておくと迷いません。 (マイクロソフト ラーン)
| Intune 側のログカテゴリ | Sentinel 側のテーブル | 主に分かること | まずの使い道 |
|---|---|---|---|
| AuditLogs | IntuneAuditLogs | だれが何を変更したか、操作結果はどうだったか | ポリシー変更、アプリ配布変更、リモート操作の監査 |
| OperationalLogs | IntuneOperationalLogs | 登録や運用処理の成否、処理内容 | 登録失敗や運用エラーの検知 |
| DeviceComplianceOrg | IntuneDeviceComplianceOrg | 準拠状態、端末名、OS、最終接触、ユーザー情報 | 非準拠端末の洗い出し、準拠崩れの監視 |
| IntuneDevices | IntuneDevices | 端末インベントリ、登録状態、暗号化状態、所有区分など | インシデント調査時の端末文脈付け |
実務では、最初から 4 種類すべて送るのがいちばん手堅いです。最小構成から始めるなら AuditLogs と OperationalLogs を先行し、その後 DeviceComplianceOrg と IntuneDevices を足す形でも構いません。ただし、コンプライアンス監視まで本気でやるなら、後者 2 つを省くと価値がかなり落ちます。
Microsoft Sentinel へ Intune ログを取り込む手順
Microsoft の現行ガイダンスを、運用設計しやすい形に直すと次の流れです。設定自体は難しくありませんが、ワークスペース選択と反映確認でミスが出やすいです。 (TECHCOMMUNITY.MICROSOFT.COM)
| 手順 | やること | つまずきやすい点 |
|---|---|---|
| 1 | Microsoft Sentinel が有効な Log Analytics ワークスペースを用意する | 既存ワークスペースが複数あると選択ミスしやすい |
| 2 | Intune 管理権限と Log Analytics への権限を確認する | 権限不足だと設定保存や確認で詰まりやすい |
| 3 | Intune 管理センターで Reports > Diagnostics settings を開く | 初回は診断設定の有効化が必要なことがある |
| 4 | AuditLogs OperationalLogs DeviceComplianceOrg IntuneDevices を選ぶ | まずは全選択が無難 |
| 5 | 送信先に Log Analytics を選び、Sentinel ワークスペースを指定する | サブスクリプションやディレクトリの取り違えが多い |
| 6 | 保存後、Defender ポータルまたは Azure ポータルでテーブルを確認する | 反映時間に差があるため、すぐ出ないことがある |
| 7 | 初期 KQL を実行し、分析ルールやワークブックへつなぐ | 着弾確認をせずにルール作成へ進むと空振りしやすい |
ログが入らないとき、まず「設定ミス」を疑いがちですが、そもそも記録対象のイベントが発生していないケースもあります。Microsoft も、端末登録がない、ポリシー変更がない、といった状況ではログがまだ出ない可能性を案内しています。着弾確認の前に、実際に Intune で操作や状態変化が起きているかも見ておくべきです。 (TECHCOMMUNITY.MICROSOFT.COM)
ログが見えないときに最初に疑うべきこと
いちばん多いのは、反映時間の見誤りです。 AuditLogs と OperationalLogs は比較的すぐ Azure Monitor に送られますが、DeviceComplianceOrg と IntuneDevices は 最大 48 時間かかることがあり、しかも 24 時間ごとのエクスポートで送られるため、設定直後に空でも異常とは限りません。コンプライアンス系とインベントリ系だけを見て「失敗した」と判断するのは早すぎます。 (マイクロソフト ラーン)
次に多いのが、ワークスペースやディレクトリの取り違えです。 Microsoft の FAQ でも、正しいサブスクリプション、正しい Sentinel ワークスペース、正しいテナントかを確認するよう案内しています。複数テナントを運用している環境では、設定画面上で保存できていても、想定外のワークスペースに落ちていることがあります。 (TECHCOMMUNITY.MICROSOFT.COM)
クエリ例はそのまま鵜呑みにしないほうが安全です。 今回のブログ本文では検証用の例として IntuneDevice | take 5 が示されていますが、同じ記事のテーブル一覧や Microsoft Learn のテーブル定義では IntuneDevices が使われています。実運用では、まずスキーマ一覧でテーブル名を確認し、そこからクエリを作るほうが確実です。 (TECHCOMMUNITY.MICROSOFT.COM)
列名に強く依存した作り込みも早すぎます。 Microsoft Learn では、Intune のこれらのログは スキーマが変わる可能性があると案内しています。取り込み直後から列を厳密に固定した複雑な KQL を量産するより、まずは少ない列で確認し、数日運用してから検知ロジックを固めるほうが失敗しにくいです。 (マイクロソフト ラーン)
取り込み直後に保存しておきたい KQL
次のクエリは、Microsoft が公開しているテーブル名と代表列をもとに、着弾確認と初期監視に使いやすい形にしたものです。環境によって列や値の出方が変わることがあるため、まずはこのまま実行し、結果を見てから条件を調整してください。 (マイクロソフト ラーン)
管理変更を直近 24 時間で確認する
IntuneAuditLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, Identity, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc非準拠端末を洗い出す
IntuneDeviceComplianceOrg
| where TimeGenerated > ago(24h)
| where ComplianceState != "Compliant"
| project TimeGenerated, DeviceName, UserName, OS, OSVersion, ComplianceState, LastContact
| order by TimeGenerated desc登録や運用の失敗を確認する
IntuneOperationalLogs
| where TimeGenerated > ago(24h)
| where tostring(Result) !in~ ("Success", "Succeeded")
| project TimeGenerated, OperationName, Result, Properties
| order by TimeGenerated desc端末インベントリの文脈を付ける
IntuneDevices
| where TimeGenerated > ago(24h)
| project TimeGenerated, DeviceName, OS, OSVersion, Ownership, CompliantState, EncryptionStatusString, PrimaryUser
| order by TimeGenerated desc取り込んだあとに、何を作れば運用が回り始めるか
今回の Microsoft のガイドが本当に重要なのは、取り込みがゴールではなく、その先の検知と可視化まで見据えている点です。ブログでは、Intune ログをもとにカスタム検知ルールや Sentinel の scheduled analytics rules を作り、ワークブックやハンティング、インシデント対応へつなげることが勧められています。さらに、Defender ポータルでは Sentinel データと他の Defender データを横断してハンティングできるため、Intune を端末管理ログとして終わらせず、調査の文脈データとして使いやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
最初に作る運用としては、次の 3 本が現実的です。
| まず作るもの | 目的 | 最初の判断基準 |
|---|---|---|
| 非準拠端末急増の分析ルール | 証明書失効、ポリシー不整合、広域トラブルの早期検知 | 30分で 10 台以上の非準拠端末が出たら通知 |
| 想定外アカウントによる Intune 管理変更の検知 | ポリシー改変や誤操作の早期把握 | 承認済み管理者以外の変更操作を通知 |
| 登録失敗の可視化ワークブック | 展開や更改時の品質監視 | 日次・時間帯別に失敗件数を可視化 |
ここで期待値も調整しておくべきです。Microsoft のブログでは、現時点でネイティブな Intune 向けの事前構成コンテンツパックがあるわけではないと明記しています。つまり、今回のガイダンスは「つながるようになった」ことが主眼で、運用価値を最大化するには、自分たちの監視観点に沿ってルールやワークブックを最初に 2〜3 本作る前提で考えるべきです。 (TECHCOMMUNITY.MICROSOFT.COM)
コストと保持を設計するときの注意点
ブログでは、保存後に Intune ログが Analytics tier に入ることが説明されています。これは重要で、Microsoft Learn でも Analytics tier はアラート、ハンティング、ワークブックなど、Microsoft Sentinel のリアルタイム機能向け、一方の Data lake tier は長期保持向けで、リアルタイム分析機能には向かないと整理されています。コンプライアンス異常や登録失敗をその場で検知したいのに、安さだけで lake-only に寄せると、期待した運用が成立しません。 (TECHCOMMUNITY.MICROSOFT.COM)
さらに厄介なのは、Intune 系テーブルでも性質が同じではないことです。IntuneAuditLogs と IntuneOperationalLogs は ingestion-time DCR をサポートし、IntuneDeviceComplianceOrg はそれをサポートしません。IntuneDevices は Basic log、ingestion-time DCR、lake-only ingestion をサポートしています。つまり、インベントリ寄りの IntuneDevices は最適化の候補になり得ますが、検知に使うテーブルと同じ感覚で扱うと危険です。しかも Microsoft は、Basic logs の管理は現時点で Defender ポータルではなく Log Analytics ワークスペース側で行うよう案内しています。テーブルごとの違いを見ずに「全部まとめて安くする」は失敗しやすい判断です。 (マイクロソフト ラーン)
まとめ
今回の Microsoft のガイダンスが示している本質は、Intune ログを Microsoft Sentinel に取り込むこと自体より、Intune を SOC の観測点に変えることです。Reports > Diagnostics settings から 4 種類のログを正しいワークスペースへ送り、反映時間の違いを踏まえて着弾確認し、まずは「管理変更」「非準拠端末」「登録失敗」を見る 3 本のクエリとルールを作る。ここまでできれば、Intune は単なる MDM ではなく、エンドポイントとコンプライアンス監視の重要なログソースになります。加えて、今後は Defender ポータル前提の運用へ寄せておくと、2027年3月31日以降の移行でも慌てにくくなります。 (マイクロソフト ラーン)
コメント