はじめに

S3署名付きURL発行機能を触っていたのですが、仕様がおもしろかったので整理します。

結論から言うと、以下の記事原文と、その解説を行ってくれている記事２つが全てです。

その本質は「URLを発行するIAMユーザーまたはロールで可能なS3に対する操作を、URLを介して、期限付きでできるようにする」です。

やってみた

適当に拾った犬の画像でテストします（可愛いから）。

バケットとオブジェクトを用意します。

S3コマンドで署名をテストするので、
CloudShellとS3:GetObjectのみを許可するユーザーグループを作成します。

早速動作確認します。

まずは何もせずにGETしてみます。

403が返却されます。
ブラウザでも同様の表示が確認できます。

aws cliで署名付きURL発行コマンドを実行します。

ドキュメントを見るに、以下の形式でよさそうです。
aws s3 presign s3://DOC-EXAMPLE-BUCKET1/mydoc.txt --expires-in 604800
実際にCloudshell内でコマンドを実行してみます。

コマンドを実行すると、長いURLが返却されました。

ブラウザでURLを入力すると、可愛い犬の画像が表示されました。

ここまでで、署名付きURL発行には、s3:GetObjectのみ必要なことが分かりました。

逆に言うと、aws s3 presignコマンドには権限が不要なのでしょうか？
試してみます。

テスト中のユーザーが所属するユーザーグループから、s3:GetObjectを許可していたポリシーをデタッチしました。

この状態で、aws s3 presignコマンドを実行してみます。

長いURLが返却されました。コマンド自体は成功しているようです。
ブラウザで確認してみます。

よく見る403の画像が表示されました。面白いですね。

文頭にも記載しましたが、署名付きURL作成機能の本質は以下の通りです。

その本質は「URLを発行するIAMユーザーまたはロールで可能なS3に対する操作を、URLを介して、期限付きでできるようにする」です。

つまり、URLを介して、aws s3 presignコマンド実行者の権限を与えているに過ぎないわけですね。

KMSキーをS3の暗号化キーに指定し、S3:GetObject権限は持つが、KMS:Decryptなどの権限を持たないユーザーで署名付きURLを発行し、アクセスしてみると、この仕様がよく分かります。

署名付きURLを発行したユーザーがkms関連の権限を持っていないことが原因で、
オブジェクトにアクセスできない旨が記載されています。

URLのパラメータをもとに、AWS側でURL発行IAMユーザーの権限をチェックしている挙動がうかがえます。

そのため、URL発行コマンドそのものについてはポリシーなしでも可能なようです。

そんなに面白くないだろうと思って触ってみたS3の署名付きURL発行機能ですが、
仕様が少し面白かったので記事にしてみました。

こういう発見があるので、あまり興味ない機能・リソースでも、気軽に触っていきたいです。