ルートアクセス管理から「パスワード回復を許可」してAWSアカウントのルートユーザーの認証情報を回復してみた

ルートアクセス管理から「パスワード回復を許可」してAWSアカウントのルートユーザーの認証情報を回復してみた

AWS Organizations の「ルートアクセス管理」を使って、封印されたルートユーザーのパスワード回復を許可し、パスワードを設定する手順を紹介します。セキュリティベストプラクティスから外れる作業ですが、やんごとなき理由がある場合のみお使いください。
2026.07.31

こんにちは、臼田です。

みなさん、ルートユーザーを封印してますか?(挨拶

今回はどうしてもやんごとなき理由により封印されているルートユーザーを解放する必要がある際の、ルートアクセス管理からルートユーザーのパスワードを作成する手順を紹介します。

概要

AWSアカウントを作成する際に、最初に作成するユーザーがルートユーザーです(AWSアカウント単体で作成した際)。あるいは、AWS Organizations環境では「アカウント所有者の E メールアドレス」としてルートユーザーとなるメールアドレスを登録します。

ルートユーザーは非常に権限が強く制御が基本的にできないため、「MFAを設定して封印して使わないこと」が長いことベストプラクティスでした。

しかし、2024年末のre:Inventにて待望の「ルートアクセス管理」機能がリリースされ、AWS Organizationsの管理アカウントあるいは委任された管理者アカウントからルートユーザーの認証情報を削除できるようになりました!

https://dev.classmethod.jp/articles/root-access-management/

これにより、ベストプラクティスは「そもそもルートユーザーを使えなくする(封印する)」となりました。

通常はそれでよいのですが、どうしてもやんごとなき理由により、この封印を解かねばならない場合が、基本的にはこれっぽっちも無いのですが、そういう時にはこの手順を回していく必要があります。

というわけでルートアクセス管理から「パスワード回復を許可」して実際にパスワードを使える状態にしていきます。

やってみた

※通常ルートユーザーのパスワードを使えるようにする事はデメリットしかありませんのでぜったいにやらないでください

さて、やんごとなき理由により仕方なくルートユーザーのパスワードを設定して、サインインできるようにしていきます。

現代のAWS Organizationsではもうあたりまえのように使う機能であるルートアクセス管理機能ですが、こちらにより新規に作成するAWSアカウントのルートユーザーは最初から作成していないことが多いのではないでしょうか?

しかし、この状態でルートユーザーを利用するために「パスワードリセット」の手順を行うと以下のようにエラーとなり実行できません。

パスワードの回復に失敗しました
AWS アカウントのパスワードの回復は無効になっています。管理者にサポートを依頼してください。

というわけでこれを許可していく必要があります。

ルートアクセス管理からパスワードの回復を許可する

AWS Organizationsと連携する機能ですが、ルートアクセス管理は管理アカウントのIAMのマネジメントコンソールから利用します。

001_allow_root_recovery

ルートアクセス管理を開くと、該当アカウントのルートユーザー認証情報が「存在しない」となっています。

本来はこれが正しい状態ですが、仕方なく変更していきます。

「特権的なアクションを実行する」を押します。

実行できる特権的なアクションから「パスワード回復を許可」を選択して進めます。

002_allow_root_recovery

許可されて、「ルートユーザーはパスワードを忘れた場合のフローでパスワードを回復できるようになりました。」と表示されました。

003_allow_root_recovery

この状態でルートユーザー認証情報が「存在する」に変わっています。

フォーカスを当てると、コンソールパスワードのみ「存在する」となっているようです。

004_allow_root_recovery

この状態でパスワードリセットの手順が実行できるということですね。

パスワードを回復する

ではパスワードを回復してみます。ルートユーザーのサインイン画面でメールアドレスを入力してパスワード入力画面に進みます。

「パスワードをお忘れですか?」を押します。

005_allow_root_recovery

パスワードの回復のため、指示通りに文字を入力してロボットの確認を行います。

006_allow_root_recovery

問題なければリセット用のメールが飛びます。

007_allow_root_recovery

メールを確認すると以下のメールが届きます。

  • タイトル: アマゾン ウェブ サービス パスワードアシスタント
  • 送信元: password-reset-no-reply@verify.signin.aws

008_allow_root_recovery

リンクを開くと新しいパスワードを設定する画面となりますので、設定します。

009_allow_root_recovery

無事リセットできたらサインインを行います。

010_allow_root_recovery

今回はサインインした段階で、リスクがあると判断されたのか本人確認のために検証コードがメールで送られました。

011_allow_root_recovery

検証コードのメールとして以下のメールが届きます。

  • タイトル: ご本人確認のお願い
  • 送信元: no-reply@verify.signin.aws

012_allow_root_recovery

検証コードを入力して進めると、今度はMFAを設定する画面が出てきます。

最近はルート認証情報を使う場合にはMFAが必須とされていて、すぐには強制されませんが35日以内の設定が必要です。というわけでこれも設定しましょう。一瞬だけだからと言って設定しないのは良くないですね。絶対スキップしないで設定しましょう。最近ならパスキーが簡単でおすすめですね。

013_allow_root_recovery

https://dev.classmethod.jp/articles/mfa-root-users-across-all-account-types/

というわけでMFAの設定も完了しました。これでルートユーザーでAWSマネジメントコンソールへアクセスができます。

014_allow_root_recovery

ルートユーザーの認証情報を削除する

やんごとなき理由によりルートユーザーのパスワードを回復しましたが、いつまでもその状態は良くないですよね。

再び管理アカウントからルートアクセス管理の画面を確認すると、以下のようにコンソールパスワードの他にMFAデバイスの設定もされていることが確認できます。

015_allow_root_recovery

しかしそれだけでは良くないです。

「特権的なアクションを実行する」を押して進むと、「ルートユーザー認証情報を削除」の選択肢が出ていて、削除が可能となっています。

016_allow_root_recovery

ルートユーザーのパスワードを使う必要がなくなったら、すぐにでもここから良い状態にしましょう。

まとめ

本来のAWSセキュリティのベストプラクティスから外れますが、やんごとなき理由によりルートユーザーの封印を解き、パスワードを設定する手順を確認しました。

昔はルートユーザーの管理が大変でしたが、今は認証情報を削除して持たなくて良くなっているので大変よい時代です。ぜひルートユーザーの認証情報を封印して楽な管理を謳歌しましょう。


そのマルチアカウント運用、気合いで支えていませんか

Organizations や Control Tower で土台は作れても、アカウントもポリシーも増えるほど、運用は「詳しい一人」に寄りかかっていく。属人化が限界を迎える前に、組織として回す仕組み=CCoEへ。5,600社の支援から得た立ち上げの型を、無料資料にまとめました。

CCoE総合支援

組織で回す仕組みの資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事