Securing Azure data — Hardening the storage account
In this article, we cover on Azure storage account and how to secure using recommended storage account policies
What is Storage account in Azure?
An Azure storage account contains all of your Azure Storage data objects: blobs, file shares, queues, tables, and disks. The storage account provides a unique namespace for your Azure Storage data that’s accessible from anywhere in the world over HTTP or HTTPS
Types of storage accounts
Standard general-purpose — Standard storage account type for blobs, file shares, queues, and tables. Recommended for most scenarios using Azure Storage
Premium block blobs — Provides solid-state drives (SSDs) for low latency and high throughput
Premium file share — High performance file sharing, Use this account type if you want a storage account that supports both SMB and NFS file shares.
For creating storage account, please refer the link https://docs.microsoft.com/en-us/azure/storage/common/storage-account-create?tabs=azure-portal
Below are the Industry standard configurations for securing the Storage accounts
1. Ensure that ‘Secure transfer required’ is set to ‘Enabled’
The secure transfer option enhances the security of a storage account by only allowing requests to the storage account by a secure connection and enables data encryption in transit.
This ensure when API call made to security accounts only HTTPS allowed
Azure command to validate
az storage account list — query [*].[name,enableHttpsTrafficOnly]
The default value is disabled, to enable
az storage account update — name — resource-group — https-only true
2. Ensure that storage account access keys are periodically regenerated
When a storage account is created, Azure generates two 512-bit storage access keys, which are used for authentication when the storage account is accessed. Rotating these keys periodically ensures that any inadvertent access or exposure does not result in these keys being compromised
Azure command to check all account
1. Get a list of storage accounts**
az storage account list
Make a note of id, name and resourceGroup.
2. For every storage account make sure that key is regenerated in past 90 days.
az monitor activity-log list — namespace Microsoft.Storage — offset 90d — query “[?contains(authorization.action, ‘regenerateKey’)]” — resource-id
The output should contain
“authorization”/”scope”: AND “authorization”/”action”: “Microsoft.Storage/storageAccounts/regenerateKey/action” AND “status”/”localizedValue”: “Succeeded” “status”/”Value”: “Succeeded”
3. Ensure Storage logging is enabled for Queue service for read, write, and delete requests
The Storage Queue service stores messages that may be read by any client who has access to the storage account. A queue can contain an unlimited number of messages, each of which can be up to 64KB in size using version 2011–08–18 or newer. Storage Logging happens server-side and allows details for both successful and failed requests to be recorded in the storage account. These logs allow users to see the details of read, write, and delete operations against the queues. Storage Logging log entries contain the following information about individual requests: Timing information such as start time, end-to-end latency, and server latency, authentication details , concurrency information and the sizes of the request and response messages.
Storage Analytics logging is not enabled by default for your storage account
For checking in command line
az storage logging show — services q — account-name
Use the below command to enable the Storage Logging for Queue service for 90 days retention
az storage logging update — account-name — account-key — services q — log rwd — retention 90
4. Ensure that shared access signature tokens expire within an hour
A shared access signature (SAS) is a URI that grants restricted access rights to Azure Storage resources, the recommended setting should be set as low as possible and preferably no longer than an hour.
5. Ensure that ‘Public access level’ is set to Private for blob containers
Another recommended configuration is Disable anonymous access to blob containers and disallow blob public access on storage account.
Ensure the below command output contains null
az storage container list — account-name — account-key — query ‘[*].properties.publicAccess’
Ensure allowBlobPublicAccess is false
az storage account show — name — resource-group — query allowBlobPublicAccess — output tsv
1. Identify the container name from the audit command
2. 2. Set the permission for public access to private(off) for the above container name, using the below command
az storage container set-permission — name — public-access off — account-name — account-key
3. Set Disabled if no anonymous access is wanted on the storage account
az storage account update — name — resource-group — allow-blob-public-access false
6. Ensure Storage logging is enabled for Table service for read, write, and delete requests
The Storage Table storage is a service that stores structure NoSQL data in the cloud, providing a key/attribute store with a schema less design. Storage Logging happens server[1]side and allows details for both successful and failed requests to be recorded in the storage account. These logs allow users to see the details of read, write, and delete operations against the tables. Storage Logging log entries contain the following information about individual requests: Timing information such as start time, end-to-end latency, and server latency, authentication details , concurrency information and the sizes of the request and response messages.
Storage Analytics logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor individual requests and to diagnose issues with a storage service. Requests are logged on a best-effort basis.
Ensure the below command’s output contains properties delete, read and write set to true
az storage logging show — services t — account-name <storageAccountName>
Use the below command to enable the Storage Logging for Table service for 90 days
az storage logging update — account-name — account-key — services t — log rwd — retention 90
7. Ensure default network access rule for Storage Accounts is set to deny
Storage accounts should be configured to deny access to traffic from all networks (including internet traffic). Access can be granted to traffic from specific Azure Virtual networks, allowing a secure network boundary for specific applications to be built. Access can also be granted to public internet IP address ranges, to enable connections from specific internet or on-premises clients. When network rules are configured, only applications from allowed networks can access a storage account. When calling from an allowed network, applications continue to require proper authorization (a valid access key or SAS token) to access the storage account.
Ensure default Action is not set to Allow.
az storage account list — query ‘[*].networkRuleSet’
Use the below command to update default-action to Deny.
az storage account update — name — resource-group — default-action Deny
8. Ensure ‘Trusted Microsoft Services’ is enabled for Storage Account access
Some Microsoft services that interact with storage accounts operate from networks that can’t be granted access through network rules. To help this type of service work as intended, allow the set of trusted Microsoft services to bypass the network rules. These services will then use strong authentication to access the storage account. If the Allow trusted Microsoft services exception is enabled, the following services: Azure Backup, Azure Site Recovery, Azure DevTest Labs, Azure Event Grid, Azure Event Hubs, Azure Networking, Azure Monitor and Azure SQL Data Warehouse (when registered in the subscription), are granted access to the storage account.
Turning on firewall rules for storage account will block access to incoming requests for data, including from other Azure services. This includes using the Portal, writing logs, etc. We can re-enable functionality. The customer can get access to services like Monitor, Networking, Hubs, and Event Grid by enabling “Trusted Microsoft Services” through exceptions. Also, Backup and Restore of Virtual Machines using unmanaged disks in storage accounts with network rules applied is supported via creating an exception.
Ensure bypass contains AzureServices
az storage account list — query ‘[*].networkRuleSet’
Use the below command to update trusted Microsoft services.
az storage account update — name — resource-group — bypass AzureServices
9. Ensure soft delete is enabled for Azure Storage
The Azure Storage blobs contain data like ePHI, Financial, secret or personal. Erroneously modified or deleted accidentally by an application or other storage account user cause data loss or data unavailability. It is recommended the Azure Storage be made recoverable by enabling soft delete configuration. This is to save and recover data when blobs or blob snapshots are deleted
Enabling this configuration for azure storage ensures that even if blobs/data were deleted from the storage account, Blobs/data objects remain recoverable for a particular time which set in the “Retention policies” [Retention policies can be 7 days to 365 days].
Ensure that the output of the below command contains enabled status as true and days is not empty or null
az storage blob service-properties delete-policy show — account-name
Update retention days in below command
az storage blob service-properties delete-policy update — days-retained — account-name — enable true
10. Ensure storage for critical data are encrypted with Customer Managed Key
Best practice for customer data, use customer managed key rather than Microsoft Managed keys
11. Ensure Storage logging is enabled for Blob service for read, write, and delete requests
Storage Logging happens server-side and allows details for both successful and failed requests to be recorded in the storage account. These logs allow users to see the details of read, write, and delete operations against the blobs. Storage Logging log entries contain the following information about individual requests: Timing information such as start time, end-to-end latency, and server latency, authentication details , concurrency information and the sizes of the request and response messages.
Storage Analytics logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor individual requests and to diagnose issues with a storage service.
Ensure the below command’s output contains properties delete, read and write set to true.
az storage logging show — services b — account-name <storageAccountName>
Use the below command to enable the Storage Logging for Blob service for 90 days retention
az storage logging update — account-name — account-key — services b — log rwd — retention 90
Configuring the cloud storage is very important to enterprises storing the sensitive data on the cloud. The above configurations are is based on the CIS benchmark recommendation and hardens the security on the Azure cloud storage
References:
1. https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations
