前の章では、Microsoft Entra IDがユーザーを認証し、
MFAを使って本人確認を強化できることを説明しました。
しかし実際の会社では、
すべてのアクセスを同じ条件で許可するとは限りません。
たとえば、
- 社外からアクセスした場合はMFAを要求する
- 会社の基準を満たしたPCだけアクセスを許可する
- 特定の国や地域からのアクセスを拒否する
- 管理者にはより強い認証を要求する
といった制御が必要になることがあります。
このように、
アクセスしてきたユーザーやデバイスなどの状況を確認し、
条件に応じてアクセス方法を変える仕組みが
Microsoft Entra IDの条件付きアクセス（Conditional Access）です。
- 条件付きアクセスとは？
- 条件付きアクセスの基本は「IF → THEN」
- 条件付きアクセスは何を見ている？
- ① 誰がアクセスしているのか
- ② どのサービスへアクセスするのか
- ③ どこからアクセスしているのか
- ④ どのデバイスからアクセスしているのか
- 「準拠デバイス」は条件そのものではなくアクセス要件
- ⑤ リスクも判断材料にできる
- 条件を満たしたら何をする？
- 具体例① 社外からアクセスしたらMFA
- 具体例② 安全な会社PCだけアクセスを許可する
- 複数の条件付きアクセスポリシーが適用される場合
- 条件付きアクセスとMFAの関係
- 条件付きアクセスとIntuneの関係
- 条件付きアクセスにはライセンスが必要
- いきなり「オン」にしない
- レポート専用とは？
- 緊急アクセス用アカウントも考える
- 条件付きアクセスの管理画面
- この章で覚えること
- ここまでの関係を整理
条件付きアクセスとは？
条件付きアクセスを簡単に表すと、
「もし○○なら、△△を要求する」
という仕組みです。
たとえば、
もし社外からMicrosoft 365へアクセスしたら
↓
MFAを要求する
というポリシーを作成できます。
別の例では、
もし会社の基準を満たしていないデバイスなら
↓
Microsoft 365へのアクセスを許可しない
といった制御も可能です。
条件付きアクセスは、
単純にユーザー名とパスワードだけを見るのではなく、
アクセス時のさまざまな情報を使ってアクセス可否を判断する
仕組みです。
条件付きアクセスの基本は「IF → THEN」
条件付きアクセスは、
プログラムのIF文のように考えると分かりやすくなります。
| 考え方 | 条件付きアクセス |
|---|---|
| IF | どのようなアクセスなのか |
| THEN | 何を要求するのか |
たとえば、
IF：社外ネットワークからアクセス
THEN：MFAを要求
という形です。
もうひとつ例を挙げると、
IF：管理者が管理サービスへアクセス
THEN：強い認証を要求
といったポリシーも考えられます。
条件付きアクセスは何を見ている？
条件付きアクセスでは、
サインイン時のさまざまな情報を判断材料として利用できます。
代表的なものは次のとおりです。
| 判断材料 | 確認する内容 |
|---|---|
| ユーザー・グループ | 誰がアクセスしているのか |
| 対象リソース | どのアプリやサービスへアクセスするのか |
| ネットワーク・場所 | どこからアクセスしているのか |
| デバイスプラットフォーム | Windows、iOS、Android、macOSなど |
| クライアントアプリ | どの種類のクライアントからアクセスしているのか |
| サインインリスク | そのサインインが危険である可能性 |
| ユーザーリスク | そのユーザーアカウントが侵害されている可能性 |
つまり条件付きアクセスは、
「誰が」「何に」「どこから」「どの端末などを使って」
アクセスしているのかを確認しながら判断できます。
① 誰がアクセスしているのか
条件付きアクセスでは、
対象となるユーザーやグループを指定できます。
たとえば、
- すべてのユーザー
- 特定の部署
- 管理者
- 特定のグループ
などを対象にできます。
そのため、
一般ユーザーと管理者で異なるアクセスルールを設定する
ことも可能です。
② どのサービスへアクセスするのか
条件付きアクセスでは、
どのサービスやリソースへのアクセスを対象にするのかを指定します。
たとえば、
- Microsoft 365
- Azure管理サービス
- 特定のクラウドアプリ
などです。
つまり、
すべてのサービスへ同じルールを適用する必要はありません。
③ どこからアクセスしているのか
アクセス元のネットワーク情報も判断材料にできます。
たとえば会社に固定グローバルIPアドレスがある場合、
そのIPアドレスをネットワーク・場所として定義できます。
そのうえで、
会社ネットワーク
→ 通常のアクセス
会社ネットワーク以外
→ MFAを要求
といった設計も可能です。
ただし、
「社内ネットワークだから必ず安全」とは限りません。
場所だけに依存してセキュリティを下げるのではなく、
ユーザー、認証、デバイスなど複数の情報を組み合わせて判断することが重要です。
④ どのデバイスからアクセスしているのか
条件付きアクセスでは、
デバイスに関する情報もアクセス判断に利用できます。
たとえば、
- Windows
- macOS
- iOS
- Android
- Linux
など、デバイスのプラットフォームによって
ポリシーを分けることができます。
さらにIntuneと組み合わせれば、
会社のセキュリティ基準を満たしたデバイスだけアクセスを許可する
といった制御につなげることができます。
「準拠デバイス」は条件そのものではなくアクセス要件
ここは少し分かりにくいポイントです。
条件付きアクセスでは、
Intuneによって
「準拠としてマークされているデバイスを要求する」
ことができます。
たとえば、
ユーザーがMicrosoft 365へアクセス
↓
条件付きアクセスを評価
↓
準拠デバイスであることを要求
↓
Intuneの準拠状態を確認
↓
条件を満たしていればアクセス
という流れです。
「デバイスが準拠しているか」は、
条件付きアクセスの結果として要求する
アクセス制御（Grant Control）のひとつとして考えると整理しやすくなります。
⑤ リスクも判断材料にできる
Microsoft Entra IDでは、
サインインやユーザーに関するリスク情報を
条件付きアクセスの判断材料として利用できる構成があります。
たとえば、
通常とは異なる不審なサインインが検出された場合に、
リスクの高いサインイン
↓
MFAを要求
といった制御ができます。
ただし、
リスクベースの条件付きアクセスにはMicrosoft Entra ID P2の機能が関係します。
最初の学習段階では、
「条件付きアクセスは場所やデバイスだけでなく、
リスク情報も利用できる」
と覚えておけば十分です。
条件を満たしたら何をする？
条件付きアクセスでは、
条件を確認したあとに
どのようなアクセス制御を行うかを設定します。
代表的なものは次のようなものです。
| アクセス制御 | 意味 |
|---|---|
| アクセスをブロック | アクセスさせない |
| MFAを要求 | 追加の本人確認を要求する |
| 認証強度を要求 | 指定した強度の認証方法を要求する |
| 準拠デバイスを要求 | Intuneなどで準拠と判定されたデバイスを要求する |
| Microsoft Entra hybrid joinedデバイスを要求 | Hybrid Joinされたデバイスを要求する |
条件付きアクセスは、
単に「許可する・拒否する」だけではありません。
「追加の条件を満たせばアクセスを許可する」
という使い方ができることが重要です。
具体例① 社外からアクセスしたらMFA
条件付きアクセスを理解するため、
具体的な例を見てみましょう。
会社では通常、
固定されたグローバルIPアドレスを使用しているとします。
次のようなポリシーを考えられます。
| 項目 | 設定例 |
|---|---|
| 対象ユーザー | 社員 |
| 対象リソース | Microsoft 365 |
| ネットワーク | 会社ネットワーク以外 |
| アクセス制御 | MFAを要求 |
この場合、
社員
＋
Microsoft 365
＋
会社ネットワーク以外
↓
MFAを要求
という判断になります。
具体例② 安全な会社PCだけアクセスを許可する
Intuneを利用している場合には、
さらにデバイスの状態を利用できます。
たとえば、
| 項目 | 設定例 |
|---|---|
| 対象ユーザー | 社員 |
| 対象リソース | Microsoft 365 |
| アクセス制御 | 準拠デバイスを要求 |
とすると、
Intuneで会社のセキュリティ基準を満たしていると判定されたデバイスを
アクセスの要件にできます。
これによって、
ユーザーが正しい
＋
デバイスも会社の基準を満たしている
↓
アクセスを許可
という考え方ができます。
複数の条件付きアクセスポリシーが適用される場合
条件付きアクセスでは、
ひとりのユーザーに複数のポリシーが適用されることがあります。
たとえば、
- ポリシーA：MFAを要求
- ポリシーB：準拠デバイスを要求
の両方が対象になっている場合、
基本的には
適用されるポリシーすべての要件を満たす必要があります。
つまり、
MFA
＋
準拠デバイス
↓
アクセス
という状態になります。
「後から作ったポリシーで前のポリシーを上書きする」
という単純な仕組みではないので注意してください。
条件付きアクセスとMFAの関係
前の章で説明したMFAと、
条件付きアクセスは役割が異なります。
| MFA | 条件付きアクセス | |
|---|---|---|
| 役割 | 本人確認を強化する | いつ何を要求するか判断する |
| 例 | Authenticatorで追加認証 | 社外アクセス時にMFAを要求 |
簡単に言えば、
MFA ＝ 本人確認の方法
条件付きアクセス ＝ MFAなどを要求する判断ルール
です。
条件付きアクセスとIntuneの関係
条件付きアクセスとIntuneも、
それぞれ役割が異なります。
| サービス | 役割 |
|---|---|
| Microsoft Entra ID | ユーザーやデバイスを識別・認証する |
| Microsoft Intune | デバイスを管理し、準拠状態などを判定する |
| 条件付きアクセス | それらの情報を使ってアクセス方法を判断する |
イメージすると、
ユーザー
↓
Entra IDで認証
↓
Intuneのデバイス状態などを確認
↓
条件付きアクセスで判断
↓
Microsoft 365
という流れです。
この関係については、
第7章でさらに詳しく説明します。
条件付きアクセスにはライセンスが必要
条件付きアクセスを利用するには、
基本的にMicrosoft Entra ID P1以上のライセンスが必要です。
Microsoft 365 Business Premiumには、
条件付きアクセスを利用できるMicrosoft Entra ID P1の機能が含まれています。
一方、
ユーザーリスクやサインインリスクを利用した
リスクベースの条件付きアクセスでは、
Microsoft Entra ID P2の機能が必要になります。
いきなり「オン」にしない
条件付きアクセスは非常に強力な機能です。
設定を間違えると、
一般ユーザーだけでなく
管理者自身がMicrosoft 365やEntra管理センターへサインインできなくなる
可能性があります。
そのため実務では、
いきなり本番ユーザー全体へポリシーを適用するのではなく、
段階的に確認することが重要です。
基本的には、
ポリシーを作成
↓
対象・除外を確認
↓
レポート専用で確認
↓
サインインログを確認
↓
テストユーザーで確認
↓
問題がなければオン
という流れで展開します。
レポート専用とは？
条件付きアクセスポリシーには、
レポート専用（Report-only）
という状態があります。
レポート専用では、
ポリシーを実際に強制せずに、
「このポリシーを有効にした場合、どのサインインが対象になるのか」
を確認できます。
たとえば、
「社外アクセス時にMFAを要求する」
というポリシーをレポート専用にしても、
実際にそのポリシーによってMFAが要求されるわけではありません。
まず影響範囲を確認し、
問題がないことを確認してからオンにするための機能と考えると分かりやすいでしょう。
緊急アクセス用アカウントも考える
条件付きアクセスを本格的に運用する場合は、
管理者が誤ったポリシーによって
完全にサインインできなくなる事態にも備える必要があります。
そのため、
通常の管理者アカウントとは別に
緊急アクセス用アカウントを用意する考え方があります。
緊急アクセス用アカウントは、
条件付きアクセスの設定ミスや障害などによって
通常の管理者がサインインできない場合に利用するためのアカウントです。
本番環境で条件付きアクセスを設計するときには、
単にポリシーを作るだけではなく、
「設定を間違えたときにどう戻すか」
まで考える必要があります。
条件付きアクセスの管理画面
条件付きアクセスは、
Microsoft Entra管理センターから設定できます。
代表的には、
Microsoft Entra管理センター
↓
Microsoft Entra ID
↓
条件付きアクセス
↓
ポリシー
から作成・管理します。
ただし、この入門では
設定画面の操作方法よりも、
「誰に・何へのアクセスで・どの条件を確認し・何を要求するのか」
という考え方を理解することを優先します。
この章で覚えること
- 条件付きアクセスはアクセス時の状況に応じて制御を変える仕組み
- 基本は「IF：条件 → THEN：アクセス制御」で考える
- ユーザー、対象リソース、ネットワーク、デバイス、リスクなどを判断材料にできる
- MFAを要求したり、アクセスをブロックしたりできる
- Intuneと組み合わせて準拠デバイスを要求できる
- MFAは本人確認の方法、条件付きアクセスはそれをいつ要求するか判断する仕組み
- 複数のポリシーが適用される場合は、適用された要件をすべて満たす必要がある
- 条件付きアクセスには基本的にMicrosoft Entra ID P1以上が必要
- リスクベースの条件付きアクセスにはP2の機能が必要
- 本番適用前にレポート専用で影響を確認する
ここまでの関係を整理
ここまで学習した内容をつなげると、
Entra IDのアクセス管理の流れが見えてきます。
ユーザー
↓
Entra IDで認証
↓
必要ならMFA
↓
ユーザー・場所・デバイスなどを確認
↓
条件付きアクセスで判断
↓
Microsoft 365へアクセス
さらにIntuneを組み合わせることで、
デバイスが会社のセキュリティ基準を満たしているかという情報も
アクセス判断に利用できます。
次の第7章では、
Microsoft Entra IDとIntuneがどのように役割分担し、
条件付きアクセスと連携するのか
を整理します。