共有アカウントにMFAを付けたい。でも認証アプリは誰のスマホに届くのか、退職者が出たらどうするのか――運用で詰まりがちです。本記事ではMicrosoft Entra ID（旧Azure AD）を前提に、共有アカウントを減らしつつ安全に守る設計と、条件付きアクセスを使った現実的な落としどころを解説します。
共有アカウントにMFAを「そのまま」適用すると失敗しやすい理由
「複数人で同じ端末・同じIDを使う共有アカウント」に対して、多要素認証（MFA）を導入してセキュリティを上げたい――この相談は現場でとても多いです。ところが、共有アカウントはMFAの前提（本人確認＝個人）と根本的に相性が悪く、無理に運用すると“セキュリティ強化のつもりが、監査性も運用性も下がる”結果になりがちです。
Microsoft Entra ID（旧Azure AD）ではMFAを柔軟に設計できますが、まずは「共有アカウントにMFAを付ける」発想をいったん止めて、何を共有しているのか（アカウントなのか、権限・リソースなのか）を切り分けることが近道です。
| 共有アカウントにMFAを付けたときに起きやすいこと | なぜ問題になるか | 現場での典型症状 |
|---|---|---|
| 認証通知・コードの行き先が決められない | MFAは「誰が承認したか」を個人に紐づける仕組みのため | 特定の人のスマホに通知が集中／不在で業務停止 |
| 退職・異動時の回収が漏れる | 共有アカウントは責任者が曖昧になり、認証手段の棚卸しが難しい | 前任者の電話番号が残り続ける／解除できずパスワードを回す |
| 監査ログで「誰がやったか」が追えない | サインイン主体が同一IDになるため、行為者特定が不可能になる | 事故・情報漏えい時の調査が長期化 |
| “共有のMFA”が常態化して形骸化 | コード共有・通知転送が起きると、第二要素が第三者にも届く | チャットにワンタイムコードが流れる／運用が危険物化 |
「共有アカウント」と一括りにしない：タイプ別に最適解が違う
共有アカウントの改善が進まない最大の理由は、用途の異なるものを同じ“共有アカウント”として扱ってしまうことです。まずはタイプを分けて考えると、代替策が見えやすくなります。
| タイプ | 例 | よくある誤解 | 推奨アプローチ |
|---|---|---|---|
| 人が使う共有ID | 店舗端末の共通ログイン、代表メールのログインID | 端末が共用だからIDも共用にする | 個人アカウント + 委任（共有メールボックス、グループ、ロール） |
| 特権（管理者）共有ID | admin@ を複数人で使う、外注先と共有する管理ID | 管理作業は共通IDのほうが便利 | 個人管理者 + 昇格（PIM）+ 強いMFA + 厳格な条件付きアクセス |
| 自動化・バッチ用ID | RPA、夜間バッチ、API連携のログインID | 人間と同じ“ユーザーID”で動かすのが普通 | ワークロードID化（アプリ登録/サービスプリンシパル/マネージドID）を検討 |
MFA運用の大原則：共有するのは「アカウント」ではなく「権限」と「リソース」
結論から言うと、共有アカウントの課題を最もきれいに解決するのは「個人アカウント + 権限委任（委任アクセス）」へ寄せることです。サインインは常に個人で行い、共有したいもの（メールボックス、フォルダー、アプリ機能、管理作業）だけを権限として共有します。
| 共有したいもの | やりがちな“共有アカウント” | 推奨（個人アカウント + 権限委任） | 得られる効果 |
|---|---|---|---|
| 代表メール（例：support@） | support@ を全員でログインして使う | 共有メールボックスを作成し、各個人にフルアクセス/送信権限を付与 | 誰が送受信したか追跡できる／退職時に権限を外すだけ |
| ファイル・資料 | 共有IDでOneDriveに保存 | SharePoint/Teamsに置き、メンバー/権限グループで共有 | 世代管理・権限管理が標準化 |
| 業務アプリの操作 | 部署共通IDでサインイン | アプリ側でロール管理、またはEntraのグループ/アプリロールを割り当て | 最小権限・職務分掌を作りやすい |
| 管理者作業 | admin@ を複数人で共有 | 個人の管理者アカウント + Privileged Identity Management（PIM）で昇格 | 管理操作の監査性が大幅に向上 |
まずやるべき棚卸し：共有アカウントを「用途」で分解する
移行を成功させるコツは、いきなり「共有アカウントを廃止する」と宣言しないことです。現場にとって共有アカウントは“便利な近道”なので、用途別に代替策を示すと抵抗が下がります。
- 対人業務（メール・問い合わせ）：代表メール、店舗受付、採用窓口など
- 端末都合（共用PC・共用タブレット）：交代制、現場端末、カウンター端末など
- システム都合（レガシー/ベンダー）：アプリが個人アカウント前提でない、SaaSがロール分離できない
- 運用都合（管理者・RPA・バッチ）：特権操作や自動化が絡む
この分類ができると、以降の打ち手（共有メールボックス、共有デバイス設計、ワークロードID化、特権管理）にスムーズに接続できます。
理想形：個人アカウントにMFAを必須化し、共有は委任で解く
Microsoft Entra IDでセキュアに運用するなら、基本方針は次の通りです。
- 全ユーザーに固有の個人アカウント（Entra IDアカウント）を発行する
- 個人アカウントに対してMFAを必須化する（条件付きアクセスまたはセキュリティの既定値）
- 共有したいリソースには、グループ・ロール・委任アクセスで権限を付与する
- 監査ログ（サインインログ/監査ログ）で“誰が何をしたか”を追える状態にする
これにより、サインインは常に「個人 + MFA」になり、共有は「権限の共有」に変わります。セキュリティの強度だけでなく、事故対応や内部統制の観点でも大きなメリットがあります。
セキュリティの既定値と条件付きアクセス、どちらでMFAを必須化する？
Entra IDには、最低限の保護をまとめて有効化できる「セキュリティの既定値」と、細かく設計できる「条件付きアクセス」があります。共有アカウントのように例外や段階移行が必要な環境では、基本的に条件付きアクセスが向きます。
| 項目 | セキュリティの既定値 | 条件付きアクセス |
|---|---|---|
| 柔軟性 | 低い（細かな例外設計が難しい） | 高い（ユーザー/場所/端末/アプリごとに制御可能） |
| 導入難易度 | 低い | 中〜高（設計とテストが必要） |
| 共有アカウントへの適性 | 低い | 高い（暫定防御の作り分けができる） |
| ライセンス | 追加のプレミアム機能がなくても有効化できる | 一般にEntra ID P1相当が必要（リスクベースはP2相当） |
代表メールは「共有メールボックス + 委任」が最短ルート
代表メールを共有アカウントで運用しているケースは特に多いですが、これは共有メールボックス（Exchange Online）に置き換えるのが最も効果的です。運用のポイントは次の3つです。
- 共有メールボックスに対して、担当者の個人アカウントへ「フルアクセス」「送信 as」「送信 on behalf」など適切な権限を付与する
- 自動応答やルールは共有メールボックス側で管理し、個人の受信トレイに依存しない
- 退職・異動時は“アカウント停止”ではなく“権限剥奪”で済むようにする
「全員が同じIDでログインしている」状態が解消され、MFAは個人に自然に紐づきます。
共有PC・共有タブレットは「共有アカウント」より「共有デバイス」を正しく設計する
現場の共用端末でよくあるのが、「端末が共用だからアカウントも共用」という誤った短絡です。端末が共用でも、サインインは個人アカウントにできます。例えば次のような設計が現実的です。
- Windows端末：ユーザーは個人でサインインし、必要に応じてサインアウト/自動サインアウト（タイムアウト）を設定
- モバイル端末：MDM（例：Intune）で管理し、アプリやデータの分離（業務領域）を徹底
- サイネージ/受付/キオスク：そもそも個人サインインを不要にし、キオスクモードでアプリを限定
“共有アカウントを守る”発想ではなく、共有デバイスとしての制御（準拠デバイス、アプリ保護、セッション制御）を強めるのがポイントです。
条件付きアクセスでMFAを「強制」する前に押さえるべき設計要素
個人アカウントへMFAを必須化するとき、いきなり全社一斉に強制すると混乱します。条件付きアクセス（Conditional Access）を使う場合は、次の観点で設計すると失敗しにくくなります。
| 設計観点 | 具体例 | 狙い |
|---|---|---|
| 対象の絞り込み | ユーザー/グループ、対象アプリ、対象プラットフォームを段階適用 | 影響範囲を制御し、検証しながら進める |
| 例外の扱い | 緊急用アカウント（ブレークグラス）は別管理し、原則はポリシーから除外 | ポリシー誤設定時の復旧手段を確保する |
| 認証強度 | パスワード+SMSより、Authenticator/セキュリティキー/Windows Helloを優先 | フィッシング耐性とユーザー体験を両立 |
| セッション制御 | サインイン頻度、永続ブラウザーセッション、アプリ強制サインアウト | “一度通ったら永遠に通る”を防ぐ |
ブレークグラス（緊急用）アカウントは“共有”ではなく“非常口”として設計する
条件付きアクセスを本格的に使い始めると、設計ミスや想定外の影響で「管理者がサインインできない」事故が起きる可能性があります。そのため、多くの組織では緊急用（ブレークグラス）アカウントを用意します。重要なのは、これは共有アカウントの代用品ではなく、あくまで復旧のための“非常口”だという点です。
| 項目 | おすすめの考え方 |
|---|---|
| アカウント数 | 最低でも複数（例：2つ）用意し、片方が使えない事態に備える |
| 条件付きアクセスの適用 | 原則として除外し、誤設定時でも管理者が復旧できる状態を確保する |
| パスワード | 長く強いものを設定し、パスワード保管庫や物理的に厳重な場所で管理する |
| 利用ルール | “いつ・誰が・なぜ使ったか”を記録し、使用後はパスワード変更などの後処理を徹底する |
| 監視 | サインインが発生したら即時通知するなど、平常時は「使われない」ことを前提に監視する |
ブレークグラスを日常の共有運用に流用すると、結局「誰がやったか」が追えなくなります。共有アカウント問題の解決策としては使わず、例外は例外として分離するのが安全です。
MFA方式の選び方：利便性と強度のバランス
MFAというと「SMSコード」を思い浮かべる人も多いですが、運用とセキュリティの両面からは推奨度が高い順に選ぶのが定石です。特に共有端末がある環境では、端末にひもづく強い方法（Windows Hello for Business、FIDO2セキュリティキーなど）が効きます。
| 方法 | ユーザー負担 | フィッシング耐性 | 向くシーン | 注意点 |
|---|---|---|---|---|
| Microsoft Authenticator（プッシュ/番号一致） | 低 | 中 | 一般社員、日常業務 | 端末紛失時の手順（再登録）を整備 |
| Windows Hello for Business | 低 | 高 | Windows中心、共有PCでも個人ログオンする運用 | 端末展開（Intune/ポリシー）と初期登録設計が必要 |
| FIDO2セキュリティキー | 中 | 高 | 高権限、フィッシング対策を強めたい | 配布・紛失・予備キー管理が必須 |
| SMS/音声通話 | 中 | 低 | 暫定対応 | SIMスワップ等のリスクを考慮し、長期運用は避けたい |
どうしても共有アカウントを残す場合の「被害を小さくする」運用
レガシーな業務システムや外部ベンダー要件などで、共有アカウントをすぐに廃止できないこともあります。その場合は、MFAを“共有”してしまうのではなく、条件付きアクセスでリスクを囲い込むのが現実的です。質問者が行っている「社内ネットワークからのみログインを許可」は良い方向性で、さらに次を積むと効果が上がります。
| 追加防御 | 設定例 | 期待できる効果 |
|---|---|---|
| 場所（IP）制限 | 社内グローバルIPを信頼済みロケーションとして登録し、それ以外をブロック | 資格情報漏えい時の外部悪用を抑止 |
| 端末制限 | 準拠デバイスのみ許可、または特定デバイス（フィルター）だけ許可 | “どこからでもログイン”を防ぐ |
| レガシー認証の遮断 | 基本認証/古いプロトコルをブロック | MFAを迂回する入口を閉じる |
| セッション制御 | サインイン頻度を短く、永続セッションを無効化 | 共有端末の“置きっぱなしログイン”を減らす |
| 検知ベースの強化 | サインインリスクが高い時のみ追加検証（一般にP2相当が必要） | 平常時の負担を抑えつつ異常時に強くする |
ただし、この段階はあくまで“暫定”です。共有アカウントは監査性の問題が残るため、最終的には「個人アカウント + 委任」へ寄せるロードマップを持つことをおすすめします。
避けるべき運用：MFAを共有する仕組みは作らない
「共有アカウントにMFAを付けたが、承認が回らない」→「コードを転送する」→「みんなで承認できるようにする」という流れは、現場で起きがちです。しかし、これはMFAの前提を壊すので避けてください。
- ワンタイムコードやプッシュ通知をチャット/メールで共有する
- SMSを転送して“全員が見られる電話番号”に集約する
- Webhookや外部サービスでコードを配布する
- 認証アプリのバックアップ情報を共通ストレージに保管する
これらは「第二要素が第三者にも届く」状態を作り、漏えい時の被害を拡大させます。どうしても共有アカウントが残るなら、MFA共有ではなくアクセス経路を限定する方向で考えるべきです。
段階的な移行プラン：現場を止めずに共有アカウントを減らす
共有アカウントの廃止は“技術”より“段取り”が重要です。おすすめの進め方を、実務で使える形に落とします。
| フェーズ | やること | 成果物 | よくある落とし穴 |
|---|---|---|---|
| 現状把握 | 共有アカウント一覧化（用途/利用者/端末/アプリ/必要な権限/代替可否） | 棚卸し表、優先度（廃止しやすい順） | “誰が使っているか不明”のアカウントが大量に出る |
| 暫定防御 | 共有アカウント用の条件付きアクセス（社内IP/準拠デバイス/レガシー遮断） | 共有アカウント専用ポリシー | 例外が増えすぎて管理不能になる |
| 置き換え | 共有メールボックス/SharePoint/グループ/アプリロール/PIMへ移行 | 委任設計、権限付与の標準手順 | 権限設計が属人化し、再び“裏共有ID”が生まれる |
| 個人MFA強制 | 条件付きアクセスで個人にMFA必須（段階適用、ヘルプ手順整備） | ヘルプデスク手順、ユーザー向け手順書 | サポート窓口がパンクし、抜け道を作りがち |
| 廃止・監視 | 共有アカウント停止、サインイン監視・アラート、定期棚卸し | 廃止計画、監視ルール | 停止後に“実は使われていた”が発覚 |
質問者の構成（社内ネットワークのみ許可）をより強くする改善案
すでに「共有アカウントをセキュリティグループに入れ、社内ネットワークからのみログインを許可する条件付きアクセス」で対応しているのは、暫定防御としてとても良い判断です。ここに次を追加すると、より“攻撃されにくい共有アカウント”に近づきます。
- 準拠デバイス必須：未管理端末からのログインを遮断する
- 対象アプリの最小化：必要なクラウドアプリだけ許可し、その他はブロックする
- サインイン頻度の見直し：共有端末での“ログインしっぱなし”を減らす
- レガシー認証のブロック：MFAを回避しやすい入口を閉じる
- 監視の仕組み：共有アカウントのサインインがあったら通知、異常パターンを早期に拾う
この改善は、共有アカウントをゼロにするまでの“安全なつなぎ”として機能します。
セキュリティグループとポリシーを「役割」で分けると運用が回りやすい
条件付きアクセスは、例外が増えるほど破綻しやすい仕組みです。共有アカウントを抱える環境では、ユーザーやアカウントをセキュリティグループで役割分担し、ポリシーを“薄く複数”に分けると管理しやすくなります。以下は一例です。
| グループ例 | 入れる対象 | 対応するポリシー例 |
|---|---|---|
| SG-Shared-Accounts | 暫定的に残る共有アカウント | 社内IP + 準拠デバイスのみ許可、レガシー認証をブロック、セッション短め |
| SG-MFA-Pilot | MFA必須化のパイロット対象ユーザー | 対象アプリを広めに取り、MFA必須を段階適用（問題が出たらすぐ切り戻せる） |
| SG-Privileged-Admins | 管理者ロールを持つ個人アカウント | より強い認証（可能ならフィッシング耐性の高い方法）、管理画面アクセスに限定した厳格ポリシー |
| SG-BreakGlass | 緊急用アカウント | 原則として条件付きアクセスから除外（ただし監視は強化） |
グループ名にプレフィックス（SG-）や用途を入れておくと、棚卸しや監査で説明しやすくなります。
公式ドキュメントで確認したいキーワード（Microsoft Learn）
運用設計を固めるときは、Microsoftの公式情報（Microsoft Learn）で用語をそのまま検索すると迷いにくくなります。以下は、共有アカウント問題に直結しやすいドキュメントのキーワードです（日本語ページが見つからない場合は英語名でも検索してください）。
- 条件付きアクセス（Conditional Access）の概要 / ポリシー作成
- 認証方法ポリシー（Authentication methods policy）
- 認証強度（Authentication strengths）
- サインインログ（Sign-in logs）と監査ログ（Audit logs）
- 共有メールボックス（Shared mailboxes）と委任（Full Access / Send As / Send on behalf）
- Privileged Identity Management（PIM）
- 緊急アクセスアカウント（Emergency access account / break glass account）
- Windows Hello for Business、FIDO2 security keys
「用語が正しくそろう」と、社内向けの手順書や運用ルールもぶれにくくなります。
よくある質問（現場で詰まりやすいポイント）
社内IP制限だけで十分では？
社内IP制限は効果がありますが、端末の持ち込みや社内からの不正、VPN経由、認証迂回（古いプロトコル）などのリスクが残ります。準拠デバイス必須、レガシー遮断、対象アプリ最小化を合わせて“面”で守るのがおすすめです。
MFA必須化でユーザー負担が増えそう
負担を下げるには、認証方式の見直しが効きます。たとえばWindows中心ならWindows Hello for Business、モバイル中心ならAuthenticatorの番号一致を標準にするなど、「強いけれど毎回面倒」ではなく「強いのに自然」な方式を選ぶのがコツです。
交代勤務で1台の端末を回す。どうしても“同じアカウント”が便利
便利に見える一方で、監査性と退職者対応が重くなります。端末が共用なら、個人サインイン＋自動サインアウト、キオスク化、アプリ側ロール管理など、端末運用を整えて“共有アカウントに頼らない”方向が長期的に楽になります。
運用チェックリスト：公開前に最低限見直したい項目
| チェック項目 | 目安 |
|---|---|
| 共有アカウントの一覧（用途・所有者・利用者）がある | 棚卸し表が最新で、責任者が明確 |
| 共有アカウント用の条件付きアクセスを分離している | 個人アカウント用ポリシーと混ざっていない |
| 社内IP制限＋準拠デバイス必須など複数の条件で囲えている | 単一条件に依存していない |
| レガシー認証をブロックしている | MFA回避の入口を閉じている |
| 共有メールボックス/SharePoint/グループ等への置き換え計画がある | 暫定運用で終わらないロードマップがある |
| サインインログの監視とアラートがある | 異常を早期に検知できる |
まとめ：共有アカウントにMFAを“頑張って”当てるより、設計を変えるほうが安全で楽
共有アカウントは、便利な一方で「本人性」「監査性」「退職者対応」に弱く、MFAの価値を最大化しにくい構造を持ちます。Microsoft Entra IDのベストプラクティスに寄せるなら、個人アカウントにMFAを必須化し、共有は委任で実現するのが王道です。
どうしても共有アカウントが残る場合も、MFA共有で破綻させるのではなく、条件付きアクセスで“使える場所・端末・アプリ”を絞り込み、暫定防御として安全側に倒しましょう。最終的に共有アカウントが減れば、セキュリティも運用も確実に軽くなります。
コメント