MFA必須化に備える！IAMルートアクセス管理の導入方法と注意点を解説！

はじめに

2025年春より、AWS Organizations配下にある メンバーアカウントのルートユーザーに対し、多要素認証（以下、MFA）が必須化されるというアナウンスがありました。ドキュメントにも以下のように記載されています。

2024 年 5 月以降、MFA がまだ有効になっていない場合、すべてのルートユーザーは次回のサインイン時に MFA を有効にする必要があります。ユーザーは、プロンプトをスキップすることで、MFA 登録を最大 35 日間延期できます。35 日後、MFA を有効にすると、サインインを続行し、AWS Management Console にアクセスすることが必須になります。メンバーアカウントの場合、MFA 設定は現在オプションですが、2025 年 Spring に実施が予定されています。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/enable-mfa-for-root.html

今までは Organizations配下のメンバーアカウントの場合、MFA設定はオプションとなっていましたが、全てのAWSアカウントのルートユーザーの認証にMFA設定が必要となります。このため大量のAWSアカウントを運用している環境や、IAM Identity Centerでユーザー管理を行っている環境などでは、多くのMFAを管理する必要が出てきます。

そこで今回はルートユーザーの認証情報を一元管理することができる「ルートアクセス管理」機能における設定手順と注意点について共有します。

ルートアクセス管理

ルートアクセス管理とは、2024年11月に発表されたIAMの新機能で、Organizationsの管理アカウントから、メンバーアカウントのルートユーザーの一元管理ができる機能になります。この機能を利用することで、メンバーアカウントのルートユーザー認証情報を消すだけではなく、各種特権操作の実行、ルートユーザー認証情報を作らないAWSアカウントの作成などが可能になります。従来、ルートユーザーしか実施できなかった操作を、管理アカウントのIAMユーザーに委任することも可能となります。（誤って設定してしまったバケットポリシーの削除など）

具体的には以下のような操作・設定が可能です。

• 特権タスクを実行する
  • S3 バケットポリシー削除
  • SQS キューポリシー削除
• ルートユーザーの認証情報を管理する
  • ルートユーザー認証情報の削除（パスワード、アクセスキー、署名証明書、多要素認証）
  • ルートユーザーパスワードの回復
• 特権アクションをメンバーアカウントに委任する
• 新アカウント作成時のルートユーザーの認証情報を作成しない

ルートアクセス管理の有効化手順

１．Organizations の管理アカウントにログインし、IAMの左メニューに増えた「ルートアクセス管理」から「有効化」を選択します。

２．ルートアクセス管理の設定項目を選択し、「有効化」します。
　　基本的にはデフォルト設定で問題ありません。

これだけの手順でOrganizations 全体のルートアクセス管理が有効化され、アカウントの認証情報の設定状況の確認とアカウントへの特権アクションの実行が可能になります。

有効化時に発生した課題と解決策

実際にルートアクセス管理を有効化してみると、弊社の環境ではいくつか問題が発生しました。
以下にその内容と対応策を共有します。

ルートユーザー認証情報がアクセス拒否で取得出来ない

事象

管理アカウント側ルートアクセス管理のアカウント一覧において、ルートユーザー認証情報の存在有無が表示されるところ、「アクセス拒否」と表示されてしまう。

原因と対応

今回検証を行った Organizations 環境では、SCP（サービスコントロールポリシー）による組織ポリシーによりルートユーザーの全アクションを拒否する設定が登録されていました。メンバーアカウントのルートユーザーは通常利用しないため、操作を禁止する設定を入れていたのですが、これが今回のアクセス拒否の原因となっていました。
対応として、ルートアクセス管理の特権アクションに必要な権限について、ルートユーザーで操作可能となるようにすることで対応しています。変更後のSCP設定例では、認証情報のステータスを表示するほか、認証情報の削除権限もあわせて付与しています。

設定していたSCP：ルートユーザーの全てのアクションを拒否

変更後のSCP：ルートユーザーに特定アクションを許可

参考：特権アクションの実行に必要な権限

ルートユーザーのパスワードの回復許可に失敗する

事象

ルートアクセス管理設定確認のため、ルートユーザー認証情報が存在しないアカウントのパスワード回復許可を実施しようとしたところ、「iam:CreateLoginProfile へのアクセスが拒否されました」のエラーが発生してパスワードの回復許可設定が変更できない。

原因と対応

この環境ではIAM Identity Center を利用してユーザー一括管理を行っているため、個別アカウントのユーザーのコンソールアクセスを許可しないよう CreateLoginProfile を別のSCPで制限していました。これがルートユーザーのパスワードの回復を実施する際に引っかかってしまい、アクセス拒否エラーとなっていました。

対応として、ルートユーザーはログインプロファイルの作成が可能となるようにSCPポリシーを変更することで、パスワードの回復が実施可能になりました。

設定していたSCP：全てのユーザーの iam:CreateLoginProfile アクションを拒否

変更後のSCP：ルートユーザーに iam:CreateLoginProfile アクションを許可

以下は、SCP変更後にパスワードの回復許可に成功した例です。コンソールパスワードのみ「存在する」に変更されていて、アクセスキーやMFAはパスワードの回復後に個別設定する必要があります。

GuardDutyからの大量のアラート通知が発生する

事象

Organizations 配下の全メンバーアカウントに対しルートユーザー認証情報の削除を行ったところ、全てのメンバーアカウントで、以下GuardDuty Findingsによるアラート通知が発生しました。

• Policy:IAMUser/ShortTermRootCredentialUsage
• Impact:IAMUser/AnomalousBehavior
• Discovery:IAMUser/AnomalousBehavior

原因

管理アカウントでの特権アクションの実行は、実際には AssumeRoot というAPIを利用し、それぞれのメンバーアカウントのルートユーザー操作を行っています。このため、ルートユーザーの認証情報が使われた、認証情報の削除や再作成が行われたことを 、GuardDuty 側で異常な行動として検知したものになります。

こちらについては正常な検出動作になるので、MFA有効化に伴いルートユーザーの認証情報を削除する際は、関係者に事前に通知する、または事前にアラートの対象外にする等で対応することになります。

まとめ

ルートアクセス管理を有効化することで、Organizations 配下のルートユーザーの認証情報管理が不要となりセキュリティ強化が図れるほか、今までルートユーザーのみしか出来なかった操作をIAMユーザーに委任することも出来るようになります。設定も簡単ですし、Organizations 配下のルートユーザーを管理するうえでは有効化すべき機能となっています。
まだ導入されていない方は、今回紹介した手順や注意点を参考にぜひ導入を検討してみてください。