patternMinor
Is it possible to securely delete a file from a virtual disk in a cloud provider?
Viewed 0 times
fileproviderdeletediskvirtualcloudpossiblefromsecurely
Problem
Considering that virtual hard drives are generally formatted using something like
Is it possible to use something like
ext3 that abstracts away from the underlying block device, which in and of itself is an abstraction over the top of a physical and network topology.Is it possible to use something like
wipe or shred against a single file or an entire device to mitigate the risk of data being recovered at a later date if that machine was compromised?Solution
You can't really use those tools with ext3 anyway. Wipe manpage has a large note about it:
No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system.
Moreover, the fact the data will be written really in-place is not guaranteed and you may be writing aside the original data.
That said the reason to do this goes back to a point where a data was written on disk on consecutive sectors on the same physical medium, usual storage nowadays use striping technology to spread data on multiple physical medium, each write in the system toward this storage will have an impact on all the stripes this file was part of. Each provider will have its own custom storage backend, but I'm pretty confident the same principles are used.
When you get the picture even higher, you're writing a file on a virtual hard disk which is itself a file on a storage pool, probably streched on multiple lun composed of raid array of physical disks.
There's so many IOs running on all those strates of striping/aggregation that the probability someone could recover a file by magnetic reading of physical disks (what wipe and shred should protect against) is very very very low as the storage used for this file has probably been reused a bunch of time already.
Even on existing ext3/ext4 filesytem, tools like extundelete have a hard time recovering any file if the disk is not unmounted/mounted read only very quickly after the deletion.
No secure deletion program that does filesystem-level calls can sanitize files on such filesystems, because sensitive data and metadata can be written to the journal, which cannot be readily accessed. Per-file secure deletion is better implemented in the operating system.
Moreover, the fact the data will be written really in-place is not guaranteed and you may be writing aside the original data.
That said the reason to do this goes back to a point where a data was written on disk on consecutive sectors on the same physical medium, usual storage nowadays use striping technology to spread data on multiple physical medium, each write in the system toward this storage will have an impact on all the stripes this file was part of. Each provider will have its own custom storage backend, but I'm pretty confident the same principles are used.
When you get the picture even higher, you're writing a file on a virtual hard disk which is itself a file on a storage pool, probably streched on multiple lun composed of raid array of physical disks.
There's so many IOs running on all those strates of striping/aggregation that the probability someone could recover a file by magnetic reading of physical disks (what wipe and shred should protect against) is very very very low as the storage used for this file has probably been reused a bunch of time already.
Even on existing ext3/ext4 filesytem, tools like extundelete have a hard time recovering any file if the disk is not unmounted/mounted read only very quickly after the deletion.
Context
StackExchange DevOps Q#3165, answer score: 2
Revisions (0)
No revisions yet.