Maintaining business-critical data integrity in Azure

Reading Time: 3 minutes

I recently learned about an Azure feature called Immutable Blob Storage. Also known as WORM (write once, read many), these features make data non-erasable and non-modifiable. It is quite a simple feature to understand and implement. In this article I discuss the typical scenarios, how it works and provide an example of how to use this feature.

Side Note: As of the time of this writing, this feature is available for Blob Storage accounts in all Azure regions.

Typical Scenarios

These are a few cases for immutable storage:

  • Immutable storage is crucial for industries such as Financial and Healthcare, where the data integrity is paramount. It helps business achieve regulatory compliance such as HIPAA and FINRA.
  • Immutable storage keeps in a tamper proof state. This is a requirement for cases such as litigation related or business documents.
  • Immutable storage ensures that users cannot modify documents, including those with administrator privileges.

How It Works

Azure Immutable Storage comes in two types of immutable policies, one is time-based and the other is legal hold. Both policies have the same effect, that is, once implemented on a given storage, all documents in that storage go into an immutable state.

It is not possible to delete a container or account if there are any blobs protected by the immutable policy. An attempt to do so will fail while at least one policy is active in at least one storage container in the account.

Policy Types

Time-based policy: When you add a time-based policy to a container, it applies to all documents in a container. For existing documents, the time it remains immutable is based on the time the document was last modified. For new documents, the time it remains immutable is the time specified by the policy. The main difference is that for existing documents, the time span begins when the document was last modified, vs. from its creation date.

Example: Suppose you have a storage container that has one file created 5 months ago. You add a time-based policy defining a 6-month hold. This file will have an effective hold of 1 month because it has remained in an unmodified state for 5 months prior to when the policy went into effect. Therefore, only the difference in time is the effective hold time.

Meanwhile a new file, added after the policy is created will have an effect hold of 6-months.

A time-based policy has two states, locked or unlocked. By locking a time based policy, it can no longer be deleted. Locked policies allow for extensions of the retention interval. Most regulatory compliance rules require a locked time-based policy, before it can be compliant.

Legal-hold policy: When you add a legal hold policy to a container, all documents in that container will remain in an immutable period until the legal hold is removed. A legal hold policy is very straight forward.

How to Implement

Implementing a hold policy is quite simple. Once you have created a storage container, you can add a policy via the Portal or command line.

Here I create a new Resource Group, Storage Account and Container. The container called immutableblob. Then you need to access the container Access Policy options via the options menu to the right of the container name.

azure immutable access policy

Once here, you have the option for Immutable Blob Storage.

azure immutable access policy

Once here, you choose the Policy Type – Time Baser or Legal Hold. The Time Based policy requires a parameter for the number of days for which it should remain in effect. If the Time Based policy is not locked, it can be removed at any time.

azure immutable access policy

This covers the basics of Azure Immutable Blob Storage. As you can see, the feature is fairly simple to understand and implement. More details, including an FAQ and scripts are available on Microsoft’s documentation page.

Leave a comment

Your email address will not be published. Required fields are marked *