特定のオブジェクト (PUT) を Amazon S3 バケットにアップロードするための、いわゆる「署名済み」URL を作成したいと考えています。
ここまでは順調ですね。Python ライブラリbotoを使用して、必要なもの (有効期限、署名など) をすべて含む URL を作成しています。URL は次のようになります。
https://<bucketname>.s3.amazonaws.com/<key>?Signature=<sig>&Expires=<expires>&AWSAccessKeyId=<my key id>&x-amz-acl=public-read
最後のパラメーターに注意してください。
少なくとも、私が理解しているように、これは、この URL を使用して特定のバケットの特定のキーにオブジェクトをアップロードする人を制限し、オブジェクトに設定される既定の ACL を「パブリック読み取り」に制限します。
しかし、私の最後の声明はかなり間違っています。
結局のところ、この URL を使用している場合、x-amz-aclヘッダーを使用して次の操作を実行できます (同じ名前のクエリ文字列パラメーターとは対照的に、署名チェックを成功させるために設定する必要があります)。
- 「公開読み取り」に設定します。オブジェクトのアクセス許可は、「全員」の「読み取り」とバケット所有者の「フル コントロール」の 2 つのエントリで構成されます。これはかなり予想されます。
- x-amz-acl ヘッダーを省略します。オブジェクトに対する権限は、バケットごとのデフォルトと同じです (バケットの所有者がフル コントロールを持っています)。なんで？
- 「public-read-write」に設定します。結果は(1)とまったく同じです。
- 「認証済み読み取り」に設定します。「認証されたユーザー」は「読み取り」権限を取得し、バケット所有者はフル コントロールを持ちます。
- 「bucket-owner-read」に設定します。結果は（2）とまったく同じです。バケット所有者はフル コントロールを持ち、他の権限は定義されていません。
- 「bucket-owner-full-control」に設定します。当然のことながら、バケットの所有者が完全に制御できます。
- 存在しない既定の ACL 名に設定すると、エラーが発生します。
どうやら、それは
- x-amz-aclヘッダーは、自由に変更でき、リクエストが成功するため、署名チェックには参加しません。ただし、クエリ文字列パラメーターは、署名チェック中に確実に考慮されます。
- x-amz-aclクエリ文字列パラメーターは、オブジェクトのアクセス許可に直接影響しません。つまり、それ自体では何もしません。
- x-amz-acl ヘッダーを送信した場合、結果のアクセス許可は決して
- デフォルトよりもバケット所有者に対する制限が厳しくなります。
- バケット所有者以外の制限が緩和されます。
- ただし、バケット所有者以外の場合は、より制限が厳しくなる可能性があります。つまり
x-amz-acl=public-read、クエリ文字列で指定すると、x-amz-aclヘッダーを設定してauthenticated-read、パブリックに読み取り可能なオブジェクトの代わりに、認証されたユーザーのみが読み取ることができるオブジェクトを取得できます。
x-amz-acl QS パラメーターと同じ名前のヘッダーの間の実際の関係は何ですか? PUTいわゆる「署名済み」URL へのリクエストを介してアップロードされるオブジェクトのアクセス許可を制限する方法はありますか?