◆記事概要
CL事業部の相澤です。
前回の検証で、バケットポリシーを作成しましたが、一歩間違えばどこからも触ることのできないゾンビバケットになってしまうところでした。
バケットポリシーの内容、ゾンビバケットとその修正などについて、前回の検証で苦戦した内容を書いていきます。
◆目次
◆筆者情報・取得資格
AWSは実務未経験、オンプレミスのインフラ経験が2年あります。
AWSの資格は、SAA→SAP→DVA→SOA→CLFを順に取得しています。
◆本文
・作成したバケットポリシー
今回作成したバケットポリシーはこちらです。
バケットポリシーを適用した結果、コンソールからバケット操作が一切できなくなってしまいました。
このポリシーは、"Deny"でS3バケットへのすべてのアクションを拒否しています。例外は、"StringNotEquals"で記述したVPCエンドポイントです。
前回の検証ではプライベートインスタンス→ゲートウェイエンドポイント→S3以外の接続を拒否するようにしたので、想定通りではあります。
・起こりうる問題
仮にゲートウェイを間違えた場合、"StringNotEquals"にゲートウェイを記述し忘れた場合、このS3バケットはどこからもアクセスできないゾンビバケットとなります。
その場合、ルートユーザーでログインし、バケットを修正するしか、解決方法はありません。
[AWS公式での回答]
Regain access to an Amazon S3 bucket | AWS re:Post
・今回のバケットポリシーの修正について
ゲートウェイからはバケットを修正できるので、CLIでバケットポリシーを削除・修正できます。
しかし、バケットポリシーを修正するにはスクリプトを作成する必要があるらしいので、
今回はバケットポリシーの削除をCLIで行いました。
aws s3api delete-bucket-policy --bucket [S3バケット]
・修正したバケットポリシー
再度バケットポリシーを作成しました。修正したバケットポリシーはこちらです。
コンソールからでもバケットを触ることが可能になり、格納されたオブジェクトにはコンソールでは触れられなくなります。オブジェクトのアップロード、ダウンロードもアクセス拒否されます。
もちろん、ゲートウェイエンドポイントを経由した接続ではすべてのアクションが可能です。
◆まとめ・最後に
バケットポリシーは丁寧に、確認をしながら作成するべきだと感じました。
バケットポリシーは、極力権限を最小にするのがベストプラクティスと考えています。しかし、一歩間違えると、どこからもアクセスできないといったインシデントが発生します。
バケットポリシーは慎重に作成し、確認を怠らないようにしましょう。
