複数アカウント運用チームの2FA管理：認証アプリ・バックアップコード・アカウント引継ぎの分担

ECやSNSアカウントを複数運用するチームでは、メンバーの入れ替わりで2FAに詰まることがよくあります。退職する運用担当者の名義アカウントは十数個。半数で二段階認証が有効です。認証アプリは本人のスマホ。パスワードはその場で変えられても、ログイン時の6桁コードだけは、退職者のスマホが通知するのを待つしかありません。

問題の根っこは、2FAが個人利用では「設定したら放置できる安全スイッチ」だった点にあります。多アカウントチームでは、継続的な管理が必要な3種類の資産に変わります。認証アプリをどこに置くか、バックアップコードをどこに保管するか、人が離れるときどう引き継ぐか。どれか一つでも整っていないと、アカウントは認証の段階で止まります。最悪は外に締め出されます。

この記事では、管理の順序に沿って3つのことを説明します。まず認証アプリの配置方式を決める。次にバックアップコード。復旧層として管理します。最後に引継ぎ。決まった手順で進めます。各パートには、チームのルールにそのまま書ける具体策を添えます。

アカウントが増えると、2FAは安全スイッチから運用対象になる

2FAの仕組みは一言で説明できます。ログイン時にパスワードに加え、アカウント所有者だけが持つ第2の要素を示す、というものです。難しいのは導入ではなく、アカウントが増えた後の管理です。第2の要素が「自分のスマホ」からチーム内の一式のデバイスと材料に広がり、管理対象そのものが変わります。変化は次の3点に集中します。

• 数量の増幅：認証アプリに十数件のエントリがあるメンバーは、どれがどのアカウントか区別できません。再紐付けのとき1件ずつ試すことになります。
• 環境と認証の分離：指紋ブラウザはアカウントごとのログイン環境を固定し、Cookie・フィンガープリント・プロキシを独立させます。環境の揺れによるリスク検知は起きにくくなります。ただし二段階認証はプラットフォーム側のセキュリティ設定で、ブラウザの外で行われます。だから環境分離では代替できません。
• 人の流動：認証アプリは人についていく。退職がそのまま引継ぎ問題になります。

3つの変化は同じ結論を指します。2FAにはチームのプロセスが必要です。各メンバーが自分の紐付け場所を覚えていること。そこに頼ってはいけません。

まず決める認証アプリの配置：人に付けるか、アカウントに付けるか

主流の認証アプリが生成するのはワンタイムコードで、規格はIETFのRFC 6238、いわゆるTOTPです。紐付け後、アプリは時間に応じてコードを出し、30秒ごとに切り替わります。通信は一切不要です。この仕組みのおかげで、認証アプリは移設できます。別の端末で登録し直せば、コードはこれまでどおり生成されます。

認証方式の強度には差があります。米国のサイバーセキュリティ機関CISAはMFAガイダンスで、どんなMFAでもないよりはいいが、方式は等価ではない、と述べています。SMSコードが最も弱い。番号マッチング付きの認証アプリはより堅牢です。FIDO/WebAuthnのようなフィッシング耐性のある認証は、現在普及している選択肢の中で最強です。多アカウントチームは少なくともSMSを避けるべきです。機種変更やSIMの再発行で認証が止まります。SMS受け取りサービスの番号は、さらに関連性のシグナルを持ち込みます。

配置の考え方は2通りだけ。

• 人に付ける：認証アプリをメンバー個人のスマホに入れます。紐付けは速く済みます。日常のコード取得も楽です。ただし代償があります。認証要素が端末に縛られることです。スマホの紛失、機種変更、退職がそのまま認証の滞留につながります。

• アカウントに付ける：TOTPをチームのパスワード管理ツールや専用デバイスに集約します。コードはアカウント資産と一緒に動き、引き継げて監査もできます。代償もあります。日常のログインにコード取得の一手間が増えます。どちらが絶対的に正しいというより、違いは認証要素を誰が保持するかにあります。

配置方式はアカウントの重要度で決められます。

1. 売上を支える中核アカウント：アカウントに付ける。複数人で使うため、認証要素の引き継ぎが必須で、バックアップコードも別途管理します。
2. 中長尾のアカウント：人に付けても構いません。引継ぎ時に再紐付けを一度挟み、空白期間を短く抑えます。
3. FIDO対応のプラットフォーム：ハードウェアキーかPasskeyを優先し、フィッシング耐性を最大限使います。条件が整わなければ認証アプリに戻します。

認証アプリやスマホを替える前に、プラットフォームで旧い紐付けを解除できるか確認します。そのうえで新しい紐付けを行います。解除に審査期間を設けているプラットフォームもあります。その期間中は新旧どちらの認証アプリも使えません。こうしたプラットフォームの再紐付けは、引継ぎ当日ではなく、引継ぎの期間に入る前に段取りします。

バックアップコードは復旧層：一度生成し、失効まで管理する

バックアップコードとは、プラットフォームが2FA有効化の際に一度だけ発行する静的な復旧コードの組です。認証アプリの紛失や端末の破損時に、これが唯一の入り口になります。NISTのデジタルアイデンティティガイドSP 800-63Bは、この種の「事前発行・1回使用・使用後失効」のクレデンシャルをlook-up secretsという別カテゴリに分類しています。動的なコードとは別物です。普段は使いません。問題が起きたときの唯一の復旧経路です。管理目標は2つ。必要なときに見つかること。漏れても持って行かれないこと。

保管場所の選択は、この表に沿って並べてみてください。

表の並びは日常の使用頻度順です。中核アカウントは2層の併用を推奨します。運用の規律は保管に合わせます。バックアップコードはアカウントのパスワードと別の場所に置きます。こうすれば1件の漏えいで2層まとめて失わずに済みます。1枚使うたびに、プラットフォームで一式を再生成します。新しい副本で古い副本を置き換えます。メンバーの異動時は、退職者が持っていた副本を、回収できたかどうかにかかわらず漏えい扱いにして再生成します。

チーム運用では、もう一つ位置づけの問題が残ります。どのアカウントがどの認証方式と紐付いているか、バックアップコードがどの副本にあるか。MostMateの環境メモは、こうした設定の目印を記録できます。アカウントの対応関係、認証方式の種類、バックアップコードの保管場所は、環境の行に書いておきます。メンバーは環境リストを開いた瞬間に照合できます。コード本体はメモに入れません。メモを行き来するのは位置情報であって、クレデンシャルではありません。

引継ぎは3段階で：先に再紐付け、次に復旧材料、最後に環境

引継ぎが詰まるのは、たいてい順序のせいです。先にメンバーのログイン権限を回収すると、後任はアカウントに入れません。コードがまだ旧スマホの中にあるからです。あるいはアカウントが2週間放置されることもあります。その間ずっと、退職者がリモートでコードを提供し続けます。どちらもコストの出所は順序です。正しい順序は、2FAの移管を権限回収より先に発生させること：

1. プラットフォーム側の再紐付け：アカウントのセキュリティ設定で、2FAを後任者の認証アプリに付け替えます。その場で新しいコードが通ることを一度確認します。次の段階に進みます。

2. 復旧材料の引き継ぎ：バックアップコードの副本を対面で手渡した後、プラットフォームで一式を再生成します。新しい副本はチームの保管先へ。古い副本は失効させます。

3. 環境側の引き継ぎ：アカウントに通常どおりログインできることを確認してから、環境・プロキシ・設定を新しい担当者に引き継ぎます。環境だけ先に来て、アカウントに入れない空白期間を避けるためです。

この3段階で、認証要素の移管が完了です。

環境側の操作は、MostMateに入口が用意されています。MostMateは環境を単位とする指紋ブラウザです。アカウントごとに1セット、環境同士はデータを持ち込みません。チームで使う場合、環境は環境グループを通じてメンバーに権限付与します。メンバーリストでは、各メンバーに付与された環境グループ、メンバーとしての身分、最終ログイン時刻などが確認できます。後任に足りない権限がひと目で分かります。製品紹介ページでは、この分離と協業の構造をより詳しく説明しています。

引継ぎの記録はメンバーログに残ります。ログインログで、退職者が最近どの端末からログインしたかを確認します。環境の共有記録と移転記録で、引継ぎの前後の経手人を確定します。各記録には操作時刻、操作種別、メンバー、IP情報が付きます。問題が起きたときに遡れます。

2FAの状態そのものは、各プラットフォームのセキュリティ設定の中にあります。MostMateが扱うのは環境とメンバーの協業です。プラットフォームアカウントの認証アプリの代行管理ではありません。退職時の棚卸しでは、退職者にプラットフォーム上で付け替えを完了させます。後任者が新しい認証アプリで一度ログインして有効を確認します。その確認を引継ぎチェックリストに記録します。1アカウントずつのログイン確認は省けません。ただし移管の当日に済ませるほうが、後から問題を追跡するよりずっと楽です。

環境側の権限回収には、グループとメンバー状態の2つの操作がさらにあります。チェックリストとログの使い方は、多アカウントセキュリティ管理：グループ、ログ、引継ぎ記録で手順通りに整理されています。引継ぎ前に一度通して読めば、抜け漏れを避けられます。

よくある質問

認証アプリを紛失した場合、アカウントは復旧できますか？

できます。条件はバックアップコードを手元に持っていることです。ログイン時に「コードを提供できない」を選びます。有効なバックアップコードをどれか1つ入力すれば入れます。入ったら最初にやること。コード一式の再生成と、新しい認証アプリへの付け替えです。バックアップコードも失った場合は、プラットフォームへの本人確認の申立てのみが残ります。復旧までの期間はコードでの復旧よりはるかに長くなります。アカウント盗難とデータ損失への備え方は、アカウント資産管理の記事の進め方を参考にしてください。

バックアップコードが少なくなってきたらどうしますか？

1枚使うたびに一式を再生成します。再生成の操作で旧コードは失効します。新しい副本はチームの保管先に同期します。古い印刷物やスクリーンショットはまとめて破棄します。最後の2枚まで使い切ってから対処すると、復旧の窓口は2枚分しか残りません。

メンバーの退職時、2FAの再紐付けと権限回収、どちらを先に？

先に再紐付け。後に権限回収です。環境とログイン権限だけ回収すると、アカウントは二段階認証の段階で止まります。結局は退職者がコードを提供するはめになります。プラットフォーム側の付け替えを先に済ませれば、その後の回収作業に退職者の協力は不要になります。

指紋ブラウザと2FAはどんな関係ですか？

2つの層は受け持ち範囲が違います。2FAは「ログインした人がアカウント所有者か」を検証します。指紋ブラウザは「ログインがどんな環境で行われるか」を管理します。環境分離により、アカウントごとのCookie・フィンガープリント・プロキシは独立して安定します。リスク検知による認証の発生を減らせます。ただし二段階認証を通せるかはプラットフォーム側のセキュリティ設定次第です。2層はセットで段取りしてください。

まとめ

2FA管理は分解すれば3つの仕事です。認証アプリの人付けかアカウント付けかを決める。バックアップコードを復旧層として失効まで管理する。引継ぎは再紐付け、移管、環境移行の固定順序で進める。どれも重くはありません。難しいのは、アカウントが増えた後も誰かがチェックリストどおりに動き続けることです。

この仕組みをまだ持っていないチームは、2アカウントから試せます。片方は認証要素をチームの保管先に移します。もう片方は個人のままにします。次に人が入れ替わるとき、2通りの引継ぎを比べれば、プロセスが使えるかどうか一度で分かります。

環境側の分離とチーム設定は、MostMateがすでに用意しています。MostMateをダウンロードして最初の環境グループを作り、アカウントの帰属と認証要素の保管先を一緒に固定しましょう。