本ブログエントリでは、AWS からの新発表を一般的に取り上げることを目的としており、AWS Organizations をお使いでないなどお客様のご利用状況や弊社でのご利用プランによっては実行が困難な内容も含んでいる場合があります。
あらかじめご了承ください。
みなさん、こんにちは。 AWS CLI が好きなテクニカルサポート課の市野です。
ラスベガスで年に一度開催される AWS 最大のイベント re:Invent が開催中ですが、今日はそんな re:Invent 会期中のニュース発表から漏れた、いわゆる「落選組」のニュースの中で、しれっと大きめのアップデートがありましたのでその紹介と、ちょっとしたやってみた記録を書いてみます。
クリックで目次が表示されます。
公式発表とニュースの概要
Centrally manage root access in AWS Identity and Access Management (IAM)
上記は、AWS Organizations のメンバーアカウント側で root アカウントの権限が必要な特権的な作業のうち、以下については、管理アカウント側から集中的に管理ができるようになったニュースとなります。
実行できる管理項目
- Delete S3 bucket policy
アクセス元グローバル IP アドレスを書き間違えた、など、条件を満たせる IAM エンティティがいなくなり、操作不能となった原因の S3 バケットポリシーを削除し、アクセス可能にリカバリーします - Delete SQS queue policy
上記と同様に、Amazon SQS のキューポリシーに対して、誤った記載をしてしまい、root アカウントでしか復旧できなくなったものに対してキューポリシーを削除し、アクセス可能にリカバリーします - Delete root user credentials
ルートアクセスキー、パスワードや署名証明書を削除し、設定されている多要素認証（MFA）があればその MFA デバイスも削除します
AWS Organizations member accounts can now regain access to accidentally locked Amazon S3 buckets
本発表は、前述の「Centrally manage root access」で実行可能な操作の一つとして挙げられている「Delete S3 bucket policy」について特記したものとなります。
ネットの情報や弊社へのお問い合わせをみていても、一定数 S3 バケットを操作不能にするバケットポリシーを書いてしまった例は見聞きしますし、AWS を使っていてよくやるやらかしの代表例かもしれませんね。
やってみた
What's New AWS の中から二つの記事を取り上げている形になりますが、本質的には同質のアップデートですので合わせて検証をしてみます。
機能の有効化
まず、前提として「Centralized root access for member accounts」を利用するには機能の有効化をする必要があります。 内部処理的には、管理アカウント側の IAM エンティティが、メンバーアカウントの root アカウントの「短期的なルートセッション」を引き受けるという動作で成り立っているため、Identity and Access Management（IAM）に操作を行う箇所が２パターン用意されています。
コンソールでの操作箇所１
IAM コンソールの左ペイン「アカウント設定」から遷移した先に「Centralized root access for member accounts」のセクションが新設されています。
このセクションから「有効化」ボタンをクリックすることで機能の有効化をすることができます。
コンソールでの操作箇所２
動線はもうひとパターンあり、IAM コンソールの左ペインに新規追加された「Root access management」リンクから遷移した先に「Root access management」ページが新設されています。
このページにある「有効化」ボタンをクリックすることで機能の有効化をすることができます。
機能の有効化画面
結局のところ、上記の操作箇所１あるいは操作箇所２のどちらの動線をたどっても、「Centralized root access for member accounts」というページに行き着く、という結果は一緒です。
そのため、どちらの手順を通っていただいても問題ないのですが、後述の通り、作業の実施自体が「Root access management」から行うので「操作箇所２」を使う方が多くなるような気がしています。（あくまで主観）
有効化画面では、Capabilities として2種類を選択できるようになっていますが、前述の概要部分で述べた「実行できる管理項目」にあるうち、「Delete root user credentials」のみを扱える「Root credentials management」と、「Delete S3 bucket policy」および「Delete SQS queue policy」を扱える「Privileged root actions in member accounts」の2種類に細分化されています。
また、recommended（推奨）と記載されているように Centralized root access for member accounts の機能自体を任意のメンバーアカウントに対して権限委任することも可能となっています。
今回は、一度の操作で両方とも有効化し、権限委任はしない形で有効化を進めます。
選択できる Capabilities についてまとめ
以下いずれかを制御可能となり、他方にチェックを入れず有効化した場合はそれらの機能は扱えないこととなる。
広めの権限とならないように、最小権限を検討可能な箇所ですね。
- Root credentials management
Delete root user credentials のみ実行できる - Privileged root actions in member accounts
Delete S3 bucket policy および Delete SQS queue policy のみを実行できる
Delete S3 bucket policy の実施
Delete SQS queue policy についても操作としては同様のため、今回は代表で Delete SQS queue policy をやってみます。
（事前準備）やらかしたアカウント
検証用のメンバーアカウントに 20241203.do.not.access というバケットを作成し、以下の（私の自宅環境からは）絶対に成立しないバケットポリシーを仕込んでみました。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::20241203.do.not.access", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "8.8.8.8/32" ] } } } ] }
無事に（？）アクセス不能なバケットが出来上がりました。
管理アカウントからのリカバリー
左ペインの「Root access management」へアクセスします。
すでに、機能が有効化されていればアカウント一覧が表示されます。
ここで、復旧対象のアカウントのラジオボタンを活性化して、「特権的なアクションを実行する」ボタンをクリックします。
次画面で選択したアカウントに対して実行する特権アクションを選択します。
今回は、S3 バケットのリカバリーを実行したいので「Delete S3 bucket policy」にチェックを入れます。
チェックを入れると「Delete S3 bucket policy」セクションが表示され S3 URI を入力する形となります。
「S3 を参照」ボタンをクリックすると、対象のアカウントの S3 バケット一覧がポップアップしますのでその一覧から選択することも可能です。
S3 URI を入れた状態で「Delete bucket policy」ボタンをクリックすると最終確認ダイアログが表示されますので、確認文字列を入力の上、削除を実施します。
これで、バケットポリシーの削除ができるはずなのですが、検証時、Network Failure というエラーメッセージが発生したため、本エントリ執筆時点でマネージメントコンソールでの作業では完結していない状況です。（後日再度検証をやってみます）
というわけで AWS CLI の出番
私が CLI が好きだからこの流れにしたわけではないのですが、GUI で完結できなかったため CLI での操作方法も検証しました。
公式ドキュメントは Perform a privileged task on an AWS Organizations member account にありますが、手順としては以下の通りとなります。
aws sts assume-root コマンドで任意のタスクポリシーに assume root します。
aws sts assume-root \ --target-principal 84xxxxxxxxxx \ --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy \ --duration 900
実行後、以下のような返却がありますので、export で環境変数に設定します。
# aws sts assume-root コマンドで返却される値の例
{
"Credentials": {
"AccessKeyId": "ASXXXXXXXXXXXXXXXXXX",
"SecretAccessKey": "vzexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"SessionToken": "IQoJb3JpZ2luX2VxxxxxxxxxFwLW5vcnRoZWFzdC0xIkYwRAIgTfgnHqlNDBuhrTvZuGHVNia2kHvhXsII9NMHhNcuUj0CID/i...",
"Expiration": "2024-12-03T04:51:40+00:00"
}
}
# 上記で得られた値を以下のように環境変数に設定
export AWS_ACCESS_KEY_ID="ASXXXXXXXXXXXXXXXXXX"
export AWS_SECRET_ACCESS_KEY="vzexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2VxxxxxxxxxFwLW5vcnRoZWFzdC0xIkYwRAIgTfgnHqlNDBuhrTvZuGHVNia2kHvhXsII9NMHhNcuUj0CID/i..."
環境変数へ一時認証情報を格納の上、aws s3api delete-bucket-policy コマンドを実行することで、S3 バケットポリシーの削除が完了します。
aws s3api delete-bucket-policy \ --bucket 20241203.do.not.access
なお、実行後、リクエストのパラメータに誤りがなければ正常終了時に返却される値はありません。
一応、root の一時セッションのままですが aws s3api get-bucket-policy コマンドで状況を見てみるとポリシーが存在しないと返却されています。
aws s3api get-bucket-policy \ --bucket 20241203.do.not.access An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist
Delete root user credentials の実施
事前確認
対象のメンバーアカウントの root アカウントでは、パスワード設定があり、ログインができる状態です。
ただ、これまでのベストプラクティスの通り MFA で保護している状態ではあります。
クレデンシャル情報の削除
続いて、root アカウントの各種認証情報の削除を試してみます。
先ほどと同様に左ペインの「Root access management」から Root access management 画面へ遷移したアカウント一覧の中で、root アカウントにクレデンシャル情報の設定がある場合は「存在する」という表記がされています。
対象のアカウントを選択し、「特権的なアクションを実行する」ボタンをクリックし「Delete root user credentials」を選択すると、Delete root user credentials セクションが展開され、コンソールパスワードの使用履歴やルートアクセスキーの使用履歴とともに説明（注意文）が表示されます。
「Delete root user credentials」ボタンをクリックすると最終確認ダイアログが表示され、確認文字列を入力の上、削除を実施することとなります。
（なお、上記の root アカウントのクレデンシャル情報の削除はマネジメントコンソールの操作でも問題なく実行が可能でした。）
削除が完了すると、Root access management ページでの対象のアカウントの表示は「存在しない」となりました。
なおかつ、該当の操作により root アカウントでのログイン試行時の「パスワードをお忘れですか?」リンクを経由して実行できる「パスワードの回復」もできない状況となります。
そのため、root アカウントのメールが流出したような場合でも、一時文字列を入力した上で、パスワードアシスタントのメールを受信することで得られるパスワードリセット用の URL 自体が機能しなくなり、メンバーアカウントの root アカウントの保護レベルを一段上げることができると考えられます。
再度、パスワード設定を行えるようにするには、Root access management ページへ遷移し、アカウントを選択の上「特権的なアクションを実行する」をクリックして遷移した特権アクションの設定画面で表示される Allow password recovery を実行する必要があります。
AWS CLI の場合
AWS CLI では、ログインプロファイル、アクセスキー、署名証明書、MFA（物理・仮想とも）デバイスの削除がそれぞれ異なる AWS API となりますので、以下の公式ドキュメント Perform a privileged task on an AWS Organizations member account に記載がある通り、aws sts assume-root を実行した上で、それぞれに対応する AWS CLI コマンドを実行し、root アカウントのクレデンシャル情報を削除していくこととなります。
root アカウントの各種認証情報を削除すべき対象のメンバーアカウントが多い場合など、プログラムを作成して逐次実行していくような場合には AWS CLI が有用ですが、一つ二つなど少ないメンバーアカウントを対象にするような場合は、マネジメントコンソールで実行してしまったほうが速そうです。
- Delete root user credentials. Use the following commands to delete root access. You can remove the root user password, access keys, signing certificates, and deactivate and delete multi-factor authentication (MFA) to remove all access to and recovery of the root user.
まとめ
これまでのベストプラクティスでは、root アカウントに対しては MFA デバイスを設定し、ログインプロファイルとの併用をすることで厳格な保護を促すものでした。
今回のアップデートで root アカウントでしか行えない特権的なアクションのうちいくつかを AWS Organizations の管理アカウントから行えるようにすることで、メンバーアカウントの root アカウント自体へのログインの必要性を下げてくれるアップデートが提供されたことで、そもそもメンバーアカウントの root アカウントにログインプロファイル自体設定しなくても良い運用が模索できることになりました。
いくつか root アカウントでしか行えない作業は引き続き残るものの、アカウントの閉鎖など従来から管理アカウントで行えていた管理で代替できる作業だったり、そもそも頻度が高くない行為が多いと思いますので、運用の変更が可能そうかご検討いただくと良いかと思われます。
本記事がどなたかのお役に立てば幸いです。
ではまた。
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X（Twitter）：@kazzpapa3（AWS Community Builder）
