Why Security in Storage Matters

Data security is a non-negotiable requirement for enterprises. Whether it’s financial data, healthcare records, or customer files, Azure Storage must be designed to meet compliance, confidentiality, and access control needs.

As a Solution Architect, you must know how to design storage access, encryption, and key management to balance usability with security.

Key Security Mechanisms in Azure Storage

1. Shared Access Signatures (SAS)

• A time-bound, permission-limited token that grants access to storage resources.

• Example: Allow a vendor to upload files for 2 hours without exposing the account key.

• Types:

  • User Delegation SAS (preferred, tied to Azure AD identity).

  • Service SAS (applies to specific resource type like blob, queue).

  • Account SAS (applies at account level, broader).

Best Practice: Always use User Delegation SAS instead of Account SAS for least privilege.

2. Role-Based Access Control (RBAC)

• Control storage access using Azure AD authentication.

• Built-in roles include:

  • Storage Blob Data Owner

  • Storage Blob Data Contributor

  • Storage Blob Data Reader

• Provides fine-grained access to resources.

When to Use: For internal users, apps, and managed identities where central identity governance is needed.

3. Customer-Managed Keys (CMK)

• By default, Azure Storage uses Microsoft-managed keys for encryption.

• With CMK, you control encryption keys via Azure Key Vault.

• Required for compliance-heavy workloads (finance, healthcare, government).

When to Use: When regulatory standards require ownership and rotation of keys.

4. Encryption-at-Rest & In-Transit

• All Azure Storage data is automatically encrypted at rest using AES-256.

• In-transit encryption uses TLS for secure access.

• You can enable double encryption for extra protection.

Example Enterprise Scenario

A financial services firm wants to:

• Allow partners to securely upload documents for 24 hours only.

• Ensure encryption keys are under the firm’s control.

• Prevent accidental public access to storage accounts.

Correct design:

• Use User Delegation SAS with 24-hour validity for file upload.

• Enable CMK via Key Vault for encryption.

• Restrict access to storage accounts with RBAC and private endpoints.

Confusion Buster

• SAS vs RBAC:

  • SAS = temporary access via token.

  • RBAC = identity-based permanent/flexible access.

• Microsoft-Managed Keys vs Customer-Managed Keys:

  • Microsoft = default, hands-off.

  • Customer = regulatory control, managed in Key Vault.

• Encryption-at-Rest vs In-Transit:

  • At-rest = stored data.

  • In-transit = data moving over the network.

Exam Tips

• “Which mechanism provides time-limited access without sharing keys?” → SAS.

• “Which roles control storage access in Azure AD?” → RBAC Storage roles.

• “Which option gives compliance control over encryption keys?” → Customer-Managed Keys (CMK).

• “Is encryption-at-rest automatic in Azure Storage?” → Yes (AES-256).

What to Expect in the Exam

• Direct Q: “Which service integrates with Azure Storage for customer-managed keys?” → Key Vault.

• Scenario Q: “Company must give vendor upload access for 2 hours.” → SAS.

• Scenario Q: “Regulated bank must manage its own encryption keys.” → CMK.

• Trick Q: “Azure Storage data is not encrypted at rest by default.” → False.