EBSボリュームは使用後にワイプされますか？
誤ってwipefsを実行したebsボリュームからデータを復元しようとしました。
私はPhotoRec（ http://www.cgsecurity.org/wiki/PhotoRec ）...を使用しましたが、ファイルは元に戻りましたが、自分のものではない他のファイルも大量に返ってきました。
画像、テキストファイル、コードなどを取得しました。それらはすべて、私のアカウントからではなく、有効なデータでした。
それで私は尋ねるようになりました... EBSボリュームを削除すると、私のデータは明らかに他の誰かが使用できると思いますか？
https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf w/EBSを処理するためのAmazonの公開プロセスについて説明しています。 2つの引用が関連しているようです：
Amazon EBSボリュームは、利用可能になる前にワイプされた未フォーマットの未フォーマットブロックデバイスとして提示されます
だけでなく
EBSスナップショットは、EBSボリューム全体のブロックレベルのビューです。削除されたファイルなど、ボリューム上のファイルシステムを介して表示されないデータは、EBSスナップショットに存在する可能性があることに注意してください。
最も可能性が高いのは、データを削除したスナップショットからボリュームを作成している場合です。
新しいPIOPS、gp2、および磁気ボリュームを使用してus-east-1でシナリオを再現しようとしましたが、データを回復できませんでした。
つまり、KMS暗号化ボリュームを利用することで、EBSデータをさらに保護できます。
AWSドキュメント から
削除されたEBSボリュームによって使用される物理ブロックストレージは、別のアカウントに割り当てられる前にゼロで上書きされます。
their forums のAWS担当者から。
お客様のボリューム（EBSまたはインスタンスストレージボリューム）が終了すると、他のお客様が使用できるようになる前に完全に消去されます。
これが本物であり、本当に誰か他の人のデータがある場合は、AWSに連絡する必要があります。異常な主張には異常な証拠が必要です。
TLDR;2セットのテストを行ったところ、@ stevelandissが生成した結果を再現できませんでした。
更新-テスト1
自分で試してみました。これが私がやったことと私の結果です。
TLDR;再現できませんでした。
0）gp2ボリュームとio1（プロビジョニングされたIOPS）ボリュームがそれぞれ10 GBのm3.mediumスポットインスタンスを割り当てました。標準の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
チェックのためにディスクをマウントしようとしましたが、もちろんファイルシステムがないため失敗しました
マウント/ dev/xvdba/gp2 /マウント：不正なfsタイプ、不正なオプション、/ dev/xvdba上の不正なスーパーブロック、不足しているコードページまたはヘルパープログラム、またはその他のエラー
場合によっては、syslogに役立つ情報があります-dmesgを試してください。尾かそこら。
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
IO1プロビジョニングIOPS
ご覧のとおり、ファイルは見つかりませんでした。 @stevelandissが彼のやり方を別の方法で指摘できる場合は、もう一度再現してみることができます。たとえば、マウントについては何も触れられておらず、別のデバイス名を使用しています。数分マウントせずに再試行しますが、失われないようにこの更新を保存します。
更新-2つをテスト
今回はほぼ同じですが、ファイルシステムの作成やディスクのマウントは行いませんでした。これは、@ stevelandissが行ったことに近いです。これは違いがなく、ファイルは回復されませんでした。
GP2
IO1プロビジョニングIOPS
wipefs のmanページから：
wipefsは、ファイルシステム自体やその他のデータをデバイスから消去しません
ボリュームに関する詳細情報が必要です。どのように作成しましたか？あなた以外に誰も作成していないことを100％確信していますか？
AWSは彼らがどのようにテクノロジーを設計したかを共有していないので、私はNetApp認定のストレージ担当者だと思います。 EBSボリュームは、RAIDグループ上に構築された抽象化レイヤーです。 1つのディスクだけになるとは思えません。したがって、ボリュームをプロビジョニングするたびに、さまざまな物理デバイスから問題が発生します。そのため、完全なファイルを取得することはほとんど不可能です。
ボリュームのプロビジョニング方法について詳しく教えてください。しかし、私はあなたがどこかで間違いをしていると思います。さもなければ、これはそのような基本的な機能に関する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ユーザーがいますか？おそらく、そのボリュームをインスタンスに接続して、そのように使用したのでしょう。