Authorize access to data in Azure Storage

Each time you access data in your storage account, your client application makes a request over HTTP/HTTPS to Azure Storage. By default, every resource in Azure Storage is secured, and every request to a secure resource must be authorized. Authorization ensures that the client application has the appropriate permissions to access a particular resource in your storage account.

Understand authorization for data operations

The following table describes the options that Azure Storage offers for authorizing access to data:

Azure artifact Shared Key (storage account key) Shared access signature (SAS) Azure Active Directory (Azure AD) On-premises Active Directory Domain Services Anonymous public read access Storage Local Users
Azure Blobs Supported Supported Supported Not supported Supported but not recommended Supported, only for SFTP
Azure Files (SMB) Supported Not supported Supported, only with AAD Domain Services Supported, credentials must be synced to Azure AD Not supported Supported
Azure Files (REST) Supported Supported Not supported Not supported Not supported Not supported
Azure Queues Supported Supported Supported Not Supported Not supported Not supported
Azure Tables Supported Supported Supported Not supported Not supported Not supported

Each authorization option is briefly described below:

  • Shared Key authorization for blobs, files, queues, and tables. A client using Shared Key passes a header with every request that is signed using the storage account access key. For more information, see Authorize with Shared Key.

    Microsoft recommends that you disallow Shared Key authorization for your storage account. When Shared Key authorization is disallowed, clients must use Azure AD or a user delegation SAS to authorize requests for data in that storage account. For more information, see Prevent Shared Key authorization for an Azure Storage account.

  • Shared access signatures for blobs, files, queues, and tables. Shared access signatures (SAS) provide limited delegated access to resources in a storage account via a signed URL. The signed URL specifies the permissions granted to the resource and the interval over which the signature is valid. A service SAS or account SAS is signed with the account key, while the user delegation SAS is signed with Azure AD credentials and applies to blobs only. For more information, see Using shared access signatures (SAS).

  • Azure Active Directory (Azure AD) integration for authorizing requests to blob, queue, and table resources. Microsoft recommends using Azure AD credentials to authorize requests to data when possible for optimal security and ease of use. For more information about Azure AD integration, see the articles for either blob, queue, or table resources.

    You can use Azure role-based access control (Azure RBAC) to manage a security principal's permissions to blob, queue, and table resources in a storage account. You can also use Azure attribute-based access control (ABAC) to add conditions to Azure role assignments for blob resources.

    For more information about RBAC, see What is Azure role-based access control (Azure RBAC)?.

    For more information about ABAC and its feature status, see:

    What is Azure attribute-based access control (Azure ABAC)?

    The status of ABAC condition features

    The status of ABAC condition features in Azure Storage

  • Azure Active Directory Domain Services (Azure AD DS) authentication for Azure Files. Azure Files supports identity-based authorization over Server Message Block (SMB) through Azure AD DS. You can use Azure RBAC for granular control over a client's access to Azure Files resources in a storage account. For more information about Azure Files authentication using domain services, see the overview.

  • On-premises Active Directory Domain Services (AD DS, or on-premises AD DS) authentication for Azure Files. Azure Files supports identity-based authorization over SMB through AD DS. Your AD DS environment can be hosted in on-premises machines or in Azure VMs. SMB access to Files is supported using AD DS credentials from domain joined machines, either on-premises or in Azure. You can use a combination of Azure RBAC for share level access control and NTFS DACLs for directory/file level permission enforcement. For more information about Azure Files authentication using domain services, see the overview.

  • Anonymous public read access for blob data is supported, but not recommended. When anonymous access is configured, clients can read blob data without authorization. We recommend that you disable anonymous access for all of your storage accounts. For more information, see Overview: Remediating anonymous public read access for blob data.

  • Storage Local Users can be used to access blobs with SFTP or files with SMB. Storage Local Users support container level permissions for authorization. See Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP) for more information on how Storage Local Users can be used with SFTP.

Status of condition features in Azure Storage

Currently, Azure attribute-based access control (Azure ABAC) is generally available (GA) for controlling access only to Azure Blob Storage, Azure Data Lake Storage Gen2, and Azure Queues using request and resource attributes in the standard storage account performance tier. It is either not available or in PREVIEW for other storage account performance tiers, resource types, and attributes.

See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

The table below shows the current status of ABAC by storage account performance tier, storage resource type, and attribute type. Exceptions for specific attributes are also shown.

Performance tier Resource types Attribute types Specific attributes Availability
Standard Blobs
Data Lake Storage Gen2
Queues
request
resource
all except for the snapshot resource attribute for Data Lake Storage Gen2 GA
Standard Data Lake Storage Gen2 resource snapshot Preview
Standard Blobs
Data Lake Storage Gen2
Queues
principal all Preview
Premium Blobs
Data Lake Storage Gen2
Queues
request
resource
principal
all Preview

Protect your access keys

Your storage account access keys are similar to a root password for your storage account. Always be careful to protect your access keys. Use Azure Key Vault to manage and rotate your keys securely. Avoid distributing access keys to other users, hard-coding them, or saving them anywhere in plain text that is accessible to others. Rotate your keys if you believe they may have been compromised.

Important

Microsoft recommends using Azure Active Directory (Azure AD) to authorize requests against blob and queue data if possible, rather than using the account keys (Shared Key authorization). Authorization with Azure AD provides superior security and ease of use over Shared Key authorization.

To protect an Azure Storage account with Azure AD Conditional Access policies, you must disallow Shared Key authorization for the storage account. For more information about how to disallow Shared Key authorization, see Prevent Shared Key authorization for an Azure Storage account.

Next steps