なぜ“準拠性 + CA”なのか
ID だけを守っても、脆弱な端末からのアクセスを許せば侵害リスクは残ります。
Intune の準拠性で端末の健全性を評価し、Entra 条件付きアクセス（CA） でアクセス可否を判断するのが王道です。（CA 概要）
連携の全体像
- Intune でプラットフォーム別の 準拠性ポリシー を作成（OS/暗号化/改変検出など）
- Entra の CA で 「デバイスが準拠していること」を必須 に設定。
必要に応じて MFA や場所条件を追加（ポリシー設計） - 例外が必要なアプリやユーザーは“除外”と“期限付きアクセス権”で管理
設計の型（Assignments/Controls）
- 割り当て（Assignments）：ユーザー/グループ、アプリ（Exchange/SharePoint/Teams など）、条件（場所、クライアントアプリ）。
- アクセス制御（Controls）：許可（MFA/準拠性必須）またはブロック。リスクベースやパスワードレス併用も検討。
- 段階適用：まず Report-only で影響を可視化→問題なければ On。
実装ステップ（例）
- Intune の デバイス準拠性ポリシー を作成（概要、Windows 設定）
- CA で “すべてのクラウドアプリ”に対し「準拠性必須＋MFA」を設定
経営層などは別ポリシーで条件を緩和 - レポート：サインインログと CA の結果を確認し、ブロック理由を特定
- チューニング：VPN/レガシープロトコル利用など特殊要件を除外し、最小限に抑える
よくある課題と解決
- MFA 要求が多すぎる：認証の強度プロファイルを活用し、条件に応じた多要素を最小化
- 非準拠端末の復旧が遅い：Intune 通知＋Company Portal の自己解決ガイドで復旧時間を短縮
- レガシー クライアント：モダン認証未対応のアプリは代替手段を検討、可能なら段階廃止
検証とロールバック
- What If ツールでポリシーの影響を事前検証。
- Report-only 期間を 1〜2 週間設け、ポリシー衝突を洗い出す。
- 重大インシデント時は 緊急ポリシー（準拠性要件の一時緩和や特定アプリのブロック）を発動できるようテンプレ化。
ケーススタディ（40 名の営業部門）
- 準拠性：OS 最新、BitLocker、改変なし、脅威レベル“中以上”でブロック。
- CA：MFA 必須、国外からのアクセスはブロック。
- 結果：誤検知 2 件は Report-only 中に除外調整、本番適用後の業務影響はゼロ。
監視と改善
- 主要 KPI：ブロック件数、復旧までの中央値、再発率、MFA 拒否率
- 月次レビューで“ブロックの上位理由”を潰し込み、ヘルプデスク FAQ を改訂
追加のヒント（CA 連携編）
- 🧰 緊急用バイパス：経営層の端末トラブル時に備え、限定時間の例外グループを用意
- 🔍 ログの突合：サインインログと Intune レポートを照合し、端末側の是正アクションへ即フィードバック
- 🧑🏫 ユーザー向け解説：“なぜブロックされたか”をポータルで可視化し、自己解決を促す
コメント