{
	"id": "26b71469-9af9-4b07-9983-4ebb5fd7eca8",
	"created_at": "2026-04-06T00:19:09.085279Z",
	"updated_at": "2026-04-10T03:21:29.82818Z",
	"deleted_at": null,
	"sha1_hash": "b41ab366ce8e30f01f2084b0c3ac8c12e085809a",
	"title": "Security recommendations for Blob storage - Azure Storage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 65124,
	"plain_text": "Security recommendations for Blob storage - Azure Storage\r\nBy normesta\r\nArchived: 2026-04-05 21:55:05 UTC\r\nThis article contains security recommendations for Blob storage. Implementing these recommendations will help\r\nyou fulfill your security obligations as described in our shared responsibility model. For more information on how\r\nMicrosoft fulfills service provider responsibilities, see Shared responsibility in the cloud.\r\nSome of the recommendations included in this article can be automatically monitored by Microsoft Defender for\r\nCloud, which is the first line of defense in protecting your resources in Azure. For information on Microsoft\r\nDefender for Cloud, see What is Microsoft Defender for Cloud?\r\nMicrosoft Defender for Cloud periodically analyzes the security state of your Azure resources to identify potential\r\nsecurity vulnerabilities. It then provides you with recommendations on how to address them. For more\r\ninformation on Microsoft Defender for Cloud recommendations, see Review your security recommendations.\r\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nUse the Azure Resource\r\nManager deployment\r\nmodel\r\nCreate new storage accounts using the Azure Resource Manager\r\ndeployment model for important security enhancements, including\r\nsuperior Azure role-based access control (Azure RBAC) and\r\nauditing, Resource Manager-based deployment and governance,\r\naccess to managed identities, access to Azure Key Vault for secrets,\r\nand Microsoft Entra authentication and authorization for access to\r\nAzure Storage data and resources. Migrate all existing storage\r\naccounts that use the classic deployment model to use Azure\r\nResource Manager. For more information about Azure Resource\r\nManager, see Azure Resource Manager overview.\r\n-\r\nEnable Microsoft\r\nDefender for all of your\r\nstorage accounts\r\nMicrosoft Defender for Storage provides an additional layer of\r\nsecurity intelligence that detects unusual and potentially harmful\r\nattempts to access or exploit storage accounts. Security alerts are\r\ntriggered in Microsoft Defender for Cloud when anomalies in\r\nactivity occur and are also sent via email to subscription\r\nadministrators, with details of suspicious activity and\r\nrecommendations on how to investigate and remediate threats. For\r\nmore information, see Configure Microsoft Defender for Storage.\r\nYes\r\nTurn on soft delete for\r\nblobs\r\nSoft delete for blobs enables you to recover blob data after it has\r\nbeen deleted. For more information on soft delete for blobs, see\r\n-\r\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nPage 1 of 6\n\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nSoft delete for Azure Storage blobs.\r\nTurn on soft delete for\r\ncontainers\r\nSoft delete for containers enables you to recover a container after it\r\nhas been deleted. For more information on soft delete for\r\ncontainers, see Soft delete for containers.\r\n-\r\nLock storage account to\r\nprevent accidental or\r\nmalicious deletion or\r\nconfiguration changes\r\nApply an Azure Resource Manager lock to your storage account to\r\nprotect the account from accidental or malicious deletion or\r\nconfiguration change. Locking a storage account does not prevent\r\ndata within that account from being deleted. It only prevents the\r\naccount itself from being deleted. For more information, see Apply\r\nan Azure Resource Manager lock to a storage account.\r\nStore business-critical\r\ndata in immutable blobs\r\nConfigure legal holds and time-based retention policies to store\r\nblob data in a WORM (Write Once, Read Many) state. Blobs stored\r\nimmutably can be read, but cannot be modified or deleted for the\r\nduration of the retention interval. For more information, see Store\r\nbusiness-critical blob data with immutable storage.\r\n-\r\nUse Encryption to\r\nProtect Data\r\nAzure Storage encrypts all data at rest by default using Microsoft-managed keys. For enhanced control, configure customer-managed\r\nkeys with Azure Key Vault to manage encryption keys directly. To\r\nfurther strengthen security, implement client-side encryption before\r\nuploading data.\r\n-\r\nRequire secure transfer\r\n(HTTPS) to the storage\r\naccount\r\nWhen you require secure transfer for a storage account, all requests\r\nto the storage account must be made over HTTPS. Any requests\r\nmade over HTTP are rejected. Microsoft recommends that you\r\nalways require secure transfer for all of your storage accounts. For\r\nmore information, see Require secure transfer to ensure secure\r\nconnections.\r\n-\r\nLimit shared access\r\nsignature (SAS) tokens\r\nto HTTPS connections\r\nonly\r\nRequiring HTTPS when a client uses a SAS token to access blob\r\ndata helps to minimize the risk of eavesdropping. For more\r\ninformation, see Grant limited access to Azure Storage resources\r\nusing shared access signatures (SAS).\r\n-\r\nDisallow cross-tenant\r\nobject replication\r\nBy default, an authorized user is permitted to configure an object\r\nreplication policy where the source account is in one Microsoft\r\nEntra tenant and the destination account is in a different tenant.\r\nDisallow cross-tenant object replication to require that the source\r\nand destination accounts participating in an object replication\r\n-\r\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nPage 2 of 6\n\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\npolicy are in the same tenant. For more information, see Prevent\r\nobject replication across Microsoft Entra tenants.\r\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nUse Microsoft Entra ID to\r\nauthorize access to blob data\r\nMicrosoft Entra ID provides superior security and ease of use\r\nover Shared Key for authorizing requests to Blob storage. For\r\nmore information, see Authorize access to data in Azure\r\nStorage.\r\n-\r\nKeep in mind the principle of\r\nleast privilege when\r\nassigning permissions to a\r\nMicrosoft Entra security\r\nprincipal via Azure RBAC\r\nWhen assigning a role to a user, group, or application, grant\r\nthat security principal only those permissions that are\r\nnecessary for them to perform their tasks. Limiting access to\r\nresources helps prevent both unintentional and malicious\r\nmisuse of your data.\r\n-\r\nUse a user delegation SAS to\r\ngrant limited access to blob\r\ndata to clients\r\nA user delegation SAS is secured with Microsoft Entra\r\ncredentials and also by the permissions specified for the SAS.\r\nA user delegation SAS is analogous to a service SAS in terms\r\nof its scope and function, but offers security benefits over the\r\nservice SAS. For more information, see Grant limited access\r\nto Azure Storage resources using shared access signatures\r\n(SAS).\r\n-\r\nSecure your account access\r\nkeys with Azure Key Vault\r\nMicrosoft recommends using Microsoft Entra ID to authorize\r\nrequests to Azure Storage. However, if you must use Shared\r\nKey authorization, then secure your account keys with Azure\r\nKey Vault. You can retrieve the keys from the key vault at\r\nruntime, instead of saving them with your application. For\r\nmore information about Azure Key Vault, see Azure Key Vault\r\noverview.\r\n-\r\nRegenerate your account\r\nkeys periodically\r\nRotating the account keys periodically reduces the risk of\r\nexposing your data to malicious actors.\r\n-\r\nDisallow Shared Key\r\nauthorization\r\nWhen you disallow Shared Key authorization for a storage\r\naccount, Azure Storage rejects all subsequent requests to that\r\naccount that are authorized with the account access keys. Only\r\nsecured requests that are authorized with Microsoft Entra ID\r\nwill succeed. For more information, see Prevent Shared Key\r\nauthorization for an Azure Storage account.\r\n-\r\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nPage 3 of 6\n\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nKeep in mind the principle of\r\nleast privilege when\r\nassigning permissions to a\r\nSAS\r\nWhen creating a SAS, specify only those permissions that are\r\nrequired by the client to perform its function. Limiting access\r\nto resources helps prevent both unintentional and malicious\r\nmisuse of your data.\r\n-\r\nHave a revocation plan in\r\nplace for any SAS that you\r\nissue to clients\r\nIf a SAS is compromised, you will want to revoke that SAS as\r\nsoon as possible. To revoke a user delegation SAS, revoke the\r\nuser delegation key to quickly invalidate all signatures\r\nassociated with that key. To revoke a service SAS that is\r\nassociated with a stored access policy, you can delete the\r\nstored access policy, rename the policy, or change its expiry\r\ntime to a time that is in the past. For more information, see\r\nGrant limited access to Azure Storage resources using shared\r\naccess signatures (SAS).\r\n-\r\nIf a service SAS is not\r\nassociated with a stored\r\naccess policy, then set the\r\nexpiry time to one hour or\r\nless\r\nA service SAS that is not associated with a stored access\r\npolicy cannot be revoked. For this reason, limiting the expiry\r\ntime so that the SAS is valid for one hour or less is\r\nrecommended.\r\n-\r\nDisable anonymous read\r\naccess to containers and\r\nblobs\r\nanonymous read access to a container and its blobs grants\r\nread-only access to those resources to any client. Avoid\r\nenabling anonymous read access unless your scenario requires\r\nit. To learn how to disable anonymous access for a storage\r\naccount, see Overview: Remediating anonymous read access\r\nfor blob data.\r\n-\r\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nConfigure the minimum\r\nrequired version of\r\nTransport Layer Security\r\n(TLS) for a storage\r\naccount.\r\nRequire that clients use a more secure version of TLS to make\r\nrequests against an Azure Storage account by configuring the\r\nminimum version of TLS for that account. For more information,\r\nsee Configure minimum required version of Transport Layer\r\nSecurity (TLS) for a storage account\r\n-\r\nEnable the Secure\r\ntransfer required option\r\non all of your storage\r\naccounts\r\nWhen you enable the Secure transfer required option, all\r\nrequests made against the storage account must take place over\r\nsecure connections. Any requests made over HTTP will fail. For\r\nmore information, see Require secure transfer in Azure Storage.\r\nYes\r\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nPage 4 of 6\n\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nEnable firewall rules\r\nConfigure firewall rules to limit access to your storage account to\r\nrequests that originate from specified IP addresses or ranges, or\r\nfrom a list of subnets in an Azure Virtual Network (VNet). For\r\nmore information about configuring firewall rules, see Configure\r\nAzure Storage firewalls and virtual networks.\r\n-\r\nAllow trusted Microsoft\r\nservices to access the\r\nstorage account\r\nTurning on firewall rules for your storage account blocks\r\nincoming requests for data by default, unless the requests originate\r\nfrom a service operating within an Azure Virtual Network (VNet)\r\nor from allowed public IP addresses. Requests that are blocked\r\ninclude those from other Azure services, from the Azure portal,\r\nfrom logging and metrics services, and so on. You can permit\r\nrequests from other Azure services by adding an exception to\r\nallow trusted Microsoft services to access the storage account. For\r\nmore information about adding an exception for trusted Microsoft\r\nservices, see Configure Azure Storage firewalls and virtual\r\nnetworks.\r\n-\r\nUse private endpoints\r\nA private endpoint assigns a private IP address from your Azure\r\nVirtual Network (VNet) to the storage account. It secures all traffic\r\nbetween your VNet and the storage account over a private link.\r\nFor more information about private endpoints, see Connect\r\nprivately to a storage account using Azure Private Endpoint.\r\n-\r\nUse VNet service tags\r\nA service tag represents a group of IP address prefixes from a\r\ngiven Azure service. Microsoft manages the address prefixes\r\nencompassed by the service tag and automatically updates the\r\nservice tag as addresses change. For more information about\r\nservice tags supported by Azure Storage, see Azure service tags\r\noverview. For a tutorial that shows how to use service tags to\r\ncreate outbound network rules, see Restrict access to PaaS\r\nresources.\r\n-\r\nLimit network access to\r\nspecific networks\r\nLimiting network access to networks hosting clients requiring\r\naccess reduces the exposure of your resources to network attacks.\r\nYes\r\nConfigure network\r\nrouting preference\r\nYou can configure network routing preference for your Azure\r\nstorage account to specify how network traffic is routed to your\r\naccount from clients over the Internet using the Microsoft global\r\nnetwork or Internet routing. For more information, see Configure\r\nnetwork routing preference for Azure Storage.\r\n-\r\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nPage 5 of 6\n\nRecommendation Comments\r\nDefender\r\nfor Cloud\r\nTrack how requests\r\nare authorized\r\nEnable logging for Azure Storage to track how requests to the service\r\nare authorized. The logs indicate whether a request was made\r\nanonymously, by using an OAuth 2.0 token, by using Shared Key, or\r\nby using a shared access signature (SAS). For more information, see\r\nMonitoring Azure Blob Storage with Azure Monitor or Azure Storage\r\nanalytics logging with Classic Monitoring.\r\n-\r\nSet up alerts in\r\nAzure Monitor\r\nConfigure log alerts to evaluate resources logs at a set frequency and\r\nfire an alert based on the results. For more information, see Log alerts\r\nin Azure Monitor.\r\n-\r\nAzure security documentation\r\nSecure development documentation.\r\nSource: https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nhttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide"
	],
	"report_names": [
		"storage-security-guide"
	],
	"threat_actors": [],
	"ts_created_at": 1775434749,
	"ts_updated_at": 1775791289,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b41ab366ce8e30f01f2084b0c3ac8c12e085809a.pdf",
		"text": "https://archive.orkl.eu/b41ab366ce8e30f01f2084b0c3ac8c12e085809a.txt",
		"img": "https://archive.orkl.eu/b41ab366ce8e30f01f2084b0c3ac8c12e085809a.jpg"
	}
}