Dealing with Azure Storage Account – know how to secure them in all possible ways

Although this is a technical blog but I don’t able to stop myself citing an incident which I have witnessed recently which is somehow related to the technical aspect of this post.

Picture Credit: Royalty free photos from pexels.com

Last September there was a case of fraudulent transaction reported by one of my very close friend. In his case fraudulent transaction has occurred in one of his credit card issued by a top global bank in Bangalore, the card was issued in India however three transaction were done in Atlanta US, my friend who is in India is unaware of the transactions because in US there is no process of MFA (Multi Factor Authentication), i.e. unlike card transaction in India, in US you will not receive the OTP in your mobile phone to authenticate the transaction. Although user has received the alert message of the transactions post the transaction happened however it was late night and he was sleeping that time (The transactions took place during 12 AM to 1 AM IST). When he saw the SMS and reported the incident to bank, bank has immediately blocked his card and issued him a temporary credit after three days. He also need to send a dispute form to the bank against those three transactions.

Post investigation it was revealed that he purchased an item from a US based small merchant website and his credit card information was stolen from there. Merchant has confirmed that his infrastructure recently migrated to Azure and the storage account has been compromised which has caused this issue for multiple customers. Although the bank has given the complete credit to my friend credit card account (Thanks to Reserve Bank of India for this notification issued in July 2017 mentioning zero liability to customer if fraudulent transaction were reported within three days) but it was the mental agony which he has faced for 45 days since fraudulent transaction in credit card are not very common in India and the bank, although credited the amount temporarily in his account informed in an email that it will be credited permanently only post investigation which will take 45 days’ time to complete, especially for the people who started using credit card only after the recent demonetization drive happened in last year Nov. in India, a fraudulent traction is a real night mare J

Now let’s see the technical side of it, if your infrastructure is in Azure and you are storing important data on them it’s very important that you should know how to protect the azure storage account. In azure storage it is very simple and easy to manage if you know some basic concepts like types of storage, permissions, use cases for each storage types etc. The storage account is one of the building block of the Azure Infrastructure and it is required for almost everything, so it’s very important that you should know how to securely access your storage account. There is another problem that most developer doesn’t concentrate on the security side of the Azure storage account while writing the code. Security is utmost important since Brute Force Attacks are very common now a days and it is very important you should use the best method available to protect the Azure Storage Account. This is also becoming very important because most of the large ecommerce websites are moving to public cloud rapidly to support their seasonal flash sales where they can easily scale out their infrastructure in need basis but during all these migration security is something which is generally neglected because that requires lots of changes in the code and delay the migration schedule of such projects.

Let’s see the security layers and features which are available to protect your azure storage account.

Various ways to protect and secure your Azure Storage Account, data inside the storage account and data which is on transit

How to protect your storage account

The first step to protect the Azure Storage Account is to protect them with RBAC (Role Based Access Control)

Understand what are the built in RBAC Roles available for the Azure storage Account – Secure and restrict the access of your storage account with RBAC roles.

When you are dealing every day with Azure Storage Account, there are few things which you should keep in your mind. All Azure Storage Account are controlled by Azure RBAC (Role Based Access Control). The following roles have some or full permissions to the Azure Storage Account

• Owners – They can manage everything including the access in the storage account. As you can see the Add button to give users access it’s missing in other

• Contributors – They can do anything the owner can do except assign access. For example if you are a contributor you can create a storage account and create a container but you can’t add user access to that storage account.

• Storage Account Contributor – They can manage the storage account – they can read the storage account and can create, modify or delete the storage accounts. They can also access and delete the content of the storage account after login through storage explorer.

It may be possible a user has been only given the above storage account contributor permission to a storage account in a resource group, if he goes to the resource group tabs he will not be able to see the resource group where I have given him the contributor access in the storage account.

For example I have given a particular user access to four resource groups out of that three are US East and one in Australia East, however I have given him the permission to a storage account which is in US West. This is what he can see when he will check his resources groups tab.

And this what he will see when he will check the storage accounts tab in Azure Portal.

• Reader – They can view information about the storage account, except secret information like storage keys. They can’t able to see the storage keys.
• User Administrator – They can grant user access to particular storage accounts
• VM Contributor – This role allow the users to manage the storage account. In order for a user to create a virtual machine, they have to be able to create the corresponding VHD file in a storage account. To do that, they need to be able to retrieve the storage account key for creating the VM through API. Therefore, they must have this permission so they can list the storage account keys.

How to Access the Storage Account Data Securely?

You can protect the storage account data with storage keys

This step is to protect the access of your storage account with the help of the storage keys

Understand the storage keys

Every storage account in Azure have two 512-bit strings keys (Key1 and Key2) created along with the storage account. These keys are used get the access to the storage account objects in a secured way. A common question which has been asked by many admins is whether it will cause any problem for the VM if we regenerate keys of the storage account where the VHD are stored. The answer is if you have VMs whose VHD files are stored in the storage account, they will not be affected by regenerating the storage account keys.

How to secure your storage keys?

The best practice to secure your storage keys is to use the Azure Key vault. When you regenerate the key and update the Azure Key Vault, the applications or any scripts will not need to be redeployed because they will pick up the new key from the Azure Key Vault automatically. This is very common and highly secure way to protect the keys even from the Admins and developers, since the keys are stored in the key vault developers don’t need to hardcode them in the script file or application so it’s can be considered as an additional layer of security. In most of our scripts which we are using for various automation tasks we regenerate storage keys with the help of keys, every 30 mins a PowerShell script will re generate the keys and write them back to Key Vault, the PowerShell script is stored in a Azure Runbooks which run in an interval of every 15 minutes. This is a very good practice which can be followed in all the enterprises to secure the keys. A reference article which may help to gather some information about how to write the PowerShell script for this purpose can be found here.

Best Practice: Always use same storage key in your application, as using of key1 for some pieces and key2 for other is not recommended. Key rotation will be successful in case you use the same key in the entire application.

How to cover the risk of 15 mins? (This interval is going to change based on your application requirement)

You know if a hacker knows the keys he can do so many things within 15 mins before the regeneration of your next set of keys, to cover this risk MS also provided another way the application should access the storage and that is called Shared Access Signature.

What is Shared Access Signature?

If you are an azure developer you must use the SAS in your application. A Shared Access Signature is a string containing a security token that can be attached to a URI that allows you to delegate access to storage objects and specify constraints such as the permissions and the date/time range of access. With Shared Access Signatures, you can give a client just the permissions required for a limited amount of time. Additionally, you can specify that requests made using a SAS are restricted to a certain IP address or IP address range external to Azure. You can also require that requests are made using a specific protocol (HTTPS or HTTP/HTTPS). This means if you only want to allow HTTPS traffic, you can set the required protocol to HTTPS only, and HTTP traffic will be blocked.

What to do when you suspect that the SAS also has been compromised?

• You can issue SAS tokens with short expiration policies and wait for the token to expire.
• You can rename or delete the resource (assuming the token was scoped for a single object).
• You can change the storage account keys immediately (But this may have larger effect and downtime for other application which is using the same storage account)

(If you have accidently deleted your storage account please refer to this blog post to see what are the options available for you)

Another two ways to protect your Azure Storage Account Data is by registering your application in Azure AD

First way

In this case the service account access will be first authenticated in Azure AD and based on that the secret key will be issued from Azure Key Vault when the application request the key.

This is an older approach where developers create an Azure AD application and associate the AD service account credential in the application code. This web application that will be accessing the Key Vault is the one that is registered in Azure Active Directory and has been given access to the Key Vault. However because of the following two limitations this method is not so secure.

• The Azure AD application service account credentials are typically hard coded in the source code
• When the Azure AD application credentials expire, application used to be down

To stop the misuse of this approach the storage keys can be changed/rotated frequently however the AD credential hard coding can’t be stopped unless the service account is stored in an azure automation account which will cause multiple authentication hops and may create latency in the application unless coded in a better way.

Second Way

To avoid this above mentioned loopholes MS has recently introduced another technique. In this new approach which has been released recently and still in public preview is the use of Azure Managed Service Identity (Preview). Here a managed service identity from Azure Active Directory allows your app to easily access other AAD-protected resources such as Azure Key Vault. The identity is managed by the Azure platform and does not require you to provision or rotate any secrets. In this case when you request a token to Key Vault, you need to make sure you have added an access policy that includes your application’s identity. Otherwise, your calls to Key Vault will be rejected, even if they include the token. A more details about the Azure MSI can be found here.

How to protect the storage account data on transit?

There are three ways to protect your data transport in Azure Storage Account.

The first one is the transport level encryption.

To protect the data which is on transit, it’s always advisable to encrypt the data with the transport level encryption. This can be done with the HTTPS protocol. HTTPS ensure secure communication over public internet. Always enable secure transferred required to force the secure transit of data.

A PowerShell command can be used to enable the secure transfer

Set-AzureRmStorageAccount -Name “{StorageAccountName}” -ResourceGroupName “{ResourceGroupName}” -EnableHttpsTrafficOnly $True

StorageAccountName : {StorageAccountName}

Kind : Storage

EnableHttpsTrafficOnly: True

A common example is when you need to upload important data from your on premise data center to Azure.

In the below example I have used AzCopy to move the data from on-premises to Azure with the help of HTTPS protocol.

Copy data (From On-Premises to Azure Blob container)

Copy data (From Blob Container to Azure VM)

The second method is the use of Azure File shares

You can mount an Azure File Share and enable the secure transfer with the SMB 3.0 protocol. In this case also you need to enable the Secure Transfer Required switch.

The third method is the use of the Client-side encryption

Client-side encryption is also a method for encrypting your data at rest, as the data is stored in its encrypted form.  This feature allows you to programmatically encrypt your data in a client application before sending it across the wire to be written to Azure Storage, and to programmatically decrypt your data after retrieving it from Azure Storage. To know more about the client side encryption please click here

How to protect the storage account data when the data is at rest?

There are three ways to protect your storage data which is at rest, the first one is what I have mentioned above is the use of client-side encryption which also secure the data in the storage account post transit but using https protocol while transit of data is widely used and very simple to configure.

There are other two methods also available which can be used to store the data in encrypted form when it is at rest. The first one is the Azure Disk Encryption and this is commonly used for VM’s.

Azure Disk Encryption is another new feature which is widely used now a days for the Azure IaaS VM’s. This allow the encryption of the OS disk and data disks in the VM. If you are using a windows OS disks are encrypted with the Bitlocker technology and for the Linux VM disks are encrypted with DM-Crypt technology.

The 3^rd technique to protect the data which is at rest is the use of the Storage Service Encryption (SSE), SSE allows you to write the data in the storage account in encrypted form, when the request of read the data originate, it again decrypt the data and send back to the requester. This enables you to secure your data without having to modify code or add code to any applications. As you can see below there is switch which allows to enable this feature. This settings is applicable to the entire storage account.

How to protect the storage account at the network level?

Although there are many ways you can protect the storage account but it’s always good if you can protect them at the network layer as by securing this layer you can easily discard 90% of the attacks. Microsoft has recently released a solution for this and that is Azure Storage Firewalls and Virtual Networks (preview), like any network firewall, implementing this will help to allow users to access the storage account only from specific allowed network subnets. This is in conjunction with the Azure Storage Account Security is a very good way to protect your storage account from every day attacks. IP network rules are only allowed for public internet IP addresses. IP address ranges reserved for private networks are not allowed in IP rules. Private networks include addresses that start with *10. **, *172.16. **, and *192.168.**, Only IPV4 addresses are supported at this time. Each storage account can support up to 100 IP network rules.

Note: Currently if you try to connect your Azure Storage Account from on premises it will follow the public internet path but with this new technology you can grant access from your on-premises networks to your storage account with an IP network rule, site to site VPN is not supported yet however Azure ExpressRoute Circuit is supported.

Since the Storage Firewalls and Virtual Networks are in preview. This capability is currently only available for new or existing storage accounts in all Azure public cloud regions.

Conclusion

Securing the Azure storage Account is an important criteria for most of the Azure related development work and it’s the responsibility of the Azure Admin to make the developers make aware of all the possible security features available in Azure to secure the Azure storage. In this article I have tried to jot down various ways available to secure your azure storage account. Use of Azure Storage Firewalls and Virtual Network and proper access with RBAC and proper authorization with Azure Storage Keys and/or SAS tokens is going to be very good combination for all the future related development in this area.