Azure Conditional Access ポリシー設計完全ガイド｜推奨ベースライン・テンプレート・実装パターン

Microsoft Entra ID の Conditional Access (条件付きアクセス) は、現代的なエンタープライズ ID 管理の中核技術です。 ユーザー・グループ・アプリ・サインインリスク・デバイス状態・場所などの条件を評価し、動的にアクセス制御を行う仕組みで、ゼロトラスト戦略の Identities 柱の中心。 本記事では、Conditional Access の基本動作・推奨ベースラインポリシー・実装テンプレート・運用ベストプラクティス・落とし穴を網羅的に整理します。

Conditional Access の基本動作

Conditional Access ポリシーは 『Conditions (条件) → Controls (制御)』 の構造で定義します。

Conditions (条件)

• Users / Groups: 対象ユーザー・グループ・ゲスト・特定ロール
• Cloud apps or actions: Microsoft 365・Azure・サードパーティ SaaS アプリ
• Conditions: Sign-in Risk・User Risk・デバイスプラットフォーム・場所 (Named Locations)・クライアントアプリ・デバイス状態 (Compliant / Hybrid Joined)・フィルター

Controls (制御)

• Grant Controls: Block / Grant access、Grant 時の追加要求 (MFA・デバイス準拠性・Hybrid Azure AD Join・承認済みアプリ・パスワード変更・利用規約同意)
• Session Controls: Sign-in Frequency・Persistent Browser Session・App Enforced Restrictions・Conditional Access App Control (CASB)・Customize continuous access evaluation

前提条件: ライセンスと初期設定

Conditional Access を有効にするには以下が必要です。

• Microsoft Entra ID Premium P1 以上 (Microsoft 365 E3 / Business Premium / Entra ID P1 単体)
• 対象ユーザー全員に Premium P1 ライセンス割り当て (例: 1000 ユーザー対象なら 1000 P1 ライセンス必要)
• Premium P2 で追加機能: リスクベース Conditional Access (Identity Protection)・PIM 連携
• Security Defaults と併用不可 (Conditional Access 有効化で Security Defaults 自動 Disable)

推奨ベースラインポリシー 7 種

Microsoft が公開する Conditional Access のベースライン (推奨スタートセット) は以下の通り。新規 Conditional Access 運用は、これらを Report-only で順次導入するのが定石です。

1. 管理者ロールに MFA 要求: Global Admin・Privileged Role Admin など 14 ロール対象。特権アクセスの第一防衛線。
2. すべてのユーザーに MFA 要求: 全社展開。Block アカウント侵害の最大効果。
3. 既知のリスクサインインをブロック: Identity Protection 連携、High Risk Sign-in を Block (Premium P2 必須)。
4. レガシー認証をブロック: POP/IMAP/SMTP/Basic Auth (MFA Bypass の典型経路)。
5. 管理ポータルアクセスに MFA 要求: azure-portal・admin-portal・microsoft-intune-portal などターゲットアプリ指定。
6. 非準拠デバイスからのアクセスをブロック: Microsoft Intune Compliance Policy 連携。
7. 国別アクセス制限: 中国・ロシア・北朝鮮などからのアクセスをブロック (Named Locations 活用)。

Report-only モードの活用

Report-only モードは、Conditional Access ポリシーを実際に強制せず、適用結果のみログに記録するテストモードです。

• 新規ポリシー展開時は必ず Report-only で 1-2 週間運用、想定外の Block 発生を Sign-in Logs で確認
• 誤ったポリシー (例: 全ユーザーに iOS デバイス要求) を本番強制すると、Windows ユーザー全員がログイン不可になる事故
• Sign-in Logs の Report-only 結果欄で『Failure - Reported only』のステータスを確認
• What If ツールでも事前シミュレーション可能

Break Glass Account (緊急アクセス)

Conditional Access 運用の最重要前提条件が Break Glass Account の例外設定です。

1. 必ず 2 つの Break Glass Account を作成 (1 つは Conditional Access 例外、もう 1 つは追加保険)
2. Cloud-only アカウント (オンプレ AD 同期不可、AD FS / Federated 非対応)
3. 16 文字以上の超強力パスワード (パスワード管理ツールで物理的に分離保管)
4. Global Administrator ロール永続割り当て (PIM Eligible ではなく Active)
5. すべての Conditional Access ポリシーで除外設定に追加
6. サインインアラート設定 (使用時に CISO / IT セキュリティチームに通知)

Break Glass Account を設定し忘れると、Conditional Access の誤動作時に組織の全管理者がログイン不可になる致命的な事故が発生します。

Named Locations の設計

Named Locations は、IP アドレス範囲 (CIDR) または国を Named Location として定義し、Conditional Access の Conditions で参照する機能。

Session Controls の活用

Session Controls は、認証後のセッション動作を制御します。

Sign-in Frequency

• 機密データアクセス時 → 1 時間ごとに再認証
• 管理者ポータル → 4 時間ごと
• 一般ユーザー → 8 時間 (1 営業日)
• 高セキュリティ環境 → ブラウザ閉じるたびに再認証 (Persistent Browser Session を Never)

その他

• Persistent Browser Session: Always / Never の切り替え。Shared Computer 環境は Never 推奨。
• App Enforced Restrictions: SharePoint / OneDrive で『Web ブラウザのみ、ダウンロード不可』のような制限
• Conditional Access App Control: Microsoft Defender for Cloud Apps (CASB) との連携、サードパーティ SaaS でのインライン監視

テスト・運用ベストプラクティス

1. Report-only で 1-2 週間運用、Sign-in Logs で適用結果を確認
2. 影響範囲を絞った Pilot Groupで 1 週間先行強制 (例: IT 部門 50 名のみ)
3. What If ツールで個別ユーザーの想定動作をシミュレーション
4. 段階的に対象ユーザー拡大 (Pilot → 100 名 → 500 名 → 全社)
5. Microsoft Sentinel への Sign-in Logs 集約で異常検知
6. 定期的なポリシーレビュー (四半期に 1 回、Microsoft Secure Score 確認)

Conditional Access の落とし穴

1. Break Glass Account を Conditional Access から除外し忘れ: 最致命的な事故。必ず 2 つ作って例外設定。
2. Report-only を経ずに本番強制: 全社ロックアウト事故の典型。
3. Named Locations を Trusted (信頼済み) に分類: リスクポリシーが効かなくなる。Trusted は本当に必要な場合のみ。
4. Service Principal / Managed Identity への CA 設定漏れ: 近年は Workload Identity に対する CA も対応。
5. サードパーティアプリのレガシー認証: Slack・Salesforce 等で Basic Auth が残ると CA が効かない。
6. Mobile アプリの App Password Bypass: 古いプロトコル使用アプリで MFA 迂回。

関連認定試験

• SC-300 (Identity and Access Administrator Associate): Conditional Access が深く問われる。
• MS-102 (Microsoft 365 Administrator Expert): ドメイン 2 (Identity and Access)。
• SC-100 (Cybersecurity Architect Expert): ゼロトラスト戦略の中核。
• SC-200 (Security Operations Analyst): Sentinel との連携・Identity Protection。

よくある質問

本記事の技術情報は Microsoft Entra Conditional Access Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure、Microsoft Entra は Microsoft group of companies の商標です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。