Microsoft: Blobs can be WORMs in the new, regs-compliant Azure Microsoft emitted a preview of immutable storage for Azure Storage Blobs yesterday in an effort to win the hearts and minds of industries weighed down by regulation. The feature, which bears more than a passing resemblance to Amazon's Glacier Vault Lock, is the latest move in a series of tit-for-tat feature updates as …
Tokenising identifying information in documents would address that, but that is quite tricky and needs to be there from the start so is unlikely to be used in most current cases, perhaps future cases will do it properly (but I'm not holding my breath).
Also tokenisation creates a whole new can of worms as the token holding database is by definition stuffed full of personal identifying data, keeping that secure and current will be a fun task for administrators.
Something that will become important is how such blobs are read. The design of the blob format and the reading of it will need to be closely examined to ensure that everything recorded in the blob is made available to, and displayed by, the Reader. If there's tags contained in the blob stream which could be used to filter out passages from view then there's a danger that Readers can be constructed which silently redact content.
To quote a certain G. Orwell in one of his minor works..
"This process of continuous alteration was applied not only to newspapers, but to books, periodicals, pamphlets, posters, leaflets, films, sound-tracks, cartoons, photographs — to every kind of literature or documentation which might conceivably hold any political or ideological significance. Day by day and almost minute by minute the past was brought up to date. In this way every prediction made by the Party could be shown by documentary evidence to have been correct, nor was any item of news, or any expression of opinion, which conflicted with the needs of the moment, ever allowed to remain on record."
I'm ever reminded that the man could see the future.
https://en.wikipedia.org/wiki/Write_once_read_many
"Write once read many (WORM) describes a data storage device in which information, once written, cannot be modified. This write protection affords the assurance that the data cannot be tampered with once it is written to the device."
Last I looked at amazon's offering(month or three ago) theirs was not really WORM. It sounds like Azure is going the same route, where the WORM aspect is just a policy. Adjust the policy and you can then write to the data again?(didn't see any indication that this was not easily achievable by an admin)
On the SAN side I know 3PAR has a feature called Virtual Lock which has a better approach:
"Virtual Lock Software gives users the ability to protect data volumes and volume copies from intentional or unintentional deletions. During the user-specified retention period, volumes and copies can be read but are protected against deletion, even by an administrator with the highest level user privileges."
(if you wanted to protect against any writes to the data you would create a read only snapshot and lock that)
emphasis on the fact that the admin cannot change the policy once set. If you lock the data for 2 years it is set for 2 years. More difficult to achieve perhaps on from a service provider perspective where you may be paying per month for the service I don't know.
I'm sure there are other systems that have similar capabilities I am just personally most familiar with 3par.
That policy looks pretty bad if someone fat-fingers the lock. Or if someone sets the lock when they lack authority. Or if they set it based on a misunderstanding. Or if a regulation or law changes that requires something else. Or if they are a bad actor.
OTOH, it would be easy to move such a policy to the cloud by simply requiring prepayment for the storage of & access to the data...
I'm not yet intimate with the AWS or Azure offerings, however I have experience of EMC Centera.
When an object is saved it receives the policy in force at the time it is written as part of the metadata of the object. You cannot then reduce the life of an already stored object . You can reduce the policy for new writes, and you can add life to existing objects.
It's a shame Dell have decided to stop selling Centera as it was pretty good and simple as part of a lifecycle management service.
And yes, if you fat-finger some form of mistake you're stuck with your data. Like sex, one mistake and you have to support for life.
"raised the spectre of the General Data Protection Regulation (GDPR), warning that immutability could cause headaches when personal data requires rectification or erasure." and the "right to be forgotten"
Normally you would only use this type of storage when you have to meet a regulatory requirement to retain data (e.g. in case the FCA, HMRC, etc what to investigate you) Those regulatory requirements absolutely keep you within storing the data as part of GDPR and they trump the right to be forgotten. e.g. banks must retain mortgage contracts for 7 years after the mortgage is closed, and you cannot request that data be deleted within those 7 years (well you can request, they just won't do it).
The storage does come with a lifecycle management ("time-based data retention" as AWS calls it), so it prevents deletion during the required hold period and can automatically delete it at the end of the lifecycle, actually simplifying and enhancing compliance with GDPR.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
