стираются ли тома EBS после использования?

Из Документация AWS

Физическое блочное хранилище, используемое удаленными томами EBS, перезаписывается нулями перед выделением другой учетной записи.

От представителя AWS их форумы.

Я могу подтвердить, что при закрытии любого клиентского тома (будь то EBS или объем хранилища экземпляров) он полностью очищается, прежде чем станет доступным для использования другими клиентами.

Если это правда и у вас действительно есть чужие данные, вам необходимо связаться с AWS. Чрезвычайные заявления требуют чрезвычайных доказательств.

TL; DR; Я провел два набора тестов и не смог воспроизвести результаты, полученные @stevelandiss.

Обновление - тестовое

Я сам это пробовал. Вот что я сделал и мои результаты.

TL; DR; не мог воспроизвести.

0) Я выделил спотовый экземпляр m3.medium с томами gp2 и io1 (подготовленные IOPS), по 10 ГБ каждый. Я использовал стандартный Ubuntu 16.04 AMI (ami-b7a114d7). Обратите внимание, что я не мог смонтировать как / dev / xvdb, как предлагал OP, AWS заставил меня использовать более длинные имена, такие как / dev / xvdba, что вызывает у меня немного подозрений.

1) Установил photorec / testdisk

apt-get install testdisk

2) Я использовал lsblk, чтобы посмотреть доступные тома

lsblk
NAME    MAJ:MIN   RM SIZE RO TYPE MOUNTPOINT
xvda    202:0      0   8G  0 disk
└─xvda1 202:1      0   8G  0 part /
xvdba   202:13312  0  10G  0 disk
xvdbb   202:13568  0  10G  0 disk
xvdca   202:19968  0   4G  0 disk

3. Я пытался смонтировать диски, чтобы проверить, но, конечно, у них нет файловой системы, поэтому это не удалось

   mount / dev / xvdba / gp2 / mount: неправильный тип файловой системы, неправильная опция, неправильный суперблок на / dev / xvdba, отсутствие кодовой страницы или вспомогательной программы или другая ошибка

   В некоторых случаях полезная информация может быть найдена в системном журнале - попробуйте dmesg | хвост или около того.

3) Я сделал файловые системы на каждом устройстве

mkfs -t ext4 /dev/xvdba
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: e32b2ed1-a0f8-49df-895d-c56b9802a009
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

root@ip-11-0-2-184:/home/ubuntu# mkfs -t ext4 /dev/xvdbb
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: 4f1f7c75-bbce-4887-aac7-02e197a36c89
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

4) Смонтировал диски

mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/

5) Я запускал photorec на каждом томе

photorec /dev/xvdba

GP2

IO1, выделенный IOPS

Как видите, файлов не найдено. Если @stevelandiss может указать на то, что он сделал иначе, я могу снова попытаться воспроизвести. Например, он не упомянул о какой-либо установке и использовал другое имя устройства. Я попробую еще раз, не монтируя несколько минут, но я хочу сохранить это обновление, чтобы не потерять его.

Обновление - тест два

На этот раз я сделал то же самое, но не создавал файловую систему и не монтировал диск. Это ближе к тому, что сделала @stevelandiss. Это не имело значения, файлы не восстанавливались.

GP2

IO1 подготовлено IOPS

из wipefs страницы руководства:

wipefs не стирает саму файловую систему или любые другие данные с устройства.

нам нужна дополнительная информация об объеме. Как ты его создал? Вы на 100% уверены, что его никто не создал, кроме вас?

AWS не сообщает, как они разработали эту технологию, поэтому я предполагаю, что являюсь сертифицированным специалистом по хранению данных NetApp. Тома EBS - это уровни абстракции, построенные на группах RAID. Я сомневаюсь, что это будет только один-единственный диск. Таким образом, каждый раз, когда вы предоставляете том, вы будете получать блоки с разных физических устройств. Поэтому получение полных файлов маловероятно.

Сообщите нам больше информации о том, как вы подготовили том. Но я предполагаю, что в какой-то момент вы совершаете ошибку. В противном случае это было бы серьезным нарушением безопасности AWS в отношении такой базовой функции.

вот тест, который я сделал, я создаю новый том, новый экземпляр. прикрепил том к экземпляру, а затем запустил тест photoRec. я нашел 0 файлов, как и ожидалось.

PhotoRec 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/xvdf - 1073 MB / 1024 MiB (RO)
 Partition                  Start        End    Size in sectors
P Unknown                  0   0  1   130 138  8    2097152


0 files saved in /home/ec2-user/testdisk-7.0/recup_dir directory.
Recovery completed.

есть ли у вас в аккаунте другие пользователи IAM? возможно, они прикрепили этот том к своим экземплярам и использовали его таким образом.

https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf описывает опубликованный Amazon процесс работы с EBS. Уместны две цитаты:

Тома Amazon EBS представляются вам как сырые неформатированные блочные устройства, которые были стерто до того, как стать доступным

но также

Моментальный снимок EBS - это представление всего тома EBS на уровне блоков. Обратите внимание, что данные, которые не видны через файловую систему на томе, например, файлы, которые были удалены, могут присутствовать в моментальном снимке EBS.

Наиболее вероятный случай - вы создаете свой том из моментального снимка, который удалил данные на нем.

Я попытался воспроизвести ваш сценарий в us-east-1 с новыми томами PIOPS, gp2 и магнитными томами, но не смог восстановить никаких данных.

Тем не менее, вы можете дополнительно защитить свои данные EBS, используя зашифрованные тома KMS.