Microsoft Intune でポリシー設計を始めると、「何から設定すればよいのか」「どこまで厳しくしていいのか」で迷いがちです。本記事では、公式セキュリティ ベースラインと GitHub のサンプル テンプレートを軸に、初期構築から本番運用まで役に立つ Intune ポリシー設定のベストプラクティスを整理します。
Intune ポリシー設計でよくあるつまずき
Intune 管理を始めたばかりの担当者から、次のような声をよく聞きます。
- 「GPO と同じ感覚で設定を詰め込んだら、端末が一気に不便になった」
- 「テンプレートが欲しいが、どの値が“普通”なのか分からない」
- 「ポリシーが増えすぎて、どれが効いているのか分からない」
背景には次のようなパターンがあります。
- 製品の機能一覧から「使えそうな設定を片っ端からオン」にしている
- ビジネス要件ではなく「設定名ベース」で設計している
- テスト グループを作らず、いきなり全社に適用してしまう
この状況を避けるための、Intune ポリシー設計・展開の全体像を、まずは 5 ステップで俯瞰してみます。
Intune ポリシー設計 5 ステップ概要
| ステップ | 具体策 | 補足・ポイント |
|---|---|---|
| ① 公式セキュリティ ベースラインを利用 | Intune に標準搭載されている Windows 10/11・Microsoft Edge・Microsoft Defender for Endpoint などのセキュリティ ベースラインを有効化し、自社向けに最小限の微調整を行う。 | ベースラインには Microsoft 推奨値がプリセットされており、適用するだけで主要なセキュリティ ベストプラクティスを一括適用できる。 |
| ② カスタム ポリシーは要件ベースで設計 | ベースラインでカバーできない領域（アプリ構成、デバイス制限、条件付きアクセスなど）は、 「どのリスクを、どの操作で防ぎたいか」を明文化してから個別ポリシーを追加する。 | 先にコンプライアンスポリシー（OS バージョン・ BitLocker 必須など）で「合格ライン」を決めておくと、他のポリシーとの整合性が取りやすい。 |
| ③ GitHub リポジトリを活用 | Microsoft 公式の mggraph-intune-samples や PowerShell Intune Samples などから JSON テンプレート・スクリプトを取得し、ポリシーのエクスポート／インポートや一括作成を自動化する。 | サンプルは「そのまま本番投入」ではなく、必ずテスト テナントまたはテスト グループで動作確認してから、本番へ反映する。 |
| ④ パイロット運用 → 段階的展開 | 影響の大きい設定（USB 禁止、Firewall 例外、Credential Guard など）は IT 部門など小さなグループで試験適用し、問題がなければ部門単位 → 全社へと順に拡大する。 | 条件付きアクセスは「Report-only」モードで影響度を可視化してから有効化すると安全。 |
| ⑤ 監査 & レポート | セキュリティ ベースラインのコンプライアンス レポートやデバイス準拠レポートを定期的に確認し、 「どの設定でどの端末が落ちているか」を継続的に把握する。 | 非準拠デバイスには自動メール通知や条件付きアクセスによるアクセス制限を組み合わせると、運用負荷を大きく下げられる。 |
以降では、この 5 ステップをもう少し細かく分解しながら、実際の画面操作レベルに落とし込んで解説していきます。
Intune のポリシー種別と役割を整理する
まず、Intune で扱う代表的なポリシー種別と役割を整理しておくと、設計がブレにくくなります。
| 種別 | 主な目的 | 例 |
|---|---|---|
| コンプライアンスポリシー | 「端末が社内基準を満たしているか」を判定するための基準を定義 | 最小 OS バージョン、デバイス暗号化必須、パスコード要件 など |
| 構成プロファイル（設定カタログ / テンプレート） | Windows / macOS / iOS / Android の設定を構成 | 壁紙固定、ローカル管理者の制御、USB デバイス制限 など |
| エンドポイント セキュリティ ポリシー | Defender Antivirus / Firewall / Disk Encryption などのセキュリティ設定を集中管理 | Defender のリアルタイム保護、BitLocker の暗号化方式、Firewall ルール など |
| アプリ保護ポリシー（MAM） | 会社データのコピー／保存先を制御（BYOD 向け） | Outlook から個人 OneDrive への保存禁止、コピー & ペーストの制限 など |
| スクリプト（PowerShell / Shell） | ポリシーだけでは実現しにくい設定や、移行・メンテナンスを自動化 | 古いローカルアカウントの削除、既存 BitLocker の状態収集 など |
| 条件付きアクセス（Entra ID） | ユーザーのサインイン条件（場所・デバイス状態・アプリなど）に応じてアクセス制御 | 準拠デバイスかつ MFA 済みでなければ Exchange Online に接続させない など |
設計時は、いきなり設定カタログを開く前に、「これはコンプライアンスの話か？構成か？それともアクセス制御か？」と自問して、どのポリシー種別で実現するかを切り分けるところから始めるのがおすすめです。
公式セキュリティ ベースラインで「土台」を作る
セキュリティ ベースラインとは何か
セキュリティ ベースラインは、Windows や Edge、Defender などについて Microsoft セキュリティ チームが推奨する設定をまとめたテンプレートです。
- すぐに使える「プリセット」の集合
- CIS ベンチマークや Microsoft 自身の運用知見を反映
- すべての設定は後からカスタマイズ可能
たとえば Windows セキュリティ ベースラインの既定値では、リムーバブル ドライブへの BitLocker 自動有効化や、パスワード入力の必須化、基本認証の無効化など、多くのセキュリティ設定が一括で有効になります。
利用できる主なベースライン
Intune で利用できる主なセキュリティ ベースラインは次の通りです。
| ベースライン名（例） | 対象 | 用途のイメージ |
|---|---|---|
| Windows 10 and later Security Baseline | Windows 10 / 11 デバイス全般 | OS 全体のセキュリティを底上げする「標準セキュリティ プロファイル」 |
| Microsoft Defender for Endpoint 基準 | Defender for Endpoint を利用している Windows デバイス | EDR・次世代 AV・脅威検出を最大限活かすための推奨設定 |
| Microsoft Edge セキュリティ ベースライン | Edge ブラウザー | 安全なブラウジング、スマートスクリーン、パスワード管理などの強化 |
特に Windows デバイスでは、まず「Windows セキュリティ ベースライン」を全体の標準として適用し、Defender for Endpoint を導入している環境では、その上に「Defender for Endpoint ベースライン」をレイヤーとして重ねる構成が推奨されています。
セキュリティ ベースライン適用の実践ステップ
Intune 管理センターでのセキュリティ ベースライン適用の流れを、運用イメージ込みで整理すると次のようになります。
- Intune 管理センターにサインインし、[エンドポイント セキュリティ] > [セキュリティ ベースライン] を開く。
- 適用したいベースライン（例: Windows 10 and later）を選択し、「ポリシーの作成」を実行。
- 名前・説明を入力し、構成タブで各設定を確認する。初回は「既定値のまま」＋最小限の変更にとどめる。
- 割り当てで、まずは パイロット グループ（IT 部門や意識の高いユーザー）だけに適用する。
- 数日〜数週間、コンプライアンス レポートやユーザーの声を確認し、必要に応じて一部設定を緩和。
- 問題なければ、対象グループを部門単位 → 全社へ拡大する。
条件付きアクセスと組み合わせる場合は、ベースラインによって準拠判定が変わるため、先にベースラインを安定させてから条件付きアクセスを本格適用する方が安全です。
ベースラインのバージョン管理とアップデート
セキュリティ ベースラインは定期的にアップデートされ、新しいバージョンがリリースされます。古いバージョンを使い続けると、最新の脅威に追随できないだけでなく、「どの設定がいつのバージョン前提なのか」が分かりにくくなります。
運用のポイントは次の通りです。
- 新バージョンが出たら、まずテスト テナントやパイロット グループで検証する
- 既存プロファイルはアップデート時に差分 CSV をエクスポートできるので、「新規設定」「削除された設定」を確認してから置き換える
- 旧バージョンのプロファイルは「読み取り専用」になるが、そのまま残しておくと過去の設定の証跡としても活用できる
「ベースラインのカスタマイズをどこまで許すか」は組織によって異なりますが、原則としては「既定値からの変更を最小限にし、変更点はすべてドキュメントに残す」運用がトラブルを防ぎます。
要件ベースでカスタム ポリシーを設計する
セキュリティ ベースラインはあくまで「土台」です。業種や業務アプリに応じて必要になる細かな要件は、個別のカスタム ポリシーで実現します。
要件の書き出しから始める
いきなり設定カタログをスクロールするのではなく、まずは次の 3 つに分けて要件を書き出すのがおすすめです。
- セキュリティ要件（例: 管理者権限の制限、USB メモリ禁止、暗号化必須）
- 運用要件（例: 社内 proxy 設定の自動配布、社内証明書の配布、特定アプリの自動インストール）
- 利便性要件（例: Wi-Fi 設定の自動構成、プリンター配布、スタートメニュー構成）
これを Excel などにまとめ、「要件 → Intune のどの機能で実現するか」を紐付けると、設計がかなりクリアになります。
代表的な要件と Intune ポリシーの対応表
| 要件 | 主に使う機能 | 補足 |
|---|---|---|
| 最低 OS バージョンを Windows 11 22H2 以上にしたい | コンプライアンスポリシー | 「最小 OS バージョン」に値を設定し、条件付きアクセスで「準拠デバイスのみ許可」と組み合わせる。 |
| すべての端末で BitLocker を必須にしたい | エンドポイント セキュリティ（ディスク暗号化）＋ コンプライアンス | 暗号化ポリシーで BitLocker を有効化し、コンプライアンス側で「暗号化必須」にすることで未暗号化端末を検知。 |
| USB メモリへの書き込みを禁止したい | デバイス制限（構成プロファイル）＋ Defender の攻撃面削減ルール | 業務で例外が必要な場合は、「許可されるシリアル番号のみ許可」といった細かいルール設計も検討。 |
| ローカル管理者アカウントをなくしたい | エンドポイント セキュリティ（アカウント保護）＋ Azure AD / Entra ID のロール設計 | 「ローカル管理者に誰を含めるか」を最小権限で定義し、GPO 側に残存しているローカル管理者設定がないかも確認。 |
| Edge のセキュリティ設定を標準化したい | Edge セキュリティ ベースライン＋ 設定カタログ（ブラウザー） | ベースラインをベースに、社内ポータルのホームページ固定やパスワードマネージャーの扱いなどを追設定。 |
| 社外からは準拠デバイス＋ MFA だけ接続させたい | コンプライアンスポリシー＋条件付きアクセス | 条件付きアクセスで「準拠デバイス」かつ「多要素認証済み」を必須にする。 |
このように、「要件 → Intune 機能」のマッピング表を一度作ってしまえば、新しい要件が出てきても迷子になりにくくなります。
設定カタログは「微調整」と「例外」に絞る
設定カタログは非常に強力ですが、項目数が多いため、最初からここだけで完結させようとすると迷子になります。おすすめは次の順番です。
- まずセキュリティ ベースラインで大枠を決める
- どうしても足りない部分だけを設定カタログで追加する
- 例外が必要なユーザーや部門は、「別プロファイル＋別グループ」で分離する
一つのポリシー内で例外条件を複雑にするより、「標準」「例外」「さらに強化」といったプロファイルを作り、グループで割り当てを分ける方が運用がシンプルになります。
GitHub の Intune サンプルで設計と運用を効率化
「ゼロからポリシーを作る」のは学びになりますが、時間もかかります。Microsoft 公式の GitHub リポジトリには、Intune 管理者向けのサンプルやスクリプトが多数公開されています。
代表的な Microsoft 公式リポジトリ
| リポジトリ名（検索キーワード） | 内容 | 主な用途 |
|---|---|---|
mggraph-intune-samples | Microsoft Graph 経由で Intune リソースにアクセスする PowerShell サンプル集。 | 既存ポリシーのエクスポート、JSON テンプレのインポート、設定値の一括更新など。 |
| PowerShell Intune Samples（「Powershell Intune Samples」などで検索） | REST API や Graph API を利用した各種自動化スクリプト。 | デバイスの一括ワイプ／リタイア、レポートの自動生成、Win32 アプリのアップロードなど。 |
shell-intune-samples | Intune 管理用のシェルスクリプト サンプルを集めたリポジトリ。 | macOS や Linux 向けのスクリプト配布、ログ収集などに応用可能。 |
これらのリポジトリ名は、GitHub や検索エンジンでそのままキーワードとして利用できます。
サンプル スクリプト活用の基本フロー
サンプルを安全に活用するための、現実的なフローの一例です。
- 目的を決める
例: 「現状のセキュリティ ベースライン設定を JSON としてバックアップしたい」 - GitHub で検索
「mggraph-intune-samples backup baseline」などで近いサンプルを探す。 - コードレビュー
認証方法（アプリ登録／デリゲート権限）、書き込み系操作の有無（DELETE / POST）がないかを確認し、意図しない削除や変更をしないようにする。 - テスト テナントまたはテスト グループで実行
テナントを分けられない場合でも、サンドボックス用 Azure AD グループを用意し、そこだけを対象にする。 - 本番反映
スケジュール実行が必要なものは Azure Automation や GitHub Actions などと連携して定期ジョブ化する。
GitHub のサンプルはあくまで「ひな形」です。コードの意味を理解せずに実行すると、大量のポリシー削除や誤った設定上書きにつながる可能性があるため、必ずレビューを挟みましょう。
パイロット運用と段階的展開のベストプラクティス
ポリシーの内容がどれだけ正しくても、展開の仕方を間違えると業務停止につながります。ここでは、現実的に使いやすい「リング型（段階的）展開」の例を紹介します。
推奨グループ構成の例
| グループ名の例 | 対象ユーザー / デバイス | 目的 |
|---|---|---|
| Intune-Pilot-IT | IT 部門、セキュリティ担当 | 最もリスク許容度が高いメンバーで、新ポリシーの動作確認を行うリング 0。 |
| Intune-Ring1-EarlyAdopters | IT と親和性の高い部門（情報システム寄り） | ユーザー視点での影響を早期に確認するリング 1。 |
| Intune-Ring2-Dept-XX | 主要部門ごとのグループ | 部門単位で徐々に適用範囲を広げるリング 2。 |
| Intune-Ring3-All | 全社 | 十分な検証が終わった後に適用する最終リング。 |
Azure AD の動的グループを使えば、「Windows 11 かつ 社員区分 = 正社員」のように条件ベースでグループを組めるため、展開ミスを減らせます。
影響の大きい設定は段階と時間をかけて
特に注意したいのは、次のような設定です。
- USB ストレージの禁止
- Firewall ルールの大幅な変更
- 古いプロトコル（SMBv1 や TLS 1.0）の無効化
- 旧 OS / 旧 Office の完全ブロック
これらは「やるべき」設定であっても、いきなり全社に適用すると、現場で使われている古い機器や業務アプリが動かなくなり、想定以上の混乱を招くことがよくあります。
実務では、次のようなイメージで進めると安全です。
- リング 0（IT 部門）で適用し、ログとユーザーの声を集める
- 問題がなければ、リング 1（Early Adopters）に拡大
- 影響が見えたら、代替手段や例外ルールを検討しつつ、リング 2 → リング 3 へ順次展開
条件付きアクセスの Report-only モードを活用
条件付きアクセスは誤設定すると「全員サインイン不可」といった事故につながるため、必ず Report-only モードで影響を確認してから有効化しましょう。Report-only モードでは、実際のサインインに対して「もしこのポリシーが有効だったらどうなっていたか」がサインインログに記録されます。
おすすめの流れは次の通りです。
- 対象ユーザー・アプリ・条件を設定したポリシーを作成し、「有効化」を Report-only に設定。
- 数日〜数週間、サインインログやワークブックで結果を確認し、「どのユーザーがブロックされそうか」を把握。
- 例外が必要なアカウント（サービスアカウント、来訪者用端末など）を洗い出す。
- 問題がなければ、リング 0 / リング 1 から順に「オン」に切り替えていく。
セキュリティ ベースライン＋ Intune ポリシーで「端末側の安全性」を上げつつ、条件付きアクセスで「アクセス経路と条件」を押さえると、ゼロトラスト的な構成に近づいていきます。
Intune とグループポリシー（GPO）の競合を避ける
オンプレミスの Active Directory 環境から移行中の組織では、GPO と Intune の設定がぶつかるケースがよくあります。Microsoft の説明によると、原則として ドメイン レベルの GPO が Intune ポリシーより優先されますが、Windows 10 1803 以降では MDMWinsOverGP という設定により、一部の MDM ポリシーを優先させることもできます。
ただし、この挙動はすべての設定に一律で適用されるわけではなく、Policy CSP に含まれるポリシーなど特定の範囲に限定されます。そのため、ベストプラクティスとしては次のような方針が推奨されます。
- 同じ設定を GPO と Intune の両方で構成しない（どちらか一方に寄せる）
- 移行前に Group Policy Analytics を使って、既存 GPO の一覧と Intune へのマッピング可能性を分析する
- Intune 側でポリシーを作り込んだら、段階的に GPO を無効化／削除していく
特にセキュリティ系の設定（Firewall・Defender・暗号化など）は、どのチャネルから適用しているかを洗い出しておかないと、「Intune で変更したのに GPO に上書きされる」といった状況になりがちです。
監査・レポートで「作って終わり」を防ぐ
Intune の強みの一つは、「設定した結果」をレポートで継続的に追えることです。セキュリティ ベースラインやコンプライアンスポリシーには、それぞれ専用のレポート機能が用意されています。
セキュリティ ベースラインのコンプライアンス レポート
[エンドポイント セキュリティ] > [セキュリティ ベースライン] から対象ベースラインを選ぶと、次のような観点で状況を確認できます。
- ベースラインごとの準拠デバイス数／非準拠デバイス数
- どの設定項目で非準拠になっているか
- 時間経過による改善状況
このレポートを週次または月次の定例会で確認し、「どの設定を、どの期限までに是正するか」をチーム内で合意しておくと、セキュリティ レベルを継続的に引き上げていけます。
コンプライアンスポリシーの活用
コンプライアンスポリシーは、「基準を満たしていないデバイス」を洗い出すための機能です。OS バージョンや暗号化状態だけでなく、「ルート化・ジェイルブレイクされているか」「セキュリティ パッチの最新度」などもチェック対象にできます。
条件付きアクセスと組み合わせれば、「非準拠デバイスからは Exchange Online に接続させない」といった制御も可能です。非準拠を検知した際に、ユーザーに自動メールを飛ばすフローを Power Automate などで作っておくと、運用チームの手作業を減らせます。
監査ログとトラブルシューティング
ポリシー変更があった際の監査ログや、デバイス側の Intune ログもトラブルシューティングに役立ちます。
- いつ、誰が、どのポリシーを変更したか
- その結果として、どのデバイスがエラーや競合状態になっているか
こうした情報を追えるようにしておくと、「昨日の夜から一部の端末だけ VPN が繋がらない」といった問い合わせにも、原因をピンポイントで特定しやすくなります。
中小企業向け：サンプル構成シナリオ
最後に、「Windows 11 PC が 100 台程度の中小企業で、Intune 管理をこれから本格導入する」ケースを想定したサンプル構成を簡単に紹介します。
前提条件
- Microsoft 365 Business Premium または同等のライセンスを利用
- Windows デバイスはすべて Azure AD 参加＋自動登録（Autopilot は今後導入予定でも可）
- Defender for Endpoint も併用（P1/P2 相当）
推奨ポリシー セット
| カテゴリ | 具体的なポリシー | 備考 |
|---|---|---|
| セキュリティ ベースライン | Windows 10 and later ベースライン（標準） | 全端末に適用。初回は IT 部門のみ → 段階的展開。 |
| セキュリティ ベースライン | Defender for Endpoint ベースライン | Defender for Endpoint ライセンスがある端末にのみ適用。 |
| コンプライアンス | OS 最小バージョン（例: Windows 11 22H2）、暗号化必須、パスコード要件 | 条件付きアクセスと連携して「準拠デバイスのみ社外からのアクセス許可」に利用。 |
| 構成プロファイル | 社内 Wi-Fi / VPN プロファイル、社内証明書、プリンター配布 | 利便性向上を目的とした設定。セキュリティ ベースラインとは別プロファイルで管理。 |
| エンドポイント セキュリティ | BitLocker、Defender Antivirus、Firewall の詳細設定 | ベースラインで足りない部分を補完するイメージで最小限に。 |
| 条件付きアクセス | すべてのクラウド アプリに対して、「準拠デバイスかつ MFA 必須」ポリシー | まず Report-only モードで影響を確認してから段階的に有効化。 |
この構成に、必要に応じて「USB 制限」や「ローカル管理者制御」などのポリシーを追加していくイメージです。最初から盛り込みすぎず、「ベースライン＋コンプライアンス＋最低限の構成」からスタートし、レポートを見ながら徐々に強化していく方が現実的です。
まとめ：テンプレートと GitHub を味方にした Intune 運用
Intune のポリシー設計は、一見すると設定項目の多さに圧倒されますが、次の流れを押さえておけば迷いにくくなります。
- まずは公式セキュリティ ベースラインで「最低限守るべき設定」を一括適用する
- カスタム ポリシーは、ビジネス要件・セキュリティ要件から逆算して設計する
- GitHub の公式サンプルを使って、設定のバックアップや一括作成・比較を自動化する
- 必ずパイロット グループと Report-only モードで影響を確認してから全社展開する
- セキュリティ ベースラインとコンプライアンス レポートを定期的に確認し、「作って終わり」にしない
「Intune security baseline」「Microsoft Intune Samples GitHub」などのキーワードで検索しながら、本記事の内容を自社環境にあてはめていけば、ゼロからのポリシー設計でも迷いを大きく減らせるはずです。まずは小さな範囲でベースラインを試し、レポートを見ながら一歩ずつ強化していきましょう。
コメント