☰

EBS 卷在使用后会被擦除吗？

tag-icon • tag-icon linux amazon-web-services filesystems amazon-ebs
EBS 卷在使用后会被擦除吗？

我尝试从我意外运行的 ebs 卷中恢复一些数据wipefs。

我使用了 PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec）...它不仅恢复了我的文件，而且还恢复了一大堆不属于我的其他文件。

它有图像、文本文件、代码等...它们都是有效数据，不是来自我的帐户。

这让我想问...当我删除 EBS 卷时，我猜我的数据可以被别人清楚使用吗？

答案1

https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf描述了 Amazon 发布的 EBS 处理流程。以下两段引言似乎很有意义：

Amazon EBS 卷以原始未格式化的块设备的形式呈现给您，这些设备已在可用之前被清除

但是也

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

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

我尝试使用新的 PIOPS、gp2 和磁性卷在 us-east-1 中重现您的场景，但无法恢复任何数据。

也就是说，您可以利用 KMS 加密卷进一步保护您的 EBS 数据。

答案2

来自AWS 文档

已删除的 EBS 卷所使用的物理块存储在分配给另一个账户之前将被零覆盖。

来自 AWS 代表他们的论坛。

我可以确认，当任何客户卷（无论是 EBS 还是实例存储卷）终止时，它会被彻底清除，然后才能供其他客户使用。

如果这是真的，而且你确实拥有其他人的数据，那么你需要联系 AWS。非凡的主张需要非凡的证据。

TLDR；我做了两组测试，无法重现@stevelandiss 产生的结果。

更新-测试一

我自己尝试过。以下是我所做的和结果。

TLDR；无法重现。

0) 我分配了一个 m3.medium 现货实例，带有 gp2 和 io1（预配置 IOPS）卷，每个 10GB。我使用了标准 Ubuntu 16.04 AMI（ami-b7a114d7）。请注意，我无法按照 OP 建议的那样挂载为 /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

  1. 我尝试安装磁盘只是为了检查，但它们当然没有文件系统，所以失败了

    mount /dev/xvdba /gp2/ mount: 错误的 fs 类型、错误的选项、/dev/xvdba 上的错误超级块、缺少代码页或辅助程序，或者其他错误

    在某些情况下，可以在 syslog 中找到有用的信息 - 尝试 dmesg | tail 等。

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

Photorec 在新的 AWS GP2 卷上的结果

IO1 预置 IOPS

Photorec 在新 AWS IO1volume 上的结果

如您所见，未找到任何文件。如果@stevelandiss 可以指出他做的不同之处，我可以再次尝试重现。例如，他没有提到任何安装，并且使用了不同的设备名称。我会在几分钟内再次尝试而不安装，但我想保存此更新，以免丢失它。

更新-第二次测试

这次我做了类似的事情，但我没有创建文件系统或安装磁盘。这更接近@stevelandiss 所做的。这没什么区别，没有恢复任何文件。

GP2

新 AWS 卷上的 GP2 Photorec

IO1 预置 IOPS

IO1 Photorec 在新的 AWS 卷上

答案3

来自擦拭手册页：

wipefs 不会删除文件系统本身或设备上的任何其他数据

答案4

我们需要有关该卷的更多信息。您是如何创建它的？您是否 100% 确定除了您之外没有其他人创建了它？

AWS 没有分享他们是如何设计这项技术的，所以我猜测，作为一名 NetApp 认证的存储专家。EBS 卷是建立在 RAID 组上的抽象层。我怀疑它只是一个磁盘。因此，每次配置卷时，您都会从不同的物理设备获取数据块。这使得您不太可能获得完整的文件。

请向我们提供您如何配置卷的更多信息。但我猜您在某个时候犯了一个错误。否则，对于如此基本的功能，这将是 AWS 的重大安全违规行为。

这是我做的测试，我创建了一个新卷，一个新实例。将卷附加到实例，然后运行 ​​photoRec 测试。我找到了 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 用户吗？也许他们将该卷附加到他们的实例并以这种方式使用。

相关内容