Secure deletion on physical spindles is extremely resource heavy especially if someone is deleting a very large drive.

Storing encrypted first does affect performance but it is generally much less and more predictable (doing a big secure delete on a drive inflicts an immediate and unexpected hit on that part of a storage array).

We think encryption is also just a lot more robust. If you don't lay down the data in the first place in readable form on the physical drives, its eliminates a lot of data leakage possibilities.

Best wishes,

Patrick

Sorry, but this is really bordering on FUD here.

Have you ever looked at a freshly mounted EBS volume on EC2? It shows all zero's for me. And I'm almost sure that was not just a coincidence for the volumes I looked at.

Moreover there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level.

Our post is regarding IaaS clouds in general and has nothing specifically to do with EC2 or any other particular vendor. It may be the case that EC2 does have secure measures in place; I wonder how many of their customers can articulate them (or customers of other IaaS clouds for that matter)? We are merely raising an important issue. You can look at the many other posts we have on the other various aspects of security in the cloud of which this post forms the latest instalment regarding data storage.

"there are more efficient ways than encryption or "full sweep overwrite" to address this at the storage-level."

Your suggestion would be?

Kind regards,

Patrick

Your suggestion would be?

See my reply above about using a loopback-file.

It's a one-liner:

  dd if=/dev/zero of=/vols/customer123/vol234 seek=$SIZE bs=1 count=1

There's surely quite a few other ways to skin this cat (eventually arriving at the multi-tenancy features in proprietary SAN appliances), but this seems the most obvious one.

Vukk,

The issue there is more about tracking. You'd have to track every single block and return zero for any that hadn't been used/altered since drive creation. I'm guessing it would prove pretty costly in terms of latency for drive access after initial drive creation but its a good idea potentially. I'll pass it onto our technical guys as well to ask about its feasibility.

Best wishes,

Patrick

Since we are not directly accessing the HDD, couldn't the virtualization layer say if(disk block not written before) return 0; and thus the customer wouldn't have to worry? Or is this too inefficient?