【Microsoft 365】サービスアカウントにMFAを設定できない時の代替設計

Microsoft 365の管理業務において、サービスアカウントに多要素認証(MFA)を設定しようとすると、自動化処理が停止してしまうという壁に直面することがあります。サービスアカウントは人ではなくシステムが利用するため、MFAによる追加認証が発生すると、スクリプトやバッチ処理が途中で止まってしまうからです。この記事では、サービスアカウントにMFAを強制できない状況で、どのようにしてセキュリティを担保しつつ業務を継続するか、具体的な代替設計の方法を解説します。実際の現場で発生しやすい失敗パターンや、管理者が確認すべきポイントもあわせて紹介します。

1. サービスアカウントにMFAが設定できない根本原因

サービスアカウントは、メール送信、データ同期、バックアップ、監査ログの収集など、人間の操作を介さずにバックグラウンドで動作することを前提としています。MFAを有効にすると、認証のたびにワンタイムパスワードや承認要求が発生し、自動化プロセスが停止してしまいます。この競合が、サービスアカウントにMFAを設定できない最大の理由です。

MFAと自動化の競合

通常のユーザーアカウントでは、MFAを有効にしてもユーザーが対話的に応答できます。しかし、サービスアカウントではその応答を行なう人間がいません。PowerShellスクリプトやAzure Automation、タスクスケジューラなどが認証を試みた瞬間、MFAチャレンジが発生してエラーになります。また、アプリパスワード(従来のMFA回避策)は2024年以降段階的に廃止されており、長期的な解決策としては使えません。

アカウントの種類による制限

Microsoft 365にはいくつかのアカウント種類があります。ユーザーアカウント(人間用)にMFAを設定するのは標準的ですが、サービスアカウントとして使う場合は「サービスプリンシパル」や「マネージドID」を採用すべきです。しかし、既存システムがどうしてもユーザーアカウントをサービス用に流用しているケースが多く、そこにMFAをかけられないという問題が発生します。また、ゲストユーザーや共有メールボックスに関連づけられたアカウントも同様の課題を抱えています。

2. 代替設計の選択肢と比較

サービスアカウントにMFAを設定できない場合、以下の代替設計を検討します。各方式にはメリットとデメリットがあるため、自社の要件に合わせて選択してください。

方式	セキュリティ	自動化の容易さ	管理負荷	推奨用途
条件付きアクセスによる除外	中(条件次第)	高い(そのまま使える)	低(一度設定すればOK)	既存ユーザーアカウントを当面使う場合
アプリパスワード(レガシー)	低(パスワードのみ)	高い	中(発行と管理が必要)	非推奨、移行前提の暫定利用
サービスプリンシパル+証明書認証	高い(証明書)	中(証明書管理が必要)	中～高	長期的な自動化基盤
マネージドID(Azureリソース向け)	非常に高い	高い(自動管理)	低(Azure側で管理)	Azure上のワークロード

3. 条件付きアクセスによる除外設定の手順

最も現実的な対応として、条件付きアクセスポリシーで特定のサービスアカウントをMFA対象から除外する方法があります。以下の手順を参考にしてください。

1. Azure AD管理センター(https://aad.portal.azure.com)にグローバル管理者または条件付きアクセス管理者でサインインします。
2. 左メニューの「セキュリティ」→「条件付きアクセス」をクリックします。
3. 「+新しいポリシー」をクリックし、ポリシー名を入力します(例:「サービスアカウントMFA除外」)。
4. 「ユーザーとグループ」で「特定のユーザーを含める」を選び、除外したいサービスアカウントを選択します。逆に、「すべてのユーザー」を含めて「除外」にサービスアカウントを追加する方法もあります。
5. 「クラウドアプリまたは操作」で「すべてのクラウドアプリ」または必要なアプリを選択します。
6. 「条件」で「場所」を設定し、信頼できるIPアドレス(オフィスやデータセンターのIP)からのアクセスのみ許可することで、不正アクセスを防ぎます。
7. 「アクセス許可」で「ブロック」ではなく「アクセス許可」を選び、さらに「付与」設定で「多要素認証が必要」のチェックを外します。代わりに「デバイスは準拠としてマーク済みである必要があります」などを追加してもよいでしょう。
8. 「ポリシーを有効にする」を「オン」にして「作成」をクリックします。

この設定により、指定したサービスアカウントはMFA認証を求められなくなりますが、場所やデバイスの制限をかけることでリスクを低減できます。なお、条件付きアクセスを利用するにはAzure AD Premium P1以上のライセンスが必要です。

4. 管理者が確認すべき事項と失敗パターン

代替設計を実施する前に、管理者が確認しておくべきポイントと、よくある失敗例を挙げます。

確認事項

• サービスアカウントが実際にどのような認証方式を使っているか(基本認証、モダン認証、証明書ベースなど)。基本認証は2022年10月以降廃止されているため、モダン認証への移行が前提です。
• 組織のセキュリティポリシーで「すべてのユーザーにMFA必須」と定められていないか。もしそうであれば、サービスアカウントの例外を明文化してもらう必要があります。
• 条件付きアクセスで除外したアカウントの監査ログを有効にし、不審なアクセスがないか定期的に確認する仕組みを整えてください。

失敗パターン

• パターン1: 「すべてのユーザー」にMFAを強制するポリシーを最優先に設定してしまい、除外ポリシーが適用されない。条件付きアクセスポリシーは優先順位がなく、すべてのポリシーが評価されるため、意図した除外が効かない場合があります。その場合は「ユーザーとグループ」で「すべてのユーザー」を含めず、対象ユーザーを明示的に指定する方法に変更します。
• パターン2: サービスアカウントにアプリパスワードを発行して使い続け、パスワードが漏洩してしまう。アプリパスワードはMFAを回避できる反面、単一パスワードと同等のリスクがあります。どうしても使う場合は、定期的なローテーションとアクセス元IP制限を併用してください。
• パターン3: サービスプリンシパルに切り替えた後も、古いユーザーアカウントの認証情報が残っていて、二重管理になる。移行時には必ず元のアカウントを無効化または削除し、認証情報の棚卸しを行ないましょう。

5. よくある質問

現場で寄せられる質問をまとめました。

• Q: 条件付きアクセスでサービスアカウントを除外しても、MFAを求められてしまいます。
  A: ポリシーの評価順や、既定のMFA登録ポリシーが別途有効になっていないか確認してください。Azure ADの「ユーザーごとのMFA」設定が有効になっていると、条件付きアクセスより優先される場合があります。その場合は「ユーザーごとのMFA」を無効にし、条件付きアクセスに統一します。
• Q: サービスアカウントにマネージドIDを使いたいが、オンプレミスのリソースからは使えません。
  A: その通りです。マネージドIDはAzure内のリソースに限定されます。オンプレミスから使う場合は、サービスプリンシパル+証明書認証か、Azure App Proxyを経由する方法を検討してください。
• Q: アプリパスワードはいつまで使えますか?
  A: Microsoftはアプリパスワードを段階的に廃止する方針です。2024年以降新規テナントでは作成できなくなる可能性があります。できるだけ早く条件付きアクセスやサービスプリンシパルに移行してください。
• Q: 複数のサービスアカウントを一括で管理する方法はありますか?
  A: グループを作成し、そのグループを条件付きアクセスの除外対象にすると便利です。また、PowerShellを使って一括設定するスクリプトを作成することも可能です。

6. まとめ

サービスアカウントにMFAを設定できない問題は、自動化とセキュリティのトレードオフとして頻繁に発生します。本記事で紹介した代替設計(条件付きアクセスによる除外、サービスプリンシパルへの移行、マネージドIDの活用)は、状況に応じて適切に選ぶ必要があります。まずは既存のアカウントがユーザーアカウントかサービスプリンシパルかを確認し、長期的には自動化専用の認証方式へ移行することをおすすめします。条件付きアクセスを使う場合は、場所やデバイスの制限を組み合わせることで、MFAなしでも一定のセキュリティを維持できます。最後に、必ず変更前に影響範囲を検証し、管理者間で合意を得てから実施してください。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。