Muokkaa

Jaa

Storage Accounts and reliability

  • Artikkeli

Azure Storage Accounts are ideal for workloads that require fast and consistent response times, or that have a high number of input output (IOP) operations per second. Storage accounts contain all your Azure Storage data objects, which include:

  • Blobs
  • File shares
  • Queues
  • Tables
  • Disks

Storage accounts provide a unique namespace for your data that's accessible anywhere over HTTP or HTTPS.

For more information about the different types of storage accounts that support different features, reference Types of storage accounts.

To understand how an Azure storage account supports resiliency for your application workload, reference the following articles:

The following sections include design considerations, a configuration checklist, and recommended configuration options specific to Azure storage accounts and reliability.

Design considerations

Azure storage accounts include the following design considerations:

  • General purpose v1 storage accounts provide access to all Azure Storage services, but may not have the latest features or the lower per-gigabyte pricing. It's recommended to use general purpose v2 storage accounts, in most cases. Reasons to use v1 include:

    • Applications require the classic deployment model.
    • Applications are transaction intensive or use significant geo-replication bandwidth, but don't require large capacity.
    • The use of a Storage Service REST API that is earlier than February 14, 2014, or a client library with a version earlier than 4.x is required. An application upgrade isn't possible.

For more information, reference the Storage account overview.

  • Storage account names must be between three and 24 characters and may contain numbers, and lowercase letters only.
  • For current SLA specifications, reference SLA for Storage Accounts.
  • Go to Azure Storage redundancy to determine which redundancy option is best for a specific scenario.
  • Storage account names must be unique within Azure. No two storage accounts can have the same name.

Checklist

Have you configured your Azure Storage Account with reliability in mind?

  • Turn on soft delete for blob data.
  • Use Microsoft Entra ID to authorize access to blob data.
  • Consider the principle of least privilege when you assign permissions to a Microsoft Entra security principal through Azure RBAC.
  • Use managed identities to access blob and queue data.
  • Use blob versioning or immutable blobs to store business-critical data.
  • Restrict default internet access for storage accounts.
  • Enable firewall rules.
  • Limit network access to specific networks.
  • Allow trusted Microsoft services to access the storage account.
  • Enable the Secure transfer required option on all your storage accounts.
  • Limit shared access signature (SAS) tokens to HTTPS connections only.
  • Avoid and prevent using Shared Key authorization to access storage accounts.
  • Regenerate your account keys periodically.
  • Create a revocation plan and have it in place for any SAS that you issue to clients.
  • Use near-term expiration times on an impromptu SAS, service SAS, or account SAS.

Configuration recommendations

Consider the following recommendations to optimize reliability when configuring your Azure Storage Account:

Recommendation Description
Turn on soft delete for blob data. Soft delete for Azure Storage blobs enables you to recover blob data after it has been deleted.
Use Microsoft Entra ID to authorize access to blob data. Microsoft Entra ID provides superior security and ease of use over Shared Key for authorizing requests to blob storage. It's recommended to use Microsoft Entra authorization with your blob and queue applications when possible to minimize potential security vulnerabilities inherent in Shared Key. For more information, reference Authorize access to Azure blobs and queues using Microsoft Entra ID.
Consider the principle of least privilege when you assign permissions to a Microsoft Entra security principal through Azure RBAC. When assigning a role to a user, group, or application, grant that security principal only those permissions necessary for them to perform their tasks. Limiting access to resources helps prevent both unintentional and malicious misuse of your data.
Use managed identities to access blob and queue data. Azure Blob and Queue storage support Microsoft Entra authentication with managed identities for Azure resources. Managed identities for Azure resources can authorize access to blob and queue data using Microsoft Entra credentials from applications running in Azure virtual machines (VMs), function apps, virtual machine scale sets, and other services. By using managed identities for Azure resources together with Microsoft Entra authentication, you can avoid storing credentials with your applications that run in the cloud and issues with expiring service principals. Reference Authorize access to blob and queue data with managed identities for Azure resources for more information.
Use blob versioning or immutable blobs to store business-critical data. Consider using Blob versioning to maintain previous versions of an object or the use of legal holds and time-based retention policies to store blob data in a WORM (Write Once, Read Many) state. Immutable blobs can be read, but can't be modified or deleted during the retention interval. For more information, reference Store business-critical blob data with immutable storage.
Restrict default internet access for storage accounts. By default, network access to Storage Accounts isn't restricted and is open to all traffic coming from the internet. Access to storage accounts should be granted to specific Azure Virtual Networks only whenever possible or use private endpoints to allow clients on a virtual network (VNet) to access data securely over a Private Link. Reference Use private endpoints for Azure Storage for more information. Exceptions can be made for Storage Accounts that need to be accessible over the internet.
Enable firewall rules. Configure firewall rules to limit access to your storage account to requests that originate from specified IP addresses or ranges, or from a list of subnets in an Azure Virtual Network (VNet). For more information about configuring firewall rules, reference Configure Azure Storage firewalls and virtual networks.
Limit network access to specific networks. Limiting network access to networks hosting clients requiring access reduces the exposure of your resources to network attacks either by using the built-in Firewall and virtual networks functionality or by using private endpoints.
Allow trusted Microsoft services to access the storage account. Turning on firewall rules for storage accounts blocks incoming requests for data by default, unless the requests originate from a service operating within an Azure Virtual Network (VNet) or from allowed public IP addresses. Blocked requests include those requests from other Azure services, from the Azure portal, from logging and metrics services, and so on. You can permit requests from other Azure services by adding an exception to allow trusted Microsoft services to access the storage account. For more information about adding an exception for trusted Microsoft services, reference Configure Azure Storage firewalls and virtual networks.
Enable the Secure transfer required option on all your storage accounts. When you enable the Secure transfer required option, all requests made against the storage account must take place over secure connections. Any requests made over HTTP will fail. For more information, reference Require secure transfer in Azure Storage.
Limit shared access signature (SAS) tokens to HTTPS connections only. Requiring HTTPS when a client uses a SAS token to access blob data helps to minimize the risk of eavesdropping. For more information, reference Grant limited access to Azure Storage resources using shared access signatures (SAS).
Avoid and prevent using Shared Key authorization to access storage accounts. It's recommended to use Microsoft Entra ID to authorize requests to Azure Storage and to prevent Shared Key Authorization. For scenarios that require Shared Key authorization, always prefer SAS tokens over distributing the Shared Key.
Regenerate your account keys periodically. Rotating the account keys periodically reduces the risk of exposing your data to malicious actors.
Create a revocation plan and have it in place for any SAS that you issue to clients. If a SAS is compromised, you'll want to revoke that SAS immediately. To revoke a user delegation SAS, revoke the user delegation key to quickly invalidate all signatures associated with that key. To revoke a service SAS that's associated with a stored access policy, you can delete the stored access policy, rename the policy, or change its expiry time to a time that is in the past.
Use near-term expiration times on an impromptu SAS, service SAS, or account SAS. If a SAS is compromised, it's valid only for a short time. This practice is especially important if you can't reference a stored access policy. Near-term expiration times also limit the amount of data that can be written to a blob by limiting the time available to upload to it. Clients should renew the SAS well before the expiration to allow time for retries if the service providing the SAS is unavailable.

Next step

Storage Accounts and security