Skip to content

MS_AzureConditionalAccess

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 2 revisions

Azure Active Directory 条件付きアクセス

概要

AzADP1, AzADP2 で利用可能。

シグナル（状況）を評価して、ポリシー（許可／MFA 要求／ブロック）を適用する。

補足: Microsoft Entra ID P1 以上が必要という意味。
無償版では利用できない。
なお、機能の一部（サインイン リスク / ユーザー リスクによる制御 ＝
Identity Protection）は P2 が必要である。

補足（何を判断する仕組みか）: 条件付きアクセスは、
「認証が成功したか」ではなく
「この状況で通してよいか」を判断する仕組みである。
LoA(Level of Assurance) の
「要求されるレベルに応じて認証を強める」という考え方の実装と言える。

ゼロ トラストの文脈では、
すべてのアクセスを明示的に検証するための中核機能に位置付けられる。

補足（位置づけ）: 条件付きアクセスは、
FgCF が言う
「トラストのベースは主体（ID）の信頼性（正当性）」を
実際に実装する機構にあたる。

【シグナル】            【評価】              【制御】
 誰が（ユーザ）      ┐
 何に（アプリ）      │
 どこから（IP/場所） ├─▶ ポリシー ─▶ 許可（MFA / 準拠デバイス）
 何で（デバイス）    │                または ブロック
 リスク（異常検知）  ┘

「ネットワーク経路は一要素でしかない」という主張が、
そのまま「場所は条件の 1 つに過ぎない」という設計に反映されている。

詳細

シグナル

ユーザまたはグループ メンバーシップ

...

IP の場所に関する情報

ネームド・ロケーション

補足: **名前付きの場所（Named locations）**として
IP レンジや国・地域を登録し、
「信頼できる場所」としてマークできる。
具体的な構成手順は
AzADによる条件付きアクセス機能を構成する。 を参照。

Device、Application

セキュア・ワークステーション

補足: デバイス条件では、

  • 準拠しているデバイス（Intune の準拠ポリシーを満たす）
  • ハイブリッド Azure AD 参加済みデバイス
  • デバイスのプラットフォーム（Windows / iOS / Android …）

を条件にできる。
FgCF の「デバイス保護」「特権アクセス端末（PAW）」を
強制する手段がこれにあたる。

リスクベース認証

...

補足: Microsoft Entra ID Protection（P2）が算出する
次の 2 種のリスクを条件にできる。

リスク 内容
サインイン リスク そのサインインが本人でない可能性（不審な IP、匿名 IP、異常な移動）
ユーザー リスク その ID 自体が侵害されている可能性（資格情報の漏洩など）

「サインイン リスクが中以上なら MFA を要求」
「ユーザー リスクが高ならパスワード変更を要求」
といったポリシーが組める。
FgCF が「絵に描いた餅」と評した
動的認可ポリシーエンジンは、現在ここまで実装されている。

Microsoft Cloud App Security (MCAS)

...

補足（最新化）: MCAS は Microsoft Defender for Cloud Apps に改称。
条件付きアクセスと連携すると
セッション制御（アプリ内の操作をリアルタイムに制限）が可能になり、
「閲覧はできるがダウンロードはできない」
「印刷を禁止する」といった制御ができる。
OA-LANとAzureのVNETの分離 が扱う
「持ち出し防止」を、ネットワーク分離ではなく ID 側で実現する手段。

ポリシー

許可

許可する。

多要素認証（MFA）

MFA を要求する。

  • OATH トークン

    • ハードウェア・トークン
    • ソフトウェア・トークン
      Microsoft Authenticator スマホ・アプリ

  • 携帯電話、スマホ

    • SMS
    • 音声通話

補足（最新化 / 強度の違い）: 現在、SMS と音声通話は非推奨である
（SIM スワップ、SS7 の脆弱性、フィッシングへの耐性が低いため）。
推奨される順序は次のとおり。

方式 フィッシング耐性 備考
FIDO2 / パスキー、証明書ベース認証 あり 最も強い。特権アカウントに推奨
Windows Hello for Business あり デバイスに紐づく
Microsoft Authenticator（番号の一致） 中 MFA 疲労攻撃への対策として番号一致が既定に
OATH トークン（TOTP） 低 中間者に中継され得る
SMS / 音声通話 低 非推奨

また、**認証強度（Authentication Strengths）**という機能により、
「この操作にはフィッシング耐性のある方式のみ許可」といった
指定ができるようになっている。

SMS / 音声通話は、SIM スワップや SS7 の脆弱性で傍受されうるため、
NIST SP 800-63B でも「制限付き」の扱いになっている。
また、承認を連打させる MFA 疲労攻撃への対策として、
Microsoft Authenticator の**番号一致（Number Matching）**が
既定で有効化されている。
ワンタイム・パスワード の補足のとおり、
MFA を入れてもフィッシング耐性は得られないため、
重要な系では FIDO 系への移行を検討すること。

ブロック

ブロックする。

補足（運用上の必須事項）: ポリシーを作る際は必ず、

  • 緊急事態用アカウント（break glass）を除外する
    除外し忘れると設定ミスで全員が締め出される。
    条件付きアクセスの対象外にした管理者アカウントを 2 つ用意し、
    長く強力なパスワードで保護してオフライン保管する。
    詳細は AzADのテナント作成方法、
    Azure Subscriptionの管理@エンプラ を参照。
  • 「レポート専用」モードで影響を先に確認する。
  • 「What If」ツールで特定ユーザ・条件の評価結果を検証する。

なお、条件付きアクセスはトークン発行時に評価されるため、
発行済みトークンの有効期間中は条件の変化が反映されない。
これを補うのが 継続的アクセス評価 (CAE) で、
IP の変化やアカウント無効化をほぼ即時に反映できる。

なお、複数のポリシーは AND で合成され、
ブロックが常に優先される点も押さえておくこと。

参考

本 Wiki 内

Microsoft Learn

AzADによる条件付きアクセス機能を構成する。

移行メモ（重複ページの統合）: 本ページは、同一の元ページが
MS_AzureADConditionalAccess と MS_AzureConditionalAccess の
2 つのファイル名で二重に移行されていたものを統合した結果である。
Azure AD が Microsoft Entra ID へ改称されたことを踏まえ、
製品名を含まない MS_AzureConditionalAccess を残し、
MS_AzureADConditionalAccess 側の固有記述
（LoA / ゼロ トラストとの関係、NIST SP 800-63B、MFA 疲労攻撃、
break-glass アカウントの運用、ポリシーの合成規則）を取り込んだうえで
当該ファイルを削除し、参照元のリンクを本ページへ張り替えた。

Tags: 移行, セキュリティ, アカウント, クラウド, 認証基盤, Azure, Active Directory

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally