MFAでAWSから締め出された話：ログイン不能の危機から復旧した教訓
はじめに
AWSを利用する上でセキュリティを高めるために欠かせないMFAですが、一歩間違えると自分自身を完全に締め出す「凶器」になります。
先日、私は MFAデバイスの紛失 によって、AWS環境へのログイン手段をすべて失うという、いわゆる 詰んだ 状態に陥りました。本記事では、その復旧の経緯を共有しつつ、同じ目に遭わないための予防・復旧・再発防止のハンドブックとして整理します。
MFAは「持っているもの（デバイス）」で本人を証明する仕組みなので、推奨されるほどセキュリティは上がります。しかしここに逆説があります。セキュリティが高いほど、バックアップ戦略がないと自分自身を締め出すリスクも逆に高まる のです。私が痛感したのは、まさにこの点でした。
この記事で学べること
- MFAデバイスを失ったときに何が起きるか（実体験ベース）
- AWSサポートを使った復旧の流れと、自力復旧の限界
- MFAの種類ごとのリスクと、ツイン構成での役割
- 締め出しを防ぐための具体的な予防策とチェックリスト
記事は 予防 → 復旧 → 再発防止 の流れで構成しています。まずは私が実際にハマった「復旧」の話から見ていきましょう。
Pattern 1：認証デバイスの紛失・故障でログイン不能に陥った状況
私の環境では、以下の構成で運用していました。
- AWS SSO （IAM Identity Center）を利用してログイン
- セキュリティのため MFA （多要素認証）を必須化
- 認証用デバイスは、自分のスマートフォン1台のみを登録
ある日、この唯一の認証デバイスであるスマホでアプリが正常に動作しなくなり、ログインコードを取得できなくなってしまいました。
rootアカウントも全滅
通常、SSOで入れなくなっても root アカウントがあれば何とかなります。しかし、万全を期して root アカウントにも MFA を設定しており、あろうことか 同じスマホ を登録していたため、すべての入り口が塞がってしまいました。
Pattern 2：電話認証トラブルで自力復旧の限界に直面
自力で復旧するため、rootアカウントのログイン画面から 「 MFAのトラブルシューティング 」 を試みました。
通常、メール認証と電話番号認証の2段階をクリアすればMFAを一時的にバイパスできます。メール認証は問題なく通過しましたが、次の 電話番号認証 でトラブルが発生しました。
キーパッドが検知されない
AWSから自動音声の電話がかかってきて、画面に表示された番号をスマホのキーパッドで入力するよう求められます。しかし、なぜか入力した数字がAWS側に全く検知されませんでした。何度試してもタイムアウトになり、自力での復旧は不可能になりました。
AWSサポートによる救済
最終的に、AWSの 「 お問い合わせフォーム 」 から、サインインできない旨を伝えてサポートへ連絡しました。
その後、AWSの担当者から直接電話がかかってきました。通話の中で本人確認などのプロセスを経て、ようやく手動で MFAの解除 を行ってもらうことができました。
担当者の方との直接の通話がなければ、今もログインできないままだったかもしれません。
なぜ「2台目」が決定的に重要なのか
ここから先は再発防止の話です。私が締め出されたのは、root も SSO も認証を 同じスマホ1台 に集約していたからでした。1台目が動かなくなった瞬間、すべての入り口が同時に塞がったのです。
逆に言えば、2台目のMFAが登録されていれば、1台目が壊れても2台目でログインし、落ち着いて1台目を再登録できます。サポートへの問い合わせも、半日がかりの電話認証も不要でした。「2台目があるかどうか」だけで、被害の重さが天と地ほど変わる というのが、今回いちばん身に沁みた教訓です。だからこそ、まず最初にやるべきは予備デバイスの登録です。
【30秒で完了】今すぐ予備のMFAを登録する手順
この記事を読んでいる皆さんは、私のような目に遭う前に、今すぐ以下の手順で 「 2台目のMFA 」 を登録してください。
- AWSコンソールの右上にある 「 ユーザー名 」 をクリック
- 「 セキュリティ認証情報 」 を選択
- 「 多要素認証（MFA） 」 セクションで 「 MFAデバイスの割り当て 」 をクリック
- 2台目のスマホや、ハードウェアセキュリティキー（YubiKey等）を登録する
※rootアカウント、SSOユーザーの両方でこの設定を確認することをお勧めします。
MFAの種類と特徴を理解する
今回の反省を踏まえて、AWSで使えるMFAの種類を整理しておきます。
推奨度と「ツイン構成での役割」は、後述する私の実構成（root に YubiKey + 仮想MFA を併用）から導いた所見です。
| MFAの種類 | 代表例 | メリット | デメリット | 推奨度 | ツイン構成での役割 |
|---|---|---|---|---|---|
| 仮想MFAデバイス | Google Authenticator, Authy, Microsoft Authenticator | 無料で手軽に導入できる | デバイス故障・紛失でコードを失う | ◎（導入の最初の1つに最適） | 普段使いのメイン認証 |
| FIDO2セキュリティキー | YubiKey, Titan Security Key | フィッシング耐性が高い。デバイスに依存しない | 購入コストがかかる（数千円〜） | ◎（rootの保険として最有力） | デバイス故障時のバックアップ |
| ハードウェアTOTPトークン | Gemalto等のトークンデバイス | スマホ不要で運用可能 | コストが高く、入手に時間がかかる | △（個人なら優先度低） | スマホを持てない運用時の代替 |
個人アカウントでのおすすめ構成
重要なのは、異なるデバイスにMFAを分散させること です。同じスマホに全てを集約していた過去の私の構成が、まさに今回の障害の根本原因でした。その反省を踏まえ、運用スタイル別に2つのパターンを提案します。
パターンA：YubiKeyを使う構成（推奨）
これは私が現在実際に採用している構成です。物理キーを1つ持つだけで、スマホが壊れても締め出されません。
- rootアカウント: YubiKey（物理キー） + 仮想MFA（スマホ）の 2つを登録
- IAMユーザー / SSO: 仮想MFA（メインスマホ） + 仮想MFA（タブレットまたは家族のスマホ）
パターンB：スマホのみで運用する場合の必須チェック
「物理キーは持たず、スマホだけで運用したい」という方もいるはずです。私はこの構成で締め出された側なので、もしこの形を選ぶなら、最低限これだけは満たしてほしいという必須チェックを推奨として挙げます。
- メインスマホとは 別の端末（古いスマホ、タブレット、家族のスマホ等）にも仮想MFAを登録する
- 2台の端末は 同じカバンに入れない（同時紛失・盗難を避ける）
- root の登録メールと電話番号に確実にアクセスできるか、定期的に確認する
ポイントは、パターンAでもBでも 1つの物理デバイスが死んでも入り口が残ること です。これが担保されていない構成は、過去の私と同じ事故予備軍だと考えてください。
組織アカウントで気をつけるべきこと
個人利用だけでなく、チームや組織でAWSを使っている場合は、さらに注意が必要です。
- rootアカウントの認証情報は、複数の管理者がアクセスできる安全な場所に保管する（例：パスワードマネージャーの共有Vault）
- 退職・異動時のMFA引き継ぎ手順を事前に決めておく
- AWS Organizationsを使っている場合、管理アカウントのrootは特に厳重に保護する（全アカウントに影響するため）
再発防止チェックリスト
最後に、同じトラブルを繰り返さないためのチェックリストをまとめます。ログインできている今のうちに確認してみてください。
- rootアカウントに 2つ以上 のMFAデバイスを登録しているか
- SSO / IAMユーザーにも 予備のMFA を設定しているか
- MFAデバイスは 物理的に別の場所 に保管されているか（同じカバンに入れていないか）
- rootアカウントの メールアドレス に確実にアクセスできるか
- rootアカウントに登録した 電話番号 は現在も有効か
- AWSサポートへの問い合わせ方法を把握しているか
まとめ
MFAは非常に強力な仕組みです。だからこそ、バックアップ手段の確保は 必須の運用項目 だと痛感しました。
特に重要なポイントは以下の3つです。
- MFAデバイスは必ず2つ以上登録する（rootアカウントは特に重要）
- 異なる種類・異なるデバイスに分散させる（同じスマホに集約しない）
- 定期的にMFA設定を見直す習慣を作る（デバイス買い替え時は特に注意）
「自分は大丈夫」 と思わず、ログインできている今のうちに、設定を見直してみてください。
なお、MFAはあくまでサインイン時の本人確認の話です。日々の操作で長期アクセスキーを使い回すのではなく、CLI認証は IAM Identity Center 経由の一時的な認証情報を使うことをおすすめします。認証情報の保管・取り扱いについては、別記事のAWSのシークレット管理の考え方も参考にしてください。