📱 スマホが壊れた！MFAが使えない！どうする？
IAMコンソールは「本人が正常な状態で操作する前提」の道具です。
MFAデバイスが壊れた・紛失した・機種変更した...
こんな時、
本人はコンソールにログインすらできません
。
この緊急事態を救えるのは
「管理者ロールによるAPI直接操作」
だけ！
なぜそうなのか、どう対処すべきか、完全解説します🔧
🏢 オフィスビルのセキュリティで考えよう
正面玄関（コンソール）
📋 入館の流れ：
1️⃣ 社員証をかざす（ID/パスワード）
2️⃣ 指紋認証する（MFA）
3️⃣ ゲートが開く（ログイン成功）
💡 ポイント：
「社員証」と「指紋」の 両方 がないと入れない！
1️⃣ 社員証をかざす（ID/パスワード）
2️⃣ 指紋認証する（MFA）
3️⃣ ゲートが開く（ログイン成功）
💡 ポイント：
「社員証」と「指紋」の 両方 がないと入れない！
❌ 指紋認証機が壊れたら？
「社員証はある」「本人である」
でも 指紋認証できないから入れない ！
正面玄関からは入る方法がない...
「社員証はある」「本人である」
でも 指紋認証できないから入れない ！
正面玄関からは入る方法がない...
セキュリティ管理室（管理者API）
🛡️ 管理者の特別な権限：
セキュリティ管理者は マスターキー を持っている。
社員の指紋認証を リセット できる。
ゲートを 直接操作 できる。
セキュリティ管理者は マスターキー を持っている。
社員の指紋認証を リセット できる。
ゲートを 直接操作 できる。
✅ 緊急時の対応：
1️⃣ 本人確認を別の方法で行う
2️⃣ 管理者が指紋データを 削除
3️⃣ 新しい指紋を 再登録 させる
正面玄関を通らずに解決！
1️⃣ 本人確認を別の方法で行う
2️⃣ 管理者が指紋データを 削除
3️⃣ 新しい指紋を 再登録 させる
正面玄関を通らずに解決！
🖥️ IAMコンソールの「暗黙の前提」
📋
コンソールが想定している「正常な状態」
AWSマネジメントコンソールは、以下の条件が
すべて満たされている前提
で設計されています：
- ID/パスワードを覚えている （または安全に保管している）
- MFAデバイスが手元にある （スマホ、ハードウェアトークン等）
- MFAデバイスが正常に動作する （バッテリー切れ、故障なし）
- MFAアプリにアクセスできる （機種変更、アプリ削除なし）
- 時刻同期が正しい （TOTPは時刻ベース）
⚠️
前提が崩れると「詰む」理由
MFAが有効な場合、コンソールログインのフローは：
MFAコードを入力できなければ、
ログインプロセスはそこで停止
します。
コンソールには「MFAをスキップする」ボタンはありません。
なぜなら、それがあったらMFAの意味がなくなるからです。
→ つまり「正面玄関」からは絶対に入れない！
ID/パスワード入力 → MFAコード入力 → ログイン成功
コンソールには「MFAをスキップする」ボタンはありません。
なぜなら、それがあったらMFAの意味がなくなるからです。
→ つまり「正面玄関」からは絶対に入れない！
😱 MFAが使えなくなるシナリオ
📱 よくある「詰み」パターン
1
スマホの紛失・故障・盗難
MFAアプリ（Google Authenticator、Authy等）が入ったスマホがなくなった。
または画面が割れて操作できない、水没して起動しない...
または画面が割れて操作できない、水没して起動しない...
2
機種変更でのデータ移行忘れ
新しいスマホにMFAアプリのデータを移行せずに、古いスマホを初期化。
最も多いパターン 。LINEやゲームは移行したのに、MFAを忘れがち。
最も多いパターン 。LINEやゲームは移行したのに、MFAを忘れがち。
3
MFAアプリの誤削除・再インストール
ストレージ整理でアプリを消してしまった。
再インストールしても、登録情報は復元されない。
再インストールしても、登録情報は復元されない。
4
ハードウェアトークンの故障・電池切れ
YubiKeyやハードウェアMFAデバイスが壊れた。
電池式トークンの電池が切れて表示されなくなった。
電池式トークンの電池が切れて表示されなくなった。
💀
結果：コンソールにログインできない！
パスワードは正しいのに、MFAコードが入力できないため
自分のアカウントなのに一切操作できない状態 に陥る。
自分のアカウントなのに一切操作できない状態 に陥る。
🔄 コンソール vs API - 緊急時の違い
❌ コンソール経由（本人）- 不可能
👤 本人
(MFA壊れた)
(MFA壊れた)
→
🔐 MFA認証
(入力不可)
(入力不可)
✖️
🖥️ コンソール
(到達不可)
(到達不可)
✅ API経由（管理者）- 可能
👑 管理者
(正常なMFA)
(正常なMFA)
→
⌨️ AWS CLI
API直接操作
API直接操作
✓
👤 本人のMFA
削除・リセット
削除・リセット
🛠️ 管理者による救済方法
✅ API直接操作でMFAをリセットする
管理者ロールでMFAを無効化
IAM管理権限を持つ別のユーザー/ロールが実行
1
管理者が自分のアカウントでAWS CLIにログイン
管理者は自分のMFAが正常なので、通常通りアクセスできる
管理者は自分のMFAが正常なので、通常通りアクセスできる
2
対象ユーザーのMFAデバイスを確認
aws iam list-mfa-devices --user-name <対象ユーザー名>
3
MFAデバイスを無効化（削除）
aws iam deactivate-mfa-device --user-name <対象ユーザー名> --serial-number <MFAのARN>
4
本人がコンソールにログイン可能に
MFAが無効化されたので、パスワードのみでログイン可能
MFAが無効化されたので、パスワードのみでログイン可能
5
本人が新しいMFAデバイスを登録
コンソールから新しいMFAを設定して、セキュリティを回復
コンソールから新しいMFAを設定して、セキュリティを回復
# 管理者が実行するコマンド
# 1. 対象ユーザーのMFAデバイスを確認
aws
iam list-mfa-devices
--user-name
"tanaka"
# 出力例:
# {
# "MFADevices": [
# {
# "UserName": "tanaka",
# "SerialNumber": "arn:aws:iam::123456789012:mfa/tanaka",
# "EnableDate": "2024-01-15T10:30:00Z"
# }
# ]
# }
# 2. MFAデバイスを無効化
aws
iam deactivate-mfa-device \
--user-name
"tanaka"
\
--serial-number
"arn:aws:iam::123456789012:mfa/tanaka"
# 3. 仮想MFAデバイスも削除（必要な場合）
aws
iam delete-virtual-mfa-device \
--serial-number
"arn:aws:iam::123456789012:mfa/tanaka"
# これで tanaka さんはパスワードのみでログイン可能に！
rootユーザーのMFA救済（最終手段）
AWSサポートへの連絡が必要なケース
⚠️ rootユーザーのMFAが使えなくなった場合
rootユーザーは「管理者」が存在しない最上位のアカウント。
API操作でも rootのMFAは他から削除できない ため、
AWSサポートに連絡 して本人確認の上、リセットしてもらう必要があります。
rootユーザーは「管理者」が存在しない最上位のアカウント。
API操作でも rootのMFAは他から削除できない ため、
AWSサポートに連絡 して本人確認の上、リセットしてもらう必要があります。
1
AWSサポートに連絡
電話またはWebフォームから「MFAリセット」をリクエスト
電話またはWebフォームから「MFAリセット」をリクエスト
2
本人確認
アカウントに登録されたメールアドレス、電話番号、
請求先住所などで本人確認を実施
アカウントに登録されたメールアドレス、電話番号、
請求先住所などで本人確認を実施
3
MFAリセット
確認完了後、AWSがMFAを無効化
確認完了後、AWSがMFAを無効化
4
再設定
ログイン後、すぐに新しいMFAを設定
ログイン後、すぐに新しいMFAを設定
📊 MFA緊急時の対応方法比較
| 状況 | コンソール | API/CLI | 対応者 |
|---|---|---|---|
| IAMユーザーのMFA喪失 | ❌ 本人ログイン不可 | ✅ 管理者が無効化可能 | IAM管理者 |
| rootユーザーのMFA喪失 | ❌ ログイン不可 | ❌ API操作も不可 | AWSサポート |
| IAMロールのMFA条件 | ❌ AssumeRole不可 | ✅ 管理者がポリシー変更可能 | IAM管理者 |
|
一時的なMFA不具合
（時刻ズレ等） |
✅ 前後のコードで試行 | ✅ 再同期コマンド実行 | 本人 or 管理者 |
| パスワード忘れ + MFA喪失 | ❌ 完全にログイン不可 | ✅ 管理者がPW＆MFAリセット | IAM管理者 |
📋 緊急時に備える事前準備
🛡️ 「詰まない」ための予防策
管理者ロールを必ず用意
「自分以外にMFAを解除できる人」を必ず確保！
• IAM管理権限を持つ管理者ユーザー/ロールを作成
• 複数人で管理者権限を持つ（1人だけだと危険）
• 管理者もMFAを設定し、お互いに救済できる体制に
🚨 最重要
• IAM管理権限を持つ管理者ユーザー/ロールを作成
• 複数人で管理者権限を持つ（1人だけだと危険）
• 管理者もMFAを設定し、お互いに救済できる体制に
MFAバックアップコードの保存
仮想MFA設定時のQRコード/シークレットキーを保存
• 設定時にシークレットキーをコピーして安全に保管
• 複数のデバイスに同じMFAを登録可能
• パスワードマネージャーや金庫に保管
⚠️ 重要
• 設定時にシークレットキーをコピーして安全に保管
• 複数のデバイスに同じMFAを登録可能
• パスワードマネージャーや金庫に保管
複数のMFAデバイスを登録
IAMユーザーは最大8つのMFAを登録可能
• メインのスマホ + バックアップ用スマホ
• 仮想MFA + ハードウェアトークン
• 1つが壊れても別のデバイスでログイン可能
⚠️ 重要
• メインのスマホ + バックアップ用スマホ
• 仮想MFA + ハードウェアトークン
• 1つが壊れても別のデバイスでログイン可能
rootアカウント情報の厳重管理
rootは最後の砦！情報を分散管理
• rootのパスワードを安全に保管
• MFAのバックアップコードを別の場所に保管
• アカウント登録のメール・電話にアクセス可能か確認
🚨 最重要
• rootのパスワードを安全に保管
• MFAのバックアップコードを別の場所に保管
• アカウント登録のメール・電話にアクセス可能か確認
緊急時手順書の作成
「誰が」「何を」「どうやって」を明文化
• MFA無効化の手順とコマンド
• 管理者の連絡先リスト
• AWSサポートへの連絡方法
• 承認フロー（勝手にリセットされない仕組み）
📋 推奨
• MFA無効化の手順とコマンド
• 管理者の連絡先リスト
• AWSサポートへの連絡方法
• 承認フロー（勝手にリセットされない仕組み）
定期的な動作確認
いざという時に動かないことがないように
• 管理者アカウントで定期的にログイン確認
• MFAリセット手順の訓練
• バックアップデバイスの動作確認
• 緊急連絡先の有効性確認
📋 推奨
• 管理者アカウントで定期的にログイン確認
• MFAリセット手順の訓練
• バックアップデバイスの動作確認
• 緊急連絡先の有効性確認
⚠️
よくある「最悪のパターン」を避けよう
❌ パターン1：管理者が1人だけで、その人のMFAが壊れた
→ 誰もMFAをリセットできない！AWSサポート頼みに...
❌ パターン2：rootアカウントを日常的に使っていて、MFAが壊れた
→ 最上位アカウントなので、誰もリセットできない
❌ パターン3：機種変更のたびにMFA再設定を忘れる
→ 毎回「緊急事態」になり、管理者に迷惑をかける
❌ パターン4：「自分は大丈夫」とバックアップを取らない
→ スマホは壊れるもの。紛失するもの。水没するもの。
→ 誰もMFAをリセットできない！AWSサポート頼みに...
❌ パターン2：rootアカウントを日常的に使っていて、MFAが壊れた
→ 最上位アカウントなので、誰もリセットできない
❌ パターン3：機種変更のたびにMFA再設定を忘れる
→ 毎回「緊急事態」になり、管理者に迷惑をかける
❌ パターン4：「自分は大丈夫」とバックアップを取らない
→ スマホは壊れるもの。紛失するもの。水没するもの。
✅
推奨される運用体制
1. 「3人以上の管理者」体制を構築
誰か1人のMFAが壊れても、他の2人で救済できる。全員が同時にMFAを失う確率は極めて低い。
2. rootアカウントは「緊急用」として封印
日常業務はIAMユーザー/ロールで行い、rootは本当の緊急時のみ使用。MFAバックアップコードは金庫等で厳重管理。
3. API/CLIでの操作に慣れておく
緊急時に「CLIの使い方がわからない」では救済できない。日常的にCLIを使い、操作に慣れておく。
4. 緊急時手順を文書化し、定期的に訓練
「MFAリセット訓練」を年に1回は実施。手順書の有効性を確認し、新メンバーにも周知。
誰か1人のMFAが壊れても、他の2人で救済できる。全員が同時にMFAを失う確率は極めて低い。
2. rootアカウントは「緊急用」として封印
日常業務はIAMユーザー/ロールで行い、rootは本当の緊急時のみ使用。MFAバックアップコードは金庫等で厳重管理。
3. API/CLIでの操作に慣れておく
緊急時に「CLIの使い方がわからない」では救済できない。日常的にCLIを使い、操作に慣れておく。
4. 緊急時手順を文書化し、定期的に訓練
「MFAリセット訓練」を年に1回は実施。手順書の有効性を確認し、新メンバーにも周知。
💡
知っておくと役立つTips
1. 仮想MFAは「複数デバイス」に同時登録できる：
設定時のQRコード（シークレットキー）を複数のスマホでスキャンすれば、同じコードが複数デバイスで生成される。
2. ハードウェアMFAの電池寿命に注意：
ハードウェアトークンは3〜5年で電池切れ。事前に新しいものを購入して切り替え準備を。
3. 時刻ズレはMFAの大敵：
TOTPは時刻ベースで計算。スマホの時刻が1分以上ずれていると認証失敗することがある。
解決策：スマホの「自動時刻設定」をONに。CLI:
4. AWS Organizationsを使っているなら：
Organizations管理アカウントから、メンバーアカウントのIAMを操作可能。
ただし、SCP（サービスコントロールポリシー）で制限されている場合があるので事前確認を。
5. パスワードマネージャーのTOTP機能も活用：
1Password、Bitwarden等のパスワードマネージャーはTOTP対応。スマホ以外のバックアップになる。
設定時のQRコード（シークレットキー）を複数のスマホでスキャンすれば、同じコードが複数デバイスで生成される。
2. ハードウェアMFAの電池寿命に注意：
ハードウェアトークンは3〜5年で電池切れ。事前に新しいものを購入して切り替え準備を。
3. 時刻ズレはMFAの大敵：
TOTPは時刻ベースで計算。スマホの時刻が1分以上ずれていると認証失敗することがある。
解決策：スマホの「自動時刻設定」をONに。CLI:
aws iam resync-mfa-device
4. AWS Organizationsを使っているなら：
Organizations管理アカウントから、メンバーアカウントのIAMを操作可能。
ただし、SCP（サービスコントロールポリシー）で制限されている場合があるので事前確認を。
5. パスワードマネージャーのTOTP機能も活用：
1Password、Bitwarden等のパスワードマネージャーはTOTP対応。スマホ以外のバックアップになる。
❓ よくある質問
🙋
Q. 管理者もMFAを設定していますが、管理者のMFAが壊れたらどうなりますか？
A.
だから「複数の管理者」が重要なのです！
管理者Aが壊れた → 管理者BがAのMFAをリセット
管理者Bが壊れた → 管理者AがBのMFAをリセット
最低でも2人、理想は3人以上 の管理者を用意しましょう。
管理者Aが壊れた → 管理者BがAのMFAをリセット
管理者Bが壊れた → 管理者AがBのMFAをリセット
最低でも2人、理想は3人以上 の管理者を用意しましょう。
🙋
Q. MFAを無効化するのは、セキュリティ上問題ありませんか？
A.
一時的な無効化は必要悪です。重要なのは：
• 本人確認を必ず行う （社内承認フローを経由）
• 無効化後、速やかに再設定させる
• CloudTrailでログを記録・監視 （誰がいつ無効化したか）
勝手にMFAを無効化されないよう、承認プロセスを整備しましょう。
• 本人確認を必ず行う （社内承認フローを経由）
• 無効化後、速やかに再設定させる
• CloudTrailでログを記録・監視 （誰がいつ無効化したか）
勝手にMFAを無効化されないよう、承認プロセスを整備しましょう。
🙋
Q. なぜコンソールには「MFAスキップ」機能がないのですか？
A.
あったらMFAの意味がなくなるからです。
MFAは「本人であることの二重確認」です。
「パスワードは盗まれたけどMFAデバイスは手元にある」ケースで攻撃を防ぐためのもの。
もしスキップ機能があったら、パスワードが漏洩した時点でアカウントが乗っ取られます。
正面玄関の厳格さがセキュリティを守っている のです。
MFAは「本人であることの二重確認」です。
「パスワードは盗まれたけどMFAデバイスは手元にある」ケースで攻撃を防ぐためのもの。
もしスキップ機能があったら、パスワードが漏洩した時点でアカウントが乗っ取られます。
正面玄関の厳格さがセキュリティを守っている のです。
🙋
Q. 一人会社（個人事業主）で管理者を複数用意できません。どうすれば？
A.
以下の対策を組み合わせてください：
• 複数のMFAデバイスを登録 （最大8つまで可能）
• MFAシークレットキーをオフラインで保管 （紙に印刷して金庫へ）
• rootアカウントのMFAバックアップコードを別保管
• AWSサポートプランに加入 （最悪の場合の救済ルートを確保）
• 複数のMFAデバイスを登録 （最大8つまで可能）
• MFAシークレットキーをオフラインで保管 （紙に印刷して金庫へ）
• rootアカウントのMFAバックアップコードを別保管
• AWSサポートプランに加入 （最悪の場合の救済ルートを確保）
🙋
Q. SSO（IAM Identity Center）を使っている場合は？
A.
SSO管理者がIdentity Center側でMFAをリセットできます。
SSO環境では、MFA設定はIAM Identity Center（旧AWS SSO）側で管理されます。
Identity Center管理者が：
• ユーザーのMFAデバイスを削除
• 次回ログイン時にMFA再登録を強制
という対応が可能です。
SSO環境では、MFA設定はIAM Identity Center（旧AWS SSO）側で管理されます。
Identity Center管理者が：
• ユーザーのMFAデバイスを削除
• 次回ログイン時にMFA再登録を強制
という対応が可能です。
🎓 まとめ
🏢 正面玄関（コンソール）vs 管理者入口（API）
コンソールは「本人が正常な状態」でないと使えない
MFA緊急時は「管理者のAPI直接操作」でしか救えない
🚪
コンソール
MFAが必須
壊れたら
入れない
⌨️
API/CLI
管理者が
他人のMFAを
直接操作可能
👑
管理者
複数人で
お互いを
救える体制に
🛡️ 今日からできる3つのアクション：
1️⃣
管理者を複数人確保する
（最低2人、理想は3人以上）
2️⃣
MFAバックアップを取る
（複数デバイス登録 or シークレットキー保管）
3️⃣
緊急時手順を文書化する
（誰が・何を・どうやって）
🚨
「いつか」ではなく「今日」備えよう！
スマホは壊れる。紛失する。水没する。
その日が来てからでは遅い。
管理者とバックアップで「詰まない」体制を構築しよう！
🔐