Secure Your Data: Advanced Techniques in Azure Storage Security

Introduction

In today’s digital world, protecting your data is more important than ever. Azure provides powerful tools and features to help you secure your storage and keep your information safe. Adhering to security and compliance guidelines is crucial across all storage tiers. Microsoft offers secure design principles for storage, ensuring your data is well-protected.

This blog post is designed for anyone seeking a comprehensive guide on securely configuring Azure Storage resources. We’ll walk you through advanced security techniques to ensure your data is shielded from threats. Whether you’re a seasoned professional or new to cloud security, you’ll find valuable insights to enhance your security strategy. Let’s dive in and learn how to safeguard your data in Azure.

It covers the following key aspects:

• Secure Configurations: Identifying the right configurations to achieve compliance and security.
• Risk Assessment: Understanding the risks associated with each configuration to prioritize and address them effectively.
• Control Automation: References to Azure policies that can be used as detective, corrective, or preventative controls.

Azure Storage Security Compliance

Cloud infrastructure services, such as storage accounts, come with a baseline set of configurations and provide various options that users must select based on their application needs. Many cloud security issues arise from these configurations being too “open” or insecure. For storage services, users do not have access to the host operating system. Instead, storage can be deployed within a user’s chosen network boundary, and user data is stored at rest.

You may also see below whether an Azure built-in Policy (built-in meaning available via Microsoft) is available to be used. Please note that you are also able to create custom policies via Azure policies in cases where the built-in policy is not available and in cases the risk can be controlled via a policy definition.

Policies can be created as a detective, preventative and corrective control based on the chosen “effect” of the policy (for example: Audit, Deny, Modify, etc.). Once policies have been assigned (built-in) or created (then assigned), you can view the compliance stature of your resources (beyond just storage) via the policy tab within your Azure console/UI:

Here’s the link to the Azure policy documentation Link.

Identity and access management

Ensure storage account access is configured via Azure AD

Requests to your cloud storage should be authorized by default to either use Azure AD or access keys. Please note that it is recommended to use Azure AD for authorization requests since it provides a higher level of security, and it is the recommended Azure path.

Ensure storage account access keys are renewed (decided intervals)

During the creation of a storage service, access keys are auto-generated in the background which can be used for authentication (between storage and applications). Please note that it is recommended to use Azure AD for authorization requests.

Ensure SAS tokens are set with an expiry

SAS tokens are an alternative to using account access keys (for fine-grained access) and are an option when you want to provide limited permissions of your storage, to users or applications. It provides secure delegated access to resources in your storage account. With SAS, you have granular control over how a client can access your data. It’s best practice to provide SAS tokens with a set expiry time, to reduce the risk of exposure and unwanted access (recommended time is an hour). Refer to this link for more info on SAS types Link.

Prioritize Managed identity over SAS tokens

Managed identities are a safer way to grant access to storage data and it nulls the requirement for you to include shared access signature tokens (SAS) with your source and target container URLs. Managed identities provide an alternate method for you to grant access to your storage data.

Ensure shared access signature tokens are over HTTPS only

Ensure that your SAS tokens are configured to allow access requests over the HTTPS protocol only. A Shared Access Signature (SAS) is a URI that grants restricted access rights to your Azure Storage resources. A SAS token is the query string that includes all the information required to authenticate the Shared Access Signature, as well as to specify the Azure Storage service and resource, the permissions required for access, and the timeframe for which the signature is valid.

Ensure overly permissive stored access policies are not present

A stored access policy provides an additional layer of control on top of the service-level shared access signature (SAS). A SAS URI should have limited access rights (based on the principle of least privilege).

RBAC

Beyond the IAM secure configurations, it’s also important to understand and use RBAC (Microsoft’s authorization system that controls access to Azure resources) in the correct way to securely configure your storage service. Configuring Azure Storage RBAC involves:

• Defining who can access your storage resources
• Defining what actions, they can perform
• Understanding roles, security principles (plus managed identities) and role assignments

Roles help you define permissions for accessing resources (e.g., Storage Blob Contributor, Storage Account Contributor). Security Principal is the identity requesting access (user, group, application). Role Assignment is the link between a security principal to a role at a specific scope (subscription, resource group, storage account, container).

Note that it is recommended to use Azure RBAC instead of key usage (for example SAS keys).

Network Security

The default network access rule should be set to “Deny” within your storage account

By default, access is open: all network connections are accepted. When set, this will deny access to traffic from all networks including public networks. You can also allow limited networks to access your storage by configuring those specific settings.

Ensure private endpoints are used:

Azure provides the availability of private endpoints, which essentially is a secure network “tunnel” that provides storage to use private IP addresses. Using a private endpoint, you can connect to a storage service using their private IP: without exposing them to the public. Note that the private link itself is free to use but private endpoints have cost implications. There are also limits to the number of private endpoints you can create in a subscription but there are no specific performance limitations or issues with private endpoints.

Ensure “trusted access” is enabled for Microsoft-specific services

Enabling firewall rules for your storage account will block access to incoming requests for data, including from other Azure services. To allow these Azure services to work as intended and be able to access your storage account resources, you must add an exception so that the trusted Microsoft Azure services can bypass your network rules.

Ensure public access to storage accounts with blob containers is disabled

Disable anonymous access to all the blob containers provisioned within your Azure storage accounts. To follow security best practices and keep your data safe and secure in the Azure cloud, ensure that your blob containers are not publicly exposed. Note: also ensure that the Microsoft Azure storage container where the exported activity log files are saved is not publicly accessible from the Internet, in order to avoid exposing sensitive data and minimize security risks.

Configure Minimum TLS Version

Ensure that all your Microsoft Azure Storage accounts are using the latest available version of the TLS protocol in order to enhance the security of the connection between your storage accounts and their clients/applications and comply with industry standards.

Ensure secure transfer setting is enabled

STS or secure transfer ensures that all data transferred to and from your storage account is encrypted.

Asset management

Ensure Enable Blob Storage Lifecycle Management is utilized:

Users can set lifecycle management policies to change data state (for example change data state from hot to archive) or expire data which can be very useful for security, availability and cost optimization reasons.

Ensure Cross-Tenant Object Replication is disabled

This is required to prevent object replication across other Azure tenants. This is usually done to increase redundancy and disaster recovery across tenants (which translates to organization boundaries).

Data protection:

Enable Infrastructure Encryption

By default, the data stored within your Microsoft Azure Storage accounts is automatically encrypted at rest using 256-bit AES encryption. When infrastructure encryption is enabled for a storage account or an encryption scope, data is encrypted at two levels: once at the service level and once at the infrastructure level (with two different encryption algorithms and two different keys).

The keys in question here could be either platform or customer-managed (that’s also where the distinction between infra encryption and customer-managed key lies). Note that this leads to a slight performance impact due to the double encryption and decryption. The cost involved is based on the keys being used and type (platform vs customer managed).

Make use of the immutable blob feature

The immutable blob storage feature helps you store your blob objects in a non-changeable or “immutable” form: making sure that modification or deletion operations cannot be completed. This is mainly used by applications that need to conform to more strict compliance or regulatory requirements.

Ensure you use customer-managed keys (CMKs) to encrypt data within Azure Storage accounts

When you store data in storage accounts, it is automatically encrypted using platform-managed encryption keys created and maintained by Microsoft Azure. While these keys provide security, they are still controlled by Azure. For stricter compliance or full control over your encryption keys, you should use customer-managed encryption keys. These come in a few varieties:

Note that the use of customer-managed keys has cost implications (based on type and storage location).

Logging and threat detection

Ensure diagnostic settings are enabled for storage types:

Diagnostic settings in Azure are used to collect resource logs. You can also set up metrics and logs are set up to be used via Azure monitor: please reference this official documentation Link.

Ensure Defender is deployed for storage accounts:

Azure Defender is a security management tool that helps protect Azure resources and other workloads from threats. Note that enabling a defender has cost implications.

Backup and recovery

Ensure blob versioning is enabled

Enable Blob storage versioning to automatically maintain previous versions of an object. With blob versioning enabled, earlier versions of a blob can be accessed, allowing data recovery if it is modified or deleted.

Ensure backup is enabled

Backup can help protect storage data from deletion, ransomware, and other disasters (in accidental or sabotage scenarios).