Well your correct that a valid address would be needed to access the content. But if you are being told by an api to access Z content it's easy to say "here is a sig that's only valid for the next x mins" (x being something you base on your user base) instead of anyone knowing the file name of the file (which they can get from dumping your db) from access the file without having that extra layer of protection.
Disable indexing on s3 and you need to know the direct link. Dump the table to get those links but then you still need to know the secret your app shares with s3 to create the sig needed to download from s3. I.E. They need to know Z and X and X only gets issued to people logged in and expires after a time. Knowing Z alone gets you nothing.
I do the same to protect the s3 bucket from direct access our cache pulls from (cache has a shared secret with s3 to pull from. Cache also has another signing process for the client to use to download from the cache). Client Signing for Z file is not valid for client+1. We just use a cache in-between client and s3 as we managed to get a deal thats cheaper for us then direct access to s3. But the same could be done for direct client to s3.
Disable indexing on s3 and you need to know the direct link. Dump the table to get those links but then you still need to know the secret your app shares with s3 to create the sig needed to download from s3. I.E. They need to know Z and X and X only gets issued to people logged in and expires after a time. Knowing Z alone gets you nothing.
I do the same to protect the s3 bucket from direct access our cache pulls from (cache has a shared secret with s3 to pull from. Cache also has another signing process for the client to use to download from the cache). Client Signing for Z file is not valid for client+1. We just use a cache in-between client and s3 as we managed to get a deal thats cheaper for us then direct access to s3. But the same could be done for direct client to s3.