Azure Storage Security

In today’s cloud-native landscape, securing your data is more important than ever. Microsoft Azure offers powerful storage solutions—but with great power comes great responsibility. For any cloud administrator, understanding how to secure Azure Storage is essential. This article breaks down the tools, features, and best practices you need to confidently manage and protect data stored in Azure.

Core Security Features in Azure

• Encryption at rest and in transit

  Azure Storage automatically encrypts all data at rest using Storage Service Encryption (SSE) with a 256-bit AES cipher, one of the strongest block ciphers available. This process is transparent, incurs no additional cost, and doesn’t degrade performance. It cannot be disabled, ensuring that all data written to storage is always protected. In transit, data is protected using transport-level security (TLS). Azure recommends and enforces the use of HTTPS to secure communication between the client and the storage account. You can enforce HTTPS by enabling "secure transfer required" at the storage account level, which also ensures SMB 3.0 is used for Azure File shares.

• Authentication and Authorization using Entra ID and RBAC

  Azure Storage supports Microsoft Entra ID (formerly Azure AD) and role-based access control (RBAC) to manage access at a fine-grained level. This applies to both resource management operations (like key management) and data operations (like uploading or reading blobs).

  • Assign RBAC roles scoped to the storage account (e.g., Storage Blob Data Contributor) to users, groups, or applications.

  • Entra ID integration is supported for Blob and Queue Storage operations, providing identity-based access rather than relying on storage account keys.

  • This approach enhances security by allowing centralized and auditable access control.

• Shared Access Signatures

  Shared Access Signatures (SAS) allow you to grant limited, time-bound access to storage resources without exposing your storage account keys. They are ideal for scenarios where you need to provide delegated access to clients, partners, or applications.

  Always limit permissions and set short expiration times when using SAS to minimize risk.

• Disk Encryption

  For Virtual Machines using Azure-managed disks, Azure supports full disk encryption through Azure Disk Encryption:

  • Windows VMs use BitLocker.

  • Linux VMs use dm-crypt.

Keys and secrets are managed using Azure Key Vault, ensuring secure handling of encryption keys. This protects the underlying virtual hard disks (VHDs)—even if someone downloads a disk image, the contents remain encrypted and inaccessible without the proper keys.

Understanding Shared Access Signature

A Shared Access Signature (SAS) is a URI that grants limited access to Azure Storage resources without exposing your storage account keys. It's similar to how Google Docs lets you create a link that allows others to view or edit a document, depending on the permissions you set.

With Azure, SAS tokens are created using the access keys from your storage account. We then add these tokens to the storage service endpoints, defining the actions (such as reading, writing, or deleting) and their duration. This gives you a secure way to share specific resources without giving full control over your storage account.

Types of SAS

Today, Azure supports three different types of SAS:

• Account SAS
  Account SAS allows access to resources across multiple storage services—Blob, File, Queue, and Table. You can also use it for service-level operations like getting service properties or statistics. It provides the most control and is ideal when you need to manage access across services.

• Service SAS
  This is more focused and is used for a single storage service—Blob, Queue, Table, or File. You can use it to give someone permission to upload a blob, read from a queue, or access a specific file share. It is suitable for limited and task-specific access.

  💡

  Note: You can think of Account SAS and Service SAS as being different in terms of scope. Account SAS applies to multiple storage services (Blob, Files, Queues, and Tables), while Service SAS is restricted to just one service at a time.

• User Delegation SAS
  This is available only for Blob Storage and uses Microsoft Entra credentials instead of account keys. It provides a higher level of security because it ties access to an identity in Azure Active Directory. This approach is ideal for enterprise scenarios where fine-grained, identity-based access is preferred.

When creating a SAS token, you’ll notice several short parameters like sv, sr, se, ss, and more included in the query string. These parameters define the permissions, validity period, and scope of access to the storage resource.

For example, a SAS URL might look like this:
https://myaccount.blob.core.windows.net/sascontainer/blob1.txt?sp=rw&st=2023-05-24T01:13:55Z&se=2023-05-24T09:13:55Z&sip=198.51.100.10-198.51.100.20&spr=https&sv=2022-11-02&sr=b&sig=...

To help you understand what each of these abbreviations means, refer to the table below:

Encryption and Key Management in Azure Storage

Azure ensures your data is protected through different encryption mechanisms, both at rest and in transit. This encryption is applied automatically, with various options depending on how much control you want over the encryption keys.

1. Infrastructure Encryption

For added security, infrastructure encryption can be enabled on a storage account or at the encryption scope level. When turned on, your data is encrypted twice—once at the service level and again at the infrastructure level—using two separate encryption keys and algorithms. This provides an additional layer of defense for sensitive workloads.

2. Platform-Managed Keys (PMKs) or Microsoft Managed Keys (MMKs)

By default, Azure handles encryption using platform-managed keys. These keys are created, maintained, and rotated automatically by Azure. Users don’t need to manage or interact with them directly. For most scenarios, PMKs offer sufficient protection with minimal overhead.

3. Customer-Managed Keys (CMKs)

If your organization needs more control or has compliance requirements, you can use customer-managed keys. These keys are stored in your own Azure Key Vault or hardware security module (HSM). With CMKs, you are responsible for key rotation (the practice of regularly changing your encryption or access keys to reduce the risk of unauthorized access if a key gets exposed or compromised), access policies, and lifecycle management.

A common CMK use case is Bring Your Own Key (BYOK)—where you import encryption keys generated outside Azure into Key Vault, giving you full ownership and control.

Conclusion

Securing Azure Storage goes beyond just setting up access; it involves making intentional choices about how that access is granted and managed. While Shared Access Signatures (SAS) offer flexible, time-bound permissions, it’s generally safer to avoid using account keys or passwords directly. Instead, leveraging Microsoft Entra ID with role-based access control (RBAC) provides a more secure and manageable approach, especially in cases where keys might be compromised. Combining strong access controls with encryption strategies—whether platform-managed or customer-managed—ensures that your data remains protected at all times. By adopting these best practices, you not only enhance security but also align with modern cloud governance standards.