【中編】Intuneコンプライアンスポリシー実践:業務を止めない猶予期間の設計とグループ展開のポイント

Intune/Autopilot
【中編】Intuneコンプライアンスポリシー実践:業務を止めない猶予期間の設計とグループ展開のポイント

株式会社アーザスです。

前編 では、Intuneにおけるコンプライアンスポリシーの基本概念や、条件付きアクセスと連携したゼロトラスト制御の仕組みについて解説しました。

コンプライアンスポリシーは非常に強力なセキュリティ機能ですが、十分な計画なしにいきなり全社展開すると、「OSの更新が遅れている端末が一斉にアクセス遮断され、業務がストップしてしまう」といったトラブルを引き起こすリスクがあります。

今回は中編として、社内の混乱を防ぎ、スムーズに全社展開を進めるための「運用設計における3つの重要ポイント」を解説します。

1. 非準拠へのアクション(猶予期間)の設計

コンプライアンスポリシーでは、基準を満たさなかった端末に対して「どのようなアクションをどのタイミングで実行するか」を設定できます。

即座にアクセスを遮断するのではなく、ユーザーが自律的に対処できる猶予期間を設けるのが実務運用の鉄則です。

非準拠へのアクション(猶予期間)の設計フロー

※Intune上では基準未達を検知した時点で状態が記録されますが、「非準拠としてマークするまでの猶予日数」を設定しておくことで、その期間中はMicrosoft Entra ID側で準拠(猶予中)扱いが維持され、条件付きアクセスによる即時遮断を防ぐことができます。

実務でのポイント:日数ベースで伝わる通知メールにする

非準拠アクションで送信するメールは、事前に作成した「通知メッセージテンプレート」の固定文面で送られます。端末ごとの期日を自動で差し込むことはできないため、「〇月〇日までに」という書き方は使えません。非準拠を検知した時点を起点とした日数で案内するのが現実的です。

  • 例:「この通知から〇日以内にOSアップデートを実施してください。期間を過ぎると、社内システムへアクセスできなくなる場合があります。」
  • メール送信アクションと「非準拠としてマーク」アクションの日数設定を、文面の日数と一致させておく
  • 問い合わせ先や社内マニュアルの案内も記載しておく。URLが想定どおりクリックできる形で届くかは、事前にテスト端末へ送って確認する

具体的な対処日数と手順を示すことで、ユーザーの自律的な対応を促し、ヘルプデスクへの問い合わせを大幅に削減できます。

2. 「コンプライアンスポリシーなしのデバイスのマーク」設定の確認

Intune テナント全体の全般設定([デバイス] > [コンプライアンス] > [コンプライアンス ポリシーの設定] など)にある、以下の評価設定の事前確認が必須です。

管理センターのメニュー構成はアップデートにより表記が若干異なる場合があります。

  • 設定項目:ポリシーが割り当てられていないデバイスをマークする
  • 選択肢:準拠(デフォルト値) / 非準拠

設計上の注意点

デフォルト状態(準拠)の留意点

デフォルト値の「準拠」の場合、コンプライアンスポリシーが未割り当ての端末が自動的に安全とみなされ、条件付きアクセスを通過してしまいます。

「非準拠」へ切り替える運用計画

セキュリティの観点では最終的に「非準拠」に設定するのが望ましいですが、全端末へのポリシー割り当てが完了する前に変更すると、既存端末が即座にブロックされる危険があります。全社展開の最終ステップとして切り替えタイミングを組み込みます。

3. 段階的なパイロット展開とグループ設計

コンプライアンスポリシーおよび条件付きアクセスを適用する際は、全体一括適用ではなく段階的な展開(パイロット運用)を行います。

推進3ステップ

ステップ 実施内容 目的
Step 1:IT部門・テスト展開 システム部門の端末や検証機だけに先行適用 ポリシーの評価ロジックや通知メールの動作検証
Step 2:「レポートのみ」検証 ポリシーを端末へ割り当てつつ、条件付きアクセス側を「レポート専用」で運用 実際にポリシーをオンにした際、どの端末がブロック対象になるか事前分析
Step 3:部門ごとの本番展開 影響範囲を見極めながら、業務部門へ順次適用 ヘルプデスクの負荷を分散させつつ全社展開を完了

グループ設計の考え方

段階展開を実現するには、ポリシーの割り当て先となるグループを事前に設計しておく必要があります。

割り当て先:ユーザーグループかデバイスグループか

コンプライアンスポリシーは、ユーザーグループにもデバイスグループにも割り当てられます。ただし、ユーザーグループに統一しておくと、1人が複数端末を使う場合や端末を入れ替えた場合でも、割り当て漏れが起きにくくなります。デバイスグループは、共有端末や検証機など、ユーザーに紐づかない端末に限って使うと整理しやすくなります。パイロット用・部門別のグループを用意し、Step 1 から順に対象を広げていきます。

条件付きアクセスの除外グループを必ず用意する

「準拠済みデバイスを必須とする」条件付きアクセスを有効化する際は、以下を除外グループとして用意し、ポリシーの対象から外します。

  • 緊急用アクセスアカウント(ブレークグラス):ポリシーの設定ミスや障害でテナントから全員が締め出された場合の、最後の復旧手段です。少なくとも1つは除外しておき、通常業務では使わず、サインインを監視します。
  • サービスアカウント・共有用途のアカウント:対話的なサインインができず、準拠デバイスの条件を満たせないため、個別に対応方針を決めて除外または別ポリシーで制御します。

除外は恒久的な抜け穴にならないよう、対象アカウントを台帳で管理し、定期的に見直すことをおすすめします。

まとめ

コンプライアンスポリシーの運用設計では、厳格なセキュリティ要件の定義だけでなく、「ユーザーに修正の機会を与える猶予期間の設計」や「段階的な展開計画」が重要になります。

次回 後編 では、実際にIntune管理センターでOSバージョンを判定条件としたポリシーを作成し、条件付きアクセスと連携させてアクセス制限の挙動を確認する手順を解説します。

Windows 11展開・Intuneポリシー設計でお困りですか?

株式会社アーザスでは、Windows 11リプレイスに伴う構成プロファイル・コンプライアンスポリシーの設計から、条件付きアクセスを活用したセキュリティ強化まで、現場に即した技術サポートを提供しています。
ぜひお気軽にお問い合わせください。