Hi there! Welcome to Storage Security! In this lecture, we’re going to take a look at a few of the different storage security options that are available in Microsoft Azure. We’ll look at Azure Storage Service Encryption, Shared Access Signatures, Storage Account Keys, and Storage Analytics.

Data that is persisted to the cloud is automatically encrypted by Azure, through Azure Storage encryption. This process protects the data you store and helps you meet organizational security and compliance commitments.

Data stored in Azure Storage is encrypted and decrypted transparently using 256-bit AES encryption. 

When a new storage account is provisioned, Azure Storage encryption is automatically enabled for it – and this encryption cannot be disabled. Since data in Azure is secured by default, organizations don’t need to bother with code modifications or application changes in order to leverage Azure Storage encryption.

I should also point out that all storage accounts, whether they are standard or premium tiers, are encrypted. It’s also important to note that all Azure Storage redundancy options support encryption. Azure Storage resources, including blobs, disks, files, queues, and tables are also encrypted – along with all object metadata.

These encryption services have no effect Azure Storage performance, nor is there any additional cost for Azure Storage encryption.

For more information on Azure Storage Encryption, visit the URL that you see on your screen.

https://docs.microsoft.com/azure/storage/common/storage-service-encryption

Shared Access Signatures are another storage security feature in Azure. Shared access signatures, or SAS, provide secure delegated access to resources in a storage account - and they do so without compromising data security. Shared access signatures provide granular control over how your data can be accessed, and they allow you to control which resources can be accessed by an entity, what permissions that entity has on those resources, and how long the shared access signature is valid.

There are three types of shared access signatures that are supported by Azure Storage. They include user delegation SAS, service SAS, and account SAS.

A user delegation SAS, which applies to Blob storage only, is secured with Azure AD credentials and by the permissions specified for the SAS. 

A service SAS is secured with the storage account key and is used to delegate access to a resource in either Blob storage, Queue storage, Table storage, or Azure Files. It delegates access to a resource in just one of the services.

An account SAS is also secured with the storage account key. However, unlike a service SAS, it delegates access to resources in one or more of the storage services. The same operations that are available via a service SAS or a user delegation SAS are also available via an account SAS. 

Microsoft recommends as a best practice that you use Azure AD credentials, rather than the account key, whenever possible. They make this recommendation because the account key can be more easily compromised.

So, how exactly does a shared access signature work? Well, it’s actually rather simple.

A shared access signature, or SAS, is a signed URI that includes a special token and a set of query parameters, which includes a signature. This signed URI points to a storage resource, and the token dictates how the resource can be accessed by the client. The signature is built from the SAS parameters and then signed with the key that was originally used to create the SAS. 

When a SAS URI is presented to Azure Storage as part of a request, Azure checks the SAS parameters and signature to determine their validity for authorizing the request. Assuming the signature is valid, the request is then authorized. If the signature is NOT valid, the request is declined with a 403 “forbidden” error code.

The sample service SAS URI that you see on your screen shows the resource URI and the SAS token.

Storage Account Keys are generated by Azure when you create a storage account. Azure generates two of them – and each is 512-bits. You use these keys to authorize access to data that resides in your storage account. This is done via Shared Key authorization.

Once your storage account keys are created, you should use Azure Key Vault to manage them. You should rotate and regenerate your keys on a regular basis. Azure Key Vault simplifies this process and even allows you to perform the rotation without interrupting the applications that use them. You can also manually rotate your keys if needed.

You need to understand that storage account access keys are essentially root passwords for your storage account. That being the case, you need to ensure they are protected at all times. You should not distribute them to users, save them anywhere in plain text, nor hard code them in apps. If you think your keys may have been compromised, rotate them immediately.

Azure Storage Analytics is a service that performs logging for storage accounts. It provides metrics data for storage accounts as well. This data is typically used to trace storage requests and to analyze usage trends. It can also be used to diagnose issues with storage accounts.

Before using Azure Storage Analytics, it needs to first be enabled for each service that you wish to monitor. This can be done manually right from the Azure portal OR programmatically through the REST API or the client library.

There is a 20TB limit on the amount of data Storage Analytics can store. This limit is separate and independent from the total limit for your storage account. 

Visit the URL that you see on your screen for more information on Azure Storage Analytics.

https://docs.microsoft.com/en-us/azure/storage/common/storage-analytics