Den tors 8 juni 2023 kl 09:43 skrev Marc <Marc@xxxxxxxxxxxxxxxxx>: > > I bumped into an very interesting challenge, how to secure erase a rbd > > image data without any encryption? As Darren replied while I was typing this, you can't have dangerous data written all over a cluster which automatically moves data around, and after-the-fact prove that no bits ever can be found anywhere. That said, you need to figure out exactly which kind of "opponent" you are protecting from. If the opponent is an auditor with lots of fantasies and less technical knowledge, they will be able to imagine "even if you overwrite 1-2-3-10 times, there are side channels on the disk tracks on which $imaginary_enemy can read by moving the head slightly to the side and find old data". If you pay insane amounts to disk rescue companies, they will still not succeed with this, but auditors seldom care about that. Or you overwrite 5 times and they will say "it must be 10 times", because failing you means more money for them, more consultant hours and all that. Now, if you mount the image after stopping the previous RBD image user, and overwrite it one or ten times over with zeroes or patterns or /dev/urandom contents, you will end up in a situation where me, you and probably everyone else on this list could not get consistent data back EVEN if someone threatened our families and loved ones with pain and suffering. Especially not if we must make the attempt via the APIs and qemu/openstack layers and try to get someone elses old data back this way instead of stealing drives from data centers. For many situations, this probably is as good as it gets unless you destroy all OSD drives to molten metal. For everything in between "I could not save my kids" and "this is what the auditor is finally ok with", there is just a huge amount of "work" and probably zero actual gains to be had. Auditors love for you to document the amount of work you did, all the time and money spent on the effort, but the actual end effect you get from all of it is just lots of paperwork and almost no extra digital security. If we get customers who want to make sure no one can read their data when they destroy a box, we always suggest they make an image/OS-install with local drive encryption, then before deleting the instance, re-set the key to something random that neither they nor we know, and then remove the instance and have the system delete the encrypted data whenever it suits. This means someone needs to type in a password or passphrase at each boot to unlock, but that is the price one has to pay in order to protect against someone dumpster-diving old OSD drives, or evil ceph admins that don't really delete the image but moves it away or something along those lines. -- May the most significant bit of your life be positive. _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |