条件付きアクセスのMFA除外、場所例外、端末条件、break glassを安全に棚卸しする実務手順。例外の理由、期限、ログ、初動対応、判断基準を整理します。
冒頭要約
条件付きアクセスは、ユーザー、場所、端末状態、対象アプリ、サインインリスクなどを組み合わせて、アクセスを許可・追加認証・ブロックする仕組みです。Microsoft EntraではConditional Access、Google WorkspaceやGoogle CloudではContext-Aware AccessやAccess Context Managerのような名称で、似た考え方が使われます。
ただし、どれだけ強いポリシーでも、MFA除外、場所例外、端末条件の免除、特定アプリ除外、break glass除外が増えると、実際の防御力は下がります。例外は業務継続に必要な場合がありますが、所有者、理由、期限、補完統制、ログ確認がなければ、標準ルールを迂回する固定ルートになります。
まずやるべきことは、例外を一括削除することではありません。対象、理由、期限、ログ、最近のサインイン、代替統制を棚卸しし、削除してよい例外、短期継続が必要な例外、セキュリティ初動へ切り替える例外を分けます。
この記事は、情シス、SaaS管理者、IdP管理者、CSIRT、開発組織の管理者向けに、条件付きアクセス例外を安全に見直す手順を整理します。攻撃手順や回避方法ではなく、防御・確認・初動対応・判断基準に限定します。
読者別の影響：誰が何を見るべきか
条件付きアクセス例外は、IdP管理者だけの設定項目ではありません。例外の対象には、メール、ファイル共有、GitHub、CRM、会計SaaS、管理画面、開発者ツール、緊急用管理者アカウントが含まれるため、複数の担当が同じ前提を共有する必要があります。
| 読者・担当者 | 影響 | まず見る場所 |
|---|---|---|
| 情シス・IdP管理者 | MFA・端末・場所条件の実効性が下がる | 条件付きアクセスポリシー、除外ユーザー/グループ、named locations、サインインログ |
| SaaS管理者 | SSO配下でも特定アプリだけ弱い条件で使われる | 対象アプリ、管理者権限、外部ユーザー、OAuthアプリ、監査ログ |
| 開発者・DevOps | GitHub、CI/CD、クラウド管理画面の高権限操作に影響する | Organization owner、管理者グループ、端末条件、IP例外、API連携 |
| CSIRT・SOC | 侵害時に「正規ログイン」に見えやすい | サインイン成功、MFA結果、端末情報、場所、ユーザーエージェント、操作ログ |
| 監査・管理部門 | 例外の根拠と期限を説明する必要がある | 申請チケット、承認者、期限、再確認日、補完統制、レビュー履歴 |
重要なのは、「ログインできる」ことと「必要な範囲だけ使える」ことを分けて見ることです。基礎を整理したい場合は、認証と認可の違いを先に確認すると判断しやすくなります。
まず確認すること：条件付きアクセス例外の10項目チェック
棚卸しでは、ポリシー名だけでなく、実際に誰が、どの条件で、どのアプリへアクセスできるかを確認します。Microsoft Learnでも、条件付きアクセスはユーザー、グループ、場所、端末、アプリ、リスクなどのシグナルを組み合わせる前提で説明されています。つまり、例外も同じ粒度で見なければなりません。
| 確認項目 | 見るポイント |
|---|---|
| 1. 除外ユーザー/グループ | 個人直指定、古いグループ、退職者、委託先、特権ロールが含まれていないか |
| 2. MFA除外 | 対象者、対象アプリ、期間、代替認証、承認者、ログ通知があるか |
| 3. 場所例外 | trusted locationやnamed locationが広すぎないか、家庭回線や委託先IPが混ざっていないか |
| 4. 端末条件 | compliant device、管理端末、OS条件、ブラウザ条件の除外が説明できるか |
| 5. アプリ除外 | レガシーアプリ、管理画面、メール、ファイル共有、GitHub、クラウド管理が除外されていないか |
| 6. break glass | 非常用アカウントの除外理由、監視、訓練、保管、利用通知があるか |
| 7. サービスアカウント | 人間用ポリシーの抜け道として長期トークンや共有IDが残っていないか |
| 8. report-only | 変更前に影響確認できる状態か、サインインログで結果を見ているか |
| 9. ログ保管 | サインインログ、監査ログ、ポリシー変更履歴、管理者操作を追えるか |
| 10. 期限と所有者 | 例外の終了日、再確認日、承認者、実作業者、業務オーナーが残っているか |
SaaS権限棚卸しチェックリストを使う場合は、通常の管理者権限やOAuth同意に加えて、「条件付きアクセス除外」「MFA除外」「場所例外」「端末条件の例外」を項目として追加すると、確認漏れを減らせます。
Microsoft Entraの条件付きアクセスでは、ユーザーやグループがincludeとexcludeの両方に含まれる場合、excludeが優先されると説明されています。つまり「全員にMFAを要求している」つもりでも、除外グループに入っているユーザーには効かない可能性があります。
初動対応：不明な例外や不審ログを見つけたとき
条件付きアクセス例外を見つけたとき、最初にやるべきことは、削除ボタンを押すことではありません。業務停止や管理者ロックアウトにつながる可能性があるため、事実確認、影響把握、代替経路、ログ保全を分けて進めます。
やること
- 例外の対象ユーザー、グループ、アプリ、場所、端末条件、作成日、最終更新日を記録する。
- 直近30日から90日程度のサインインログを見て、成功/失敗、MFA結果、端末、場所、対象アプリを確認する。
- 例外の理由、承認者、期限、補完統制が既存チケットや台帳に残っているか確認する。
- break glassや唯一の管理者に関係する例外は、代替復旧経路を確認してから変更する。
- 変更が必要な場合は、report-onlyや小さな対象グループで影響を見てから本番適用する。
- 説明できないサインイン、想定外の国/地域、管理者操作があれば、漏えい疑い初動テンプレートへ切り替える。
やらないこと
- 影響確認なしに、すべてのMFA除外や場所例外を一括削除しない。
- 「社内IPだから安全」として広いIPレンジを恒久的に信頼しない。
- 例外ユーザーを通常業務用アカウントや共有アカウントに混ぜない。
- 例外理由を「業務上必要」の一文だけで残さない。
- 不審なサインインを「VPN利用だろう」と推測だけで閉じない。
記録すること
| 記録項目 | 具体例 |
|---|---|
| 対象 | ポリシー名、ユーザー/グループ、アプリ、場所、端末条件、対象ロール |
| 例外理由 | 業務制約、復旧経路、非対応アプリ、委託先条件、移行期間 |
| 補完統制 | 送信元制限、短期期限、ログ通知、承認、手動レビュー、権限縮小 |
| ログ | サインイン時刻、MFA結果、端末、IP、国/地域、操作内容、相関ID |
| 判断 | 継続、期限設定、削除、report-only検証、追加調査、インシデント化 |
判断基準：どこから危険度を上げるか
例外の危険度は、存在するかどうかだけでは決まりません。誰に対する例外か、どのアプリに効くか、期限があるか、ログで追えるか、不審な利用があるかを組み合わせて判断します。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | 特権管理者、Organization owner、Super Admin、break glass以外の高権限ユーザーがMFA除外されている | 直近ログを確認し、代替認証・PIM/JIT・期限付き例外へ移す |
| 高 | 広いグループや全従業員に近い単位で場所例外・端末例外が効いている | 影響範囲を分割し、report-onlyで縮小案を検証する |
| 高 | 例外ユーザーで説明できないサインイン成功、端末登録、MFA変更、管理者操作がある | ログ保全、セッション失効、認証情報更新、CSIRT報告を検討する |
| 中 | 非対応SaaSや共有端末のために例外が必要だが、期限や承認者がない | セキュリティ例外申請へ移し、期限と補完統制を設定する |
| 中 | trusted locationが古い拠点、VPN、委託先、家庭回線を含んでいる | 利用実態を確認し、必要最小限の範囲に絞る |
| 低 | 期限、所有者、監視、訓練があり、直近ログも想定内 | 台帳を更新し、次回レビュー日を設定する |
Microsoft Learnでは、条件付きアクセスを本番適用する前に影響を確認するためのreport-only modeや、サインインログで評価結果を見る方法が説明されています。実務では、例外削除も同じです。変更前に「誰が困るか」ではなく、「誰がどの条件で止まるか」をログと小さな検証で確かめます。
よくある誤解
「trusted locationならMFAなしでも安全」
場所は重要なシグナルですが、場所だけで本人や端末の安全性を保証するものではありません。VPN、プロキシ、委託先回線、共有拠点、侵害端末が混ざると、trusted locationは攻撃者にも使える条件になります。場所例外は、端末状態、ユーザー、対象アプリ、ログ監視と組み合わせて判断します。
「break glassは除外が必要なので、監視しなくてよい」
逆です。緊急用管理者アカウントは通常の条件付きアクセスから除外する場合があるからこそ、サインイン通知、監査ログ、保管、訓練、利用後レビューが必要です。非常用アカウントを通常業務へ使うと、例外が恒久的な弱点になります。
「report-onlyで成功しているので安全」
report-onlyは影響確認のための材料であり、運用設計の代わりではありません。対象ユーザー、対象アプリ、例外条件、ログの見方、サポート体制、ロールバック方法を用意したうえで、本番適用の判断を行います。
「MFA除外は短期間なら記録しなくてよい」
短期間の例外ほど、期限と終了条件を明確にする必要があります。記録がない短期例外は、担当者の異動やチケットの埋没によって長期例外になりやすいからです。
関連用語・関連ページ
| 目的 | 内部リンク |
|---|---|
| 用語を理解する | Conditional Access、Device Posture、Risk-Based Authentication、IdP |
| 認証・権限を整理する | MFA、PAM、JIT Access、最小権限の原則 |
| 実務チェックへ進む | SaaS権限棚卸しチェックリスト、退職者アカウント確認チェックリスト |
| 例外管理を整える | セキュリティ例外申請の書き方、緊急用管理者アカウントの棚卸し |
| ログ確認へ進む | セキュリティログの読み方、Audit Log、Log Retention |
| 初心者向けに練習する | ログイン失敗ログの読み取りミニCTF、認証と認可のミニCTF、用語クイズ |
まとめ：例外は「消す」より先に、説明できる状態へ戻す
条件付きアクセス例外は、ゼロにすればよいものではありません。緊急用管理者アカウント、非対応SaaS、移行期間中の共有端末、委託先アクセスなど、現実には短期的な例外が必要な場面があります。問題は、例外が理由・期限・監視なしに残り続けることです。
最初の一歩は、MFA除外、場所例外、端末条件、アプリ除外、break glassを一覧化し、所有者、期限、ログ、補完統制を付け直すことです。説明できないサインインや管理者操作があれば、棚卸しではなく初動対応へ切り替えます。
次に実務へ落とすなら、SaaS権限棚卸しチェックリストに条件付きアクセス例外の項目を追加し、四半期レビューで繰り返し確認してください。恒久的な例外を減らすには、ゼロトラストアーキテクチャの考え方に沿って、ユーザー、端末、場所、アプリ、リスクを継続的に見直すことが重要です。
公式情報・参考情報
- Microsoft Learn: What is Conditional Access? 条件付きアクセスが、ユーザー、場所、端末、アプリ、リスクなどのシグナルを組み合わせてアクセス制御を行う考え方を確認できる。
- Microsoft Learn: Conditional Access users, groups, agents, and workload identities include/excludeの関係、除外がincludeを上書きすること、break glass用途の除外を確認できる。
- Microsoft Learn: Plan a Conditional Access deployment テストユーザー、report-only、ロックアウト回避、例外の限定利用、ポリシー運用の考え方を確認できる。
- Microsoft Learn: Analyze Conditional Access policy impact report-only modeでポリシー影響を確認し、サインインログで結果を見る考え方を確認できる。
- Microsoft Learn: Conditional Access network assignments named locationsやIP/場所条件を条件付きアクセス判断に使う考え方を確認できる。
- Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID 緊急アクセスアカウントを条件付きアクセス除外、監視、定期検証と合わせて管理する考え方を確認できる。
- Google Cloud: Access Context Manager Overview ユーザー、端末、IPアドレスなどのコンテキストを用いてアクセスレベルを定義する考え方を確認できる。
- NIST SP 800-207: Zero Trust Architecture アクセス要求ごとに継続的に検証し、暗黙の信頼を置かないゼロトラストの原則を確認できる。
