2

I have an SLES 12 SP1 system running on AWS. I need to "wipe" the EBS volumes before deprovisioning them as a customer requirement. The data is sensitive in a commercial way only (no TLAs). Is shred an appropriate tool?

I see there are several posts on SO on shred and scrub which are helpful. However, they typically quote a caveat from shred man page that it may not work reliably on journaled finesystems BUT it may work better when applied to the device itself. This is somewhat confusing. I need help figuring out if this will work in my case. I use both standard hard drives and SSD hard drives.

Q1. how to tell if the filesystem is journaled? mount and pvdisplay shows the following. I am tempted to assume it is not journaled (and I am lucky!) but is there a way to explicitly check for it?

/dev/mapper/vgdb-lvdbdata on /db/data type xfs (rw,noatime,nodiratime,attr2,nobarrier,inode64,logbsize=256k,sunit=512,swidth=1536,noquota)

pvdisplay

--- Physical volume ---
PV Name               /dev/xvdf
VG Name               vgdb
PV Size               1.00 TiB / not usable 4.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              262143
Free PE               255
Allocated PE          261888

Q2. is shred inadequate for SSD disks? Elsewhere in SO a method using hdparm is recommended but I don't have enough specifics about what I actually get in an EBS SSD drive.

Q3. what is the idiomatic way of doing this? I was thinking of stopping my EC2 instance; detach volumes; launch a small server; attach the volumes and run the wiper. Is there a simpler way?

--EDIT

Some have replied (here and elsewhere on SO) that AWS wipes the drive before presenting it available to a new user. We all are aware of that assertion and don't doubt it, but one must read that statement carefully since after all we are in risk area. There is some time lag potentially between one user releasing a drive and another acquiring it. Another potential for a time lag is between the drive being marked for destruction and its actual destruction.

I am not paranoid - just want to do a job well if I am going to do it.

Dinesh
  • 179
  • 1
  • 2
  • 9
  • Why bother ? The data is already out of your control, and no doubt Amazon have backups of it and TLA's have their hooks in whatever they want. While shred will work, in practice it won't buy you anything significant over overwriting with zeros (dd if=/dev/zero of=...) and will take a lot longer. Also, snippets of data will likely still exist in the ssd (in bad/re-allocated blocks). The way to solve this problem is to use encryption on the disks before writing data to them - bit late for that now. – davidgo Jul 12 '17 at 10:25
  • @davidgo *"no doubt Amazon have backups of it"* ...not unless the user has made snapshots of the volume. Amazon does not appear to back up EBS volumes independently, but the underlying devices are redundant (mirrored). – Michael - sqlbot Jul 12 '17 at 12:20
  • @davidgo We do use EBS encryption. Plus the database is also encrypted. But my question here is specific and I will appreciate your answer – Dinesh Jul 12 '17 at 15:45

2 Answers2

2

EBS volumes are wiped prior to being allocated

Amazon EBS volumes are presented to you as raw unformatted block devices that have been wiped prior to being made available for use. Wiping occurs immediately before reuse so that you can be assured that the wipe process completed. If you have procedures requiring that all data be wiped via a specific method, such as those detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88 (“Guidelines for Media Sanitization”), you have the ability to do so on Amazon EBS. You should conduct a specialized wipe procedure prior to deleting the volume for compliance with your established requirements.

Additionally, if the data is confidential you should use encrypted EBS volumes. Each volume has a unique key, when you destroy the volume the key is deleted. Even if the data could be accessed it can't be decrypted.

Each AWS account has a unique master key that is stored separately from your data, on a system that is surrounded with strong physical and logical security controls. Each encrypted volume (and its subsequent snapshots) is encrypted with a unique volume encryption key that is then encrypted with a region-specific secure master key. The volume encryption keys are used in memory on the server that hosts your EC2 instance; they are never stored on disk in plaintext.

If you want to be triply sure, yes you can destroy data manually. You can use shred for this.

Tim
  • 594
  • 3
  • 8
  • I looked into shred but got some questions. Can you please share some details around those? – Dinesh Jul 15 '17 at 00:17
  • Given EBS volumes are definitely wiped before reuse, and based on comments from an AWS engineer I read on their forum there's a good chance they're wiped when they're terminated, I wouldn't worry too much about it. I wonder if you'd be best to drop the partition then wipe the raw device somehow. If you can't do that drop the file system, create a new file system that's not journaled and wipe that. Honest, I wouldn't bother with either, I'd just delete the device, snapshots, and call it done. – Tim Jul 15 '17 at 01:37
  • I very much appreciate your inputs but I would probably appreciate hard answers even more... – Dinesh Jul 17 '17 at 21:02
0

I looked at the AWS documentation, and according to Amazon once you have deleted an EBS volume the data is gone and there is no way to attach that volume to any instance so it could be read.

For extra assurance you certainly could delete your customer's data and then overwrite the volume. Or you could replicate what this company is doing, here's a post from SumoLogic on how they wipe their AWS volumes when a customer project is done.

Ina Kahn
  • 31
  • 5
  • that's pretty much what I also ended up doing. AWS's assurance is great but we want to ensure the disk is wiped out prior to us ceding control – Dinesh Dec 10 '17 at 03:30