Ensure 'Enable Infrastructure Encryption' for Each Storage Account in Azure Storage is Set to 'enabled'

Overview

Enabling double encryption at the hardware level on top of the default software encryption for Storage Accounts accessing Azure storage solutions.

Rationale

Azure Storage automatically encrypts all data in a storage account at the network level using 256-bit AES encryption, which is one of the strongest, FIPS 140-2-compliant block ciphers available. Customers who require higher levels of assurance that their data is secure can also enable 256-bit AES encryption at the Azure Storage infrastructure level for double encryption. Double encryption of Azure Storage data protects against a scenario where one of the encryption algorithms or keys may be compromised. Similarly, data is encrypted even before network transmission and in all backups. In this scenario, the additional layer of encryption continues to protect your data. For the most secure implementation of key based encryption, it is recommended to use a Customer Managed asymmetric RSA 2048 Key in Azure Key Vault.

Impact

The read and write speeds to the storage will be impacted if both default encryption and Infrastructure Encryption are checked, as a secondary form of encryption requires more resource overhead for the cryptography of information. This performance impact should be considered in an analysis for justifying use of the feature in your environment. Customer-managed keys are recommended for the most secure implementation, leading to overhead of key management. The key will also need to be backed up in a secure location, as loss of the key will mean loss of the information in the storage.

Default Value

By default, Infrastructure Encryption is disabled in blob creation.

Additional Information

The default service side encryption for Azure Storage is enabled on every block blob, append blob, or page blob that was written to Azure Storage after October 20, 2017. Hardware encryption, however, cannot be enabled on a blob storage after its creation. There are ways to copy all data from a blob storage into another or download and reupload into another blob storage. This could result in data loss and is not recommended.

Remediation guidance

From Azure Portal

During Storage Account creation, in the Encryption tab, check the box next to Enable infrastructure encryption.

From Azure CLI

az storage account create \
  --name <storage-account> \
  --resource-group <resource-group> \
  --location <location> \
  --sku Standard_RAGRS \
  --kind StorageV2 \
  --require-infrastructure-encryption

From PowerShell

New-AzStorageAccount -ResourceGroupName <resource_group> `
  -AccountName <storage-account> `
  -Location <location> `
  -SkuName "Standard_RAGRS" `
  -Kind StorageV2 `
  -RequireInfrastructureEncryption

Service-wide remediation

Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.

Azure

Use management group or subscription Azure Policy assignments, remediation tasks where supported, landing-zone standards, and IaC modules so drift is prevented at scale.

Operational rollout

Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
Re-scan and track approved exceptions with an owner and expiry date.

Query logic

These are the stored checks tied to this control.

Azure Storage Accounts Without Infrastructure Encryption

Connectors

Microsoft Azure

Covered asset types

StorageAccount

Expected check: eq []

{
  storageAccounts(where: { requireInfrastructureEncryption: false }) {
    ...AssetFragment
  }
}