CODEWITHSUNDEEP
azureazure-storageazure-blob-storage
Ryan
Ryan

Reputation: 4414

Azure blob storage and security best practices

When exploring Azure storage I've noticed that access to a storage container is done through a shared key. There is concern where I work that if a developer is using this key for an application they're building and then leave the company that they could still login to the storage account and delete anything they want. The workaround for this would be to re-generate the secondary key for the account but then we'd have to change all of the keys in every application that uses those keys.

Is it best practice to have an entire storage account per application per environment (dev, test, staging, production)? Is it possible to secure the storage account behind a virtual network? Should we use signatures on our containers on a per application basis?

Anybody have experiences similar and have found a good pattern for dealing with this?

Upvotes: 0

Views: 6101

Answers (2)

David Makogon
David Makogon

Reputation: 71118

I won't get into subjective / opinion answers, but from an objective perspective: If a developer has a storage account key, then they have full access to the storage account. And if they left the company and kept a copy of the key? The only way to block them out is to regenerate the key.

You might assume that separating apps with different storage accounts helps. However, just keep this in mind:if a developer had access to a subscription, they had access to keys for every single storage account in that subscription.

When thinking of key regeneration, think about the total surface area of apps having knowledge of the key itself. If storage manipulation is solely a server-side operation, the impact of changing a key is minimal (a small app change in each deployment, along with updating any storage browsing tools you use). If you embedded the key in a desktop/mobile application for direct storage access, you have a bigger problem with having to push out updated clients, but you already have a security problem anyway.

Upvotes: 0

b2zw2a
b2zw2a

Reputation: 2693

I have a bit different scenario – external applications, but the problem is the same - data access security

I use Shared Access Signatures(SAS) to grant an access to a container.

In your scenario you can create Shared Access Policy per application on a container and generate SAS using this Stored Access Policy with long expiration time, you can revoke it at any point by removing Shared Access Policy from container. So in you scenario you can revoke current SAS and generate new one when your developer leaves. You can't generate single SAS for multiple containers so if you application uses multiple containers you would have to generate multiple SAS.

Usage, from the developers perspective, stays the same: You can use SAS token to create CloudStorageAccount or CloudBlobClient so it’s almost like a regular access key.

Longer term, I would probably think about creating one internal service(internal API) responsible for generating SAS and renewing them. This way you can have completely automated system and with access keys only disclosed to this main service. You can then restrict access to this service with virtual network, certificates, authentication etc. And if something goes wrong (developer who wrote that service leaves :-) ) you can regenerate access keys and change them, but this time only in one place.

Few things:

  • Storage account per application (and/or environment) is a good strategy, but you have to be aware of the limit – max 100 storage accounts per subscription.
  • There is no option to limit access to a storage account with virtual network
  • You can have maximum 5 Shared Access Policies on a single container

Upvotes: 1

Related Questions