4 ms·

Also putting the word out via Twitter: https://twitter.com/nixgeek/status/450438984574193665 https://twitter.com/nixgeek/status/450438984574193665 I think awa

by nixgeek 13y ago

Also putting the word out via Twitter: https://twitter.com/nixgeek/status/450438984574193665 https://twitter.com/nixgeek/status/450438984574193665 I think awareness is key with these type of issues, infrastructure providers are very opaque beasts and the underlying platform behaviour varies with each of them. Knowing that you may need to erase sensitive data yourself before initiating the destroy, so that it is not captured in the snapshot, that's probably half the battle.

derefr 13y ago
The snapshot is on object storage. Just delete the snapshot after it's made, and everything will be okay. For DO staff: also add an option (orthogonal to the secure-erase checkbox) to not make a snapshot.
- nixgeek 13y ago
  It's actually impossible to delete the snapshot as a single operation, first you have to 'Restore' it. Oh the irony. The entire motivation behind this submission was to be educational and informative: the fact is you either need to erase sensitive data from within your droplet before initiating the destroy, or take additional actions (including jumping through the 'restore before destroy' hoops) to eliminate the snapshot after the fact. Note also that DigitalOcean said that in most cases the snapshot is just deleted via `rm` and is not overwritten with zeroes or random data, so you're still vulnerable to your instance contents potentially showing up down the road when a hard drive ends up in a dumpster somewhere.
  - deleted 13y ago
    [deleted]
  - derefr 13y ago
    > It's actually impossible to delete the snapshot as a single operation, first you have to 'Restore' it. Oh the irony. Now that's a bug! DO staff, fix this! > so you're still vulnerable to your instance contents potentially showing up down the road when a hard drive ends up in a dumpster somewhere From my experience in the computer refurbishing industry, any US corporation with a legal department has data-disposal-related asset-liquidation procedures. If the company is sensible, this results in giant magnets or DBAN; more often, though, it just results in a concrete warehouse floor and a sledgehammer. Either way, client data isn't getting out of the building. (see the sibling comment at https://news.ycombinator.com/item?id=7499125 https://news.ycombinator.com/item?id=7499125 for more details.) It's true that someone who hacked into DO's live snapshot servers could dump and examine the disks and possibly find your data[1]. But they could, equally easily, hack into DO's live compute servers and dump your keys from your VM's memory. Until we've got homeomorphic machine-emulation software, instance memory, not snapshots, are the weakest link in your security. [1] If the user-provided-snapshot servers are themselves a cluster of DO droplets--running, say, OpenStack Swift--then those instances would certainly get secure-erased. This is probably the way I'd set up the system myself, though I have no idea whether DO does.

by nixgeek 13y ago

derefr 13y ago

The snapshot is on object storage. Just delete the snapshot after it's made, and everything will be okay. For DO staff: also add an option (orthogonal to the secure-erase checkbox) to not make a snapshot.

nixgeek 13y ago
It's actually impossible to delete the snapshot as a single operation, first you have to 'Restore' it. Oh the irony. The entire motivation behind this submission was to be educational and informative: the fact is you either need to erase sensitive data from within your droplet before initiating the destroy, or take additional actions (including jumping through the 'restore before destroy' hoops) to eliminate the snapshot after the fact. Note also that DigitalOcean said that in most cases the snapshot is just deleted via `rm` and is not overwritten with zeroes or random data, so you're still vulnerable to your instance contents potentially showing up down the road when a hard drive ends up in a dumpster somewhere.
- deleted 13y ago
  [deleted]
- derefr 13y ago
  > It's actually impossible to delete the snapshot as a single operation, first you have to 'Restore' it. Oh the irony. Now that's a bug! DO staff, fix this! > so you're still vulnerable to your instance contents potentially showing up down the road when a hard drive ends up in a dumpster somewhere From my experience in the computer refurbishing industry, any US corporation with a legal department has data-disposal-related asset-liquidation procedures. If the company is sensible, this results in giant magnets or DBAN; more often, though, it just results in a concrete warehouse floor and a sledgehammer. Either way, client data isn't getting out of the building. (see the sibling comment at https://news.ycombinator.com/item?id=7499125 https://news.ycombinator.com/item?id=7499125 for more details.) It's true that someone who hacked into DO's live snapshot servers could dump and examine the disks and possibly find your data[1]. But they could, equally easily, hack into DO's live compute servers and dump your keys from your VM's memory. Until we've got homeomorphic machine-emulation software, instance memory, not snapshots, are the weakest link in your security. [1] If the user-provided-snapshot servers are themselves a cluster of DO droplets--running, say, OpenStack Swift--then those instances would certainly get secure-erased. This is probably the way I'd set up the system myself, though I have no idea whether DO does.