はじめに

こんにちは、YUJIです。

12月にAWS re:invent開催を控え、サービスアップデートが盛んに発表される時期がやってきました。
つまりお外が寒いです。皆さんいかがお過ごしでしょうか。

今回は、AWS Organizationsに新機能が追加されたので紹介します。

忙しい人向けの3行

• (AWSアカウント管理者向け)AWS Organizationsの管理アカウントを通じて、操作不能になったS3バケットのポリシーの回復をはじめとして、ルート特権がないと出来なかった作業が出来るようになりました。
• (AWSアカウント管理者向け)「特権が必要な操作をするために、メンバーアカウントでルートユーザーを作る」という運用が不要になるかも？
• (開発者向け)Amazon S3のバケットポリシーに、Denyと軽率に書いたりしないよう、引き続きお気をつけください。

なにがあったの？

例えば、↓の記事で注意喚起されているようなバケットポリシーの書き方をして
操作不能のS3バケットを作り出してしまったとします。
(割とあるあるなのと、記事として面白いので是非見てみてください。)

そういった場合、該当アカウントのルートユーザーを用いることでしか、操作不能になったバケットを復旧できなかったところ
今回の記事で取り扱う、新機能のRoot access managementが追加されたことで

• 該当アカウントのルートユーザーでログインして、バケットポリシーを削除する　←今まではこれだけ
• AWS Organizationsの管理アカウントから、該当アカウントのS3のバケットポリシーを削除する　← New!

と、新しい選択肢が出てきました。

公式記事・ブログ

AWS Organizations member accounts can now regain access to accidentally locked Amazon S3 buckets
https://aws.amazon.com/jp/about-aws/whats-new/2024/11/aws-organizations-member-accounts-access-locked-amazon-3-buckets/

Centrally managing root access for customers using AWS Organizations(AWS公式ブログ)
https://aws.amazon.com/jp/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/

Q.じゃあ今後はバケットポリシーに軽々しくDenyを使ってもいいの？

A.ダメです。

操作不能のバケットに対処する選択肢が増えた。というだけなので
ルートユーザーを使うにしても、AWS Organizationsの管理アカウントを使うにしても
どの道、『特別な権限の所有者が、どうにかしてポリシーを消すことになる』というのは変わりません。

Root access managementを実際に使ってみた

Root access managementは、AWS Organizationsの新機能ではありますが
AWS IAMのサービスページのここに生えています。

↑メンバーアカウントでは、管理権限を委任されない限り、この新規機能は使えません。

管理アカウントでは、↓このような形で表示されます。
早速有効化してみます。

①…メンバーアカウントのルートユーザーのクレデンシャル(パスワード、アクセスキー、MFAなど)を削除したり、元通り使えるようにされたりしないよう監査できる。
②…一時的なルートのクレデンシャルを使い、強力すぎるdenyで誰も触れなくなったS3バケットポリシーやAmazon SQS キューのポリシーを削除できる
③…(オプション)メンバーアカウントを指定して、Root access managementの権限を委任できる。

無事機能が有効化されたとメッセージが出ました。

先程の①～③の機能の有効化/無効化は、ここから変更できます。

では、本記事の主題である②の機能を使い、ルートユーザーへのログイン無しで、一時的な認証情報を使って
操作不能になったバケットポリシーを削除してみましょう。

メンバーアカウントの方でバケットを作り、仮に↓こういうポリシーをバケットにつけるとします
※現用しているバケットで真似しないでください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::yuji-test-bucket-deny-policy",
                "arn:aws:s3:::yuji-test-bucket-deny-policy/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "*",
            "Resource": [
                "arn:aws:s3:::yuji-test-bucket-deny-policy",
                "arn:aws:s3:::yuji-test-bucket-deny-policy/*"
            ]
        }
    ]
}

明示的なDenyが強すぎて、Administratorアクセスをもってしても、ポリシーの変更すら受け付けずバケット毎消したりすることもできない
操作不能バケットが出来上がってしまいました。あ～あ。

この操作不能バケットの問題に対処するため
管理アカウントに戻って、Root access managementで、該当のバケットを作ってしまったアカウントを選択し
[特権的なアクションを実行する]をクリックします。

Delete S3 bucket policyを選んで
[S3を参照]から、該当バケットを選択します。

今どんなバケットポリシーが付いているかは、ここから確認できます。
削除する前に、念の為コピーしておくと良いでしょう。

[削除]を押すと、バケットポリシーを削除できました。
これで、また適切なバケットポリシーを付け直すなり、開発者でも対応ができるようになりました。

ちなみに、私の検証用Organizationでは、下記のようなNetwork Failureエラーが出ることがありました。
メンバーアカウント作成＆検証用バケット作成から10時間程度経ってもこのエラーのままでしたが、0時の日付変更をもって出来るようになってました。
ここは何がトリガーなのか謎のままです。

他にもAmazon SQSキューのポリシーの削除ができたりなどありますが
こういう事がルートユーザーを介さなくてもできるようになったよ！というのが、今回の機能追加の概要です。

まとめ

この機能によって何が嬉しいかというと

• ルートユーザーを使う作業のために、ルートユーザーをメンバーアカウント分作って管理しないといけない
• でも本来は、メンバーアカウントのルートユーザーを無闇に作りたくない(MFA等を管理したくない)

という要件に苦しめられていた情シス担当者の方などが
「この機能があるからメンバーアカウントのルートユーザーなんて無くてもいいじゃん！」
と、苦悩から開放されるきっかけになるのではないかなと思います。
(あくまで判断材料の一つです。ある意味、管理アカウントがroot相当の一時的な強権を都度持つことについてはご留意ください。)

私自身、ルートユーザーを弊社側で管理することになる、通常のリセールプランを利用のお客様と接する事が多いので
このあたりの運用で困っている方を見かけることはあまりないですが、一人でも多くのAWSアカウント管理者の方が救われれば幸いです。

ありがとうございました。