Azure Storage Security
Azure storage security is divided into five major areas.
Management plane security
The management plane refers to the operation that affects the storage account itself. The way we control access to the services that affect the storage account is by using Azure active directory.
Role-based access control
- As we are aware that every Azure subscription has an associated Azure active directory. The Azure active directory contains users, groups, and applications. To them, we can provide access to manage resources within the Azure subscription. That resource can be a storage account, and the way we control the level of access to storage accounts is by assigning an appropriate role to the user. So we can have an owner role or contributor role or reader role that we can define.
Key Points to remember:
- When we are assigning a role, we can control access to the operations used to manage the storage account but not data objects in the account.
- However, we can give access to data objects by providing permission to read storage account keys because storage account keys enable the users to have access to data objects.
- Each role has a list of actions.
- There are some standard roles available, e.g., Owner, Reader, Contributor, etc.
- We can define a new custom role by selecting a set of actions from the list of available actions.
Data Plane security
It refers to the methods used to secure data objects (blobs, queues, tables, and files) within the storage account.
There are three ways that you can control access to the data within the storage account
- Azure active directory authorizes access to containers and queues. Azure Active Directory provides advantages over other approaches to authorization, including removing the need to store secrets in your code.
- Storage account keys provide blanket access to all data objects within the storage account.
- Shared Access Signatures, in case, if we want to provide access to certain services, for example – only to blobs, only to queues, or a combination of them. And also, if we want to control the level of access, for example – read-only, update, delete in that way, and also we wish to provide time-limited access. So we want to give access to only one year, and after that one year, we generate another SAS and present it to them for security reasons. In that case, we use shared access signatures.
We can allow public access to our blobs by setting the access level for the container that holds the blob accordingly.
Encryption in transit
Transport level Encryption using HTTPS
- Always use HTTPS when using REST APIs or accessing the object in storage.
- If we are using SAS, we can specify that only HTTPS should be applied.
Using encryption in transit for Azure file shares
- 1 does not support encryption, so connections are only allowed within the same region.
- 0 supports encryption, and cross-region access is allowed.
Client-side encryption
- Encrypt the data before being transferred to Azure storage
- When retrieving the data form Azure, data is decrypted after it is received on the client-side.
Encryption at rest
Client-side encryption
- Encrypt the data before being transferred to Azure storage.
- When retrieving the data form Azure, data is decrypted after it is received on the client-side.
Storage Service Encryption (SSE)
This is what we generally use to encrypt the data at REST is Azure storage
- It is enabled for all storage accounts and cannot be disabled.
- It automatically encrypts data in all performance tiers (Standard and premium), all deployment models (Azure Resource Manager and Classic), and all of the Azure Storage services (Blob, Queue, Table, and File). So it is blanket encryption across all Azure storage.
- We can use either Microsoft-managed keys or your custom keys to encrypt the data.
Azure Disk Encryption
This is a recommended approach from Microsoft to encrypt the disks particularly with Azure disk
- Encrypt the OS & data disks used by IaaS Virtual Machine
- You can enable encryption on existing IaaS VMs
- You can use customer-provided encryption keys
CORS (Cross-Origin Resource Sharing)
- When a web browser makes an HTTP request for a resource from a different domain, this is called a cross-origin HTTP request.
- Azure Storage allows us to enable CORS. For each storage account, we can specify domains that can access the resources in that storage account. For example, enable CORS on the mystorage.blob.core.windows.net storage account and configure it to allow access to mywebsite.com.
- CORS allows access but does not provide authentication, which means we still need to use SAS keys to access non-public storage resources.
- CORS is disabled on all services by default. We can enable it using the Azure portal or Power Shell, and we can specify the domains from where the request will come to access the data in your storage account.
