【Entra ID】条件付きアクセスの除外ユーザーを増やしすぎた時の棚卸しと整理

条件付きアクセスポリシーでトラブルシューティングを行う際、特定ユーザーを緊急で除外対象に追加することは珍しくありません。しかし、運用を続けるうちに除外ユーザーが増えすぎて、当初意図したセキュリティ要件が形骸化してしまうケースが多く見られます。本記事では、Entra ID(旧Azure AD)の条件付きアクセスで除外ユーザーが膨れ上がった状態を棚卸しし、安全かつ効率的に整理する方法を解説します。原因の特定から代替手段の検討、再発防止までを実務的にまとめました。

1. なぜ除外ユーザーが増えすぎるのか?原因とリスク

条件付きアクセスでユーザーを除外する運用は、特定のアクセス制限を回避したい場合に使われます。しかし、以下のような背景から除外ユーザーが徐々に増加していきます。

原因1:緊急時の一時的な除外がそのまま残る

ある新システムの導入時やアプリケーションのテスト期間中、特定ユーザーがポリシーに引っかかり業務が止まったため、「一時的に除外」として追加されたケースです。問題が解決した後も除外が解除されず、数年単位で残っていることがあります。このような除外は、担当者の異動や退職により管理が途切れると、そのまま恒久化します。

原因2:管理者権限の分散と属人管理

複数の管理者がそれぞれの判断で除外ユーザーを追加できる環境では、誰がどんな理由で除外したかがブラックボックス化しやすくなります。例えば、ヘルプデスクが一時回避のために除外し、その情報を共有しないまま後任者がさらに別のユーザーを追加する、という悪循環に陥ります。

原因3:ポリシーの細分化不足

「すべてのクラウドアプリに対して多要素認証を要求する」という単一ポリシーで運用していると、特定アプリだけMFAをスキップしたい場合にユーザー単位の除外しか選択肢がなくなります。本来であればアプリごとに独立したポリシーを設定し、対象範囲を絞るべきです。

これらの原因が重なることで、除外ユーザーは無秩序に増え、セキュリティホールになり得ます。数百人規模の組織では、除外ユーザーが全ユーザーの10%を超えることも珍しくありません。

2. 除外ユーザー増加による具体的な問題

除外ユーザーが増えると、以下のような実務上の問題が発生します。

• セキュリティリスクの増大: 除外ユーザーは条件付きアクセスの保護対象外となるため、パスワードのみの認証や未準拠デバイスからのアクセスを許容することになります。特に管理職や特権アカウントが除外対象になっていると、攻撃者に狙われやすい状態になります。
• 監査対応の困難: 内部監査やコンプライアンス監査で「なぜこのユーザーが除外されているのか」と問われたとき、理由が明確でないと説明責任を果たせません。除外ユーザーの棚卸しをしていないと、監査で指摘されるリスクがあります。
• 管理工数の増加: ユーザーの入退社や異動に伴い除外対象のメンテナンスが発生しますが、除外リストが長いほど更新漏れが発生しやすくなります。結果として、不要な除外が残り続けるだけでなく、新たなユーザーを追加するたびに一覧の確認が必要になります。

3. 棚卸し・整理の事前準備:確認すべき情報

整理を始める前に、以下の情報を事前に収集しておくとスムーズです。

1. Entra ID管理センターに条件付きアクセスの管理者権限(条件付きアクセス管理者以上)でログインできることを確認します。
2. 現在有効なすべての条件付きアクセスポリシーをエクスポートします。PowerShellの「Get-MgIdentityConditionalAccessPolicy」コマンドレットを使用すると一括取得できます。
3. 各ポリシーの「除外」タブに設定されているユーザーとグループを一覧化します。特に、個別ユーザー(ユーザーID)が指定されている場合はレガシーな運用の可能性が高いため注意します。
4. 除外理由の記録があるかどうかを確認します。チケット管理システムや変更管理記録と突き合わせると、理由が不明な除外を特定できます。
5. 代替手段として利用可能な機能(後述)を調査します。例えば、場所ベースの条件やリスクベースのアクセス制御が導入済みかどうかを確認します。

4. ステップバイステップ:除外ユーザーの棚卸し手順

以下の手順で、除外ユーザーを整理していきます。影響を最小限に抑えるため、必ず非稼働時間帯に実施してください。

1. 一時的にすべての除外を無効化するテスト用ポリシーを作成する: 既存ポリシーをコピーし、テストモード(レポートのみ)に設定して、除外を一旦外した状態でログを収集します。これにより、どのユーザーが影響を受けるか事前に把握できます。
2. 除外ユーザーごとに必要性を確認する: 各ユーザーに連絡を取り、なぜ除外が必要なのかヒアリングします。チケットや変更履歴がない場合は、原則として除外を解除する方向で調整します。
3. 代替手段を検討する: どうしても除外が必要なユーザーについては、ユーザー個別除外ではなく、動的グループによるグループ除外や、他の条件(信頼できるIPアドレス範囲の追加)で回避できないか検討します。下記の比較表を参考にしてください。
4. 除外をグループ化して管理する: 個別ユーザー指定をすべてグループ指定に置き換えます。例えば「MFA除外グループ」を作成し、そのグループにユーザーを追加します。グループのメンバーシップを動的にする(部署や役職ベース)とさらに管理が楽になります。
5. ポリシーを設計し直す: 一つのポリシーにすべての条件を詰め込むのではなく、アプリケーションごと、アクセス元ごとにポリシーを分割します。そうすることで、除外ユーザーを最小限にできます。
6. 変更を適用し、影響を監視する: 整理後のポリシーを本番環境に適用したら、サインインログを数日間監視し、ブロックやMFAチャレンジが増えていないか確認します。問題があれば迅速にロールバックできる準備をしておきます。
7. 定期的なレビューサイクルを設定する: 四半期ごとなど定期的に除外ユーザー一覧を見直すルールを作り、担当者を決めておきます。このサイクルを継続しないと、また元の状態に戻ってしまいます。

5. 代替手段の比較と選択

ユーザー単位の除外に代わる手段として、以下の選択肢があります。状況に応じて適切な方法を選んでください。

手法	概要	メリット	デメリット	適したケース
動的グループによる除外	ユーザー属性(部署、役職など)に基づいて自動的にメンバーシップが更新されるグループ	管理工数削減、ルールベースで一貫性が保てる	属性更新の遅延、複雑なルールは設計が難しい	部門単位で一律に除外したい場合
場所(IPアドレス範囲)の指定	信頼できるオフィスネットワークからのアクセスを条件付きアクセスの対象外にする	ユーザーごとの調整が不要、ネットワーク単位で制御できる	リモートワークでは効果が薄い、IPアドレスが変わる可能性	オフィス勤務が主体の組織
リスクベースの条件付きアクセス	Entra ID Identity Protectionで検出したユーザーリスクやサインインリスクに基づいてアクセスを制御	リスクが低い場合にのみ制限を緩和できる、セキュリティと利便性のバランスが良い	Identity Protectionライセンス(P2)が必要、設定が複雑	高度なセキュリティ要件がある組織
ポリシーの分割(アプリ単位など)	すべてのアプリを対象にするポリシーではなく、特定アプリだけに適用するポリシーに分割	ポリシーごとに除外対象を限定できる、影響範囲が明確	ポリシー数が増える、管理が煩雑になる可能性	特定アプリだけ例外動作が必要な場合

6. よくある失敗パターンと対策

棚卸し作業で陥りがちな失敗とその対策を紹介します。

失敗1:いきなり除外を全解除してしまう

不要な除外を一掃したい気持ちから、すべての個別ユーザー除外を解除してしまうと、重要な業務アプリケーションにアクセスできないユーザーが発生し、混乱を招きます。必ずレポートモードで事前確認し、影響範囲を把握した上で段階的に解除する必要があります。

失敗2:除外理由を記録しないまま整理する

棚卸しの結果、一部の除外を残す判断をしたとき、その理由を文書化しないと、次回の棚卸しで同じ問題が繰り返されます。変更管理チケットやWikiに理由・承認者・有効期限を記録する習慣をつけてください。

失敗3:権限が不足したまま作業を試みる

条件付きアクセスの変更には「条件付きアクセス管理者」または「グローバル管理者」ロールが必要です。一般ユーザーやヘルプデスク権限では変更できないため、適切な権限を持つアカウントを事前に準備してください。権限がないまま作業しようとすると、変更が反映されず混乱の元になります。

7. よくある質問(FAQ)

• Q. 除外ユーザーが100人を超えていますが、一括で整理する方法はありますか?
  A. PowerShellを使用してポリシーをエクスポートし、CSVで一覧化してから、グループ化や代替手段への置き換えを計画的に進めるのが効率的です。ただし、影響が大きいため、必ずテスト環境で検証してから本番に適用してください。
• Q. 除外ユーザーを減らした後、どうやって元に戻らないようにするのですか?
  A. ポリシー変更の申請フローを整備し、除外を追加する際には必ず理由と有効期限を記録するルールを徹底します。また、定期的なレビューを自動化するために、Microsoft SentinelやAzure Automationを活用することも検討できます。
• Q. 管理コンソールで除外ユーザーを確認すると、古いユーザーが多数残っています。退職済みのアカウントは削除しても問題ありませんか?
  A. 退職済みでアカウントが既に無効化されている場合は、除外リストから削除しても問題ありません。ただし、アカウントが削除されていない場合は、再度有効化されたときに除外が解除されているとアクセス制限がかかる可能性があるため、事前にアカウントの状態を確認してください。
• Q. 除外グループの動的メンバーシップのルールがうまく設定できません。アドバイスはありますか?
  A. 動的グループのルールは、ユーザーの属性に依存します。属性値が正しく設定されていないと期待通りに動作しません。まずはEntra IDのユーザープロファイル(部署、役職など)が最新かどうかを確認し、必要に応じて属性を修正してからルールをテストすることをお勧めします。

8. まとめ

条件付きアクセスにおける除外ユーザーの増加は、セキュリティ低下と管理負荷増大の両方を引き起こします。棚卸しの第一歩は、現状の除外ユーザーを可視化し、その必要性を一つ一つ検証することです。可能な限り個別ユーザー除外をグループ化や他の条件に置き換え、代替手段を活用することで、管理しやすい状態を維持できます。最後に、定期的なレビューサイクルを導入して、再発を防止する仕組みを組織に根付かせてください。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。