уничтожение данных
Здравствуйте, в Recuva после многократной перезаписи (35 раз) файлов, если попытаться найти удалённые файлы, всё равно видны их названия. Правда при восстановлении такого файла информация недоступна, но как сделать, чтобы и названия нельзя было увидеть? Может программу посоветуете.
комментариев: 9796 документов: 488 редакций: 5664
Есть простая контрмера: создаёте шифрованный LVM-том (раздел) нужного небольшого размера и делаете его чистую копию на другой LVM-том (раздел). Когда надо затереть файлы, просто делаете luksClose, luksKillSlot и форматируете его заново, после чего восстанавливаете содержимое из чистой копии (бэкапа). Это быстрый и надёжный способ удаления файлов. А в других разделах исходите из того, что быстро затереть их нельзя. В общем, это скорее организационный вопрос.
комментариев: 9796 документов: 488 редакций: 5664
Очевидно удачный пример использования LVM-ов. Разве что пересоздавать файловую систему заново и заново переносить все файлы на чистую FS может занять заметное время.
Есть ещё всякие free-space-over-FS вайперы, наподобие secure-delete, но особого доверия к ним нет.
Поэтому нужно делать такие файловые системы компактными и хранить на них только то, что реально необходимо — например, логи и настроки IM. У меня примерно такая схема работает для юзера, из-под которого запускается TBB. На файловой системе ничего кроме нескольких конфигов и распакованного бандла TBB нет, всё распаковывается и зачищается за секунды, при этом можно быть уверенным, что всё временное и неважное, связанное с работой браузера в сети, надёжно зачищается.
комментариев: 11558 документов: 1036 редакций: 4118
С теми же целями (если данные нужны в пределах одного сеанса) можно использовать tmpfs, даже слоты в случае чего убивать не нужно.
Но swap лучше шифровать или отключать.
Можно, и это даёт ряд преимуществ, но менее гибко. Например, если у меня есть временный пул важных файлов, который я ещё не успел перенести на постоянный раздел, я буду расстроен, если они утеряются из-за внезапного зависания системы и перезагрузки. К тому же, иногда надо перезагрузиться, а времени скопировать файлы нет — в этом случае копирование можно отложить, если используется убивание слотов LUKS, но нельзя, если используется tmpfs.
Подтверждаю. + В тему этих комментариев: делаешь, как описано — df показывает всё равно наличие некоторого свободного места на файловой системе. Повторяешь с другим именем файла — и оно иногда уменьшается, иногда нет. Но факт, что второй файл создаётся, а также создаётся и третий и т.д. Где они создаются, если ФС уже забита? Значит, не всё забито, есть ещё место для хранения данных, есть какие-то резервы. И, вообще, в отличие от BSD, в Linux df показывает где-то на 5% меньше свободного места для ФС, чем есть на самом деле (Used+Avail≠Size в df).
комментариев: 11558 документов: 1036 редакций: 4118
Зарезервировано для рута.
Спасибо за информацию. Теперь заодно понял, почему раньше ноль писалось, а потом перестало (ранее из-под рута тёр).
Вы про низкоуровневый доступ к SSD? Там с HPA что-то не очень вразумительное происходит.
А люди не верят в возможность надёжного частичного затирания данных на SSD, если вы об этом.
Ну, и, вообще, SSD — это отдельный вопрос.
К любому ATA-устройству. В HPA разве записываются пользовательские данные? Скорей всего нет, поэтому даже если Secure Erase его не затирает, в этом нет необходимости.
Про надёжность не говорилось. Перечислено то, что в любом случае необходимо сделать при уничтожении данных. А для обычных HDD-дисков можно утверждать что этого достаточно.