こんにちは、InfraAcademyを運営しているryuです。
今回は、Microsoft Entra IDで多要素認証（MFA）を設定する考え方と方法を、IT初心者向けに解説します。
クラウドサービスを使うとき、IDとパスワードだけでログインしていませんか。もしパスワードが漏えいすると、それだけで第三者にログインされる可能性があります。
そこで重要になるのが多要素認証です。パスワード以外の認証方法も組み合わせることで、アカウントを不正ログインから守りやすくなります。
この記事は2019年に公開した内容を、現在のMicrosoft Entra IDに合わせて全面的に見直しています。以前のAzure Active Directoryという名称や、ユーザーごとにMFAを「有効」「強制」へ変更する古い手順を中心にせず、現在推奨されているSecurity defaultsとConditional Accessを軸に解説します。
多要素認証（MFA）とは？¶
多要素認証は、異なる種類の認証要素を組み合わせて本人確認を行う仕組みです。
代表的な認証要素は、次の3種類です。
| 認証要素 | 例 |
|---|---|
| 知識情報 | パスワード、PIN |
| 所持情報 | スマートフォン、セキュリティキー |
| 生体情報 | 指紋、顔認証 |
例えば、パスワードだけでログインする場合は知識情報だけを使っています。そこへスマートフォンを使った認証を追加すると、知識情報と所持情報を組み合わせた認証になります。
元記事ではIPアドレスやGPSの位置情報も認証要素として紹介していましたが、これらは一般的には本人を証明する認証要素ではなく、アクセス元のリスクを判断するための条件やシグナルとして利用されます。
この違いを理解しておくと、後ほど紹介するConditional Accessも分かりやすくなります。
なぜパスワードだけでは不十分なの？¶
強いパスワードを設定することは大切です。しかし、どれだけ複雑なパスワードでも、フィッシングなどで本人が入力してしまえば攻撃者に知られる可能性があります。
また、複数のサービスで同じパスワードを使い回していると、別のサービスから漏えいした認証情報を使ってログインを試されることもあります。
MFAを設定しておけば、パスワードが知られただけではログインを完了できない状態を作れます。
ただし、MFAならどの方式でも同じ強さというわけではありません。SMSやワンタイムコードもパスワードだけより安全性を高められますが、フィッシングに強い方法として、MicrosoftはパスキーやFIDO2セキュリティキー、Windows Hello for Businessなどの利用を推奨しています。
Azure ADはMicrosoft Entra IDへ名称変更された¶
古いAzureの記事では、Azure Active DirectoryやAzure ADという名前をよく見かけます。
現在の名称はMicrosoft Entra IDです。
サービスの役割がまったく別物になったわけではありません。AzureやMicrosoft 365などで利用するユーザー、グループ、認証、アクセス制御を管理するクラウドベースのID管理サービスです。
そのため、古い記事にAzure ADと書かれている場合は、現在のMicrosoft Entra IDに相当するものだと考えてください。
Microsoft Entra IDでMFAを有効にする方法¶
現在、MFAを適用する代表的な方法は次の3つです。
| 方法 | 向いている環境 |
|---|---|
| Security defaults | 小規模環境や、細かな条件設定が不要な場合 |
| Conditional Access | ユーザーやアプリ、リスクなどに応じて細かく制御したい場合 |
| Per-user MFA | 互換性など特別な理由がある場合 |
Microsoftは、MFAを適用する方法としてConditional Accessを推奨しています。
Conditional Accessを利用できない環境では、Security defaultsを使う方法があります。Per-user MFAも現在利用できますが、Conditional AccessやSecurity defaultsを利用している環境で併用する方法は推奨されていません。
初心者ならSecurity defaultsから理解しよう¶
Security defaultsは、Microsoft Entra IDで基本的なセキュリティ設定をまとめて適用する仕組みです。
複雑な条件を自分で作成しなくても、MFA登録など、基本的な保護を有効にできます。Conditional Accessを利用しない小規模な環境では、最初に検討しやすい方法です。
Security defaultsを利用する場合、対象ユーザーはMFAに利用する認証方法を登録します。現在はMicrosoft Authenticatorなどを使った認証を利用できます。
ただし、Security defaultsは細かな除外や条件を自由に設定する仕組みではありません。特定の部署だけ条件を変えたい場合や、管理者アカウントにより強い認証を要求したい場合はConditional Accessを検討します。
Conditional AccessでMFAを要求する¶
企業でMicrosoft Entra IDを利用する場合、Conditional Accessは非常に重要な機能です。
Conditional Accessでは、誰が、どのサービスへ、どのような条件でアクセスしたかを判断し、その結果に応じてMFAなどのアクセス制御を適用できます。
例えば、すべてのユーザーに対してMicrosoft Entra MFAを要求するポリシーを作成できます。さらに、必要に応じて特定のユーザーやアプリ、デバイス状態などを条件に設定できます。
設定するときは、いきなり本番で全ユーザーへ適用するのではなく、テスト用ユーザーで確認し、Report-onlyモードで影響を確認してから有効化する方法が安全です。
特に管理者自身を誤ってロックアウトしないよう、緊急アクセス用アカウントの設計も含めて進める必要があります。
Conditional Accessの基本的な設定項目¶
Conditional Accessポリシーを作るときは、主に次の内容を設定します。
- 対象となるユーザーやグループを決めます。
- 対象となるクラウドアプリやリソースを決めます。
- 必要に応じて場所、デバイス、サインインリスクなどの条件を設定します。
- アクセスを許可するために必要な認証強度やMFAを指定します。
- Report-onlyで動作を確認してからポリシーを有効にします。
初心者のうちは、細かな条件を増やすよりも、まず「誰に」「何へアクセスするとき」「何を要求するのか」の3点を整理すると理解しやすいです。
例えば、全社員が業務用クラウドサービスへアクセスするときにMFAを要求する、という設定なら目的が明確です。
Microsoft Authenticatorを登録する¶
MFAを要求するだけでは、ユーザー側で利用できる認証方法がなければログインできません。
Microsoft Authenticatorを使う場合は、ユーザー自身がMicrosoft Entra IDのセキュリティ情報から認証方法を登録します。
登録時には、スマートフォンへMicrosoft Authenticatorをインストールし、画面に表示されたQRコードを読み取ってアカウントを追加する方法が一般的です。
登録後は、サインイン時にAuthenticatorへ届いた通知を確認して認証します。
現在はAuthenticatorだけでなく、パスキーやFIDO2セキュリティキーなども利用できます。組織のセキュリティ要件に応じて、Authentication methods policyで利用可能な認証方法を管理します。
SMS認証だけに頼らない¶
元記事では、SMS認証を中心にMFAを説明していました。
SMSを使った認証もパスワードだけより安全性を高める方法ですが、現在はよりフィッシングに強い認証方法があります。
Microsoft Entra IDでは、パスキー、FIDO2セキュリティキー、Windows Hello for Business、証明書ベース認証など、フィッシング耐性を持つ認証方法を利用できます。
すべてのユーザーを一度に移行するのが難しい場合でも、管理者や重要システムへアクセスするユーザーから強い認証方法を導入する考え方があります。
MFAを設定することをゴールにせず、どの認証方法を使うのかまで考えることが大切です。
Per-user MFAは使ってはいけないの？¶
Microsoft Entra IDには、ユーザーごとにMFAをEnabledやEnforcedへ変更するPer-user MFAも残っています。
古いAzure記事では、この方法がよく紹介されています。今回リライトした元記事もこの方式でした。
現在は、Conditional Accessを利用できる環境ならConditional Accessへ移行することが推奨されています。Microsoft Entra ID FreeでConditional Accessを利用しない場合は、Security defaultsを検討できます。
既存環境でPer-user MFAが設定されている場合は、何も確認せず無効化するのではなく、Conditional AccessやSecurity defaultsで同等以上の保護が適用されることを確認してから移行してください。
MFAを設定してもフィッシングには注意する¶
MFAを設定すれば、すべてのアカウント攻撃を防げるわけではありません。
例えば、攻撃者が偽のログイン画面を用意し、パスワードだけでなくワンタイムコードまで入力させるフィッシングがあります。利用者が内容を確認せずAuthenticatorの通知を承認してしまう攻撃も考えられます。
そのため、MFAとあわせて次の対策も重要です。
- フィッシングに強い認証方法を利用する
- 不要な認証方法を許可しない
- Conditional Accessでアクセス条件を制御する
- サインインログを監視する
- 管理者権限を必要最小限にする
- ユーザーへフィッシング対策を教育する
認証を1つ追加するだけで終わらず、IDを中心に複数の対策を組み合わせます。
MFAの動作をサインインログで確認する¶
設定したMFAが本当に適用されているか確認するときは、Microsoft Entra IDのサインインログが役立ちます。
サインインログでは、ユーザーのログイン結果だけでなく、Conditional Accessポリシーの評価結果や認証に関する情報も確認できます。
MFA設定後は、自分で実際にログインして動作を確認し、そのサインインがログ上でどのように記録されたかまで見ると理解しやすくなります。
設定画面だけを見て終わるのではなく、実際の認証結果とログを確認するところまで行うのがおすすめです。
ID管理とセキュリティはセットで学ぶ¶
MFAを理解すると、Microsoft Entra IDだけでなく、認証、アクセス制御、ログ監視などの知識がつながってきます。
例えば、MFAで本人確認を強化しても、ユーザーへ必要以上の管理者権限を与えていれば、アカウントが侵害されたときの影響は大きくなります。
InfraAcademyでは、Linux、ネットワーク、クラウド、セキュリティなど、インフラエンジニアに必要な基礎を段階的に学習できます。
認証方法の名前だけを覚えるのではなく、ユーザーがどのサービスへアクセスし、どこで認証され、どの権限を与えられているのかまで考えられるようになると、セキュリティを理解しやすくなります。
Microsoft Entra MFAまとめ¶
今回は、Microsoft Entra IDで利用する多要素認証について解説しました。
多要素認証では、知識情報、所持情報、生体情報など、異なる種類の認証要素を組み合わせて本人確認を強化します。
現在のMicrosoft Entra IDでは、MFAを適用する方法としてConditional Accessが推奨されています。Conditional Accessを利用しない小規模環境などではSecurity defaultsも利用できます。
古い記事でよく紹介されていたPer-user MFAは現在も存在しますが、新しい構成ではConditional AccessやSecurity defaultsを先に検討した方がよいでしょう。
また、MFAを有効にするだけでなく、Microsoft Authenticator、パスキー、FIDO2セキュリティキーなど、どの認証方法を使うのかも重要です。
最初は、パスワードだけの認証とMFAの違いを理解し、そのあとConditional Accessや認証強度へ進むと分かりやすくなります。
