どうも、株式会社ソフトクリエイト で情報屋やってます。山口です。
普段は企業様向けに Microsoft 365 活用のご支援をおこなっています。
問 : 全員にMFA設定していれば、クラウドID(Entra ID)保護は"万全"なの？
解 : はい(^^。ただし、MFAアプリ(Authenticator アプリ)を利用する必要があり、この状態なら、今時点で、できることの最高到達点に近いと言えます。
最近では、フィッシングや情報漏えい事件が増加し、「パスワードだけでは組織を守れない」という認識が定着してきており、現在では多要素認証（MFA）がセキュリティ対策の重要な柱として位置付けられています。(^^
これは、ユーザーIDやパスワードの漏洩、パスワードスプレー攻撃により、パスワード認証が成立したとしても、MFA(アプリ)にて、悪意のあるユーザー側での認証を完了させることが難しくなるためで、これを「全員に強制」することで、クラウドIDの入口対策としては「今できることはしっかりやれている状態(最高到達点に近い)」と言えます。
全員にMFA設定していれば、クラウドID(Entra ID)保護は"万全"なの？
■ MFAに強度がある?!
「MFAやってます」「MFA全員に適用しています」と言ってもいろんなレベルがあります。
| 状態 | 実効性 |
|---|---|
| 希望者のみMFA設定可能 | △ 設定してない人が狙われる |
| 全員MFA必須（方式は自由） | ○ ただしSMS認証はやや弱い |
| 全員MFA必須（Authenticator のみ） | ◎ かなり強固 |
| レガシー認証も無効化済み | ◎◎ 入口対策としてはほぼ完璧 |
「MFA全員強制」というのは、全ユーザーに Authenticator アプリでの認証を必須にしている状態を指し、「レガシー認証（基本認証）は無効化」「管理者アカウントは、必ずMFA対象化」等々の条件を満たす必要があります。
また、MFAで、SMSや電話認証を利用している場合があると思いますが、MFAと一口に言っても、実は強度に差があり、同じではありません。
| 認証方式 | 強度 | リスク |
|---|---|---|
| SMS・電話認証 | △ | SIMスワップ・盗聴・誤承認のリスク |
| Authenticator（プッシュ通知のみ） | ○ | MFA疲労攻撃で誤タップされる可能性 |
| Authenticator（数値一致） | ◎ | 画面に表示された数字を入力する必要あり |
Microsoft Authenticator の数値一致（Number Matching）機能は、「サインイン画面に表示された2桁の数字」を「スマホのAuthenticatorアプリに入力する」という仕組みです。これは、「MFA疲労攻撃」（何度もプッシュ通知を送りつけて、ユーザーが疲れて承認ボタンを押してしまうやつ）への耐性が高いという効果があります。
加えて、「地図表示（どこからのサインインか）」「アプリ名表示（何にサインインしようとしているか）」これらも表示されるので、「あれ？自分じゃないぞ？」と気づきやすい設計になっています。
なんとなく、MFAを運用しているのではなく、実効性のあるMFAを全員で利用していることが重要です。
■ Entra ID P2 にて提供される"ID Protection"とは?
さて、次なる話は、Entra ID P2 にて提供される"ID Protection"についてです。
まず、Microsoft Entra ID P2 に含まれる ID Protection は、サインインやユーザーの振る舞いを分析し、資格情報漏えいや不審なサインインを自動検知する機能です。
検知したリスクを条件付きアクセスと連携させることで、MFA 要求やパスワード変更を強制し、侵害の拡大や見逃しを防ぐ仕組みを提供します。
この、ID Protection のフル機能を使うには、ライセンスが必要で、以下のようなライセンスの契約が必要になります。
- Microsoft Entra ID P2
- Microsoft 365 E5
- Microsoft 365 E5 Security
- Defender Suite for Business Premium
- Defender & Purview Suite for Business Premium
- Enterprise Mobility + Security E5
なお、Entra ID P1（旧 Premium P1）でも、リスクレポートを「見る」ことはできます。ただし、条件付きアクセスと連動した自動保護（MFA強制やパスワード変更強制など）は使えない点については、注意が必要です。
MFAがカバーしているのは、あくまで認証時点での事前防御で入り口対策になり、「正しいユーザーか？」「本人確認できるか？」これを認証の瞬間にチェックしています。
対して、Entra ID P2 の"ID Protection"は、「すり抜け」と「その後」の防御の役割を持ちます。
| シナリオ | MFAで防げる？ | ID Protection で検知できる？ |
|---|---|---|
| MFA設定漏れのユーザーがいた | ❌ そもそもMFAかかってない | ✅ リスクとして検知可能 |
| 一時的な例外追加（VIP対応など） | ❌ 例外は素通り | ✅ リスク検知でカバー |
| トークン盗難（AiTM攻撃） | ❌ MFA後のトークンを奪われる | ✅ ユーザーリスクとして検知 |
| 侵害済み端末からのアクセス | ❌ MFAは通過する | ✅ デバイスリスクと連携可能 |
| Impossible Travel（ありえない移動） | ❌ 認証自体は成功 | ✅ サインインリスクで検知 |
最新のサイバーセキュリティ攻撃には、「トークン盗難（AiTM攻撃）」と呼ばれる、攻撃者がユーザーと正規サービスの間に割り込み、やり取りされる認証情報やセッション（通信）を盗み取る中間者攻撃が、存在しています。このタイプの攻撃では、通信自体は最終的に正規サイトに届くため、ユーザーには「正しくログインできている」ように見えてしまう点が特徴です。
その結果、パスワードやワンタイムコードだけでなく、MFA通過後のセッショントークンまでもが窃取されることで、不正アクセスにつながってしまいます。
このMFAでの事前防御で防げなかった、「想定外」を拾う役割を ID Protection は担っているわけです。
MFAが「玄関の鍵」だとすると、ID Protection は「監視カメラ＋異常検知システム」みたいなイメージですね (^^
この「想定外」を拾う役割を実現するためには、Entra ID P2 の"ID Protection"には、「管理ユーザーの通知・レポート」「ユーザーリスクポリシー」「サインインリスクポリシー」等の機能が実装されており、制限および制御の役割を「Entra ID の条件付きアクセス」で実現します。
①ID Protection 「管理ユーザーの通知・レポート」
この機能は、「怪しいこと起きてるよ」を管理者に即知らせるための設定で、パスワードスプレー、異常サインイン、漏えい資格情報などを検知したときに通知したり、週間レポートを管理者宛に送信します。
次に、ID Protection には、ユーザー リスクポリシーとサインイン リスク ポリシーの2つの種類の設定可能なリスク ポリシーがあります。これらのポリシーを使用すると、それぞれのリスクを検出することができるようになります。ただ、リスクシグナルを送るだけでは、対策にはなりませんので、Microsoft Entra の条件付きアクセスを利用して、それぞれのリスクシグナルへの自動対処を組み込み、セーフティーネットを引く必要があります。
②サインインリスクポリシー × 条件付きアクセス
「このサインイン、今まさに怪しい」 という視点で、パスワードスプレー攻撃や異常な場所・挙動からのアクセスを検知し、攻撃を“その場で成立させない”ための制御を行います。
「普段と異なる国・IP からのアクセス」「自動化された不自然なサインイン試行」「既知の攻撃キャンペーン由来の挙動」といった 「瞬間的な危険度」 を評価し、これを条件付きアクセスと組み合わせることで、リスクに応じて、「MFAを要求する」といった制御を行います。
③ユーザーリスクポリシー × 条件付きアクセス
「このユーザー自体が怪しい」 という視点で、資格情報漏えいの疑いや、過去の不審な挙動の蓄積を検知し、侵害されている可能性のあるアカウントを是正するための制御を行います。
ユーザーリスクは、「資格情報が漏えいした可能性」「繰り返し発生する不審なサインインや操作」といった 継続的な危険度 を評価し、これを条件付きアクセスと組み合わせることで、リスクに応じて、「パスワードの変更を強制する」からの「MFA を要求する」といった制御を行い、侵害済みアカウントを“そのまま使い続けさせない”を実現します。
■ まとめ
MFA（アプリ認証）を全員に強制することで、クラウドID防御としては、かなりレベルの高い状態と言えます。
パスワードスプレーはほぼ成立しなくなるし、Authenticator アプリでの数値一致があればMFA疲労攻撃にも高い強度を持ちます。
◆Entra ID P2 の ID Protection は、セーフティーネット
MFAを全員に強制していても、設定漏れ、例外追加、トークン盗難など「想定外」は起こりえます。そこを自動で検知し、必要に応じて修復アクションを取ってくれるのが ID Protection の役割です。
「全員にMFAしてるから安心」ではなく、「安心な状態を維持し続けるために ID Protection を使う」
MFA全社強制という「土台」がしっかりできている組織であれば、ID Protection は「セーフティーネット」としての重要な役割を担います。
