Azure Immutable Storage Explained

Azure Immutable Storage is a game-changer for data protection and compliance. It ensures that data is stored in a read-only state, making it tamper-evident and resistant to accidental or malicious modifications.

This feature is especially useful for organizations that need to meet strict regulatory requirements, such as those in the healthcare or finance industries. Azure Immutable Storage helps ensure that data remains intact and unchanged over time.

In Azure Immutable Storage, data is stored in a blob or file, which is then frozen in place and cannot be modified or deleted. This means that any changes made to the data will result in a new version being created, rather than overwriting the original.

Readers also liked: What Is the Data Storage in Azure Called

Microsoft recommends enabling blob soft delete for extra protection before applying immutability policies. This ensures that blobs are protected from accidental deletion.

Blob soft delete is configured at the storage account level and applies to all blobs within the account, regardless of any legal hold or time-based retention policy. Soft-deleted blobs can be restored during the soft delete retention period.

Consider reading: Azure Blob Storage Retention Policy

Azure Storage Blobs support two types of WORMs: Time-based Retention and Legal Holds. These policies can be applied at the account or container level.

Here are the two types of WORMs supported by Azure Storage Blobs:

Even the Administrator of the Storage Account cannot delete or modify content if a WORM is active. This ensures that data is preserved in a non-rewriteable and non-erasable format, meeting securities industry requirements.

Immutable Storage is designed to meet securities industry requirements for preserving records in a non-rewriteable and non-erasable format.

Azure Storage Blobs support two types of Write-Once, Read-Many (WORM) policies: Time-based Retention and Legal Holds. These policies are supported at account or container level.

The Time-based Retention policy locks data for a specified period, preventing modification or deletion until the retention period expires. The Legal Holds policy, on the other hand, allows data to remain locked even after the retention period has expired, until the hold is lifted.

Curious to learn more? Check out: Which Azure Storage Service Supports Big Data Analytics

Azure Storage Blobs support WORM policies at container level, and once applied, all blobs under the container will respect that specific policy. This means that existing or new blobs will be immutable, and even the Administrator of the Storage Account will not be able to delete or modify the content.

The following types of blobs support WORM policies: Block Blobs, Append Blobs, and Page Blobs. However, it's recommended to use only Block Blobs and Append Blobs for this feature.

Related reading: Block Level Storage

Immutable storage is a feature that ensures data is preserved in a non-rewriteable and non-erasable format. This means that even the administrator of the storage account cannot delete or modify the content if the WORM (Write-Once, Read-Many) policy is active.

Azure Storage Blobs support two types of WORMs: Time-based Retention and Legal Holds. These policies can be applied at the account or container level.

Time-based Retention and Legal Holds prevent write and delete operations while they are in effect. This ensures that data is preserved for a specified period of time or until a legal hold is removed.

A WORM policy can be applied to all types of blobs, but it's recommended to use only block blobs. Once a policy is applied, existing or new blobs under the container will respect that specific policy.

The following types of WORMs are supported:

These two types of WORMs are supported at account or container level. Once a policy is applied at the container level, all blobs under the container will respect that specific policy.

If you enable blob soft delete and then configure an immutability policy, any blobs that have already been soft deleted are permanently deleted once the soft delete retention policy is expired.

Curious to learn more? Check out: Azure Storage Container

Configuring immutable storage is a crucial step in ensuring the integrity and security of your data in Azure. You can configure immutable storage through the Azure portal or using the Azure SDK libraries.

All redundancy configurations in Azure support immutable storage. For more information about redundancy configurations, see Azure Storage redundancy.

Immutable storage with blob soft delete is a powerful feature that provides extra protection for your data. If you enable blob soft delete and then configure an immutability policy, any blobs that have already been soft deleted are permanently deleted once the soft delete retention policy is expired.

You can use a storage task to configure immutable policies at scale across multiple storage accounts based on a set of conditions that you define. A storage task is a resource available in Azure Storage Actions; a serverless framework that you can use to perform common data operations on millions of objects across multiple storage accounts.

To set up version-level time-based retention policies, you need to enable blob versioning for your storage account. This can be done by navigating to the Storage accounts page on the Azure portal, selecting Data management, and then selecting Data protection.

The SDK libraries that support immutable storage are Java, Python, Node.JS, .NET, and Go. It can also be configured from PowerShell or Azure Portal. To enable support for version-level immutability on a new storage account, follow these steps: Navigate to the Storage accounts -> On the Data protection tab, under Access control, select Enable version-level immutability support.

Readers also liked: Azure Recover Deleted Storage Account

Here's a summary of the steps to enable version-level immutability:

Note that if you don’t see the option to configure a legal hold, it means that your Azure Storage account needs to be upgraded to V2. This can be done from the Azure Portal.

Retention and Compliance is a top priority for organizations that store sensitive data in Azure Immutable Storage. Microsoft has validated that immutable storage meets the relevant storage requirements of CFTC Rule 1.31(c)-(d), FINRA Rule 4511, and SEC Rule 17a-4(f), which represent the most prescriptive guidance globally for records retention for financial institutions.

A time-based retention policy stores blob data in a WORM format for a specified interval, which can be as short as one day or as long as 400 years. This means that once a blob is created, it can't be modified or deleted until the retention period has expired.

The minimum retention interval for a time-based retention policy is one day, and the maximum is 146,000 days (400 years). You can set up a default time-based retention policy for your Azure storage account in the portal, which will apply to all new blob versions.

Related reading: What Is Google One Storage

You can configure a time-based retention policy at either the version-level or container-level, depending on your needs. Here are the scopes where you can configure a time-based retention policy:

Retention scope is a crucial aspect of retention and compliance. A time-based retention policy can be configured at either the version-level or container-level.

At the version-level, a time-based retention policy can be configured to apply to a specific blob version, allowing for granular management of sensitive data. This means you can apply a policy to an individual version or configure a default policy for a storage account or individual container.

A time-based retention policy configured at the container-level applies to all objects in that container. Individual objects can't be configured with their own immutability policies.

You can configure a default time-based retention policy for your Azure storage account in the portal by following the steps outlined in Example 3.

Here's a summary of the different retention scope options:

A legal hold policy can also be configured at either the version-level or container-level. A legal hold is a temporary immutability policy that can be applied for legal investigation purposes or general protection policies.

Deletion is a crucial aspect of retention and compliance, and understanding the rules is essential. A container with a container-level WORM policy set must be empty before it can be deleted.

If there's a policy set on a container with hierarchical namespace enabled, a directory must be empty before it can be deleted. This is a critical step to ensure compliance and avoid any potential issues.

You can't delete a container that has immutable policies if it has even a single blob inside it. The same rule applies to Storage Accounts, which can only be deleted if no active WORM policies are active or no blobs exist.