You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
Azure Storage service-side encryption (SSE) automatically encrypts all data at rest using 256-bit AES encryption, which meets FIPS 140-2 standards and works like BitLocker. This encryption is turned on by default for every storage account, covering all performance tiers, access tiers, and deployment models. It protects not just the actual data but also object metadata across blobs, disks, files, queues, and tables. There is no extra charge for this encryption, and it cannot be turned off, so data stays protected without any extra work from you.
Microsoft-managed keys handle encryption by default, but you can take more control through two customer-controlled options. Customer-managed keys let you use your own key stored in Azure Key Vault or Azure Key Vault Managed HSM to encrypt and decrypt data in Blob Storage and Azure Files. Customer-provided keys work differently—you supply an encryption key directly with each Blob Storage request, giving you fine-grained control over individual operations. The main difference between these options is where the key lives and who is responsible for rotating it.
Encryption scopes let you apply different encryption rules to specific containers or even individual blobs within the same storage account. This is useful when you need to separate data between different customers or departments. Each encryption scope can use either Microsoft-managed keys or customer-managed keys, creating distinct security boundaries that help meet regulatory compliance requirements.
For the highest security needs, you can enable infrastructure encryption, which applies double encryption—once at the service level and again at the infrastructure level—using two different algorithms and two different keys. Even if someone compromises one encryption system, the data remains protected by the second layer. The service-level encryption can use Microsoft-managed or customer-managed keys, while the infrastructure level always uses a separate Microsoft-managed key.
Client-side encryption encrypts data in your application before it uploads to Azure, adding protection for sensitive information. However, you should use client-side encryption v2 (which uses GCM mode with AES) rather than v1, because v1 has a known security vulnerability. If you have existing v1-encrypted data, you need to migrate it to v2. Note that client-side encryption does not work with Table Storage.
Azure Storage Service Encryption (SSE) protects all data at rest by default using Microsoft-managed keys, giving every storage account basic security without any setup. For organizations that need more control—such as meeting specific regulatory requirements—you can switch to customer-managed keys (CMK) using Azure Key Vault, which lets you own and manage the encryption keys yourself.
To enable customer-managed keys, you need an Azure Key Vault with Soft Delete and Do Not Purge properties turned on. These settings protect against accidentally losing your keys—if a key gets deleted, soft delete lets you recover it within the retention period. Without these properties enabled, you cannot use the key vault with storage account encryption.
You can configure customer-managed keys through the Azure portal, PowerShell, or Azure CLI. In the portal, you navigate to your storage account, select Security + networking, then Encryption, and change the encryption type to customer-managed keys before specifying your key vault and key. With PowerShell, you use the Set-AzStorageAccount command with the -StorageEncryption option, while Azure CLI uses az storage account update with --encryption-key-source set to Microsoft.KeyVault.
For extra protection, infrastructure encryption adds a second layer of encryption on top of whatever you already have configured. When you enable this, data gets encrypted twice—once by the storage service and once at the infrastructure level—using two different keys and algorithms. You enable this when creating a storage account by including the -RequireInfrastructureEncryption option in PowerShell or CLI.
Using customer-managed keys and infrastructure encryption helps meet compliance requirements by giving you control over encryption keys and the ability to audit key access. This matters most for organizations in regulated industries like healthcare or finance where strict data protection standards apply.
Customer-managed keys (CMK) give you full control over the encryption keys protecting your Azure Storage data, which helps meet compliance requirements and provides flexibility in how you manage key lifecycle. These keys must live in Azure Key Vault or Azure Key Vault Managed HSM, and the key vault must have both soft delete and purge protection enabled before you can use it with storage encryption.
To set up CMK, you need a managed identity assigned to your storage account—this can be either user-assigned or system-assigned. This managed identity receives the Key Vault Crypto Service Encryption User role, which grants minimum permissions to perform three operations: wrapkey (to encrypt the key), unwrapkey (to decrypt the key), and get (to read the key). The key vault supports RSA and RSA-HSM keys at 2048, 3072, or 4096 bits.
When configuring CMK, you choose between automatic and manual key version updates. With automatic rotation, Azure Storage checks your key vault daily for new key versions and updates the encryption key without any action from you. With manual rotation, you specify the exact key version and must update the storage account settings yourself whenever you create a new key version. Either approach works, but automatic rotation reduces the operational burden.
Key rotation is important for security, and while Azure Storage does not rotate keys automatically, you can set up rotation policies in Azure Key Vault or rotate keys manually. After rotating a key, you update the storage account to use the new version—this does not cause any downtime or affect data accessibility. The old key version remains usable for decrypting existing data until you remove it.
If you disable or revoke a customer-managed key, any storage operations that need decryption will fail with error code 403 (Forbidden). This affects Blob Storage operations like listing, reading, copying, and writing blobs, as well as Azure Files operations like creating, listing, reading, and modifying files and directories. Revoking a key essentially locks access to the encrypted data, which is exactly what you want when meeting strict compliance requirements—but it also means you must be careful never to revoke a key you still need.
You can switch between Microsoft-managed keys and customer-managed keys at any time through the portal, PowerShell, or CLI. This flexibility lets your organization change its security approach as requirements evolve. When switching back to Microsoft-managed keys, Azure takes over key lifecycle management again. Always keep soft delete and purge protection enabled on your key vault, assign only necessary permissions through Azure RBAC, and regularly audit who has access to your encryption keys.
StudyCerts
StudyCerts