Best approach to create logical separation between users in Azure Blob Storage

1
votes

I'm trying to understand how cloud storage works with Azure Blob Storage. The use case is a microservice architecture with a few APIs and a frontend where the users can upload, download and delete blobs.

I have two types of blobs, one type are profile pictures and assets that may be accessed by all the users and the other type are blobs that the user has ownership and only certain users can see/download (users of the same company, website admins...).

We have 3 concepts that I'm trying to figure out the purpose:

  • Storage account, that's me, the Azure account holder.
  • Container, that can be used one for every entity/user.
  • Blobs

Upload blobs can only be possible using a frontend of my microservice architecture, so the authentication will be service to service with the new service I want to build.

Download blobs it will be exposing an URL and (here start doubts) when the user click the URL, I'm going to check against AuthService if the user has a session logged (if not, redirect to login frontend) and then I need to request if the user has permissions to download this blob.

How can I do this?

I think about click URL, check with AuthService that the user is logged, download service ask for user information and then check against blob metadata what is the blob ownership. That needs to store in the upload process information into metadata like entity_id, user_id. I don't know...

1
azureazure-storageazure-storage-blobs

1 Answers

1
votes

Did you consider implementing an API/capability in your frontend to generate a SAS URL to the specific blob the user should have access to? That way this API can verify the user permissions however you wish, and if the user's request checks out you provide him with SAS URL that will expire whenever you choose and can have read/write/delete (you choose) on a specific blob.

Also I'd highly recommend to separate storage accounts that hold system data that is entirely internal to the system, and storage accounts with blobs accessible to the user. This is become the SAS URL does contain the storage account DNS, which exposes it to DDOS and other DNS-based attacks, and therefore in my opinion you should limit their scope to only the blobs you need to let users access anyways.