Microsoft Intune / Windows エンドポイント運用

Microsoft Intune を中核にした Windows エンドポイントの日常運用を、Win32 アプリ配布、Cloud PKI 証明書認証、Windows Autopatch、UEFI セキュアブート証明書更新、リモート ワイプといったライフサイクル操作とその攻撃面の観点から整理します。

最終更新:

定義

Microsoft Intune / Windows エンドポイント運用とは、Microsoft の統合エンドポイント管理サービスである Microsoft Intune を中核にして、組織が管理する Windows デバイスの日常運用(アプリ配布、証明書配布、パッチ適用、構成管理、リモート操作)をクラウドから一元的に行う運用領域です。具体的には、Win32 アプリを .intunewin パッケージとして配布・更新する Win32 アプリ管理、オンプレミスの CA を不要にする Microsoft Cloud PKI による証明書配布(Wi-Fi の EAP-TLS / VPN / S/MIME 用途)、更新リングと展開リングで段階配信する Windows Autopatch、2011 年発行の証明書が 2026 年(6 月以降)から順次期限切れを迎える UEFI セキュアブート証明書の更新、そして「ワイプ」「廃止」「Fresh Start」などのリモート アクションが含まれます。これらの管理機能は強力であるため、Intune の管理プレーンそのものが攻撃面になり得る点(報道された Stryker Corporation 事案で正規ワイプ機能が悪用されたとされる)まで含めて運用設計する必要があります。

要点

  • Win32 アプリは Microsoft Win32 Content Prep Tool で生成した .intunewin パッケージとして配布し、インストール コマンドと「検出規則」の組み合わせでインストール済み判定が行われる(検出規則の評価が最初に走る点が運用上の要)。
  • Win32 アプリの「置き換え(Supersedence)」機能は新旧バージョンのポリシーを連結してアップデートを管理する仕組みで、Microsoft の公式ドキュメント上、置き換えの関係(supersedence relationship)は最大 10 ノードまで、単一の置き換えグラフ全体では最大 11 ノードまでとされている。
  • Microsoft Cloud PKI は Intune に統合されたクラウド型 PKI で、オンプレミスの AD CS やコネクタ・ハードウェアを必要とせず、Intune 管理デバイスへのクライアント証明書の発行・更新・失効を Microsoft クラウド側で完結できる。
  • Cloud PKI が発行するクライアント証明書は EAP-TLS(RADIUS / Wi-Fi 認証)・VPN・S/MIME などの用途で利用でき、証明書ベース認証では KB5014754 以降の「強いマッピング」要件(証明書と AD アカウントの対応付け)に注意が必要になる。
  • Windows Autopatch は Intune の更新管理を拡張するクラウド サービスで、Autopatch グループの「展開リング」を用いて品質更新・機能更新・ドライバー・Microsoft 365 Apps / Edge の更新を段階配信し、品質更新で対象期日までに 95% のデバイスを更新することを目標としている。
  • UEFI セキュアブートで使われている Microsoft の 2011 年発行証明書は 2026 年(6 月以降)から順次期限切れを迎え、新しい 2023 年版(Windows UEFI CA 2023 / Microsoft Corporation KEK 2K CA 2023 など)への更新が必要で、原則 Windows Update 経由で自動配信されるが OEM のファームウェア更新が前提になる場合がある。
  • Intune のリモート アクションには「ワイプ(工場出荷時リセット)」「廃止(企業データのみ削除)」「Fresh Start」などがあり、Microsoft Learn が各操作の削除範囲を公式に定義しているが、正規の管理者権限が侵害されると正規ワイプ機能が大規模な破壊操作(環境寄生型攻撃)に転用され得る。

Intune を中核とした Windows エンドポイント運用の主な機能領域

機能領域代表的な機能・仕組み主な用途運用上の注意点
アプリ配布Win32 アプリ管理(.intunewin / 検出規則 / 置き換え機能)業務アプリのインストール・アップデート・アンインストールの自動化検出規則の評価が最初に走るため、ファイル バージョン等で「未更新」を正しく判定できる設計が必要
証明書ベース認証Microsoft Cloud PKI(SCEP で証明書配布)Wi-Fi(EAP-TLS / RADIUS)・VPN・S/MIME 用クライアント証明書のクラウド発行証明書ベース認証では KB5014754 以降の強いマッピング要件に対応する必要がある(SID の SAN 埋め込み等)
パッチ・更新管理Windows Autopatch(Autopatch グループ / 展開リング / 複数フェーズ機能更新)品質・機能・ドライバー・Microsoft 365 Apps / Edge 更新の段階配信と可視化ライセンス要件(Business Premium / Enterprise E3・E5 等)とデバイス登録形式(Entra Join / Hybrid Join)の前提を満たす必要がある
ブート保護の維持UEFI セキュアブート証明書の更新(2011 → 2023 CA)期限切れ後も将来のブート コンポーネント署名検証・セキュリティ更新を受けられる状態の維持原則 Windows Update で自動更新だが、OEM のファームウェア更新が前提になる場合があり、まず現状把握が重要
リモート ライフサイクル操作リモート アクション(Wipe / Retire / Fresh Start)紛失・盗難・退職者対応、デバイスの初期化・回収正規操作のため EDR で攻撃と即時判別しにくく、RBAC 最小権限・フィッシング耐性 MFA・多管理者承認で管理プレーンを保護する必要がある

よくある質問

Intune で配布した Win32 アプリ(.intunewin)が、ファイルを差し替えてもアップデートされないのはなぜですか?
Win32 アプリの配布ポリシーは、インストール コマンドの実行前に「検出規則」でアプリがインストール済みかどうかを最初に評価します。そのため、検出規則をファイルの存在だけで構成していると、古いバージョンが入っているだけで「インストール済み」と判定され、インストール コマンドが実行されずアップデートが走りません。確実にアップデートさせるには、検出規則をファイル バージョンで構成し、必要に応じて「置き換え(Supersedence)」機能で新旧ポリシーを連結します。Microsoft の公式ドキュメント上、置き換えの関係は最大 10 ノードまで(単一の置き換えグラフ全体では最大 11 ノードまで)とされています。
Microsoft Cloud PKI を使うと、オンプレミスの AD CS は完全に不要になりますか?
用途によります。Microsoft Cloud PKI は Intune 管理デバイスへの「クライアント証明書」の発行・更新・失効をクラウドで完結でき、オンプレミスのサーバーやコネクタ・ハードウェアを必要としません。ただし、EAP-TLS による Wi-Fi 認証のように、RADIUS(NPS)サーバーが提示する「サーバー証明書」が別途必要になる構成では、サーバー証明書の発行は Cloud PKI のスコープ外となり、その部分はオンプレミスの AD CS 等で発行する必要があります。脱 AD への過渡期では、クライアント側を Cloud PKI、サーバー側を AD CS と役割分担する構成が現実的です。
UEFI セキュアブートの証明書更新は、企業側で何をすればよいですか?
Microsoft の公式情報によると、セキュアブートで使われている 2011 年発行の証明書は 2026 年(6 月以降)から順次期限切れを迎え、新しい 2023 年版(Windows UEFI CA 2023 / Microsoft Corporation KEK 2K CA 2023 など)への更新が必要です。更新は原則として Windows Update を通じて自動的に配信されますが、メーカーによっては事前に BIOS / ファームウェアの更新が前提となる場合や、自動更新が想定どおり適用されないケースもあります。そのためまずは PowerShell(Get-SecureBootUEFI)や Windows セキュリティ アプリ、Intune の Autopatch レポート / 修復機能で現状の更新状況を把握し、必要に応じて強制更新を検討するのが実務的な進め方です。
Intune の「ワイプ」「廃止」「Fresh Start」はどう違いますか?
Microsoft Learn の定義では、「ワイプ(Wipe)」はデバイスを工場出荷時状態にリセットし、企業データ・個人データ・OS 設定をすべて削除します(紛失・盗難端末の完全初期化や退職者の会社所有デバイス回収が想定用途)。「廃止(Retire)」は企業データのみを削除して個人データは保持します(退職者の BYOD 端末から会社データのみ抜く用途)。「Fresh Start」はプリインストール以外のアプリを削除し、ユーザー データの保持を選択できます(Windows デバイスのクリーンアップ用途)。いずれも正規の管理操作ですが、管理者権限が侵害されると破壊的に転用され得るため、権限管理とあわせて運用する必要があります。
Intune の正規ワイプ機能が攻撃に悪用された事案があると聞きました。どう備えるべきですか?
報道によれば、米医療機器大手 Stryker Corporation が 2026 年にサイバー攻撃を受け、攻撃者が特権アカウントを侵害したうえで Intune の正規のワイプ機能を用いて多数のデバイスを初期化したとされています(被害台数や技術的詳細は報道により幅があり、一次情報では完全には確認されていません)。重要なのは、こうした「正規の管理機能の不正利用」は通常の運用操作と区別しにくく、EDR/XDR 単体では即時検知が難しいという点です。Microsoft が示す管理プレーンの保護策に沿うと、優先すべきは (1) RBAC による Intune 管理者の最小化、(2) 特権アカウントへのフィッシング耐性 MFA と PIM による時限付与、(3) ワイプなど破壊的操作への多管理者承認(Multi Admin Approval)の適用です。条件付きアクセスや EDR は補完であり、まず管理プレーンの権限と承認フローを固めることが要になります。

一次情報