使用后擦拭EBS卷？

https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf描述了亚马逊公布的与EBS交易的stream程。 两个引号似乎相关：

Amazon EBS卷将作为原始未格式化块设备呈现给您，这些设备在可用之前已被擦除

但也

EBS快照是整个EBS卷的块级视图。 请注意，通过卷上的文件系统不可见的数据（例如已删除的文件）可能存在于EBS快照中。

最可能的情况是您正在从已删除数据的快照创build卷。

我尝试用新的PIOPS，gp2和磁盘卷来复制我们在east-1的场景，但无法恢复任何数据。

也就是说，通过使用KMSencryption卷，您可以进一步保护您的EBS数据。

从AWS文档

被删除的EBS卷使用的物理块存储在被分配到另一个帐户之前被零覆盖。

来自他们论坛上的AWS代表。

我可以确认，当任何客户的数量被终止（是EBS或实例存储卷），它被完全擦除之前，可供其他客户使用。

如果这是真的，并且您确实拥有其他人的数据，则需要联系AWS。 非常规的索赔需要非常的证据。

TLDR; 我做了两套testing，无法复制@stevelandiss生成的结果。

更新 – testing一个

我自己试了一下 这是我做的和我的结果。

TLDR; 无法复制。

0）我分配了一个m3.medium现货实例，其中gp2和io1（预configurationIOPS）卷，每个10GB。 我使用标准的Ubuntu 16.04 AMI（ami-b7a114d7）。 请注意，我不能像OPbuild议的那样挂载为/ dev / xvdb，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：错误的fstypes，错误的选项，/ dev / xvdba上的错误超级块，缺less代码页或帮助程序或其他错误

   在某些情况下，可以在syslog中find有用的信息 – 试试dmesg | 尾巴左右。

3）我在每个设备上创build文件系统

 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预configurationIOPS

正如你所看到的没有文件被发现。 如果@stevelandiss可以指出他做了什么不同，我可以再次尝试重现。 例如，他没有提到任何安装，他使用了不同的设备名称。 我会再试一次，不用挂几分钟，但我想保存这个更新，所以我不会失去它。

更新 – testing二

这一次我做了很多，但我没有创build一个文件系统或挂载磁盘。 这更接近于@stevelandiss所做的。 这没有什么区别，没有文件被恢复。

GP2

IO1预configurationIOPS

从wipefs手册页：

wipefs不会擦除文件系统本身，也不会擦除设备上的其他数据

我们需要更多关于音量的信息。 你是怎么创造的？ 你100％确定没有人创造它，但你？

AWS不分享他们devise技术的方式，所以我猜测他是NetAppauthentication的存储人员。 EBS卷是build立在RAID组上的抽象层。 我怀疑这将只是一个单一的磁盘。 所以每次你提供一个音量，你会（将）从不同的物理设备获取大块。 这使得你不可能获得完整的文件。

向我们提供更多信息如何configuration音量。 但是我猜你在某个时候犯了一个错误。 否则，这将是一个关于这样一个基本function的AWS上的一个巨大的安全违规。

这里是我做的testing，我创build了一个新的卷，一个新的实例。 将卷附加到实例，然后运行photoRectesting。 我发现如预期的0个文件。

 PhotoRec 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <[email protected]> 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用户？ 也许他们将这个卷附加到他们的实例并使用这种方式。