はじめに
S3でバケットポリシーを使ったことがある方は、1回は以下のような光景を見たことがあるんじゃないでしょうか。
経験ある方は原因をご存じだと思いますが、これはバケットポリシーの設定ミスによって引き起こされる誰もアクセスできないS3バケットになります。
この記事だと、この状態のS3バケットを"ゾンビバケット"と呼んでいるようです。
今回はこのS3バケットを復旧させる手順を試してみました。
作業内容
前提
S3バケットポリシーには元々以下のポリシーが設定されていましたが、そこから間違ってCondition部分だけを削除してしまった、という想定とします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::test-deny-error-bucket",
"arn:aws:s3:::test-deny-error-bucket/*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"XXX.XXX.XXX.XXX/32"
]
}
}
}
]
}
復旧作業
どのように復旧したらよいかは以下のページに記載があります。
https://repost.aws/ja/knowledge-center/s3-accidentally-denied-access
手順部分だけ抜粋します。
- アカウントルートユーザーとして AWS マネジメントコンソールにサインインします。
- Amazon S3 コンソールを開きます。
- 正しく設定されていないバケットに移動します。
- [権限] タブを選択します。
- [バケットポリシー] を選択します。
- [削除] を選択します。
- バケットポリシーの削除ページで、テキストフィールドに「delete」と入力して、バケットポリシーの削除を確認します。
- [削除] を選択します。
- AWS マネジメントコンソールからサインアウトします。
実際に作業を行う前に以下の部分はよく読んでおきます。
今回の作業はルートユーザーを使用しますが、ルートユーザーは通常作業に使用するべきでないユーザーですので、今回のような"ルートユーザーを使わないとどうしようもなくなってしまった"時だけ十分に気を付けて作業を行います。
**重要:**ルートユーザーを日常業務に使用しないでください。これらの認証情報の使用は、ルートユーザーとしてサインインする必要があるタスクのみに制限してください。ルート認証情報は、完全な管理者アクセス権を持つ AWS Identity Access Management (IAM) ユーザーまたはロールとは異なります。許可または拒否の権限を持つ IAM ポリシーをルートアカウントにアタッチすることはできません。
ルートユーザー以外で削除
まずはルートユーザー以外でバケットポリシーの操作ができないか試してみます。
検証にはSSOユーザーを利用し、AdministratorAccess権限を付与しています。
コンソールからアクセスしてみますがバケットポリシーで拒否されているので何も操作ができません。
もちろんAWSCLIからもアクセスできません。
$ aws s3 ls test-deny-error-bucket
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
ルートユーザーで削除
では、ルートユーザーでマネジメントコンソールにログインして、S3バケットポリシーの削除を行います。
S3コンソールから見た限りは先ほどの表示と特に変わりません。
S3バケットにアクセスして権限タブからバケットポリシーを確認すると、先ほどはエラーになっていましたが、エラーが出ずにポリシーが表示されていました。
※今回はポリシー自体を削除しますが、編集ボタンを押下するとポリシーの編集も可能です。
アクセス確認
最初にアクセスしていたSSOユーザー側のコンソールで確認するとエラーの文字が消えていることがわかります。
正しいバケットポリシーを設定し直して復旧完了です。
ルートユーザーは忘れずにサインアウトしておきましょう。
おわりに
ルートユーザーを使用すればアクセスできなくなったS3バケットポリシーを削除できることは知っていましたが、試したことはなかったので実施してみました。
弊社は希望すれば1人に対してAWSの検証環境をもらえるんですが、ルートユーザーは流石にもらえないので、今回は個人で保有しているAWSアカウントで試してみました。
会社でAWSアカウントを利用しているのであれば、恐らくルートユーザーを管理する人が社内にいると思いますので、本作業はその方に依頼して対応していただくことになるかと思います。
この記事がどなたかの参考になれば幸いです。