Instiq
第1章 · ID とアクセスの管理·v2.0.0·更新 2026/6/28·読了目安 約9分

変更要約: AZ-500 第1章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）

1.2多要素認証と条件付きアクセス

この節の要点

パスワードだけに頼らない 多要素認証（MFA） と、サインインの状況（ユーザー・場所・デバイス・リスク）に応じてアクセスを制御する 条件付きアクセス を理解します。ゼロトラストの中核となる仕組みです。

パスワードは漏洩しやすいため、追加の本人確認である MFA と、状況に応じて許可/ブロック/追加認証を判断する 条件付きアクセス でアクセスを守ります。

1.2.1条件付きアクセスの考え方

サインイン試行が条件付きアクセスのポリシーに入り、シグナル（ユーザー/グループ・場所・デバイス・アプリ・サインインリスク）を評価して、許可（MFA 要求や準拠デバイス必須などの制御付き）またはブロックを決定する流れを示し、MFA は追加の本人確認である旨を添えた図。
条件付きアクセスの評価フロー
  • MFA：パスワード（知識）に加え、アプリ通知・ワンタイムコード・生体など別要素で本人確認する。
  • 条件付きアクセス：「もし（条件）〜ならば（制御）」の if-then ポリシーでアクセスを判断する。
  • シグナル：ユーザー/グループ・場所（IP）・デバイスの準拠状態・アプリ・サインインリスクなどを評価する。
  • 制御：アクセスを許可/ブロック、または MFA 要求・準拠デバイス必須などの条件付きで許可する。
試験ポイント

「状況に応じてアクセスを制御＝条件付きアクセス」「追加の本人確認＝MFA」「リスクの高いサインインに自動で MFA/ブロック＝条件付きアクセス＋Identity Protection」 は AZ-500 で頻出です。条件付きアクセスは Entra ID P1 以上が必要です。

ゼロトラストの中核が MFA と 条件付きアクセス です。MFA はパスワード（知識）に加え、Authenticator の承認/TOTP・FIDO2 セキュリティキー・Windows Hello・SMS/電話（フィッシング耐性は FIDO2/パスキー＞アプリ＞SMS）など別要素で本人確認します。条件付きアクセス は if（条件＝シグナル）→ then（制御） のポリシーで、シグナルは ユーザー/グループ・場所（名前付き場所/国）・デバイス準拠（Intune）・クライアントアプリ・サインインリスク/ユーザーリスク、制御は 許可/ブロック・MFA 要求・準拠デバイス必須・アプリ保護ポリシー・セッション制御（サインイン頻度等）。リスクベースは Identity Protection（P2）と連携し、漏洩資格情報や不可能な移動を検知して自動で MFA/ブロック。導入は レポート専用モード で影響を確認してから有効化、緊急アクセス用の ブレークグラスアカウント は除外します。P1 で条件付きアクセス、P2 でリスクベース/PIM が使えます。判断軸は「状況でアクセス制御＝条件付きアクセス」「追加の本人確認＝MFA」「リスクで自動対応＝Identity Protection」。

要件手段
状況に応じてアクセス制御条件付きアクセス（if-then）
追加の本人確認MFA（FIDO2/アプリ＞SMS）
リスクの高いサインインに自動対応Identity Protection（P2）＋条件付きアクセス
本番投入前に影響確認レポート専用モード
例

シナリオ：通常は快適に、リスク時だけ強く守りたい。 条件付きアクセスで「信頼できる場所/準拠デバイスなら MFA を省く」「サインインリスクが高い/未知の場所なら MFA 要求 or ブロック」を設定（リスク判定は Identity Protection）。FIDO2/Authenticator を優先し SMS は限定。まず レポート専用で影響を確認してから有効化し、締め出し防止に ブレークグラスアカウントを除外します。

補足

Q. 状況でアクセス制御？ 条件付きアクセス。Q. 追加の本人確認？ MFA（FIDO2/アプリが SMS より安全）。Q. リスクで自動 MFA/ブロック？ Identity Protection（P2）＋条件付きアクセス。Q. 本番前の確認？ レポート専用モード。Q. 締め出し防止？ ブレークグラスを除外。Q. CA に必要なライセンス？ P1 以上。

注意

混同に注意：
①条件付きアクセスは P1 以上、リスクベース/PIM/Identity Protection は P2——無料テナントでは不可。
②全ユーザーをブロックする CA を作ると自分も締め出される——ブレークグラスを必ず除外＋レポート専用で検証。
③MFA の SMS はフィッシング/SIM スワップに弱い——FIDO2/パスキー推奨。
④条件付きアクセスはサインインの認可制御で、Azure リソースの RBAC とは別。

コツ

「すべてのユーザーに MFA を要求」だけでなく、「信頼できる場所からは MFA を省く」など、条件を組み合わせて利便性とセキュリティのバランスを取れます。

1.2.2この節のまとめ

  • MFA＝別要素での本人確認（漏洩パスワード対策）
  • 条件付きアクセス＝if-then でアクセス制御（シグナル→制御）

進捗の記録にはログインが必要です。

理解度チェック

（軽い確認用）

Q1. パスワードに加えてスマホアプリの承認やワンタイムコードで本人確認を強化する仕組みはどれですか？

Q2. サインインの場所・デバイス・リスクに応じてアクセスを許可/ブロック/MFA 要求と判断したい。何を使いますか？

Q3. 条件付きアクセスで評価される「シグナル」に該当しないものはどれですか？

理解度を確認第1章「ID とアクセスの管理」の問題を解く