「Azure App Service に多要素認証（MFA）を“無料で”付けられるのか？」——2025 年に入り、Microsoft から「テナントで MFA を有効にしてください」という通知を受け取った管理者や開発者から、同じ質問を多く聞きます。本記事は“誰に”“何が”“いくらで”必要なのかを誤解なく整理し、費用ゼロで要件を満たすための実務手順と、ライセンスが必要になる境界線、運用上の落とし穴まで具体的に解説します。
結論（先に知りたい人向けの要約）
- 通知の対象は「テナントのユーザー（管理者・開発者）」です。公開 Web サイトの匿名閲覧者には MFA 義務はありません。
- Microsoft Entra ID（旧 Azure AD）の「セキュリティ既定値」を有効化すれば、追加ライセンス費用なしで「全ユーザーに MFA」を実現できます。
- 細かな条件分岐（条件付きアクセス）やリスクベース制御をしたい場合のみ、Entra ID P1/P2の有料ライセンスが必要です。
- 自動化・スクリプト・サービス プリンシパルは MFA ではなく、マネージド IDや証明書認証／ワークロード ID フェデレーションに移行しましょう。
「MFA 義務」は誰にかかるのか？——誤解しやすいポイントを整理
Microsoft から届く「MFA を有効にしてください」というメールは、Azure サブスクリプションや App Service を操作できるテナントのユーザー（管理者・開発者・運用担当）に対して、強固な認証（＝MFA）を必須化しましょうという通知です。公開 Web サイトの閲覧者（匿名ユーザー）が Azure にサインインすることはありませんので、閲覧だけの一般ユーザーに MFA は不要です。
逆に、社内向けや会員向けにアプリ側でサインインを実装している場合は、そのサインイン先が Microsoft Entra（B2E / External Identities / B2C 等）であれば、テナント側のポリシーに従って MFA が求められます。これは アプリのユーザー認証の設計に依存する話であり、Azure リソース（App Service）を操作する管理者の MFA 義務とは切り分けて考える必要があります。
「無料」で要件を満たす最短ルート：セキュリティ既定値
セキュリティ既定値（Security Defaults）は、小中規模テナント向けに Microsoft が用意する無償のベースライン保護です。オンにするだけで次の効果が適用されます。
- 全ユーザーに強力な認証（MFA）を要求
- レガシー認証（POP/IMAP/SMTP AUTH などの基本認証）をブロック
- 特権ロール（全体管理者等）への追加保護
- トークン有効期限等のセキュリティ既定設定
設定手順（3 ステップ）
- Microsoft Entra 管理センターで［プロパティ］→［セキュリティ既定値の管理］を開く。
- 「セキュリティ既定値を有効にする」を［有効］に切り替えて保存。
- ユーザーは初回サインイン時または案内に従い、Microsoft Authenticator 等の第二要素を登録（登録ページの目安：aka.ms/mfasetup）。
この手順だけで、追加ライセンス費用なしに「テナントのユーザーは MFA 必須」を満たせます。App Service 自体に何かを“買い足す”必要はありません。
セキュリティ既定値の注意点
- テナント全体に一律で適用され、特定ユーザーやグループの除外はできません（除外や細かな条件は条件付きアクセスの領域）。
- 有償の条件付きアクセス（P1/P2）と併用はできません。高度な制御が必要なら、セキュリティ既定値を無効化し、代わりに条件付きアクセスへ移行します。
- レガシー認証のブロックにより、古いメールクライアントやスクリプトが動かなくなる場合があります。対象ワークロードの洗い出しと移行（アプリ パスワード廃止、OAuth 2.0 化等）を事前に行いましょう。
「有料が必要」になるのはどんな時？——条件付きアクセスとリスクベースの境界線
「すべてのユーザーに MFA を必須」で足りるならセキュリティ既定値で十分です。次のような要件が出たら P1/P2 の検討に移ります。
- 特定のグループ／ロールだけに MFA を課したい（例：管理者は常時 MFA、一般ユーザーは管理ポータルにアクセスするときだけ）
- 場所・デバイス・アプリのリスクに応じて MFA を出し分けたい（例：海外からのアクセスはブロック／MFA 強制）
- サインイン リスクやユーザー リスクに基づく自動対応（P2 の領域）
- 来訪者（外部ユーザー）を柔軟に扱いたい（条項同意、アクセスレビュー、多要素の再確認 など）
機能比較早見表
| 要件 | セキュリティ既定値（無償） | 条件付きアクセス P1 | Identity Protection P2 |
|---|---|---|---|
| 全ユーザーに MFA | ◯（一律適用） | ◯（細かな制御可） | ◯ |
| 特定グループだけに適用／除外 | × | ◯ | ◯ |
| 場所／デバイス／アプリ条件 | × | ◯ | ◯ |
| サインイン リスクに応じた対応 | × | 一部（レポート中心） | ◯（自動ブロック・MFA 等） |
| 外部ユーザーへの細かな制御 | 最小限 | ◯ | ◯ |
Azure App Service と MFA の関係を正しく理解する
「App Service に MFA を付ける」という表現が混乱の元です。実際には次の二層で考えます。
- テナント／Azure リソース操作の認証（管理者・開発者）
Azure ポータル、Azure CLI、PowerShell、ARM/REST 等にサインインするテナントのユーザーに対して MFA を課す領域。今回の通知はここを指します。セキュリティ既定値＝無料で満たせます。 - アプリ利用者の認証（アプリの閲覧・ログイン）
アプリがログインを実装するなら IdP（Entra ID / External Identities / B2C 等）と連携し、テナント側のポリシーに従って MFA が実施されます。匿名閲覧しか提供しないサイトには無関係です。
「App Service Authentication（Easy Auth）」は無料
アプリ側でログインを実装したい場合、App Service の Authentication（旧 Easy Auth）を使えば、追加費用なしで Microsoft アカウント（Entra）、GitHub、Google 等の OIDC/OAuth プロバイダーを統合できます。ここで Microsoft を選べば、テナントの MFA ポリシー（セキュリティ既定値や条件付きアクセス）がそのまま効きます。つまり「アプリに MFA を付ける」のではなく、IdP に MFA のルールがあり、その結果として MFA が要求される形です。
シナリオ別：何をすればよいか早見表
| シナリオ | 必要な対処 | ライセンス | 留意点 |
|---|---|---|---|
| 公開サイトのみ（匿名閲覧） | テナントのセキュリティ既定値を有効化（管理者・開発者向け） | 無償 | 閲覧者には MFA 不要。運用者は Authenticator 登録必須。 |
| 社内ポータル（社員がサインイン） | App Service Authentication + Entra 連携 | 無償〜（高度な条件は P1/P2） | 端末準拠性や場所条件が必要なら P1/P2 で条件付きアクセス。 |
| 会員サイト（社外ユーザー） | External Identities/B2C でユーザー管理 | MAU 課金モデル等 | 規約同意、MFA、再認証などの体験設計が重要。 |
| 自動化・スクリプト（CI/CD） | サービス プリンシパル＋証明書 または ワークロード ID フェデレーション（GitHub Actions/Azure DevOps） | 無償 | MFA ではなく非対話式の強固な認証に設計変更。発行秘密の管理は厳格に。 |
| Azure リソース間アクセス（DB/Key Vault 等） | マネージド ID（System/User Assigned） | 無償 | アプリ内の接続文字列から秘密を排除。RBAC/アクセスポリシーで最小権限。 |
実務手順：セキュリティ既定値の導入から運用まで
1) 事前アセスメント
- 対象ユーザーの洗い出し（全ユーザー、管理ロール保有者、来訪者）
- レガシー認証使用ワークロードの棚卸し（IMAP/POP/SMTP AUTH、基本認証依存のツール 等）
- 特別扱いが必要なアカウントがあるか（注：セキュリティ既定値では除外不可。必要なら CA 構成へ）
2) 段階的な周知と登録
- 周知メール：MFA 必須化の背景、登録期限、サポート窓口、代替手段（電話/ハードウェアトークン 等）
- 登録ガイド：Authenticator のインストール、アカウント追加、バックアップ方法
- バックアップ要素：代替サインイン方法（電話/別端末）を必ず登録
3) 有効化と検証
- テナントのセキュリティ既定値を有効化
- 代表ユーザーで Azure ポータル／CLI を使ってサインイン検証（MFA が出ること、登録が完了すること）
- App Service のデプロイ操作（発行プロファイルではなく、Azure ログイン＋RBAC推奨）
4) 運用ルール
- 権限の最小化（所有者ではなく共同作成者や専用ロールを付与）
- Azure CLI/PowerShell での作業は原則 デバイス コード フローかブラウザフローでサインイン（MFA に対応）
- 発行プロファイル（Publish Profile）の利用は最小化し、サービス接続は サービス プリンシパル＋証明書／マネージド IDへ移行
- 定期的にサインイン ログを確認（不審な失敗、レガシー認証の試行）
トラブルになりやすいケースと回避策
レガシー認証がブロックされてメール送信が失敗する
セキュリティ既定値はレガシー認証を遮断します。アプリの SMTP 送信が失敗する場合は、OAuth 2.0 対応の送信方法（Graph API/SMTP AUTH OAUTH）に移行するか、外部メール送信サービスのモダン認証に切り替えます。
自動化ジョブが「MFA 要求」で止まる
非対話式の処理に MFA は適しません。サービス プリンシパル＋証明書、または ワークロード ID フェデレーション（GitHub Actions などで秘密不要の OIDC）に設計変更しましょう。App Service から Key Vault／Storage へアクセスするなら マネージド IDを使います。
一部ユーザーだけ MFA を外したい
セキュリティ既定値では除外設定ができません。どうしても出し分けが必要なら、セキュリティ既定値を無効化し、条件付きアクセス（P1）で同等以上のポリシーを作成します。その際は、緊急用アカウント（ブレークグラス）を最低 2 つ用意し、厳格な保管・監査ルールを定めてください。
「Per-user MFA（ユーザー単位の旧式設定）」との関係
古い「ユーザー単位の MFA」設定は、現在は推奨されません。セキュリティ既定値または条件付きアクセスに統一し、重複や競合を避けるのがベスト プラクティスです。
Azure CLI・PowerShell・DevOps への具体的インパクト
- Azure ポータル／CLI／PowerShell：サインイン時にMFA 登録／認証が求められます。
- REST / SDK：対話式サインインを使うツールは MFA 対応が必須になります。
- パイプライン（CI/CD）：MFA ではなく、アプリケーション ID＋証明書もしくはOIDC フェデレーションでのトークン発行を用います。
- App Service ↔ Azure リソース：Key Vault/Storage/SQL などは マネージド ID＋RBAC/アクセス ポリシーで連携します。
参考：強制適用の進行状況（目安）
以下は MFA 強制適用の代表的なマイルストーンの目安です。プロダクトごとに段階的に進むため、正式アナウンスとテナントの実挙動を合わせて確認してください。
| 対象サービス | MFA 強制開始予定 | 影響の中心 |
|---|---|---|
| Azure ポータル / Entra 管理センター / Intune | 2024 年内完了済み | 管理者・運用者の対話式サインイン |
| Azure CLI・PowerShell・SDK・REST API | 2025‑09‑15 から | 開発者・自動化ツール（非対話は要設計変更） |
| Microsoft 365 管理センター | 2025‑02 予定 | M365 管理者のサインイン |
「無料で MFA」を実現した後にやると良い改善
- レポートの可視化：サインイン ログから MFA 失敗を可視化し、ユーザー支援に活用。
- パスキー／FIDO2 対応：Authenticator に加えて フィッシング耐性認証（FIDO2/Windows Hello for Business）を段階導入。
- アクセス権の棚卸し：サブスクリプション所有者を最小化、リソース スコープに分割。
- シークレットレス化：Key Vault・マネージド ID・OIDC フェデレーションで“秘密を持たない”運用へ。
ケーススタディ：小規模テナントでの実装例
個人開発者が App Service で静的サイトや API を公開しているケースを想定します。
- ステップ 1：セキュリティ既定値を有効化。管理者（自分）の Authenticator 登録を完了。
- ステップ 2：GitHub Actions からのデプロイは、発行プロファイルではなく、リポジトリに秘密を残さない OIDC フェデレーションで実装。
- ステップ 3：アプリから Key Vault のシークレットを読む必要があれば、App Service の システム割り当てマネージド IDを有効化し、Key Vault にアクセス許可。
- 結果：管理者アカウントは MFA で保護、CI/CD とアプリの横連携は ノーシークレットで安全に。
よくある質問（FAQ）
Q. セキュリティ既定値を有効にしただけで本当に無料ですか？
A. はい。ライセンス課金は発生しません。一方、MFA の条件出し分けやデバイス準拠性を絡めたい等の高度な要件が出れば、P1/P2の検討に進みます。
Q. 匿名閲覧者に MFA を求める必要はありますか？
A. いいえ。匿名閲覧に MFA は不要です。アプリにログイン機能を持たせた場合のみ、IdP とポリシーにより MFA が働きます。
Q. 旧式の「ユーザー単位の MFA」を使い続けても良いですか？
A. 非推奨です。セキュリティ既定値または条件付きアクセスに寄せて一元管理しましょう。
Q. ブレークグラス（緊急）アカウントはどう扱いますか？
A. セキュリティ既定値では除外ができません。高度な運用を求めるなら CA（P1）に移行し、厳格な保管・監査のもとで緊急アカウントを設けます。
Q. SMTP 送信が止まりました。
A. レガシー認証ブロックの影響です。OAuth 対応の送信方式（Graph API/SMTP AUTH OAUTH）に移行するか、モダン認証対応の外部送信サービスへ切り替えましょう。
運用チェックリスト（貼って使える）
- すべての管理者・開発者のAuthenticator 登録が完了している
- レガシー認証を使うワークロードをゼロにできた
- CI/CD は OIDC フェデレーション または 証明書で秘密レス運用
- App Service の横連携は マネージド IDで実装
- サインイン失敗／MFA 失敗の監視とサポート動線を整備
まとめ：公開サイト運営者がやるべき最小限の対策
公開サイトしか運営していない個人・小規模テナントなら、Microsoft Entra の「セキュリティ既定値」を有効化するだけで、追加コストなく MFA 義務をクリアできます。これにより、Azure ポータルや CLI などテナントのユーザーがリソースにアクセスする際は必ず強固な認証を通過します。匿名閲覧者に影響はありません。今後、条件出し分けやリスクベースの制御が必要になったときだけ、P1/P2 ライセンスへの移行を検討しましょう。併せて、自動化はマネージド ID／証明書認証／OIDC フェデレーションへ寄せることで、MFA と矛盾しない安全な運用基盤が完成します。
付録：設定手順メモ（画面遷移）
- Microsoft Entra 管理センターに全体管理者でサインイン
- 左メニュー［ID］→［プロパティ］→［セキュリティ既定値の管理］
- 「セキュリティ既定値を有効にする」＝［はい］に変更 → 保存
- ユーザーへ案内（Authenticator、代替電話、バックアップ コード等）
- 代表者で Azure ポータル／CLI で MFA 動作を検証
コメント