Answers: <p>You can't really use those tools with ext3 anyway. Wipe manpage has a large note about it:</p>
  
  <blockquote>
    <p>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. </p>
  </blockquote>
  
  <p>Moreover, the fact the data will be written really in-place is not guaranteed and you may be writing aside the original data.  </p>
  
  <p>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.</p>
  
  <p>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.<br>
  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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-24T07:43:05.357Z
Answers: Thanks, @Tensibai - this is further mitigated by cloud service providers applying encryption of customer data at the Azure Blob/S3 and by applying BitLocker on Windows and DM-Crypt on Linux to encrypt volumes.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2018-01-24T08:31:30.153Z
Answers: @RichardSlater I didn't go this way as its another step for securing files, your question sounded more about standard usage and risk of 'undelete' on another instance getting part of the space one of your instance have freed when terminating. Considering AWS, EBD, EFS and S3 are not using the same storage methods from what I can guess so your mileage may vary depending on what you use as instance backend. I kept generic on the actual risk on virtualized environment
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2018-01-23T16:22:21.523Z
Answers: 2018-01-23T16:22:21.523Z
Answers: Tensibai
Body: <p>Considering that virtual hard drives are generally formatted using something like <code>ext3</code> 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.</p>
  
  <p>Is it possible to use something like <a href="https://linux.die.net/man/1/wipe" rel="nofollow noreferrer"><code>wipe</code></a> or <a href="https://linux.die.net/man/1/shred" rel="nofollow noreferrer"><code>shred</code></a> 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?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-23T15:18:45.603Z
Comments: I don't think this question is something anyone will be able to answer. I would assume each cloud provider has a different methodology for storing/abstracting files and the deletion of them would differ greatly. The process by which your machine is replicated is also abstracted by cloud providers. Who is to say that they appropriately purge the data on the devices that my previous file/drive was running on?
Comments: Preston Martin
Comments: CC BY-SA 3.0
Comments: 2018-01-24T07:39:54.557Z
Comments: I think you've got to assume that the cloud provider takes responsibility for protecting and purging of data, by signing a contract to deliver services you are effectively transferring that risk to the cloud service provider.  I only mentioned it for context rather than expecting anyone to have found an undocumented `/delete?mode=wipe` endpoint somewhere in S3.
Comments: Richard Slater
Tags: <linux><security><cloud>
Title: Is it possible to securely delete a file from a virtual disk in a cloud provider?
UserDisplayName: Richard Slater
ThreadText: # Is it possible to securely delete a file from a virtual disk in a cloud provider?
  
  (Asked by: username_0 on 2018-01-23)
  
  Considering that virtual hard drives are generally formatted using 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`](https://linux.die.net/man/1/wipe) or [`shred`](https://linux.die.net/man/1/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?
  
  **Tags:** linux, security, cloud
  
  > **Comments:**
  > **username_1**: I don't think this question is something anyone will be able to answer. I would assume each cloud provider has a different methodology for storing/abstracting files and the deletion of them would differ greatly. The process by which your machine is replicated is also abstracted by cloud providers. Who is to say that they appropriately purge the data on the devices that my previous file/drive was running on?  
  > **username_0**: I think you've got to assume that the cloud provider takes responsibility for protecting and purging of data, by signing a contract to deliver services you are effectively transferring that risk to the cloud service provider.  I only mentioned it for context rather than expecting anyone to have found an undocumented `/delete?mode=wipe` endpoint somewhere in S3.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-01-23. Score: 2
  
  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.
  
  > **Comments:**
  > **username_0**: Thanks, @username_2 - this is further mitigated by cloud service providers applying encryption of customer data at the Azure Blob/S3 and by applying BitLocker on Windows and DM-Crypt on Linux to encrypt volumes.  
  > **username_2**: @username_0 I didn't go this way as its another step for securing files, your question sounded more about standard usage and risk of 'undelete' on another instance getting part of the space one of your instance have freed when terminating. Considering AWS, EBD, EFS and S3 are not using the same storage methods from what I can guess so your mileage may vary depending on what you use as instance backend. I kept generic on the actual risk on virtualized environment  
  
  ---
  
  