Azure Policy built-in definitions for Azure Storage
This page is an index of Azure Policy built-in policy definitions for Azure Storage. For additional Azure Policy built-ins for other services, see Azure Policy built-in definitions.
The name of each built-in policy definition links to the policy definition in the Azure portal. Use the link in the Version column to view the source on the Azure Policy GitHub repo.
Microsoft.Storage
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| [Preview]: Azure Backup should be enabled for Blobs in Storage Accounts | Ensure protection of your Storage Accounts by enabling Azure Backup. Azure Backup is a secure and cost effective data protection solution for Azure. | AuditIfNotExists, Disabled | 1.0.0-preview |
| [Preview]: Configure backup for blobs on storage accounts with a given tag to an existing backup vault in the same region | Enforce backup for blobs on all storage accounts that contain a given tag to a central backup vault. Doing this can help you manage backup of blobs contained across multiple storage accounts at scale. For more details, refer to https://aka.ms/AB-BlobBackupAzPolicies | DeployIfNotExists, AuditIfNotExists, Disabled | 2.0.0-preview |
| [Preview]: Configure blob backup for all storage accounts that do not contain a given tag to a backup vault in the same region | Enforce backup for blobs on all storage accounts that do not contain a given tag to a central backup vault. Doing this can help you manage backup of blobs contained across multiple storage accounts at scale. For more details, refer to https://aka.ms/AB-BlobBackupAzPolicies | DeployIfNotExists, AuditIfNotExists, Disabled | 2.0.0-preview |
| [Preview]: Storage account public access should be disallowed | Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it. | audit, Audit, deny, Deny, disabled, Disabled | 3.1.0-preview |
| [Preview]: Storage Accounts should be Zone Redundant | Storage Accounts can be configured to be Zone Redundant or not. If a Storage Account's SKU name does not end with 'ZRS' or its kind is 'Storage,' it is not Zone Redundant. This policy ensures that your Storage Accounts use ae Zone Redundant configuration. | Audit, Deny, Disabled | 1.0.0-preview |
| Azure File Sync should use private link | Creating a private endpoint for the indicated Storage Sync Service resource allows you to address your Storage Sync Service resource from within the private IP address space of your organization's network, rather than through the internet-accessible public endpoint. Creating a private endpoint by itself does not disable the public endpoint. | AuditIfNotExists, Disabled | 1.0.0 |
| Configure Azure File Sync with private endpoints | A private endpoint is deployed for the indicated Storage Sync Service resource. This enables you to address your Storage Sync Service resource from within the private IP address space of your organization's network, rather than through the internet-accessible public endpoint. The existence of one or more private endpoints by themselves does not disable the public endpoint. | DeployIfNotExists, Disabled | 1.0.0 |
| Configure diagnostic settings for Blob Services to Log Analytics workspace | Deploys the diagnostic settings for Blob Services to stream resource logs to a Log Analytics workspace when any blob Service which is missing this diagnostic settings is created or updated. | DeployIfNotExists, AuditIfNotExists, Disabled | 4.0.0 |
| Configure diagnostic settings for File Services to Log Analytics workspace | Deploys the diagnostic settings for File Services to stream resource logs to a Log Analytics workspace when any file Service which is missing this diagnostic settings is created or updated. | DeployIfNotExists, AuditIfNotExists, Disabled | 4.0.0 |
| Configure diagnostic settings for Queue Services to Log Analytics workspace | Deploys the diagnostic settings for Queue Services to stream resource logs to a Log Analytics workspace when any queue Service which is missing this diagnostic settings is created or updated. Note: This policy is not triggered upon Storage Account creation and requires creation of a remediation task in order to update for the account. | DeployIfNotExists, AuditIfNotExists, Disabled | 4.0.1 |
| Configure diagnostic settings for Storage Accounts to Log Analytics workspace | Deploys the diagnostic settings for Storage accounts to stream resource logs to a Log Analytics workspace when any storage accounts which is missing this diagnostic settings is created or updated. | DeployIfNotExists, AuditIfNotExists, Disabled | 4.0.0 |
| Configure diagnostic settings for Table Services to Log Analytics workspace | Deploys the diagnostic settings for Table Services to stream resource logs to a Log Analytics workspace when any table Service which is missing this diagnostic settings is created or updated. Note: This policy is not triggered upon Storage Account creation and requires creation of a remediation task in order to update for the account. | DeployIfNotExists, AuditIfNotExists, Disabled | 4.0.1 |
| Configure secure transfer of data on a storage account | Secure transfer is an option that forces storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking | Modify, Disabled | 1.0.0 |
| Configure Storage account to use a private link connection | Private endpoints connect your virtual network to Azure services without a public IP address at the source or destination. By mapping private endpoints to your storage account, you can reduce data leakage risks. Learn more about private links at - https://aka.ms/azureprivatelinkoverview | DeployIfNotExists, Disabled | 1.0.0 |
| Configure storage accounts to disable public network access | To improve the security of Storage Accounts, ensure that they aren't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in https://aka.ms/storageaccountpublicnetworkaccess. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks. | Modify, Disabled | 1.0.1 |
| Configure Storage Accounts to restrict network access through network ACL bypass configuration only. | To improve the security of Storage Accounts, enable access only through network ACL bypass. This policy should be used in combination with a private endpoint for storage account access. | Modify, Disabled | 1.0.0 |
| Configure your Storage account public access to be disallowed | Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it. | Modify, Disabled | 1.0.0 |
| Configure your Storage account to enable blob versioning | You can enable Blob storage versioning to automatically maintain previous versions of an object. When blob versioning is enabled, you can access earlier versions of a blob to recover your data if it's modified or deleted. | Audit, Deny, Disabled | 1.0.0 |
| Deploy Defender for Storage (Classic) on storage accounts | This policy enables Defender for Storage (Classic) on storage accounts. | DeployIfNotExists, Disabled | 1.0.1 |
| Geo-redundant storage should be enabled for Storage Accounts | Use geo-redundancy to create highly available applications | Audit, Disabled | 1.0.0 |
| HPC Cache accounts should use customer-managed key for encryption | Manage encryption at rest of Azure HPC Cache with customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. | Audit, Disabled, Deny | 2.0.0 |
| Modify - Configure Azure File Sync to disable public network access | The Azure File Sync's internet-accessible public endpoint are disabled by your organizational policy. You may still access the Storage Sync Service via its private endpoint(s). | Modify, Disabled | 1.0.0 |
| Modify - Configure your Storage account to enable blob versioning | You can enable Blob storage versioning to automatically maintain previous versions of an object. When blob versioning is enabled, you can access earlier versions of a blob to recover your data if it's modified or deleted. Please note existing storage accounts will not be modified to enable Blob storage versioning. Only newly created storage accounts will have Blob storage versioning enabled | Modify, Disabled | 1.0.0 |
| Public network access should be disabled for Azure File Sync | Disabling the public endpoint allows you to restrict access to your Storage Sync Service resource to requests destined to approved private endpoints on your organization's network. There is nothing inherently insecure about allowing requests to the public endpoint, however, you may wish to disable it to meet regulatory, legal, or organizational policy requirements. You can disable the public endpoint for a Storage Sync Service by setting the incomingTrafficPolicy of the resource to AllowVirtualNetworksOnly. | Audit, Deny, Disabled | 1.0.0 |
| Queue Storage should use customer-managed key for encryption | Secure your queue storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. | Audit, Deny, Disabled | 1.0.0 |
| Secure transfer to storage accounts should be enabled | Audit requirement of Secure transfer in your storage account. Secure transfer is an option that forces your storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking | Audit, Deny, Disabled | 2.0.0 |
| Storage account containing the container with activity logs must be encrypted with BYOK | This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here https://aka.ms/azurestoragebyok. | AuditIfNotExists, Disabled | 1.0.0 |
| Storage account encryption scopes should use customer-managed keys to encrypt data at rest | Use customer-managed keys to manage the encryption at rest of your storage account encryption scopes. Customer-managed keys enable the data to be encrypted with an Azure key-vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more about storage account encryption scopes at https://aka.ms/encryption-scopes-overview. | Audit, Deny, Disabled | 1.0.0 |
| Storage account encryption scopes should use double encryption for data at rest | Enable infrastructure encryption for encryption at rest of your storage account encryption scopes for added security. Infrastructure encryption ensures that your data is encrypted twice. | Audit, Deny, Disabled | 1.0.0 |
| Storage account keys should not be expired | Ensure the user storage account keys are not expired when key expiration policy is set, for improving security of account keys by taking action when the keys are expired. | Audit, Deny, Disabled | 3.0.0 |
| Storage accounts should allow access from trusted Microsoft services | 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. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should be limited by allowed SKUs | Restrict the set of storage account SKUs that your organization can deploy. | Audit, Deny, Disabled | 1.1.0 |
| Storage accounts should be migrated to new Azure Resource Manager resources | Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should disable public network access | To improve the security of Storage Accounts, ensure that they aren't exposed to the public internet and can only be accessed from a private endpoint. Disable the public network access property as described in https://aka.ms/storageaccountpublicnetworkaccess. This option disables access from any public address space outside the Azure IP range, and denies all logins that match IP or virtual network-based firewall rules. This reduces data leakage risks. | Audit, Deny, Disabled | 1.0.1 |
| Storage accounts should have infrastructure encryption | Enable infrastructure encryption for higher level of assurance that the data is secure. When infrastructure encryption is enabled, data in a storage account is encrypted twice. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should have shared access signature (SAS) policies configured | Ensure storage accounts have shared access signature (SAS) expiration policy enabled. Users use a SAS to delegate access to resources in Azure Storage account. And SAS expiration policy recommend upper expiration limit when a user creates a SAS token. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should have the specified minimum TLS version | Configure a minimum TLS version for secure communication between the client application and the storage account. To minimize security risk, the recommended minimum TLS version is the latest released version, which is currently TLS 1.2. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should prevent cross tenant object replication | Audit restriction of object replication for your storage account. By default, users can configure object replication with a source storage account in one Azure AD tenant and a destination account in a different tenant. It is a security concern because customer's data can be replicated to a storage account that is owned by the customer. By setting allowCrossTenantReplication to false, objects replication can be configured only if both source and destination accounts are in the same Azure AD tenant. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should prevent shared key access | Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over Shared Key, and is recommended by Microsoft. | Audit, Deny, Disabled | 2.0.0 |
| Storage accounts should restrict network access | Network access to storage accounts should be restricted. Configure network rules so only applications from allowed networks can access the storage account. To allow connections from specific internet or on-premises clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges | Audit, Deny, Disabled | 1.1.1 |
| Storage Accounts should restrict network access through network ACL bypass configuration only. | To improve the security of Storage Accounts, enable access only through network ACL bypass. This policy should be used in combination with a private endpoint for storage account access. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should restrict network access using virtual network rules | Protect your storage accounts from potential threats using virtual network rules as a preferred method instead of IP-based filtering. Disabling IP-based filtering prevents public IPs from accessing your storage accounts. | Audit, Deny, Disabled | 1.0.1 |
| Storage Accounts should use a virtual network service endpoint | This policy audits any Storage Account not configured to use a virtual network service endpoint. | Audit, Disabled | 1.0.0 |
| Storage accounts should use customer-managed key for encryption | Secure your blob and file storage account with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. | Audit, Disabled | 1.0.3 |
| Storage accounts should use private link | Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your storage account, data leakage risks are reduced. Learn more about private links at - https://aka.ms/azureprivatelinkoverview | AuditIfNotExists, Disabled | 2.0.0 |
| Table Storage should use customer-managed key for encryption | Secure your table storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. | Audit, Deny, Disabled | 1.0.0 |
Microsoft.StorageCache
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| HPC Cache accounts should use customer-managed key for encryption | Manage encryption at rest of Azure HPC Cache with customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. | Audit, Disabled, Deny | 2.0.0 |
Microsoft.StorageSync
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Azure File Sync should use private link | Creating a private endpoint for the indicated Storage Sync Service resource allows you to address your Storage Sync Service resource from within the private IP address space of your organization's network, rather than through the internet-accessible public endpoint. Creating a private endpoint by itself does not disable the public endpoint. | AuditIfNotExists, Disabled | 1.0.0 |
| Configure Azure File Sync with private endpoints | A private endpoint is deployed for the indicated Storage Sync Service resource. This enables you to address your Storage Sync Service resource from within the private IP address space of your organization's network, rather than through the internet-accessible public endpoint. The existence of one or more private endpoints by themselves does not disable the public endpoint. | DeployIfNotExists, Disabled | 1.0.0 |
| Modify - Configure Azure File Sync to disable public network access | The Azure File Sync's internet-accessible public endpoint are disabled by your organizational policy. You may still access the Storage Sync Service via its private endpoint(s). | Modify, Disabled | 1.0.0 |
| Public network access should be disabled for Azure File Sync | Disabling the public endpoint allows you to restrict access to your Storage Sync Service resource to requests destined to approved private endpoints on your organization's network. There is nothing inherently insecure about allowing requests to the public endpoint, however, you may wish to disable it to meet regulatory, legal, or organizational policy requirements. You can disable the public endpoint for a Storage Sync Service by setting the incomingTrafficPolicy of the resource to AllowVirtualNetworksOnly. | Audit, Deny, Disabled | 1.0.0 |
Microsoft.ClassicStorage
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Storage accounts should be migrated to new Azure Resource Manager resources | Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management | Audit, Deny, Disabled | 1.0.0 |
Next steps
- See the built-ins on the Azure Policy GitHub repo.
- Review the Azure Policy definition structure.
- Review Understanding policy effects.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for