Entra ID 多要素認証導入ガイド：ライセンス・テナント設定からポリシー構築まで

1. 前提条件と環境準備

MFA を本格的に運用するには、まず ライセンスの適合性 と テナントの基本構成 が整っていることが前提です。この章では、Premium P1/P2 の有無確認手順と、テナント・ユーザーを整理しておくべきポイントを具体的に解説します。

1‑1. Azure AD Premium ライセンスの確認

概要：条件付きアクセスや認証方法登録ポリシーは Premium P1 以上でしか利用できません。そのため、導入前に必ずライセンス状態を把握し、必要ならば追加購入します。

確認手順（チェックリスト）

1. Azure portal にサインインし、左メニューから 「Cost Management + Billing」 → 「Subscriptions」 を選択。
2. 対象サブスクリプションの 「サービス プラン」 列に Azure AD Premium P1 または P2 が表示されているか確認。
3. 表示がない場合は、Microsoft 365 管理センター の 「ライセンス」 ページから追加購入手続きを行う。

ポイント：Premium P2 を有効化すると、Identity Protection やリスクベースの MFA も利用できるため、将来的な拡張を見据えて P2 の導入を検討してください。

1‑2. テナント設定と基本的なユーザー構成

概要：MFA ポリシーは「ユーザー」「グループ」「クラウドアプリ」単位で評価されます。対象範囲が不明確だと、予期せぬ例外や運用負荷の増大につながります。

実践的な設定ポイント

ベストプラクティス：テナント作成直後に「全員」グループと部門別グループを同時に作成し、以降のポリシー設定はこれらのグループ単位で行うと管理が楽になります。

2. Entra admin center へのアクセスと UI の最新情報

2024 年 10 月現在、Microsoft は Entra admin center（https://entra.microsoft.com/）へ全機能を統合しています。本章では、旧ポータルからの移行手順と、現行 UI の主要構造を把握するためのポイントを解説します。

2‑1. 旧 Azure AD ポータルから Entra admin center への移行手順

概要：旧ポータルは自動リダイレクトされますが、ブックマークや社内ドキュメントが残っていると混乱の元です。以下のステップで確実に新コンソールへ切り替えてください。

移行手順（ステップバイステップ）

1. ブラウザで Entra admin center にアクセスし、企業アカウントでサインイン。
2. 画面左側メニューに 「Azure Active Directory」 アイコンが表示されたことを確認。
3. 旧ポータル（https://aad.portal.azure.com/）へアクセスした場合は、右上の通知バナーにある 「Entra admin center に切り替える」 ボタンをクリック。
4. 移行完了後は、社内ウィキや手順書の URL を https://entra.microsoft.com/ に統一する。

公式情報：Microsoft の移行ガイド（Entra admin center への移行）にスクリーンショットが掲載されていますので、手順書作成時の参考にしてください。

2‑2. 現在の UI 構造と主要ポイント

概要：Entra admin center の UI は左側ナビゲーションパネルと右側コンテキストペインの二層構造になっており、頻繁に使用する設定項目へのアクセスが高速化されています。以下では、代表的なメニュー配置と操作フローを解説します。

UI の主要変更点

• Security → Conditional Access：条件付きアクセスポリシーの作成・管理が左パネルから直接アクセス可能です。
• Identity → Authentication methods：認証方式の有効化や登録ポリシー設定は右側ペインに詳細が展開され、変更内容が即座にプレビューできます。

最新ドキュメント：Entra の全体像と UI 改善については、2024 年 11 月更新版の公式ページ（What is Microsoft Entra?）をご参照ください。

3. MFA 設定の基本構成：Security defaults と条件付きアクセスポリシー

MFA の導入段階は大きく 2 つ に分かれます。（1）Security defaults による全体的な保護、（2）Conditional Access による細粒度制御です。本章ではそれぞれの特徴と実装手順を示します。

3‑1. Security defaults の有効化・無効化と影響

概要：Security defaults は全ユーザーに対して基本的な MFA とパスワード保護を自動で適用しますが、対象の絞り込みや例外設定はできません。小規模環境や導入初期段階での「最低限の防御線」として有効です。

設定手順

1. Entra admin center の左パネルから 「Security」 → 「Identity Protection」 を選択。
2. 上部タブの 「Security defaults」 を開き、スイッチを 「Enabled」 に変更。
3. 変更が反映されるまで数分待ち、全ユーザーでサインイン時に MFA が要求されることを確認。

注意点：Security defaults を無効化した場合は、必ず Conditional Access で代替の MFA ポリシーを作成しないと保護が抜け落ちます。

3‑2. 条件付きアクセスで MFA を必須にする手順

概要：Conditional Access は「ユーザー」「グループ」「アプリ」「場所」など複数の条件を組み合わせて評価でき、業務シナリオごとに最適な MFA 要求を実装できます。まずは全員・全アプリ対象でベースラインポリシーを作成し、その後段階的に例外や追加条件を設定します。

実装フロー

1. 左パネル → 「Security」 → 「Conditional Access」 を開く。
2. 「New policy」 ボタンで新規ポリシー作成画面へ遷移。

3. Assignments（割り当て） で以下を設定：

4. Users：全員または MFA_Required グループ

5. Cloud apps：すべてのアプリ、または重要アプリ（Office 365、Azure portal 等）

6. Locations：信頼できる IP 範囲（社内 VPN など）を除外

7. Access controls（アクセス制御） の Grant で 「Require multi-factor authentication」 にチェック。

8. Enable policy を 「On」 にし、Create で保存。

推奨的な段階的導入例

ベストプラクティス：ポリシー作成後は、必ず 「Report-only」モード で挙動を確認し、実際にブロックされるサインインがないかを Sign‑in logs で検証してください。

4. 認証方法と登録ポリシーの設定

MFA の有効化だけでは不十分です。ユーザーが 認証手段を事前に登録 できていなければ、サインイン時にブロックされるケースが頻発します。本章では利用可能な認証方式と、必須登録ポリシーの作成手順を解説します。

4‑1. 利用可能な認証手段（Authenticator, FIDO2, 電話・SMS, パスワードレス）

概要：Microsoft Authenticator が最も汎用性が高く、FIDO2 キーはフィッシング耐性に優れます。電話／SMS はバックアップとして残すことで、認証手段喪失時のリスクを低減できます。

実装指針：まずは全員に Authenticator を必須化し、重要ユーザーや管理者には FIDO2 キーを追加で割り当てます。

認証方式の有効化手順（UI）

1. Entra admin center の左パネル 「Security」 → 「Authentication methods」 を開く。
2. 各認証方式（Authenticator, FIDO2, Phone, SMS）ごとに 「Enable」 スイッチをオンにする。
3. 必要に応じて 「Maximum number of methods per user」 で上限（例：2 種類）を設定。

公式ドキュメント：認証方法の有効化手順は Microsoft のページ（Enable authentication methods）に詳細なスクリーンショットがあります。

4‑2. Authentication methods registration policy の作成と有効化

概要：登録ポリシーは「ユーザーがサインイン時に必ず指定した認証手段を事前に登録させる」ための仕組みです。これが未設定だと、MFA を要求されたにも関わらず「認証方法が未登録」のエラーでサインインできなくなります。

作成フロー（ステップバイステップ）

1. Entra admin center の左パネル 「Security」 → 「Authentication methods」 → 「Registration campaign」 を選択。
2. 「New policy」 ボタンをクリックし、ポリシー名（例：MFA Registration Policy）を入力。
3. Users セクションで対象ユーザーを指定。全員に適用する場合は 「All users」、一部だけにしたい場合は Azure AD グループを選択。
4. Methods で必須登録させる認証方式（例：Microsoft Authenticator と Phone）にチェックを入れる。
5. Settings → 「Enable policy」 を 「On」 にし、保存。

公式情報：ポリシー作成手順は Microsoft のドキュメント（Configure authentication methods registration campaign）に画像付きで掲載されていますので、社内マニュアルの参照リンクとして活用してください。

ポリシー適用後のユーザー体験

• 初回サインイン時に 「認証方法の登録が必要です」 というバナーが表示され、指定した方式で登録を促す画面へ遷移。
• 登録期限（例：7 日）を設定すると、期限切れ前にリマインダーがメールで送信されます。

5. テスト・検証・トラブルシューティング、例外設定

実運用開始前に テストユーザー でフルサイクルを確認し、エラーケースや例外アカウントの取り扱い方針を固めておくことが成功の鍵です。

5‑1. テストユーザーでの検証フローとサインインログ確認

概要：代表的なシナリオ（社内ネットワーク、外部アクセス、管理者アカウント）をテストし、Sign‑in logs に期待通りの情報が出力されているかをチェックします。

テスト手順詳細

ポイント：テストは必ず 2 種類以上のネットワーク（社内 VPN とパブリック Wi‑Fi） で実施し、場所条件が正しく評価されるかを検証してください。

5‑2. 一般的なエラー対策（デバイス未登録・アプリ不具合等）

概要：多くの障害は「認証手段が未登録」や「Authenticator の同期エラー」に起因します。以下に代表的エラーと復旧フローをまとめました。

トラブルシューティングツール：Get-MgAuditLogSignIn PowerShell コマンドでサインインログを取得すれば、エラーコードと発生時刻が一目で分かります。

5‑3. ロールベースでの例外設定（管理者・サービス アカウント）

概要：高度権限アカウントや自動化用サービスプリンシパルは、業務継続性確保のため MFA の除外が必要になるケースがあります。Conditional Access の 「Exclude」 セクションでロール・サービス アカウントを明示的に除外します。

例外ポリシー設定手順

1. Conditional Access ポリシー作成画面の 「Assignments」 → 「Exclude」 を開く。
2. 「ユーザーとグループ」 に 「Directory roles」 から Global administrator、Privileged role administrator 等を選択。
3. 必要に応じて 「クラウドアプリ」 の除外リストにサービスプリンシパル（例：AppId=00000000-0000-0000-0000-000000000000）を追加。
4. ポリシー保存後、対象ロールのユーザーでサインインテストを実施し、MFA がスキップされることを確認。

ベストプラクティス：例外は最小限に抑え、除外されたアカウントには別途 「条件付きアクセス」＋「リスクベースのブロック」 などで保護レイヤーを追加してください。

6. 運用自動化と監視の拡張ポイント

6‑1. PowerShell / Microsoft Graph を活用したライセンス・ポリシー管理

• ライセンス一括付与：Set-AzureADUserLicense -ObjectId <userId> -AddLicenses @{SkuId="XXXXXXXX"}
• Conditional Access の一覧取得：Get-MgIdentityConditionalAccessPolicy（Microsoft Graph PowerShell）
• 認証方法登録キャンペーンの自動作成：Graph API POST /policies/authenticationMethodsRegistrationCampaigns

スクリプト例（全ユーザーに Authenticator と Phone を必須化）

6‑2. Sign‑in logs の定期分析とアラート設定

• Azure Monitor：SignInLogs テーブルに対して Kusto クエリを作成し、ResultStatus != "0"（失敗）や ConditionalAccessStatus == "failure" を抽出。
• アラート例：1 時間以内に同一ユーザーで 5 回以上 MFA エラーが発生したらメール通知。

7. 本章まとめ

• ライセンス：Premium P1/P2 が無いと条件付きアクセスや認証方法登録ポリシーは利用できない。導入前に必ず確認・取得すること。
• Entra admin center は https://entra.microsoft.com/ に統合済みで、左側ナビゲーションが主軸となる新 UI が提供されている（2024 年時点）。公式ドキュメントのスクリーンショットを参照しながら手順書を作成すべき。
• Security defaults は初期防御として有効化し、段階的に Conditional Access へ移行する方針が安全かつスムーズ。
• 認証方式は Authenticator をコアに据え、FIDO2 キーや電話/SMS を補完で構成。必ず Authentication methods registration policy で事前登録を義務化し、未登録エラーを防止する。
• テストは代表ユーザーで全シナリオ（社内・外部・管理者）を実施し、Sign‑in logs でポリシー適用結果とエラーコードを可視化。
• 例外設定はロールベースで最小限に抑え、除外されたアカウントには別途リスクベース保護や監査ログの強化でフォローする。
• 自動化（PowerShell／Graph）と モニタリング（Azure Monitor/Kusto）を組み合わせることで、運用負荷を低減しつつ継続的なセキュリティ評価が可能になる。

これらの手順とベストプラクティスに沿って実装すれば、Entra ID の MFA 導入は 安全性・可用性・運用効率 の三位一体で成功します。ぜひ本ガイドを社内標準化ドキュメントとして活用し、継続的な見直しサイクルに組み込んでください。