Blob Security On Azure Storage - Part Three

Introduction

This article will help you learn about SAS (Shared Access Signature) on Azure Storage to keep your Azure Storage secured.

Note

Here are a few links that you should go through before heading to Azure storage security,

  • Click here for Azure Storage - Creating A Container Using Visual Studio.
  • Click here for Part One - Azure Storage components – Blob.
  • Click here for Part Two - Azure Blob Storage Service – Uploading a Blob and Set Container propertied with metadata.

Shared Access Signature (SAS)

Shared Access Signature is called SAS for shot. SAS is a URI that grants the restricted access rights to Azure Storage resources. You can provide a SAS to clients who should not be trusted with your Azure Storage account key but for whom you wish to delegate access to certain storage account resources. By distributing a shared access signature URI to these clients, you can grant them access to the resource for a specific period time. The Service – Level SAS delegates access to multiple storage services like the blob, files, tables, and queues.

Note
Stored Access Policies are currently not supported for an account-level SAS.

Example of where SAS can be used

SAS can be used for scenarios where users read and write their own data to your storage account, where two typical design patterns exist.

Clients upload and download the data via a front-end proxy service, which performs authentication. This front-end proxy service has the advantage of allowing validation with business rules like for large amounts of data or high volume transactions, as creating a service that can scale to match the demand may be expensive or difficult.

Azure Storage

A lightweight service authenticates the client as needed and then generates a SAS. Once the client receives the SAS, they can access the Storage account resources directly with the permissions defined and for the interval allowed by the SAS. SAS also migrates the need for routing all the data through the front-end proxy service.

Azure Storage

Solution on accessing blob securely

Open the solution file which was created in the previous demo.

Azure Storage

Default Endpoints Protocol – HTTP or HTTPS

In the App Settings, when setting up the DefaultEndopointsProtocol, you can access the storage over HTTP or HTTPS as per the need.

Azure Storage

https: in this protocol “s” stands for Secure Sockets Layer (SSL); SSL is a secure data encryption over the network protocol.

http: this protocol is a non – s protocol without SSL.

Azure Storage

AccountKey: it gives access to the users for connecting to a storage account and accessing any blob, table, files, or queues.

Multiple Access Keys

Azure also supports you with multiple access keys for Azure Storage accounts. The maximum number of access keys a storage account can have is two and there are two access keys because you can switch to the second key while the other key is regenerated, providing uninterrupted access to the Storage account.

Azure Storage

Shared Access Signature on Azure Portal

An Access Key is a universal key for the entire storage with which you cannot restrict any app or user's access to it. Azure introduced SAS to everyone to overcome this disadvantage.

You can find the SAS on Azure Storage Account under Settings panel,

  • This service is accessible with the account of SAS, the Resource types accessible with the account SAS and permissions are valid only if they match the specified allowed resource types.
  • Start and expiry date/time are about the account on which SAS is valid.
  • You can also allocate an IP address or range of IP addresses from which to accept requests can be done.
  • The protocols permitted for a request made with the account SAS recommended type is of HTTPS.

    Azure Storage

Clicking on “Generate SAS” will generate the Shared Access Signature (SAS) token as shown below for the given timestamp.

Azure Storage

Summary

Thus, these access keys and Shared Access Signature will help you to keep your storage account secure.

<<Click here for the previous article