Werden EBS-Volumes nach Gebrauch gelöscht?

Ich habe versucht, einige Daten von einem ebs-Volume wiederherzustellen, auf dem ich versehentlich ausgeführt habe wipefs.

Ich habe PhotoRec ( http://www.cgsecurity.org/wiki/PhotoRec ) verwendet ... und es hat meine Dateien zurückbekommen, aber auch eine Menge anderer Dateien, die mir nicht gehörten.

Es hat Bilder, Textdateien, Code usw. ... Alle waren gültige Daten, nicht von meinem Konto.

Das hat mich zu der Frage geführt ... Wenn ich ein EBS-Volume lösche, können meine Daten eindeutig von jemand anderem verwendet werden?

https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf beschreibt den von Amazon veröffentlichten Prozess für den Umgang mit EBS. Zwei Zitate scheinen relevant zu sein:

Amazon EBS-Volumes werden Ihnen als unformatierte Blockgeräte angezeigt, die vor der Bereitstellung gelöscht wurden

aber auch

Ein EBS-Snapshot ist eine Blockansicht eines gesamten EBS-Volumes. Beachten Sie, dass Daten, die im Dateisystem auf dem Volume nicht sichtbar sind, z. B. gelöschte Dateien, möglicherweise im EBS-Snapshot vorhanden sind.

Der wahrscheinlichste Fall ist, dass Sie Ihr Volume aus einem Snapshot erstellen, auf dem Daten gelöscht wurden.

Ich habe versucht, Ihr Szenario in us-east-1 mit neuen PIOPS-, gp2- und Magnetvolumina zu reproduzieren, und konnte keine Daten wiederherstellen.

Sie können Ihre EBS-Daten jedoch weiter schützen, indem Sie KMS-verschlüsselte Volumes verwenden.

Aus der AWS-Dokumentation

Der von gelöschten EBS-Volumes verwendete physische Blockspeicher wird mit Nullen überschrieben, bevor er einem anderen Konto zugewiesen wird.

Von einem AWS-Mitarbeiter in den Foren .

Ich kann bestätigen, dass ein Kundenvolumen, das beendet wird (sei es EBS oder ein Instanzspeichervolumen), vollständig gelöscht wird, bevor es anderen Kunden zur Verwendung zur Verfügung gestellt wird.

Wenn dies echt ist und Sie wirklich die Daten eines anderen haben, müssen Sie sich mit AWS in Verbindung setzen. Außerordentliche Ansprüche erfordern außerordentliche Nachweise.

TLDR; Ich habe zwei Tests durchgeführt und konnte die von @stevelandiss erzielten Ergebnisse nicht reproduzieren.

Update - teste eins

Ich habe das selbst ausprobiert. Hier ist was ich getan habe und meine Ergebnisse.

TLDR; konnte nicht reproduzieren.

0) Ich habe eine m3.medium-Spot-Instanz mit gp2- und io1-Volumes (bereitgestelltes IOPS) mit jeweils 10 GB zugewiesen. Ich habe das Standard-Ubuntu 16.04 AMI (ami-b7a114d7) verwendet. Beachten Sie, dass ich nicht wie vom OP vorgeschlagen als / dev / xvdb mounten konnte. AWS hat mich gezwungen, längere Namen wie / dev / xvdba zu verwenden, was mich etwas misstrauisch macht.

1) Ich habe photorec / testdisk installiert

apt-get install testdisk

2) Ich habe lsblk verwendet, um die verfügbaren Volumes zu überprüfen

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. Ich habe versucht, die Datenträger nur zur Überprüfung bereitzustellen, aber natürlich haben sie kein Dateisystem, so dass es fehlgeschlagen ist

   mount / dev / xvdba / gp2 / mount: falscher fs-Typ, schlechte Option, schlechter Superblock auf / dev / xvdba, fehlende Codepage oder Hilfsprogramm oder anderer Fehler

   In einigen Fällen finden Sie nützliche Informationen in syslog - versuchen Sie es mit dmesg | Schwanz oder so.

3) Ich habe auf jedem Gerät Dateisysteme erstellt

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) Ich habe die Festplatten montiert

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

5) Ich habe auf jedem Volume Photorec ausgeführt

photorec /dev/xvdba

GP2

IO1 bereitgestellte IOPS

Wie Sie sehen, wurden keine Dateien gefunden. Wenn @stevelandiss darauf hinweisen kann, was er anders gemacht hat, kann ich erneut versuchen, es zu reproduzieren. Zum Beispiel erwähnte er keine Montage und verwendete einen anderen Gerätenamen. Ich werde es erneut versuchen, ohne ein paar Minuten zu mounten, aber ich möchte dieses Update speichern, damit ich es nicht verliere.

Update - Test zwei

Diesmal habe ich das Gleiche getan, aber kein Dateisystem erstellt oder die Festplatte gemountet. Dies ist näher an dem, was @stevelandiss getan hat. Dies machte keinen Unterschied, es wurden keine Dateien wiederhergestellt.

GP2

IO1 bereitgestellte IOPS

von den wipefs- Manpages:

wipefs löscht weder das Dateisystem selbst noch andere Daten vom Gerät

Wir brauchen mehr Informationen über das Volumen. Wie hast du es geschaffen? Sind Sie zu 100% sicher, dass niemand außer Ihnen es erstellt hat?

AWS teilt nicht mit, wie sie die Technologie entworfen haben, daher schätze ich, dass sie ein NetApp-zertifizierter Speicher-Typ sind. EBS-Volumes sind Abstraktionsschichten, die auf RAID-Gruppen basieren. Ich bezweifle, dass es nur eine einzige Festplatte sein wird. Jedes Mal, wenn Sie ein Volume bereitstellen, erhalten (würden) Sie Chuncks von verschiedenen physischen Geräten. Das macht es sehr unwahrscheinlich, dass Sie vollständige Dateien erhalten.

Geben Sie uns weitere Informationen darüber, wie Sie das Volume bereitgestellt haben. Aber ich vermute, Sie machen irgendwann einen Fehler. Andernfalls wäre dies eine große Sicherheitsverletzung in AWS in Bezug auf eine solche Grundfunktion.

Hier ist der Test, den ich gemacht habe. Ich erstelle ein neues Volume, eine neue Instanz. Hängte das Volume an die Instanz an und führte dann den photoRec-Test aus. Ich fand 0 Dateien wie erwartet.

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.

Haben Sie andere IAM-Benutzer in Ihrem Konto? Vielleicht haben sie dieses Volume an ihre Instanzen angehängt und auf diese Weise verwendet.