Microsoft から「2025年10月1日以降、Azure のリソース管理操作は MFA 必須」という通知が届くケースが増えています。すでに条件付きアクセス（CA）で管理者 MFA を強制していても、例外（除外）にしているアカウントがあると自動化が止まる可能性があります。本記事では、影響範囲と現場での落とし穴、そして自動処理を止めないための移行方針を具体的に整理します。
まず結論：2025年10月1日以降「Azureを管理するID」は原則MFA必須
2025年10月1日以降、Azure リソースの管理操作（主に Azure Resource Manager＝コントロール プレーンの操作）を行うユーザーは、MFA（または同等の強力な認証）を完了していないと「作成・更新・削除」が通らなくなります。対象は管理者ロールだけではなく、Azure の管理系アプリにサインインする“すべてのユーザー”です。
そして重要なのは、これは「自社テナントのCAポリシーで設定するMFA」とは別に、Microsoft がプラットフォーム側で段階的に強制する仕組みだという点です。つまり、CAで除外しているユーザーがいても、その除外で“必須化そのもの”を回避できません。
今回の必須化は「フェーズ」で理解すると迷わない
Azure/Entra の必須 MFA は大きく2段階（フェーズ1/2）で展開されます。メールで案内されることが多い「2025年10月1日」は、Azure CLI や PowerShell、IaC、REST API など“プログラム的アクセス”を含む範囲に広がるタイミング（フェーズ2）です。
| フェーズ | 主な対象 | MFAが求められる代表例 | ポイント |
|---|---|---|---|
| フェーズ1 | Web管理ポータル系 | Azure portal / Microsoft Entra 管理センター / Intune 管理センター / Microsoft 365 管理センター（順次） | ポータル上のCRUD（閲覧含む）でMFAが必須になりやすい |
| フェーズ2 | ARM経由の管理操作（任意クライアント） | Azure CLI / Azure PowerShell / Azureモバイルアプリ / IaC（Terraform/Bicep等）/ REST API / SDK | 特に「作成・更新・削除」でMFAが必須、読み取りは原則対象外 |
「対象になる操作」はどこまで？管理操作と読み取りの境界
実務で混乱しやすいのが「どの操作が必須化の対象か」です。フェーズ2では、Azure CLI/PowerShell/IaC/REST/SDK などで Azure リソースに対して Create / Update / Delete（作成・更新・削除）を行う操作が対象で、Read（読み取り）は必須化の対象外とされています。
ただし、現場の“体感”としては次のような違いが出ます。
- CLI/PowerShell/IaC： サインイン自体は通っても、作成・更新・削除の実行時に「MFAでサインインし直して」とエラーになることがある
- 一部クライアント： 要求チャレンジ（ステップアップ）でMFAを促してくれるものもあるが、エラーだけ返して止まるものもある
つまり「MFAが求められるタイミング」が“ログイン時”とは限らないため、事前にMFAを満たした状態でトークンを取る運用に寄せないと、現場ではトラブルになりやすいです。
質問1：CAで除外しているContributorアカウントは、2025年10月1日以降も通る？
結論：通りません（回避になりません）。
CAポリシー上は除外が残っていたとしても、必須 MFA の適用が始まると「例外／除外は適用されなくなる」前提で設計し直す必要があります。実際に Microsoft Learn でも、必須化に備えてCAを構成する際、例外や除外を設定しても適用されなくなる旨が示されています。
さらに「すべてのユーザーに必須なのか？」というFAQに対しても、対象アプリにサインインするユーザーは、管理者ロールかどうか、またユーザー除外の有無に関係なくMFAが必要、という整理になっています。
したがって、現在 CA から除外している Contributor（共同作成者）ロールのユーザーアカウントが、Azure の管理操作（作成・更新・削除）を行う限り、MFA を求められます。自動処理で使っている場合、止まる可能性が非常に高いです。
“除外したまま”で起こりやすい現象
- 夜間バッチや連携ジョブが突然失敗し始める（認証エラー／追加認証が必要）
- Terraform/CLI/PowerShell の実行が「MFAでサインインし直せ」系のエラーで停止
- 運用担当が気づかないまま、リソース更新・デプロイが止まり、影響が遅れて顕在化
質問2：一般ユーザー（通常の社員）もMFAが必須になる？今後すべてのユーザーが対象？
今回の必須化は「Azure/Entra の管理系アプリや管理操作」に紐づくものです。つまり、一般ユーザーであっても、次のように Azure リソースの管理を行うなら対象になります。
- Azure portal でリソースを作成・変更・削除する
- Azure CLI / Azure PowerShell / IaC / REST API / SDK で Azure リソースを操作する
- Entra 管理センターでID管理の変更を行う（テナント設定、ユーザー管理など）
一方で、Azure リソースの管理を一切しないユーザー（例：Teams/Exchange/SharePointなど“業務利用のみ”）については、今回の「Azure 管理操作に対する必須化」の直接対象ではありません。管理系アプリ以外のアプリにアクセスする場合は、そのアプリ所有者が認証要件を決める、という整理です。
ただし、攻撃者の狙いは“管理者だけ”ではありません。侵害された一般ユーザーが足掛かりになって最終的に特権へ到達する攻撃も多いため、セキュリティ全体としては「全ユーザーにMFA（できればフィッシング耐性の高い方法）」を広く適用するのが現実的です。
自動化（Business Central等）に最も効く対策：ユーザーアカウント運用をやめ、ワークロードIDへ移行する
今回、最も影響を受けやすいのが「人間のユーザーアカウントを“サービスアカウント”として使っている自動化」です。Microsoft Learn でも、ユーザーアカウントをサービスアカウントとして使うケースがあることに触れたうえで、ワークロードIDへの移行を推奨しています。
そして決定的に重要なのが、マネージドIDやサービスプリンシパルなどのワークロードIDは、この必須MFAの影響を受けないという点です。自動化を止めたくないなら、ここが最短ルートです。
ユーザーアカウント自動化が危険な理由（今回に限らない）
- MFA必須化と相性が悪い： 無人実行では追加認証を完了できない
- 認証情報が漏れやすい： パスワードをスクリプトや設定に埋め込みがち
- 権限が肥大化しやすい： 便利さのために Contributor を広いスコープに付けがち
- 退職/異動/パスワード変更の影響を受ける： “人に紐づくID”をサービス用途に使うほど運用事故が増える
ワークロードIDの選び方（迷う人向けの早見表）
| 選択肢 | 向いている実行場所 | 秘密情報の管理 | 今回のMFA必須化 | 現場目線のポイント |
|---|---|---|---|---|
| マネージドID（Managed Identity） | Azure上（Functions / Logic Apps / Automation / VM等） | 原則不要（シークレット不要） | 影響なし | Azure内で完結する自動化なら最優先。鍵管理が圧倒的に楽 |
| サービスプリンシパル（アプリ登録）＋証明書 | オンプレ/他クラウド/外部SaaS/自社サーバー | 証明書管理が必要（期限・配布） | 影響なし | クライアントシークレットより安全。運用は“証明書更新”が肝 |
| サービスプリンシパル＋フェデレーション（OIDC等） | CI/CD（GitHub Actions / Azure DevOps等） | 原則不要（シークレットレス運用） | 影響なし | 漏えいリスクを大幅に下げられる。外部からの自動化に強い |
| ユーザーアカウント（現状のContributor） | “人が操作する”前提 | パスワード＋MFAが必要 | 影響大 | 自動化用途には非推奨。暫定対応なら期限を切って廃止する |
Business Central の自動処理が止まらないようにする設計例
Business Central 側から Azure の管理操作（例：リソース作成、設定変更、デプロイ、スケールなど）を自動で行う場合、よくある“落とし穴”は「Business Central からユーザーIDで直接 ARM を叩く」構成です。これだと MFA 必須化で詰みます。
現実的には、次のような“中継”を置く設計が安定します。
- 中継に Azure Functions / Logic Apps / Automation を採用し、そこにマネージドIDを付与
- Business Central からは「中継サービス」を呼び出すだけにして、Azure 管理操作はマネージドIDが実行
- 必要な権限はサブスクリプション全体ではなく、対象リソースグループ単位に絞って付与（最小権限）
これにより、MFA と無人実行の矛盾を解消しつつ、監査（誰が何をしたか）も追いやすくなります。
移行の最小ステップ（現場で詰まりやすい順に）
- 対象作業の棚卸し： そのContributorアカウントが「何を」「どのスコープで」しているか（サブスクリプション/リソースグループ/リソース）
- 権限の絞り込み： Contributor固定にせず、必要ならカスタムロールも検討
- ワークロードIDの作成： 実行場所に合わせて Managed Identity か Service Principal を選択
- RBAC付与： 既存のContributor権限を“そのまま付け替える”のではなく、最小権限で再設計
- 認証方式の差し替え： ユーザーIDログイン（ユーザー名/パスワード）を廃止
- 本番適用前テスト： 監査モードで影響を見える化してから段階展開
“ユーザー名＋パスワードでトークン取得”は要注意（ROPC系は壊れやすい）
スクリプトやアプリで「ユーザー名とパスワードを渡してトークンを取得する」方式（いわゆる ROPC）は MFA と両立できません。必須化が進むと、ROPC を使うAPIが例外を返すようになるため、該当箇所は早めに置き換え対象として洗い出すのが安全です。
ありがちな例として、環境変数にユーザー名/パスワードを入れて SDK が自動ログインする実装や、CIでユーザーIDログインを行う運用は、長期的に維持できません（今回の必須化で顕在化しやすいポイントです）。
“プログラム的アクセス”の延期オプション：2026年7月1日まで延ばせるが、恒久対策ではない
どうしても2025年10月1日までに対応しきれない場合、グローバル管理者が「フェーズ2の適用開始」をテナント単位で延期できるオプションがあります。延期できる期限として 2026年7月1日が示されています。
ただし、これは“やらなくていい”という意味ではなく、単なる猶予です。延期を選んだ場合でも、次の2点は同時に進めるのが現実的です。
- ユーザーアカウント自動化の廃止計画： ワークロードIDへ段階移行
- 影響範囲の可視化： 監査モードで「何が止まるか」を先に把握
対応の実務ガイド：何から着手すべきか（おすすめ順）
影響を受けるユーザー・IDを洗い出す
まずは「誰がAzure管理をしているか」を人ベースではなく“IDベース”で洗い出します。ポイントは、運用担当だけでなく、開発・外部ベンダー・CI/CD・SaaS連携なども含めることです。
| 観点 | チェック方法（例） | 見つかったらやること |
|---|---|---|
| Azure RBAC | Owner / Contributor / User Access Administrator 等の割当 | 最小権限へ見直し、サービス用途はワークロードIDへ |
| 自動化の認証方式 | ユーザーIDでログインしていないか（スクリプト、バッチ、ツール設定） | Managed Identity / Service Principal へ切替 |
| 利用クライアント | CLI/PowerShell/IaC/SDK/REST の利用有無 | 更新・置換・テスト計画を立てる |
| “除外されているID” | CAの除外、MFA未登録ユーザー、例外運用 | 例外を廃止（または期限付きで縮小）し、移行へ |
条件付きアクセス（CA）の役割を再定義する
必須化後も CA は不要になりません。むしろ、次のような“自社ルール”を表現するのが CA の役割になります。
- どのネットワーク（社内/社外）で追加制御するか
- 準拠デバイスのみ許可するか
- フィッシング耐性の高いMFA（パスキー/FIDO2等）を特権に要求するか
- サインイン頻度（再認証）をどうするか
一方で、必須化を“避ける”目的の除外設計は成立しません。必須化に備える文脈でも、例外/除外は適用されなくなる前提で運用する必要があります。
クライアントの更新：CLI/PowerShellは「古いまま」が事故要因
フェーズ2では、クライアント側の要求チャレンジ（ステップアップ）対応が重要になります。互換性の観点で、Azure CLI と Azure PowerShell は一定以上のバージョンが推奨されています。現場で「急に動かない」が起きる典型なので、更新計画を先に入れておくと安定します。
“事前に壊れる箇所”を見える化する：Azure Policy の自己強制（監査→強制）
本番で突然止まるのが一番高コストです。Microsoft は、将来の必須化に備えて Azure Policy で自己強制（事前検証）できる手順を提供しています。
手順の要点だけ抜き出すと次の通りです。
- Azure Policy で多要素ポリシー定義を割り当てる（まず監査モード）
- 監査イベントで「MFAなしで実行された作成/更新/削除」を把握
- 問題が整理できたら、効果（Effect）を Deny/DenyAction に切り替えて段階強制
実際に用意されている組み込み定義は、少なくとも次の2種類が明示されています（作成/更新 と 削除 を分けて検証できるのが実務的に便利です）。
- リソースを削除するには、ユーザーが多要素認証で認証する必要があります
- ユーザーは、リソースを作成または更新するために、多要素認証で認証する必要があります
さらに、いきなり全リージョンで強制すると事故が起きるため、リソース セレクター等を使って低リスクの範囲から段階ロールアウトする設計が推奨されています。
よくある論点：緊急用（ブレークグラス）アカウントはどうする？
CAの世界では「ブレークグラスは除外」が定番ですが、必須化では緊急アクセスアカウントも含めて MFA 要件を満たす必要がある、という整理になっています。運用上は、緊急アカウントにパスキー（FIDO2）や証明書ベース認証など“強い方法”を持たせて、MFA要件を満たしつつ復旧手段として機能させるのが現実的です。
外部MFA（Okta/ADFS等）を使っている場合の考え方
既存の外部MFAを使い続けたい場合でも、Microsoft Entra 側で「MFAを満たした」というアサーションが正しく渡る構成であれば要件を満たせます。一方で、レガシの条件付きアクセスのカスタムコントロール（プレビュー）は要件を満たさない、といった注意点もあるため、“今の構成が要件を満たす形で統合されているか”を確認してください。
最終チェック：この必須化で「今すぐ見直すべき」運用ルール
| チェック項目 | 危険サイン | 推奨アクション |
|---|---|---|
| CAの除外 | 自動化用ユーザーや特定担当者をMFAから除外している | 除外は廃止。自動化はワークロードIDへ |
| ユーザーIDの自動化 | ユーザー名/パスワードでCLIやSDKが動いている | Managed Identity / Service Principal に切替 |
| 権限スコープ | Contributor がサブスクリプション全体に付いている | リソースグループ単位、必要ならカスタムロール |
| 検証のやり方 | 本番で“当日止まったら考える”状態 | Azure Policy 監査モードで事前可視化 |
| クライアント更新 | 古いCLI/PowerShellを固定で使っている | 推奨バージョンへ更新し、要求チャレンジ対応を確保 |
まとめ：今回のメールを受け取ったら、運用方針をこう決める
- 「Azureを管理するユーザー（ID）は、原則MFA必須」として棚卸しする
- CAの除外で回避する運用は終了（止まる前提で設計変更）
- 自動化はユーザーIDからワークロードIDへ（Managed Identity / Service Principal）
- 延期オプションは“時間を買うだけ”。恒久対応の計画とセットで使う
- 監査→段階強制で、事前に壊れる箇所を潰す（Azure Policy活用）
Business Central のように業務プロセスに組み込まれた自動処理ほど、止まったときの影響は大きくなります。今のうちに「ユーザーアカウント＋Contributor」で動いている箇所を洗い出し、ワークロードIDへ切り替える設計に寄せておくと、2025年10月以降も運用を安定させやすくなります。
コメント