Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Azure Storage offers two primary ways to control who can access data: Shared Key and Azure Active Directory (Azure AD). Shared Key access uses account keys that grant full administrative rights to the storage account—anyone with a key can read, write, and delete any data in the account. Azure AD integration ties access to user identities, allowing fine-grained permissions through Role-Based Access Control (RBAC), so administrators can assign specific roles like "Storage Blob Data Reader" to specific users or groups. When you enable Azure AD authentication for a storage account, requests must include a valid OAuth token, and the identity must have an RBAC role that permits the requested operation. The control plane (management operations like creating containers) and the data plane (reading/writing blobs) can each use different authentication methods, giving teams flexibility in how they secure different types of access.
Each storage account has two access keys (primary and secondary) that work identically and grant full access to all data and services within the account. These keys never expire, which makes them powerful but risky—if a key leaks, an attacker gains complete control over the storage account. Administrators should store keys in Azure Key Vault rather than in code or configuration files, and applications should retrieve keys securely at runtime rather than hardcoding them. Azure provides the ability to regenerate keys on demand; when you regenerate the primary key, any applications using it lose access until they update to use the secondary key, so teams typically regenerate keys in pairs (regenerate secondary, update applications, then regenerate primary). For higher security, disable Shared Key authentication entirely and require Azure AD or Shared Access Signatures (SAS) for all access, which removes the risk of accidental key exposure.
Azure Files offers two protocol options: Server Message Block (SMB) for Windows/Linux file shares and Network File System (NFS) for Linux workloads. SMB access supports both Shared Key and Azure AD authentication, while NFS requires Azure AD Domain Services for identity mapping. When mounting Azure Files shares, the storage account name becomes part of the UNC path (\storageaccount.file.core.windows.net\share), and the authentication method determines what credentials the client presents. For enterprises, Azure AD authentication over SMB integrates with existing Active Directory permissions, so file-level ACLs work similarly to an on-premises file server. Teams choose SMB when they need broad OS compatibility and choose NFS when they need POSIX-compliant permissions on Linux systems.
Azure Blob Storage supports three access tiers: Hot (frequently accessed), Cool (infrequently accessed), and Archive (rarely accessed). Access to blobs can be controlled through Azure AD, Shared Access Signatures, or anonymous public access. SAS tokens are useful for granting limited-time access to specific blobs or containers without sharing account keys—a token can specify permissions (read, write, delete), an expiration time, and optionally a specific IP address or protocol. When SAS tokens are generated, they are signed with either the account key or a Stored Access Policy that defines the token's parameters centrally. Blob-level permissions can also be set using Azure AD role assignments that apply to specific containers or even individual blobs through inherited role definitions. For applications, the SDK automatically handles authentication when configured with the appropriate credential type.
Soft delete protects against accidental or malicious deletion by retaining deleted blobs and container entries for a configurable retention period (1-365 days). When soft delete is enabled, a deleted blob enters a soft-deleted state rather than being permanently erased, and administrators can recover it before the retention period expires. Versioning maintains historical copies of blobs automatically whenever a blob is modified, creating a new version with each write operation; this allows teams to restore previous versions when data becomes corrupted or needs rollback. Immutable storage prevents any modifications or deletions for a specified duration using WORM (Write Once, Read Many) policies, which satisfy regulatory requirements for data that must not change after creation, such as financial records or healthcare documents. Azure Backup can protect blob data by taking snapshots and storing them in a Recovery Services vault, providing another recovery point beyond what soft delete offers. These controls work together: immutable storage blocks changes at the storage layer, versioning preserves previous states automatically, soft delete protects against accidental loss, and backups provide off-site recovery capability.
Bring Your Own Key (BYOK) allows customers to use encryption keys they control in Azure Key Vault to encrypt data in their storage accounts, rather than relying solely on Microsoft-managed keys. The process involves generating an encryption key on-premises (or in a separate Key Vault), transferring it to the target Key Vault using the Azure Key Vault import feature, and then assigning that key to the storage account's encryption settings. When BYOK is configured, the storage account requests the key from Key Vault each time it needs to encrypt or decrypt data, and the key never leaves the HSM-protected environment. This model satisfies compliance requirements where organizations must control the lifecycle of their encryption keys, because administrators can revoke access, rotate keys, or delete them entirely, which renders the encrypted data unrecoverable. The storage account must have permission to use the key (through Key Vault access policies or RBAC), and the key must remain available for the storage account to function.
Azure Storage enables double encryption by default for all new storage accounts, providing encryption at both the service level and the infrastructure level using different algorithms and keys. Service-level encryption (SSE) uses AES-256 and is managed by Microsoft by default, but customers can replace the platform key with their own key from Key Vault (the BYOK scenario described above). Infrastructure-level encryption adds a second encryption layer that uses platform-managed keys, ensuring that data remains encrypted even if one encryption layer were somehow compromised. Both layers encrypt data before it is written to disk, and both layers decrypt data when read, with the decryption happening transparently to users and applications. This defense-in-depth approach satisfies many regulatory frameworks that require multiple encryption mechanisms, and because both layers are enabled automatically, administrators do not need to take additional steps beyond creating the storage account.
Prepare and test your skills
Prepare and test your skills
Shared Key authentication uses account keys that grant full administrative rights to the entire storage account, while Azure AD authentication ties access to user identities and allows fine-grained permissions through Role-Based Access Control (RBAC). Azure AD enables administrators to assign specific roles like 'Storage Blob Data Reader' to users or groups, and requests must include a valid OAuth token.
Azure Blob Storage offers soft delete, which retains deleted blobs for a configurable period of 1 to 365 days, and versioning, which automatically maintains historical copies of blobs whenever they are modified. Immutable storage uses Write Once, Read Many (WORM) policies to prevent any modifications or deletions for a specified duration, and Azure Backup can provide additional recovery points via snapshots.
Bring Your Own Key (BYOK) allows customers to use their own encryption keys from Azure Key Vault instead of Microsoft-managed keys. The storage account requests the key from Key Vault for encryption and decryption operations, and the key never leaves the HSM-protected environment, giving the organization control over the key's lifecycle, including revocation and rotation.
StudyCerts
StudyCerts