-
Notifications
You must be signed in to change notification settings - Fork 0
MS_AzureADConditionalAccess
nishi_74322014 edited this page Aug 4, 2026
·
1 revision
- 戻る(Microsoft Azure Active Directory、Azureのアクセス制御と権限)
- Azure Active Directory 条件付きアクセス
- Azure Active Directory Identity Protection
- Role Based Access Control (RBAC)
AzAD P1, AzAD P2 で利用可能。
シグナル(状況)を評価して、ポリシー(許可/MFA 要求/ブロック)を適用する。
補足: 条件付きアクセスは、 「認証が成功したか」ではなく「この状況で通してよいか」を判断する仕組みである。 LoA(Level of Assurance) の 「要求されるレベルに応じて認証を強める」という考え方の実装と言える。
ゼロ トラストの文脈では、 すべてのアクセスを明示的に検証するための中核機能に位置付けられる。
| シグナル | 内容 |
|---|---|
| ユーザまたはグループ メンバーシップ | 対象/除外の指定 |
| IP の場所に関する情報 | ネームド・ロケーション(社内 IP、国など) |
| Device、Application | セキュア・ワークステーション、対象アプリ |
| リスクベース認証 | Identity Protection のリスク評価 |
| Microsoft Cloud App Security (MCAS) | セッション制御 |
| ポリシー | 内容 |
|---|---|
| 許可 | 許可する |
| 多要素認証(MFA) | MFA を要求する |
| ブロック | ブロックする |
MFA の手段
- OATH トークン
- ハードウェア・トークン
- ソフトウェア・トークン(Microsoft Authenticator スマホ・アプリ)
- 携帯電話、スマホ
- SMS
- 音声通話
補足(最新化): MFA の手段には強度の差がある。 現在は次の順で推奨される。
強度 手段 高(フィッシング耐性あり) FIDO2 セキュリティ キー、Windows Hello for Business、証明書ベース認証 中 Microsoft Authenticator(番号一致)、TOTP 低 SMS、音声通話 SMS と音声通話は非推奨である。SIM スワップや SS7 の脆弱性で傍受されうるため、NIST SP 800-63B でも 「制限付き」の扱いになっている。
また、承認を連打させる MFA 疲労攻撃への対策として、 Microsoft Authenticator の番号一致(Number Matching) が 既定で有効化されている。 ワンタイム・パスワード の補足のとおり、 MFA を入れてもフィッシング耐性は得られないため、 重要な系では FIDO 系への移行を検討すること。
補足(運用上の注意): 条件付きアクセスで最も多い事故は 自分を締め出す(lockout) ことである。
- 緊急アクセス用アカウント(break-glass)を必ず除外する
条件付きアクセスの対象外にした管理者アカウントを 2 つ用意し、 長く強力なパスワードで保護してオフライン保管する。- 新しいポリシーは必ずレポート専用モードで影響を確認してから有効化する。
- 「What If」ツールで、特定ユーザ・アプリでの評価結果を事前確認する。
なお、複数のポリシーは AND で合成され、 ブロックが常に優先される点も押さえておくこと。
- Microsoft Azure Active Directory
- Azure Active Directory Identity Protection
- Role Based Access Control (RBAC)
- LoA(Level of Assurance)
- ワンタイム・パスワード
- FIDO
- Microsoft Entra 条件付きアクセス - Microsoft Learn
Tags: セキュリティ, アカウント, クラウド, 認証基盤, Azure, Active Directory
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。