AZ-500 Objective 3.2: Plan and Implement Security for Storage

Understanding Azure Storage Security

Azure Storage accounts host Blob Storage, Azure Files, Queue Storage, and Table Storage requiring comprehensive security protecting data access, encryption, and resilience. Storage security challenges include unauthorized data access through compromised credentials or misconfigurations exposing sensitive data, insider threats from users with excessive permissions accessing data inappropriately, data exfiltration where attackers extract large amounts of data undetected, ransomware attacks encrypting or deleting data demanding ransom for recovery, accidental deletion or modification by administrators or users destroying important data, compliance violations failing to meet regulatory requirements for data protection and retention, and key management complexity in maintaining encryption keys securely. Traditional approaches often rely heavily on storage account keys providing overly broad access, lack granular permissions leading to privilege escalation risks, have no audit trail tracking who accessed what data, and use single encryption layer providing limited protection against cryptographic attacks.

Azure Storage security features address these challenges through multiple layers: Identity and access management using Azure AD authentication with RBAC providing granular, auditable access control, managed identities eliminating credential management for Azure services, and SAS tokens offering time-limited delegated access without sharing account keys. Network security through Private Endpoints providing private IP connectivity eliminating public exposure, service endpoints optimizing routing over Azure backbone, and firewall rules restricting access to trusted networks and IP ranges. Encryption protecting data at rest with automatic encryption using platform-managed or customer-managed keys, encryption in transit requiring HTTPS, and optional infrastructure-level double encryption for maximum protection. Data protection features including soft delete recovering accidentally deleted items, versioning maintaining complete change history, immutable storage preventing modification or deletion for compliance, and Azure Backup providing operational backup and recovery. This objective explores comprehensive storage security enabling protection of data through identity-based access, granular permissions, network isolation, encryption controls, and resilient data protection defending against accidental and malicious data loss while meeting compliance requirements for regulated industries.

Storage Account Access Control

Azure RBAC for Storage Accounts

Storage account access control operates at two planes: Control plane (Azure Resource Manager) manages storage account itself—creating, configuring, deleting storage account, modifying network rules, configuring encryption. Data plane accesses data within storage—reading/writing blobs, uploading files, sending queue messages, querying tables. Each plane uses different RBAC roles. Control plane roles: Owner provides full management access including role assignments, suitable for storage administrators, includes ability to assign roles to others. Contributor provides full management but can't assign roles, suitable for storage operators, can't grant access to others. Reader provides read-only view of storage account configuration, can't access data or modify settings, suitable for auditors. Storage Account Contributor provides full management of storage accounts specifically, can create, modify, delete storage accounts, doesn't provide data access. User Access Administrator manages user access to resources, can assign roles but not manage resources directly, suitable for access management teams. Assign control plane roles: Portal → Storage account → Access Control (IAM) → Add role assignment → Select role (Owner, Contributor, Reader) → Select Azure AD identity (user, group, service principal, managed identity) → Assign.

Data plane access controls who reads/writes data in storage using Azure AD with RBAC (recommended method): Storage Blob Data Owner grants full access including setting ownership and ACLs, highest privilege blob role, equivalent to file system owner permissions. Storage Blob Data Contributor grants read, write, and delete access to blobs and containers, most common role for application access, suitable for services that manage blob data. Storage Blob Data Reader grants read-only access to blobs and metadata, suitable for reporting services, analytics applications. Storage Blob Delegator allows generating user delegation SAS tokens, requires Azure AD authentication, users can create SAS tokens without storage account keys. Storage File Data SMB Share Contributor grants read, write, delete access to Azure Files over SMB, modify NTFS permissions, suitable for users needing full file management. Storage File Data SMB Share Reader grants read-only access to Azure Files, view files but can't modify. Storage File Data SMB Share Elevated Contributor grants full access including ownership changes, highest privilege file role. Storage Queue Data Contributor grants read, write, delete queue messages. Storage Queue Data Reader grants read-only queue access. Storage Table Data Contributor grants read, write, delete table entities. Storage Table Data Reader grants read-only table access.

Scope of role assignments: Subscription level—role applies to all storage accounts in subscription, useful for organizational policies. Resource group level—applies to all storage accounts in resource group, common for project-based access. Storage account level—applies to all services in storage account (Blob, Files, Queue, Table), most common assignment level. Container or share level—granular access to specific container or file share, enables multi-tenant scenarios with isolated access. Best practices for RBAC: Use Azure AD groups instead of individual users simplifying management when users join or leave organization, implement least privilege assigning minimum permissions required for task (prefer Reader over Contributor when write access not needed), separate duties between control plane and data plane (storage administrators vs data users), use managed identities for Azure services eliminating credentials in code, implement time-bound access using Privileged Identity Management for temporary elevated access, regularly audit role assignments removing unnecessary access, document access requirements and role mappings for compliance, use custom roles when built-in roles too broad, test permissions ensuring users have required access, monitor role assignments tracking who has access to what data.

Network Security and Private Endpoints

Storage account network security controls network-level access to storage. Firewall and virtual networks: Default—allow access from all networks, storage publicly accessible from internet. Selected networks—restrict access to specific VNets and IP ranges, default deny all, explicitly allow trusted sources. Disabled public network access—no internet access, only Private Endpoints. Configure: Storage account → Networking → Firewalls and virtual networks → Selected networks → Add VNet (service endpoint required on subnet), Add IP range (public IPs for access), Enable trusted Azure services (allows Azure services like Azure Backup). Exceptions: Trusted Microsoft services—allows Azure services (Backup, Site Recovery, Azure Monitor, Azure Defender) to access storage even when public access restricted, enable for operational services while maintaining security. Logging and metrics—allows diagnostic logs and metrics collection, enable for monitoring without opening firewall. Resource instances—grant access to specific Azure resource instances (App Service, Azure Functions), enables granular service-based access.

Private Endpoints: Dedicated private IP from VNet for storage account, eliminates public endpoint completely, traffic between VNet and storage over Microsoft backbone, requires Private DNS zone for name resolution (privatelink.blob.core.windows.net, privatelink.file.core.windows.net). Deploy: Create Private Endpoint → Select storage account as resource → Choose sub-resource (blob, file, queue, table, dfs, web) → Select VNet and subnet → Configure DNS (automatic Private DNS zone or manual). Benefits: Storage accessible only from VNet and connected networks (via VPN or ExpressRoute), no public internet exposure, reduced attack surface, compliance for data that can't traverse internet. Multiple private endpoints: Create separate private endpoints for different sub-resources (one for Blob, one for Files), connect from multiple VNets for hub-spoke architecture, isolate access patterns (different endpoint for production vs development VNet). Service Endpoints: Alternative to Private Endpoints optimizing routing but not providing private IPs, traffic routes over Azure backbone not internet, enables firewall rules based on VNet, lower cost than Private Endpoints but less isolation. Enable: VNet → Subnets → Enable Microsoft.Storage service endpoint → Add VNet to storage firewall.

Secure transfer required: Forces HTTPS for all data transfer encrypting data in transit, HTTP requests rejected, critical security configuration, enabled by default on new storage accounts, verify enabled: Storage account → Configuration → Secure transfer required → Enabled. Minimum TLS version: Configure minimum TLS version (1.0, 1.1, 1.2) preventing legacy protocol vulnerabilities, set to 1.2 minimum for production, TLS 1.0 and 1.1 deprecated and insecure. Best practices network security: Use Private Endpoints for production storage with sensitive data, configure firewall rules restricting to trusted networks, disable public access entirely when all access via Private Endpoints, enable secure transfer requiring HTTPS, set minimum TLS 1.2, enable trusted Microsoft services for operational services, implement NSG rules on storage subnet for additional control, use service endpoints for cost-effective routing improvements, monitor network rule violations in diagnostic logs, regularly audit network configurations, test connectivity from all required sources before production, document network architecture including Private Endpoints and firewall rules for compliance.

Storage Account Access Key Management

Access Key Rotation and Protection

Storage account access keys (shared keys) provide root-level access to entire storage account including all Blobs, Files, Queues, and Tables making them high-privilege credentials requiring careful management. Two keys per account: Key1 and key2 enable key rotation without downtime, applications use one key while other regenerated, keys 512 bits providing strong cryptographic protection, keys grant full access bypassing RBAC. Regenerate keys periodically reducing window of compromise if key leaked, recommended every 90 days meeting compliance standards, more frequent for highly sensitive data (30-60 days). Key rotation process: Identify applications currently using key1, regenerate key2 creating new value (portal, CLI, PowerShell), update applications to use new key2 value (configuration files, Key Vault secrets, environment variables), verify all applications functioning correctly with key2, wait appropriate period ensuring no applications still using key1 (monitor logs), regenerate key1 creating new value, document rotation date and next rotation deadline. Automated rotation reduces manual errors, ensures consistency, provides audit trail.

Key Vault integration: Store storage account keys in Azure Key Vault as secrets instead of application configuration or code, applications retrieve keys from Key Vault using managed identity or service principal authentication, Key Vault provides centralized key management, access control through RBAC, comprehensive audit logging, automatic rotation support, secret versioning for rollback, high availability and disaster recovery. Configure Key Vault to manage storage keys: Grant Key Vault permissions to storage account (Storage Account Key Operator Service Role), configure Key Vault storage account management, Key Vault automatically regenerates keys on schedule (30, 60, 90 days), applications retrieve current valid key from Key Vault. Benefits: No keys in application configuration or code, automatic rotation without application changes, audit trail of key retrievals in Key Vault logs, immediate key revocation by rotating keys in vault, separation of duties (security team manages vault, developers access without seeing keys). Monitoring: Enable diagnostic settings on storage account capturing authentication events, track storage account key usage (authorization method in logs shows shared key vs Azure AD), alert on key regeneration events, monitor failed authentication attempts potentially indicating compromised keys, integrate with Azure Sentinel for correlation with other security events.

Disabling shared key authorization: Preview feature preventing storage account key and SAS token authentication, forces Azure AD authentication only, configure: Storage account → Configuration → Allow shared key access → Disabled. Before disabling: Identify all applications using shared keys or SAS tokens, migrate to Azure AD authentication with managed identities or service principals, verify no legacy applications requiring shared key, document exceptions (some Azure services require shared key), test thoroughly in non-production. Benefits: Eliminates highest privilege credential, enforces identity-based access with RBAC, provides better audit trail (Azure AD user identity vs anonymous key), meets compliance requirements prohibiting shared secrets. Access key alternatives: Azure AD authentication with managed identities (preferred for Azure services), service principals with certificate authentication (for external applications), user delegation SAS tokens (secured with Azure AD credentials not storage keys), Azure Active Directory Domain Services for Azure Files (identity-based file access). Best practices: Rotate keys every 90 days minimum or per compliance requirements, store keys in Key Vault never in code or configuration, use automated rotation reducing manual process, disable shared key authorization when all applications support Azure AD, implement key compromise response procedures, restrict key access through RBAC, monitor key usage with alerts on anomalies, prefer Azure AD authentication over shared keys, document key management procedures, regular audit of key access and rotation status, test key rotation procedures periodically, maintain inventory of applications using keys for impact analysis.

Azure Files Access Methods

Identity-Based Authentication for Azure Files

Azure Files supports SMB and NFS protocols with different authentication mechanisms. SMB Azure Files authentication: Storage account key (default but not recommended)—full access to all file shares using storage account key, no per-user access control, all users share same credentials, suitable only for testing or scenarios where identity-based access not possible, security risk in production. Azure AD Domain Services (Azure AD DS)—cloud-based domain services integrated with Azure AD, provides Kerberos authentication for Azure AD users, supports Windows ACLs for file/directory permissions, recommended for cloud-native scenarios without on-premises Active Directory, requires Azure AD DS deployment in Azure. On-premises Active Directory Domain Services (AD DS)—hybrid identity solution integrating Azure Files with on-premises Active Directory, users authenticate with existing domain credentials, leverages Kerberos authentication, supports NTFS permissions, recommended for hybrid environments with existing AD infrastructure, requires Azure AD Connect syncing identities.

Azure AD DS configuration: Enable Azure AD DS in Azure AD tenant (separate service with deployment time), domain-join storage account to Azure AD DS managed domain using PowerShell or portal, configure storage account identity: Storage account → Configuration → Azure Active Directory Domain Services (Azure AD DS) → Enable, assign share-level permissions using Azure RBAC (Storage File Data SMB Share Contributor, Reader, or Elevated Contributor) at storage account, file share, or directory scope, mount file share on domain-joined or Azure AD-joined Windows client, configure directory and file level permissions using Windows File Explorer setting NTFS ACLs on folders and files. Benefits: Cloud-native identity management without on-premises infrastructure, integration with Azure AD providing SSO and MFA, simplified deployment compared to on-premises AD, automatic synchronization with Azure AD (users, groups, passwords), suitable for organizations moving entirely to cloud. On-premises AD DS configuration: Ensure Azure AD Connect syncing on-premises AD to Azure AD, install AzFilesHybrid PowerShell module, run Join-AzStorageAccountForAuth connecting storage account to AD domain (domain joins storage account creating computer account in AD), configure Kerberos encryption types and service principal name, assign share-level permissions via Azure RBAC in portal, mount share from domain-joined machine, configure NTFS permissions on directories and files using icacls or File Explorer. Benefits: Leverages existing AD infrastructure and investments, users authenticate with corporate credentials, existing group policies and security configurations apply, works with on-premises file servers for hybrid scenarios.

Share-level permissions (RBAC roles): Storage File Data SMB Share Contributor—read, write, delete files, modify ACLs on files and directories, most common role for general users. Storage File Data SMB Share Reader—read-only access to files and directories, can't modify or delete, suitable for users needing view-only access. Storage File Data SMB Share Elevated Contributor—full control including taking ownership and changing permissions at root level, similar to Administrator, suitable for storage administrators. Assign at storage account (all shares), specific share, or directory level. Directory/file level permissions: Windows ACLs (NTFS permissions) applied after share-level RBAC access granted, standard Windows permissions (Full Control, Modify, Read & Execute, List Folder Contents, Read, Write), inherited from parent unless explicitly blocked, configure using Windows tools (File Explorer properties, icacls command), compatible with on-premises file server permissions enabling lift-and-shift migrations. Permission evaluation: First Azure RBAC (share-level) evaluated—if denied access stops, if granted proceed to ACL check, then NTFS ACLs (directory/file level) evaluated—most restrictive permission applies. Example: User has Contributor at share level but Read-only ACL on folder—user can only read that folder despite Contributor role.

Azure Files Best Practices

Choosing authentication method: Azure AD DS for cloud-only organizations without on-premises Active Directory, new deployments starting in cloud, simplified management without AD infrastructure. On-premises AD DS for hybrid organizations with existing Active Directory, lift-and-shift file servers to Azure maintaining existing permissions, integration with on-premises security policies and group policies. Storage account key only for testing and development (insecure for production), legacy applications that can't support identity authentication, temporary access during migration. Security configuration: Disable storage account key access after configuring identity authentication, enable secure transfer requiring SMB 3.0+ with encryption, configure Private Endpoints for file share access preventing internet exposure, implement network rules restricting access to corporate VNet, configure minimum TLS version 1.2, enable soft delete for file share protection against accidental deletion (7-365 day retention), implement Azure Backup for file shares with scheduled backups and retention policies. Monitoring: Enable diagnostic logs capturing SMB authentication events, monitor failed authentication attempts, track file access patterns detecting anomalies, alert on unauthorized access attempts, integrate logs with Azure Sentinel for security correlation. Permission management: Use Azure AD groups for share-level RBAC simplifying management, document permission structure (RBAC roles and NTFS permissions), regularly audit permissions removing unnecessary access, implement least privilege (grant minimum permissions required), test permissions thoroughly before production, use separate file shares for different security zones (production, development, test).

Azure Blob Storage Access Methods

Azure AD Authentication for Blob Storage

Azure AD authentication provides most secure and recommended access method for Blob Storage using identities instead of keys. Authentication uses OAuth 2.0 tokens issued by Azure AD, supports Azure AD users, service principals, and managed identities, integrates with Conditional Access enforcing MFA and device compliance, provides audit trail with Azure AD user identity in logs. Built-in RBAC roles: Storage Blob Data Owner—full access to blobs and containers including ownership and setting ACLs, highest privilege role, suitable for storage administrators. Storage Blob Data Contributor—read, write, and delete blobs and containers, most common role for applications managing blob data, can't set ownership or ACLs. Storage Blob Data Reader—read-only access to blobs and metadata, suitable for reporting applications, analytics services, backup systems. Storage Blob Delegator—allows generating user delegation SAS tokens, special role for delegating access without sharing storage keys, requires Azure AD authentication. Assign roles: Portal → Storage account or Container → Access Control (IAM) → Add role assignment → Select role → Select identity (user, group, service principal, managed identity) → Assign. Role assignment scope: Subscription (all storage accounts), resource group (all storage in group), storage account (all containers), container (specific container only). Use narrowest scope meeting requirements (prefer container-level over account-level when possible).

Managed identities: System-assigned or user-assigned identities for Azure services (VMs, App Service, Functions, Logic Apps, AKS, Azure Data Factory), eliminates credential management (no keys or passwords in code), automatic credential rotation by Azure platform, authentication transparent to application code. Configuration: Enable managed identity on Azure service (VM → Identity → System-assigned → On or User-assigned → Add), assign Storage Blob Data Contributor role to managed identity at appropriate scope, application code uses DefaultAzureCredential or ManagedIdentityCredential automatically authenticating. Example: Azure Function with managed identity—enable managed identity, grant Storage Blob Data Contributor on container, function code uses Azure.Identity library connecting without credentials. Service principals: Azure AD application registrations providing identity for external applications or CI/CD pipelines, supports certificate or secret-based authentication (certificates recommended), can have multiple credentials for rotation, suitable for applications outside Azure or cross-tenant scenarios. Configuration: Create App Registration in Azure AD, create certificate or secret for authentication, assign Storage Blob Data Contributor role to service principal, application authenticates using client ID and certificate/secret. Best practices: Use managed identities for Azure services (eliminates credential management), use service principals with certificates for external applications, assign roles at container scope for granular access, use Azure AD groups assigning roles to groups not individual users, implement least privilege (Reader role when write access not needed), regularly audit role assignments removing unnecessary access, enable Conditional Access for user accounts requiring MFA, document identity mappings for compliance.

Shared Access Signatures (SAS)

Shared Access Signature (SAS) provides time-limited delegated access to storage resources without sharing account keys, enables granular permissions control, includes security features (expiration, IP restrictions, protocol constraints). Three SAS types: User delegation SAS (most secure)—secured with Azure AD credentials instead of storage account key, generated by Azure AD authenticated user or service principal with Storage Blob Delegator role, can't be revoked except by revoking user's Azure AD credentials or deleting storage account key policy, recommended over service and account SAS, only available for Blob Storage, validity maximum 7 days. Service SAS—secured with storage account key, grants access to specific service (Blob, Queue, Table, Files), configure permissions (read, write, delete, list) and time window, use stored access policy for revocation capability. Account SAS—secured with storage account key, grants access to multiple services and resource types, broadest SAS type, harder to secure than service SAS, use when multi-service access required.

SAS token parameters: Permissions—read (r), write (w), delete (d), list (l), add (a), create (c), update (u), process (p), tag (t), filter (f), set immutability policy (i), permanent delete (y), specify minimal required. Start time—when SAS becomes valid, optional (defaults to creation time), use for future-dated access. Expiry time—when SAS expires, required field, set shortest duration meeting requirements (hours for temporary access, days for longer operations). Allowed IP addresses—restrict SAS usage to specific IP or range, enhances security preventing token use from unexpected locations. Allowed protocols—HTTPS only (recommended) or HTTP and HTTPS, always use HTTPS for production. Resource types (Account SAS)—service, container, object, specify which resource types accessible. Generating SAS: Portal (Storage account → Shared access signature → Configure parameters → Generate SAS), Azure Storage Explorer (right-click container or blob → Get Shared Access Signature), PowerShell (New-AzStorageContainerSASToken), CLI (az storage container generate-sas), SDK (BlobSasBuilder). User delegation SAS example: User authenticated with Azure AD, has Storage Blob Delegator role, generates token signed with Azure AD credentials, shares token with external party, external party accesses blob using SAS URL, access expires after configured time.

Stored access policies: Define access policy on container or share, create SAS referencing stored policy by name, modify policy changing all associated SAS tokens without regenerating, enables SAS revocation (delete stored policy invalidating all tokens), up to 5 stored access policies per container. Configure: Container → Access policy → Add policy → Set permissions, start time, expiry → Save. Create SAS referencing policy: Specify policy ID when generating SAS, SAS inherits policy parameters, modify policy updating all SAS tokens. SAS best practices: Use user delegation SAS instead of account-key-based SAS for Blob Storage, set shortest expiration meeting requirements (hours or days not months), always use HTTPS only protocol, restrict to specific IP ranges when client IP predictable, grant minimal permissions required for task, use stored access policies for service SAS enabling revocation, monitor SAS usage in diagnostic logs, implement SAS generation service controlling who can create SAS, don't embed SAS tokens in client-side code or URLs, rotate SAS tokens regularly for long-term use, document SAS token distribution for security tracking. Anonymous access (public read): Allows unauthenticated access to blobs without credentials, three levels: Off (default, no anonymous access), Blob (anonymous read of individual blobs but can't list container), Container (anonymous read of blobs and container listing). Security risk: Data accessible to anyone with URL, use only for truly public content (public website assets, public downloads), disable at storage account level (portal → Configuration → Allow Blob public access → Disabled) preventing any container from enabling anonymous access. Best practice: Disable anonymous access at storage account level for production, use SAS tokens for temporary sharing instead of anonymous access, audit anonymous access configuration regularly, alert on anonymous access enablement attempts.

Data Protection and Resilience

Soft Delete and Versioning

Soft delete protects against accidental or malicious deletion retaining deleted items for recovery. Blob soft delete: Deleted blobs and snapshots retained in soft-deleted state for configured period (1-365 days), deleted items marked but hidden from normal listing, recover deleted blobs during retention period, protects against accidental deletion, provides defense against ransomware (restore to point before attack). Enable: Storage account → Data protection → Enable soft delete for blobs → Set retention period (recommended 30-90 days balancing recovery window and storage costs). Viewing deleted blobs: Portal → Container → Show deleted blobs (toggle) → Lists deleted items with deletion timestamp and remaining retention days → Select blob → Undelete restoring blob to active state. CLI: az storage blob list --show-deleted, undelete: az storage blob undelete. Container soft delete: Protects entire containers and their blobs from deletion, retention period 1-365 days, deleted containers appear in deleted containers list, restore entire container with all blobs and metadata, enable: Storage account → Data protection → Enable soft delete for containers → Set retention days. Important: Container soft delete independent of blob soft delete—enable both for complete protection. File share soft delete: Protects Azure Files shares from deletion, retention period 1-365 days, deleted shares stored in soft-deleted state, restore share with all files and permissions, enable: Storage account → Data protection → Enable soft delete for file shares → Set retention days.

Blob versioning: Automatically maintains previous versions of blob whenever modified or deleted, every write operation creates new version with unique version ID, previous versions preserved, current version represents latest blob state, no expiration (versions retained until explicitly deleted or lifecycle policy removes), protects against accidental overwrites and modifications. Enable: Storage account → Data protection → Enable versioning for blobs → Automatically tracks all changes. How versioning works: Upload blob—creates version (initial), modify blob—previous becomes version, new state becomes current version, delete blob (soft delete disabled)—current version becomes previous version, blob appears deleted but versions remain, delete blob (soft delete enabled)—current version soft-deleted, accessible for retention period. Accessing versions: Portal → Container → Blob → Versions tab → Shows all versions with timestamp and version ID → Download or promote specific version to current. API: Specify version ID in request URL to access specific version. Lifecycle management: Automatically delete old versions reducing storage costs (example: delete versions older than 90 days). Versioning vs snapshots: Versioning automatic on every change, snapshots manual or policy-based, versioning maintains complete history, snapshots capture specific points in time, use versioning for automatic change tracking, snapshots for explicit backups or milestones. Combining features: Soft delete + versioning + lifecycle management provides comprehensive protection—versioning tracks all changes, soft delete protects against deletion, lifecycle management controls costs deleting old versions, recommended configuration for production storage.

Immutable Storage and Backup

Immutable storage (Write Once Read Many - WORM) prevents modification or deletion of blobs for specified period meeting compliance requirements for financial services, healthcare, legal. Two immutability policy types: Time-based retention—retains blobs in immutable state for specified duration (days, years) from policy application or last modification, blobs readable but not modifiable or deletable during retention, allows creating additional snapshots or versions but not deleting, after retention expires blobs deletable but still not modifiable, extend retention period or apply new policy after expiration. Legal hold—immutable state until legal hold explicitly removed, independent of retention period, multiple legal holds can be applied simultaneously, used for litigation, investigations, regulatory holds, requires explicit removal to allow deletion, tags identify reason for hold (case number, investigation name). Configure immutability: Container → Access policy → Add policy → Select type (Time-based retention or Legal hold) → For time-based: Set retention period in days → Lock policy (optional but recommended for compliance), for legal hold: Set tag → Add. Locked vs unlocked policies: Unlocked policies can be deleted or retention decreased (testing and validation), locked policies permanent—can't be deleted, retention can only be increased (meets SEC 17a-4(f) and similar regulations), always lock policies for compliance scenarios.

Immutability scopes: Container-level immutability (default)—policy applies to all blobs in container, simplest configuration, suitable when all blobs have same retention requirements. Version-level immutability—policy on individual blob versions, granular control for scenarios with different retention per blob, enables some blobs deletable while others protected. Compliance use cases: SEC 17a-4(f) compliance (securities broker-dealers must retain communications and records), CFTC 1.31 (commodity trading), FINRA 4511 (securities regulations), healthcare records (HIPAA retention), legal evidence preservation, ransomware protection (backups can't be deleted or encrypted by attackers). Azure Backup for Blobs: Operational backup providing continuous protection for block blobs, point-in-time restore to any second within retention period (up to 360 days), no scheduled backup jobs (continuous), protects against accidental deletion, corruption, ransomware, restores at container level to original or alternate storage account, requires versioning and soft delete enabled (provides recovery source). Configure: Recovery Services vault → Backup → Azure Blobs → Configure backup policy (retention period) → Select storage accounts → Enable backup. Restore: Select restore point (date/time), choose containers to restore, destination (original or alternate account), restore. Azure Backup for Files: Traditional scheduled backup creating recovery points, configures backup at file share level, creates snapshots as recovery points, retention configurable (days, weeks, months, years), integrates with Recovery Services vault, restores to original location or alternate, supports individual file or full share restore. Configure: Recovery Services vault → Backup → Azure Files → Select file shares → Configure policy (schedule and retention) → Enable protection. Best practices: Enable soft delete for all storage types (blobs, containers, file shares) with 30-90 day retention, implement blob versioning for automatic change tracking, use immutable storage for compliance data (financial records, legal documents, backups), lock time-based retention policies for enforceability, apply legal holds for investigations and litigation, configure Azure Backup for operational backup and long-term retention, combine multiple features for defense-in-depth, test restore procedures regularly, document data protection architecture for compliance, implement lifecycle policies managing costs of versioning and soft delete, enable Resource Lock on storage account preventing account deletion.

Customer-Managed Keys (BYOK)

Implementing Customer-Managed Keys

Azure Storage encrypts all data at rest by default using 256-bit AES encryption. Platform-managed keys (PMK): Microsoft manages encryption keys automatically, no configuration required, keys rotated automatically, no additional cost, sufficient for most scenarios, no customer control over keys or rotation schedule. Customer-managed keys (CMK): Customer controls encryption keys stored in Azure Key Vault or Managed HSM, full lifecycle control (creation, rotation, disabling, auditing, deletion), supports compliance requiring customer-controlled keys (HIPAA, PCI DSS, FedRAMP, FINRA, government), audit trail of key operations, ability to revoke access immediately, optional but required for certain compliance standards. Prerequisites: Azure Key Vault or Managed HSM, RSA or RSA-HSM key (2048, 3072, or 4096 bits, 3072+ recommended for security), Key Vault with soft delete and purge protection enabled (required for CMK), storage account system-assigned or user-assigned managed identity, managed identity with permissions to Key Vault (Key Vault Crypto Service Encryption User role or Get, Wrap Key, Unwrap Key access policies). Configuration steps: Create Key Vault with soft delete and purge protection enabled, create RSA key in Key Vault (recommended 3072-bit or larger), enable managed identity on storage account (System-assigned or User-assigned), grant managed identity Key Vault permissions, configure storage account encryption to use customer-managed keys: Storage account → Encryption → Customer-managed keys → Select Key Vault and key version → Save. Encryption occurs automatically, all data re-encrypted with customer key.

Key Vault configuration: Soft delete retention period (7-90 days, deleted keys recoverable), purge protection (prevents permanent deletion during retention, required for CMK), network rules (restrict Key Vault access to specific networks for security), firewall rules (allow trusted Microsoft services including storage), diagnostic logs (audit key operations), Private Link (private connectivity to Key Vault). Managed identity choice: System-assigned—lifecycle tied to storage account, automatically deleted when storage account deleted, suitable for single storage account scenarios. User-assigned—independent lifecycle, reusable across multiple storage accounts, survives storage account deletion, suitable for centralized identity management, enterprise scenarios. Encryption scopes: Customer-managed keys apply at storage account level (encrypts all services: Blob, Files, Queues, Tables, Managed Disks) or at encryption scope level (different keys for different containers or scenarios). Encryption scopes enable multi-tenant scenarios where each tenant has separate encryption key, different keys for different data classifications (public, internal, confidential), key isolation for compliance. Key rotation: Manual rotation—create new key version in Key Vault, update storage account encryption to reference new version (portal: Encryption → Customer-managed keys → Update key version), Azure re-encrypts data gradually with new key (automatic background process), old key version retained for reading existing data during re-encryption. Automatic rotation (recommended)—enable automatic key rotation in Key Vault storage account encryption settings, storage account automatically uses latest key version, configure rotation policy in Key Vault (days, months, years before rotation), eliminates manual rotation errors.

Key Management and Monitoring

Key Vault permissions: Managed identity requires specific permissions for encryption operations. RBAC method (recommended): Assign Key Vault Crypto Service Encryption User role to managed identity at Key Vault scope, provides get, wrap key, unwrap key permissions, scoped to keys only. Access policy method (legacy): Grant managed identity Get (read key metadata), Wrap Key (encrypt), Unwrap Key (decrypt) permissions. Key revocation: Disable or delete key in Key Vault immediately revoking storage account access to data, storage operations fail with authorization errors, read and write operations return errors, useful for security incidents, compliance requirements, emergency access revocation, re-enable key or restore from soft delete to resume access. Test revocation: Disable key in Key Vault, attempt storage operation (should fail), enable key, retry operation (should succeed). Monitoring: Key Vault diagnostic logs capture key operations (Get, Wrap Key, Unwrap Key) showing when storage accessed keys, storage account metrics show encryption status and failures, configure alerts on encryption failures or key access issues, integrate logs with Log Analytics for analysis, create dashboards showing key usage patterns. Azure Monitor queries: Key operations by storage account, failed key accesses indicating issues, key access frequency patterns, unauthorized key access attempts.

Managed HSM: Higher security than Key Vault for highly regulated environments, FIPS 140-2 Level 3 validated HSM hardware, single-tenant dedicated HSM pool, customer controls security domain (cryptographic control), supports same CMK scenarios as Key Vault, higher cost than Key Vault, recommended for government, finance, healthcare, any scenario requiring hardware-based key protection with full customer control. Configure: Create Managed HSM, transfer security domain to customer control, create RSA-HSM key, configure storage account encryption using Managed HSM key. Benefits: Hardware-based security, FIPS 140-2 Level 3 compliance, single-tenant isolation, customer security domain control. Best practices: Enable soft delete and purge protection on Key Vault, use user-assigned managed identity for enterprise scenarios, implement automatic key rotation reducing manual overhead, monitor key operations with alerts on failures, test key revocation procedures, document key management processes for compliance, restrict Key Vault network access using Private Link or firewall, configure Key Vault diagnostic logging for audit trail, use Managed HSM for highest security requirements, combine CMK with infrastructure encryption for double encryption, maintain key backup and recovery procedures, regularly audit Key Vault access and permissions, implement break-glass access procedures for Key Vault issues, use separate Key Vaults for production and non-production, document customer-managed key architecture for audits, test disaster recovery scenarios including key recovery.

Infrastructure-Level Double Encryption

Understanding and Enabling Double Encryption

Azure Storage infrastructure encryption provides second encryption layer below service-level encryption creating defense-in-depth against cryptographic attacks. Single encryption (default): Data encrypted once at service level using AES-256, sufficient for most scenarios, uses platform-managed keys (default) or customer-managed keys (optional), meets standard security requirements. Infrastructure encryption (double encryption): Enables second encryption layer at Azure infrastructure level (hardware/firmware), data encrypted twice with different keys: Service layer encryption using AES-256 (customer-managed or platform-managed keys), Infrastructure layer encryption using AES-256 (always platform-managed keys, customer doesn't control infrastructure keys), two layers use different keys eliminating single point of failure, encryption algorithms independent providing cryptographic diversity. Benefits: Defense-in-depth with two encryption layers, compliance for regulated industries requiring double encryption (government, defense, financial services, healthcare), protection if one encryption layer compromised, cryptographic diversity reducing attack risk, meets FIPS 140-2 requirements, suitable for highly sensitive data (classified information, financial data, PHI).

Enable infrastructure encryption: Must enable during storage account creation (cannot enable on existing accounts), cannot be disabled after creation, configuration: Portal → Create storage account → Advanced tab → Enable infrastructure encryption checkbox → Create. CLI: az storage account create --require-infrastructure-encryption true. PowerShell: New-AzStorageAccount -RequireInfrastructureEncryption. Verification: Storage account properties show Infrastructure encryption enabled, audit configuration using Azure Policy. Supported services: Blob Storage (including Data Lake Storage Gen2), Azure Files, Queue Storage, Table Storage, applies to all data in enabled account. Key management: Service layer uses customer-managed keys (optional, configured separately) or platform-managed keys (default), infrastructure layer always uses platform-managed keys (Microsoft controls, customer can't access or manage), separation ensures Microsoft manages lower layer while customer optionally controls upper layer. Combining CMK and infrastructure encryption: Customer-managed key for service layer (full customer control), platform-managed key for infrastructure layer (Microsoft control), provides three-layer protection: Customer-managed key at service layer, platform-managed key wrapping customer key, platform-managed key at infrastructure layer. Maximum security configuration: Enable infrastructure encryption at creation, configure customer-managed keys for service layer, result: two encryption layers with customer controlling one layer.

Performance and cost: Minimal performance impact (hardware-accelerated encryption), no observable latency increase for most workloads, no additional cost for infrastructure encryption (no premium pricing), storage costs same as single encryption. Use cases: Government and defense (classified data protection, FedRAMP High compliance), financial services (sensitive financial data, SEC/FINRA requirements), healthcare (PHI and medical records, HIPAA compliance), critical infrastructure (protection of sensitive operational data), legal and compliance (data requiring maximum protection for litigation or audit), any highly regulated industry requiring defense-in-depth. Verification and audit: Storage account properties display infrastructure encryption status, Azure Policy can audit and enforce infrastructure encryption (custom policy: Require infrastructure encryption on storage accounts), Resource Graph queries identify storage accounts with/without infrastructure encryption, compliance reports document encryption configuration. Best practices: Enable infrastructure encryption for new storage accounts in regulated environments, combine with customer-managed keys for maximum control, verify encryption enabled during account creation, use Azure Policy enforcing infrastructure encryption for compliance, document encryption architecture in security documentation, include in compliance audits, test disaster recovery with encrypted storage, monitor encryption operations for failures, maintain encryption configuration inventory, regular security assessments validating encryption effectiveness. Migration strategy: Infrastructure encryption only available at creation, migrate data from existing account to new account with infrastructure encryption using AzCopy or Azure Data Factory, thoroughly test migrated data, update applications to new storage account, document migration for compliance, schedule migration during maintenance window.

Exam Preparation Tips

Key Concepts to Master

• Access control: Control plane (Azure RBAC: Owner, Contributor, Reader), data plane (Storage Blob Data Contributor/Reader, File Data SMB Share roles)
• Access keys: Two keys enable rotation without downtime, rotate every 90 days, store in Key Vault, disable shared key authorization when Azure AD sufficient
• Azure Files auth: Azure AD DS (cloud-native), on-premises AD DS (hybrid), storage key (not recommended), share-level RBAC + NTFS permissions
• Blob access: Azure AD (recommended with managed identities), SAS (user delegation most secure), storage keys, anonymous access (disable at account level)
• SAS types: User delegation SAS (Azure AD-secured, most secure), Service SAS (key-secured, specific service), Account SAS (key-secured, multiple services)
• Soft delete: 1-365 day retention, recovers deleted blobs/containers/file shares, enable for all storage types with 30-90 day retention
• Versioning: Automatic on every change, maintains complete history, combine with lifecycle management for cost control
• Immutable storage: Time-based retention (days/years), legal hold (until removed), lock policies for compliance, prevents modification/deletion
• BYOK: Customer-managed keys in Key Vault, soft delete + purge protection required, managed identity with Get/Wrap/Unwrap, automatic rotation recommended
• Infrastructure encryption: Double encryption at creation only, can't enable later, combines with CMK for triple protection

Practice Questions

Hands-On Practice Lab

Lab Activities

Lab Outcomes

After completing this lab, you'll have practical experience with Azure Storage security. You'll understand how Azure AD authentication provides identity-based access control, user delegation SAS tokens enable secure temporary access, soft delete and versioning protect against accidental deletion and modification, customer-managed keys provide encryption key control, and monitoring captures storage access events. These hands-on skills demonstrate storage security capabilities tested in AZ-500 exam and provide foundation for implementing comprehensive storage protection in production Azure environments.

Frequently Asked Questions