Protecting snapVault volumes against rogue administrator deletion

[sstsupportcontracts]

Hello fellow community members,

I'm trying to work out, in detail, how to protect our snapVault volumes against deletion by a rogue administrator, whilst still being able to perform restores using FlexClones.

We run our VMs on volumes accessed over NFS on our MetroCluster. These volumes are protected by snapVault to a FAS8200 system. When we need to restore a VM, we clone the relevant snapVault volume from the appropriate snapshot, present this volume to the VM hosts, import the VM then migrate it back to it's original volume on the MetroCluster. All this works perfectly.

We are concerned that a rogue administrator, or more likely a compromised administrator account, could access our snapVault array and delete all the data. Furthermore, they could log into the service processor and re-initialize the system. They could then do the same to our MetroCluster and in less time than it takes to realize what's happened, all of our data is gone. Obviously, we'd like to protect ourselves against this eventuallity.

SnapLock Compliance seems like the answer to this but from what I've read (https://community.netapp.com/t5/Tech-OnTap-Articles/Back-to-Basics-FlexClone/ta-p/84874) you shouldn't create a clone of a snaplock'd volume. My understanding, is that the clone inherits the properties of the parent, therefore cannot be deleted before the retention period expires. My intention had been to set a short retention period, say 14 days, just to protect our most recent snapshots but would this also mean the clone cannot be deteted for 14 days?

If you've solved this issue by another means or have experience of doing so using snaplock, I'd be very interested to hear how. Any help and advice is very much appreciated.

Regards,

Mark

[Sergey_Osipov]

Hello Mark,

I can't imagine how snaplock volumes are going to protect you from a speculative situation you described, like a rogue admin who is able to reinitialize the system.

Okay, let's say snaplock is a protection from reinitializing the system, however still an admin with such a rights will be able to destroy data in other ways, like failing disks for example.

[sstsupportcontracts]

Hi Sergey,

Thanks for your reply. In https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.pow-arch-con%2FGUID-B0D72285-9301-4A20-B68A-8C64A317E995.html it is stated that disks cannot be reinitialized when running in compliance mode. However, I hadn't considered a rogue admin deliberately failing disks in order to destroy the data. I guess it could be argued that manually failing a disk doesn't destroy the data on it and although once you fail enough of them you'll take the aggregate offline, technically, the data would still be present on the disks. If not, then how does snapLock comply with the SEC Rule 17a-4 etc?

One for the guys who wrote it perhaps?

Mark

[Sergey_Osipov]

Mark,

It looks for me that you are trying to find out notional situation and then a protection from it.

By my opinion it is always like that - yes unfortunately in theory it is possible that employees might be rouges, but it is very hard to protect from those kind of situations in general.

here is another theoretical possibility - a rougue  admin have an access to data centre and even though he can't physically destroy storage system - he can steal\replace several disks (5 for example) - so data is inaccessible in general, no matter if it was protected by snaplock or by any other solution.

Which by the way is written 

https://www.netapp.com/us/media/ds-2448.pdf

" Only an act of willful destruction,
such as physically removing disks from a NetApp system, can result in record
deletion before the specified expiration date"

[sstsupportcontracts]

Hi Sergey,

Thanks for the link. To be fair, although I've stated rogue administrator, the case I'm more concerned with is that of an administrator account compromise. In that instance, local access wouldn't be available. This only really came to light when I was reflecting on how long it took to erase all our old backup tapes and I commented to a colleague just how much quicker I could do this with our disk based storage system. If I can do that, so can someone with my level of access; how do I protect us against that I wondered.

Regards,

Mark