Microsoft 365へサインインするとき、
メールアドレスやパスワードを入力します。
このときMicrosoft Entra IDでは、
「本当にそのユーザー本人なのか」
を確認しています。
この本人確認の仕組みが
認証（Authentication）です。
さらにMicrosoft Entra IDでは、
パスワードだけではなくMicrosoft Authenticatorなどを組み合わせた
MFA（多要素認証）を利用して、
本人確認を強化できます。
この章では、
認証とは何か、MFAはなぜ必要なのか、そして認証とアクセス許可は何が違うのか
を順番に確認します。
認証とは？
認証とは、
アクセスしてきたユーザーが本当に本人なのかを確認すること
です。
たとえばMicrosoft 365へサインインすると、
Microsoft Entra IDがユーザーの認証を行います。
基本的な流れは次のようになります。
ユーザー
↓
Microsoft 365へサインイン
↓
Entra IDが本人確認
↓
認証成功
この「本人確認」に利用されるのが、
パスワードやMicrosoft Authenticator、
Windows Hello for Businessなどの認証方法です。
パスワードも認証方法のひとつ
もっとも身近な認証方法が、
パスワードです。
ユーザーしか知らないパスワードを入力できれば、
本人である可能性が高いと判断できます。
しかし、パスワードには問題があります。
- フィッシングによって盗まれる
- 同じパスワードを複数サービスで使い回してしまう
- 単純なパスワードを設定してしまう
- 情報漏えいによって外部へ流出する
つまり、
パスワードを知っている＝必ず本人である
とは限りません。
そこで重要になるのがMFAです。
MFAとは？
MFAは、
Multi-Factor Authentication
の略で、日本語では
多要素認証
と呼ばれます。
複数の異なる要素を使って本人確認することで、
パスワードだけの場合より認証を強化します。
認証に使われる要素は、大きく次のように分類できます。
| 認証要素 | 意味 | 例 |
|---|---|---|
| 知識情報 | 本人だけが知っているもの | パスワード、PINなど |
| 所持情報 | 本人が持っているもの | スマートフォン、セキュリティキーなど |
| 生体情報 | 本人自身の特徴 | 指紋、顔など |
異なる認証要素を組み合わせて本人確認するのがMFAです。
「パスワードを2回入力」はMFAではない
ここは重要です。
MFAは単純に
「認証を2回行うこと」
ではありません。
たとえば、
パスワード
＋
別のパスワード
では、どちらも「知識情報」なので、
異なる認証要素を組み合わせたことにはなりません。
一方、
パスワード
＋
Microsoft Authenticatorを登録したスマートフォン
であれば、
- パスワード：知識情報
- スマートフォン：所持情報
という異なる要素を利用するため、
MFAとして本人確認を強化できます。
Microsoft Authenticatorとは？
Microsoft Entra IDのMFAでよく利用される認証方法のひとつが、
Microsoft Authenticatorです。
Microsoft Authenticatorは、
iPhoneやAndroidへインストールして利用するMicrosoftの認証アプリです。
Microsoft 365へサインインすると、
登録しているスマートフォンのAuthenticatorへ
認証要求を送ることができます。
代表的な流れは次のようになります。
Microsoft 365へサインイン
↓
パスワードを入力
↓
Authenticatorへ認証要求
↓
スマートフォンで確認
↓
認証成功
仮にパスワードが第三者へ漏れても、
Authenticatorを登録した端末を持っていなければ、
認証を突破しにくくなります。
Authenticatorの番号一致とは？
Microsoft Authenticatorでは、
MFAを要求されたときに
番号一致（Number Matching）
が使用されます。
たとえばPCの画面に、
42
と表示された場合、
Authenticator側にもその番号を入力して認証します。
イメージすると、
PC：「42」と表示
↓
Authenticator：「表示された番号を入力してください」
↓
42を入力
↓
承認
という流れです。
単純にスマートフォンへ届いた「承認」ボタンを押すだけではないため、
身に覚えのない認証要求を誤って承認するリスクを減らせます。
MFAなら絶対安全というわけではない
MFAを利用すると、
パスワードだけの場合と比較してアカウントを大幅に保護しやすくなります。
ただし、
MFAを設定すればすべての攻撃を防げるわけではありません。
認証方法によって安全性には違いがあります。
たとえばMicrosoft Entra IDでは、
- Microsoft Authenticator
- Windows Hello for Business
- Passkey（FIDO2）
- FIDO2セキュリティキー
- 証明書ベース認証
- SMS
など、さまざまな認証方法を利用できます。
特に高度なセキュリティが必要な場合は、
フィッシング耐性を持つ
Windows Hello for BusinessやPasskey（FIDO2）など
も重要になります。
最初の段階では、
「認証方法によって安全性が異なる」
という点だけ覚えておけば十分です。
認証方法を登録しただけではMFAは要求されない
ここもEntra IDを学習するときに混同しやすいポイントです。
Microsoft Authenticatorをユーザーへ登録したからといって、
すべてのサインインで自動的にMFAが要求されるわけではありません。
大きく分けると、
認証方法
＝ どの方法で本人確認できるか
と、
MFAを要求する仕組み
＝ いつMFAを実行させるか
は別です。
| 仕組み | 役割 |
|---|---|
| Authentication Methods | ユーザーが利用できる認証方法を管理する |
| 条件付きアクセス | 条件に応じてMFAなどを要求する |
| セキュリティの既定値群 | Microsoftが用意した基本的なセキュリティ設定を適用する |
つまり、
Authenticatorを使えるようにする設定
≠
Authenticatorを必ず使わせる設定
です。
この違いは非常に重要なので覚えておきましょう。
MFAを要求する代表的な方法
Microsoft Entra IDでは、
MFAを要求する方法が複数あります。
代表的なものは次の3つです。
| 方法 | 特徴 |
|---|---|
| 条件付きアクセス | ユーザー、アプリ、場所、デバイスなどの条件に応じてMFAを要求できる |
| セキュリティの既定値群 | Microsoftが用意した基本的なセキュリティ保護を利用する |
| ユーザー単位MFA | ユーザー単位でMFAを有効化する従来の方式 |
現在、細かくアクセス条件を設計する環境では、
条件付きアクセスを利用してMFAを要求する方法が基本
です。
条件付きアクセスについては、
次の第6章で詳しく説明します。
認証とアクセス許可は違う
ここまで説明してきた
認証と、
サービスを利用できるかどうかを決める
アクセス許可は別の考え方です。
認証に成功したからといって、
すべてのサービスやデータへアクセスできるわけではありません。
たとえば、
「この人はAさん本人です」
と確認するのが認証です。
その後、
「AさんはこのSharePointサイトを利用してよい」
「Aさんは管理者画面を操作してよい」
と判断するのは、アクセス権やアクセス制御の役割です。
認証とアクセス許可を整理
| 認証 | アクセス許可・アクセス制御 | |
|---|---|---|
| 英語 | Authentication | Authorization / Access Control |
| 確認すること | あなたは誰ですか？ | あなたは何を利用してよいですか？ |
| 例 | パスワード、Authenticator、Windows Hello | グループ、ロール、アクセス権、条件付きアクセスなど |
簡単に覚えるなら、
認証 ＝ 本人確認
アクセス許可 ＝ 本人確認後に何を許可するか
です。
具体例：Microsoft 365へアクセスする場合
会社のユーザーがMicrosoft 365へアクセスする場面で考えてみましょう。
最初にユーザーがメールアドレスなどを入力します。
Entra IDは、
登録されているユーザーを確認します。
その後、
パスワードやAuthenticatorなどを使って本人確認を行います。
さらにアクセス条件やユーザーの権限などが確認され、
問題がなければサービスを利用できます。
大きな流れは次のようになります。
ユーザー
↓
Entra ID
↓
認証
↓
必要ならMFA
↓
アクセス条件を確認
↓
アクセス許可
↓
Microsoft 365
Entra IDは単にパスワードを確認するだけではなく、
認証とアクセス制御を組み合わせてMicrosoft 365などへのアクセスを管理している
ということです。
MFAは毎回要求する必要がある？
必ずしも、
すべてのユーザーへ同じ条件で毎回MFAを要求する必要はありません。
たとえば、
- 特定のアプリへアクセスするとき
- 管理者が管理画面へアクセスするとき
- 特定の場所からアクセスするとき
- サインインのリスクが高いと判断されたとき
など、条件に応じてMFAを要求できます。
このような
「条件を確認して、どのアクセス方法を要求するか」
を制御する代表的な機能が、
Microsoft Entra IDの
条件付きアクセスです。
Authentication Methodsと条件付きアクセスの違い
もう一度、重要な部分を整理します。
| Authentication Methods | 条件付きアクセス | |
|---|---|---|
| 役割 | 利用できる認証方法を決める | アクセス時の条件と要求を決める |
| 例 | Authenticatorを利用可能にする | MFAを要求する |
| 考え方 | 何を使えるか | いつ何を要求するか |
つまり、
Authentication Methods
＝ Authenticatorを「使えるようにする」
条件付きアクセス
＝ Authenticatorなどを使ったMFAを「必要な場面で要求する」
という関係です。
実務ではMFAをどう考える？
現在のMicrosoft 365環境では、
パスワードだけに依存した認証を前提にしないことが重要です。
基本的には、
- MFAを利用する
- 管理者アカウントは特に強く保護する
- Authenticatorなど適切な認証方法を用意する
- 必要に応じてフィッシング耐性のある認証方法を利用する
- 条件付きアクセスを利用できる環境ではアクセス条件と組み合わせる
という方向で設計します。
ただし、
MFAの要求方法や対象ユーザーを十分に確認せず、
いきなり本番環境へ設定すると、
管理者自身がサインインできなくなる可能性
もあります。
実際に設定するときは、
テストユーザーやレポート専用モードなどを利用して
影響を確認してから展開することが重要です。
この章で覚えること
- 認証は「本当に本人なのか」を確認する仕組み
- パスワードも認証方法のひとつ
- MFAは異なる複数の認証要素を使って本人確認を強化する
- Microsoft Authenticatorは代表的な認証方法のひとつ
- 認証方法を登録しただけでは、必ずMFAが要求されるわけではない
- Authentication Methodsは「利用できる認証方法」を管理する
- 条件付きアクセスなどで「MFAをいつ要求するか」を制御する
- 認証とアクセス許可は別の仕組み
- 認証は「あなたは誰か」、アクセス許可は「何を利用してよいか」を判断する
ここまでの関係を整理
第1章からここまでの内容をつなげてみましょう。
テナント
↓
ユーザー
↓
グループ
↓
管理者ロール
↓
デバイス
↓
認証
↓
MFA
Entra IDでは、
ユーザーやデバイスを登録するだけではなく、
「アクセスしてきた人が本当に本人なのか」
を確認します。
そして、本人確認に成功した後、
そのユーザーやアクセス元の状態を確認して
サービスを利用させてよいかを判断します。
次の第6章では、
この判断を行うための重要な仕組みである
条件付きアクセス
について説明します。