À partir de la documentation AWS
Le stockage de bloc physique utilisé par les volumes EBS supprimés est remplacé par des zéros avant d'être alloué à un autre compte.
D'un représentant AWS sur leurs forums.
Je peux confirmer que lorsqu'un volume client est résilié (qu'il s'agisse d'EBS ou d'un volume de stockage d'instance), il est complètement effacé avant d'être mis à la disposition d'autres clients.
Si cela est authentique et que vous avez vraiment les données de quelqu'un d'autre, vous devez entrer en contact avec AWS. Les réclamations extraordinaires nécessitent des preuves extraordinaires.
TLDR ; J'ai fait deux séries de tests et je n'ai pas pu reproduire les résultats produits par @stevelandiss.
Mise à jour - testez-en une
J'ai essayé moi-même. Voici ce que j'ai fait et mes résultats.
TLDR ; n'a pas pu se reproduire.
0) J'ai alloué une instance ponctuelle m3.medium, avec des volumes gp2 et io1 (IOPS provisionnés), de 10 Go chacun. J'ai utilisé l'AMI standard d'Ubuntu 16.04 (ami-b7a114d7). Notez que je ne pouvais pas monter en tant que /dev/xvdb comme l'OP le suggérait, AWS m'a forcé à utiliser des noms plus longs comme /dev/xvdba, ce qui me rend légèrement suspect.
1) J'ai installé photorec/testdisk
apt-get install testdisk
2) J'ai utilisé lsblk pour voir les volumes disponibles
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
-
J'ai essayé de monter les disques juste pour vérifier, mais bien sûr ils n'ont pas de système de fichiers donc ça a échoué
mount /dev/xvdba /gp2/mount :mauvais type de fs, mauvaise option, mauvais superbloc sur /dev/xvdba, page de code ou programme d'assistance manquant, ou autre erreur
Dans certains cas, des informations utiles se trouvent dans syslog - trydmesg | queue ou plus.
3) J'ai créé des systèmes de fichiers sur chaque appareil
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
[email protected]:/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) J'ai monté les disques
mount /dev/xvdba /gp2/
mount /dev/xvdbb /pio/
5) J'ai exécuté photorec sur chaque volume
photorec /dev/xvdba
GP2
IOPS provisionnées par IO1
Comme vous pouvez le voir, aucun fichier n'a été trouvé. Si @stevelandiss peut souligner ce qu'il a fait différemment, je peux réessayer de reproduire. Par exemple, il n'a mentionné aucun montage et il a utilisé un nom d'appareil différent. Je vais réessayer sans monter quelques minutes, mais je veux enregistrer cette mise à jour pour ne pas la perdre.
Mise à jour - test 2
Cette fois, j'ai fait à peu près la même chose, mais je n'ai pas créé de système de fichiers ni monté le disque. C'est plus proche de ce que @stevelandiss a fait. Cela n'a fait aucune différence, aucun fichier n'a été récupéré.
GP2
IOPS provisionnées par IO1
à partir des pages de manuel de wipefs :
wipefs n'efface pas le système de fichiers lui-même ni aucune autre donnée de l'appareil
nous avons besoin de plus d'informations sur le volume. Comment l'avez-vous créé ? Êtes-vous sûr à 100 % que personne d'autre que vous ne l'a créé ?
AWS ne partage pas la façon dont ils ont conçu la technologie, donc je suppose en tant que spécialiste du stockage certifié NetApp. Les volumes EBS sont des couches d'abstraction, construites sur des groupes RAID. Je doute qu'il s'agisse d'un seul disque. Ainsi, chaque fois que vous provisionnerez un volume, vous obtiendrez (obtiendrez) des morceaux de différents appareils physiques. Il est donc très peu probable que vous obteniez des fichiers complets.
Donnez-nous plus d'informations sur la manière dont vous avez provisionné le volume. Mais je suppose que vous faites une erreur à un moment donné. Sinon, ce serait une énorme violation de la sécurité sur AWS à propos d'une fonctionnalité aussi basique.
voici le test que j'ai fait, je crée un nouveau volume, une nouvelle instance. attaché le volume à l'instance, puis a exécuté le test photoRec. j'ai trouvé 0 fichiers comme prévu.
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.
avez-vous d'autres utilisateurs IAM dans votre compte ? peut-être ont-ils attaché ce volume à leurs instances et l'ont utilisé de cette façon.