トップ > AWS Organizations > AWS Organizations でメンバーアカウントの root メールアドレスを管理アカウントで一元管理できるようになりました

AWS Organizations でメンバーアカウントの root メールアドレスを管理アカウントで一元管理できるようになりました

AWS Organizations
記事タイトルとURLをコピーする

みなさん、こんにちは。 AWS CLI が好きなテクニカルサポート課の市野です。

表題の通りなのですが、AWS Organizations の管理アカウントからメンバーアカウントの root メールアドレスの管理ができるようになりました。

うれしい機能のような気もしますが、何でもかんでもやれてしまっては困るお客様もいらっしゃると思います。

なので、この機能について少し調べてみました。

クリックで目次を表示します

公式情報

AWS What’s New

aws.amazon.com

AWS 公式ドキュメント

docs.aws.amazon.com

先にまとめ

  • この機能がリリースされたからといって、すぐさま管理アカウントからメンバーアカウントの root メールアドレスを変更できるわけではないことが確認できました。

  • 変更するためには AWS Organizations のサービスで「AWS アカウント管理の信頼されたアクセス（AWS Account Management trusted access）＝ account.amazonaws.com 」が有効化されている必要があります。

    • この有効化の実行には organizations:EnableAWSServiceAccess アクションの許可が必要となります。

  • さらに「AWS アカウント管理の信頼されたアクセス（AWS Account Management trusted access）」が有効化されている状況で、StartPrimaryEmailUpdate の実行を行い、届いたワンタイムパスワードを用いて AcceptPrimaryEmailUpdate を行う必要があります。

    • そのため操作の実行者に account:StartPrimaryEmailUpdate と account:AcceptPrimaryEmailUpdate のアクションの許可が必要となります。

挙動の確認

有効化されている AWS サービスアクセスの確認

AWS Organizations 管理アカウント側で、以下のコマンドを実行することで現在有効化されている AWS サービスアクセスの一覧を取得可能です。

aws organizations list-aws-service-access-for-organization

実行結果（例）

以下のような結果が得られ、検証した AWS Organizations 組織では、「AWS アカウント管理の信頼されたアクセス（AWS Account Management trusted access）＝ account.amazonaws.com 」が有効化されていない状態です。

{
    "EnabledServicePrincipals": [
        {
            "ServicePrincipal": "access-analyzer.amazonaws.com",
            "DateEnabled": "2023-02-07T11:11:23.048000+09:00"
        },
        {
            "ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com",
            "DateEnabled": "2022-12-08T17:17:48.131000+09:00"
        },
        {
            "ServicePrincipal": "ram.amazonaws.com",
            "DateEnabled": "2023-10-23T14:31:25.918000+09:00"
        },
        {
            "ServicePrincipal": "reachabilityanalyzer.networkinsights.amazonaws.com",
            "DateEnabled": "2022-12-08T17:17:47.568000+09:00"
        },
        {
            "ServicePrincipal": "sso.amazonaws.com",
            "DateEnabled": "2022-06-07T15:05:23.585000+09:00"
        },
        {
            "ServicePrincipal": "user-subscriptions.amazonaws.com",
            "DateEnabled": "2024-06-03T17:27:49.822000+09:00"
        }
    ]
}

GUI での確認方法は以下。

  • AWS Organizations → サービス へ進み AWS Account Management を確認します。
  • 「アクセス無効」となっており、現時点で有効化されていない状態であることが確認できます。

有効化されている AWS サービスアクセスの確認

AWS アカウント管理 の有効化

以下のコマンドを実行し、サービスプリンシパル account.amazonaws.com を有効化します。

aws organizations enable-aws-service-access \
  --service-principal account.amazonaws.com

実行コマンドの構文にエラーがない限り、上記サブコマンド実行時に返却される値はありません。

有効化されている AWS サービスアクセスの確認（再）

aws organizations list-aws-service-access-for-organization
実行結果（例）

先ほどの実行結果に加え、account.amazonaws.com が追加されていることを確認します。

{
    "EnabledServicePrincipals": [
        {
            "ServicePrincipal": "access-analyzer.amazonaws.com",
            "DateEnabled": "2023-02-07T11:11:23.048000+09:00"
        },
        {
            "ServicePrincipal": "account.amazonaws.com",
            "DateEnabled": "2024-06-09T12:23:52.108000+09:00"
        },
        {
            "ServicePrincipal": "member.org.stacksets.cloudformation.amazonaws.com",
            "DateEnabled": "2022-12-08T17:17:48.131000+09:00"
        },
        {
            "ServicePrincipal": "ram.amazonaws.com",
            "DateEnabled": "2023-10-23T14:31:25.918000+09:00"
        },
        {
            "ServicePrincipal": "reachabilityanalyzer.networkinsights.amazonaws.com",
            "DateEnabled": "2022-12-08T17:17:47.568000+09:00"
        },
        {
            "ServicePrincipal": "sso.amazonaws.com",
            "DateEnabled": "2022-06-07T15:05:23.585000+09:00"
        },
        {
            "ServicePrincipal": "user-subscriptions.amazonaws.com",
            "DateEnabled": "2024-06-03T17:27:49.822000+09:00"
        }
    ]
}

GUI での確認方法は以下。

  • AWS Organizations → サービス から AWS Account Management をクリックします。
  • 「信頼されたアクセスを有効化する」ボタンをクリックします。
    AWS Account Management 画面遷移後
  • ボタンをクリックした後、入力欄に確認目的のため「有効化」と入力し、「信頼されたアクセスを有効にする」ボタンをクリックします。
    信頼されたアクセスの有効化確認画面
  • ステータスが「信頼されたアクセスが有効」となることを確認します。
    信頼されたアクセスの有効化完了状態

メンバーアカウントの root メールアドレスの変更

現在設定されている root メールアドレスの確認

今回のアップデートに伴い、現在設定されている root メールアドレスを取得するための GetPrimaryEmail というアクションも合わせて追加されました。

また、後ほど実行する StartPrimaryEmailUpdate 、AcceptPrimaryEmailUpdate とともに新設されており、AWS CLI v1 であれば 1.33.3、AWS CLI v2 では 2.16.3 で追加されています。

変数へのアカウント ID の代入
ACCOUNT_ID=3XXXXXXXXXX9
account get-primary-email サブコマンドの実行
aws account get-primary-email \
  --account-id ${ACCOUNT_ID}
実行結果

以下のように、PrimaryEmail として設定されているメールアドレスが返却されます。

{
    "PrimaryEmail": "xxxxxxxxxx+org-test-20240609@example.com"
}

GUI での確認方法は以下。

  • AWS Organizations → AWS アカウント へ遷移し、組織内のアカウント一覧ページ内に、アカウント ID とともに、root メールアドレスが記載されているので、該当箇所から確認が可能です。
    また、該当のアカウント一覧ページ内で目的のアカウントのエイリアス名をクリックし、遷移した後の画面上部の「アカウントの詳細」セクションにも該当の AWS アカウントの root メールアドレスが記載されており、ここからも確認が可能です。
    現在のメンバーアカウントの root メールアドレスの確認

メンバーアカウント root メールアドレスの更新の開始

StartPrimaryEmailUpdate API を実行し、新しい root メールアドレスへの更新の開始をします。

上記の API リファレンスでは簡素な説明ですが、Updating the root user email address for a member account のドキュメントを読む限り、新しいメールアドレス文字列を投入することで、投入した新しいメールアドレスにワンタイムパスワードが送信されるとのことです。

変数への新しいメールアドレス文字列の代入
NEW_EMAIL=xxxxxxxxxx+org-test-20240609-alt@example.com
account start-primary-email-update サブコマンドの実行
aws account start-primary-email-update \
  --account-id ${ACCOUNT_ID} \
  --primary-email ${NEW_EMAIL}
実行結果
{
    "Status": "PENDING"
}
投入したメールアドレス側の確認

本文中にも記載がありますが、届いたワンタイムパスワードの有効期限は 24時間 となります。

新しく設定するメールアドレスへのワンタイムパスワード通知例

GUI での実行方法は以下。

  • 「アカウントの詳細を編集」セクションの「アクション」プルダウンをクリックし「E メールアドレスを更新」ボタンをクリックします。
    E メールアドレスを更新]
  • 新しく登録する E メールアドレスを入力し、「保存」ボタンをクリックします
    新しく設定するメールアドレスの入力
  • このあと、入力した新しいメールアドレスに対し、ワンタイムパスワードが届きます。

メンバーアカウント root メールアドレスのアップデートの完了

start-primary-email-update サブコマンドを実行後、投入していたメールアドレスに届くワンタイムパスワードと、メールアドレスを引数にし、accept-primary-email-update サブコマンドを実行することでアップデートが完了します。

account accept-primary-email-update サブコマンドの実行
aws account accept-primary-email-update \
  --account-id ${ACCOUNT_ID} \
  --otp 800214 \
  --primary-email ${NEW_EMAIL}
実行結果

上記サブコマンドの構文に誤りがなければ、以下のようにステータスとして ACCEPTED が返却されます。

{
    "Status": "ACCEPTED"
}

アップデート成功後のメール通知

前述のコマンド成功後、以下のようなメールが、メンバーアカウントの従来の root メールアドレス、メンバーアカウントに新しく設定した root メールアドレス、および管理アカウントの root メールアドレスに届きます。

配信先 メール件名
メンバーアカウントの従来の root メールアドレス The root user email address for AWS account ID ${対象のメンバーアカウント ID} has been updated
メンバーアカウントに新しく設定した root メールアドレス
管理アカウントの root メールアドレス 		The root user email address for AWS account ID ${対象のメンバーアカウント ID} has been updated to ${メンバーアカウントに新しく設定した root メールアドレス}

GUI での実施方法は以下。

  • 「アカウントの詳細を編集」セクションの「アクション」プルダウンをクリックし「E メールのアップデートを完了」ボタンをクリックします。
    「アクション」プルダウンでの操作
  • 先ほど入力した新しく設定するメールアドレス、および E メールアドレスの更新実行後に届いたワンタイムパスワードを入力し、「確認」ボタンをクリックします。
    新しく設定するメールアドレスと届いたワンタイムパスワードを入力

この変更で変わらないもの

  • すでに設定済みの root アカウントの「パスワード」は変更になりません。
  • すでに設定済みの多要素認証デバイスは変更になりません。（当方の検証環境では仮想 MFA デバイスのみでの検証でしたが、変更にならないことは確認済みです）

検証を通じて確認している挙動としては、管理アカウント側での変更時（変更が成功するまでの間）には、現在の root メールアドレスへの通知などがないため、変更が成功した後で届くメール通知でしか知り得ないこととなります。
そのため、管理アカウント側で想定していない操作可能な IAM エンティティが存在した場合、意図せずメンバーアカウントの root アカウントの変更ができてしまうこととなります。

上記を考えても、ベストプラクティス通り root アカウントには多要素認証の設定をしておくことが望ましいと言えます。

AWS 管理ポリシーの追従状況

PowerUserAccess

執筆時点の バージョン 5 では、organizations および account 以外のすべてのアクションが許可されており、例外的に organizations:DescribeOrganization、account:ListRegions そして account:GetAccountInformation のみが許可されている状態です。
そのため、PowerUserAccess のみを持つ IAM エンティティがすぐさま当該の作業を行えることはなさそうです。

クリックでポリシー全文を表示します

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "iam:DeleteServiceLinkedRole",
                "iam:ListRoles",
                "organizations:DescribeOrganization",
                "account:ListRegions",
                "account:GetAccountInformation"
            ],
            "Resource": "*"
        }
    ]
}

AWSOrganizationsReadOnlyAccess

AWS Organizations を対象とした PowerUser 系の AWS 管理ポリシーはないため、AWSOrganizationsFullAccess で今回の新しいアクションへの許可がされていることを把握していれば良いかと思いますが、ReadOnly 系を確認してみました。

執筆時点で、すでにバージョン 6 がリリースされており、account:GetPrimaryEmail アクションの許可が追加されていました。 そのため、AWSOrganizationsReadOnlyAccess が付与されている IAM エンティティでは特にポリシーの変更をせずに、メンバーアカウントで現在設定されている root アカウントの確認をすることが可能な状態です。

クリックでポリシー全文を表示します

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSOrganizationsReadOnly",
            "Effect": "Allow",
            "Action": [
                "organizations:Describe*",
                "organizations:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AWSOrganizationsReadOnlyAccount",
            "Effect": "Allow",
            "Action": [
                "account:GetAlternateContact",
                "account:GetContactInformation",
                "account:ListRegions",
                "account:GetRegionOptStatus",
                "account:GetPrimaryEmail"
            ],
            "Resource": "*"
        }
    ]
}

AWSAccountManagementReadOnlyAccess

AWS アカウント管理でも PowerUser 系のポリシーはないため、Organizations 同様、AWSAccountManagementFullAccess で今回の新しいアクションへの許可がされていることを把握していれば良いかと思いますが、ReadOnly 系を確認してみました。

AWSAccountManagementReadOnlyAccess では、Get* が許可されているため、今回追加された account:GetPrimaryEmail が自動的に内包されます。

クリックでポリシー全文を表示します

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "account:Get*",
                "account:List*"
            ],
            "Resource": "*"
        }
    ]
}

AWSAccountActivityAccess

AWSAccount〜 で始まる似たような IAM ポリシーで AWSAccountActivityAccess が存在します。
このポリシーはアカウントアクティビティページへのアクセス許可を想定したポリシーですが、当該のポリシーでの Get 系のアクションは制限されており、今回追加となった account:GetPrimaryEmail は対象外となっており、閲覧ができない状態です。

クリックでポリシー全文を表示します

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "account:GetAccountInformation",
                "account:GetAlternateContact",
                "account:GetChallengeQuestions",
                "account:GetContactInformation",
                "account:GetRegionOptStatus",
                "account:ListRegions",
                "billing:GetIAMAccessPreference",
                "billing:GetSellerOfRecord",
                "payments:ListPaymentPreferences"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "aws-portal:ViewBilling"
            ],
            "Resource": "*"
        }
    ]
}

おわりに

管理アカウント側だけの操作で、メンバーアカウントの root メールアドレスの管理を行えるようになったことで、複数のアカウント間を行き来せずに操作が行えるようになりました。
ワンタイムパスワードの入力が必要で、かつ変更後に新旧の root メールアドレスに加えて、管理アカウント側にもメール通知されるため、最低限意図しない変更を防ぐ、あるいは気づくことは可能です。
IAM ポリシーでのアクションでもきめ細かく操作の制御を行えるので、適切に設定してうまく管理したいところですね。

このエントリがどなたかのお役に立てば幸いです。

ではまた。

市野 和明 (記事一覧)

マネージドサービス部・テクニカルサポート課

お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。

情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。

X（Twitter）：@kazzpapa3（AWS Community Builder）