Immutable Storage for Azure Storage Blobs Available Now

Microsoft is coming with many more supporting features for Azure and they are growing very fast  . In this post we just share now feature availability Immutable Storage for Azure Storage Blobs and some information about this Immutable Storage.

You may think what is mean  by  Immutable Storage and what is the purpose of this  , When using immutable storage, no one can delete or alter your data–not even a systems administrator.

• No one person should be able to destroy data that is in an immutable storage
• Nobody should be able to touch a production system anonymously.

Let’s check what Microsoft says about what they offers with Immutable Storage

Financial Services organizations regulated by the Securities and Exchange Commission (SEC), Commodity Futures Trading Commission (CFTC), Financial Industry Regulatory Authority (FINRA), Investment Industry Regulatory Organization of Canada (IIROC), Financial Conduct Authority (FCA), and more are required to retain business-related communications in a Write-Once-Read-Many (WORM) or immutable state that ensures they are non-erasable and non-modifiable for a specific retention interval. The immutable storage requirement is not limited to financial organizations but also applies to industries such as healthcare, insurance, media, public safety, and legal services.

Today, we are excited to reveal the general availability of immutable storage for Azure Storage Blobs to address this requirement. The feature is available in all Azure public regions. Through configurable policies, users can keep Azure Blob storage data in an immutable state where Blobs can be created and read, but not modified or deleted.

Typical applications include:

• Regulatory compliance: Immutable storage for Azure Blobs is designed to help financial institutions and related industries address SEC 17a-4(f), CFTC 1.31©-(d), FINRA etc. A technical whitepaper with details on how the feature addresses these regulatory requirements is downloadable now via the Service Trust Portal. The Azure Trust Center contains detailed information about our compliance certifications.
• Secure document retention: Users receive maximum data protection as the immutable storage feature for Azure Blobs service ensures that data cannot be modified or deleted by any user including those with account administrative privileges.
• Legal hold: Immutable storage for Azure Storage Blobs enables users to store sensitive information critical to a litigation, criminal investigation, and more in a tamper-proof state for the desired duration.

Immutable storage for Azure Storage Blobs enables

• Time-based retention policy support: Users set policies to store data immutably for a specified interval of time.
• Legal hold policy support: When the retention interval is not known, users can set legal holds to store data immutably until the legal hold is cleared.
• Support for all Blob tiers: WORM policies are independent of the Azure Blob Storage tier and will apply to all the tiers, hot, cool and archive. This allows customers to store the data in the most cost-optimized tier for their workloads while maintaining the data immutability.
• Blob Container level configuration: Immutable storage for Azure Storage Blobs allows users to configure time-based retention policies and legal hold tags at the container level. Users can create time-based retention policies, lock policies, extend retention intervals, set legal holds, clear legal holds etc. through simple container level settings. The policies apply to all the Blobs in the container, both existing and new Blobs.

Immutable data is priced in the same way as mutable data and there is no additional charge for using this feature. Please refer to the Azure Storage Pricing page for the related pricing details.

How to Use Immutable Storage

To use this feature you must create a General-purpose v2 (GPv2) account through the Azure Resource Manager. You can test or enable this feature using below procedure

• Navigate to Storage Account -> Blobs Service
• Create a new container or select an existing container to store the blobs that need to be kept in the immutable state.

Note:-The container must be in a GPv2 or blob storage account.

• Select Access policy in the container settings and choose Add policy under Immutable blob storage
• Select Time-based retention from the drop-down menu

• Enter the retention interval in days (minimum is one day) and Click OK.

Initial state of the policy will be in unlocked and you can change to the policy before you lock it. Locking is essential for compliance with regulations like SEC 17a-4.

• You can lock the policy by  Right-clicking  the ellipsis (…), and the following menu appears and click on Lock Policy

You have type  ” yes ” to confirm and click to get activate the policy . After the policy is locked, it can’t be deleted, and only extensions of the retention interval will be allowed.

After enabling the your window will look like below image .

• To enable legal holds again add Policy and simply selectLegal hold from the drop-down menu and click ok.

• Create a legal hold with one or more tags by adding the tag names over there

• Click OK to activate the legal hold   . Additionally to clear a legal hold, simply remove the tag.

Test Immutable Storage working or not

Select container we created with policy and click on Delete , it will give a message shown below , lets click on ” yes “ to continue

And it failed , as it cannot be deleted since it  is a Immutable Storage  , Message shows like below image.

 

Immutable Storage for Azure Storage Blobs is supported in the Azure Portal, the .net Client Library (version 7.2.0-preview and later) the node.js Client Library (version 4.0.0 and later), the Python Client Library (version 2.0.0 and later) and the Java Client Library. Preview support is available in CLI 2.0, and PowerShell (version 4.4.0-preview) with production support coming very soon.

You can also directly use the Storage Services REST API. This feature is supported on Blob Service REST API version 2017-11-09 and later and on Azure Storage Resource Provider REST API version 2018-02-01 and later. In general, we always recommend using the latest versions regardless of whether you are using the feature or not.

Reference 01

Reference 02