os volumes do EBS são apagados após o uso?

Question

Eu tentei recuperar alguns dados de um volume de ebs no qual acidentalmente corri wipefs .

Eu usei o PhotoRec ( link ) ... e ele recuperou meus arquivos, mas também muitos outros arquivos que não me pertenceu.

Ele tem imagens, arquivos de texto, código, etc. Todos eles são dados válidos, não da minha conta.

Isso me leva a perguntar ... quando eu deletar um volume do EBS, acho que meus dados estão disponíveis para uso por outra pessoa?

    

Answer 1

O

link descreve o processo publicado da Amazon para negociação com EBS. Duas citações parecem relevantes:

Amazon EBS volumes are presented to you as raw unformatted block devices that have been wiped prior to being made available

mas também

An EBS snapshot is a block-level view of an entire EBS volume. Note that data that is not visible through the file system on the volume, such as files that have been deleted, may be present in the EBS snapshot.

O caso mais provável é que você esteja criando seu volume a partir de um instantâneo que excluiu dados nele.

Tentei reproduzir seu cenário no us-east-1 com novos volumes PIOPS, gp2 e magnéticos e não recuperei nenhum dado.

Dito isso, você pode proteger ainda mais os dados do EBS usando volumes criptografados pelo KMS.

    

Answer 2

Na documentação da AWS

The physical block storage used by deleted EBS volumes is overwritten with zeroes before it is allocated to another account.

De um representante da AWS em seus fóruns .

I can confirm that when any customer volume is terminated (be it EBS or an instance storage volume) it is completely wiped before being made available for use by other customers.

Se isso for genuíno e você realmente tiver os dados de outra pessoa, será necessário entrar em contato com a AWS. Reivindicações extraordinárias exigem evidências extraordinárias.

TLDR; Eu fiz dois conjuntos de testes e não consegui reproduzir os resultados que @evevelandiss produziu.

Atualizar - testar um

Eu mesmo tentei isso. Aqui está o que eu fiz e meus resultados.

TLDR; não foi possível reproduzir.

0) Aloquei uma instância spot m3.medium, com volumes gp2 e io1 (IOPS provisionados), 10 GB cada. Eu usei o padrão Ubuntu 16.04 AMI (ami-b7a114d7). Note que eu não consegui montar como / dev / xvdb como o OP sugeriu, o AWS me forçou a usar nomes mais longos como / dev / xvdba o que me deixa um pouco desconfiada.

1) Eu instalei o photorec / testdisk

apt-get install testdisk

2) Eu usei o lsblk para ver os volumes disponíveis

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. Eu tentei montar os discos apenas para verificar, mas é claro que eles não têm sistema de arquivos, então ele falhou

   monte / dev / xvdba / gp2 / mount: errado tipo fs, má opção, bad superblock em / dev / xvdba,    falta de página de código ou programa auxiliar ou outro erro

   Em alguns casos, informações úteis são encontradas no syslog - tente    dmesg | cauda ou mais.

3) Eu fiz sistemas de arquivos em cada dispositivo

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) montei os discos

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

5) Eu corri photorec em cada volume

photorec /dev/xvdba

GP2

IO1provisionouIOPS

Comovocêpodever,nenhumarquivofoiencontrado.Se@stevelandisspodeapontaroqueelefezdiferente,eupossotentarreproduzirnovamente.Porexemplo,elenãomencionounenhumamontagemeusouumnomededispositivodiferente.Tentareinovamentesemmontaralgunsminutos,masquerosalvaressaatualizaçãoparanãoperdê-la.

Atualização-testedois

Destavezeufizomesmo,masnãocrieiumsistemadearquivosnemmonteiodisco.Issoestá[email protected]ãofezdiferença,nenhumarquivofoirecuperado.

GP2

IO1provisionouIOPS

    

Answer 3

das páginas de manual do wipefs :

wipefs does not erase the filesystem itself nor any other data from the device

    

Answer 4

precisamos de mais informações sobre o volume. Como você criou isso? Você tem 100% de certeza de que mais ninguém criou, mas você?

A AWS não compartilha como eles projetaram a tecnologia, por isso acredito que seja uma pessoa de armazenamento certificada pela NetApp. Os volumes do EBS são camadas de abstração, criadas em grupos de RAID. Eu duvido que seja apenas um único disco. Portanto, toda vez que você provisionar um volume, você estará recebendo chunks de diferentes dispositivos físicos. Isso torna muito improvável que você obtenha arquivos completos.

Dê-nos mais informações sobre como você provisionou o volume. Mas eu estou supondo que você está cometendo um erro em algum momento. Ou então isso seria uma enorme violação de segurança na AWS sobre esse recurso básico.

aqui está o teste que eu fiz, eu crio um novo volume, uma nova instância. anexou o volume à instância e, em seguida, executou o teste photoRec. Eu encontrei 0 arquivos como esperado.

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.

você tem outros usuários do IAM em sua conta? talvez eles tenham anexado esse volume às suas instâncias e usado dessa maneira.