はじめに
こんにちは。クラウド活用推進担当、新人の安田です。
2024年11月にAWS Organizationsを使用している際、管理アカウントから各メンバーアカウントのルートユーザーを使用禁止にしたり、ルートユーザー特有の操作を実行することが可能となりました。
本記事では、メンバーアカウントのルートアクセスを一元管理する方法と、一時的なルートアクセス権限付与の検証内容を紹介します。
目次
- ルートアクセスの一元管理の重要性
- 前提条件
- コンソールを使用した設定
- ルートセッション認証情報の付与の方法を検証
- S3バケットポリシーの削除検証
- SQSキューポリシーの削除検証
- まとめ
- 最後に
- 参考
ルートアクセスの一元管理の重要性
- セキュリティリスクの軽減: ルートユーザー認証情報は非常に強力であり、誤用されると重大なセキュリティリスクを引き起こす可能性があります。
- 運用効率の向上: 一元管理により、複数のアカウントでのルートアクセス管理が簡素化され、運用負荷が軽減されます。
前提条件
- AWS Organizations を有効にしていること
コンソールを使用した設定
- AWS Management Console にサインイン: 管理アカウントでサインインします。
- IAM コンソールを開く: ナビゲーションペインで「ルートアクセス管理」を選択します。
- ルートアクセス管理を有効にする: 「有効化」を選択し、必要な設定を行います。

ルート認証情報管理とメンバーアカウントでの特権ルートアクションの2つの機能を有効化するか確認されます。前者はルートユーザーの資格情報削除、パスワード回復の許可を設定するもので、後者はメンバーアカウントのS3/SQSのリソースポリシー削除を許可する機能です。今回は両方とも有効化します。
ルートユーザーの資格情報を削除すると、ルートユーザーでログインができなくなります。

Eメールでのパスワードのリセットもできなくなります。リセット用のメールの送信はできますが、メール内のリンクから飛ぶとパスワードリセットが禁止されていることが確認できます。

管理アカウントのコンソールからEメールでのパスワードリセットを許可することができます。アカウントを選択して『特権的なアクションを実行する』を選択し、『パスワード回復を許可』を選択するとメンバーアカウントのルートユーザーのパスワードを回復できるようになります。

ルートセッション認証情報の付与の方法を検証
今回は、誤ったバケットポリシーを設定したS3バケットを作成し、ポリシーを削除する権限を持った認証情報をアカウントに付与して検証します。
ルートセッション認証情報の付与の必要性
- 特権タスクの実行: 一部のタスクはルートユーザーとしてのみ実行可能です。
- セキュリティの確保: 短期的なルートアクセスを付与することで、長期的な認証情報を必要とせずに安全に実行できます。
S3バケットポリシーの削除検証
検証準備
検証用に作成したアカウントで、以下のようなバケットポリシーを持ったS3バケットを作成します。
- {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Action": "s3:*",
- "Effect": "Deny",
- "Resource": [
- "arn:aws:s3:::my-bucket",
- "arn:aws:s3:::my-bucket/*"
- ],
- "Principal": "*"
- }
- ]
- }
ポリシーを設定すると、バケットの中身を見ることやバケットの削除など何もできない状態になります。

検証手順
- 管理アカウントでサインインします。
- CloudShellを開きます。
- ルートアクセス管理機能を有効化時にルート認証情報管理とメンバーアカウントでの特権ルートアクションの2つの機能を有効化していない場合、以下のコードを実行します。有効化済みの場合は次の手順に進みます。
- aws iam enable-organizations-root-credentials-management
- aws iam enable-organizations-root-sessions
- 一時的な認証情報を発行します。今回はS3のバケットポリシーを削除するためのポリシーを付与します。
- aws sts assume-root \
- --target-principal <my member account id> \
- --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy
- >>{
- >> "Credentials": {
- >> "AccessKeyId": "xxxxxxxxxx",
- >> "SecretAccessKey": "xxxxxxxxxx",
- >> "SessionToken": "xxxxxxxxxx",
- >> "Expiration": "2024-09-23T17:44:50+00:00"
- >> }
- >>}
- アクセスキー ID、シークレットアクセスキー、セッショントークンを取得したら、これらを環境変数として渡します。
- export AWS_ACCESS_KEY_ID=xxxxxxxxxx
- export AWS_SECRET_ACCESS_KEY=xxxxxxxxxx
- export AWS_SESSION_TOKEN=xxxxxxxxxx
- メンバーアカウントにルートで認証されていることを確認します。
- aws sts get-caller-identity
- >>{
- >> "UserId": "<my member account id>",
- >> "Account": "<my member account id>",
- >> "Arn": "arn:aws:iam::<my member account id>:root"
- >>}
- S3 の delete-bucket-policy を使用して、バケットに適用されている誤ったポリシーを削除します。出力がない場合、正常に削除が完了しています。
- aws s3api delete-bucket-policy --bucket
バケットを確認すると、中身が確認できるようになっています。

管理アカウントのコンソールからポリシーを削除することも可能です。アカウントを選択して『特権的なアクションを実行する』を選択すると、メンバーアカウントのバケットポリシーを削除できます。

SQSキューポリシーの削除検証
検証準備
検証用に作成したアカウントで、以下のようなバケットポリシーを持ったSQSキューを作成します。
- {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Action": "sqs:*",
- "Effect": "Deny",
- "Principal": "*",
- "Resource": "arn:aws:sqs:Region:AccountID:my-queue"
- }
- ]
- }
ポリシーを設定すると、作成したキューを確認することができなくなります

検証手順
- 管理アカウントでサインインします。
- CloudShellを開きます。
- ルートアクセス管理機能を有効化時にルート認証情報管理とメンバーアカウントでの特権ルートアクションの2つの機能を有効化していない場合、以下のコードを実行します。有効化済みの場合は次の手順に進みます。
- aws iam enable-organizations-root-credentials-management
- aws iam enable-organizations-root-sessions
- 一時的な認証情報を発行します。SQSのキューポリシーを削除するためのポリシーを付与します。
- aws sts assume-root \
- --target-principal <my member account id> \
- --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/SQSUnlockQueuePolicy
- >>{
- >> "Credentials": {
- >> "AccessKeyId": "xxxxxxxxxx",
- >> "SecretAccessKey": "xxxxxxxxxx",
- >> "SessionToken": "xxxxxxxxxx",
- >> "Expiration": "2024-09-23T17:44:50+00:00"
- >> }
- >>}
- アクセスキー ID、シークレットアクセスキー、セッショントークンを取得したら、これらを環境変数として渡します。
- export AWS_ACCESS_KEY_ID=xxxxxxxxxx
- export AWS_SECRET_ACCESS_KEY=xxxxxxxxxx
- export AWS_SESSION_TOKEN=xxxxxxxxxx
- メンバーアカウントにルートで認証されていることを確認します。
- aws sts get-caller-identity
- >>{
- >> "UserId": "<my member account id>",
- >> "Account": "<my member account id>",
- >> "Arn": "arn:aws:iam::<my member account id>:root"
- >>}
- 作成したキューが見えなくなっているので、キューの一覧を取得して確認します。
- aws sqs list-queues
- >>{
- >> "QueueUrls": [
- >> "https://sqs.ap-northeast-1.amazonaws.com/<my member account id>/my-queue"
- >> ]
- >>}
- SQS の set-queue-attributes を使用して、キューに適用されている誤ったポリシーを空にします。出力がない場合、正常に完了しています。
- aws sqs set-queue-attributes --queue-url <queue url> --attributes Policy=""
確認すると、作成したキューが確認できるようになっています。

管理アカウントのコンソールからポリシーを削除することも可能です。アカウントを選択して『特権的なアクションを実行する』を選択し、キューのARNを入力するとメンバーアカウントのキューポリシーを削除できます。

まとめ
AWS Organizations を使用したルートアクセスの一元管理とルートセッション認証情報の付与は、セキュリティと運用効率を大幅に向上させることができます。これにより、複数のアカウントを安全かつ効率かつ効率的に管理することが可能になります。
最後に
今回はAWS Organizationsでルートアクセスを一元管理する方法と、ルートセッション認証情報の付与の方法を紹介しました。
一元管理機能を使うことで、ルートユーザーの管理の負担を減らすことが可能となります。
この記事が参考になれば幸いです。ここまで読んでいただきありがとうございました。
参考
AWS Organizations を使用するお客様のためのルートアクセスの一元管理