How to secure erasing a rbd image without encryption?
Dear ceph folks, I bumped into an very interesting challenge, how to secure erase a rbd image data without any encryption? The motivation is to ensure that there is no information leak on OSDs after deleting a user specified rbd image, without the extra burden of using rbd encryption. any ideas, suggestions are highly appreciated, Samuel huxiaoyu@horebdata.cn
I bumped into an very interesting challenge, how to secure erase a rbd image data without any encryption?
The motivation is to ensure that there is no information leak on OSDs after deleting a user specified rbd image, without the extra burden of using rbd encryption.
any ideas, suggestions are highly appreciated,
what about something this? Maybe even via qemu-agent-command? find /home -type f -exec shred -n 1 {} \; Why are you not encrypting the osd? I thought that was the most efficient way of using encryption.
Den tors 8 juni 2023 kl 09:43 skrev Marc <Marc@f1-outsourcing.eu>:
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.
Unfortunately this is impossible to achieve. Unless you can guarantee that the same physical pieces of disk are going to always be mapped to the same parts of the RBD device then you will leave data lying around on the array. How easy it is to recover is a bit of a question about how valuable the data is to someone. Ceph moves data around at the backend which means there could be old blocks left on OSD’s that contain the user data. There is no guarantee as to how long those pieces of data will be around for. If your RBD device is on SSD/NVME then you cannot get to all the blocks that contain your data unless you use the manufacturer supplied utilities to erase the device completely. This problem is overcome with encrypted OSD’s but it doesn’t help your end user RBD device that needs to be deleted. If the RBD devices had snapshots of it then there is even more copies of the data within the array which you cannot directly access. Any array that moves data around without the client knowing about it and being able to map to all the blocks used means there are old parts of the image that where presented to the client that have the original data that can still be recovered. Things like a re-balance or an OSD server failure mean that some of the original data is on blocks that are no longer available. The only way to guarantee that your data is secure and no-one can read it is to control the actual code that does the encryption and to keep control of the encryption keys. Ie you do something on the client before you send it to the array. This is not a unique to Ceph problem but an issue for all arrays. Darren Soothill Looking for help with your Ceph cluster? Contact us at https://croit.io/ croit GmbH, Freseniusstr. 31h, 81247 Munich CEO: Martin Verges - VAT-ID: DE310638492 Com. register: Amtsgericht Munich HRB 231263 Web: https://croit.io/ | YouTube: https://goo.gl/PGE1Bx
On 8 Jun 2023, at 06:14, huxiaoyu@horebdata.cn wrote:
Dear ceph folks,
I bumped into an very interesting challenge, how to secure erase a rbd image data without any encryption?
The motivation is to ensure that there is no information leak on OSDs after deleting a user specified rbd image, without the extra burden of using rbd encryption.
any ideas, suggestions are highly appreciated,
Samuel
huxiaoyu@horebdata.cn _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
participants (4)
-
darren＠soothill.com
-
huxiaoyu＠horebdata.cn
-
Janne Johansson
-
Marc